单卡 32G 显存放不下两个引擎，所以两个版本是同一天交替跑的：停一个、起一个、同一套客户端脚本、同一批 prompt。下面所有对比都是这样测出来的。

硬件

两个版本的差异（配置层面）

一、单流 decode 和 TTFT —— 基本持平

n=40，每条 256 tokens：

结论：单流没有任何回退，也没有明显提升。 TTFT 那 4 毫秒的差距，在实际使用里被网络往返盖掉了，可以忽略。

二、并发 —— 提升最大的一项

两个请求同时发，各 512 tokens：

9 月版是 --max-num-seqs 1，第二个请求只能排队等第一个跑完（所以 TTFT 4 秒多）；10 月版两个请求真的并行，各自还有 116 t/s。

三、长文档 prefill（pp）—— 也基本持平

用一份长文档做冷启动，pp 按「输入 tokens ÷ 首字延迟」折算：

两边都在 2200–2600 t/s 量级，并且都随深度下降（129K → 187K 掉约 14%）。升级没有改变 prefill 性能。

四、长文档重复提问 —— 单文档两边都很好

同一份 187K tokens 的文档，连问三次：

这一项 10 月版没有优势 —— 9 月版的 prefix caching 已经能把整份 187K 文档留在缓存里，暖启动 1.7 秒。

五、多个对话并存 —— 真正的差距在这里

同时开 N 个长约 61K tokens 的对话，轮流问（每个都问两轮，看第二轮的缓存命中）：

同时打开的对话	总 tokens	9 月版	10 月版
2 × 61K	123K	全部保留	—
3 × 50K	150K	全部淘汰	全部保留
8 × 61K	492K	不可能（超出上下文）	全部保留
9 × 61K	554K	—	全部淘汰

9 月版的 KV 只有 206K tokens，同时开 3 个约 5 万 token 的对话，缓存就整体失效，之后每次切回某个对话都要重新 prefill（约 15 秒）。10 月版可以稳定保留 8 个这样的对话，总共 492K tokens。

注意：两边的「淘汰点」都明显低于标称容量 —— 9 月版在 60%–73% 之间（60% 还能保留，73% 就全丢），10 月版在 82%–88% 之间。标称数字不能直接当可用容量看。

DSH 实测同时跑五个sessions，解码速度最低 83tok/s，单跑一个session 最高 168tok/s。 有兴趣可以到这连结看看跑过的 prompts。
One Prompt to a 3D Website in 30 Seconds (6 Tested)

六、短问题插在长 prefill 后面 —— 感受最明显的一项

场景很日常：让 agent 读一份大文件（长 prefill 正在跑），这时你问一个 17 个 token 的短问题。

9 月版的短问题延迟会随长上下文线性恶化；10 月版靠 --long-prefill-token-threshold 2048，短问题被插在 prefill 的分块之间执行，延迟稳定在 0.6–1.1 秒，与长文档大小无关。

这一项是单用户、单对话就能遇到的，不需要并发。

七、更长的上下文

10 月版把上下文上限开到 262144（实测最大输入约 262K）：

	9 月版	10 月版
上下文上限	204800	262144
单次 231K tokens 输入	HTTP 400（超限）	冷 111.45 s → 暖 1.55 s（缓存 99.6%，72×）

八、输出质量

定义：预算是每题允许输出的 max_tokens。 我们故意跑两档，因为这两档回答的是不同问题：

结果：

结论：在我们这 29 条题上，4-bit KV 没有量到任何质量损失。 需要说明的是题库不大、
类别也有限，这只是一个方向性的检查，不等于全面的质量保证。

九、显存表现

满 KV 持续压测（10 分钟持续请求 + 4×90K 长上下文占住缓存）：

10 月版跑得更靠近上限（余量约为 9 月版的 63%），但全程没有出现卡顿。我们用 10 月版新增的 PAITON_VRAM_HEADROOM_MIB=1024 来替代 9 月版手动下调 --gpu-memory-utilization 的做法。

我们最终用的参数

镜像：ghcr.io/eliovp/paiton-vllm-plugin:qwen38-rocm10-vllm029-20261005-r1

# 关键参数
--mode long-kv4
--max-model-len 204800
--max-num-seqs 8
--max-num-batched-tokens 4096
--kv-cache-dtype fp8
--kv-cache-memory-bytes 11870208000
--gpu-memory-utilization 0.98
--enable-prefix-caching --enable-chunked-prefill
--prefix-cache-retention-interval 32000
--long-prefill-token-threshold 2048
--attention-backend R4D
--speculative-config '{"method":"dflash","num_speculative_tokens":7,…}'

# 视觉输入
--limit-mm-per-prompt '{"image":10}'
--mm-processor-kwargs '{"min_pixels":1048576,"max_pixels":4194304}'
--mm-processor-cache-gb 1

# 环境变量
PAITON_KV4=1
PAITON_KV4_CAPACITY=1
PAITON_VRAM_HEADROOM_MIB=1024
PAITON_LMHEAD_W8=1
PAITON_HOST_EMBED=1
PAITON_PC_EAGLE_TAIL=1
PAITON_PC_SPARSE_ALIGN=1
PAITON_NGRAM_CODRAFT=1

几个我们改过、和官方 launcher 默认值不一样的地方：

• PAITON_VRAM_HEADROOM_MIB=1024：官方的 --vision 组合会把它去掉，我们手动加回来（这是控制显存不顶到 100% 的机制）。
• --long-prefill-token-threshold 2048：官方的 --vision 组合也会去掉，我们加回来 —— 上面第六节的 43.7× 就是靠它。
• 图片像素上限：官方默认 max_pixels 是 8294400（4K），我们压到 4194304（2K）并加了 min_pixels 1048576。实测 10 张 4K 图时显存峰值到 97.6%（只剩约 0.76 GiB），压到 2K 后峰值约 95.7%（剩约 1.36 GiB）—— 我们选后者是为了留出余量。
• PAITON_LMHEAD_W8=1 省下的 1.18 GiB 会变成 KV 缓存块：在 262144 上下文下我们量到 KV 从 569878 → 628877 tokens（+10.4%）。它是加缓存，不是提速度。

小结

对我们这种会同时开几个长对话、并且经常在 agent 读大文件时追问的场景，第三到第五行的收益是实打实的。如果你只是单对话串行使用，升级主要拿到的是短问题延迟那一项。

以上都是我们在一张卡上的实测，不是标准 benchmark，客户端脚本和 prompt 集是我们自己写的。镜像来自上游仓库，参数已经列在上面。