AI工程:如何选好推理模型,别瞎选!

点击上方蓝字关注我们

导读助手

章节

字数：9805

还可阅读25分钟

客官，点个关注呗🤪

引言

市面上的模型选型总是被写成排行榜比较，把几个模型放进表格，抄入公开分数、价格和上下文窗口，再挑一个“综合最好”的作为默认模型。可这套方法的问题不只是太过粗糙，而是直接定义错了对象！生产系统真正调用的从来都不只是一个模型名，而应当是由模型版本、供应端点、运行时、量化、消息模板、采样参数、工具协议、检索策略、权限和验证路径共同组成的推理配置。只要其中任一项变化，系统行为、成本、失败方式和可复现性都可能发生巨变。

因此，模型选型不是寻找单一赢家，而是在任务目标和风险边界已经明确的前提下完成三次关键决策：

先用许可证、数据边界、模态、工具、可用性和延迟等硬约束规划出可行域
再用公开测评和官方资料缩小候选范围
最后用项目真实任务、失败样本、人工复核成本和回退能力决定候选进入哪一种受控角色

高能力模型未必适合团队默认工作路径，低成本模型也未必总带来成本优势；真正有工程价值的模型，是能在指定任务上稳定地产出可接受、可检测、可验证且可撤销结果的那套配置

本文为系列文章首篇，负责定义模型候选如何形成、怎么比较、怎么进入任务路由以及如何退出任务默认路径；所有内容与数据的事实核验均至2026年7月12日。免责声明：仅代表个人观点。

排行榜为什么无法替代团队完成选型

排行榜回答的是“某个系统在某组公开任务和测量条件下表现如何”，而工程领域的选型要回答的是“本项目的输入分布、损失结构、数据边界和验证条件下，哪套配置值得承担哪一种责任”。二者之间并不存在任何自动继承和自动推导的逻辑关联关系。

一项公开成绩要成为工程结论，至少需要跨越三道坎：

第一道，任务分布间隙，SWE-bench测量真实GitHub issue的补丁能力，却不认识本项目的目录职责、数据迁移窗口和业务禁区；RULER能测试长上下文中的检索、跟踪和聚合，却不能证明模型能真正理解一份不断演化的内部架构文档[7][8]。

第二道，系统构成间隙，Agent榜单的结果往往属于“模型 × 脚手架 × 工具 × 资源预算”，并不属于裸模型。

第三道，损失函数间隙，两个模型都少回答一道题，在公开基准上可能只是相同的一分损失而已；但在生产中，一个错误可以被单独测量立即发现，另一个错误可能静默修改权限或污染数据，两者不具有等同意义。

所以，公开benchmark的牛不牛逼不是工程决策参考的主要参照物，其在决策链条里不应放在裁决层，而是决策选项候选！HELM之所以强调多场景、多指标和透明度，恰恰是在反对用单一分数概括模型；OpenAI和A社（Anthropic）当前官方选型指南也都要求先定义可测量的成功标准，再比较能力、速度和成本[1][2][3]。这些材料能提供方法论上的共同特征结论：先定义成功和失败，再讨论模型选型；不能先选模型，再为它找自己业务领地里适合的任务。

更深一层观察来看，榜单直选实际上把对工程问题的约束排序丢给了榜单的编辑者。榜单选了哪些任务、如何加权、允许多少次尝试、使用什么脚手架，都已经替使用者作出价值判断。团队若不重建自己的任务优先级和复杂度，以及成本损失模型，那就不是在选合适的大模型，而是替别人继承他们的个人偏好，未必适合自己的团队。

在看

选型对象不应只看模型名，而是推理配置

同一个名称并不足以唯一标识一个可复现工程系统。模型调度供应商可能让别名指向新的快照；同一个模型在不同云平台的退役日期可能不同；开源权重经过不同量化裁剪后会改变精度与吞吐；运行时可能从模型仓库读取默认生成参数；聊天模板若与训练时格式不一致，模型看到的 token 序列也会差异巨大。vLLM 官方文档明确说明，其服务端默认可能应用模型仓库中的 generation_config.json； Hugging Face 强调聊天模型依赖特定消息模板，本质上仍是在续写被格式化后的 token 序列［9］［10］。这说明“模型相同”并不等同于“推理行为相同”。

上图将一次可评测、可上线的选型对象定义为一个具体、可复核的模型身份。

身份维度	需要冻结或记录的内容	忽略后容易发生什么
模型制品	精确 model ID、snapshot、权重摘要、许可证	别名热切换后，历史结果不可复现
供应端点	Provider、区域、API 版本、配额与数据政策	同名模型在不同平台的能力或生命周期不同
运行时	vLLM、llama.cpp、MLX、Transformers 及其版本	默认参数、支持算子和工具协议发生变化
数值表示	FP32、BF16、FP8、INT8、GGUF 等量化方案	容量、质量、速度和稳定性同步变化

A 社（Anthropic）将模型划分为 Active、Legacy、Deprecated 和 Retired，并指出同一个模型在合作平台上的生命周期日期可能不同；Gemini 则区分为 Stable、Preview、Latest 与 Experimental，其中 Latest 会被热切换［4］［5］。OpenAI 的固定 snapshot 机制同样用于锁定行为版本［6］。这些都指向同一个工程结论：模型身份必须可枚举，动态别名不能直接承担可复核校验的默认路径。

在看

从任务合同开始

一切都应从任务合同开始，模型承担的不是任务名称，而是一种责任！

“摘要”、“写代码”、“RAG问答“仍然不足以描述选型需求。同一项摘要任务，可能不只是帮助员工浏览材料，也可能进入工程安全、项目开发、医疗、法律或财务的具体决策中；同一项代码任务，可能被用于生成备选代码草稿，也可能在一些天真的员工帮助下获取仓库写权限并直接部署在生产环境的部署命令。选型的第一输入应该是任务合同，而不是任务标签。

任务合同至少要回答七类问题：

维度	核心问题	选型的影响
目标	什么结果才算成功，最低可接受质量是什么	定义能力门槛和判分方式
输入	输入来自哪里，是否包含敏感或受限数据	决定本地、区域和供应商可行域
输出	输出是建议、草稿、结构化数据还是执行动作	决定格式、引用和权限要求
损失	错误会造成什么后果，影响能否局部隔离	决定风险门禁和人工参与程度
可检测性	错误能否由规则、测试、第二模型或人工发现	决定自动化深度，而非仅决定模型强弱
可撤销性	结果是否能回滚，回滚需要多少时间和状态恢复	决定恢复范围与默认权限
时效性	首token、完整结果、批处理窗口和可用性目标	决定模型、端点、缓存与路由策略

其中，最容易被忽略的是可检测性。一个能力较强但会生成难以发现错误地模型，未必比能力略低，但错误清晰可见的模型更适合默认配置路径。对于可由编译器、schema和单元测试强约束的任务，团队可以容许更积极的自动化程度；对于业务语义、权限边界和迁移正确性难以自动检查的任务，模型能力再高也不能替代审查。

在看

先划地盘，再比较能力

任何候选比较都应该先回答“能不能用”，再回答“谁更好用”。若数据依照法律法规不能离开制定区域，远端高分模型就不能列进候选集合；若任务必须输出可由程序验证的结构，长期破坏schema的模型不能靠其他能力补偿；若商业经营范围或许可证不允许目标商业场景，部署成本再低也没有意义。

硬约束的作用，是防止综合评分把不可接受的失败“平均掉”！建议按照各个企业各个不同项目的实际情况建立如下资格门：

资格门	典型核查项	证据来源
法律许可	商用许可、再分发、使用限制、训练/输出条款	官方 license、法律评审
数据边界	数据驻留、保留、训练使用、租户隔离、密钥策略	官方数据政策、合同、部署实例
能力接口	模态、上下文、结构化输出、工具调用、流式与批处理	官方API/model card + 本地烟雾测试
运行可行性	硬件容量、运行时兼容、量化、并发与启动恢复	provider工具本地实测、性能调优实测、推理引擎架构工具实测（后续文章会讲）
服务目标	可用性、限流、p95/p99延迟、峰值吞吐	供应商SLA + 灰度日志
可验证性	是否可固定版本、记录轨迹、获得引用和失败原因	API/运行时能力 + 项目验证链
安全与权限	工具批准、读写边界、网络与凭证隔离	Agent配置、沙箱和安全评审
退出能力	fallback、数据导出、接口替换、退役通知与迁移窗口	退役文档、迁移演练

资格门并不是一成不变的统一顺序。医疗数据、本地代码、公开内容生成和离线批处理面对的硬件约束不同，具体优先级由不同企业的工程决策以及战略承诺所决定；工程决策不是一次静态排序，而是把不完整证据转换成有责任人、有承诺强度、有监测条件、有退出路径的行动。但一旦某项被定义为硬约束，就只能通过或不通过，不能用更高的benchmark分数交换。

NIST AI RMF及其生成式AI Profile强调风险管理必须与具体目标、资源、使用情境和生命周期相结合[11]。这为模型选型提供了一个重要校准：风险不是模型固有属性，而是模型在某个系统和用途中的关系属性。所谓“安全模型”或“生产模型”若脱离数据、权限、使用者和后果，那它就只是个没有定义完整的“形容词”而已！！！

在看

公开证据如何参考？

公开资料不是无用，而是必须被放置在合适的语境里，合适的问题下。不同来源承担不同证据职责：

证据类型	适合回答	不能独自回答
官方model card/API文档	支持的模态、上下文、接口、许可证、版本状态	本项目真实质量、长期稳定性
官方/厂商benchmark	厂商在其设置下测得的能力信号	独立复现、项目适配、事故概率
独立公开benchmark	通用坐标、候选粗筛、跨系统比较线索	私有业务语义、权限和维护成本
正式论文	实验条件下的方法与测量结果	超出实验规模的普遍结论
Issue/Discussion	已经出现的具体兼容或故障模式	故障普遍率和整体质量
本地smoke test	当前配置是否可运行、接口是否闭合	长期质量和完整风险分布
项目私有eval	本项目样本上的质量与失败形态	未覆盖场景、未来分布漂移
灰度运行	真实延迟、成本、重试、人工修复和异常	未暴露的长尾风险

SWE-bench的价值在于把代码模型放入真实仓库issue与补丁验证环境，而不是证明某个模型可以安全修改任何项目[7]。RULER的价值在于揭示大模型厂商标称上下文与有效上下文之间的差距，明确被厂商收取了多少“token税”，而不是证明长上下文可以替代检索、文档治理和约束继承[8]。HELM的价值则在于多场景、多指标与透明度，不是为了再生成一个新的总排名[1]。

所以，候选准入不应用“某榜单前N名“，而应关注：某项外部证明表明该配置可能满足某种能力要求，值得投入本地评测的实际经济成本。公开证据决定”是否值得测“，项目证据决定”允许其承担什么责任“。

在看

私有测评应当作为风险采样依据，而不是搞新榜单

项目私有评测的目标不应该佐证技术人或者老板的个人偏见，更不应为了公开榜单的编辑者延续他们的幻想！而应该专注在估计候选模型在真实任务与风险边界内会如何失败。它应覆盖高频任务、高损失任务、历史事故、边界输入和不可自动裁决样本，而不是按固定的30/30/30题型凑数量！

样本规模取决于决策风险，任务异质性、期望检测的退化幅度和可接受不确定性。少量样本可以用于淘汰明显不适配的候选模型，却不能硬达到某个整数门槛就自动获得上线资格；同样，七天无严重事故也不能证明低频灾难性问题不存在。具体采样、判分器、置信区间、聚类相关性和回归集治理必须交由“AI系统评测与决策证据体系”（后续文章会聊），本文只规定选型必须从评测取得以下输出：

每个任务族的通过率或质量分布，而非单一均值；
严重失败的数量、类型和可检测方式；
格式、工具、引用和边界遵守情况
任务级延迟、token、重试与人工复核耗时
结果对prompt、模版、上下文和运行时变化的敏感性
与当前默认配置相比，哪些场景提升、哪些场景退化
尚未获得证据的范围

官方eval指南普遍要求先定义可测成功标准，并使用多维度标准衡量任务忠实度、稳定性、隐私、上下文使用、延迟和价格[02][03]。这里的关键不是维度越多越好，而是每个维度都必须可对应任务合同中的一项责任。

私有评测还应保留“无法裁决”这一结果。若样本本身含糊不清、判分器分歧高或真实业务规则未明确，正确结论不是强行给模型打分数，而是必须承认系统尚且无法具备选型所必需的事实依据。评测不确定性不能被隐藏在小数点之后！

在看

能力之外，必须可控：错误损失、可检测与可撤销

模型选型最有价值的比较，不是看“谁犯错更少”或“不犯错”，而是“谁以什么方式犯错，以及系统能否在损失成型前立即准确识别”。可用下表理解能力与工程风险之间的交叉关系：

失败形态	典型表现	可检测性	工程处置
显式拒绝或格式失败	返回拒绝、JSON校验失败、工具schema不通过	高	自动重试、fallback或人工接管
局部事实错误	引用错误、参数错误、函数名错误	中到高	检索落地、规则校验、测试
自洽但错误的推理	解释完整，却基于错误假设前提	中到低	反事实、第二证据源、专家review
越权行动	修改禁区、执行外部副作用	高或滞后	权限隔离、批准门禁、回滚
静默状态污染	错误写入索引、配置、数据或记忆	低	事务边界、审计日志、隔离与恢复
分布漂移	同一配置在新数据或供应商更新后退化	滞后	持续采样、版本冻结、漂移告警

借助这张表，可暴露一些公开或私有榜单无法暴露的事实：失败可检测性本身就是能力的一部分。对自动化系统而言，一个能明确拒绝、能稳定输出schema、能保留引用和工具轨迹的模型，可能比平均分稍高但会静默编造的模型更有价值。

同样地，模型不应通过语言上的自然自信，而给予裁决权！事实检索、执行、验证和最终批准是不同系统角色下的责任归属问题；一套配置可擅长候选生成，却不适合事实裁决；有的可擅长规划，但不应给予写的权限。选型输出必须说明模型承担哪一种角色，而不是只写“推荐使用”。

在看

候选之间的较量

通过硬约束后，候选模型可能仍然存在质量、延迟、成本、稳定性、隐私和维护负担上互有优势。此时不宜把所有变量粗暴相加权成一个综合分，因为人民币/美元、分钟、错误概率和数据边界没有天然汇率，否则你会借助新时代经济要求“Token"交出更多真金白银！

所以，最应该做的分三步，也就是在存活候选模型之间比较：资格门、Pareto边界、情境分析：

资格门：先淘汰违反不可补偿约束的候选
Pareto分析：识别没有在所有关键维度被另一候选支配的方案
情境裁决：在明确流量、任务分布、人工能力和风险偏好的情境下比较剩余候选。

例如，一个配置质量很高但是延迟长，另一质量略低但可本地运行。二者谁更优，则取决于它们用于异步架构审查、交互式补全还是敏感数据处理。若没有任务情境，“综合最好”没有可验证含义。

建议在团队中维护如下比较矩阵，但不计算统一总分：

比较维度	测量对象	典型统计或证据	是否可补偿
任务质量	通过、偏好、事实与结构正确性	分任务分布、严重失败	仅在资格线上比较
可检测性	错误被规则、测试或人发现的概率	failure、taxonomy、revie记录	部分可补偿
延迟	首toen、完整结果、尾部延迟	p50/p95/p99	受SLO硬限制
成本	API、本地资源、重试、review、CI、迁移	分项成本占	只能在同一情境比较
数据与合规	驻留、保留、训练使用、许可	合同和审计	通常不可补偿
稳定性	格式、工具、拒答、版本漂移	重复运行与灰度轨迹	资格线 + 比较项目
退出能力	fallback、可移植性、退役窗口	演练与官方生命周期	高风险路径近似硬约束

⚠️注意：本文不替所有项目预设“隐私 > 安全 > 成本”之类统一价值排序，只要求此顺序必须显式，硬约束不能被加权分数走私绕过。

在看

成本，千万不能假性精确

原始调用价格只是成本的一部分，可被财务公式明确统计的；但把所有隐性成本直接相加也会制造另一种假精确：人工复核、事故风险、供应商绑定和数据边界并不总能被可靠折算进同一个货币计算公式项里。更稳妥的方式是建立单位可接受结果的成本账目，分项拆分记录而非强行汇总：

可接受结果 = 结果满足任务质量门 + 所需证据已到位 + 未发生禁止的副作用 + 验证已完成一项公开成绩要成为工程结论，至少需要跨越三道坎：

第二道，系统构成间隙，Agent榜单的结果往往属于“模型 × 脚手架 × 工具 × 资源预算”，并不属于裸模型。

第三道，损失函数间隙，两个模型都少回答一道题，在公开基准上可能只是相同的一分损失而已；但在生产中，一个错误可以被单独测量立即发现，另一个错误可能静默修改权限或污染数据，两者不具有等同意义。

只有当单位、估计方法和数据质量足够一致时，吃啊可以形成总成本区间；否则，应保留多维账本，并通过情景分析判断“在当前流量和人工条件下是否值得”。

成本项目	建议记录	说明
推理成本	输入、输出、缓存、工具与重试费用	供应商账单或本地资源计算
时间成本	排队、首token、完整响应、CI和Review时间	不能只看模型生成速度
人工成本	复核、修正、升级与事故处理工时	低价模型可能把成本转移给人
失败成本	失败严重程度、回滚和重放资源	用情景或区间，不伪造精确概率
迁移成本	prompt、工具协议、索引、接口与培训改造	在引入时就应建立退出估计
机会成本	容量占用、并发限制、供应商锁定	以替代方案或容量损失表达

“便宜模型意味着低成本”的命题只有在重试、复核、失败和维护成本不反向增长时才成立。反之，价格更高但一次通过率高、错误可检测的配置，可能拥有更低的单位可接受结果成本。模型选型要优化的是完成目标的系统成本，而非单单的token价格！！！

在看

模型组合与路由：没有赢家通吃，更无免费路由

当任务类型稳定、流量足够大且候选模型之间存在明显的“能力+成本”差异，多模型组合通常比把所有请求交给最大模型更合理。FrugalGPT、RouteLLM等研究表明，级联或学习式路由可以在特定评测设置下改善“成本-质量”权衡[12][13]。但，这些结果不能直接推导出“所有团队都应建设智能路由”。

路由器增加了新的系统责任：任务分类可能错误或者细分不足，路由分布会漂移，模型价格和能力会变化，fallback可能形成循环，强模型和弱模型之间的输出格式可能不兼容。若团队还无法稳定测量单模型表现能力，增加路由只会把错误归因变得更加困难与扑朔迷离。

建议按照成熟度采用三种形态：

静态任务映射：由任务合同直接指定默认配置和fallback，适合任务种类少、流量有限阶段；
规则路由：依据数据边界、模态、风险、上下文问和延迟预算选择配置，适合因规则明确的场景；
学习式或级联路由：依据预测难度、置信度或质量评估动态审计，适合样本和反馈充足、分布相对稳定的场景；

无论哪一种形态，硬约束必须在路由评分之前执行，敏感数据不能因为预测质量更高而被路由到不允许的端点；高风险行动不能因路由判断“简单”而绕过批准。路由输出也必须包含选择理由、候选版本和fallback轨迹，否则它无法被审计。

在看

模型生命周期是天数，而是带证据义务的状态机

模型发布速度远快于传统系统的组件依赖。供应商会弃用旧端点、旧产品、切换latest别名，开源模型会出现新的量化和运行时实现。A社（Anthropic）和Gemini的官方生命周期文档都明确区分活跃、预览、弃用和退役状态；截至今年（2026年），多家供应商仍在平凡调整模型与接口[4][5]。因此，选型必须被设计成状态机，而不是一次性采购决策。

状态	允许承担的责任	进入证据	退出触发
发现	仅登记外部信号	model card、论文、榜单或需求	不满足硬约束则关闭
候选	可运行受控评测	复核身份已记录、smoke通过	明显不适配或进入试验
沙箱实验	不接触真实副作用	私有任务集、失败归类	证据不足、淘汰或进入影子
影子/并行	读取真实输入但不成为最终动作源	与当前默认对照、数据政策允许	质量、成本或稳定性不达标
受限使用	仅承担明确任务与权限	达到任务资格线、fallback可用	扩权、降级或冻结
默认	成为某任务族默认路由	完整评测、灰度、owner和回滚演练	漂移、弃用、预算或政策触发
降级/falllback	只在故障或特定情境使用	已验证最低能力和恢复路径	不再可靠或被替换
冻结	保持可复现、不接受扩权	版本和制品可保留	复核后恢复、受限或退役
退役	不再接受新请求	替换完成、历史证据归档	终态；必要时仅做重放

状态迁移不使用统一的“七天无P0/P1"、“低于一百题只能筛选”之类普遍门槛。观测窗口时长应当覆盖目标任务的真实周期和低频风险；样本规模应由统计目标和任务异质性决定；严重事故是否一票否决则应当由任务损失结构决定。模型固定配置天数可以只作为某个项目的初始baseline，但必须记录来源和替换条件。

每个默认配置都必须同时有 owner、下一复核日期、弃用监测、fallback和退役路径。若无法定义退出方式，说明团队选择的不是模型，而是一项没有被承认的长期平台承诺；小心承诺可以不兑现的哦😁。

在看

模型最容易误判的三大坑

长上下文不是稳定理解，更不是知识库

标称上下文，只表示接口允许的最大输入规模，不表示模型在全部位置和任务复杂度上都能稳定利用。RULER专门通过多针检索、变量跟踪、聚合和干扰任务测量“有效上下文”，其存在本身就说明NIAH或窗口长度不足以代表真实能力[8]。

再者，长上下文还会改变延迟、缓存、成本和注意力噪声。选型时应当分别测试：能否找到证据、能否正确整合冲突、能否保持引用、能否在目标长度下完成输出、在真实运行时的过程中是否满足资源和延迟约束。需要长期更新、权限过滤和来源追踪的知识仍应进入团队的“知识输入与证据检索的横切面”（挖坑，后续文章会聊），而不是永久塞入某个prompt！

工具调用不是一个“是或非”的布尔特性

“支持function calling”只能说明接口存在，不能说明模型在真实工具集成中能正确选择、填参数、处理错误和停止。工具能力至少要包含：是否需要调用、选择哪个工具、参数是否合法、能否理解返回值、失败后是否重试、是否遵守批准和副作用边界。

模型选择必须在实际schema、工具描述、权限和异常返回下测试。Agent的安全性主要来自工具执行层的最小权限和验证，而不是来自模型承诺“谨慎与否”。

结构化输出必须在完整配置上复测

Json、diff、引用标记和停止条件会受到模版、采样、推理模式、量化和最大输出长度影响。供应商升级甚至可能改变tokenizer、参数约束和token计费方式；A社的迁移文档就曾明确记录过新模型tokenizer和参数行为变化[4]。因此，结构化输出的评测对象必须是完整推理配置，并用schema或程序执行判分，而不是仅仅靠肉眼观察几个示例！这很愚蠢，而且代价极大！

在看

个人建议候选方向

注意⚠️：此仅为个人建议且一切数据和事实来源，均截至2026-7-12日的数据

本节保留模型家族信息，但仅将其作为候选档案。表中的“工程观察”来自官方资料、厂商披露、个人实测，只能说明为什么值得进入候选池，但绝不构成任何独立性能裁决，需各位看官谨慎对待。

生态家族	截至7-12日的公开状态	进入候选池利用	必须重新验证的部分
Open AI GPT 5.6系列	官方按照Sol、Terra、Luna提供不同能力-成本定位，并提供固定模型ID/快照机制[6][14]	复杂推理、编码、工具与多模态API候选	私有任务质量、端点数据政策、成本与工具执行轨迹
Anthropic Claude	官方同时提供不同能力档，并维护Active/Deprecated/Retired什么周期[4][15]	长程Agent、代码、文档和工具工作流候选	具体平台可用性、迁移行为、拒答与成本
Google Gemini	Stable、Preview、Latest、Exprimental状态明确，3.x系列覆盖高能力与低延迟形态[5][16]	多模态、长上下文、实时或批量API候选	latest热切换风险、预览退役、项目适配
Qwen	Qwen3提供从小型dense到大型MoE的开放权重，Qwen3-Coder面向代码/Agent[17]	中文、多语言、本地、代码和不同容量档候选	当前checkpoint、量化、模版、许可证与真实仓库表现
DeepSeek	官方API和开放模型持续迭代；2026年v4仍含preivew/迁移状态[18]	推理、代码、开放部署与成本敏感候选	预览稳定性、运行时支持、工具协议与退役窗口
Meta Llama	Llama 4 Scout/Maverick为开放权重、多模态MoE候选[19]	广泛自托管生态、定制和多模态候选	许可证、硬件需求、量化后能力和工具稳定性
Google Gemma	Gemma4面向本地和边缘开放模型，并以Apache 2.0发布[20]	设备侧、离线、专用化和多语言候选	官方规格在目标设备上的可达性、任务质量
Mistral	Mistral 3覆盖大型与小型开放权重，官方强调不同成本/部署档	自托管、多语言、代码和企业定制候选	厂商benchmark的独立复测、许可证和硬件成本

这张表有一部协作“战略成模型”、“本地执行模型”。部署位置和任务责任不是模型家族它自身固有特征：一个经过充分验证的本地模型可以参与高价值分析，一个远端前沿模型也可以承担高频结构化任务。具体怎么分，要由上文我说的“任务合同”、可行域和具体评测结果来佐证决定。

附录必须定期更新，而不应随每轮发布重写。任何“当前最佳”、“默认候选”都应带上as_of、任务范围、供应商端点和证据类型。

在看

选型之后？输出什么？名字？

一次模型选型之后，至少应当输出一个可被组织中的系统和Reviewer们共同读取的配置记录：

selection_id: model-route-code-review-2026-07

as_of: 2026-07-12

task_contract:

task_family: cross_module_code_review

output_role: advisory

side_effects: none

data_classification: confidential_source

latency_slo: async

human_review_required: true

rollback_scope: not_applicable

inference_configuration:

model_id: <exact-snapshot-or-artifact-hash>

provider: <provider-or-self-hosted>

endpoint_region: <region>

runtime: <runtime@version>

precision: <precision-or-quantization>

tokenizer: <identity>

chat_template: <hash-or-version>

system_prompt: <version>

sampling_policy: <version>

tool_protocol: <version-or-none>

retrieval_policy: <version>

qualification:

hard_gates:

license: pass

data_boundary: pass

runtime_capacity: pass

required_interfaces: pass

fallback: pass

eval_report: <09-report-id>

severe_failures: []

unresolved_evidence: []

routing:

role: default|restricted|fallback|candidate

allowed_tasks: []

prohibited_tasks: []

escalation_to: <configuration-id>

lifecycle:

owner: <team-or-role>

state: restricted

next_review: <date-or-trigger>

deprecation_watch: <official-source>

rollback_to: <configuration-id>

retirement_trigger: []

adr: <10-adr-id>

这个记录应当将四个要素组织起来，即：定义候选和配置身份、提供评测报告、记录为什么当前约束下选择它、放弃了什么以及何时重开决策。

缺少任何一部分，模型都只能处于候选或受限状态，不能凭一次端侧用户级别的使用演示就直接升级为团队、工程级别的默认使用路径。

在看

总结

模型选型不是找出市面上满足一切幻想的“最聪明的模型”，而是决定哪一套推理配置可以在什么边界内获得多少信任与权限。它的基本顺序不能颠倒：

先定义任务责任、损失、可检测性和可撤销性
再用许可证、数据、接口、资源、SLO和退出能力建立可行域
用公开证据缩小候选，而不是直接决定默认
用项目eval、失败样本和灰度轨迹比较完整配置
硬约束不参与综合打分，存活候选通过Pareto与情景分析裁决
路由和多模型组合只有在单模型测量已经稳定后才值得引入
每个默认配置都必须有精确身份、owner、fallback、复核和退役路径

模式市场迭代越快、这套方法越重要。发布节奏会让任何模型家族名单迅速过期，但不会改变一个基本事实：生产系统需要的不是抽象能力上限，而是在指定任务、指定输入、指定工具、指定权限和指定验证条件下，稳定产生可接受结果的可复现配置。

在看

参考文献

1. Stanford CRFM, *Holistic Evaluation of Language Models (HELM)*:

https://crfm.stanford.edu/helm/

2. OpenAI, Model selection

https://developers.openai.com/api/docs/guides/model-selection

3. Anthropic, Define success criteria and build evaluations.

https://platform.claude.com/docs/en/test-and-evaluate/develop-tests

4. Anthropic, Model deprecations

https://platform.claude.com/docs/en/about-claude/model-deprecations

5. Google AI for Developers, Gemini API models and model states

https://ai.google.dev/gemini-api/docs/models

6. OpenAI, Models:https://developers.openai.com/api/docs/models

7. SWE-bench, Can Language Models Resolve Real-world GitHub Issues?

https://github.com/swe-bench/SWE-bench

8. NVIDIA, RULER: What’s the Real Context Size of Your Long-Context Language Models?

https://github.com/NVIDIA/RULER

9. vLLM, Quickstart — generation configuration behavior.

https://docs.vllm.ai/en/stable/getting_started/quickstart/

10. Hugging Face Transformers, Chat templates.

https://huggingface.co/docs/transformers/chat_templating

11. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1)

https://doi.org/10.6028/NIST.AI.600-1

12. Chen, Zaharia, Zou, FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance, TMLR.

https://openreview.net/forum?id=cSimKw5p6R

13. Ong et al., RouteLLM: Learning to Route LLMs with Preference Data, ICLR 2025.

https://arxiv.org/abs/2406.18665

14. OpenAI, Compare models.

https://developers.openai.com/api/docs/models/compare

15. Anthropic, Models overview.

https://platform.claude.com/docs/en/about-claude/models/overview

16. Google AI for Developers, Gemini 3.5 Flash.

https://ai.google.dev/gemini-api/docs/models/gemini-3.5-flash

17. Qwen Team, Qwen3: Think Deeper, Act Faster; Qwen3-Coder.

https://qwenlm.github.io/blog/qwen3/ ;

https://qwenlm.github.io/blog/qwen3-coder/

18. DeepSeek, API Docs and V4 preview.

https://api-docs.deepseek.com/ ;

https://api-docs.deepseek.com/news/news260424

19. Meta AI, The Llama 4 herd.

https://ai.meta.com/blog/llama-4-multimodal-intelligence/

20. Google Developers Blog, Bring state-of-the-art agentic skills to the edge with Gemma 4.

https://developers.googleblog.com/bring-state-of-the-art-agentic-skills-to-the-edge-with-gemma-4/

21. Mistral AI, Introducing Mistral 3.

https://mistral.ai/news/mistral-3/

在看

END

●观史论道，行若浮图；虚中见行，静处藏势。

●喂，看什么看，说你呢；你懂什么叫管理吗？

●万字批判｜请各位阳明学“执行官”自重！

●系统觉醒｜为什么越资深的程序员，越喜欢重造轮子？

●悲观者永远正确，乐观者永远前行？-别把智商侮辱得这么有诗意

●AGI到底参考了人类什么？（中）：以史为鉴，走出洞穴

●AGI到底参考了人类什么？（上）

●皇帝的新衣

●【经验的陷阱】32岁打工人揭秘：为何20年经验不敌1次创新？

●价值观：企业如人，健康最好，别让创新烂在家里。

●企业兴衰启示录：揭秘导致企业破产的十大致命因素

●系统设计理论下的哲学观：时间观

●第二章|警惕高并发系统隐藏陷阱“伪共享”

●第一章|警惕高并发系统隐藏陷阱“伪共享”

●万字|重学网络协议，系统认识网络基础知识

●CQRS与DDD的“基”伴（下）

●内存管理的噩梦：泄露与溢出

●CQRS与DDD的“基”伴（上）

关注个再走呗~

排版 | Ethan

文章 | Ethan

图文 | Ethan

点个在看你最好看