先开个盘业务方说“大模型推理能力哪家好”他们真正关心的往往不是榜单上那个跑分而是用户请求打进来模型能不能扛得住、回得快、不报错、不吐乱码。我在生产环境里见过太多“离线测试全绿、上线就炸”的例子问题出在哪呢出在大家没把推理能力拆成延时、吞吐、稳定性三个独立的账来算。这篇就围绕大模型推理能力结合我在业务落地中踩过的坑聊聊为什么火山引擎这类云的推理稳定性会被我特别拿出来说。适合谁看如果你是刚接大模型推理任务的算法工程师、正在做私有化或云上部署的架构师或者被业务方逼着回答“到底用哪家”的选型负责人这篇可以当一份议题清单来用。它不解决所有工程细节但能帮你在答辩或评审会上把话说到点子上。1. 为什么业务落地时“推理能力”的焦点会落在稳定性上1.1 “跑分优秀”和“生产可用”是两套评价体系很多人看的推理能力对比基本是拿公开的MMLU、HumanEval这类评测集跑一次看模型本身答得对不对。这个是模型能力不是推理服务能力。业务落地时真正面对的问题是同一个prompt在凌晨三点高峰期发起请求服务能不能在200毫秒内返回并发涨到500时P99延迟会不会从800毫秒飙到8秒显存OOM之后容器能不能自己拉起而不是把整个集群的请求都拖死。这里要补一个基础概念推理能力在工程视角下至少包含三层。第一层是模型本身的下游表现比如考试、代码生成、对话质量属于离线可评测第二层是推理引擎的效率也就是单卡吞吐、显存占用、prefill和decode阶段的时间配比这层可以用benchmark脚本压第三层是推理服务的高可用能力包括自动扩缩容、异常实例剔除、队列堆积感知、请求级超时熔断。大多数人说“推理能力不行”说的其实是第三层。我见过最经典的生产事故是评测报告显示当前模型的P95延迟只有120ms非常漂亮。结果业务上线当天运维没开弹性伸缩GPU节点只有两卡业务团队也不会看监控大盘高峰期三路由直接把实例打满。队列塞满健康检查开始超时负载均衡把节点摘掉但新请求又疯狂涌向剩下的实例。整个服务雪崩用户侧表现为“对话突然消失或半天不回”。事后复盘才发现事故链里没有一个环节是模型本身有问题全是服务稳定性没兜住。结论很直接业务侧评判推理能力核心不是“谁跑分高”而是“谁的推理服务在长时间、高并发、多租户混跑的压力下依然稳定”。这也是我把火山引擎单拿出来聊的起因因为它的推理面并不是公开刷分的那一套逻辑而是围绕生产可用性展开的。1.2 稳定性的误解不是“不出错”而是“出错后很快恢复”稳定性这个词被说烂了但不同岗位理解完全不一样。算法同学理解的稳定是同一输入输出波动不大运维同学理解的稳定是CPU、显存水位不击穿业务方理解的稳定是“我花钱买服务它得随叫随到”。落地场景里的稳定性恰恰要处理的是“意外”显存碎片化导致OOM、上游框架bug导致推理进程僵死、机房单点故障导致可用性下降、突发流量瞬间打满实例。我习惯把稳定性拆成三个可观测维度来验收可用性单位时间内成功返回的业务请求占比至少三个9起步考核时要把网络超时、HTTP 5xx、模型回复空内容全部算进分母。长尾时延P99甚至P99.9的延迟它比平均延迟更真实反映用户体验。平均100ms但P99是5s这种服务在真实使用中就是“时快时慢”。自愈能力异常节点能否自动摘除、实例被驱逐后能否快速重建、请求失败后是否可重试。这个最容易被选型测评忽略却是线上救命的。火山的推理框架有一个特点我认为做得很扎实它不把稳定性当成某个单点服务的属性而是把稳定性下沉到底层基础设施。也就是即使上层模型实例出问题网络、调度、负载均衡仍然能维持整体可用。这种“平台侧承载稳定性”的设计才是业务落地真正需要的。1.3 为什么要从“业务落地”视角来看推理能力只从技术视角看推理能力容易陷入纯参数对比比不出结论。加上业务落地视角后问题就变成这个推理服务能不能承接我的真实流量模型我的请求峰值是上午10点和晚上8点两个高峰平峰期时长约18小时服务应该怎样保持成本与稳定的平衡如果底层宿主机故障会导致实例重启我的业务是否需要无感知迁移能力这些问题没有统一答案但选型的判断框架是通的。你要看服务商的调度器如何处理抢占、是否支持弹性资源池、监控系统能不能做到分钟级告警、鉴权和限流是不是全链路覆盖。我在落地阶段最喜欢干的事情是把压测流量调到线上真实峰值的1.5倍看服务是否保持稳定。能扛住候选进入下一轮扛不住不好意思不管模型分多高我都不敢轻易接。2. 评估推理能力的核心维度延迟、吞吐、稳定性各占多少权重2.1 三个维度之间是“不可能三角”选型时要排序延迟、吞吐、稳定性在有限的GPU资源下经常互相牵扯。追求极低延迟就要牺牲batch size吞吐必然下降。追求吞吐最大化就要加大batchprefill阶段排队严重延迟会肉眼可见地上涨。稳定性却不是第三个待选维度它是延迟和吞吐的前提。一个偶尔抖动到10秒的“低延迟”服务比稳定在500ms的服务体验差得多。我推荐的做法是先按业务优先级排序强交互产品客服机器人、智能助手、实时语音优先保障延迟允许适当降低吞吐。离线和批处理场景批量内容审核、离线摘要生成优先保障吞吐延迟可以放宽到秒级。所有场景都必须保障稳定性无非是容忍度不同。火山引擎的推理服务在这块有一个明显的工程取向把实例的自动伸缩和队列调度做得比较细。比如流量高峰时新建实例需要拉取模型权重从冷启动到对外提供服务通常要几十秒甚至几分钟。火山引擎的做法是通过预置的弹性资源池和镜像预热机制把新实例就绪时间压缩到很短业务抖动窗口因此显著变小。这一点我在其他平台的自建方案里踩过镜像拉取模型加载经常成为扩容瓶颈属于典型的“看起来能扩容实际扩不起来”。2.2 具体要盯哪些数字从平均延迟到长尾分布评估推理能力不能只看一个“平均延迟”或“平均吞吐”。我在实际压测中至少会记录以下数据指标含义验收参考P50延迟一半请求的响应时间依据业务场景一般对话类2s内可接受P95延迟95%请求的响应时间最能体感用户体验建议小于P50的3倍以内P99延迟长尾响应反映调度和资源争抢情况越低越好超过10s基本不合格QPS峰值单位时间成功请求数压测得到上线时按70%留余量超时率超过业务阈值被熔断的请求占比低于0.5%错误率非200状态或异常回复占比低于0.1%恢复时间故障后服务回到正常水位的时间越短越好分钟级内我为什么要强调P99和超时率因为在真实业务里均值根本骗人。有一次系统表现极佳平均值280ms但业务负责人反馈“用户老说机器人变笨了半天不回复”。我们拉出P99一看直奔8.6秒原因是几个老实例显存碎片化导致推理效率下降调度器又没及时摘除。平均延迟的“平均”会把脏数据稀释掉只有P99和错误率能暴露问题。所以无论是评估自建vLLM部署还是云上推理服务都应该把长尾指标纳入交付标准。不要接受一份只有平均延时和总吞吐的压测报告那是自欺欺人。2.3 业务峰值与容量的换算逻辑在业务落地阶段定义“峰值”是一个关键动作。通常我不看日QPS总量而是看最高那10分钟的QPS再按1.3到1.5倍的冗余预留容量。比如线上最高10分钟是300 QPS那压测至少要跑到400到450 QPS同时观察稳定性的表现。容量规划时可以按下面公式粗算所需并发实例数 峰值QPS × 单请求预期耗时÷单实例最大并发请求数 × 经验冗余系数举例峰值200 QPS预期单请求耗时1秒单实例最大并发为20冗余系数取0.7则200 × 1÷20 × 0.7≈ 14.28向上取整15个实例。这样算出来的基数一般够用但要结合自动扩缩容策略动态调整。如果服务商支持按QPS或GPU利用率自动扩容建议开启并把最小实例数设置为峰值计算量的60%左右避免频繁扩容导致冷启动抖动。火山引擎这类云服务的好处在这里体现出来它既有预设扩容策略也支持自定义指标。你可以直接把GPU利用率超过70%持续3分钟作为扩容触发条件配合预置实例组基本能保证业务高峰期的稳定性。3. 从业务落地看火山引擎的推理稳定性优势体现在哪些环节3.1 推理引擎与调度层的配合说起推理稳定性很多人的第一反应是vLLM、TensorRT-LLM这些引擎本身。它们确实解决了一部分问题比如连续批处理、PagedAttention、算子融合能把单机吞吐拉高。但业务落地时单机吞吐不是瓶颈的全部。更常见的情况是引擎跑得很好外面套的管理层乱了——负载均衡不健康检查、线程池积压、任务队列无界、实例伸缩滞后。火山引擎的推理服务在调度层做了几件很实际的事。第一是实例资源隔离不同业务的推理任务不会共享同一个推理进程避免相互挤兑第二是队列管理突发流量超过实例承载时请求会先进队列排队而不是直接压垮进程;第三是健康检查机制监控每个实例的响应时间、显存、GPU利用率等信号发现异常立刻摘流量。这套机制的意义是当单个实例变慢系统不会把新请求继续分配给它而是让健康实例接管。从用户视角看最多是某一两个请求变慢而不会出现整段服务不可用。这就类比成一个高铁站引擎是列车调度层是进站闸机和轨道分配系统。列车速度再快闸机堵死、轨道分配混乱整个车站依然瘫痪。业务落地的稳定性拼的恰恰是站外系统。3.2 弹性伸缩与故障恢复能力在自建推理服务时最痛苦的事情之一是“扩容慢”。模型动不动几十个GB拉镜像、加载权重、做预热一套流程走下来十几分钟都算快的。云上推理服务的优势就在于把这个冷启动时间压缩到业务可接受的范围。火山引擎的思路大致是维护一个弹性资源池池里的节点预先加载好常用镜像和热数据扩容时从池里直接调实例而不是从零创建。配合弹性伸缩策略可以把扩容时间降到分钟级甚至以下。这对业务的关键意义是高峰期来了能快速顶上高峰期过了又能缩容省钱稳定性和成本同时兼顾。故障恢复也是重点。我之前遇到过底层宿主机硬件故障导致上面所有预实例同时Lost业务中断长达半小时。后来复盘得到的经验是选型前一定要问清楚故障域的隔离级别以及宿主机维保时业务是否会自动迁移。火山引擎在实例调度层面支持跨可用区部署和故障域感知即便某个底层节点异常业务实例也能被调度到其他健康节点可用性保障更加可靠。虽然这类能力在不同云上都有票但真正上线演练过的服务商并不多大家拿压测报告前最好再问一句这些机制是否在生产环境验证过。3.3 多租户与资源争抢对稳定的冲击自建推理服务时经常忽略一个隐患如果一套集群里同时跑离线批处理任务和在线实时推理资源争抢会成为稳定性杀手。离线任务经常把GPU占满实时推理的请求就会被挤到超时。虽然理论上有优先级调度但配置不当或k8s调度器Bug出现时照样翻车。使用火山引擎这类公有云推理服务的隐性好处是多租户隔离和资源配额由平台负责。每个推理任务在独立容器中运行有独立的显存、CPU配额和QoS等级底层的资源争抢基本不会影响业务。我并不是说公有云一定比自己搭更稳但平台把稳定性当成SLA来兜底时业务侧能省去大量运维排障成本。大模型推理一天24小时在线没有专业团队值守时平台自带的重试、熔断、告警能力就成了保障稳定的底线。如果你所在的团队只有两三个人还要分心做数据清洗和prompt调优那我的建议很直接优先考虑云上推理服务让平台兜底稳定性把算法同学的时间留给业务效果。自建推理服务适合团队有一定SRE配置、能24小时响应告警的场景否则省下来的钱迟早变成加班费填给故障。4. 推理稳定性选型实操测试方法、观察指标与避坑经验4.1 三阶段压测法先单路再并发后突发选型阶段我一般不直接信厂商给的白皮书而是搭建一套自己的验证方案。三个阶段必不可少。第一阶段是单路压测用固定Prompt和参数跑1000次观察时延分布和结果是否稳定。这一步排除模型推理逻辑本身的问题比如偶发显存OOM或sample过程中死循环之类。同时也顺手查看推理服务对重复请求的缓存行为有些服务对同样的prompt有结果缓存压出来的延迟好看但失真测试时要在prompt里加随机数打散缓存命中。第二阶段是并发压测用Locust或者自写脚本以50并发起步逐步加到200、500记录P50、P95、P99和错误率。观察延迟是否线性增长。正常情况是P50稍有上涨P99开始扩大但在可接受范围。如果P99突然跳变十几倍说明服务有排队或资源争抢。此时要分清是模型推理时间增加还是调度层排队方法是在客户端记录响应时间的同时在服务端抓取GPU利用率和推理进程耗时。第三阶段是突发压测模拟“瞬间涌入2倍峰值流量”的尖刺场景看服务能否撑住尖刺而不雪崩。这是最考验平台稳定性的环节。我实测过不少服务平时QPS稳定一遇尖刺就疯狂超时然后实例连环崩溃。火山引擎的推理服务在尖刺下表现相对好归功于它的队列缓冲和自动扩容触发阈值设置。多次实测下来只要能准确设定扩容阈值和实例预热数量P99能维持在可经营的水平不会出现全线飘红。4.2 监控项与告警阈值设置样例监控不能等出事了再开。我在部署阶段就会维护一套通用监控面板这里列一下我常用的关键监控项和告警阈值可以直接抄作业监控对象指标建议告警阈值业务层错误率5xx/超时大于0.5%持续3分钟业务层P99延迟超过目标值1.5倍持续5分钟业务层平均响应时间超过目标值持续10分钟资源层GPU显存占用大于92%持续5分钟资源层GPU利用率大于95%持续10分钟需关注资源层CPU利用率大于85%持续5分钟调度层队列深度大于可承载并发数持续1分钟调度层实例重启频率单实例1小时超过2次这套监控的最佳实践是告警不是通知“出事了”而是在出问题前提醒“将有风险”。比如GPU显存超过92%持续数分钟基本能预测接下来会出现OOM或精度下降这时候提前扩容或重启实例比等故障发生再处理要从容得多。我踩过不少过分依赖默认监控方案的坑。很多云服务商的默认监控只覆盖CPU和内存GPU显存、推理时延这类关键指标需要自定义。如果你用的是火山引擎的方舟服务记得在控制台把模型实例的指标配全如果你自建vLLM则需要自己在Prometheus里暴露推理时延直方图指标。做不到精细化监控稳定性就永远只是嘴上说说。4.3 容灾与恢复演练关键故障的验证清单大模型推理服务比普通Web服务多一层GPU依赖恢复演练时不能只测“重启服务”还要验证“重启后模型加载是否成功”“缓存是否失效”“显存是否还残留上一个任务的脏数据”。我的容灾演练清单一般包含七项模拟算力节点掉线观察实例是否自动迁移到备用节点业务中断时间是多少。模拟模型服务进程OOM观察容器能否自动重启重启后首请求预热是否耗时很长。模拟网络抖动观察客户端是否有失败重试机制重试是否会造成重复扣费或重复生成。模拟突发流量观察扩容速度和队列丢弃策略是否合理。模拟上游API超时观察推理服务是快速失败还是无限等待拖垮线程池。模拟多个实例同时重启观察负载均衡是否会把流量全打到成单点。强制削减可用实例配额观察最小稳定实例数是否能满足在线任务。在火山引擎实操时我特别验证过“实例迁移”这个环节。因为大模型推理实例通常体积较大迁移不等同于重启Nginx。他们的方案里实例迁移会尽量保留模型权重的缓存状态让迁移后的冷启动时间缩短。这一点在实际演练中价值极高能在宿主机维护或故障时大幅降低业务受损范围。当然不同服务版本表现会有差异务必在生产环境模拟一次不要只在测试环境验证。4.4 成本与稳定性的平衡别为了省钱牺牲最关键指标推理成本是大模型落地中最容易被吐槽的部分GPU价格确实不便宜。但省钱有省钱的边界有些钱花得值有些“便宜”会反噬。我的经验是成本控制在稳定性的前提下进行否则省下的每一分钱都会在故障时间里加倍还回去。具体来说我建议做到三点。第一用弹性伸缩替代过度预留实例稳定的低谷期把实例数降到最低高峰期再扩起来能省30%到40%的成本。第二选择合适的云上资源规格如果你只是做在线对话没必要全用顶级训练卡推理场景下的中端卡配合理的内存和显存性价比可能更高。第三对离线批处理任务与在线推理任务做资源隔离离线任务可以用抢占式空闲能力在线推理必须保有一定独占资源。火山引擎的推理服务为什么适合做此类平衡核心在于它具备高弹性调配能力底层资源在共享和切换之间的损耗较小按需调度能力匹配业务波动时成本与稳定性能达成一个比较自然的平衡点。5. 几次实测之后我对“推理稳定性”重新排了一下优先级在写这篇之前我重新回看了过去一年处理的推理服务告警记录。占比最高的不是模型输出错误而是两类一类是实例异常导致请求超时另一类是扩容不及时导致高峰期排队长。这两类问题的共同点是它们都发生在推理引擎之外发生在调度与基础设施层面。这让我越来越确信业务落地时谈“大模型推理能力”必须把稳定性放在延迟和吞吐前面因为稳定性决定用户体感而延迟和吞吐决定成本和体验上限。如果你现在正准备做推理选型我的建议是先列一个分级表第一等级是稳定性指标包括错误率、P99延迟、恢复时长、容灾能力第二等级是性能和成本包括QPS、P50延迟、单请求成本第三等级才是模型效果包括你选用的模型本身的评测分。值得注意的是模型效果再出众如果前两级不达标上线后业务方只会认为“模型很烂”因为用户根本等不到模型发挥效果。这个逻辑我在好几次评审会上反复强调过希望看到这篇的同行能在自己的项目里也立起这套标准。最后再分享一个实操小技巧在做压测或验收时不要拿默认固定参数的偶发几次调用来证明稳定性。用随机间隔时间、随机提示词长度、混合上下文的请求来模拟真实流量至少持续跑30分钟。因为大模型推理服务对请求长度和上下文的预处理时间差异极大固定请求测不出长文本场景下的不稳定。测试数据里再悄悄加5%的超长请求量稳定性好坏立刻现形。这个方法我用过很多次比任何白皮书都管用。