模型选型，选的不是“最强”，而是“最合适”

面试里说“我们选了排行榜第一的模型”，听起来很有底气，但在真实项目里往往是不合格的回答。大模型选型从来不是单维度竞赛：能力再强，如果数据不能进入该链路、P95 延迟达不到要求、调用量一上来预算失控，或者供应商接口频繁变化，它就无法成为生产方案。

更成熟的做法是：先明确业务与风险，设置合规、部署、SLA、预算等硬门槛，再用私有测试集比较任务成功率，最后根据节点难度设计模型路由。

一、为什么不能盯着排行榜无脑选？

公开 Benchmark 有价值，它能帮助我们快速了解模型的能力上限。但公开分数通常是在固定题目、固定提示词和固定评分方式下获得的，无法替代企业自己的任务分布。一个模型可能在数学推理榜单领先，却在你的中文字段抽取、财报引用、内部工具参数和拒答边界上表现一般。

排行榜测的是模型在一组公开题目上的表现；项目要测的是模型在真实业务流量中的任务成功率。

排行榜通常不包含网络抖动、限流、重试、工具等待、人工复核等工程成本。

模型发布方使用的提示词和推理预算可能不同，跨供应商的宣传分数不能直接横向相减。

模型版本迭代非常快，今天的第一名可能几周后被替换，但你的选型流程必须持续有效。

二、六个维度决定一个模型能不能上线

参考文章把重点放在合规、成本、延迟和能力上。落到生产环境，还需要补上稳定性与可运维性。六个维度不是平均重要：高风险行业可能把合规设为一票否决，实时客服更重视延迟，批量离线分析则可以接受慢一些，但对成本更敏感。

能力：不要说“整体很强”，要说具体任务

能力至少要拆成中文理解、复杂推理、代码、多模态、长上下文、结构化输出、工具调用、事实忠实度和安全拒答。不同节点的能力要求完全不同：分类节点不需要旗舰推理，调度节点却对 JSON 和函数参数非常敏感。

成本：不要只看每百万 token 的标价

真实成本还包括缓存命中、思考 token、搜索与代码工具、失败重试、超长输出、人工复核以及工程迁移。低单价模型如果经常失败，单位成功任务成本可能更高。

延迟与稳定性：平均值不够

生产系统至少需要记录首 token 延迟、每 token 延迟、端到端 P50/P95/P99、错误率、限流率、超时率和区域可用性。Agent 场景还要把检索、工具和多轮循环计算进去。

三、2026 年主流模型怎么理解？先看家族定位

截至 2026 年 7 月，各家都在做“旗舰、均衡、轻量”分层。OpenAI 官方把 GPT-5.6 Sol 定位为高能力 Agent 工作，Terra 面向均衡高吞吐，Luna 面向快速低成本；Anthropic 的官方选型指南同样强调能力、速度与成本，并建议从低成本模型开始验证，只有出现能力缺口时才升级。Google、Qwen、DeepSeek 和豆包也提供了类似的能力梯度。

官方页面透露出的共同规律

OpenAI 的同一代模型按旗舰、均衡和快速三档定价，说明“同一家族内分层”本身就是选型工具。

Anthropic 明确建议在能力、速度、成本之间权衡，并指出调整 effort 往往比直接换模型更有效。

Google 将 Flash、Flash-Lite、Pro 和 Deep Think 分别定位为效率、高吞吐、复杂任务和科学研究。

阿里云百炼以 Max、Plus、Flash 等层次提供模型，并提供多地域以及 OpenAI/Anthropic 兼容接口。

DeepSeek-V4 Flash 与 Pro 同时支持思考/非思考、JSON 和工具调用，且缓存价格与普通输入价格差异很大。

火山方舟不仅提供模型，还把工具调用、结构化输出、智能路由、低延迟推理和评测纳入平台能力。

四、把“模型能力”拆成业务测试项

模型选型最容易犯的错误，是把公开综合分数直接映射成业务结论。正确做法是先把业务流程拆成节点，再为每个节点定义可测指标。

客服：意图识别、话术一致、敏感问题拒答、情绪稳定。

RAG：检索内容是否被正确使用、引用是否准确、无依据时是否拒答。

Agent：工具选择、参数 exact match、调用顺序、异常恢复和最终状态。

代码：单元测试通过率、仓库级修改能力、是否引入回归。

多模态：图表理解、OCR、视觉定位、图片与文本联合推理。

高风险任务：事实核验、置信度、可追溯性和人工复核触发率。

五、成本要按“成功任务”计算

模型标价通常以输入和输出 token 计费，但用户购买的不是 token，而是完成任务的结果。因此要把失败、重试、工具、缓存和人工复核一起折算。

六、延迟、上下文和可靠性要分开测

用户对速度的感知主要来自首 token 延迟，而长报告生成还受逐 token 速度影响。对于 Agent，端到端延迟往往由模型、工具、检索和重试共同决定。只记录“模型平均响应 2 秒”几乎没有诊断价值。

长上下文不是一个单独的卖点

上下文窗口表示能装多少 token，但不保证模型能在很长的文档中稳定找到中间信息，也不保证跨文档引用准确。长文场景必须做位置扰动、干扰文档、引用核验和多轮工具调用测试。

七、云 API、私有化与混合部署怎么选？

接口模型通常上线快、能力更新快、无需维护 GPU；私有化模型更容易满足数据与离线要求，但需要承担推理框架、量化、多卡并行、容量规划和模型升级。企业项目常见的答案不是二选一，而是混合部署。

八、用私有测试集做选型，而不是靠“感觉不错”

OpenAI 的评测指南强调：评测要反映真实分布，尽早建立任务专属测试，并持续从生产日志中补充样本。Anthropic 也建议先定义可量化成功标准，再组合规则、人工和 LLM 评分。

黄金测试集应该包含什么？

从真实流量抽取主流问题，保证测试集与线上分布接近。

邀请业务专家补充高风险、强规则和极端边界案例。

把历史失败样本固定下来，避免同类问题在模型升级后反复出现。

为每个样本记录标签、允许工具、参考依据和评分规则，而不只是一个“标准答案”。

对 JSON、SQL、工具参数等使用程序评分；对解释质量使用校准过的 LLM 裁判与人工抽检。

九、用评分卡做决策，不要用一张排行榜

评分卡的核心不是算出一个漂亮的总分，而是让团队知道为什么选它、牺牲了什么、哪些指标是硬门槛。权重必须由业务风险决定，并保持可追溯。

十、最终方案往往不是一个模型，而是一套模型路由

如果所有请求都交给旗舰模型，成本和延迟会失控；如果所有请求都交给轻量模型，复杂任务成功率又会下降。模型路由根据敏感度、难度、模态、SLA 与预算，把请求发送到不同模型。

早期项目可以先使用规则路由，规则稳定后再引入分类器或学习型 Router。RouteLLM 与 FrugalGPT 等研究表明，按查询难度在强弱模型之间路由，能够显著改善成本与质量的平衡；但论文结果不能直接当成你的收益，需要在自己的数据上复测。

routes:
- when: sensitive_data == true
model: private_model
- when: task in [tool_call, json_output] and difficulty < 0.75
model: balanced_model
- when: difficulty >= 0.75 or risk_level == 'high'
model: frontier_model
- default: economical_model
fallback:
on_timeout: secondary_provider
on_schema_error: retry_once_then_upgrade
on_budget_limit: safe_degraded_answer

十一、模型上线后的治理，比首次选型更重要

模型不是一个永久稳定的软件依赖。供应商会发布新版本、弃用旧别名、调整价格、修改限流或默认推理参数。DeepSeek 官方页面就提示旧模型别名将在 2026 年 7 月 24 日弃用；类似变化要求生产系统具备版本固定、迁移评测和回滚能力。

固定具体模型 ID 和区域，不直接依赖 latest 或模糊别名。

每次模型、Prompt、检索或工具变更都触发回归测试。

为超时、限流、内容安全拒绝和供应商故障准备回退策略。

记录模型输入、工具调用、引用来源、最终输出和版本信息，便于审计。

设置 token 上限、并发上限、每日预算、异常输出和重试告警。

十二、案例：企业级多智能体 RAG 怎么做选型？

假设系统需要解析企业财报，多个 Agent 拆解任务，调用内部数据库与搜索工具，最后生成中文报告。这个场景同时包含敏感数据、高频中间调用、复杂分析和严格引用，不适合“一把梭”使用同一个模型。

文档清洗、分类、摘要等高频步骤使用经济模型，降低内部循环成本。

主调度节点选择结构化输出、工具调用和长上下文更稳定的均衡模型。

复杂推理、异常分析和关键报告只在必要时升级到旗舰模型。

敏感数据留在合规链路，海外或外部模型可用于脱敏后的离线评测或非敏感兜底。

最终回答必须通过引用、数字、JSON/模板和业务规则校验。

十三、面试时可以这样回答

一个完整回答不需要背几十个模型，而要体现工程思路：先说明业务场景与约束，再讲候选模型定位、私有评测、成本与延迟，最后给出模型路由与治理方案。