KV 的线性

术语先把这些指标定义清楚

下面这些缩写在正文里反复出现,它们不是同义词: 每个指标量的是流水线上不同的一段,彼此之间有确定的换算关系。 本轮负载:输入 256 → 4096 · 输出 256 · 固定并发 16。本报告固定并发、只改输入长度,所以"输出吞吐"和"总吞吐"朝相反方向走,下表这两行要分清。

  t=0   客户端发出请求
        │
        │  [1] 排队 queue_time —— 在 waiting 队列里等调度器放行
        │  [2] prefill —— 把 L 个输入 token 一次算完,写进 KV Cache
        │  [3] 前端 + IPC —— 分词、HTTP、API server 与引擎之间的通信
        │
  ━━━━━ [1]+[2]+[3]       = TTFT 首字延迟 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
        │
        │      第 1 个输出 token 送达
        │
        │  [4] ITL × 255 —— 相邻两个输出 token 之间的间隔
        │     这 255 个间隔的平均值 = TPOT
        │
  ━━━━━ [1]+[2]+[3]+[4]   = E2EL 端到端时延 ━━━━━━━━━━━━━━━━━━━━━━━━━

  # 恒等式:E2EL = TTFT + 255 × TPOT
  # 吞吐 = 所有请求的输出 token 总数 ÷ 整段测试的墙钟时间(不是 1/TPOT)

结论线性得几乎没有误差

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

线性斜率就是并发数

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

56 KiB/token 由模型结构决定

KV 池的总大小来自服务端日志;每 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: 6.41 GiB
GPU KV cache size:         120,064 tokens

# 对账
6.41 GiB ÷ 56 KiB = 120,025 token   (日志 120,064,差 0.03%,来自 6.41 的四舍五入)

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

# 这条公式的实用价值:不用跑测试就能算容量红线
单请求占满 8,192 上下文 = 8192 × 56 KiB = 448 MiB
池子 6.41 GiB ÷ 448 MiB  = 14.65 条

# 启动日志自己也算了一遍,是同一个数
Maximum concurrency for 8,192 tokens per request: 14.66x
                          ← 差 0.07%,同样来自 6.41 的四舍五入

波形502 秒全程实况

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

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

这是本轮最想回答的问题。TTFT 拆成三段:排队(request_queue_time)、 prefill(request_prefill_time)、剩下的前端开销(分词 + HTTP + 第 1 个 token 送达)。 同轮 C=1 的单流测量作为参照,它是"纯计算"的下限。

同一段 prefill,并发下的墙钟是单流的 3.9 倍

最干净的一组对照是同样 1024 个 token 的 prefill:同轮 C=1 时服务端量到 93.5 ms, 本节 C=16 时量到 360.5 ms。同一段计算、同一张卡,墙钟是 C=1 的 3.9 倍。 多出的 267 ms 不是排队(排队只有 47 ms)。原因是开了 enable_chunked_prefill: 这段 prefill 被切成块,混进 16 条正在 decode 的批次,一块一块地算完。 第一轮这个倍数是 3.9,这一轮还是 3.9。

中位数涨到 3.5 倍,尾部涨到 15 倍

上面的分解图画的是平均值。换成分位数看,长度轴上同样是尾部先恶化, 原因也和并发轴一样:排队。

# L 从 256 拉到 4096(16 倍)
TTFT p50     297.5 →  1047.4 ms       3.5×
TTFT p99     390.3 →  6027.1 ms      15.4×   ← 尾部涨得远比中位数快

# 拆开看是哪一段在涨
排队           1.5 →   318.5 ms      212×
prefill      229.4 →   804.4 ms       3.5×   ← 和 p50 同速,它不是尾部的原因

长 prefill 之间会互相阻塞:一条 4096 token 的请求在做 prefill 时, 后面排队的请求要等它走完一批 chunk 才轮得到。所以排队时间涨到 212 倍,prefill 本身只涨到 3.5 倍。 这和上一段"TTFT 是调度指标"是同一件事的两种量法。

--max-num-batched-tokens 是什么

它是 vLLM 调度器的单步 token 预算:每次 forward(一个 engine step)里, 一批最多能放多少 token。上文反复出现的"抢步""混批"都由这个数控制。

# 一个 engine step 的 batch 是拼出来的
  decode token    每条正在生成的请求各贡献 1 个
+ prefill chunk   新请求的 prompt 被切块,塞进来 一块
  ─────────────────────────────────────────────
= iteration_tokens   ≤  --max-num-batched-tokens

# 采样脚本里那一列量的正是这个和。本轮 C=16 各长度点的实测:
  L=256   每步 30.3 个 token   其中 decode 16、prefill ≈ 14
  L=1024  每步 76.5 个 token   其中 decode 16、prefill ≈ 60
  L=4096  每步 265.1 个 token  其中 decode 15、prefill ≈ 250

# 注意这是【平均】。真正决定 ITL 尾部的是【单步峰值】,见下。

它是 ITL 的旋钮,因为它决定了一个正在 decode 的请求,每一步要陪别人算多少 prefill。

• 调大 → prefill 块更大 → 一个 prompt 用更少的 step 算完 → TTFT 变好;但每个 step 变长,decode 被拖慢 → ITL p99 变差。
• 调小 → 反过来:ITL 尖峰变矮,TTFT 变差。

这就是本节结论指向的交换。显存这条路在上一节已经排除 (L=4096 稳态 KV 只有 52%–58%),能调的只剩这个预算。

反推:本轮的预算很可能是 2048

这个值没有写进服务端日志(日志只给了 max_num_seqs 128 和 max_model_len 8192),但可以从 ITL 尾部反推。 思路:一次 ITL 尖峰,就是那一步顺带算了一大块 prefill, 多出来的时间除以 prefill 的实测算力,就是那一块有多大。

# 反推公式
块大小(token) = (ITL p99 − ITL p50) × 146.3 TF/s ÷ 13.05 GFLOP/token
                 ↑ 尖峰比常态多花的时间        ↑ prefill 段实测   ↑ 2N/token

相关的几个参数,以及一个能证伪的实验

  20.26 ms  +  512 × 13.05 GFLOP ÷ 146.3 TF/s
= 20.26 ms  +  45.7 ms
= 约 66 ms          同时 TTFT 会变差,因为 4096 个 token 要切成 8 块而不是 2 块

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

同一张 4090,在纯 decode 的一秒和正在 prefill 的一秒,算力相差一个数量级。 数据来自 --enable-mfu-metrics:打开后 /metrics 多出 estimated_flops_per_gpu_total 与 estimated_read_bytes_per_gpu_total 两个累积计数器,采样脚本每秒抓一次。名字里的 estimated 名副其实: 它是 vLLM 按模型结构和当步调度的 token 数推算的,不是 GPU 性能计数器, 因此不含 kernel launch、padding 这类实际损耗。

# 采样脚本抓到的每秒瞬时 TF/s(L=4096 开场 11 秒)
t+0   Running=1  Waiting=2   28.3 TF/s   ← 刚起步
t+1   Running=4  Waiting=12  146.4 TF/s  ← 纯 prefill,贴着峰值跑
t+2   Running=6  Waiting=10  144.7 TF/s
t+3   Running=9  Waiting=7   146.3 TF/s
t+4   Running=11 Waiting=5   144.7 TF/s
t+5   Running=14 Waiting=2   146.2 TF/s
t+6   Running=16 Waiting=0   144.6 TF/s
t+7   Running=16 Waiting=0   43.9 TF/s   ← 最后一块 prefill 收尾
t+8   Running=16 Waiting=0   12.6 TF/s   ← 纯 decode,掉到 1/12
t+9   Running=16 Waiting=0   12.3 TF/s
t+10  Running=16 Waiting=0   12.6 TF/s

这两个比值是什么

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

MFU 这个叫法来自 Google 的 PaLM 论文。论文区分 MFU(只算模型本身必需的 FLOPs) 与 HFU(含重计算等硬件实际执行的 FLOPs)。本节全部用 MFU 口径。

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

# vLLM 内部怎么估的(拿本轮五个零抢占的点反推,能对上)
FLOPs/token   ≈ 13.05 GFLOP                  2N,N = 7.07e9,即总参数减掉 embedding
              + 0.000401 GFLOP × 上下文长度   注意力项 = 4 × d_model(3584) × 层数(28)

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

# 第二条可以当场验证(L=256)
55.8 迭代/s × (14.14 + 0.35) GB = 809 GB/s    实测 827.7 GB/s   差 −2.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.55 ÷ 165.2 = 14.3%     MBU = 827.7 ÷ 1008 = 82.1%
L=4096:  MFU = 87.64 ÷ 165.2 = 53.1%     MBU = 439.2 ÷ 1008 = 43.6%

反向走的原因:算术强度

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

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

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

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

把 prompt 拉长,没有让任何一个 kernel 变得更"算力密集": decode 步的强度反而从 14.8 降到 11.9(KV 读得更多)。 变的只是算力密集的 prefill 在时间轴上的占比,于是平均强度被抬过了脊点。

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

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

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

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

# 实测线性拟合(5 个点,R² = 0.99989)
ITL_p50(L) = 16.23 ms + 0.00098 ms/token · L

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

# 吻合度
0.00091 ÷ 0.00098 = 93%  ← KV 读取跑到了显存带宽峰值的 93%(第一轮 92%)

把斜率换成绝对值:每个长度点的 decode 地板

上面验证的是斜率(每多一个 token 多花多少时间)。同一个模型也能给出绝对值: 一步 decode 至少要把权重完整读一遍,再把批内所有请求的 KV 读一遍。 这些字节除以峰值带宽,就是这一步的时间下限。

# 地板 = (权重 + running均值 × 上下文 × 56 KiB) / 1008 GB/s
# 权重取 14.14 GB —— 总参数减掉 embedding,查表不流过 HBM

    L    上下文   running均   地板 ms   实测 ITL p50   达成率
  256      384     15.39      14.37       16.47       87.2%
  512      640     14.60      14.56       16.76       86.9%
 1024     1152     15.28      15.03       17.23       87.2%
 2048     2176     15.03      15.89       18.23       87.2%
 4096     4224     14.85      17.60       20.26       86.9%

# 16 倍长度跨度里,达成率只在 0.4 个百分点内浮动

代价吞吐的分叉

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

但每个输入 token 的成本一路下降

输出吞吐跌了 60%,不代表处理输入变贵了。prefill 耗时除以输入长度, 得到的单位成本一路走低,方向和输出吞吐相反。

# prefill 墙钟 ÷ 输入长度
  L=256    229.4 ms ÷  256 = 0.896 ms / 输入 token
  L=512    281.7 ms ÷  512 = 0.550
  L=1024   360.5 ms ÷ 1024 = 0.352
  L=2048   547.1 ms ÷ 2048 = 0.267
  L=4096   804.4 ms ÷ 4096 = 0.196   ← 比 L=256 便宜 4.6 倍

原因是上一节的 roofline:prefill 是算力密集的,一次前向把 14.14 GB 权重读一遍, 可以摊给 4096 个 token,而不是 256 个。 所以把多个短请求拼成一个长请求,往往比分开发更划算。

对照同样的 KV 占用,输出吞吐差 3.9 倍

并发轴(L=1024,C 从 1 到 64)和长度轴(C=16,L 从 256 到 4096)放在同一张图上。 横轴统一成 KV 池占用,也就是"这次请求占用了多少显存预算"。

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

换个横轴,两条轴就重合了

上图说明"KV 占用预测不了产出"。但只要把横轴换成一次迭代里参与计算的 token 总数 (即 --max-num-batched-tokens 那一节量的 iteration_tokens), 两条轴的利用率曲线就会叠在一起。

数据完整测量结果

这批数据能不能信:四条自检

• 零失败、零抢占:800 条请求全部成功,KV 峰值只到 57.8%。 这一轮测的是纯粹的长度效应,没有混入抢占(抢占是 Test 4 的内容)。
• 每请求输出 token 精确等于 256,五档全部如此,说明 --ignore-eos 生效。 各档输出侧工作量完全一致,差异只能来自输入。
• 只变了一个变量:服务端全程没重启,并发固定 16、输出固定 256、每档 160 条请求, 只有 --random-input-len 在变。
• 每档换了 seed(seed = 输入长度),档间没有重复的 prompt; vLLM 侧全程 enable_prefix_caching: False,五个点之间没有缓存命中。

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

• L=512 这一点要重测(采样漏了峰顶,见 Figure 1 注)。 拟合斜率 0.045% 的偏差基本都来自它。把采样提到 5 Hz,或把每个长度点跑得更久。
• 补一个 L=8192 的点。本轮 L=4096 时 KV 才 57.8%, 而 MFU/MBU 的交叉点算出来在 L≈3,157,交叉点右边只有一个测量点,外推依据不足。 L=8192 需要 16×8448 = 135,168 tok,正好超过 KV 池, 还能第一次观察到抢占。
• 把"抢步"这一项单独量出来。本轮的 267 ms 是用 C=1 基线相减得到的差值, 不是直接测量。调低 --max-num-batched-tokens 重跑, 看它是否随块大小线性缩小,才能确认因果。
• read_bytes 的残差值得追。二项模型系统性低估 2%–7%, 且随 L 单调增大。如果确认是 prefill 激活读写,可以加第三项 激活 ≈ α × prefill_tokens 拟合出 α,把这笔账完全对平。