如何为你的 AI 推理业务场景选择合适的大语言模型

本文详细讲述一种可复用的模型选择方法：通过在自有数据上进行评估来挑选推理模型，并结合来自 DigitalOcean 无服务器推理（Serverless Inference）的第一手成本数据。

模型选择让成本产生数量级的差异

在生成式 AI（GenAI）的部署中，模型的选择才是决定质量和成本的最大杠杆，而不是基础设施、提示词优化或批处理策略。Claude Sonnet 4.6 的官方定价为 3.00 美元/百万输入 Token；而 Claude Haiku 4.5 为 1.00 美元/百万输入 Token：在一个简单的分类任务中，这便存在 3 倍的价差。若与运行在 DigitalOcean 无服务器推理（Serverless Inference） 上的高性能开源模型相比，在 Token 结构完全相同的情况下，这一差距会扩大到 36 倍（数据测自 2026 年 6 月的《使用推理路由实现多模型 API 成本治理》）。

请注意： 这是两组独立的对比，而非递进关系。3 倍的价差是 Anthropic 自身产品线内部的对比；而 36 倍的数据是一个单独测量的指标，是将 Anthropic 模型与运行在 DO 无服务器推理上的开源模型进行对比得出的。如果在其他地方单独引用这两个数字，请保持其独立性。

对于你的特定任务，如果较小的模型能产生同等的质量，那么在更大的模型上多待一天都是在过度支付——这不是百分比层面的多花，而是成倍的冤枉钱。

价格说明： Token 费率反映的是 2026 年 6 月云厂商文档及 DigitalOcean 推理服务定价的公开价格。在制定预算前，请务必核实实时费率。此外，模型更迭速度极快，在引用此对比前，请确认是否有更先进的旗舰模型已经取代了本文所提及的模型。可直接咨询DigitalOcean中国区战略合作伙伴卓普云AI Droplet。

选型框架：先看准确率底线，再看成本

正确的选择顺序是：先找到适用于你任务的最低准确率门槛，再找出能跨过这道门槛的最小模型。

把所有候选模型都放到这个准确率门槛上过一遍筛子，只保留能通过该门槛的最小模型。

1. 定义你的准确率底线（Accuracy Floor）： 在关键指标上可接受的最低表现。不是“越完美越好”，而是产品不至于崩溃的那个临界点。
2. 在自有数据上评估： 使用来自你实际生产环境分布的代表性样本，而不是公开基准测试（Benchmark）的样本。
3. 从小模型开始，逐步向上尝试： 通过评估的模型即为候选模型；最终由最便宜的候选模型胜出。
4. 模型更新时重新审视： 6 个月前必须用 Sonnet 才能搞定的任务，现在用 Haiku 可能就足够了。

文本翻译：请用 COMET 而非 BLEU，大批量翻译请用 NMT 而非 LLM

翻译任务暴露了一个根本性的评估缺陷：那些极易计算的指标，往往无法衡量真正重要的东西。

BLEU 与人类的主观评价相关性极差

BLEU（双语评估替代指标）通过计算模型输出与参考翻译之间的 n-gram 重合度来打分。它速度极快且结果确定。但是，在任何需要理解细微语境的场景下，它都无法很好地预测质量。

COMET（基于跨语言优化的翻译评估指标）是一种基于人类评判训练出来的神经网络指标。它与母语者的真实质量评价相关性明显更高，甚至可以颠覆 BLEU 的排名（即一个在 BLEU 上得分较高的模型，在 COMET 上得分反而更低）。

对于任何严肃的翻译评估，COMET 应该作为首选的主力指标，而 BLEU 只能充当辅助的合理性检查（Sanity Check）。

批量任务用 NMT，精细活用 LLM

对于高产量的翻译，速度差距是决定性的。谷歌的 NMT（神经机器翻译）引擎可以在毫秒内交付结果，比大语言模型（LLM）快达 20 倍。DeepL 在高吞吐量下同样表现出色。

海量翻译：NMT 如同高速冲压机，追求效率；LLM 则是精细的抄写员，虽然速度较慢，但在处理语义细节和语境微差上更胜一筹。

LLM 的优势在于长文本上下文、俚语俗语、低资源语言（弱势语种）以及对品牌调性敏感的文案。Lokalise 的盲测研究对比了五种引擎在“英语→德语/波兰语/俄语”上的表现，在母语者的两两对比中，Claude 3.5 获得了最高的“好评”率（78%）。而 Rapidata 的数据集（DeepL 对比 DeepSeek-R1/Llama/Mixtral，涵盖 51,000+ 名母语者，已在 Hugging Face 开源）则表明，没有哪一类技术能在所有的语言对和内容类型中占据绝对统治地位。

对于低资源和特定领域的语言对，一个经过微调的 3.3B 专家模型依然能击败通用的 7-8B 全才模型。目前 AI 本地化（Localization）的核心阻碍在于“信任”而非技术；译后编辑（Post-editing）工作流之所以存在，是因为生产团队还没准备好在没有人工审核的情况下直接发布 LLM 的输出，无论它的基准测试分数有多高。

我们的实测数据：5 个模型，3 种语言，1 个评估套件

为了用数据支撑这一框架，我们在 DigitalOcean 模型评估平台（公开预览版）上运行了一次翻译评估。实验设置：包含 50 个翻译提示词，涵盖英语→德语、英语→繁体中文（台湾）以及英语→波兰语，内容涉及日常、正式、俚语和技术文本。每个提示词都包含人工撰写的参考翻译。裁判模型（Claude Opus 4.6）负责对“标准答案忠实度（Ground Truth Faithfulness, GTF）”进行打分，在 0-1 的区间内衡量其与参考翻译的语义等价性。通过阈值设为 0.80。

五个模型在相同数据集、相同裁判、相同系统提示词以及 temperature=0 下的表现如下：

DeepSeek V4 Flash 达到了与 Sonnet 相当的质量（GTF 0.781 vs 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 倍之多。在输出价格为 $4.40/百万 Token 的情况下，这种“多嘴”彻底抹平了其在输入价格上的优势。Qwen3-32B 也有同样的问题（43,006 个 Token）。这就是本系列第一篇文章《为什么你的 LLM 推理开销暴涨？大模型账单背后的 5 个隐形“陷阱”》中所提及的“冗长乘数效应（Verbosity Multiplier）”的具体数据体现：模型选型不仅仅要看单 Token 的费率，还要看该模型最终吐出了多少个 Token。

在这五个模型中，波兰语的得分普遍最低（0.653–0.744，而德语为 0.747–0.825），这也印证了前文关于低资源语言的论点。

其中一个提示词生动地展示了导致这种差距的失效模式。原文（Source）为：“Let’s not beat around the bush, the project is behind schedule and we need to course-correct.” 参考翻译（Reference）为：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）则完美对齐了俚语和措辞，仅在“纠正方向”一词上做出了无伤大雅的同义转述。便宜的模型在字面和技术文本上完全能够达标，但在面对俚语俗语时往往会败下阵来。

为了保证可复现性，本实验的数据集、系统提示词和原始结果文件均可在此处获取。如果你想在自己的提示词上运行此类评估，可参考 DigitalOcean 官方文档中的《如何评估模型》。

RAG 流水线：评估整个链路，而非单独评估模型

RAG（检索增强生成）评估之所以最容易失败，是因为大多数团队只去评估“生成”那一步。整个流水线其实有三个潜在的失败点：

1. 嵌入（Embedding）质量： 检索系统是否捞出了正确的文本块（Chunks）？
2. 检索精准度（Retrieval Precision）： Top-K 个检索结果是否真的与问题相关？
3. 生成忠实度（Generation Faithfulness）： 模型是否严格基于检索到的上下文回答，还是在凭空幻觉？

其中，忠实度（信实度/groundedness）是核心的质量信号。一个模型如果在检索到的上下文之外，自信满满地给出“看似合理实则错误”的回答，那么无论它的基准测试分数有多高，都是极其危险的。

针对 RAG 选型的实用准则：

• 将检索和生成分开进行评估。
• 利用已知标准答案的留存样本（Held-out examples）来测定模型的幻觉率。
• 对静态上下文（系统提示词 + RAG 模板）进行提示词缓存（Prompt Caching）是控制成本的核心杠杆： 一个缓存良好的 RAG 流水线，其 70-80% 的输入 Token 都可以通过缓存响应，而缓存 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 Notes）的细节。顶尖模型在 Verified 上的得分已超 70%+。然而，在由 Scale AI 推出的抗污染替代版本 SWE-bench Pro 上，顶尖模型的得分骤降至 23% 左右。

相同的任务领域，不同的基准测试：具备抗污染能力的测试集揭示了完全不同的真相。

你自己的代码库是唯一诚实的基准

模型之所以在 SWE-bench 上表现优异，是因为那些测试基于公开的、带有通用模式的 Python 仓库。而你的私有代码库有其独特的编码规范、抽象层和测试结构。模型在实际业务中的表现往往会有所打折；关键在于打折多少，且这因模型而异。

实用的代码生成选型指南：

• 将 SWE-bench Verified 和 Pro 作为初筛过滤器，直接淘汰掉表现糟糕的模型。
• 运行一个私有评估套件：使用来自你自身代码库、带有明确正确解法（解法已知）的代表性任务。
• 引入 LiveCodeBench：该测试集包含在模型训练截止日期之后才发布的题目，在结构上杜绝了数据污染的可能。
• 重点针对你们团队最常用的编程语言和框架进行定向测算。

对于涉及多文件的复杂架构变动，请使用顶级旗舰模型；而对于局部修改、测试用例生成以及样板代码（Boilerplate）编写，中端模型通常就能以极低的成本轻松过关。

客户服务：首字延迟（TTFT）决定了用户体验

对于直接面向用户的聊天机器人，模型质量层面的论战都要让位于首字延迟（Time to First Token, TTFT）——即用户发送请求到屏幕上蹦出第一个字符之间的等待时间。

用户对 500 毫秒的 TTFT 的感知是“秒回”，而一旦到了 2 秒就会觉得“卡顿”。在速度达到及格线之前，用户根本无暇关心回答的具体内容。

我们在 DigitalOcean 无服务器推理（Serverless Inference）（inference.do-ai.run，2026 年 7 月数据，各运行 3 次取中位数）上，使用一个客服工单分类提示词对四个模型进行了 TTFB（Time to First Byte，首字节时间，可作为 TTFT 的近似替代指标）测试：

Tips：对于极其容易受到网络抖动和特定时段负载影响的延迟指标来说，3 次测试的样本量较小。请将这些倍数视为方向性的趋势参考，而非绝对定义。

Llama 3.3 70B 能够在仅 $0.65/百万 Token 的价格下提供低于 400 毫秒的 TTFB，比 Sonnet 快 3.6 倍且便宜 4.6 倍。对于用户正盯着光标等待的客服聊天机器人而言，这同时实现了更好的体验与更低的成本。而 Sonnet 那 1.4 秒的 TTFB 已经逼近了让用户感到明显延迟的临界点。

核心启示：

• 更小、更快的模型能带来更好的用户体验（UX），即便其输出质量可能稍逊一筹；因为整体体验严重受 TTFT 的支配。
• 针对高频常见问题（FAQ）进行语义缓存和提示词缓存是核心的成本优化手段： 同样的提问会重复出现成百上千次；缓存静态上下文能大幅削减单次查询的开销。
• 流式传输（Streaming）至关重要： 300 毫秒吐出第一个字，给人的感觉比憋了 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）便实现了这一自动化过程：它能根据任务的复杂程度，将请求无缝分发到不同的模型层级中，而无需你手动编写复杂的路由逻辑。这让决策矩阵变成了配置项，而非冗长的代码。在 2026 年 6 月《多模型 API 成本治理》的真实运行测算中，面对分类/问答/推理的混合流量，在不改动任何提示词和模型的前提下，纯靠这种智能路由，比全跑 Sonnet 实现了 39.6% 的成本削减，比全跑 Opus 更是实现了 63.7% 的成本骤降。更深层的架构故事，我们将在本系列的下一篇文章中展开探讨。

参考资料

• 如何评估模型 (DigitalOcean 模型评估与翻译评估方法论)
• 使用推理路由实现多模型 API 成本治理 (DigitalOcean，2026 年 6 月实测数据)
• 模型评估：证明你的路由策略切实有效 (DigitalOcean)
• 谁是用于翻译的最佳 LLM？ (Lokalise)
• Rapidata 翻译基准测试：DeepL 对比 DeepSeek-R1/Llama/Mixtral (HuggingFace)
• NLLB-200 3.3B 模型 (Meta / HuggingFace)
• SWE-bench Pro 排行榜 (Scale AI)
• 为什么 SWE-bench Verified 不再能衡量前沿的代码能力 (OpenAI, 2026 年 2 月)
• LiveCodeBench (抗污染代码基准测试)
• Anthropic API 定价页
• DigitalOcean 推理服务定价页
• 如何使用推理路由 (DigitalOcean 官方文档)