1. 把“推理能力”拆开：业务眼里它不只是“答得对不对”

1.1 榜单上的推理分数，为什么一到业务就失灵

先说一个我自己的经历。去年我们团队给一个客服系统做大模型选型，当时看榜单、看评测集，几款主流模型在数学、代码、逻辑推理上的得分差距并不大，最后选了个综合分数最高的。结果上线第二天，高峰时段用户反馈“转圈圈、答不出来、越问越慢”，我们连夜查，发现大部分问题根本不在“模型懂不懂”，而在“模型在并发压力下能不能稳定地回”。

这就是很多人选型时容易踩的第一个认知差：榜单评测的是“单轮、单用户、无压力”条件下的智力水平，而业务考验的是“多轮、多用户、高并发”条件下的服务韧性。大模型推理能力这个命题，在业务落地场景里至少被拆成了四层：

• 语义层：模型答得对不对、逻辑通不通、是不是符合业务口径；
• 时延层：用户发出请求到开始收到回复，到底要等多久；
• 吞吐层：单位时间能跑完多少请求，能不能抗住波峰流量；
• 稳定性层：连续跑几个小时、几天，时延会不会漂移，显存会不会涨，服务会不会挂。

前两层大家都会测，后两层越接近真实业务场景越重要，但恰恰最容易被忽略。很多公司的选型报告写了十几页，最后决定因素却是“谁的demo演示效果更好”，这放在生产环境里是非常危险的。

1.2 业务侧真正该盯的五个硬指标

我在实际项目中总结了一套“最小可用的推理能力评测指标集”，不追求实验室级别的严谨，但求能帮我们在两天内判断一种模型托管或推理服务能不能上线。

我见过一个很有意思的例子：某业务做内容总结，prompt平均输入长度只有500字左右，选型时所有模型的TTFT都差不多，都很优秀。结果上线后用户经常贴上一整份合同文本（8000多字）让模型做摘要，TTFT瞬间从0.5秒飙到了5秒以上，不同模型之间的差距一下拉开到3倍。这就是典型只测了“平均情况”、没测“分布边界”导致的选型失误。

所以，从业务落地的视角谈论大模型推理能力，第一原则是：先定义你的业务场景长什么样，再去比较模型的能力，顺序不能反。

2. 稳定性为何压过一切：一次线上事故教会我的事

2.1 一次事故的完整复盘：从评测高分到线上拉胯

回到我前面说的那个客服项目。当时我们选的模型，在公开评测和内部抽测中表现都很好，单次请求的响应质量远超预期。但上线后的真实路径是这样的：

• 上午10点到11点，流量逐步上升，服务正常，平均时延600ms左右；
• 11点20分，达到当天第一波高峰，平均时延开始走高到1.2秒，P95到2.8秒；
• 11点40分，部分请求开始超时，客户端自动重试，重试流量进一步加重服务端压力，形成恶性循环；
• 12点，服务彻底不可用，监控面板上一片飘红。

我们当时的排查思路是先怀疑模型本身，把模型换了更小一号的版本，问题依然存在；再怀疑是GPU机器规格不够，扩容了机器，但只是延缓了故障发生的时间；最后定位到根因，是推理框架在高并发下对KV Cache的分配策略导致显存碎片化加剧，请求一多直接触发OOM（内存耗尽），部分请求被强制杀掉，从而出现大面积超时和错误。

这个排查过程大概用了三个多小时。事后我们复盘，最核心的教训是：在业务侧，模型推理的弱项往往不是“答错”，而是“服务行为不可控”——你不知道它在什么条件下会劣化，劣化的方式是什么，这比功能缺陷更难防范。

2.2 五类“软故障”才是稳定性的真正杀手

那次事故之后，我们专门整理了大模型推理服务在业务环境里的五类高频故障模式，它们都有一个共同特点：不在功能测试里暴露、不在单请求评测里暴露、只会在压力或长时间运行中慢慢现形。

1. 长尾时延失控：并发数增加时，大多数请求仍然很快，但有一小撮请求时延成倍增长，直接拖垮P99，触发下游超时重试；
2. 上下文劣化：多轮对话中，随着对话轮次增加和上下文累积变长，生成质量下降，甚至出现“答非所问”或复读机式输出；
3. 显存碎片化与OOM：服务长时间运行后，显存中KV Cache不断分配释放，碎片化导致明明总量够用却分配不出连续空间，模型进程崩溃；
4. 队列雪崩：请求排队机制设计不当，当流量波峰到来时队列积压，排队等待时间超过用户心理上限，表现为“服务假死”；
5. 推理引擎的偶发异常：某些特定输入组合会触发beam search或采样逻辑的边界bug，导致请求卡住或返回空结果，偶发性极强，复现难度极高。

这五类问题，我在不同团队的实践里基本都见过，有些团队遇到过其中两三种，但几乎没有人能完全避免。这也是为什么我在做选型评估时，会把“稳定性”放在核心权重里，甚至超过“单次推理的智力水平上限”。因为智力水平再高，只要服务不稳定，业务就永远无法真正上线——用户不会因为某个瞬间模型很强就原谅它五分钟一次的超时。

3. 用火山引擎做实测：一份可复用的推理稳定性评测流程

说回火山引擎。坦白讲，我们当时也不是冲着“它一定最好”去测的，而是因为业务里本来就用了火山引擎的GPU云服务器和方舟大模型服务平台，干脆就近做了一轮深度评测。没想到这个评测过程本身，反而帮我们把“推理稳定性”这件事彻底摸透了。下面这套流程是从那次实战里提炼出来的，你可以直接抄。

3.1 用真实业务构造评测集，而不是照抄benchmark

固定思维里，评测大模型推理能力当然要跑公开数据集。但公开数据集的问题在于，它代表的是“平均水平”，不代表你的业务流量模型。我建议构造一个“三层评测集”：

• 第一层：标准能力集。GSM8K、MMLU这类经典基准选一部分，用来确认模型的基础智力没有明显短板，顺便和公开卡点对标；
• 第二层：业务真实集。从线上日志里脱敏抽取1000条真实用户请求，包含公司业务的专有名词、长文本、特殊格式（比如发票信息、合同条款、售后工单），这是评测的“主战场”；
• 第三层：边界压力集。人为构造超长输入（比如5k、8k、16k token的文本）、超多多轮对话、超高并发的请求序列，用来专门压测前面说的五类软故障。

我当时带着这套三层评测集，在火山引擎上分别测了方舟的API托管服务和自部署的GPU实例两种模式。第一步先跑标准能力集，核心目的不是比谁分数高，而是确认“同一个模型在A平台和B平台上，智力水平是一致的”，如果这一步有差异，说明平台的预处理（比如系统提示词注入、tokenizer版本）有猫腻，后面的测试数据就不能直接比较。

3.2 分阶段压测：时延、吞吐、长尾一个都不能少

压测一定要分阶段做，不要一上来就放几十个并发全量打。我的操作习惯是：先用1路并发、8路并发、16路并发、32路并发、64路并发五个梯度，每个梯度跑10分钟，中间休息1分钟，记录TTFT、生成速度和P95/P99。这样做的好处是能画出“性能衰减曲线”，而不是只拿到一个孤立的峰值数据。

以我们当时测一个70B级别模型为例（示意数据，非精确值）：

这张表看起来不复杂，但信息量很大。注意看P99和错误率，它们比平均值的增速快得多。如果当初我们只看平均TTFT，会得出“64并发下服务还扛得住”的错误结论，但P99已经到6秒，放在客服场景里意味着有1%的用户要等6秒以上，加上重试机制，系统实际上已经开始不稳定了。

当时我们在火山引擎自部署的GPU实例上跑完这个梯度压测，又用方舟的API服务同样测了一遍，发现方舟在高并发下P99的增速更平缓，错误率也更低。这里有个容易被忽略的点：同样的模型、差不多的GPU规格，不同服务平台的调度和排队机制不同，稳定性表现可以差出很多。不要觉得“模型一样，服务肯定一样”，事实并非如此。

3.3 48小时长稳测试会暴露什么

短时间压测能暴露吞吐瓶颈，但真正决定能不能上生产的是长稳测试。我的建议是至少跑满24小时，如果条件允许直接跑48小时。长稳测试里要盯的不是“性能”，而是“趋势”：

• 显存占用曲线是否随时间持续上涨（是否存在KV Cache泄漏）；
• 时延是否呈周期性恶化（比如每30分钟、每1小时出现一次尖峰）；
• 错误率是否随运行时间缓慢爬升；
• 连续多轮对话的平均响应质量是否下降。

我们当时在火山引擎上用一段混合流量的脚本（模拟真实业务的高低峰交替）跑了48小时。最值得说的是显存曲线：在自部署的裸GPU环境里，如果我们不配置定期的模型实例重启，显存占用会随着请求累积缓慢上升，最终在某一个时间点触发OOM；而在方舟的托管服务上，平台会自动做实例的健康检查和重新调度，显存曲线被控制在一个稳定区间，整个48小时没有出现一次OOM级故障。

这就是托底能力的差异。自部署模式下，所有运维细节都得自己扛；托管模式下，平台把这些稳定性工程做在了底层。对很多业务团队来说，后者的价值远大于省下来的那点GPU租金差额。

4. 稳定性的工程源头：火山引擎的推理底座到底做了什么

很多朋友问过我同一句话：“火山引擎的推理能力凭什么更稳？”这个问题用一句话回答不准确，得从工程底座一层层拆。

4.1 推理引擎选型：vLLM还是SGLang，火山做了什么适配

大模型上线推理，绕不开推理引擎。目前主流的开源方案无非是vLLM、SGLang、TensorRT-LLM这几个，各有各的长处：

• vLLM：生态最成熟，PagedAttention解决了KV Cache显存碎片化问题，连续批处理能力好，社区文档多，是大多数团队的首选；
• SGLang：优势在于RadixAttention，对多轮对话和前缀复用场景做了专门优化，高并发下吞吐表现亮眼；
• TensorRT-LLM：走的是极致性能路线，通过图优化和算子融合把单卡吞吐推到最高，但部署和调参门槛偏高。

火山引擎的做法不是押注某一个引擎，而是做了一个统一的推理底座层，把多个引擎的适配都收拢进来。对使用者来说，不需要自己研究引擎参数怎么配、算子怎么选、并发策略怎么调，平台已经把这些东西封装掉。我们自部署时为了调vLLM的--max-num-seqs和--max-model-len组合，花了整整两天试错；在方舟上，同样的模型扔上去，平台按输入长度动态分配，开箱即用。这不是说自部署没有价值，而是说托管服务把“工程复杂度”前置消化了，对多数业务团队更友好。

4.2 连续批处理与显存管理：两条最容易翻车的技术线

推理稳定性的核心，一半在批处理策略，一半在显存管理。

批处理这块，早年很多推理服务用的是“静态批处理”：攒满一个batch才一起推理，一个batch里所有请求必须全部完成后才处理下一批。这样做的毛病是，只要batch里有一个慢请求，整批都得等它。现在的连续批处理（Continuous Batching）改成了“谁先干完谁先走”：一个请求生成完最后一个token立刻释放资源，新请求可以马上插进来，不用等整批结束。这套机制保证了高并发下不会被少数慢请求拖死，是推理服务稳定性的关键地基。

显存管理同样致命。大模型推理时，每生成一个token都要把历史token的KV Cache存下来，这些缓存占用的显存远比你想象的大。vLLM的PagedAttention把KV Cache切成小块，按需分配，类似于操作系统里的分页式内存管理，能显著降低碎片化。火山引擎在自建推理底座时，顺着这条路做了更细的显存池化管理：不同大小的请求从池子里分配显存，回收后立刻合并回池子，避免长时间运行后的碎片累积。这就是为什么托管服务里长稳表现好，因为它把显存这块最脏最累的活接过去了。

4.3 从单卡到PD分离：扩展路径同样是稳定性的一部分

业务增长后，推理迟早要从单卡扩展到多卡。这里有几条路径，每条路径的稳定性含义完全不同：

• 单卡推理：适合小模型或业务初期。很多人喜欢本地部署qwen这类27B模型，我实测下来，单卡推理的瓶颈根本不是显存容量——27B量化后显存装得下——而是显存带宽。A系列显卡跑27B模型，生成速度会受到显存带宽的硬限制，模型再聪明也快不起来；
• 多卡Tensor并行：把一个大模型切到多张卡上，每张卡算一部分，通过高速互联协同。好处是能跑更大的模型，坏处是通信开销随卡数上升，扩展性不是线性的；
• PD分离（Prefill/Decode分离）：把计算密集但短暂的预填充阶段（Prefill）和访存密集但持续的解码阶段（Decode）分别部署到不同机器上。这两类任务混在一起时会互相拖累，分离后互不干扰，高并发下的时延稳定性显著提升。

火山引擎的推理底座在国产化算力和主流GPU上都做了适配，支持从单卡到多卡、再到PD分离的平滑升级。这一点在业务落地时特别关键：你不想因为换了一个更大的模型就把整个基础设施推倒重来。推理平台的扩展路径顺滑与否，本身就是稳定性的另一个维度——架构切换期的阵痛也是故障。

5. 给选型人的一套实操打分表：别让“哪家好”停留在嘴上

5.1 一套可复用的推理能力打分表

标题问的是“大模型推理能力哪家好”，但我在实践中逐渐意识到，这个问题不能脱离业务场景泛泛回答。为了让自己和团队不再拍脑袋选型，我整理出一张可配置权重的打分表，每次做选型评审时直接套用：

我个人会给出的建议是：客服、工单、知识库这类“高并发响应型”业务，把稳定性相关权重（TTFT、P99、长稳）合计加到60%以上；而内容创作、代码生成这类“重质量型”业务，可以适当提高单请求质量和生态工具的权重，但稳定性仍然不应该低于40%。因为内容类业务通常也是长时间批量调用，一次性跑几百个生成任务，如果中途挂掉，损失更大。

5.2 四个真实踩坑案例，帮你把权重调对

有了打分表还不够，权重怎么调才是真正体现经验的地方。我整理了四个踩坑案例，每个都对应一个容易被低估的维度：

案例一：某团队只测单并发，觉得某模型速度快、质量好，结果上线后40路并发时P99直接爆表，用户投诉“系统好慢”，最后只能紧急扩容加限流。教训：并发梯度压测必须做，只看单路等于没看。

案例二：某团队用平均时延做选型，忽视了长输入。他们的业务是法律文书分析，用户经常提交上万字的合同，模型输入一长，TTFT从0.6秒涨到4秒，平均数据完全无法反映这个变化。教训：要用业务真实的输入长度分布去测，而不是用标准评测集里几百token的短输入去测。

案例三：某团队在托管API上测了一套数据，决定自部署后直接用开源引擎跑，结果性能掉了30%以上。后来发现是引擎参数没调（并发队列、KV Cache策略默认值不适合他们的流量模型）。教训：托管服务和自部署要分别评测，不能互相替代。

案例四：某团队做了压测、做了长稳，但上线后模型开始在多轮对话中“越聊越笨”，前几轮回答正常，十几轮后开始重复输出无意义内容。这是上下文窗口管理的问题，不是推理能力问题，但业务感知就是一塌糊涂。教训：长稳测试的请求里要包含真实的多轮对话序列，不能只测单轮问答。

这些案例的共同点在于：评测维度的缺失，往往会等到上线后才以事故的形式暴露出来。与其事后救火，不如选型阶段就按业务场景把权重定好，把该测的全测一遍。

6. 一点个人体会，写在最后

这篇文章从“大模型推理能力哪家好”开始，绕了一大圈，最后我想说的是：模型能力决定天花板，推理稳定性决定地板，而对绝大多数业务来说，地板比天花板重要得多。

今年大模型迭代速度快到团队追不过来，每过几个月就有新模型发布，分数更高、推理更强。模型可以随时换，这在选型时往往是最简单的一步；真正难的是换推理底座——把服务从一个平台迁到另一个平台，涉及数据、监控、运维、成本结算，每一步都是隐性成本。火山引擎在推理稳定性上的投入，本质上帮你把这块最难的地基打好了，让你把精力留在业务逻辑和模型应用层，而不是天天盯着显存曲线救火。

不管你最终选哪家，我的建议都是一样的：先拿自己业务的真实数据，跑完前面说的三层评测集和48小时长稳测试，再做决定。这套流程不会骗你。