2026 主流大模型选型笔记
最后核对：2026-07-14。模型版本、价格和可用区域变化很快，本文只保留官方资料能够支持的能力描述，实际接入前仍应复查各平台文档。
大模型选型最容易掉进两个坑：一是拿一张跑分表决定所有业务，二是只比较每百万 Token 的标价。真正上线后，工具调用成功率、输出长度、重试次数、数据合规和端到端延迟，往往比单项分数更影响结果。
一、先看当前模型家族
OpenAI
OpenAI 当前的主线是 GPT-5.6 系列，官方按能力与成本拆分为 sol、terra 和 luna。复杂生产工作优先从旗舰能力开始评测，高频、结构化或批处理任务再下探到更轻的型号。官方同时建议在工具调用和多轮工作流中优先评估 Responses API。
与其把“旗舰模型”理解成万能按钮，不如把 reasoning.effort、工具集合和输出约束一起纳入测试。更高的推理力度不一定带来更低的总成本，因为它可能增加延迟和输出 Token。
Anthropic
Anthropic 当前的高端型号是 Claude Opus 4.8，重点覆盖长时间 Agent 任务、代码工程和专业知识工作；Claude Sonnet 4.6 则更适合作为质量与成本之间的常用档位。两者都不能只凭厂商跑分直接替代自己的代码库评测。
Computer Use 和长程 Agent 能力很强，但也会引入网页提示注入、误操作和权限放大的风险。涉及浏览器、Shell 或生产系统时，审批点和可回滚性必须由应用层控制。
Google 当前提供 Gemini 3.5 Flash 与 Gemini 3.1 Pro 等型号。Gemini 3.1 Pro 官方标注为 Preview，支持文本、图片、音频、视频和 PDF 输入，并提供 1M 输入上下文；长上下文并不等于应该把所有资料一次性塞进去，检索质量和输入噪声仍会影响结果。
Google 的优势更适合从多模态、长上下文、搜索与 Google 生态集成几个方向评估，而不是简单写成“某项能力天下第一”。
国内与其他服务商
MiniMax、Kimi、GLM、Qwen、豆包等平台在中文、语音、区域可用性和计费方式上各有侧重。这里不再维护容易过期的型号与价格表。接入时直接查对应平台的模型列表、上下文限制、数据保留策略和最新账单规则，再用同一批业务样本横向测试。
二、真正需要比较的六个维度
| 维度 | 要测什么 | 常见误区 |
|---|---|---|
| 任务质量 | 正确率、完整性、格式稳定性、拒答与幻觉 | 只看公开榜单，不测自己的输入 |
| 端到端延迟 | 首 Token、完整响应、工具往返和重试时间 | 只看模型生成速度 |
| 上下文 | 有效检索范围、长文定位和多轮一致性 | 把标称窗口当成有效记忆 |
| 工具调用 | 参数正确率、失败恢复、权限与幂等性 | 能调用工具就等于能可靠完成任务 |
| 数据边界 | 区域、保留期、训练选项、审计与删除能力 | 默认认为所有套餐策略一致 |
| 实际成本 | 输入、缓存、输出、工具费、重试和基础设施 | 只比较输入 Token 单价 |
三、成本要按完整链路计算
一个简单请求的模型成本可以写成：
其中最容易被忽略的是输出和重试。某个模型输入单价低，但如果输出更长、工具参数更容易出错，最终账单未必更低。
建议至少记录这些指标：
- 每类任务的输入、缓存命中和输出 Token；
- 工具调用次数、失败率与平均重试次数；
- 首 Token 和任务完成的 P50/P95 延迟；
- 人工返工时间；
- 单次成功任务的综合成本，而不是单次请求成本。
四、我现在更倾向的选型流程
1. 先做小型真实评测集
从自己的工作流中抽取 20～50 个有代表性的任务，覆盖正常输入、缺失信息、冲突约束和工具失败。敏感数据使用独立测试样本，不直接复制生产记录。
2. 固定提示词和工具版本
同一轮比较中保持系统提示词、工具定义、温度、最大输出和重试策略一致。否则测到的往往是提示词差异，而不是模型差异。
3. 分层路由
- 分类、抽取和简单改写交给低延迟型号；
- 代码审查、复杂推理和多工具任务使用更强型号；
- 高风险操作要求人工确认，不让任何模型直接决定付款、删除或生产变更；
- 失败后按错误类型决定重试、换模型或转人工，避免无限循环。
4. 定期复测
模型别名、计费和服务行为都可能变化。固定一套回归任务，在模型升级、提示词调整或工具变更后重新运行，才能知道更新究竟是进步还是回归。
五、数据与权限比模型排名更重要
不论使用哪家模型，下面几条都应该由系统保证，而不是靠提示词提醒：
- API 密钥只保存在服务端 Secret 中；
- 工具使用最小权限，并为写操作设置审批点；
- 日志不记录原始凭据、完整业务文档和无关个人信息；
- 外部输入视为不可信数据，防范提示注入；
- 重要输出必须能够追溯到输入、工具结果和人工决策；
- 为超时、限流、模型下线和供应商故障准备降级路径。
六、当前结论
不存在脱离业务场景的“最强模型”。我的做法是：先用高能力型号建立质量上限，再用评测数据寻找更便宜、更快的可替代档位；凡是涉及真实系统写操作，都把模型放在可审计、可回滚的执行框架里。
官方资料
- OpenAI：Latest model guide
- Anthropic：Claude Opus 4.8
- Anthropic：Claude Sonnet 4.6
- Google DeepMind：Gemini models
- Google AI for Developers：Gemini models
相关阅读
如果这篇文章对你有帮助，欢迎分享给更多人！
部分信息可能已经过时