換模型不會改變它有沒有找到對的那份文件

客戶問過我兩個問題。

「那我要買多大的模型？」

「Mac Studio 兩百五十六 G，能跑多大的？」

第二個問題我答得出來。第一個問題問錯了。

「模型要多大」這個問法預設了一件事：答得準不準是模型的事。在檢索問答上不是。找到對的那份文件，從頭到尾是程式在做——切段、計分、選段、早退、轉人工規則，模型看不到，也影響不到。所以這個問題要拆成兩半，而只有後面那一半跟參數量有關。這篇是把它拆開來量的過程。

中間那五列，四個模型完全一樣

同一份語料、同一組題目、同一套外層程式，只換模型。三十題各跑三輪，每個模型九十次作答。

指標	qwen3:14b	llama3.1:8b	qwen2.5:7b	qwen3:4b
hit@1	95%	95%	95%	95%
hit@5	100%	100%	100%	100%
平均送出來源	3 段 / 240 字	3 段 / 240 字	3 段 / 240 字	3 段 / 240 字
答不出來的召回	100%	100%	100%	100%
轉人工的召回	100%	100%	100%	100%

跨越 4B 到 14B、三倍半的參數量差距，這五列一個小數點都沒有動。

那不是巧合，是設計：切段、計分、選段、早退、轉人工規則都是程式，模型看不到也影響不到。

換模型不會改變它有沒有找到對的那份文件。換模型改變的是，它把找到的東西寫成什麼樣。

這也是地端可行的理由。找文件那一半的品質，跟你買不買得起大模型無關。

差別在它怎麼講話，而最會講的那個最慢

指標	qwen3:14b	llama3.1:8b	qwen2.5:7b	qwen3:4b
全部通過	90/90	90/90	87/90	60/90
台灣用語瑕疵	0 題	0 題	0 題	26 題
平均輸出長度	50 字	38 字	49 字	689 字
全程 p95	1034 ms	558 ms	480 ms	2421 ms

最小的模型最慢，而且慢得有道理。 扣掉答不出來、根本沒有輸出的那幾題（四個模型都是 84 次有輸出），qwen3:4b 平均寫 689 字，另外三個是 38 到 50 字——十八倍。輸出 token 就是時間，所以它的 p95 是 14B 的 2.3 倍。參數量小省下來的，在話多這件事上全部吐回去了。

它的台灣用語也不行：九十次裡二十六次，其中「用戶」出現二十三次（該是「使用者」）。

另一個反直覺的：8B 跟 14B 打平，都是 90/90，而 8B 的 p95 快將近一倍、回答還最精簡。用參數量猜品質，在這個任務上猜不準——所以才要量。

地端獨有的成本一：冷啟動 20.7 秒

qwen3:14b 的延遲分布是 min 0 ms、p50 560 ms、p95 1034 ms、max 20684 ms。

那 20.7 秒是第一次呼叫時把權重載進 VRAM。回覆一則聊天訊息的預算我們抓 25 秒，冷啟動一次就吃掉 83%。

這件事雲端 API 不會遇到，是地端獨有的。所以地端的機器一定要讓模型常駐，或者開機後先打一次暖機請求；否則第一個上門的客人拿到的，就是最差的那一次體驗。語意檢索是第二個模型，也要常駐——那組「換句話說」的題目第一題花了 4.8 秒，就是它在載入。記憶體規劃要把兩個一起算。

地端獨有的成本二：併發買不到吞吐

在一張 5070 Ti 上、qwen2.5:7b、每一級兩輪、先暖機：

併發	首字延遲	吞吐
1	14 ms	147.2 tok/s
4	366 ms	149.7 tok/s
8	729 ms	150.3 tok/s

吞吐持平，首字延遲線性成長：它是排隊處理的，併發只買到延遲。 第二個人得等第一個人講完。

所以正式要交付的那台機器換掉了推論伺服器，改用會真正批次化的那一種，而不是開發時最方便的那一個。

暖機那一步是後來補的。不丟掉第一次請求的話，載入模型的 2.4 秒會全部算在「併發 1」那一列，整張表會讀起來像「一個人比四個人還慢」——那會是一個由量測方法製造出來的結論。

那麼那些記憶體買到的是什麼

不是找得更準。那一半是程式。

是寫得更好。反過來的一張表：歌詞的字數約束，四行依序 7-7-5-9，精確、不容差。程式數每一行的漢字、對十三轍查押韻，沒中的行帶著具體的抱怨送回去重寫。

模型	命中行數	每首耗時
qwen2.5:7b	2/8	696 ms
llama3.1:8b	4/8	3434 ms
qwen3:14b	6/8	7362 ms

在檢索問答上參數量買不到東西；在硬約束上，參數量單調地買到品質。

原因說得通：檢索的準確度是程式決定的，模型只要讀懂送進去的那五段就好；而「寫一句剛好五個字、又要押韻、又要通順」是模型自己的能力，沒有程式可以代勞——程式只能驗，驗完再要它改。

所以挑模型之前要先問跑的是哪一種任務。 客服問答挑得動就好，十六 G 的卡上 8B 就夠；要寫得像人的那類任務才需要大的。

這樣做的代價

• 一份 28 段語料、一組 30 題、一張顯示卡、一個推論伺服器。 上面每一個數字都在這個範圍內成立，換到客戶自己的文件上一定要重跑。
• 歌詞那張表每一格只跑一次、只有兩個主題。 它是方向性的訊號，不是統計，不該拿去當選型依據。
• 那台大機器還沒到貨。 所有關於它的句子都是推論。地端的容器化驗收也還缺一台裝了 Docker 的機器，現在跑的是一支結構檢查腳本代替。
• hit@1 只有 50%。 對的那一段每次都送進去了，但不一定排第一，所以客人看到的第一個「依據」按鈕不一定是對的那一頁。這一輪沒動它。
• 地端真正的成本不是授權費，是有人要顧。 模型常駐、版本、記憶體規劃、暖機、機器本身。這一條沒有數字，因為它是人。

接下來

對外的網址那一段反而不用錢：通道本身免費，要付的只有網域年費。所以地端的報價可以完全建立在導入與維運上，不必為基礎設施加價。

真正還沒做的是最後一步：把這三篇的做法搬到一間真的店，用他們自己的文件、他們自己的客人問法，重跑一次同樣的 eval。因為上面每一個數字，都是我們自己出題自己考的。