慢不是模型慢：AI 服務延遲裡藏著四個可量化的成分

上週幫一個團隊看線上問題：客服機器人回答太慢，用戶投訴，老闆一句「換更快的模型」。換完之後，P95 延遲降了大概 400 毫秒，投訴還是沒少。問題出在哪？他們只測量了「模型推論」這一段，但用戶感知到的等待時間裡，模型推論只佔一小塊。

把一次完整的 AI 服務呼叫拆開，延遲通常由四段組成：**網路往返、排隊等待、prompt 處理（prefill）、逐 token 生成（decode）**。這四段的性質完全不同，對應的優化手段也完全不同，混在一起看就會得出「換模型」這種籠統結論。

**網路往返**好辦，測 `t_proxy` 就行：從請求發出到收到第一個位元組。跨地域疊加 TLS，單次 80 到 200 毫秒是常態。這一段優化的辦法是把推論服務部署得離用戶近，或者用串流回應保持長連線，作用有限但上限明確。

另外別忘了**客戶端到閘道器**之間還有一段：用戶端自己調 API 的逾時設定如果只有 10 秒，你的服務明明 12 秒能答完，在用戶眼裡就是「掛了」。跨團隊聯調時，先把雙方的逾時對齊，比調任何參數都快。

**排隊等待**是最容易被忽略、也最容易出事的一段。連續批次處理（continuous batching）下，你的請求可能前面排著幾十個。同一個「7B 模型」，空閒時首 token 200 毫秒，高峰期 3 秒都不奇怪。這段延遲和流量強相關，所以必須按分位數監控——看均值會騙自己，P95 和 P99 才是真實體驗。

一個容易踩的坑：把「首 token 時間」當成整體 SLA。服務端報了 P95 首 token 800 毫秒，體感很好；但輸出平均 500 個 token，decode 每秒 40 個，用戶拿到完整答案要等 13 秒。首 token 快只影響「是否開始焦慮」，完整答案時長決定「是否放棄等待」，兩個都要盯。

**prefill** 和併發也有關係，但有硬下限：一次處理上萬 token 的長 prompt，就算 GPU 全空，首 token 也要等上幾秒。所以「長文件問答」類和「短問句」類的服務，延遲基線天然不同，不能用一套 SLA 管。

實測裡經常看到的現象：同一個模型，1 萬 token 的 prompt 首 token 約 1 秒，8 萬 token 直接 8 到 10 秒。這不是模型變慢了，是被 prompt 長度壓住了。所以「把歷史對話全塞進 prompt」的寫法，延遲代價是線性增長的，用戶側完全無感知但帳單和時延雙漲。截斷、摘要、或者檢索只注入相關片段，都是針對這一段的槓桿。

**decode** 是逐 token 輸出，速度基本由顯存頻寬決定（每生成一個 token 都要讀一遍 KV cache），升級頻寬更高的顯存直接受益。但用戶從「看到第一個字」開始就不焦慮了，所以體感上 decode 慢 50% 未必有人投訴，首 token 慢 500 毫秒一定有人投訴。

這也是為什麼你覺得「答得不快但沒人罵」，而競品「首句快但尾部毛糙」反而體驗更好——進度感本身就是產品能力，串流輸出基本是標配。

怎麼落地

三個動作，兩週能做完：

1. **拆開計時**。在閘道器層記錄四個時間點：請求到達、首位元組、串流中間點（比如第 10 個 token）、完成。不拆，一切優化都是猜。

2. **監控用分位數**。按 P50 / P95 / P99 分別報四段延遲，趨勢上任何一段惡化超過 30% 就告警，不用等用戶投訴。

3. **按場景設 SLA 和降級**。短問句服務承諾 P95 首 token < 1.5 秒；長文件場景單獨放寬。佇列長度超閾值時，直接降級到小模型或返回「排隊中」，別讓請求在佇列裡無限膨脹——一個 30 秒佇列裡的 100 個請求，不如在 3 秒內讓一半走小模型。

「換更快的模型」只有在 decode 段佔比超過 50%、且當前模型確實小一個數量級時才划算。在動手之前，先花一天把四段延遲的量打出來——大多數團隊量完會發現自己排隊等了半天，白升級了顯示卡。