KV 的线性

结论线性得几乎没有误差

KV 占用随输入长度的增长,五个点全部落在一条直线上,R² = 0.999998。 斜率实测 15.91 —— 理论值是 16.00(并发数),偏差 0.6%。 这条直线的每一个系数都能从模型结构算出来,没有留下任何需要解释的余量。

线性斜率就是并发数

下面这张图里有两条线:粗虚线是 16 × (L + 256) ÷ 86,864 算出来的理论值, 细实线是服务端 vllm:gpu_cache_usage_perc 的实测峰值。 它们在五个点上几乎完全重叠 —— 这正是 PagedAttention 的设计承诺: KV 占用只由 token 数决定,和批次形状、请求到达顺序都无关。

56 KiB/token 是从模型结构里长出来的

池子的绝对大小来自服务端日志,每 token 的占用则完全由 Qwen2.5-7B 的注意力结构决定 —— 28 层、4 个 KV head(GQA,不是 28 个 Q head)、head_dim 128、bfloat16。

# 单 token 的 KV 字节数
2 (K,V) × 28 层 × 4 KV head × 128 dim × 2 B = 57,344 B = 56.0 KiB

# 服务端日志
Available KV cache memory: 4.64 GiB
GPU KV cache size:         86,864 tokens

# 对账
4.64 GiB ÷ 56 KiB = 86,880 token   (日志 86,864,差 0.02%,来自 4.64 的四舍五入)

# GQA 省了多少:如果是 MHA(28 个 KV head)
56 KiB × 7 = 392 KiB/token  →  池子只剩 12,409 token  →  C=16 时 L 最多 519

波形410 秒全程实况

五段测试连在一起看,KV 曲线是五级台阶,每一级都比上一级高得更多 —— 因为横轴的长度是翻倍的。 台阶顶部的锯齿是请求批次的换手:所有请求长度相同且 --ignore-eos, 它们几乎同时结束,腾出的槽位要等下一批 prefill 完才重新填满。

排队首字延迟里,只有两成在算

这是本轮最想回答的问题。把 TTFT 拆成三段:排队(request_queue_time)、 prefill(request_prefill_time)、以及剩下的前端开销(分词 + HTTP + 首 token 送达)。 再把第二轮 C=1 的单流测量放进来作参照 —— 那才是"纯计算"的下限。

同一段 prefill,并发下贵了 3.9 倍

最干净的一组对照:同样是 1024 个 token 的 prefill,第二轮 C=1 时服务端量到 92.2 ms, 本轮 C=16 时量到 358.8 ms。同一段计算、同一张卡,慢了 3.9 倍。 多出来的 267 ms 不是排队(排队只有 47 ms),而是 enable_chunked_prefill=True 下, 这段 prefill 被切成块、混进 16 条正在解码的批次里,一块一块挤着算完的。

物理一张卡,两种完全不同的机器

--enable-mfu-metrics 打开后,/metrics 会多出 estimated_flops_per_gpu_total 与 estimated_read_bytes_per_gpu_total 两个累积计数器,采样脚本每秒抓一次。名字里的 estimated 是实打实的 —— 它是 vLLM 按模型结构和当步调度到的 token 数推出来的,不是 GPU 性能计数器, 因此不含 kernel launch、padding 这类实际损耗。 把这两条按秒画出来,会看到一个很干脆的现象:同一张 4090, 在"纯解码"的那一秒和"正在 prefill"的那一秒,算力相差 一个数量级。

# 采样脚本抓到的每秒瞬时 TF/s(L=4096 开场 10 秒)
t+0  Running=0  Waiting=0   86.6 TF/s   ← 上一轮收尾
t+1  Running=2  Waiting=14  146.3 TF/s  ← 纯 prefill,贴着峰值跑
t+2  Running=5  Waiting=11  144.8 TF/s
t+3  Running=7  Waiting=9   146.4 TF/s
t+4  Running=10 Waiting=6   144.8 TF/s
t+5  Running=12 Waiting=4   146.3 TF/s
t+6  Running=15 Waiting=1   122.4 TF/s
t+7  Running=16 Waiting=0   12.3 TF/s   ← 纯 decode,掉到 1/12
t+8  Running=16 Waiting=0   12.4 TF/s
t+9  Running=16 Waiting=0   12.4 TF/s

这两个比值到底是什么

一张 GPU 干活时有两堵墙:每秒能算多少次乘加,和每秒能从显存搬多少字节。 任何 kernel 都会先撞上其中一堵。MFU 与 MBU 就是分别量"离这两堵墙还有多远"的比值 —— 单看一个没什么用,放一起看才知道该往哪儿优化:MBU 高就去压显存流量 (量化权重、加大 batch、缩 KV),MFU 高就去换更好的 kernel 或更低的精度。

MFU 这个叫法来自 Google 的 PaLM 论文,它特意区分了 MFU(只算模型本身必需的 FLOPs) 与 HFU(算硬件真正执行的,含重计算等),两者可以差不少。本节全部是 MFU 口径。

# 分子 —— 采样脚本每秒抓的两个单调累积量,分析时做窗口首尾差分 ÷ 窗口时长
estimated_flops_per_gpu_total       →  CSV 的 flops 列
estimated_read_bytes_per_gpu_total  →  CSV 的 read_bytes 列

# vLLM 内部怎么估的(拿本轮五个零抢占的点反推,能对上)
FLOPs/token   ≈ 13.5 GFLOP                   2N,N ≈ 6.75e9,约等于非嵌入参数量
              + 0.000401 GFLOP × 上下文长度   注意力项 = 4 × d_model(3584) × 层数(28)

每次迭代读字节 ≈ 14.3 GB                     全部权重,与 batch 无关
              + 16 × L × 56 KiB             批内所有请求的 KV

# 第二条可以当场验证(L=256)
56.3 迭代/s × (14.3 + 0.34) GB = 824 GB/s    实测 822.5 GB/s   差 0.2%

# 分母 —— 两个规格数
165.2 TF/s   RTX 4090 BF16 张量核心「稠密」峰值
             2:4 稀疏是 330.3 —— 用它会让 MFU 直接腰斩,写报告必须注明取的是哪一个
1,008 GB/s   显存带宽 = 384-bit × 21 Gbps GDDR6X

# 代进去
L=256 :  MFU = 23.5 ÷ 165.2 = 14.2%     MBU = 822.5 ÷ 1008 = 81.6%
L=4096:  MFU = 87.9 ÷ 165.2 = 53.2%     MBU = 436.9 ÷ 1008 = 43.3%

反向走的原因:算术强度

真正在动的量是算术强度(arithmetic intensity)—— 每从显存搬一个字节,能顺带算多少次浮点。 它低于脊点就是带宽受限,高于就是算力受限。 4090 的脊点 = 165.2 TF/s ÷ 1,008 GB/s = 163.9 FLOP/byte。

# 这不是巧合,是一个恒等式
MFU ÷ MBU = (FLOPs ÷ bytes) ÷ (峰值算力 ÷ 峰值带宽) = 算术强度 ÷ 脊点

# 所以「两条线交叉」和「算术强度穿过脊点」是同一件事

# 但分相来看,负载从来没有停在脊点上:
单个 decode 步    216 GFLOP ÷ 14.5 GB  = 12 ~ 15 FLOP/byte      远低于 163.9,深度带宽受限
一段 prefill      L × 13.5 GFLOP ÷ 14.3 GB
                  L=256   → 242 FLOP/byte
                  L=4096  → 3,867 FLOP/byte                远高于 163.9,深度算力受限

换句话说:把 prompt 拉长,没有让任何一个 kernel 变得更"算力密集" —— decode 步的强度甚至还从 14.9 掉到了 12.0(KV 读得更多)。 变的只是算力密集的 prefill 在时间轴上占了更大比例,于是平均强度被抬过了脊点。

带宽每一步都要把整个模型重读一遍

显存读字节这条计数器可以完整对上账。每个 decode step 要读两样东西: 全部权重(约 14.3 GB,与 batch 无关),以及批内所有请求的 KV(= 16 × L × 56 KiB,随 L 线性增长)。 把这两项按实测迭代率乘出来,和 read_bytes 的实测速率对照:

ITL 的斜率,是 56 KiB/token 的第二次独立验证

第一次验证靠的是容量(KV 占用计数器)。第二次完全不看计数器,只看时间: 单步 decode 的中位耗时随上下文线性增长,而这个斜率应该恰好等于 "多读的 KV 字节 ÷ 显存带宽"。

# 实测线性拟合(5 个点,R² = 0.99998)
ITL_p50(L) = 16.36 ms + 0.00099 ms/token · L

# 理论:每步多读的 KV = 16 条 × 1 token × 56 KiB
16 × 57,344 B ÷ 1,008 GB/s = 0.00091 ms/token

# 吻合度
0.00091 ÷ 0.00099 = 92%  ← KV 读取跑到了显存带宽峰值的 92%

代价吞吐的分叉

长度这个轴上有一个容易踩的坑:总 token 吞吐一路上涨,看起来机器越用越好; 但用户真正拿到的输出 token 吞吐一路下跌。两条线朝相反方向走。

对照同样的 KV 占用,产出差 3.9 倍

把三轮测试放在同一张图上:前两轮沿并发轴走(L=1024,C 从 1 到 64), 本轮沿长度轴走(C=16,L 从 256 到 4096)。横轴统一成 KV 池占用 —— 也就是"这次请求吃掉了多少显存预算"。

三轮测试在 L=1024 / C=16 上的吻合度

数据完整测量结果

调度与批次形状

下一步这轮暴露出来的四个口子

• 补一条 C=1 的长度扫描。本轮的"纯计算基线"只有 L=1024 一个实测锚点, 其余四点是按 FLOPs 外推的。把 --max-concurrency 1 同样扫一遍 256→4096, Figure 3 的绿色虚线就能从推算变成实测,"排队占比"这个数字才算真正落地。
• 调 --max-num-batched-tokens,量它对 TTFT / ITL 的分配。 本轮 L=4096 的 p99 TTFT(6.0 s)几乎全部来自开场 6 秒的入场排队,而 p90 ITL(190 ms) 全部来自 prefill 抢步 —— 这两个数字被同一个旋钮控制,方向相反。 建议在 L=4096 固定的前提下扫 1024 / 2048 / 4096 / 8192,画出这条兑换曲线。
• 把 KV 池调满,重测 L=4096。服务端日志给了建议值 --kv-cache-memory=6567016960(6.12 GiB),池子能从 86,864 扩到约 114,600 token。 L=4096 下的并发上限会从 20 提到 26,KV 占用从 79.8% 降到 60%, 可以验证"稳态里那 14 次 Waiting=1 到底是不是显存造成的"(本轮判断是调度器预算,不是显存)。
• 打开 prefix caching 再扫一遍。本轮 --enable-prefix-caching=False, 每条请求的 prompt 都是全新随机 token,prefill 一分钱都省不掉。 真实业务的长 prompt 往往共享大段前缀 —— 开启后 KV 占用曲线的斜率应该明显低于 16, 那个"低多少"就是前缀复用率的直接测量。