企业如何选择基座模型：2026 能力、成本、安全与可替换性清单

企业选择基座模型时，最重要的问题不是“哪个模型综合排名第一”，而是“哪个模型在我们的任务、数据、风险、延迟和预算约束下成功完成工作的概率最高”。

2026 年的模型版本和价格变化很快，但一套好的选型方法可以稳定复用。本清单适用于 API 模型、开放权重、自建部署和多模型路由。

第一步：把业务拆成可测任务

不要以“做一个企业 Agent”为评测对象。把它拆成可以单独判定成败的任务，例如：

1. 从合同中抽取 18 个字段并提供页码依据；
2. 根据客户邮件识别意图并生成不超过 150 字的回复；
3. 查询 ERP 库存后创建待审批的补货单；
4. 修改代码、运行测试并解释失败原因；
5. 阅读会议录音和屏幕内容，生成可追溯的行动项。

每类任务至少准备正常、边界、缺失信息、对抗输入和权限不足样本。只有任务可判定，模型结果才可比较。

第二步：建立八维评分卡

权重应按业务调整。高风险财务动作可提高安全与审计权重；面向消费者的实时客服可以提高时延和成本权重。

第三步：比较“完成一次任务”的成本

模型定价不能只抄一行输入单价。实际成本至少包括：

• 输入 Token、缓存创建与缓存读取；
• 输出 Token，以及思考模式产生的额外输出；
• 长上下文阶梯价、批处理折扣和区域差价；
• 搜索、文件、向量、语音、图像或视频工具；
• 超时、限流、错误工具调用和重试；
• 人工复核与异常接管；
• 开放权重部署的 GPU、推理引擎、扩缩容、监控与值班。

用 1000 次真实任务回放得到平均值与 P95，比比较厂商价格表更接近采购事实。站内模型规格与价格目录可用于发现端点和建立初步预算，但第三方渠道报价不能代替官方采购价。

第四步：把百万上下文当作能力而不是策略

GPT-5.6、Claude 5、Qwen3.7、MiniMax-M3、Kimi K3 等已进入百万级上下文。长上下文适合大型代码库、长文档和持续任务，但不应替代检索与权限：

1. 按用户身份过滤可见文档；
2. 只注入完成当前任务需要的证据；
3. 保留引用、文档版本和检索日志；
4. 测试关键信息在开头、中间、结尾时的召回；
5. 对输入长度设置预算和降级策略。

能接收 1M Token 不等于能稳定利用 1M Token，更不等于一次请求就应消耗 1M Token。

第五步：单独测试 Agent，而不是只看回答

Agent 的失败往往发生在文本回答之外：选错工具、填错参数、重复执行、越权读取、在失败后继续写入，或在长流程中忘记原始目标。

建议对每次运行记录完整轨迹：模型版本、系统提示、可用工具、每次调用、参数、返回值、权限判断、Token、时间、重试、最终状态和人工接管。对付款、删库、发信、发布内容等动作设置确定性的审批闸门，不能只靠模型“自行谨慎”。

第六步：建立版本和退役机制

2026 年已经有多个模型家族发生别名切换、端点迁移或旧版本关闭。每个生产模型都应进入资产台账：

• 固定模型 ID 与实际版本；
• 业务 owner、技术 owner 与采购 owner；
• 上线评测结果与最低阈值；
• 官方变更源、退役日期和迁移窗口；
• 已验证回退模型与切换演练记录。

不要默认 latest 适合生产。热切换可以省去手工升级，也会绕过组织自己的回归审批。

第七步：开放权重与 API 做同口径比较

开放权重适合数据边界严格、调用规模稳定、需要定制或希望减少单一供应商依赖的组织。但必须把许可证、量化损失、硬件利用率、并发、推理引擎、安全更新和运维能力纳入评分。

闭源 API 则要评估数据用途、地域、保留、容量、模型更新、供应商可见性和退出成本。两条路径都可以治理，也都可能失控，关键是组织是否有明确控制面。

一个可执行的 30 天选型节奏

第一周完成任务拆解、数据分级和候选模型初筛；第二周建立评测集并回放候选；第三周接入真实工具、并发和故障场景；第四周完成成本模型、风险审查、回退演练和采购建议。

最终产物不应只有一张排名表，而应包括：任务—模型路由矩阵、评测报告、单任务成本、数据流图、权限清单、版本台账、回退方案和下一次复核日期。

从本站进入完整决策链

基座模型观察站提供 14 个主流家族的当前型号、上下文、价格观察、接入方式、Agent 适用性与官方来源；2026 基座模型生态地图用于建立多模型组合；基座模型专题则汇总研究、词条、家族与端点入口。

模型会持续替换，组织真正需要保持稳定的是任务、知识、工具、评测、权限和治理规则。