AI令牌流式傳輸：重點不在於SSE與WebSocket之爭
本文指出，在生產環境中實現AI令牌流式傳輸的真正挑戰並非選擇SSE還是WebSocket作為傳輸協議，而是需要解決重連、恢復、取消、令牌壓縮、多用户支持等複雜功能。文章提出了一個分離請求與響應流的架構，並強調了在實際部署中存在的巨大差距。
在AI應用中，令牌流式傳輸是將模型生成的令牌實時推送給客户端的關鍵技術。許多開發者首先想到的是SSE（服務器發送事件）與WebSocket的協議選擇，但作者指出，真正的困難並不在此。
文章提出了一種適用於生產環境的架構：將用户提示請求與響應流分離。客户端先通過POST請求提交提示，服務器立即返回一個流ID，然後客户端通過另一個GET請求連接該流獲取令牌。所有令牌在生成後存入一個令牌緩存數據庫中，這樣即使連接中斷，客户端也能從上次斷點處恢復。這種設計天然適用於水平擴展的無狀態服務器，因為任何服務器都可以處理請求或響應。
與WebSocket相比，SSE在這個架構中更為簡單。WebSocket需要客户端維持長連接並自定義消息格式，而SSE通過HTTP標準實現，並且內置了Last-Event-ID支持斷點續傳。但無論哪種協議，都必須解決以下生產級問題：重連與恢復、檢測連接斷開、處理用户取消請求、令牌壓縮（將已存儲的令牌合併為完整響應）以及多用户或多設備同步。
取消功能尤為棘手：當用户點擊停止按鈕時，服務器需要中斷令牌生成，這要求令牌緩存支持讀寫檢查。而令牌壓縮在重連和響應完成後都需要：重連時大量丟失的令牌應一次性發送，而非逐個；響應完成後則需合併存儲供後續歷史查詢。
多用户場景是最複雜的。如果多個用户共享同一個聊天會話，當一個用户發送提示時，其他用户如何自動獲取響應？一種解決方案是將整個聊天會話視為一個響應流，所有提示和響應都在該流上傳輸。
作者強調，簡易演示和博客文章與真正生產部署之間存在巨大鴻溝。多數開發者要麼沒意識到這個差距，要麼低估了填補差距的工作量。作為解決方案，他所在的公司Ably提供了一個基於發佈/訂閲系統的產品，能自動處理上述所有問題，僅需幾行代碼即可集成。