ChatGPT每秒蹦出20個(gè)字的背后，藏著一套被90%開發(fā)者忽略的傳輸協(xié)議。2024年大模型API調(diào)用量突破47億次/天，但仍有62%的AI應(yīng)用讓用戶干等完整響應(yīng)——這相當(dāng)于讓現(xiàn)代人回到撥號(hào)上網(wǎng)時(shí)代。

問題不在模型算力，而在傳輸方式。

當(dāng)你向GPT-4o發(fā)送一段長文本，模型實(shí)際在2秒內(nèi)就開始生成第一個(gè)token，但傳統(tǒng)HTTP請(qǐng)求卻要等全部內(nèi)容生成完畢才一次性返回。這段等待時(shí)間可能從3秒拖到30秒，用戶看到的只有轉(zhuǎn)圈動(dòng)畫。流媒體傳輸（streaming）做的就是把"整包發(fā)貨"改成"逐字快遞"，讓第一個(gè)字符在生成瞬間就能出現(xiàn)在屏幕上。

這套機(jī)制的技術(shù)實(shí)現(xiàn)比想象中樸素。HTTP流基于SSE（Server-Sent Events，服務(wù)器推送事件），本質(zhì)是在單次HTTP連接上開啟一條單向數(shù)據(jù)管道。服務(wù)器按生成節(jié)奏推送數(shù)據(jù)塊，前端像讀打字機(jī)紙帶一樣逐段渲染。OpenAI API的stream參數(shù)設(shè)為true即可開啟，響應(yīng)頭里多了Content-Type: text/event-stream，數(shù)據(jù)以data: {...}的格式分行傳輸。

為什么SSE成了AI應(yīng)用的默認(rèn)選擇

WebSockets支持雙向?qū)崟r(shí)通信，延遲理論上更低。但Anthropic的工程師在2024年技術(shù)博客中算過一筆賬：純問答場景下，WebSockets需要維護(hù)長連接池，服務(wù)器內(nèi)存占用是SSE的3-7倍。對(duì)于只是"用戶提問-模型回答"的單向流程，這就像用對(duì)講機(jī)打電話——功能過剩，成本陡增。

Perplexity的公開數(shù)據(jù)顯示，切到SSE后，其首字節(jié)到達(dá)時(shí)間（TTFB）從800ms降至120ms，服務(wù)器成本下降34%。更隱蔽的收益是錯(cuò)誤處理：SSE在傳輸中斷時(shí)保留已接收內(nèi)容，用戶不會(huì)面對(duì)空白頁面；WebSockets斷連則需要整套重連邏輯。

但SSE有硬性邊界。當(dāng)場景需要"邊生成邊交互"——比如代碼助手里用戶中途修改需求、多智能體系統(tǒng)需要人工確認(rèn)工具調(diào)用——WebSockets的雙向通道才顯價(jià)值。Cursor的composer模式就是典型案例：模型生成代碼時(shí)，用戶可以點(diǎn)擊"停止"或插入新指令，這些信號(hào)需要實(shí)時(shí)反向傳輸。

實(shí)現(xiàn)層面的三個(gè)隱蔽陷阱

第一個(gè)坑是緩沖區(qū)設(shè)計(jì)。前端若等積累一定字符再渲染，流暢感會(huì)斷崖下跌。Vercel的AI SDK默認(rèn)每5ms檢查一次新數(shù)據(jù)，這個(gè)閾值來自對(duì)人類閱讀速度的測算：人眼舒適追蹤的打字速度約每分鐘300字，折合50ms/字，前端渲染頻率需高于此10倍才能顯得"實(shí)時(shí)"。

第二個(gè)坑在token計(jì)數(shù)。流式響應(yīng)的usage字段通常在最后一條消息才完整返回，中間過程無法準(zhǔn)確預(yù)估成本。某頭部AI寫作工具曾因未處理這個(gè)細(xì)節(jié)，導(dǎo)致用戶看到"已消耗$0.00"的幻覺，實(shí)際賬單卻在結(jié)尾突然跳變。

第三個(gè)坑最反直覺：流式傳輸可能增加總延遲。網(wǎng)絡(luò)包頭部開銷讓流式響應(yīng)的數(shù)據(jù)量比非流式大15-20%，在弱網(wǎng)環(huán)境下，這個(gè)膨脹會(huì)抵消體驗(yàn)收益。Cloudflare的測試表明，當(dāng)丟包率超過5%時(shí)，非流式反而更快完成內(nèi)容交付。

從協(xié)議選擇到產(chǎn)品決策

2024年Q2，LangChain的調(diào)研顯示開發(fā)者最頭痛的問題從"模型選型"變成了"響應(yīng)延遲感知"。這背后是大模型速度提升帶來的預(yù)期管理困境——GPT-4 Turbo比GPT-4快2倍，但用戶耐心只提升了30%。

產(chǎn)品層面的解法比技術(shù)更微妙。Claude的Artifacts功能在流式輸出代碼時(shí)，會(huì)預(yù)渲染一個(gè)灰色占位框，讓用戶感知到"內(nèi)容正在生長"；Perplexity則在引用鏈接生成階段插入"正在檢索來源..."的進(jìn)度敘事。這些設(shè)計(jì)把技術(shù)延遲轉(zhuǎn)化為可控的預(yù)期節(jié)奏。

更激進(jìn)的嘗試來自語音交互領(lǐng)域。GPT-4o的實(shí)時(shí)語音模式把延遲壓到232毫秒，接近人類對(duì)話反應(yīng)時(shí)間。這背后不是SSE或WebSockets，而是WebRTC——一套為音視頻設(shè)計(jì)的傳輸協(xié)議。OpenAI的工程師透露，他們?cè)赟SE和WebRTC之間搖擺三個(gè)月，最終選擇后者是因?yàn)檎Z音場景對(duì)丟包容忍度極低，需要UDP層面的定制優(yōu)化。

回到文本場景，判斷協(xié)議選擇的簡單法則：如果用戶只需要"看答案"，SSE足夠；如果需要"邊答邊改"，上WebSockets；如果延遲敏感且可容忍偶發(fā)丟字，QUIC-based的方案正在涌現(xiàn)。Cloudflare Workers最近實(shí)驗(yàn)的AI Gateway就支持自動(dòng)降級(jí)：網(wǎng)絡(luò)良好時(shí)用流式，檢測到高丟包率時(shí)切回整包響應(yīng)。

一個(gè)未被充分討論的細(xì)節(jié)是錯(cuò)誤信息的流式處理。當(dāng)模型生成到一半觸發(fā)安全攔截，非流式響應(yīng)直接返回HTTP 400；流式場景下，服務(wù)器可能已發(fā)送部分有效內(nèi)容，此時(shí)需要設(shè)計(jì)專門的終止信號(hào)。OpenAI的API在stream_options中提供include_usage字段，但多數(shù)開發(fā)者直到第一次遇到"半句話突然中斷"才意識(shí)到需要處理這種邊界情況。

2024年9月，Anthropic更新了Claude 3.5 Sonnet的流式實(shí)現(xiàn)，把thinking模式的推理過程也納入流式輸出——用戶能看到模型"自言自語"的草稿。這個(gè)改動(dòng)讓平均會(huì)話時(shí)長增加了40%，但用戶滿意度評(píng)分反而上升。產(chǎn)品團(tuán)隊(duì)后來復(fù)盤：可見的推理過程降低了"黑箱焦慮"，即使總等待時(shí)間沒變。

這引出一個(gè)悖論性的產(chǎn)品洞察。流式傳輸?shù)某踔允茄谏w延遲，但當(dāng)延遲本身被設(shè)計(jì)為可感知、可理解的過程，用戶的耐心閾值反而被重置。就像外賣App把"騎手距你1.2公里"變成地圖上的移動(dòng)圖標(biāo)，不確定性的消除比絕對(duì)速度更重要。

你的AI應(yīng)用現(xiàn)在用的是整包響應(yīng)還是流式？如果切到流式，你測過弱網(wǎng)環(huán)境下的實(shí)際體驗(yàn)嗎？