跑了幾個月 LLM 實驗，四個違反直覺的心得：便宜的模型最貴
我們在 pvl-dual-rail、AutoGEO 內容管線與 Studio 影像流程上跑了幾個月的模型比較，累積了一批不算好看但很有用的帳單。這篇整理四個和直覺相反的結論——它們的共同點是：單看每百萬 token 的單價做決策，幾乎每次都會做錯。
先講結論：LLM 的成本不是「單價 × 用量」，而是「單價 × 用量 × 重試次數 ÷ 一次做對的機率」。分母被忽略時，所有的省錢決策都在虧錢。
一、不同任務分派不同模型，不要用一個模型打天下
最容易做、效益也最直接的一件事，是停止用單一模型處理所有工作。
我們的管線裡至少有四種性質完全不同的任務：
任務性質 | 例子 | 適合的模型檔次 |
|---|---|---|
機械性轉換 | 格式整理、欄位抽取、標籤分類、翻譯草稿 | 小型／快速模型足夠 |
結構化判斷 | 內容機會評分、風險規則比對、摘要重寫 | 中階模型 |
開放式推理 | 架構設計、診斷根因、長文寫作、跨文件比對 | 旗艦模型 |
高風險輸出 | 對外文案、品牌事實更正、客戶交付物 | 旗艦模型＋人工閘門 |
把機械性任務丟給旗艦模型，是在為不需要的推理能力付錢；把開放式推理丟給小模型，則是在為「看起來完成了、其實不能用」的輸出付錢——後者貴得多，因為錯誤會流到下游才被發現。
實務上的做法是路由（routing）：依任務類型、輸入長度與失敗成本，把請求分派到不同檔次的模型。這正是我們把 `pvl-dual-rail` 開源出來的原因——它處理的就是「哪些請求走哪條軌道」這件事。
判斷準則：問「這個任務做錯了，多久會被發現、修正要花多少錢？」答案是「立刻發現、重跑一次就好」的，用便宜模型；答案是「幾天後客戶告訴我們」的，用貴的。
二、便宜不一定是最佳解：把重試次數算進去
這是最違反直覺的一點。假設有兩個模型：
- A 模型：單價低，但這類任務一次做對的機率約 55%
- B 模型：單價是 A 的 5 倍，一次做對的機率約 92%
只看單價，A 便宜 5 倍。但把重試算進去，A 平均要跑 1.8 次才得到一個可用結果，B 只要 1.09 次——實際成本差距從 5 倍縮到不到 3 倍。而這還沒算上真正的大宗開銷：
- 人工審核時間：A 產出的結果有將近一半要人看過、退回、重下指令。這段時間比 token 貴得多。
- 除錯與追查：低品質輸出常常不是「明顯壞掉」，而是「看起來對但細節錯」。這種錯誤要花時間才抓得到。
- 下游污染：錯誤內容如果進了知識庫或已發佈的頁面，清理成本是原本生成成本的數十倍。
我們實際遇過的情況是：某個抽取任務改用便宜模型後，token 帳單降了六成，但那個月花在人工修正上的時間反而讓整體交付變慢。帳單變好看了，成本變高了。
判斷準則：便宜模型適合「錯了也無所謂、重跑很便宜、錯誤立刻看得出來」的任務。只要三個條件缺一個，就要重新算。
三、用貴的模型，一次把事做好
第二點的自然延伸，但值得單獨講，因為它牽涉到一個容易被忽略的成本：上下文重建的代價。
當你用便宜模型做複雜任務、失敗、然後重試時，你付的不只是第二次的 token 費用。你還要：
- 重新送一次完整的上下文（長 prompt 的情況下，這本身就是主要開銷）
- 承擔多輪對話的累積延遲
- 在多步驟管線裡，可能要回滾前面已完成的步驟
一次做對，省掉的是整條鏈的重跑。這在長上下文任務上特別明顯——當 prompt 本身就有幾萬 token 時，「重試一次」的代價接近「重跑整個任務」。
還有一個不容易量化但真實存在的成本：信心成本。當團隊知道某條管線的輸出「大概有一半要重看」，大家就會習慣性地不信任它，於是每一筆都要人工檢查——自動化的價值就消失了。用可靠的模型讓通過率拉到九成以上，人工檢查才能從「每筆都看」降級成「抽檢」，這個轉變帶來的效益遠超過模型價差。
判斷準則：如果一個任務要進入自動化管線（沒有人會逐筆看），就用你負擔得起的最好模型。自動化的前提是可信，不是便宜。
四、Max Tokens 設太小，等於錢花了卻什麼都沒拿到
這是最容易犯、也最痛的一個錯——因為它的失敗方式最隱蔽。
輸出被 `max_tokens` 截斷時，你已經付了：完整的輸入 token 費用，加上截斷前產生的所有輸出 token 費用。但你拿到的是一段不完整的內容——JSON 少了收尾括號、文章斷在半句話、表格只有一半。這種情況下的回收率是零：付了全額，得到不能用的東西。
更糟的是它常常不會報錯。API 回傳 200，內容看起來像是成功了，直到下游解析失敗（或更糟：解析成功但內容缺漏）才發現。
我們的做法：
- 先量測，再設定。 拿實際任務跑 20–30 次，記錄輸出長度分布，取 P95 再加上 30–50% 的緩衝，而不是憑感覺設一個整數。
- 監控 `finish_reason`。 這是最直接的訊號。如果 `length`（截斷）的比例超過 1–2%，上限就設得太緊了。
- 結構化輸出要留額外餘裕。 JSON、表格這類有閉合結構的輸出，截斷的破壞性遠大於純文字——純文字截斷還能用前半段，JSON 截斷就是整筆報廢。
- 針對任務分別設定，不要用全域預設。 分類任務給 200 token 就夠，長文生成給 200 token 就是保證失敗。
- 把截斷當成錯誤處理，不要當成正常回應。 偵測到 `finish_reason: length` 就重試或升級模型，不要讓半截內容流進下游。
判斷準則：`max_tokens` 不是省錢的旋鈕，是安全閥。想省錢應該從 prompt 精簡、模型選型、快取下手，而不是從掐輸出上限下手——那不會省到錢，只會把已經花掉的錢變成廢品。
把四點收成一句話
這四個心得指向同一個原則：優化的對象應該是「每個可用結果的總成本」，不是「每百萬 token 的單價」。
實作上就是三件事：把任務分級、依級數選模型、用實測數據設參數。這件事本身也是我們 AI Operational Excellence 方法論的一部分——AI 能力要能持續運作，前提是它的成本結構被理解、被量測、被治理，而不是每個月看帳單猜哪裡出了問題。
模型每隔幾個月就換一批，但這套判斷方法不會過期。