前幾天把 Model Routing、Semantic Cache 和 Cache Invalidation 接起來之後，整套系統開始有一點 Production 的樣子，簡單問題不一定要送最貴的模型，遇到重複問題也可以先看看 Cache 裡有沒有答案，不過真正開始跑完整流程之後，我又遇到一個很直接的問題：明明每個元件單獨看起來都不算慢，使用者還是會覺得整個 AI 系統等很久。

如果只看最後畫面，我能拿到的資訊通常只是一個數字：

Response Time: 6.8 sec

6.8 秒確實很慢，但這個數字對 Debug 幾乎沒有幫助，因為我不知道這 6.8 秒到底花在哪裡。

可能是 API Gateway 等了 300ms，也可能是 Embedding 花了 500ms、Vector Search 花了 200ms、Reranker 又花了 800ms，最後真正呼叫 LLM 才用了 4 秒，如果全部混成一個 Response Time，我只知道系統慢，卻不知道第一刀該從哪裡下。

先不要急著怪模型

做 AI 系統時很容易看到等待時間變長，就直接覺得是模型太慢，然後開始考慮換一個更小的 Model。

但我把 RAG 流程拆開之後，發現一次 Request 其實可能經過很多地方：

Request
Intent Classification
Embedding
Vector Search
Reranking
Prompt Building
LLM Generation
Output Validation
Response

假設最後量到：

Intent Classification   180 ms
Embedding               420 ms
Vector Search           160 ms
Reranking               920 ms
Prompt Building          35 ms
LLM Generation         3870 ms
Validation              110 ms

總時間大約 5.7 秒。

這時候當然還是 LLM 最慢，但 Reranking 已經快接近一秒，如果某些簡單 Query 根本不需要 Reranking，那光是判斷哪些 Request 可以跳過，就有機會把等待時間再往下壓。

換一個更快的模型可能有用，但那只是其中一個選項。

Average Latency 其實很容易騙人

一開始我最直覺會記平均值，例如今天 100 次 Request 平均是 3.2 秒，看起來好像還可以。

但如果實際資料是大部分 Request 都在 2 秒內完成，少數幾次突然跑到 10 秒甚至 20 秒，平均值最後可能還是很好看，可是真正碰到那幾次的使用者只會覺得系統是不是壞掉。

所以 Production 裡常會一起看：

P50
P95
P99

P50 可以大概看一般使用者平常遇到的速度，P95 則開始反映那些比較慢的尾端 Request。

例如：

P50 = 2.1 sec
P95 = 6.7 sec
P99 = 12.4 sec

這組數字就比「平均 3.0 秒」有意思很多，因為它直接告訴我，雖然大部分 Request 還可以，但有一小部分真的慢得很誇張。

接下來就可以去找 P95、P99 的那些 Request 有什麼共同點，是 Prompt 特別長、Retrieval 文件特別多、模型輸出 Token 太高，還是外部 API 在某些時段變慢。

TTFT 跟完整回答時間也要分開

另一個我以前比較少注意的數字叫做 Time to First Token。

假設一個回答總共要產生 800 個 Token，完整輸出可能需要 8 秒，但如果第一個 Token 在 700ms 就出現，使用者其實很快就會看到系統開始回答，感覺上通常會比畫面空白 5 秒之後一次跳出完整內容好很多。

所以現在我會把兩個時間拆開：

TTFT = 0.8 sec
Total Generation = 6.2 sec

這時候優化方向又不太一樣，如果 TTFT 很高，可能要看 Request 前處理、Queue、Prompt 長度或模型啟動時間，如果第一個 Token 很快，但完整 Generation 太久，那就要檢查 Output Token、回答長度或 Model 本身的輸出速度。

使用者說的都是一句「AI 很慢」，工程上卻可能是完全不同的問題。

Latency 開始跟前面的 Cost 串起來

前幾天一直在看 Token Cost、Model Routing 和 Cache，今天把 Latency 拆開之後，才發現這些東西其實會互相影響。

用比較小的模型，Cost 可能下降、Latency 也可能變短，但品質可能一起下降；加入 Reranker 可能讓 Retrieval 更準，卻會多一段等待時間；Cache 命中時幾乎可以直接回覆，但 Cache 規則如果設得太寬，又可能拿到已經過期的答案。

所以之後的 Eval 表也不能只看：

Accuracy

我比較想慢慢變成：

Quality
Latency
Token Cost
Cache Hit Rate
Failure Rate

同一個版本改動之後，把這幾個數字一起看。

做到 Day 16，我越來越能理解為什麼一個在 Notebook 裡跑得很漂亮的 AI Demo，搬到真正系統之後會突然出現一堆以前沒想過的問題，因為 Demo 通常只在乎「它回答得對不對」，等真的有人開始用之後，三秒、六秒、十秒的差距都會變成產品體驗的一部分。

所以今天先不急著把系統變快，我想先做到另一件更基本的事，下次有人說「AI 很慢」的時候，我至少可以指出到底是哪一層慢，而不是看著一個 6.8 秒的總時間猜答案。