推理服务的压测方法：从基准工具到容量验证

推理压测的特殊性：为什么 wrk 不够用

传统压测工具（wrk/ab/JMeter）在 LLM 推理上失效，原因有三。原因一：请求的形态不同——LLM 请求是「长连接的流式响应」（SSE 数秒到数分钟的持续输出——wrk 的「请求-响应」模型不适配）、输入输出的长度影响巨大（100 token 与 10000 token 的请求是两种负载）。原因二：指标的不同——要测的是 TTFT/TPOT/吞吐（tokens/s）而非 RPS——「每秒请求数」对推理服务的意义远小于「每秒 token 数」。原因三：资源的行为不同——GPU 的负载与「批处理的构成」强相关（batch 内长短不一的请求互相影响）——压测必须模拟真实的长度分布才有意义。推理压测需要专门的方法与工具。

压测的场景设计：模拟真实分布的三个要素

压测的核心是「流量画像的保真」——三要素。要素一：输入输出的长度分布。从真实流量统计（或合理假设）：输入长度 P50/P95/P99（如 500/2000/8000 token）、输出长度的分布（如 100/400/2000）——压测请求按此分布采样（全用固定长度的请求 = 测了个寂寞——长度分布直接决定 KV 与 prefill 的负载形态，本库弹性伸缩篇）。要素二：请求的构成比例。流式 vs 非流式的比例、多轮对话 vs 单轮（多轮的 prefix 缓存行为不同）、不同场景的混合（问答/生成/分类的混合比例）。要素三：并发模型。用户的到达模式（恒定并发、泊松到达、突发尖峰——真实流量是波动的）、思考时间（用户读完回复再发下一条——多轮对话的节奏）。压测场景的工程化：把「长度分布 + 构成比例 + 并发模型」写成压测的配置文件（可复现、可对比）——压测的黄金规则：每次压测的配置与结果都要存档，压测是可回归的工程活动。

工具的选择：从 vLLM benchmark 到自研

工具的梯队。第一梯队：推理引擎自带的 benchmark（vLLM 的 benchmark_serving、SGLang 的 bench——与引擎的指标体系深度对齐，TTFT/TPOT/吞吐的一手测量）。第二梯队：通用 LLM 压测工具（k6 的 LLM 扩展、llmperf 类——支持流式与 token 计量）。第三梯队：自研压测器——当你的流量形态特殊时自研（真实流量的回放、特定的会话模型——流量回放是最真实的压测：把生产流量的形状录下来重放，本库影子评测的思路）。压测的指标采集：服务端指标（引擎的批处理状态、GPU 利用率、KV 占用、队列深度）与客户端指标（TTFT/TPOT/吞吐的分位数）两侧都要采——单侧的指标会撒谎（客户端感知慢但服务端 GPU 空闲 = 网络或排队问题）。

瓶颈定位：压测数据的解读与优化方向

压测的价值在瓶颈定位——数据的解读方法。解读一：区分瓶颈类型。GPU 算力瓶颈（GPU 利用率 95%+、吞吐不再随并发上升——加卡或优化 batch）、KV 显存瓶颈（KV 占满、请求排队——本库 KV Cache 篇）、调度瓶颈（队列深但 GPU 空——调度参数或 prefill 阻塞）、网络与前端瓶颈（服务端快客户端慢——本库流式篇）。解读二：找「拐点」。压测的并发爬坡曲线有一个拐点（并发增加吞吐先升后降——拐点就是最优工作点，生产运行应留在拐点左侧留余量，本库 SLA 篇的利用率纪律）。解读三：对照「理论容量」。实测容量与理论公式（本库显存账单篇）的差距——差距大 = 有可优化的空间（批策略、KV 管理、调度参数）。优化方向的映射：瓶颈在 prefill → 前缀缓存与 prompt 瘦身（本库 Prefix Caching 篇）、瓶颈在 decode → 批处理的效率与投机解码（本库投机解码篇）、瓶颈在 KV → 量化与淘汰策略。压测报告的正确打开方式：报告不是「最高 TPS」的炫耀，是「容量边界 + 瓶颈定位 + 优化路线」的工程文档——每一次压测都要回答：这台服务的拐点在哪、瓶颈是什么、下一步优化什么。

压测的进阶实战：长稳测试与故障注入

推理压测（正文方法论）的进阶：长稳测试与故障注入——除了容量拐点，还有两类更接近生产的压测。长稳测试（soak test）。定义：中等负载下连续跑 24–72 小时（不是压力的最大化，是时间的最大化——暴露「跑久了才出现」的问题）。暴露的典型问题：内存泄漏（KV 或框架的缓慢泄漏——几小时后 OOM）、碎片的累积（显存碎片化导致的分配失败——本库显存篇的碎片）、日志与临时文件的膨胀（磁盘满）、以及降级的累积（连接池耗尽、句柄泄漏）。长稳的通过标准：无 OOM、无重启、性能无明显漂移（漂移的检测：首小时与末小时的指标对比）。故障注入（chaos）。注入的场景：GPU 掉卡（运行中的卡故障——副本的自愈验证，本库 GPU 故障篇）、网络抖动（RDMA 的延迟与丢包注入）、依赖的故障（模型仓库不可达、上游服务超时）、以及节点的消失（K8s 节点被抢占——本库弹性伸缩篇）。注入的验证目标：自愈是否生效（副本的拉起、请求的迁移）、降级是否触发（限流与降级的正确进入）、恢复的时间（MTTR 的实测——本库 GPU 故障篇）。进阶压测的收束：容量压测回答「能扛多少」，长稳测试回答「能扛多久」，故障注入回答「坏了会怎样」——三类压测合起来，才是推理服务的完整体检；只有容量压测的压测，是一半的压测。

压测的常见误区：五个「压了个寂寞」的反模式

推理压测（正文）的反模式盘点：五个「压了个寂寞」的经典误区。误区一：固定长度的均匀请求。所有请求 1000 in/1000 out——真实流量是分布（长度分布决定 KV 与 prefill 的负载——均匀压测的结果无法外推到生产）。误区二：只压 RPS 不控并发。RPS 打很高但并发只有 5——推理的容量是并发敏感的（batch 的构成与队列才是负载的真相）。误区三：压测环境与生产不一致。不同的模型量化（生产 INT4 压测 FP16）、不同的引擎版本、不同的硬件——压测结果不可迁移。误区四：只看均值不看分位数。平均 TTFT 300ms 很好——P99 5 秒被均值掩盖（本库 SLA 篇的分位数纪律）。误区五：压一次就完事。不做存档、不做回归——压测是一次性活动而非工程流程（本库正文的存档纪律）。五个误区的共同根源：把压测当成「跑个工具看看」的验证活动，而不是「模拟真实并回答问题」的工程方法——压测的每一次运行，都应该回答一个明确的工程问题；回答不了问题的压测，是烧 token 的仪式。

压测的进阶场景：多模型服务的混合压测

推理压测（正文方法论）的进阶场景：多模型服务的混合压测——网关后面多模型的压测方法。场景：LLM 网关后面挂三个模型（旗舰/中档/轻量），流量按路由策略分配。混合压测的挑战。流量的路由在压测中也要模拟（真实流量会按路由分配到三个模型——每个模型的负载比例与总流量的分布要一致）、每个模型的容量不同（旗舰的容量小、轻量的容量大——整体容量是三个模型容量的加权）、以及降级的影响（旗舰过载时降级到轻量——降级路径的压测：降级后的服务质量验证）。混合压测的设计。压测的流量模型：按路由策略的流量分配（与生产路由一致的比例——不要均匀分配）、每个模型的独立压测（先单独测各模型的容量基线）→ 混合压测（模拟真实路由下的整体行为）→ 降级场景的压测（旗舰过载触发降级——验证降级的体验与容量）。混合压测的收束：多模型架构的压测，比单模型复杂一个维度——每个模型的容量、路由的比例、降级的路径都要分别验证；网关层的压测，不是「压网关本身」，是「压整个路由体系在真实流量下的表现」。

压测的进阶工具：流量回放的实现

推理压测（正文工具）的进阶：流量回放的实现——最真实的压测是重放生产流量。流量回放的原理：录制生产流量的形状（请求的时间序列、输入输出的长度分布、请求的类型分布）→ 在压测环境中按原始时序重放——重放的是流量的「形状」而非「内容」（内容可以脱敏替换、形状必须保真）。回放的工程：流量的录制（生产网关的请求日志——结构化的时序记录）、重放的调度（按原始时间间隔重放——并发模型与到达模式与生产一致）、结果的对比（重放的指标 vs 生产的历史指标——偏差大 = 影响因素变了）。回放的适用边界：生产流量有隐私（脱敏后重放——内容的脱敏不能破坏流量的形状）、以及重放的成本（回放的 token 成本与生产相当——回放是最贵也最真实的压测）。流量回放的收束：流量回放是压测的终极形态——它模拟的「不是你想象的流量，而是你真实的流量」——当基准工具的模拟与真实分布差距太大时，流量回放是唯一的选项。实施建议：录制生产流量的形状（不含内容），用形状驱动的压测替代参数化的压测——形状保真的压测，结果才有生产参考价值。

小结

推理压测的方法论：模拟真实分布的三要素（长度分布、构成比例、并发模型）是保真的核心；工具的梯队从引擎自带 benchmark 到流量回放的自研；瓶颈定位区分四类（算力/KV/调度/网络）并找拐点。压测的黄金规则：配置与结果存档可回归、两侧指标同时采、报告回答「拐点、瓶颈、下一步」——压测不是性能的炫耀，是容量规划的地基与优化的地图。