背景：為什么需要流式輸出

大模型的響應通常很長，比如幾百甚至幾千個 token，如果等模型一次性生成完才返回：

• 延遲高：用戶要等很久才能看到第一句話。
• 體驗差：尤其是在聊天、代碼生成等場景，用戶期望“邊想邊說”。
• 內存壓力大：服務器要先緩沖全部結果再返回。

因此很多廠商（OpenAI、DeepSeek、百度、阿里等）會用 流式輸出：

• 模型邊生成邊發送給客戶端。
• 用戶前端邊接收邊渲染。

SSE 流式輸出

SSE (Server-Sent Events) 是 HTTP 長連接 + 文本事件流 協議，由服務器持續推送數據給客戶端，瀏覽器原生支持。

• 數據格式：data: 開頭，\n\n 結束
  SSE的核心就是在原本TCP的字節流基礎上，通過定義特殊的分隔格式（比如每條事件以空行\n\n結束），來劃分消息邊界，方便瀏覽器端按事件逐條處理。
• 單向：服務器 → 客戶端
• 基于 HTTP/1.1：不需要 WebSocket，也不需要額外握手
• 自動重連：瀏覽器的 EventSource 會自動重連

報文示例：

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alivedata: {"choices":[{"delta":{"content":"你"}}]}data: {"choices":[{"delta":{"content":"好"}}]}data: [DONE]

這里 data: 后面就是 JSON，每次推送一小段（chunk），最后 “[DONE]” 表示結束。

如果 chunk 粒度過小，確實會浪費資源，主要浪費在 網絡 IO 開銷 上。

很多廠商還是小 chunk

• 體驗優先：AI 聊天給人的“即時感”很重要，寧可多 IO 也要首字快。
• 心理暗示：用戶看到文字逐漸出現，會覺得模型在思考（即使真實情況是批量生成的）。
• 大部分場景數據量小：和視頻、文件傳輸比，這種文字流的帶寬占用很低，浪費的部分能接受。