模型跑得慢，為什麼用戶覺得更慢？

一個反直覺的事實：用戶投訴「太慢了」，往往不是因為總耗時真的很長，而是因為等待體驗出了問題。同樣是等三秒鐘，刷短影片幾乎無感，等一個 AI 回答卻可能讓人想重新整理頁面。這背後是一套可以量化、也可以設計的「延遲感知帳本」。

一、人對時間的感知是非線性的

心理物理學裡的 Weber-Fechner 定律告訴我們：人對刺激強度的感受是對數關係，對時間也同樣如此。等待 0.5 秒和 1 秒的差別很小，但從 5 秒到 10 秒卻是質變——大腦會把「超出預期等待」自動歸類為「卡住了」。更微妙的是，不確定的等待比已知的等待顯得更長。醫院告訴你「還要等四十分鐘」，反而比「快了快了」更容易讓人平靜，因為前者給了大腦一個可以預期的錨點。

對 AI 產品來說，這意味著：把延遲從 8 秒優化到 6 秒，用戶可能毫無感覺；但加一個「正在思考…」的進度指示，投訴會立刻下降。不是玄學，是預期管理。

二、首字延遲才是真 KPI

傳統 Web 效能有 TTFB（首字节時間），LLM 應用裡對應的指標是 TTFT（Time To First Token，首字延遲）。大量線上 A/B 測試反覆驗證：用戶對 AI 回答的滿意度更多由 TTFT 決定，而不是總生成時間。原因很簡單——第一個 token 出現之前，大腦處於「系統是否活著」的不確定焦慮中；一旦文字開始流動，等待就變成了「閱讀節奏」問題，而閱讀本身是愉悅的。

這就是為什麼串流輸出（streaming）幾乎是所有 LLM 產品的標配。後端總耗時一秒沒少，用戶感知卻快了一倍。搭配「思考中」的骨架螢幕、逐字渲染的打字機效果，感知延遲可以被壓縮到實際延遲的一半以下。

三、延遲的帳要分層記

一次 AI 請求的時間軸其實很長：網路往返、驗證、prompt 組裝、prefill（處理輸入）、decode（逐字生成）。工程上常見的坑是只盯總耗時，結果優化錯了地方。舉例來說：prefill 時間與輸入長度平方相關，一個塞滿上下文的請求光 prefill 就要兩秒；這時你優化 decode 速度毫無意義，應該先做上下文瘦身或者 KV cache 重用。

另一個常被忽略的變數是輸出的確定性。同樣的問題，用戶不知道會得到半句還是三百字時，等待顯得格外漫長。聰明的做法是先給出一個短的結論影格（哪怕只是「找到了，共三點」），再展開細節——把不確定的長等待拆成確定的短等待。

四、什麼時候快反而是壞事

最後一個少有人討論的角度：即時回覆有時反而傷害信任。秒回的客服讓人懷疑是機器人；瞬間產生的報告讓人懷疑沒認真讀材料。適當的「思考時長」反而是品質訊號。所以延遲優化的終點不是把所有時間壓到零，而是讓每一段等待都有意義、有回饋、可預期。

延遲感知是一門把工程指標翻譯成心理體驗的學問。記住這本帳的三條規則：先優化首字，再優化總時長；給等待一個錨點；把長任務切成有回饋的短段。做到這三條，六秒的用戶滿意度可以勝過三秒的沉默。