做大语言模型的可扩展性评估很多人第一反应是拿压测工具打一轮看吞吐量多少、延迟多少然后写个报告就完事。真等你做完几轮你会发现“可扩展性”这三个字远不是“加机器性能翻倍”那么简单背后牵扯着显存分配、KV Cache、调度策略、批量推理方式、通信带宽等一系列问题。我最近在一套多卡推理环境上做了一次完整的可扩展性评估从指标设计到负载模型再到压测实录中间踩了不少坑也总结了一些能直接抄作业的方法。这篇就当给同行的一份实践笔记适合正在做大模型服务选型、容量规划、性能调优的同学参考。1. 可扩展性评估到底在评什么1.1 先分清“性能”和“可扩展性”很多项目把性能测试和可扩展性评估混为一谈这是第一个要纠正的认知。性能测的是“给定资源下系统能做到多好”比如单卡情况下每秒能吐多少tokenP99延迟是多少。可扩展性测的是“资源增加后能力能不能跟着长”比如从1张卡扩到2张、4张、8张吞吐和并发承载能力是线性往上走还是涨到一定程度就平了、甚至回落。大语言模型推理服务为什么特别容易出现扩展性不佳的情况核心原因有三个显存墙、通信墙、调度墙。显存墙在于模型参数和KV Cache都会吃显存卡多了缓存可以分散但每张卡能放多少又受模型并行策略限制通信墙在于多卡之间要做张量并行、流水线并行每轮推理都要同步通信开销会随着卡数增长而放大调度墙在于推理引擎的调度策略未必能充分利用多卡算力连续批处理continuous batching的窗口设计不合理就会出现算力空转。我自己习惯用一个直观指标判断扩展性扩展效率。假设单实例的吞吐是T1n个实例的理想吞吐是T1×n实际总吞吐是Tn那么扩展效率就是Tn÷(T1×n)。如果4实例扩展效率低于60%基本可以认为扩展方案有瓶颈要么是架构选型问题要么是资源争抢问题而不是简单地继续加机器就能解决。这个指标在后面的实操部分会反复用到。1.2 按场景拆解评估目标可扩展性评估不是一个统一模板先要搞清楚你的服务跑什么场景因为场景直接决定评估指标和压测方式。在线交互场景比如聊天助手、客服机器人优先级是延迟典型指标是TTFT首Token延迟和TPOT每个输出Token的生成时间同时对尾延迟敏感P99不能高得太离谱。这种场景下评估可扩展性重点看的是并发用户数从100涨到1000系统能不能保持SLO达标率在99%以上。资源扩展的目标是让每个用户的等待时间不随总负载线性恶化。离线批量场景比如批量文档总结、代码分析、离线知识库处理优先级是吞吐。请求可以排队单个请求慢一点没关系关键是单位时间内处理完多少请求、每卡每天能产出多少Token。这种场景下评估可扩展性重点看的是从1台机器扩到10台总吞吐是不是近似线性增长单请求的平均处理时间有没有因为资源变多反而变差。还有一种混合场景线上交互和离线任务共用一套推理集群这种最麻烦。离线长请求会占住显存和算力导致在线请求的TTFT剧烈抖动。评估这种场景的可扩展性就不能只看平均吞吐还得看资源隔离能力——把在线和离线任务混部时在线服务质量会不会被离线任务拉垮。如果你遇到的是这种场景压测设计必须把混合负载考虑进去否则测出来的数据在真实生产中根本不适用。1.3 常见的三个评估误区第一个误区是只测低并发。我见过不少评估报告并发只测到8、16看起来吞吐线性上涨就得出“扩展性很好”的结论。实际上很多推理服务在低并发时表现都不差因为显存带宽和算力都没到瓶颈。真正考验扩展性的是高并发下的资源竞争比如并发128、256甚至更高时KV Cache是否够用、预填充和解码阶段争不争算力。压测设计一定要把并发推到超出预期的峰值水位。第二个误区是固定输入输出长度。用固定长度请求压测数据很干净但和真实业务差距巨大。真实场景里有的请求输入50个token有的输入5000个token输出也是长短不一。混合长度请求会直接影响显存复用策略和批处理效率固定长度测出来的扩展效率会偏高。所以我在负载模型里一定会加入长度分布这个后面详细说。第三个误区是忽略预热和冷启动。模型权重加载、CUDA Kernel初始化、显存预留都有一次性开销特别是首次请求经常会慢得离谱。如果没有预热直接开测会把正常状态的指标拉偏甚至怀疑系统有严重问题。评估开始前一定要先跑一段热身流量让推理引擎的显存分配、调度器、KV Cache池都进入稳定状态再记数据。2. 指标口径与负载模型先定尺子再测数据2.1 核心指标选型与计算口径大模型推理评估的指标比较多但不是每个都要测。我习惯根据评估目标选用一组核心指标表格里列的是我这次计算使用的口径大家可以直接参考。指标计算口径用途TTFT从请求发起到返回首个Token的时间包含排队和预填充判断接入体验在线场景关键TPOT从首个Token到完整序列结束实际解码期间每个Token的平均生成时间判断生成速度决定打字感E2E Latency从请求发起到完整返回的总时长综合体验离线场景更关注Total Throughput单位时间内系统输出的Token总数包含预填充和解码的全部Token判断系统产能SLO达标率满足给定延迟目标的请求占比如P95延迟≤2秒判断服务质量是否稳定扩展效率实际吞吐增量÷理想吞吐增量判断扩展是否收益正常关于TPOT要提醒一句不同框架里的口径不完全一样。有些框架把TPOT直接输出为解码阶段每个token的平均耗时有些则需要你自己算即E2E - TTFT除以输出Token数。不同口径之间差一个首token的预填充时间在短输出场景下差距很大。做评估报告时务必写清楚口径否则不同团队之间对不上数后面做容量规划就会基于错误数据。分位数的重要性我反复强调过只看平均值非常危险。一组请求P50延迟1.0秒P99延迟8秒均值可能只有1.3秒看起来挺好但真实用户遇到8秒延迟时早就流失了。所以我的压测报告里至少包含P50、P90、P95、P99四档分位数评估SLO时也优先用P95或P99做判定线。2.2 请求负载怎么设计负载模型决定评估结果能不能代表生产情况。我这次用了一个比较简单但有效的方案请求的输入长度按业务历史分布抽样输出长度也按业务分布抽样到达模式分两种——固定并发模式和泊松到达模式。固定并发模式适合测系统容量上限。比如固定200个并发请求每个请求结束立即发下一个让系统始终处于满负载状态测出的是系统在给定并发下的极限能力。泊松到达模式适合模拟真实用户请求的自然到达节奏平均每秒到达多少个请求峰谷波动更接近生产环境。我做容量评估时两种都会测固定并发看极限泊松到达看稳定性。具体到请求本身还需要控制两个东西输入长度和输出长度。输入长度影响预填充的算力消耗输出长度影响解码阶段的持续时间和显存占用。如果业务里输入长度是几十到几百token压测却全用2048token的输入预填充耗时会被严重放大TPOT数据也会被带偏。反过来如果业务需要长输出压测却只跑短输出KV Cache的压力就完全没测出来。正确做法是统计线上或模拟数据中的长度分布按比例生成压测请求。这里没有线上数据的话可以按经验设定一个偏真实的分布比如输入20%短文本、60%中文本、20%长文本并在报告里注明假设条件。2.3 算清楚扩展效率这笔账有了单实例基准就可以设计扩展性对比了。我的做法是先跑单实例满负载拿到吞吐T1和时延基线然后扩展到2实例、4实例、8实例分别跑同样的负载模型记录总吞吐Tn和时延曲线。最后画一条“理想线性扩展线”和实际数据曲线一眼就能看出扩展性是否健康。这里有个容易忽略的细节扩展性分为“增加推理实例”和“增加单实例内部卡数”两条路径。增加实例是水平扩展通过负载均衡分发流量理论上通信开销小扩展效率通常较高。增加单实例卡数是垂直扩展引入张量并行和流水线并行通信开销明显增幅变大但单实例处理能力会变强。两者的扩展效率曲线完全不同必须分开评估。我曾经测过一个方案水平扩展做到8实例效率还在85%以上但单实例内部从1卡扩到4卡效率只有60%原因就是张量并行每增加一张卡每层Transformer都要做一次全量通信同步计算量分配和通信比例不匹配。扩展效率的绝对值没有统一标准要看你对业务的期待。一般来说吞吐扩展效率70%以上算可以接受90%以上算优秀低于60%就要警惕。当然如果时延SLO达标才是关键指标吞吐效率低一些但延迟收益明显那结论可能也成立。关键是把所有维度的数据摆到一起算明白成本收益而不是看到一个数字就下结论。3. 实操过程一次完整压测是怎么跑下来的3.1 部署与监控准备说完了理论进入真正做压测的部分。我这次评估的环境是4卡GPU推理机用某开源大模型部署服务推理框架开启连续批处理和显存自动预留。第一步不是压测而是把基础参数定好。常用参数里最核心的是最大并发序列数max_num_seqs和KV Cache显存上限。连续批处理引擎会动态调整批大小但批太大时单请求等待时间变长批太小时算力利用率不足。我最初用默认配置跑发现并发64时TPOT直接飙高后来把KV Cache预留调大、最大序列数调小时延曲线才正常。这些参数没有绝对最优要结合模型大小和业务长度分布来调。监控方面建议至少盯四类数据GPU利用率、显存占用、请求排队长度、正在解码的序列数。压测开始前我会用监控工具记录一个基线压测中实时观察压测结束后把时间序列和压测结果对齐。这里给一个很实用的建议每一轮压测开始前重启一次推理服务确保上一轮的显存碎片和缓存状态不污染下一轮数据。对比多轮结果时千万要保证除被测变量外其他条件一致否则数据无法横向比较。3.2 压测步骤全流程我这次的可扩展性评估完整流程如下准备3组长度分布不同的压测请求集分别模拟短文本、中等文本、长文本业务每组包含相同比例的输入输出长度组合。对单实例启动服务做一次短时间预热请求等显存分配稳定、首轮请求完成。依次用16、32、64、128、256并发跑固定并发模式每轮持续5分钟收集TTFT、TPOT、吞吐和显存数据。改用泊松到达模式以平均每秒20、40、80、160个请求的速度跑一轮持续10分钟观察时延分布和丢请求情况。扩展到2实例重复步骤2到4。再用4实例重复记录所有数据。汇总数据计算扩展效率绘制吞吐和时延随并发、实例数的变化曲线。根据瓶颈现象做一两次反向验证实验比如降低并发观察TPOT是否回落或者关闭连续批处理对比差异。压测得到的原始数据量很大建议直接在整理时只保留关键指标。下面是我这次评估中间一轮的部分结果示例展示不同并发下单实例的表现方便说明怎么看数据并发数总吞吐 (token/s)TTFT P95 (ms)TPOT P95 (ms/Token)GPU利用率显存占用163204203876%58%324605904282%63%645108105588%72%12848012507390%86%25643020009591%95%这里可以看出一个典型现象并发从16涨到64时吞吐持续上涨但TTFT和TPOT也在涨说明系统在逼近算力和KV Cache瓶颈。并发超过128后吞吐不升反降TTFT大幅恶化说明请求排队严重系统过载了。这时加并发没有意义扩展评估要记录的是“最大有效并发”也就是还能维持正常服务质量的并发水位而不是无限压到系统崩溃为止。扩展到更多实例后随着总并发路由到不同实例整体吞吐应该上升。我实测4实例的扩展效率大约78%没有达到理想的2倍、4倍增长后来定位发现是负载均衡层的连接数分布不均匀导致某台实例先饱和。这个案例说明扩展性好不好不光是推理引擎的事整个服务链路上的每一个中间层都会影响最终结果。3.3 从评估结果反推瓶颈数据测完不是终点更重要的是解读数据、定位瓶颈。我总结了三类最常见的表现和解法。第一类并发升高TPOT同步恶化但GPU利用率已经很高。这说明系统已经跑到算力或显存带宽上限。这时扩展通常要减小批大小、限制并发数或者升级到带宽更高的硬件如果业务允许量化模型也能明显改善瓶颈。第二类并发升高吞吐停滞但GPU利用率不到50%。这种情况典型说明调度或排队有问题。比如max_num_seqs设得过小请求都卡在队列里GPU没有数据可算比如CPU预处理和GPU推理没有重叠数据搬运成了瓶颈。排查时先看排队序列数是多少如果队列长期有积压优先检查调度参数。第三类扩展实例后总吞吐增加不明显甚至单实例吞吐下降。大概率是负载均衡或通信链路问题。我遇到过某次扩展4实例总吞吐只有单实例的2.6倍排查发现负载均衡策略对长连接不友好大量请求被hash到同一台机器上。后来改成连续请求轮询分发扩展效率才回到85%以上。做瓶颈定位时有个重要原则一次只变一个变量。很多人压测不达标随手同时改并发数、改模型量化、改调度参数结果指标变好了都不知道是哪一步起的作用。我在压测时会把每一项改动单独跑一轮记录完整数据再对比宁可多花时间不能糊里糊涂调参。4. 常见问题与排查技巧实录4.1 并发上不去的三个典型原因压测最常见的问题是“并发一拉高就报错”或者“请求大量超时”。我遇到的大多数情况根因不出以下三个。一是显存OOM或者接近满。KV Cache是按序列数线性增长的每个序列都有独享的缓存空间并发数越高KV Cache占用越大。当显存接近满的时候推理框架会拒绝新请求或者频繁驱逐旧项目来腾空间结果就是请求失败率飙升。排查方法是看监控里的显存曲线如果显存在高并发时接近100%先调低max_num_seqs或者缩小每序列KV Cache的预留上限。二是调度器频繁抢占。连续批处理框架通常有一种策略当新请求到达且批已满时把正在生成的请求暂停腾位置给新请求做预填充这个机制叫抢占或交换。抢占发生时被暂停的请求延迟会显著增加。并发高、新请求持续到达时抢占可能成为常态导致整体延迟变得极不可控。排查方式是在日志里看preemption计数如果抢占频率很高说明并发配置超过了系统舒适区应该降低并发或者换用支持优先级队列的策略。三是CPU侧成为瓶颈。请求预处理、Tokenization、采样、调度决策都消耗CPU。GPU很贵CPU通常配得不多高并发时CPU先跑满GPU反而在等数据。排查方法是看压测机和服务端的CPU利用率如果服务端CPU利用率长期接近100%需要升级CPU型号、增加实例数分担CPU负载或者优化前处理的并行线程数。这三条排查顺序建议先看显存、再看抢占、最后看CPU因为显存和抢占问题的定位成本最低CPU问题往往要折腾配置和架构放到最后更稳妥。4.2 时延抖动和长尾问题另一类高频问题是压测平均时延看着正常但P99忽高忽低甚至某些请求出现数十秒延迟。这类长尾问题在线场景下尤为致命。我遇到的典型原因有三个。第一是长请求阻塞短请求。连续批处理虽然能把不同请求放在同一个batch里但输出长度特别长的请求会占据解码槽位很长时间后续短请求就得排队。缓解办法是在调度器层面做长度感知或者为短请求单独预留槽位。第二是抢占造成的恢复时间被抢占的请求需要重新载入KV Cache这个操作很慢会让这部分请求变成明显的尾部离群点。第三是监控和日志本身造成干扰比如大量访问日志同步写盘磁盘IO瞬时饱和也会让时延突然升高。我处理长尾问题的一个经验是先把请求长度分成短、中、长三类分别统计时延。如果只有长请求有长尾那是调度和显存问题如果短请求也有长尾多半是抢占或系统层面干扰。分桶统计比全量混在一起算P99更能定位问题。4.3 统计口径造成的坑最后这一类坑不在系统在数据统计本身。同样一组压测数据用不同统计口径能得出完全相反的结论。第一个坑是延迟从哪开始算。有的工具TTFT从请求创建时开始计时包含了连接建立和排队时间有的只从请求进入服务端开始计时丢掉了网络和排队。评估SLO时必须统一口径我建议从客户端发起角度统计端到端TTFT这样更贴近用户感受但也要同时记录服务端视角的数据方便排查两者之差。第二个坑是时间窗口设置。压测刚开始的前30秒系统在填充显存和适应负载数据通常偏慢压测结束前的最后几秒调度器可能在排空队列数据又偏快。如果只用整个4小时压测数据的平均值这些边缘效应都会被混进去。我会把每轮压测的前30秒和后30秒数据剔除只用中间稳定段做分析。第三个坑是失败请求要不要纳入统计。如果压测时发生过载部分请求超时或报错这些失败请求是不该计入平均时延的因为它们没有完整走完流程。但如果不单独记录失败率只看成功请求的数据报告会显得过于乐观。正确做法是报告里同时给出请求成功率和时延分布失败率过高时整体结论要打折扣。我这次做评估有个很深的体会做可扩展性评估比数据更重要的是一致性。改动环境参数一定要记录清楚每次只改一个变量统计口径写明白这样数据之间才是可比的。压测不是炫技也不是走流程而是从资源使用、延迟曲线、吞吐效率里读出一个系统能承担到什么水位。把这个流程跑熟了后续无论是做容量规划、成本预估还是判断架构要不要调整都会轻松很多。