交叉点

结论量化省的是字节,省不了调度

Q4_K_M 把每步要读的权重从 15.23 GB 压到 4.68 GB —— 3.25 倍。 单流解码是纯访存,这 3.25 倍几乎原样兑现成 2.70 倍的速度(差的那点是解量化的算力开销,后面对得上账)。 但把并发拉到 32 之后,vLLM 的解码步长只涨了 26%,llama.cpp 涨了 3.6 倍 —— 权重读取被摊薄这件事,llama.cpp 基本没吃到。

交叉两条吞吐曲线在 C≈20 换位

第一轮已经把 vLLM 的并发曲线从 1 扫到 64,这一轮在 1 / 8 / 32 三个点上叠了 llama.cpp。 两条线不是平移关系,是斜率不同 —— llama.cpp 起点高、爬得慢,vLLM 起点低、爬得快。

延迟三行的"倍数"按 vLLM ÷ llama 计算,所以小于 1 表示 llama.cpp 更慢。 注意 ITL p99 在 C=8 时 llama.cpp 反而好 3.2 倍,到 C=32 就倒过来差 2 倍 —— 这条线索留到第 4 节。

字节账单流那 2.70 倍,能算到小数点后两位

0.2 节的说法是"decode 是访存密集,时间 ≈ 要读的字节 ÷ 带宽"。 这一轮是第一次能用两种权重精度去验证它 —— 而且验得相当准。

# 一次解码步要读的字节
权重   FP16   7.62e9 × 2 B = 15.23 GB
       Q4_K_M              =  4.68 GB      → 3.25 倍
KV     平均上下文 1152 tok × 56 KiB = 0.066 GB / 条

# C=1 的理论地板(4090 峰值带宽 1008 GB/s)
vLLM   (15.23 + 0.066) / 1008 = 15.17 ms   实测 15.92  → 效率 95.3%
llama  ( 4.68 + 0.066) / 1008 =  4.71 ms   实测  5.88  → 效率 80.0%

# 把两笔账乘起来
预测加速 = 3.25 × (80.0% / 95.3%) = 2.72×
实测加速 = 15.92 / 5.88            = 2.70×   ← 差 0.7%

prefill 这一头,量化一点忙都帮不上

同一份 1024 token 的提示词,llama.cpp 在 C=1 下 prefill 用了 85.7 ms(12,024 tok/s), vLLM 的整个 TTFT(含调度和网络)是 104.9 ms。 两者基本打平,而 llama.cpp 少读了 3.25 倍权重却没换来任何优势 —— 因为 prefill 是算力密集:1024 个 token 一起过网络,权重读一次就够摊到 1024 个 token 头上, 瓶颈早就从带宽换到了 FLOPs,而 Q4 的解量化只会让 FLOPs 更多。

这条结论值得单独记住:量化换来的是解码速度和显存,不是首字延迟。 对话类负载(短输入长输出)量化收益大;RAG / 长文摘要(长输入短输出)收益小得多。

摊薄批处理红利,vLLM 吃到了 86%,llama.cpp 只吃到 32%

这是本轮的核心图。批处理为什么能提吞吐?因为一个解码步把权重读一次,可以同时喂给 C 条序列 —— C 越大,每 token 分摊到的权重字节越少。理论地板 (W + C×KV) / BW 随 C 增长得非常慢: vLLM 从 15.17 涨到 17.21 ms(+13%),llama.cpp 从 4.71 涨到 6.74 ms(+43%)。 实测呢:vLLM 15.92 → 19.99(+26%),llama.cpp 5.88 → 21.02(+257%)。

换个说法:每多接一条并发,要多付多少

# 解码步长对 C 求斜率(用 C=1 与 C=32 两点)
理论地板    KV 0.066 GB / 1008 GB/s   = 0.066 ms / 条 / token
vLLM       (19.99 - 15.92) / 31       = 0.131 ms / 条 / token   ← 地板的 2.0 倍
llama.cpp  (21.02 -  5.88) / 31       = 0.488 ms / 条 / token   ← 地板的 7.4 倍

波次11 个整整齐齐的 32:llama.cpp 没在做 continuous batching

把服务端日志里 312 条 slot release 按时间聚类,得到的不是均匀分布, 而是 11 个大小恰好为 32 的波。前两波的 32 条请求在 10 毫秒内全部结束 —— 它们是被当成一个同步批次跑完的。这跟 continuous batching 的行为完全不同。

9.8 秒一波,这个数能直接对上

# 一波 = 32 条 × 256 token
纯解码   256 tok ÷ 28.2 tok/s(每 slot 稳态)= 9.08 s
prefill  32 × 1024 = 32,768 token,分批塞进去 ≈ 0.7 s
                                        合计 ≈ 9.8 s  ← 实测周期 9.78 s
一波产出 32 × 256 = 8,192 token ÷ 9.8 s = 836 tok/s  ← 实测 890(含前两波缓存红利)

停顿的证据:ITL 的中位数和均值分家

                       ITL p50    TPOT 均值   停顿占比
llama.cpp  C=8         10.12 ms   12.40 ms   +22.6%
llama.cpp  C=32        21.02 ms   31.40 ms   +49.4%
vLLM       C=8         16.74 ms   18.32 ms    +9.4%
vLLM       C=32        19.99 ms   28.37 ms   +41.9%

# p99 ITL —— 一次停顿有多长
llama.cpp  C=32   369.9 ms      vLLM C=32   190.3 ms

ITL 的中位数是"没被打断时的解码步长",TPOT 均值把停顿也摊了进去。 llama.cpp 在 C=32 上有 49% 的解码时间是在等别人的 prefill,单次最长停顿 370 ms —— 是 vLLM(190 ms,已开 chunked prefill)的 1.9 倍。

显存Q4 省下的 15 GiB,这一轮一点没用上

5.5 节的预期里有一条:"量化省下的显存换成了 KV cache 空间"。 本轮没有兑现 —— 不是因为不成立,是因为 -c 65536 把配置写小了。 llama.cpp 只开了 65,536 token 的 KV,比 vLLM 的 86,896 还少,剩下约 15 GiB 显存全程闲置。

# KV 每 token 的字节数 —— 两个引擎完全一致,三处独立验证
公式    2(K,V) × 28 层 × 4 KV头 × 128 dim × 2 B = 56 KiB
vLLM    4.64 GiB ÷ 86,896 tok                   = 56.0 KiB
llama   69.961 MiB ÷ 1,279 tok(prompt cache 条目)= 56.0 KiB

# 两边的 KV 池
vLLM    86,896 tok  ·  共享池(PagedAttention,谁需要谁拿)
llama   65,536 tok  ·  硬切成 32 份(n_ctx_slot = 2048,kv_unified = false)

成色三条必须写进结论的数据瑕疵

这一轮的数据不是干净的。三个问题,一个偏向 llama.cpp,一个是它的真实缺陷,一个是采集漏了。 好消息是三个都不改变主结论 —— 但博文里必须写出来,不然就是选择性报告。

① prompt cache 默认开着,C=32 有 23% 的请求白拿了 prefill

# 服务端日志(原文)
slot get_availabl: id 31 | selected slot by LCP similarity, f_sim_best = 1.000
slot print_timing: id 24 | prompt eval time = 24.54 ms / 1 tokens   ← 应该是 1024
srv         alloc: - making room for prompt cache entry, removing oldest entry (69.961 MiB)

# 各轮的 prefill 命中率
C=1     0 / 10      0.0%
C=8    10 / 80     12.5%
C=32   72 / 312    23.1%   命中的 prefill 均值 55 ms,未命中 291 ms

成因很清楚:三轮 bench 都用 --seed 42 + --dataset-name random, C=8 的前 10 条提示词和 C=1 的完全相同,C=32 的前 90 条和前两轮相同。 llama-server 的 prompt cache(默认 8 GiB 主机内存)跨轮把它们留下了,于是 90 条里有 72 条直接命中。 而 vLLM 侧是显式 --no-enable-prefix-caching 跑的。

② C=32 掉了 8 条请求,服务端日志里找不到它们

# 对账
bench 报告            completed 312 · failed 8 · 总数 320
服务端 launch_slot_   c1 10 + c8 80 + c32 312 = 402 次
                     → 那 8 条从来没拿到 slot

# 唯一一条服务端主动放弃的记录(它反而被算成了 completed)
W common_chat_peg_parse: unparsed Content-only output: ��
W srv          stop: cancel task, id_task = 5800
I slot      release: id 0 | task 5800 | n_tokens = 1026   ← 只生成了 2 个 token

最可能的解释:--dataset-name random 造出来的提示词是随机 token id, 反解成文本后可能带上非法 UTF-8 字节序列。生成侧已经抓到一次现行(task 5800 因为输出无法解析被取消), 请求侧同样的问题会让 llama-server 在建任务之前就拒掉 —— 这正好解释"没有 slot 记录"。 C=32 的 230 条新提示词里失败 8 条 = 3.5%,而前 90 条(前两轮验证过能跑)一条没失败,与这个解释相符。

③ 两处采集缺口

• llama.cpp 的 nvidia-smi 显存没记 —— 5.3 节明确要求过。5.5 节对比表里"总显存占用"那格只能填推算值。
• C=1 只跑了 10 条请求、16 秒(vLLM 侧是 40 条、166 秒)。TPOT 有 2,560 个 ITL 样本,足够稳; 但 TTFT 只有 10 个样本,p99 那格没有统计意义。
• 两组数据隔了 9 天(8/15 vs 8/24),是两台租用实例。GPU 型号、驱动 590.48.01、 vLLM 0.27.1、torch 2.13.0+cu130 全部一致,但不是同一块物理卡。

--ignore-eos 这条倒是验过了:服务端日志里 311 条请求全部 eval time = ... / 256 tokens, 一个不多一个不少。bench 报的 254.1–255.9 是反解码再切词的损耗,不是提前停了。

核对5.5 节写下的三条预期,对了两条半

数据完整测量结果

下一步这轮之后该补的四件事

• 把 -c 拉到 262144 重跑一遍 —— 这是唯一一条没验证的预期,而且是量化专题的接口。 同时记 nvidia-smi --query-gpu=memory.used,把 5.5 表里那个 ≈ 去掉。
• 清掉 prompt cache 再测一次 C=32 —— 加 --no-prompt-cache,每轮换 seed。 当前的 TTFT / 吞吐数字对 llama.cpp 偏乐观 23%,得知道扣掉之后交叉点挪到哪。
• 用 sharegpt 数据集复现那 8 条失败 —— 顺便把 bench 的 stdout tee 下来。 要么坐实"随机 token 造出非法 UTF-8",要么发现别的问题。
• 补 C=2 / 4 / 16 三个点 —— 交叉点现在是两点插值出来的,C=16 和 C=24 各测一次就能钉死。 顺便让 llama.cpp 这条线和 vLLM 一样有 7 个点。