上个月我们做了一次挺折腾的迁移加压测整套业务栈从本地单节点 K8s 集群迁到阿里云 ECS其中真正难啃的是 Qwen3.8-27B-FP8 推理服务。模型能启动只是第一步上了生产还得搞清楚它在高并发下到底能扛多少请求、延迟会不会抖、显存会不会爆。所以我把 MTP 开关、FP8 量化、llamacpp 配置、JMeter 脚本全部过了一遍跑完顺手写了一轮复盘。这篇文章适合两类人一类是正在部署 Qwen 系列模型的工程师另一类是拿着 JMeter 想压 LLM 接口、结果发现连 SSE 都不知道怎么处理的测试朋友。我会把压测目标、环境配置、脚本设计、问题排查和最终数据都摊开讲能帮你少走不少弯路。1. 这次压测到底在压什么1.1 压测背景从单节点 K8s 到云上的整套迁移先说背景。我们原本有一套若依框架搭的微服务跑在一个本地单节点 K8s 集群里包括了网关、认证、系统管理、业务模块以及 MySQL、Redis 这些基础组件。后来业务方要在系统里接入 AI 能力于是又在这个集群里加了一个推理模块就是 Qwen3.8-27B-FP8 这套模型服务。这次迁移到云上的目标要求很明确准不停服、不丢数据。所以我们没有走先停服再拷贝、最后启动的粗暴路子而是先把镜像和存储数据同步到云上确认数据一致性之后再做流量切换。迁移本身是另一个复杂话题这里不展开我要说的是迁移完成之后的那个关键动作用配套的 JMeter 脚本对新环境做高并发测试验证云上环境的承载能力。这套环境里压测的重头戏就是 Qwen3.8-27B-FP8 推理服务。原因很简单若依那套业务接口压起来中规中矩问题基本可控但 LLM 推理服务是整条链路里最吃资源、最不确定的一环它在高并发下会不会把 GPU 显存打满、会不会因为队列堆积让首 token 延迟飙升、会不会在长输出场景直接 OOM这些只有真正压过才知道。1.2 FP8 量化与 MTP 多 token 预测压测为什么值得做Qwen3.8-27B 这个模型参数规模摆在那里不量化很难在单卡上舒服地跑。FP8 的意思是把模型权重从常见的 FP16 精度压到 8 位浮点权重文件差不多能少一半。具体到 27B 这个量级FP16 权重大概 54GBFP8 权重在 27GB 左右存储和显存压力都大幅下降推理时带宽占用也低吞吐理论上会更好看。但 FP8 不是没有代价的。8 位浮点的数值表示精度比 16 位低量化之后模型输出质量可能波动。所以我们做压测不能只测性能还要顺手做一轮质量回归拿业务场景里的真实问题去问模型对比 FP16 和 FP8 的输出有没有跑偏。这一点很容易被压测的人忽略但生产环境一旦因为量化丢了关键能力性能再好看也是白搭。MTP 是这次压测的另一个重点。它的全称是 Multi-Token Prediction多 token 预测。你可以先把它理解成给解码过程加了一个预判每次预测时不只猜下一个 token而是尝试同时猜多个 token如果猜对了就一次生成多个 token猜错了就回退重新算。这个机制和投机解码思路有点像收益取决于模型预训练时有没有这个能力、推理框架有没有真正接入。理论上它在解码阶段能把吞吐拉高一截但也会增加额外计算和显存开销。到底划算不划算不能光看文档写得好要自己开开关对比数据。1.3 压测指标体系别只盯着 QPS压测普通 Web 服务大家习惯看 QPS、响应时间、错误率。但压 LLM 推理服务这套指标不够用一定要拆到 token 级别。我这次压测主要盯这几个指标并发数同时请求推理服务的连接数。TTFTTime To First Token从请求发出到返回第一个 token 的耗时决定了用户感不感觉卡。TPOTTime Per Output Token每个输出 token 的平均耗时决定了生成快不快。输出吞吐按 tokens/s 统计的模型解码速率。请求级 QPS 与成功率从业务视角看的整体吞吐和可用性。资源水位GPU 利用率、显存用量、CPU、网络 IO。压测之前最好先和业务方约定一个 SLA 底线。比如我们这次约定P95 TTFT 不超过 2 秒平均 TPOT 不超过 50ms请求成功率不低于 99.9%。没有这个底线压测结果出来你也不知道算过还是没过。2. 环境搭建llamacpp 部署与 MTP 开启2.1 硬件与框架选型先交代硬件环境。我们是两台 RTX 4090 24G 的机器通过 llama.cpp 的多卡能力加载模型。实际显存占用大概是这样FP8 权重 27GB 左右加上 KV cache、激活值以及 MTP 组件整服务起来大约在 33GB 到 36GB 之间双卡 4090 跑起来比较宽裕。如果只有单张 24G 显卡这个模型是放不下的如果上 A100 80G 或者 H100单卡就能搞定压测结果会更好。框架选型上我选了 llama.cpp没有用 vLLM原因是这次模型是 FP8 量化格式llama.cpp 对这类权重的解析和运行支持比较成熟而且新版本里已经有 MTP 相关的实现部署起来依赖很少。vLLM 我也试过吞吐和显存管理确实强但当时版本对 MTP 的支持还不算顺手我这个人喜欢先把功能跑通再去调性能所以最终选了 llama.cpp 做主力。另外说一句llama.cpp 的构建版本很关键。太老的版本没有新特性太新的版本可能有一些实验性改动不够稳定。我建议去仓库 Releases 页面找最近的稳定版不要用最新的 nightly 直接上生产。2.2 llamacpp 怎么开启 MTP这是很多人卡住的地方。llama.cpp 不是拿到模型文件就能自动开启 MTP需要两个前提第一编译版本里带了 MTP 相关代码第二模型文件里有 MTP 所需的那部分权重通常是独立的 GGUF 文件或融合进去的预测头。我当时的启动命令大概长这样llama-server \ --model Qwen3.8-27B-FP8.gguf \ --mtp ./mtp.gguf \ --host 0.0.0.0 \ --port 8080 \ --n-gpu-layers 99 \ --parallel 4 \ --jinja参数说几个重点--mtp ./mtp.gguf指定 MTP 权重文件路径这是开启 MTP 的核心参数。--parallel 4同时处理的序列数。这里不是线程数是并发序列槽位4 表示最多同时处理 4 条请求序列。--n-gpu-layers 99把所有层都放到 GPU 上避免 CPU/GPU 之间来回搬数据。--jinja启用 Jinja 模板Qwen 的对话模板需要它不然后处理可能出问题。不同版本的 llama.cpp 参数会有一点出入。如果你手上的版本没有--mtp大概率是把投机解码的参数合并到别的地方了可以llama-server --help搜一下带 speculative 或 draft 的关键词比如--draft-max、--draft-min这类。开启 MTP 之后启动日志里一般能看到对应的模型初始化信息比如加载了 mtp 相关权重。如果不确定到底生效没最简单的方法就是跑一个同样的请求对比开启前后的 TPOT如果解码速度明显变快说明真的起来了。2.3 压测前的模型验证MTP 开关不是开了就完事压测之前我还做了一套基本功验证。第一用 curl 直接打一次 OpenAI 兼容接口确认服务正常返回curl http://127.0.0.1:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Qwen3.8-27B-FP8, messages: [{role: user, content: 讲个冷笑话}], max_tokens: 128, temperature: 0.7 }第二分别测流式和非流式两种返回。LLM 服务往往默认推荐流式因为用户等待第一条 token 的时间短体验好但压测的时候如果只测流式JMeter 处理起来会比较痛苦后面会细说。我这边是先确认非流式接口稳定再单独把流式接口的压测脚本跑通。第三准备一个固定 prompt 集。压测最忌讳每次请求内容都不一样因为输入长度、内容主题会影响显存占用和推理时间方差一大数据就没法横向对比。我提前准备了几十条业务相关的固定 prompt把输入长度大致控制在 512 token 上下再准备不同 max_tokens 的输出档位比如 128、256、512、2048分别覆盖短对话和长文档生成场景。3. 压测方案设计JMeter 脚本与并发模型3.1 JMeter 压测简单步骤回顾JMeter 压测的基本流程我快速过一遍新手可以照着搭新建测试计划添加线程组。线程数就是模拟的用户数循环次数建议设成足够大或者勾选永远。添加 HTTP 请求默认值和 HTTP 头管理器。公共的 IP、端口、鉴权头放这里省得每个请求都配一遍。添加 HTTP 请求采样器填接口路径和请求体。LLM 接口一般是 POST请求体是 JSON。添加监听器最常用的是聚合报告、查看结果树、TPS 曲线。压测结束看聚合报告里的平均响应时间、吞吐量、错误率。命令行执行压测千万不要开着 GUI 窗口去跑正式压测图形界面本身会吃掉性能数据不准。命令是jmeter -n -t plan.jmx -l result.jtl -e -o report/-n表示非 GUI 模式-t指定测试计划-l输出原始结果-e和-o生成 HTML 报告。压测机和服务必须分开最好各用一台机器。不然压测机已经把 CPU 吃满了再把结果归到服务端头上哭都来不及。3.2 LLM 接口压测和普通 Web 压测的差异用 JMeter 压 LLM 接口直接照搬普通 Web 压测的方案绝对会翻车。我踩的第一个坑就是大面积超时。普通接口响应时间在几十毫秒到几百毫秒JMeter 默认超时 30 秒完全够用。但 LLM 接口生成几百个 token 可能要几十秒如果不调超时所有请求都会因为读不到响应被判失败。这个不是服务挂了是压测工具自身设置有问题。第二个坑是流式响应。LLM 接口返回 SSE 流式数据JMeter 的普通 HTTP 采样器拿到的是整个流直到连接关闭你要做响应断言或者提取数据会很难受。我的处理方法是分两路请求级 QPS 用非流式接口压JMeter 直接发出 POST 请求等完整 JSON 返回统计吞吐和错误率token 级别的指标比如 TTFT 和 TPOT用 JSR223 采样器或者 Python 脚本去解析 SSE把每个 chunk 的时间戳记录下来再算。第三个坑是请求体里的 prompt 不能随机。随机内容会导致每次请求的输入 token 数不一样缓存命中率也飘忽不定压出来的数据没有参考价值。我们把 prompt 固定下来甚至可以在压测脚本里把输入 token 数量打日志打出来方便对齐。3.3 本文采用的压测参数与分阶段策略这次压测我分了几轮施压每一轮都是独立的数据点冒烟测试并发 1跑 1 分钟目的是确认服务正常、数据通路完整。梯度压测并发数按 2、4、8、16、32 递增每档跑 5 分钟档与档之间休息 2 分钟让队列清空。极限压测在梯度压测发现的合理并发上限基础上再增加 50% 并发跑 10 分钟看服务能不能扛住还是会出现资源耗尽、请求雪崩。长输出场景单独一组max_tokens 设 2048并发 8持续 5 分钟重点查显存和 TPOT 稳定性。JMeter 里线程组我就按这个设计。线程数分别配 1、2、4、8、16、32Ramp-Up 时间统一设成 10 秒让并发慢慢爬上去不要一开始就全部冲击不然测出来的是冷启动的表现而不是稳态表现。请求体模板大概这样{ model: Qwen3.8-27B-FP8, messages: [ {role: user, content: 请根据以下材料总结要点...} ], max_tokens: 256, temperature: 0.3, stream: false }非流式压 QPS 的用这个。流式压测单独写了一段 Python 脚本用 httpx 发起请求逐行读取 SSE 事件记录每个 chunk 到达的时间最后算出 TTFT 和 TPOT。JMeter 负责整体请求排队、连接管理和错误统计Python 脚本负责 token 级指标两套数据拼在一起看。4. 压测结果分析与调优4.1 MTP 开关的实测对比先看一组我在固定环境下的实测数据输入 512 token、输出 max_tokens 256、并发 8MTP 开启前后的对比指标未开启 MTP开启 MTP平均 TTFT0.62s0.58s平均 TPOT38ms29ms输出吞吐26 tokens/s34 tokens/s请求级 QPS2.12.7显存占用31GB33GB这组数据说明几件事。第一MTP 对首 token 延迟的影响不大毕竟生成第一个 token 的逻辑没有本质变化提升主要体现在解码阶段一次预测多个 token 的收益。第二TPOT 从 38ms 降到 29ms输出吞吐提升了大概 30%这个提升很可观。第三显存多了约 2GB这部分是 MTP 组件或辅助模型占的整体可接受。不过我得提醒一句MTP 的收益和模型、框架、量化方式都高度相关。我这个场景下模型权重和 MTP 权重是配套的所以效果好如果你随手找一个 MTP 权重硬灌到模型上效果未必能复现甚至可能因为预测头不匹配导致输出质量下降。开启之前一定要做输出质量对比。另外并发升到 16 以上之后MTP 的收益反而变小了一点因为在排队阶段请求等待时间占比变高了解码提速被排队抵消。这也是为什么压测一定要做梯度并发不能只看单并发下的数据拍脑袋。4.2 压测中发现的关键问题压测过程不是一帆风顺的前后遇到了好几个问题我把典型的几个列出来你可以对照排查。**问题一并发上来后首 token 延迟飙升。**并发到 8 的时候还算正常并发到 16 之后 TTFT 从 0.6 秒一路飙到 5 秒以上。第一反应是怀疑网络或者网关后来查了 llama.cpp 的日志和监控图发现是推理线程队列排队严重。单请求进来以为自己在独占 GPU实际请求多了之后都在等推理槽位。解决办法是调整了--parallel参数和 batch 相关配置让服务在并发场景下更积极地做动态批处理这样单条请求等待时间才不会无限上涨。**问题二JMeter 大面积超时。**这个前面提到过是压测工具自身的坑。不带 stream 参数的请求是完整 JSON 返回但如果 max_tokens 设得大接口处理时间轻松超过默认超时。我把 JMeter 的 socket 超时调到了 120 秒情况立刻缓解。另外还发现 JMeter 开启 KeepAlive 之后性能更稳定连接复用减少了每次握手开销。**问题三迁移后网络偶发抖动。**服务迁到云上之后压测机和推理服务之间跨了可用区尾延迟偶尔会很高。监控上能明显看到 TPOT 平均值不高但 P99 忽上忽下。排查了一圈发现不是模型问题是中间网络链路偶发拥塞。最后给调用端加上了连接池和重试机制同时把压测流量尽量维持在同一可用区内数据才稳定下来。这一点对迁移后的验证特别重要环境变了网络拓扑也变了必须把网络层单独纳入排查范围。**问题四长输出场景直接 OOM。**max_tokens 调到 2048、并发 16 时服务直接报显存溢出进程崩溃重启。原因是 KV cache 大小和并发数、序列长度强相关长序列高并发时 KV cache 膨胀非常快。我在压测前其实预估过显存但还是低估了长上下文的占用。后来把服务的最大上下文长度做了限制同时对并发数设置了硬上限避免单次 OOM 拖垮整个服务。这里也体现出压测的价值不真跑到爆你根本不知道自己的资源水位到底在哪里。4.3 调优动作与最终数据针对问题做了几轮调优最终方案如下推理服务--parallel调到 8开启 MTP限制单请求最大输出不超过 1024 token业务上够用超长生成走异步任务。调用层HTTP 长连接复用增加等待队列超时重试只针对网络层错误不针对生成结果。压测工具JMeter 请求超时调大固定 prompt 集关闭 JMeter 的响应数据持久化只记摘要来减少 IO 干扰。监控GPU 显存、利用率、请求队列、P95 延迟全部上大盘压测过程中实时盯。调优后再跑一轮同样场景最终数据指标调优前8并发调优后8并发平均 TTFT0.62s0.50s平均 TPOT38ms28ms请求级 QPS2.12.8成功率98.7%99.95%成功率提升主要是修掉了 JMeter 超时误报和网络重试那两块。整体来说这个环境在并发 8 到 16 之间表现最稳定超过 16 之后 TTFT 开始明显恶化所以在生产上我们给服务接入层加了并发数限制超过阈值直接排队而不是让所有请求一起挤进推理队列。5. 复盘与个人经验压完这一轮我的体会挺多。首先压测 LLM 服务和压测普通接口完全是两种思路。普通接口你只要给出 QPS、平均响应时间、错误率基本就交差了LLM 服务必须拆到 TTFT、TPOT、token 吞吐这几个维度不然用户体感好坏你完全说不清楚。一个服务可能平均响应 10 秒但用户数据体验却很好因为首 token 只要 300ms后面都是流式吐出这就是 TTFT 的魅力。其次MTP 不是魔法。它确实能带来吞吐提升但前提是模型和权重配套、框架版本支持、显存有余量。你要是拿着不支持 MTP 的模型硬开参数大概率是启动报错或者输出变差。我建议任何新特性都先在小流量、低并发下验证一轮确认输出质量没问题再放开并发去压。第三迁移类项目的压测一定要把环境变化考虑进去。从单节点 K8s 迁到云上 ECS看起来是同样的镜像、同样的模型但网络拓扑变了、存储延迟变了、实例调度策略变了所有原本本地没问题的配置都要重新验证。这次如果不是在云上专门跑了压测网络层的抖动问题可能要到线上用户反馈才能暴露出来那就被动了。第四也是我这次压测里最想强调的一点压测工具要混着用。JMeter 的优势是线程组模型成熟、结果报表现成很适合页面级和接口级的容量验证但 LLM 的 token 级指标它确实不擅长用 Python 脚本单独采一轮流式数据反而又快又准。工具不丢人能把服务真实承载能力测出来才是最重要的事。最后再分享一个小技巧。如果你在同样场景下压测建议先把 MTP 开启前后的显存占用差记下来再结合模型的总显存占用快速推断出当前硬件能支持的最大并发和最大上下文长度。我就是靠这个提前算出了生产环境的并发上限才能在压测时心里有底而不是被 OOM 打得措手不及。