為你的推論使用情境選擇正確的模型

利益揭露：我是 DigitalOcean 的 Solutions Architect，所以文中提到 DigitalOcean 產品時，是「業內人的觀點」而非中立第三方——這些地方我都會明確標示，其餘分析則盡量保持廠商中立。以下皆為個人觀點。

本文的英文版本已發表於 DigitalOcean Community。

一套可重複的方法：用你自己的資料評測來挑選推論模型，並附上 DigitalOcean serverless 的第一手成本數字。方法本身與供應商無關；DigitalOcean 特有的數字都標明出處。

模型選擇能讓成本相差好幾個數量級

模型選型，不是基礎設施、不是提示最佳化、也不是批次處理策略，才是 GenAI 部署中對品質與成本最大的單一槓桿。Claude Sonnet 4.6 標價每百萬輸入 token $3.00；Claude Haiku 4.5 標價 $1.00：在一個簡單的分類任務上就是 3 倍價差。若拿來對比 DigitalOcean Serverless Inference 上一個夠強的開源權重模型，在完全相同的 token 形狀下，這道落差會拉大到 36 倍（量測見 Multi-Model API Cost Governance with the Inference Router，2026 年 6 月）。

這是兩組各自獨立的比較，不是一個層層放大的數字：3 倍價差是 Anthropic 自家產品線內部的差距，36 倍則是另一組獨立量測、對比 DO Serverless 上開源權重模型的結果。如果你要單獨引用其中任一個數字，請把兩者分開講。

如果更小的模型在你的特定任務上能產出同等品質，那麼多用大模型的每一天都是在多付錢，而且不是多付百分之幾，是多付好幾倍。

價格說明： 文中的 token 費率為 2026 年 6 月各供應商文件與 DigitalOcean Inference 定價的公告價。編列預算前請先確認即時費率。模型產品線變動也很快；引用這組比較之前，請先確認是否已有更新的旗艦模型取代文中提到的型號。

選型框架：先定準確度下限，再談成本

正確的順序是 「先找出你任務的準確度下限，再找出能跨過這條線的最小模型」。

把候選模型倒過你的準確度下限，留下能通過的最小那一個。

1. 定義你的準確度下限：在真正重要的指標上，可接受的最低表現。不是「愈好愈好」，而是低於這條線產品就會壞掉的門檻。
2. 用你自己的資料評測：取樣自你生產環境的分布，而不是基準測試的分布。
3. 從小開始往上試：通過你評測的模型都算候選，最便宜的那個勝出。
4. 模型更新時重新檢視：半年前需要 Sonnet 才做得到的事，現在可能 Haiku 就夠了。

翻譯：用 COMET 而非 BLEU，大量翻譯用 NMT 而非 LLM

翻譯暴露出一個根本的評測缺陷：容易計算的指標，往往量不到真正重要的東西。

BLEU 與人類判斷的相關性很差

BLEU（bilingual evaluation understudy）計算模型輸出與參考譯文之間的 n-gram 重疊。它快速而且具決定性。它同時也是一個很差的品質預測指標，只要任務需要細膩度就不準。

COMET（Crosslingual Optimized Metric for Evaluation of Translation）是一個以人類評分訓練出來的神經網路指標。它與母語者評估品質的方式相關性明顯更好，而且可能把 BLEU 的排名整個顛倒過來。BLEU 分數較高的模型，有時 COMET 分數反而較低。

任何認真的翻譯評測都應該以 COMET 為主要指標，BLEU 只當作 sanity check。

大量翻譯 NMT 勝出；細膩度 LLM 勝出

在高量翻譯上，速度差距是決定性的。Google 的 NMT 引擎以毫秒級回傳結果，最快可達 LLM 的 20 倍。DeepL 在高吞吐量下表現相當。

大量翻譯：NMT 是壓印機，LLM 是仔細的抄寫員，比較慢，但更懂細膩之處。

LLM 在長篇 context、慣用語、低資源語言，以及重視品牌調性的文案上勝出。Lokalise 的盲測研究比較了五套引擎在 EN→DE/PL/RU 上的表現，由母語者做兩兩比較，發現 Claude 3.5 的「良好」評價比例最高（78%）。Rapidata 的資料集（DeepL 對比 DeepSeek-R1／Llama／Mixtral，超過 51,000 位母語者，已公開在 Hugging Face 上）則發現，沒有哪一類在所有語言配對與內容型態上全面勝出。

在低資源與特定領域的語言配對上，一個微調過的 3.3B 專才仍然勝過通用的 7-8B 通才。AI 在地化最大的阻礙是信任，不是技術；後編輯（post-editing）流程之所以存在，是因為生產團隊還沒準備好在沒有人工把關的情況下直接發佈 LLM 的輸出，不管基準測試分數多高。

我們實測了什麼：五個模型、三種語言、一套評測框架

為了替這套框架補上數字，我們在 DigitalOcean Model Evaluations（public preview）上跑了一次翻譯評測。設定是：50 題翻譯提示，涵蓋英譯德文、英譯繁體中文與英譯波蘭文，內容包含日常、正式、慣用語與技術類。每一題都附上人工撰寫的參考譯文。評審模型（Claude Opus 4.6）評 Ground Truth Faithfulness（GTF），以 0–1 的尺度衡量與參考譯文的語意等價程度。星號指標的通過門檻是 0.80。

五個模型，同一份資料集、同一個評審、同一組 system prompt、temperature=0：

DeepSeek V4 Flash 在品質上與 Sonnet 相當（GTF 0.781 對 0.784），輸入價格卻低了 27 倍，而且在德文與繁體中文上還略勝 Sonnet。它的輸出也最乾淨：總共 1,367 個 token，沒有任何前言贅詞。Sonnet 則在 50 題中有 14 題加上了「Here is the translation:」，即使指令已經明確要求不要這樣做。

GLM-5.2 的品質分數不錯（0.768），但生成了 68,876 個輸出 token，是 DeepSeek V4 Flash 的 50 倍。以每百萬輸出 token $4.40 計算，冗長度把輸入價格的優勢完全吃掉。Qwen3-32B 也有同樣的問題（43,006 個 token）。這正是本系列第一篇為什麼你的 LLM 帳單是預期的 3 倍所談的冗長度相乘因子的數字版：模型選型不只關乎每個 token 的費率，也關乎模型會產出多少 token。

波蘭文在五個模型中分數都最低（0.653–0.744，德文則是 0.747–0.825），與前面提到的低資源語言論點一致。

其中一題把這道落差背後的失敗模式呈現得很清楚。原文：「Let's not beat around the bush, the project is behind schedule and we need to course-correct.」參考譯文：Nie owijajmy w bawełnę, projekt jest opóźniony i musimy skorygować kurs. Qwen3-32B（GTF 0.4）把這個慣用語譯成 Nie kręćmy się w kółko（「我們別繞圈子」，是另一個慣用語），並把「behind schedule」直譯成 za harmonogramem，而不是自然的 opóźniony。Claude Sonnet 4.6（GTF 0.8）則完全對上了慣用語與措辭，只在「course-correct」的改寫上有無傷大雅的偏離。較便宜的模型在字面與技術性文本上能過關，遇到慣用語就失手。

資料集、system prompt 與原始結果檔可在此取得以供重現。若要在你自己的提示上跑這套評測，請參考 DigitalOcean 文件中的 How to Evaluate Models。

RAG 流程：評測整條鏈，而不是只評模型本身

RAG 評測最常失敗的原因，是團隊只評測生成這一步。整條流程有三個失敗點：

1. Embedding 品質：檢索系統有沒有撈出正確的片段？
2. 檢索精準度：top-k 的結果真的相關嗎？
3. 生成忠實度：模型有沒有緊守被檢索到的 context，還是產生幻覺？

忠實度（groundedness）是最主要的品質訊號。一個會在檢索到的 context 之外、自信地產生「看似合理但其實錯誤」答案的模型，不管基準測試分數多好都很危險。

RAG 的實務選型準則：

• 分開評測檢索與生成
• 在已知正確答案的保留樣本上量測幻覺率
• 對穩定 context（system prompt + RAG 樣板）做 prompt caching 是最主要的成本槓桿：一條快取良好的 RAG 流程，有 70-80% 的輸入 token 由快取供應，價格只要基礎輸入價的 10%。從一開始就把提示結構設計成可快取；事後補救很貴。

對大多數 RAG 來說，中階模型（Claude Sonnet、GPT-4o mini）能把與前沿模型之間的品質差距補上，因為忠實度是可以靠好的提示控制的行為，並不需要最高的模型智能。只有在調完提示後忠實度仍然過不了你的評測時，才升級到前沿模型。

程式碼生成：私有程式碼庫的表現一定低於基準測試

標準的基準是 SWE-bench，篩選階段特別是 SWE-bench Verified（500 個經人工驗證的 Python 任務），而愈來愈多人用 SWE-bench Pro 取得更難的訊號。

SWE-bench Verified 有資料污染問題

OpenAI 在 2026 年 2 月停止以它作為回報依據，原因是稽核發現部分基準任務的解法可以從 issue 內文外洩，而且在大多數受測案例中，模型會從訓練資料回想起檔案路徑與 release note 的細節。頂尖模型在 Verified 上拿 70% 以上。在 Scale AI 推出的抗污染替代基準 SWE-bench Pro 上，頂尖模型大約只有 23%。

相同的任務領域，不同的基準測試：抗污染的那一組講的是完全不同的故事。

你的程式碼庫才是唯一誠實的基準

在 SWE-bench 上表現好的模型，是在有常見模式的公開 Python repository 上表現好。你的私有程式碼庫有不同的慣例、抽象層與測試結構。表現一定會更低；問題在於低多少，而且各家模型差異很大。

程式碼生成的實務選型：

• 用 SWE-bench Verified 與 Pro 當篩選過濾器，先淘汰表現差的
• 跑一套私有的評測框架：從你程式碼庫取出的代表性任務，並附上已知的正確解法
• 納入 LiveCodeBench：題目在模型訓練截止日之後才發布，讓污染在結構上難以發生
• 針對你最主要的語言與框架來量測

複雜的跨檔案修改用前沿模型。範圍明確的編輯、測試生成與樣板程式碼，中階模型通常就能以一小部分的成本過關。

客戶支援：TTFT 主導使用者體驗

在面向客戶的對話場景，模型品質的爭論其次於 Time to First Token（TTFT），也就是從送出請求到收到回應第一個字元之間的延遲。

使用者會把 500ms 的 TTFT 感受為「即時」，把 2 秒的 TTFT 感受為「慢」。在速度可接受之前，回應的內容幾乎不會被注意到。

我們在 DigitalOcean Serverless Inference（inference.do-ai.run，2026 年 7 月，每個模型跑 3 次，取中位數）上，用一個客服工單分類提示量測了四個模型的 TTFB（time to first byte，TTFT 的代理指標）：

每個模型只跑 3 次，對一個這麼容易受網路抖動與時段負載影響的指標來說是很薄的樣本。請把這些倍數當成方向性參考，而不是定論。Llama 3.3 70B 在每百萬輸入 token $0.65 的價格下做到 400ms 以內的 TTFB，比 Sonnet 快 3.6 倍、便宜 4.6 倍。對一個使用者正盯著游標看的客服聊天機器人來說，這同時是更好的 UX 與更低的成本。Sonnet 的 1.4 秒 TTFB 已經接近使用者會感受到延遲的門檻。

意涵：

• 更小、更快的模型即使輸出品質略低，仍能帶來更好的 UX，因為體驗是由 TTFT 主導
• 對重複出現的 FAQ 類查詢做語意快取與 prompt caching 是最主要的成本最佳化：同樣的問題會出現上百次，把穩定 context 快取起來能大幅降低每次查詢的成本
• 串流很重要：300ms 就吐出第一個 token，感覺比 1.5 秒後一次給完整回應更快，即使總完成時間相同

對分類型的支援任務（意圖路由、升級判斷、情緒標記），準確度下限用比前沿模型小很多、也便宜很多的模型就能達到。

基準測試是篩選用的過濾器，不是最終判決

在依據公開基準測試決定用哪個模型之前，有四點提醒：

MMLU 已經飽和。 最先進的模型彼此集中在 2-4% 的準確度區間內，幾乎無法用來區分目前的前沿模型。

同一個模型，在不同評測框架下分數不同。 兩個團隊用不同的提示格式與答案擷取邏輯跑同一個模型，回報的分數可能相差 10-15%。評測方法本身就是結果的一部分。

SWE-bench 的污染問題。 Verified（70% 以上）與 Pro（23%）之間的落差，說明了污染會把分數灌水到什麼程度。

一份公開的 SWE-bench 排行榜。請把排名當成方向性參考；同一個模型在不同評測框架下分數會不一樣。

你自己的資料才是唯一具權威性的訊號。 每一份基準測試都建立在別人的分布上。在公開基準上排名第二的模型，在你的特定任務上可能勝過排名第一的那個。唯一能確認的方法，就是用你自己的資料去評測。

一套可重複的模型選型流程

以下就是你可以用來為推論使用情境挑選正確模型的可重複流程：

1. 定義你的準確度下限：實際的最低門檻，不是理想值
2. 挑選你的評測指標：翻譯用 COMET、RAG 用忠實度、程式碼用你自己框架的通過率、支援場景用 TTFT 加任務準確度
3. 由小到大依序評測：從最便宜可行的模型開始，一路往上直到跨過你的下限
4. 設定重新評估的節奏：模型分級演進得很快

產出是一張決策矩陣：A 類任務用模型 X、B 類任務用模型 Y，並在信心不足時升級到模型 Z。

DigitalOcean 的 Inference Router 把這件事自動化：依任務複雜度把請求路由到不同層級的模型，不需要自己維護路由邏輯。決策矩陣變成設定檔，而不是程式碼。Multi-Model API Cost Governance 在 2026 年 6 月的實跑中，於混合分類／問答／推理的流量配比下，純靠路由、不改提示也不換模型，量到相對於只用 Sonnet 降低 39.6% 成本、相對於只用 Opus 降低 63.7%。更深入的架構故事會在本系列的下一篇談。

如果你還沒讀過，請先看本系列第一篇為什麼你的 LLM 帳單是預期的 3 倍，了解模型選型的成本意涵。

參考資料

• How to Evaluate Models（DigitalOcean Model Evaluations，翻譯評測方法）
• Multi-Model API Cost Governance with the Inference Router（DigitalOcean，2026 年 6 月實跑）
• Model Evaluations: Prove Your Routing Policy Actually Works（DigitalOcean）
• What is the best LLM for translation?（Lokalise）
• Rapidata Translation Benchmark: DeepL vs DeepSeek-R1/Llama/Mixtral（HuggingFace）
• NLLB-200 3.3B Model（Meta／HuggingFace）
• SWE-bench Pro Leaderboard（Scale AI）
• Why SWE-bench Verified No Longer Measures Frontier Coding Capabilities（OpenAI，2026 年 2 月）
• LiveCodeBench（抗污染的程式碼基準測試）
• Anthropic API Pricing
• DigitalOcean Inference Pricing
• How to Use Inference Router（DigitalOcean 文件）

這是「生產環境中的 LLM 推論」系列 5 篇文章中的第 2 篇。第 1 篇談推論帳單背後隱藏的成本相乘因子。第 3 篇談 prompt caching 的實務。第 4 篇談多供應商路由架構。第 5 篇檢視整套 AI stack 的總持有成本。