評估 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