LLM串流生產實現：SSE、保活機制與斷線恢復

三個生產穩定性環節：代理超時配置、保活事件定期發送、客戶端斷線恢復邏輯

在生產環境中部署大型語言模型（LLM）應用時，串流（Streaming）是提升用戶體驗最直接的技術手段。相較於等待模型生成完整回覆後一次性輸出，串流允許系統逐字符傳送內容，用戶幾乎能即時看到回應開始出現。

本文聚焦伺服器傳送事件（Server-Sent Events，SSE）的生產實現，涵蓋保活機制、超時處理與客戶端重連設計——這三個環節是AI應用串流穩定性的基礎，亦是供應商提案中最少被主動說明的技術細節。

為何選擇串流

LLM的回應生成時間與輸出長度成正比。對於需要輸出500至2000個Token的任務，若等待完整回覆，用戶端可能需要面對10至30秒的空白等待，這在實際應用中幾乎不可接受。

串流模式下，用戶在生成開始後數百毫秒內即可看到首個Token（Time to First Token），後續內容持續出現，感知上的響應速度大幅提升，即使總體生成時間相同。

SSE的基本結構

SSE是HTTP協議的單向推送機制，由伺服器主動向客戶端推送事件流（Content-Type: text/event-stream）。相較於WebSocket，SSE更為輕量，且天然與HTTP/2相容，無需處理雙向連接狀態。

在代理串流（Proxy Streaming）模式下，後端伺服器接收LLM API的串流後，再轉發至客戶端——這是生產環境最常見的架構，因為API密鑰不應暴露在客戶端瀏覽器中。主流LLM API（Anthropic、OpenAI、xAI）均支援SSE格式的串流端點。

保活（Keepalive）機制

生產環境中，串流最常遇到的問題是中間代理——Nginx、Cloudflare CDN、負載均衡器——的超時配置。若LLM在生成長文本時出現短暫停頓，尤其是啟用深度推理的模型，停頓可達數十秒至數分鐘，中間代理可能判定連接已無活動而主動斷開。

斷線恢復設計

即使有保活機制，移動網絡或長任務場景下仍可能發生連接中斷。完整的客戶端應設計恢復邏輯：

• 連接中斷時，記錄已接收內容的狀態至本地
• 以指數退避策略重試連接
• 向伺服器請求從最後確認位置繼續輸出

若任務時長可達數分鐘（如長文件分析、複雜推理任務），客戶端的最大等待上限應設定足夠長，避免過早放棄任務。伺服器端需將中間生成結果暫存至數據庫，以支援後續的恢復請求。

超時配置清單

小結

串流的技術實現並不複雜，但生產穩定性取決於三個環節：中間代理的超時配置、伺服器端保活事件的定期發送，以及客戶端的斷線恢復邏輯。忽略任何一環，在長任務或移動網絡環境下都會導致用戶體驗崩潰。評估供應商提案時，可主動詢問其串流實現是否包含保活機制及斷線恢復設計。

更多AI系統架構分析，可參閱AI Agent還是固定Pipeline：點揀啱你用例嘅架構，以及AI應用的靜默失敗：每個錯誤都必須留下記錄。