这一章我们聊聊厂商AI能力对比。系列写到这里，前面几章把模型微调、RAG、Agent这些技术底座都聊得差不多了，很多团队开始进入下一个阶段：技术方案跑通了，要上生产、要扩容、要接更多业务线，于是发现自己手头的算力和模型服务撑不住了。这时候“换供应商”和“多供应商备份”就会提上日程。但真到选型阶段，你会发现各家官网上的数据一个比一个漂亮，参数一个比一个激进，可真正拿自己的业务场景一压，差距立刻显形。这一章就是帮你把“厂商AI能力对比”这件事做成一套可持续执行的流程，而不是靠感觉拍板。篇幅比较长，我按能力拆解、维度设计、压测流程、效果评测、成本核算、问题排查六个部分来讲，全程用虚拟厂商A/B/C代称，重点是方法论，看完你直接能拿去套用。
1. 先把“AI能力”拆开，别被一个跑分带走
做厂商对比，最容易犯的错就是把“模型跑分榜单排名”当成能力全部。实际上一家厂商能不能承接你的业务场景，要看的是从底层算力到上层工程化的完整链路。我习惯把 AI 能力拆成三层：算力层、模型层、工程化层。任何一个短板的出现，都可能让上层跑分变成废纸。
1.1 算力层：不只是显卡数量的游戏
算力层是很多团队最先忽略、后面最容易卡脖子的地方。你去看厂商官网，最直观的是“我们有多少卡”“算力规模多少P”，但这些数字只代表“有”，不代表“你能用得上”。
我举一个典型场景：某团队在厂商A上训练一个领域模型，训练任务提交后排队等了几个小时，好不容易开始跑了，没到一个小时又因为同集群其他大任务抢占资源，训练速度从预期的稳定输出变成忽快忽慢。后来一查，独享资源池和共享资源池是完全两码事。算力层的对比，至少要看四个指标：
第一个是配额和弹性。你开通账号后默认能拿到多少卡配额？按需扩容的响应速度是分钟级还是天级？动态扩缩容是否自动、是否需要提工单？我见过有厂商的配额审批要走三层流程，生产流量突然翻倍时根本来不及。
第二个是硬件代际一致性。宣传文案里写的可能是最新架构的卡，但实际分配给你的是上一代甚至上上代的存量资源。压测时必须确认实际拿到的卡型号、显存、互联带宽，别被“等效算力”这种描述带偏。
第三个是资源隔离和稳定性。共享集群是否存在“噪邻效应”？同集群其他用户的大任务会不会导致你的推理时延波动？这个很难从官网看出来，需要实测——后面第三章的压测流程会专门讲怎么测。
第四个是数据托管的合规边界。模型权重、业务日志、用户数据落到厂商的存储以后，删除流程是否透明？是否支持完全私有化部署？有些行业对数据主权要求极高，这一项直接决定厂商是否进入候选名单。
算力层的隐藏成本还体现在链路设计上：如果你只是调用API，算力层的真实性能会被厂商的调度系统“包裹”起来，你看到的时延已经是厂商优化后的结果。这时算力层的对比意义在于“上限在哪”“瓶颈在哪”，而不是单纯比谁的卡多。
1.2 模型层：榜单之外的实测差异
模型层是大家最关注的一层，也是最容易被营销牵着走的一层。公开榜单说明的是“在这套测试集、这种采样参数下，模型跑出了什么分”，换到你的业务场景，效果可能完全不是一回事。
模型层的对比需要落在几个具体维度上。模型家族覆盖度：厂商是只有一款旗舰模型，还是同时提供不同参数规模、不同成本档位的系列模型？真实业务里，简单分类任务用小模型就能搞定，硬要调旗舰模型属于纯浪费。指令遵循的稳定性：同样一个Prompt，同一个模型在不同时间调用，输出格式是否始终一致？我在实际项目中遇到过厂商模型在询答复时一次对一次错，原因就是采样参数的随机性在某些实现里没调好。
上下文窗口和长文本能力：宣传说支持128K上下文，实际用起来中间部分的“注意力”可能已经塌了，长文档检索经常丢关键段落。这里建议你自己做“大海捞针”测试，在一段超长文里埋入一个特定事实，看模型能不能准确回忆起来。多模态的实用性：能识别图片不等于能准确理解图片里的表格、手写文字和复杂版面。如果你的业务涉及OCR类任务，必须拿自己行业的样张去试。
另外一个模型层的隐藏变量是“版本漂移”。厂商在后台悄悄迭代模型版本，同一套API描述、同一个接口，Prompt的输出会变化。对生产系统来说，这是比技术指标更头疼的稳定性问题。可以咨询厂商是否有版本固定策略，或者在评测阶段就建立实时质量监控基线。
1.3 工程化层：真正决定落地效率的那一层
很多团队在对比厂商时只看前两层，但我做了几次选型之后可以负责任地说：工程化层才是决定研发效率的天花板。表现在几个细节上。
第一是API的成熟度，包括限流策略是否透明、错误码是否有区分度、是否有完整的幂等机制。有些厂商的API设计让你连“重试”都不敢随便加，因为分不清是请求没到还是处理失败。第二是SDK和多语言支持，主流语言自不必说，更重要的是是否有客户端负载均衡、自动重试、超时控制这些生产级组件，而不是只给你一个HTTP接口让团队自己造轮子。第三是调试工具链，比如推理日志采样、Token用量明细、Prompt实际触发内容的追查能力。没有这些，线上出问题只能靠猜。第四是售后与技术支持的水平，问题工单多久响一次、有没有值班群、是否有专项解决方案架构师跟进，这些在大规模迁移时直接决定项目的生死。
工程化层还有一个容易被低估的点：批量离线处理能力。如果你要跑几千甚至几万条离线推理任务，厂商是否提供异步批量接口？费用有没有折扣？任务排队策略如何？有些厂商在这个场景下专门提供廉价算力，成本和实时接口能差三到五倍。
2. 选型之前先建好对比维度矩阵
把能力拆成三层之后，下一步不是急着找厂商聊，而是先把“我们要比什么”定下来。没有维度矩阵的对比，最后必然变成销售PPT的比拼。我建议的维度矩阵包含六类一级指标，并且每个一级指标都要拆到可量化的二级子项。
2.1 六类一级指标，每条都能量化打分
第一类是可用性。包括SLA承诺值、实际可用性、故障恢复时间、限流策略和配额弹性。可用性不是口头承诺，要看合同条款里的赔偿机制。第二类是性能。包括首Token时延、正常并发下的吞吐、峰值并发下的P99时延、错误率、长连接稳定性。第三类是效果。包括业务场景下的准确率、格式遵从度、上下文利用能力、多模态准确度。第四类是成本。包括基础单价、批量折扣、私有化部署成本、迁移成本、试错成本。第五类是数据合规。包括数据存储地域、训练数据是否会被用于改进模型、删除机制、私有化支持度。第六类是工程体验。包括API完善度、SDK质量、调试工具链、工单响应速度、文档质量。
从这六个指标出发，我给一个可以直接抄的评分模板。每个一级指标下再拆两到三个二级子项，每个子项按1-5分打分，按权重加总，最后得综合分。你不用一口气把所有的项都定义得很细，先定出大框架，压测之后再回填分数就行。
2.2 不同业务场景，权重天差地别
同样是六个维度，不同业务场景的权重分配完全不同。我举几个常见场景：
如果你是做面向公众的C端内容生成工具，那么效果和成本权重最高，效果好不好用户直接流失，成本直接吃掉毛利。如果你是做金融或医疗领域的内部系统，数据合规和可用性权重压倒一切，效果反而是其次——因为错误可以被流程兜住，但数据出界是事故。如果你是做To B定制交付的项目制公司，工程体验和售后响应权重最高，因为你要拿厂商的工具去给甲方搭系统，工具难用等于你的人力成本翻倍。
我自己的一般做法是：先用初始权重出一版评分，再拉团队一起看一遍权重合理性。核心是让参与选型的人对齐评分口径——销售嘴里说的“能力很强”和你团队定义的“能力很强”经常是两个完全不同的东西。在权重表上写下来，就是把自己的定义固化下来。
为了方便理解，我给一个面向“中大型企业知识库问答系统”的权重示例：
| 一级指标 | 二级子项 | 权重 | 说明 |
|---|---|---|---|
| 效果 | 检索问答准确率 | 20% | 业务核心 |
| 效果 | 格式与引用遵从度 | 10% | 知识库场景必须可追溯 |
| 性能 | 首Token时延 | 8% | 内部工具可容忍秒级 |
| 性能 | 高并发吞吐 | 7% | 全员使用时的峰值 |
| 成本 | 百万Token综合成本 | 10% | 预算约束 |
| 成本 | 私有化部署成本 | 8% | 可能做数据隔离 |
| 数据合规 | 数据存储与删除 | 15% | 涉敏场景权重极高 |
| 可用性 | SLA与故障恢复 | 10% | 内部工具要求相对低 |
| 工程体验 | API与SDK成熟度 | 7% | 决定开发排期 |
| 工程体验 | 工单响应速度 | 5% | 生产故障救急 |
这个表格看着简单，但权重落下去之后，很多纠结就自然解开了。比如厂商A的模型效果明显好一截，但数据合规只能打低分，综合算下来总分一样甚至更低，你就不用再为“效果是不是真的香”而消耗团队精力。
3. 性能压测流程：拿自己的数据说话
性能对比不能拿厂商给的测试报告讲事，必须自己跑压测。这里说的压测不只是“十万个并发打一下看看通不通”，而是设计一套能暴露真实生产问题的测试方案。
3.1 测试前的准备：先定场景，再从业务日志里取样
压测最怕的就是拿一堆通用测试集跑一遍，得出个平均数就完事。正确做法是先从自己的业务日志里抽取有代表性的Prompt样本。如果你是客服系统，就抽那些长度中等、带多轮对话上下文、用户口吻随意的真实句子；如果你是代码生成工具，就抽那些带工程上下文、需要跨文件理解的请求。样本数量不用太大，两三百条足以覆盖主要模式，但一定要保证“像你生产环境里的输入”。
还要提前定义好“通过标准”。是P99时延小于3秒？是错误率低于0.5%？还是每分钟成功处理请求数达到某个阈值？这些标准要写在测试计划里，并且让团队有个共识：达不到就等厂商优化或者直接淘汰。
压测环境也要注意：测试账号的配额要与生产预期的并发量匹配，否则压测触发了限流，测出来的结果只反映了厂商的配额策略而不是实际能力。另外，要记录压测时段，避开厂商的全局维护窗口。
3.2 压测执行：从单请求到峰值并发的阶梯加压
压测执行建议采取阶梯式加压，而不是一上来就满负荷。流程大概是：
第一步，单请求基准测试。对每一条Prompt样例，连续调用若干次，记录首Token时延、总时延、每次响应内容是否一致。这步的目的是确认模型在无并发压力下的原始表现，也是检验输出稳定性的起点。
第二步，逐步提高并发。比如从10并发、50并发、100并发一直加到目标峰值。每个阶段跑5-10分钟，观察时延是否线性增长、是否出现错误、是否触发限流提示。
第三步，峰值保持。在目标峰值并发下持续跑30分钟以上，观察长尾时延的抖动。很多厂商扛得住短时峰值，但长跑之后就出现内存泄漏、连接池耗尽、个别节点被降级的问题。这一步最能反映真实生产体验。
第四步，突发流量模拟。从低并发瞬间拉升到高并发，模拟业务突然爆发的场景，看厂商的自动扩容是否跟得上。
在并发压测时，要同时记录几类关键指标：首Token时延（TTFT）、Token生成吞吐（tokens/s）、请求错误率、限流触发次数和响应体完整性。如果出现内容被截断但HTTP状态码还是200的情况，这比直接报错更隐蔽，后面接排查流程时要重点盯住。
我拿一次实际选型压测举个例子。当时我们同时压测厂商B和厂商C，同样的Prompt样本集每个厂商跑了三轮，厂商B的P50时延看起来和厂商C差不多，但P99时延从1.8秒直接跳到9秒，原因是厂商B的推理集群在某几条路由链路上出现了热点，流量一上来就倾斜到少数节点。这个现象在官网指标上完全看不出来，只有在P99这个分位数上才现形。所以千万不要只看平均值，P99、P999这些长尾指标才是生产稳定度的真身。
3.3 压测报告的数据怎么读
压测结束后的报告，第一眼不要看平均数，先看三个地方。第一是错误率曲线是不是随并发增长而抬升，抬升点对应的并发量就是这台服务的“真实天花板”。第二是时延分布的分位数差距，P50和P99差三倍以内算正常，差到五倍以上说明调度存在严重抖动。第三是恢复时间——把并发降下来以后，各项指标是否快速恢复正常。如果恢复很慢，说明系统里有队列积压。
读取这些数据时也要留一个心眼：厂商的客户成功经理一般都会给你解释“压测方式不同导致结果差异”，这不是废话，确实有真实影响。如果压测结果和厂商标称值差太远，先排查你的测试账号是否被限流、并发模型是否是短连接、请求体里是否带了会改变路由的字段，再下结论。
4. 效果评测：把“感觉好”变成看得见的分数
性能只是“跑得动”，效果才是“跑得好”。但效果评测往往被做得非常随意——几个团队成员拿几条业务数据试了试，凭直觉投票决定。这种做法的随机性太大，不同人、不同Prompt写法都会带偏结论。我做效果评测的基本思路是四步走：构建评测集、双人打分、随机盲测、差异评审。
4.1 评测集怎么建
评测集要覆盖三类典型任务。
第一类是生成类任务，比如写文案、做总结、生成SQL。这类任务的打分维度是信息准确度、覆盖完整性、格式符合度。第二类是抽取类任务，比如从合同里提取关键条款、从工单里识别问题类型。这类任务的打分维度是召回率和精确率，能精确比较。第三类是推理类任务，比如多步逻辑推理、代码debug、数学运算。这类任务要特别关注逻辑链条是否成立，不能只看最终答案对不对。
每一类任务从真实业务数据中抽20到30条样本，太少了不具统计意义，太多了标注成本承受不了。比较理想的是一套评测集在60到90条之间，覆盖主要业务路径。
4.2 盲测、打分与一致性校验
评测时的执行细节直接决定结果有没有参考价值。两个铁律：打乱顺序，隐藏厂商信息；至少两个人独立打分。盲测很重要，因为人对品牌和口感的先验印象会严重污染评分——你心里觉得某个厂商的模型应该强，给分的手就会不由自主地松。
打分维度建议细化成四个子项：准确率（内容与事实是否一致）、完整度（是否覆盖了用户需求的所有要点）、格式遵从度（是否按要求输出JSON、表格、特定结构）、安全性（是否拒绝回答敏感或违规内容）。每个子项按1-5分打分，再加权汇总。两轮评分之后，把分差大于1.5分的题挑出来，让两位评分者对齐讨论，实在对齐不了找第三个裁判定夺。
效果评测里面最容易忽略的是“Prompt敏感度”。同一个模型，换个Prompt措辞，输出质量可能天差地别。所以做对比评测时，所有厂商都必须用完全相同的Prompt。如果有Prompt工程团队在，可以让团队为每一家厂商单独优化Prompt，看“最优状态下各家达到什么水平”；如果团队没有专职Prompt工程的人，就直接用一份固定Prompt，看“裸状态下的默认水平”。两个结果都记录下来，选型决策参考后者为主——因为你不可能上线后为每个接口都单独调Prompt。
效果评测的最后一件事，是量化“业务可用率”。比如在客服场景，可以直接找有经验的客服团队来看模型的回答是否可以“直接复制发送给用户”，能就直接用，不能就废弃。这样算出来的可用率数据比抽象的评分更有说服力。我当时做某个问答系统时，两个厂商模型直接评分只差0.2，但业务可用率差了整整10%，就是因为高分段和低分段分布形态完全不同——一个是普遍80分，另一个是大量100分加大量40分。这种差异只有落到业务口径才能看出来。
5. 成本账：别被单价误导了总账
成本对比看似最简单，实际最容易踩坑。官网上的“每百万Token价格”只是一个起点，真实成本是由多种因素叠加出来的。
5.1 三层成本结构，每一层都可能超预算
显性成本是API调用费。这个好算，但要注意几个坑：输入Token和输出Token价格是否一样？是否区分缓存命中价格？是否对长上下文有额外计费？批量调用和实时调用价格差多少？这些细节在价格页底部的小字里往往写得清楚，要逐条看。
隐性成本是集成与迁移成本。包括开发适配新API的工时、重写数据管线的成本、Prompt迁移后重新调试的成本、压测与评测花费的人力。我见过一个团队因为贪API单价便宜而切换厂商，结果SDK的差异导致重写了整整两周的对接代码，省下的API费用一年都不够覆盖这两周人力成本。
故障成本是被所有人忽视的一层。厂商可用性不达标导致的生产事故、限流导致的用户流失、版本漂移导致的内容质量波动，这些损失很难直接算钱，但往往比API费用本身大得多。选型时可以用“故障成本 = 故障时长 × 故障期间业务损失速率”做一个粗略估算，把结果直接加到对比表里。
5.2 用临界点公式判断“自建还是调用API”
现在越来越多团队走到“量大时是否自建模型服务”的分岔路口。我的建议是先算临界点，再做技术决策。一个简化版的估算公式可以用起来：
假设你每日调用量为N次，每次平均总的Token消耗量为M，API价格为P元/百万Token，则每日API成本 C_api = N × M × P / 1,000,000。自建时，假设单张推理卡每小时综合成本（含硬件摊销、电力、运维人力）为H元，单张卡片实际吞吐能力为T Token/秒，你需要的卡片数为 K = ceil(N × M / (T × 86400 × 利用率))，则每日自建成本 C_self = K × H × 24。当C_api显著高于C_self时，自建才有讨论的必要。
当然，这只是算力硬成本，自建还要叠加模型调优、系统维护、可靠性建设的人力成本。我给出的经验判断是：如果API月成本不到10万元，自建大概率不划算；月成本几十万元之后再考虑自建才合理。而且自建也有不同路径——直接买卡部署开源模型、租用厂商裸金属集群、用云厂商的托管推理服务，成本和弹性差异巨大。把账算细之前，不要急着拍板。
这里还要提醒一个“Token浪费”问题。很多模型服务商会对输入Token按包含历史对话的上下文长度计算，而团队如果不做对话裁剪，几百轮聊天记录全部塞进上下文，费用会指数级上涨。同样一个业务，厂商A和厂商B如果对上下文的压缩策略不同，看起来单价一样的服务，最终账单可能差30%以上。成本对比务必拿你自己的真实对话数据去测算，而不是用官方示例算。
6. 常见翻车现场与排查思路
最后这部分聊几个我在实际选型中被坑过、也看别人反复踩坑的点，整理成一个速查表，方便你在自己的选型流程里直接对照排查。
| 现象 | 可能原因 | 排查动作 |
|---|---|---|
| 压测时P99时延突然飙升 | 共享集群噪邻效应或路由热点 | 查看节点分布，换时间段复测，确认是否为独享资源 |
| 同样Prompt不同时刻输出差异大 | 版本漂移或采样参数随机性 | 确认是否固定模型版本号，关闭随机采样参数再看 |
| 高并发时大量限流报错 | 测试账号配额低于生产需求 | 与厂商约定压测专属配额，不要用免费额度压测 |
| 长文本阅读理解出现明显遗漏 | 上下文窗口压缩导致中间信息丢失 | 单独做大海捞针测试，逐步加长文本找拐点 |
| 效果评测分数高但业务可用率低 | 评分维度太粗，没看出低分尾巴 | 增加业务可用率口径，让一线人员参与盲测 |
| API单价低但月账单高 | 输入Token重复计费或缓存未生效 | 拉Token用量明细，检查缓存命中率 |
| 官网标称并发很高但实测达不到 | 标称值是在理想环境下测的 | 关注合同SLA，要求厂商给出可验证的承诺值 |
| 切换API后开发排期明显拖长 | SDK和工具链不成熟 | 选型阶段就安排一名工程师写PoC代码验证集成体验 |
排查思路的核心是：任何单一指标异常，都先复现，再归因。不要因为一次压测表现就能给厂商下最终判断，也不要被厂商的方案解释带着走。你只要坚持让数据说话，再配合一套相对完整的维度矩阵，选型结论的可靠性就会高很多。
写到最后，再把我的选型心得总结一下。我做过多次厂商AI能力对比之后最大的体会是：选型这件事非常像“通过试用装买正装”，试用时间必须超过一定阈值，你才可能看到真实的样子。厂商的Sales可以给你演示最好的百条案例，但你的业务数据会在后续几百次真实调用里告诉你全部真相。所以我会在能力接近的候选厂商之间，先做一个为期两周的真实流量灰度，把一部分生产请求切过去，用线上数据来修正之前所有评测结论。这个动作比任何对比表格都有说服力。另外一个小建议：选型对比的结论要写成“该买谁、买多少、怎么备份”而不是“谁更好”。AI能力对比的最终输出不该是排行榜，而是一份可以指导采购决策和容灾策略的具体行动方案。把这几件事想透了，再拿这个框架去跑自家业务，会比绝大多数团队做得扎实。
