評估 local model 可用性，我幾乎不看 token/s
我第一次看到有人說某個 local model 跑 45 tokens/second 的時候，完全沒有任何感覺。就像你跟我說這台機器的 IOPS 是 12000，我心想... so what？要看場景啊。
後來 team 在認真評估要不要在公司內部 deploy 一套 local inference，因為有幾個 use case 涉及 IP，不想走外部 API，我才被逼著搞清楚這個數字到底代表什麼。
這個數字為什麼很容易誤導人
25 t/s 跟 50 t/s，聽起來差一倍很多，但如果你在做 streaming chat，兩個都快到讓人看不完。問題是，如果你在跑 reasoning model 處理複雜分析，model 要輸出 1000 tokens 才算一個完整答案，那 25 t/s 要等 40 秒，50 t/s 要等 20 秒，體感差距就很大了。
更弔詭的是 code generation 場景：token/s 高但 time-to-first-token 慢，反而讓使用者更不耐煩。我們 pilot 的時候有一個模型 throughput 很好，但第一個 token 要等 2 秒，工程師說感覺很卡，沒有 flow。換了一個 throughput 低一點但 TTFT 只要 0.3 秒的版本，主觀體驗好很多。所以 token/s 跟「這個模型能不能用」之間，中間有很多層要解。
我實際 evaluate 的方式
我把 use case 拆成三類，每類有不同的 threshold：
Interactive chat / Q&A：使用者在等，要有串流感。我的底線是 TTFT < 1 秒，sustained throughput > 15 t/s。低於這個，使用者會覺得「這個 AI 怎麼這麼慢」，然後就不用了。ROI 直接歸零。
Code assistance / copilot：工程師對延遲的容忍度極低，因為他們在等答案的時候是 blocked 的。測下來的結論是 TTFT 要 < 0.5 秒，不然 context switching 的代價太高。throughput 反而次要，因為有用的 completion 通常不長。
Batch processing / 背景任務（summary、classification、抽取）：使用者不在即時等，速度不是問題，accuracy 和 cost per output token 才是重點。
很多人把這三類混在一起評估，結果搞出一個「對所有場景都差不多堪用」的配置，enterprise 場景反而沒辦法真的上線。
並發這件事
你測的 token/s 是 single user 跑的數字。但 enterprise 部署不是你一個人在用。
我們的場景大概是 50 個 concurrent users，數字出來之後模型的有效 throughput 直接掉了超過 60%。所以現在 evaluate 的時候我一定要跑 concurrent load test，不然數字沒有參考價值。
簡單估算：如果你的 GPU 在 single user 跑 60 t/s，50 concurrent users 大概只剩 15–20 t/s per user（還要看 batching 實作）。這個數字對 interactive chat 已經很緊了。
把 token/s 變得有感覺
後來看到有人做了工具，把 token/s 轉換成「你在讀不同難度文字的速度」——大概 15 t/s 接近你讀 technical doc 的速度，30 t/s 接近你看故事小說，60 t/s 以上你根本讀不完。這個 mental model 很實用，因為它把物理量轉成有意義的參考點。
不過在 enterprise context 我還是會配合 concurrent load 和 P95 latency 一起看，單看一個數字都容易被誤導。
如果你在評估 local model 是否值得 deploy，建議先把 use case 分類，再定義每類的 acceptable latency，然後用那個標準去測。比起直接比 benchmark token/s，這個方法實用很多。
作者：Vivian L