大模型这个圈子，过去一年最大的变化不是某个模型又刷了多少分，而是"选型"这件事本身变难了。两年前你只需要问一句"用哪个模型"，答案基本就是那两三个名字；现在摆在面前的是 GPT-5、GPT-6、Claude Opus 5.5，以及国内一批在中文场景、私有化部署、成本控制上各有绝活的主流模型，再加上 Agent 这条独立赛道，选型维度一下子从"谁更聪明"变成了"谁更适合我这套活儿"。我自己从去年开始陆续在几个项目里切换过不同模型做对比测试，踩过的坑包括但不限于：拿通用榜单分数当选型依据、忽略上下文工程对效果的巨大影响、Agent 场景下用错了模型导致工具调用频繁失败。这篇就把我这一路对比下来的经验整理出来，从模型能力维度、Agent 适配、微调与部署、成本与合规几个角度，把"全球主流大模型怎么选"这件事讲透，适合正在做技术选型的开发者、准备搭 Agent 项目的同学，以及想搞清楚这些模型到底差在哪的从业者。
1. 先搞清楚"对比"到底在比什么
很多人一上来就问"GPT-6 和 Claude Opus 5.5 哪个强"，这个问题本身就是错的。模型对比不是一场拳击赛，而是一次需求匹配。你得先明确自己要比的是哪个维度，否则看再多评测榜单也是白看。
1.1 通用能力、推理能力、指令遵循是三件不同的事
我习惯把模型能力拆成三层来看。最底层是通用知识与语言能力，也就是模型"知道多少、表达是否流畅"，这一层现在主流模型差距已经很小了，日常问答、文案润色、翻译这类任务，头部模型基本都能做到 90 分以上，纠结那三五分的差距意义不大。
中间层是复杂推理能力，包括数学、代码、多步逻辑推导。这一层差距就明显了，GPT-5 系列和 Claude Opus 5.5 在长链条推理上的稳定性确实比多数模型好一截，尤其是需要连续十几步不出错的场景，比如复杂代码重构、多约束条件下的方案设计。GPT-6 在这一层进一步强化了"思考深度"的可控性，你可以让它想久一点再回答，代价是延迟和 token 消耗上升。
最上层是指令遵循与格式控制，这一层最容易被忽略，但在工程里最要命。你要求模型输出严格 JSON、要求它必须调用某个工具、要求它不能编造字段，这些都属于指令遵循。实测下来，同一个模型在通用问答里表现很好，但一到严格格式输出就开始"自由发挥"，这种情况太常见了。所以对比模型时，一定要拿你真实的业务 prompt 去测，而不是拿"你好，请介绍一下你自己"去测。
1.2 榜单分数的水分在哪里
公开榜单（各种 MMLU、GPQA、SWE-bench 之类的评测）能看，但不能全信。原因有三个：一是数据污染，很多评测集的内容可能已经进了训练数据；二是评测方式差异，同一个模型用不同的 prompt 模板、不同的采样参数，分数能差出好几个点；三是任务错配，榜单考的是通用能力，你的业务可能是非常垂直的领域，榜单第一到你这里未必好用。
我的做法是：榜单只用来做初筛，把明显掉队的排除掉，剩下的全部用自建评测集跑一遍。自建评测集不需要很大，50 到 100 条真实业务样本就够，但一定要覆盖你的核心场景和边界情况。这个投入非常值，因为它能帮你省下后面大量的返工。
1.3 一个实用的对比维度表
下面这张表是我自己在选型时用的框架，把对比维度拆开，每个维度单独打分，最后加权。权重根据你的业务来定，比如做 Agent 的项目，工具调用和指令遵循的权重就要拉高。
| 对比维度 | 具体考察点 | 测试方法 | 权重参考（通用业务） |
|---|---|---|---|
| 通用语言能力 | 表达流畅度、知识广度 | 开放问答抽样 | 15% |
| 复杂推理 | 数学、代码、多步逻辑 | 自建难题集 | 20% |
| 指令遵循 | 格式控制、约束遵守 | 严格 JSON/工具调用测试 | 25% |
| 上下文长度 | 长文档处理、信息召回 | 长文本问答测试 | 10% |
| 响应延迟 | 首 token 时间、总耗时 | 压测统计 | 10% |
| 成本 | 输入输出单价、缓存策略 | 按业务量估算 | 15% |
| 合规与部署 | 数据出境、私有化支持 | 合规评估 | 5% |
这张表不是死的，你要根据自己的场景调。比如做本地部署的项目，"合规与部署"这一项权重可能要拉到 30% 以上，因为能不能落地本身就是一票否决项。
2. GPT-5、GPT-6 与 Claude Opus 5.5 的定位差异
这三个名字经常被放在一起比，但它们的设计取向其实不太一样。理解这个差异，比记住谁比谁高几分有用得多。
2.1 GPT-5 系列：均衡型选手的稳定输出
GPT-5 给我的整体感觉是"稳"。它在通用能力、推理、指令遵循三个维度上都没有明显短板，属于那种你交给它一个中等难度的任务，它大概率能给你一个及格线以上的结果。这种均衡性在工程上非常有价值，因为你不希望模型在某类任务上突然"抽风"。
它的强项在于生态成熟。围绕它的工具链、SDK、文档、社区案例是最丰富的，你遇到问题基本都能搜到答案。对于刚起步的团队，用 GPT-5 系列做原型验证，试错成本最低。缺点是在某些极端复杂的推理任务上，它可能不如专门强化推理的模型那么"能扛"，尤其是需要连续几十步不出错的场景。
2.2 GPT-6：把"思考深度"变成可调参数
GPT-6 最值得说的变化，是把推理深度做成了可控的东西。你可以根据任务难度，选择让它快速回答还是深度思考。这个设计思路很务实，因为不是所有任务都值得花大代价去推理——简单分类任务你让它想半天，纯属浪费。
实测下来，GPT-6 在复杂代码任务和长链条逻辑上的提升比较明显，尤其是那种需要"先规划再执行"的任务。但要注意，深度思考模式下的延迟和成本都会显著上升，如果你的业务对响应时间敏感，得权衡。另外，GPT-6 在 Agent 场景下的工具调用稳定性有改善，多轮工具调用时"忘记自己在干什么"的情况少了，这对做 Agent 的团队是个好消息。
2.3 Claude Opus 5.5：长上下文与写作场景的偏好
Claude Opus 5.5 的定位一直比较清晰：长上下文处理能力强，写作风格自然，指令遵循在"理解意图"这件事上做得好。我拿它做过长文档摘要、技术文档改写、复杂需求理解这几类任务，体验确实不错，尤其是它能比较好地抓住长文档里的关键信息，不会像有些模型那样"读了后面忘了前面"。
它的另一个特点是"听话"，你给的约束它倾向于严格遵守，这在需要精确控制的场景里很加分。不过在纯数学推理和某些代码竞赛类任务上，它和 GPT 系列的取向不同，具体谁强要看任务类型，不能一概而论。选型时建议拿你的真实任务去测，别只看别人的结论。
2.4 三者怎么选：一个决策思路
如果你的项目是通用型应用，追求稳定和生态，GPT-5 系列是稳妥选择。如果任务复杂度高、需要深度推理、且能接受更高延迟和成本，GPT-6 值得试。如果核心场景是长文档处理、写作、需求理解，Claude Opus 5.5 往往更顺手。
但现实里更常见的做法是混合使用：简单任务走便宜快的模型，复杂任务路由到强模型。这种"模型路由"的思路现在越来越主流，后面我会专门讲怎么落地。
3. 国内主流模型的差异化打法
聊完海外三家，必须说说国内这批模型。它们的竞争策略和海外不太一样，更多是在中文场景、成本、私有化部署、合规这几个方向上做文章。
3.1 中文场景与本土知识优势
国内模型在中文理解上有天然优势，尤其是涉及本土文化、行业术语、政策表述、口语化表达的场景。我做过一个对比测试，让不同模型处理一批中文客服对话，国内模型在理解"言外之意"和本土表达上确实更准，海外模型偶尔会出现"字面理解正确但语境不对"的情况。
这个优势在垂直行业里更明显。比如法律、医疗、政务这类领域，术语和表述规范都有本土特色，国内模型经过针对性训练后，表现往往更好。当然这不是绝对的，具体还是要看模型版本和你的任务。
3.2 成本与私有化部署的现实考量
成本是国内模型的一大卖点。同样规模的调用量，国内模型的单价普遍更低，而且很多提供免费额度或低价 API，对预算有限的团队很友好。但要注意，便宜不等于划算，你得算总账：如果便宜模型需要更多轮对话才能完成任务，或者需要更多人工兜底，综合成本未必低。
私有化部署是另一个关键差异点。很多国内模型提供开源版本或私有化方案，可以部署在自己的服务器上，数据不出内网。这对金融、医疗、政务这类对数据敏感的行业是刚需。海外模型在这方面的选择就少很多。部署时要注意硬件要求，7B 级别的模型消费级显卡勉强能跑，但 70B 级别就需要专业卡了，显存、量化方案、推理框架都要提前规划。
3.3 开源生态与微调友好度
国内开源模型生态这两年发展很快，Qwen 系列、DeepSeek 系列等在社区里讨论度很高。开源的好处是你可以拿来做微调，针对自己的垂直领域做定制。微调这件事我踩过坑：一开始以为随便喂点数据就行，结果效果很差。后来才明白，微调数据的质量比数量重要得多，几百条高质量、格式统一的样本，效果可能好过几万条脏数据。
微调的典型流程是：准备数据（指令-回答对）、选择基座模型、配置训练参数（学习率、batch size、epoch）、训练、评估、部署。7B 级别模型用 LoRA 微调，单卡就能跑，成本可控。但微调不是万能药，如果基座模型本身不具备相关能力，微调也很难"无中生有"，它更多是激发和定向，而不是灌输全新知识。
3.4 一个国内模型选型的实操建议
我的建议是分两步走：先用 API 快速验证效果，确认模型能力满足需求后，再考虑私有化或微调。不要一上来就折腾部署，那样试错成本太高。验证阶段重点看三件事：中文任务效果、指令遵循稳定性、成本是否可接受。这三件事过关了，再进入部署阶段。
4. Agent 场景下的模型选择逻辑
Agent 是这两年最热的方向，但它对模型的要求和普通对话完全不同。普通对话里模型答错一句无所谓，Agent 里模型调错一个工具，整个任务链就断了。
4.1 Agent 对模型的三个硬要求
第一是工具调用能力。模型要能准确理解工具描述，在合适的时机调用合适的工具，并且正确填充参数。这个能力差异很大，有些模型在简单工具调用上没问题，但工具一多、参数一复杂就开始出错。
第二是多轮状态保持。Agent 任务往往是多轮的，模型需要记住前面做了什么、当前处于哪一步、下一步该干什么。上下文管理不好的模型，跑几轮就"迷失"了，开始重复劳动或者跑偏。
第三是错误恢复能力。工具调用失败、返回结果不符合预期，这些在 Agent 里是常态。好的模型能识别出"出错了"，然后调整策略重试或换方案，而不是一条道走到黑。
4.2 主流模型在 Agent 任务上的实测差异
我拿几个模型跑过同一套 Agent 任务（多工具调用、需要多步规划），差异挺明显。GPT-6 在多轮工具调用上的稳定性最好，很少出现"忘记目标"的情况。Claude Opus 5.5 在理解复杂工具描述和规划步骤上表现好，但偶尔会过于"谨慎"，该调用工具时犹豫。GPT-5 系列中规中矩，简单 Agent 任务够用，复杂任务偶尔掉链子。国内模型里，部分专门优化过 Agent 能力的版本表现不错，尤其是中文工具描述场景，但整体生态和调试工具还不如海外成熟。
这里要强调一点：Agent 效果不只取决于模型，还取决于你的框架和 prompt 设计。同一个模型，换个 Agent 框架、改改工具描述，效果可能天差地别。所以别把锅全甩给模型。
4.3 Agent 框架与模型的匹配问题
现在 Agent 框架很多，不同框架对模型的调用方式、prompt 组织方式不一样，匹配度也不同。有的框架对模型输出格式要求严格，模型稍微不听话就解析失败；有的框架容错性好，能处理格式偏差。
我的经验是：选框架时先看它支持哪些模型、有没有针对性的 prompt 模板。如果一个框架对某个模型有专门优化，用那个组合通常更省心。另外，Agent 的调试比普通应用麻烦得多，因为中间步骤多、状态复杂，一定要有完善的日志和可观测性，否则出了问题根本不知道是哪一步错的。
4.4 Agent 安全与记忆管理
Agent 能调用工具、能访问外部数据，安全风险就上来了。提示注入、工具滥用、越权访问，这些都是真实存在的问题。选型时要考虑模型对恶意指令的抵抗力，以及框架层面有没有权限控制。
记忆管理也是个大话题。Agent 需要记住历史交互，但上下文长度有限，怎么取舍、怎么压缩、怎么检索，都是工程问题。现在有一些专门做 Agent 记忆的方案，思路是把重要信息结构化存储，需要时检索回来，而不是全塞进上下文。这个方向值得关注，但落地时要注意检索质量和延迟。
5. 微调、部署与成本控制的实战细节
选完模型只是开始，真正落地还要过微调、部署、成本这几关。
5.1 微调到底值不值得做
微调不是必选项。如果你的任务用 prompt 工程就能解决，就别折腾微调。微调适合这几种情况：任务非常垂直、有大量标注数据、对效果要求高、且 prompt 工程已经到瓶颈了。
微调的成本不只是训练成本，还有数据准备、评估、维护的成本。而且模型更新后，微调成果可能要重做。所以做之前一定要算清楚投入产出比。我的建议是先用 prompt 工程和 RAG（检索增强）试试，实在不行再上微调。
5.2 本地部署的硬件与框架选择
本地部署的核心约束是显存。模型参数量、量化精度、上下文长度都影响显存占用。粗略估算：7B 模型 FP16 需要约 14GB 显存，4-bit 量化后约 4-5GB；70B 模型 FP16 需要约 140GB，量化后也要几十 GB。消费级显卡（如 24GB 显存）能跑 7B 到 13B 的量化模型，再大就得上专业卡或多卡。
推理框架方面，常见的有几种，各有侧重：有的追求吞吐量，适合服务多用户；有的追求低延迟，适合实时交互；有的对量化支持好，适合资源受限场景。选框架时要看它支持哪些模型格式、量化方案、以及有没有你需要的功能（如流式输出、并发处理）。
5.3 成本控制的几个实用手段
成本控制有几个立竿见影的手段。第一是模型路由，简单任务走便宜模型，复杂任务走强模型，能省不少钱。第二是缓存，相同或相似的请求复用结果，尤其是那些高频重复的查询。第三是上下文压缩，别把没用的历史全塞进去，精简上下文能显著降低 token 消耗。第四是输出长度控制，明确要求模型简洁回答，避免它长篇大论。
还有一个容易被忽略的点：prompt 本身的 token 消耗。如果你的系统 prompt 写了几千字，每次调用都要带上，累积起来很可观。定期精简 prompt，去掉冗余描述，也是省钱。
5.4 效果评估不能只看感觉
模型上线后，一定要有量化评估。我见过太多团队凭"感觉"判断模型好不好，结果出了问题才发现效果早就下滑了。评估要覆盖：准确率、响应时间、成本、用户反馈。最好建一个持续评估的机制，定期用固定测试集跑一遍，监控指标变化。
评估集要包含正常案例和边界案例。边界案例最能暴露问题，比如超长输入、模糊指令、对抗性输入。这些场景平时不常遇到，但一旦遇到就是事故。
6. 选型决策的完整落地路径
把前面这些串起来，给一条可执行的选型路径。
6.1 从需求梳理到模型短名单
第一步，明确需求。你的任务是什么类型？对延迟、成本、合规有什么要求？需不需要私有化？把这些写清楚。第二步，根据需求列短名单。通用任务看头部模型，垂直任务看有针对性优化的模型，私有化需求看开源模型。第三步，用自建评测集跑短名单，淘汰明显不合适的。
6.2 小规模验证与灰度上线
选定 1-2 个候选模型后，先小规模验证。用真实流量的一小部分跑，观察效果和稳定性。这个阶段重点看：模型在真实分布上的表现、异常情况下的行为、成本和延迟是否符合预期。验证通过后再逐步放量，灰度上线，随时准备回滚。
6.3 持续迭代与模型更新策略
模型是会更新的，今天选的不一定明天还合适。要建立定期复评机制，新模型出来时用同一套评测集跑一遍，看有没有必要切换。但也不要频繁切换，切换本身有成本，而且可能引入新的不确定性。我的做法是：除非新模型在核心指标上有明显提升，否则不轻易换。
6.4 一个真实的选型复盘
最后分享一个我参与过的选型案例。项目是一个中文客服 Agent，需要多轮对话、工具调用、知识检索。最初用的是海外某强模型，效果不错但成本高、延迟大，而且数据出境有合规顾虑。后来换成国内某模型加私有化部署，成本降了一大截，中文理解还更好，但工具调用稳定性稍差，通过优化 prompt 和加了一层结果校验补上了。最终方案是混合路由：简单问答走小模型，复杂任务走大模型，整体成本和效果都达到了预期。
这个案例的教训是：没有完美的模型，只有合适的组合。选型不是选一个"最强"的，而是设计一套"最合适"的方案。
我在实际项目里最大的体会是，模型对比这件事，七分靠测试三分靠信息。别人的结论只能帮你缩小范围，最终拍板一定要基于你自己的数据和场景。另外，别忽视工程侧的建设——好的 prompt 管理、完善的日志、灵活的模型路由，这些"周边"对最终效果的影响，有时候比换一个模型还大。
