模型跑得不慢，為什麼你還是覺得慢？延遲感知的三筆帳

上一篇我們聊了 AI 延遲（latency）的基本帳本：首字延遲、生成速度和端到端完成時間。這一篇把鏡頭拉近一點，看看一個更微妙的問題：為什麼同樣的技術指標，在不同產品裡給人的感受可以差出好幾倍？答案不在模型裡，在延遲感知這本帳上。

第一筆帳：等待的質比量更重要

人腦對等待的估計從來不是秒表。心理學裡有個經典結論：充滿資訊增量的等待顯得短，空洞的等待顯得長。一個 3 秒的載入過程，如果不斷有進度回饋（打字機效果、步驟提示），體感可能只有 1.5 秒；一個靜止 3 秒的轉圈，體感可能是 5 秒，還會伴隨是不是卡死了的焦慮。

對 AI 應用來說，這意味著首字延遲（TTFT, Time To First Token）不只是工程指標，更是體驗槓桿。把 TTFT 從 800ms 壓到 300ms 的收益，遠大於把總生成時間從 10 秒壓到 8 秒——因為前者消除的是有沒有反應的不確定，後者只是縮短了反應多久的確定等待。

第二筆帳：可預測性抵得過絕對速度

等公車的體感很說明問題：知道還有 2 分鐘到站，等待是安心的；不知道要等多久，1 分鐘都開始令人煩躁。AI 產品同理。串流輸出（streaming）最大的功勞不是更快得到答案，而是把不可預測的黑盒等待，變成了可預測的、逐字兌現的承諾。

所以工程上排優先級時，可以按這個順序自問：

1. 能不能讓第一個可見回饋更快？（路由到小模型先答、快取命中、預熱連線）
2. 回饋節奏是否穩定？（避免卡頓後突然吐出一大段，tok/s 的變異數比平均更傷體驗）
3. 最後才輪到壓縮總時長。

第三筆帳：認知負荷偽裝成延遲

很多覺得慢其實不是系統慢，是用戶在等的時候無事可做：答案太長、結構太亂，讀完的負擔被誤記為等待成本。這也是為什麼同樣 2000 token 的輸出，帶清晰小標題和清單的版本感覺更快——用戶能掃讀、能提前拿到結論，認知流水線提前下班了。

把帳本攤開給系統看

具體到落地，建議給產品埋三個感知指標：首個可見位元組時間、tok/s 的 P95 變異數、以及用戶中途停止生成的比例。第三個尤其誠實——它是用戶用腳投票給出的延遲滿意度評分。技術指標告訴你系統快不快，感知指標告訴你用戶覺不覺得快，兩者都對上，這本帳才算平了。

下次優化 AI 體驗時，別只盯著 dashboard 上的平均值。用戶心裡那本延遲帳，記的是體感，不是毫秒。