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