1. 一次“翻车”的 FP8 KV Cache 实测复盘先说结论我原本以为 FP8 KV Cache 是个“白捡”的显存优化实测下来预测只对了一半——显存确实降了但吞吐和延迟的表现跟预期完全不是一回事而且在这个过程中我还顺手揪出了自己压测方法里的一个大坑。这篇就把整个实测过程、踩过的坑、以及最后怎么把压测做扎实的完整复盘一遍。如果你正在用 vLLM 部署 Qwen3 系列模型或者正在纠结 FP8 和 INT8 到底差在哪、KV Cache 量化值不值得开那这篇应该能帮你省下不少试错时间。我会从 KV Cache 到底是什么讲起再到 FP8 量化的原理、vLLM 里的开启方式、压测脚本怎么写、指标怎么看最后重点讲那个把我坑惨的压测方法问题。全程都是我自己跑出来的数据不是抄文档。需要提前说明的是我用的环境是 vLLM 的 OpenAI 兼容镜像模型是 Qwen3 系列压测工具用的是 k6 和 JMeter 两套对照。为什么用两套因为第一套跑出来的数据太“漂亮”了漂亮到我怀疑人生后来换了一套才发现问题。这个后面细说。2. KV Cache 与 FP8 量化先把地基打牢2.1 KV Cache 到底缓存了什么为什么它这么吃显存大模型推理分两个阶段Prefill预填充和Decode解码。Prefill 阶段把整段 prompt 一次性喂进去算出每个 token 的 Key 和 Value 向量Decode 阶段每生成一个新 token都要拿当前 token 的 Query 去和前面所有 token 的 Key 做注意力计算再对 Value 加权求和。问题就出在这Decode 阶段每生成一个 token都要用到历史所有 token 的 K 和 V。如果每次都重算那计算量会爆炸。所以工程上会把已经算好的 K、V 缓存下来这就是KV Cache。它的显存占用公式大致是这样的KV Cache 显存 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 批大小 × 数据类型字节数注意最前面那个 2是因为 K 和 V 各存一份。以 Qwen3-14B 这类模型为例层数、头数、头维度都是固定的序列长度和批大小是运行时变量唯一能“动手脚”的就是最后的数据类型字节数。FP16 下每个数值占 2 字节FP8 下占 1 字节。理论上KV Cache 显存直接砍半。这就是 FP8 KV Cache 最诱人的地方——同样的显存能塞下更长的上下文或者更大的并发批。2.2 FP8 和 INT8 的区别别搞混了很多人把 FP8 和 INT8 当成一回事其实差别不小。我一开始也犯过这个迷糊后来查了资料加上实测才理清。INT8是定点量化8 个 bit 全部用来表示整数部分范围通常是 -128 到 127。它需要一个额外的scale 因子来做反量化把整数映射回浮点。优点是硬件支持广、实现成熟缺点是动态范围窄遇到离群值outlier容易精度崩。FP8是浮点量化8 个 bit 拆成符号位、指数位、尾数位。常见的两种格式格式符号位指数位尾数位动态范围精度E4M3143较小较高E5M2152较大较低E4M3 精度高但范围小E5M2 范围大但精度低。推理里 KV Cache 一般用E4M3因为注意力的 K、V 数值分布相对集中不需要太大的动态范围反而更吃精度。FP8 相比 INT8 的核心优势是动态范围更接近浮点对离群值更友好反量化开销更小。代价是需要硬件原生支持比如较新的 GPU 架构否则会走软件模拟性能反而更差。提示如果你的 GPU 不支持原生 FP8开 FP8 KV Cache 可能不但不加速还会因为模拟转换拖慢推理。开之前先确认硬件。2.3 vLLM 里 KV Cache 量化的开启方式vLLM 对 KV Cache 量化的支持是通过--kv-cache-dtype参数控制的。常见取值auto跟随模型权重的数据类型fp8KV Cache 用 FP8 存储fp8_e4m3/fp8_e5m2指定具体的 FP8 格式启动命令大概长这样vllm serve Qwen/Qwen3-14B \ --kv-cache-dtype fp8 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 64这里有几个参数需要配合调整。--max-model-len决定最大上下文长度--gpu-memory-utilization决定显存占用上限--max-num-seqs决定最大并发序列数。开了 FP8 KV Cache 之后同样的显存预算下这三个值理论上都能往上提。但注意vLLM 的调度逻辑scheduler会根据剩余显存动态决定能塞多少序列。如果显存算错了调度器可能会频繁触发抢占preemption导致请求被反复换入换出延迟飙升。这也是我后面压测时踩到的坑之一。3. 实测环境搭建与压测方案设计3.1 环境与模型选型我这次用的环境如下项目配置推理框架vLLMOpenAI 兼容镜像模型Qwen3-14BKV Cache 类型FP16基线 vs FP8实验组最大上下文32768并发序列数32 / 64 两档压测工具k6、JMeter选 Qwen3-14B 是因为它在单卡上能跑起来同时又有一定的规模KV Cache 的显存占比足够明显能看出 FP8 的效果。如果模型太小KV Cache 占比低量化收益会被淹没在噪声里。镜像方面我用的是 vLLM 的 OpenAI 兼容服务镜像。这里有个常见疑问vLLM 的 Docker 镜像里带模型吗答案是不带。镜像只包含推理框架本身模型需要你另外挂载或者从模型仓库拉取。我一般会把模型权重提前下载到本地目录然后通过 volume 挂载进去这样启动快也不依赖网络。3.2 压测指标怎么定别只看吞吐很多人压测大模型只看一个指标吞吐tokens/s。这其实很片面。我这次重点关注四个指标TTFTTime To First Token首 token 延迟反映 Prefill 性能TPOTTime Per Output Token每个输出 token 的耗时反映 Decode 性能吞吐Throughput单位时间生成的 token 数显存占用GPU Memory峰值显存和稳态显存为什么 TTFT 和 TPOT 要分开看因为 FP8 KV Cache 主要影响的是 Decode 阶段的显存带宽压力对 Prefill 的影响相对小。如果只看总吞吐很容易把两个阶段的差异混在一起得出错误结论。另外还要看P50 / P95 / P99 延迟不能只看平均值。平均值会被大量快请求拉低掩盖掉长尾问题。我这次就是被平均值骗了一次。3.3 压测脚本设计请求长度分布很关键压测脚本的设计直接决定数据有没有意义。我见过太多人压测时所有请求都用同一个固定长度比如全是 512 token 输入、256 token 输出。这种压测结果在真实场景里几乎没有参考价值因为真实请求的长度是长尾分布的。我这次设计了三种请求模式短请求输入 128 token输出 64 token中请求输入 1024 token输出 256 token长请求输入 8192 token输出 512 token然后按 6:3:1 的比例混合发送。这样既能压到 Prefill 的极限也能压到 Decode 的长序列场景。k6 的脚本大概是这样import http from k6/http; import { check } from k6; export const options { scenarios: { mixed_load: { executor: constant-arrival-rate, rate: 10, timeUnit: 1s, duration: 5m, preAllocatedVUs: 50, maxVUs: 200, }, }, }; const prompts [ { text: 短请求内容..., max_tokens: 64 }, { text: 中请求内容..., max_tokens: 256 }, { text: 长请求内容..., max_tokens: 512 }, ]; export default function () { const p prompts[Math.floor(Math.random() * prompts.length)]; const payload JSON.stringify({ model: Qwen3-14B, prompt: p.text, max_tokens: p.max_tokens, temperature: 0, }); const res http.post(http://localhost:8000/v1/completions, payload, { headers: { Content-Type: application/json }, }); check(res, { status is 200: (r) r.status 200 }); }注意temperature: 0这是为了让输出确定化减少随机性对压测结果的干扰。如果温度设高每次生成的 token 数不一样吞吐数据会抖得厉害。4. 实测数据与预期偏差分析4.1 显存预测对了一半先看显存。这是 FP8 KV Cache 最直接的收益点。配置峰值显存稳态显存可支持最大并发FP16 KV Cache68.2 GB64.5 GB32FP8 KV Cache52.7 GB49.8 GB64显存确实降了峰值从 68.2 GB 降到 52.7 GB降幅约 22.7%。但注意没有降到理论上的 50%。为什么因为 KV Cache 只是显存占用的一部分模型权重、激活值、框架开销都占显存。KV Cache 本身降了一半但它在总显存里的占比可能只有 40% 左右所以总显存降幅就被稀释了。这印证了我开头说的“预测只对了一半”——理论上的减半是 KV Cache 自身的减半不是总显存的减半。不过好消息是可支持的最大并发从 32 提到了 64翻了一倍。这意味着在同样的显存预算下能同时服务两倍的请求。对于高并发场景这个收益是实打实的。4.2 吞吐不升反降的意外接下来是让我最意外的地方。我原本预期 FP8 KV Cache 会提升吞吐因为显存带宽压力小了。但实测结果配置吞吐tokens/sTTFT P50TPOT P50FP16 KV Cache1842320ms28msFP8 KV Cache1697298ms34ms吞吐不升反降从 1842 降到 1697降了约 7.9%。TTFT 略微改善320ms → 298ms但 TPOT 变差了28ms → 34ms。这个结果一开始让我很困惑。后来分析下来原因有几个第一反量化开销。FP8 存储的 KV 在参与注意力计算前需要反量化回 FP16。这个转换虽然单次开销小但在 Decode 阶段每个 token 都要做累积起来就不可忽略了。第二显存带宽不是唯一瓶颈。在 Qwen3-14B 这个规模下Decode 阶段的瓶颈可能更多在计算而非带宽。FP8 省了带宽但增加了计算净效果就不好说了。第三并发上去了调度开销也上去了。并发从 32 提到 64vLLM 的调度器要管理更多序列抢占和换入换出的概率增加这部分开销吃掉了部分收益。提示FP8 KV Cache 不是“无脑开就快”。它的收益高度依赖模型规模、硬件架构、并发水平。小模型或低并发下可能得不偿失。4.3 长上下文场景这里才是 FP8 的主场虽然整体吞吐降了但在长上下文场景下FP8 KV Cache 的优势就体现出来了。我单独跑了一组 8192 输入、512 输出的长请求配置长请求吞吐长请求 TPOT P95是否 OOMFP16 KV Cache14289ms并发 16 时 OOMFP8 KV Cache16871ms并发 32 仍稳定长请求下FP8 吞吐反而高了 18.3%TPOT P95 也更好。原因是长序列下 KV Cache 占比大幅上升显存带宽成为主要瓶颈FP8 的带宽优势终于压过了反量化开销。而且 FP16 在并发 16 时就 OOM 了FP8 撑到 32 还稳。这说明FP8 KV Cache 的真正价值在于“能跑更长的上下文和更高的并发”而不是“让短请求更快”。5. 压测方法的坑我是怎么被自己骗的5.1 第一版压测数据漂亮得可疑我第一版压测用的是 JMeter配置了 50 个线程循环 100 次结果跑出来 FP8 的吞吐比 FP16 高了 30% 多。当时我差点就信了准备写“FP8 大幅提升吞吐”的结论。但有个细节让我起疑JMeter 报告的响应时间分布非常集中几乎没有长尾。这跟真实场景完全不符。真实的大模型推理长尾延迟是必然存在的因为请求长度、生成长度、调度抢占都会造成波动。5.2 问题定位JMeter 的默认行为在骗我排查后发现两个问题问题一JMeter 默认复用连接且没有正确处理流式响应。大模型推理如果开流式输出响应是分块返回的。JMeter 如果按普通 HTTP 响应处理会把“收到第一个块”当成响应完成导致 TTFT 被严重低估而 TPOT 根本没被测量到。问题二线程模型和真实并发不匹配。JMeter 的线程是“一个线程发一个请求等响应回来再发下一个”。这种模型下实际并发数远低于线程数因为大部分线程都在等响应。而真实场景是持续有请求打进来并发是实时的。这两个问题叠加导致 JMeter 测出来的“高吞吐”其实是假象——它测的是“低并发下的快速响应”而不是“高并发下的真实吞吐”。5.3 修正方案用 k6 的 constant-arrival-rate换成 k6 之后我用constant-arrival-rate执行器它按固定速率发送请求不管上一个请求有没有回来。这才是真实的“到达率”模型。同时我在脚本里显式处理流式响应记录首 token 时间和最后一个 token 时间分别算 TTFT 和 TPOT。修正后的数据就是我前面表格里那组——FP8 吞吐反而略降。这才是真实情况。提示压测大模型推理千万别用“固定线程数 循环”的模型。要用“固定到达率”模型并且必须处理流式响应否则 TTFT 和 TPOT 全是错的。5.4 压测方法对照表压测方式并发模型流式处理TTFT 准确性TPOT 准确性适用场景JMeter 默认线程阻塞不支持低无法测简单接口JMeter 调优线程池需自定义中中一般接口k6 constant-arrival-rate到达率支持高高大模型推理自研脚本可控支持高高精细测试6. 常见问题与排查技巧实录6.1 FP8 KV Cache 开了没效果甚至变慢这是最常见的问题。排查顺序确认硬件支持原生 FP8。如果不支持vLLM 会走软件模拟性能必然下降。确认模型规模。小模型 KV Cache 占比低FP8 收益被稀释。确认并发水平。低并发下显存带宽不是瓶颈FP8 反量化开销反而拖后腿。确认--max-model-len和--max-num-seqs有没有同步调大。如果显存省下来了但没用来提并发或提上下文那收益就浪费了。6.2 vLLM 启动报显存不足开了 FP8 之后如果还 OOM检查这几个参数--gpu-memory-utilization默认 0.9可以适当调低到 0.85 留余量--max-model-len如果设得太大即使 KV Cache 量化了也可能不够--max-num-seqs并发数设太高调度器会预留大量显存我一般会先用小max-num-seqs启动确认能跑起来再逐步往上加观察显存曲线。6.3 压测数据波动大复现性差数据波动大通常有三个原因温度没设 0。生成 token 数随机吞吐自然抖。请求长度没固定分布。每次随机到的长度不一样结果不可比。没有预热。模型第一次推理会有编译、缓存加载等开销前几十个请求的数据要丢弃。我的做法是压测前先跑 50 个预热请求然后正式开始正式数据取中间稳定段的平均值。6.4 常见问题速查表现象可能原因排查方向FP8 吞吐反降反量化开销 带宽收益看 TPOT 是否变差显存没降多少KV Cache 占比低算 KV Cache 占总显存比例长请求 OOM并发或上下文设太高降 max-num-seqs 或 max-model-len压测数据太漂亮压测模型不对换 constant-arrival-rateTTFT 异常低流式响应没处理检查是否把首块当完成7. 我个人的实操体会跑完这一轮我最大的体会是FP8 KV Cache 不是一个“开了就赚”的开关而是一个需要根据场景权衡的取舍。如果你的场景是长上下文、高并发那 FP8 值得开它能让你在同样的显存下服务更多请求、支持更长序列。但如果你的场景是短请求、低并发那 FP8 可能反而拖慢推理不如老老实实用 FP16。另外压测这件事本身比调参更需要认真对待。我这次要不是多留了个心眼差点就用错误的数据得出错误结论。压测工具的选择、并发模型的设计、流式响应的处理每一个环节都可能让你的数据失真。先保证测量准确再谈优化效果这个顺序不能反。最后分享一个小技巧压测时把 vLLM 的日志级别调到 debug能看到调度器的抢占次数和 KV Cache 的换入换出情况。如果抢占次数很高说明并发设得太激进这时候即使吞吐数字好看实际服务质量也是不稳定的。这个指标比单纯的吞吐更能反映系统的真实健康度。