机器

快在哪:四个开关各管一件事

1. octave_k3v4 KV cache(本文主角,50 倍的主角)
KV cache 是模型对读过内容的记忆,fp16 存法每 token 每个 KV head 要 1024 字节,256K 直接爆显存。octave 是 JartX 在 vLLM 里做的压缩 KV 格式:K 用 3 bit、V 用 4 bit,压到 248 字节,只有 fp16 的 1/4,同样的显存装 4 倍上下文。而且它不是只省地方——JartX 的 WMMA 内核直接从压缩格式读数据做矩阵乘,省显存和提速是同一件事。作者在 4× 7900 XTX 上压 attention 内核的实测(原文在他仓库 OCTAVE_SPEED.md,注意:那是用 VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 把 max-model-len 放宽到 380K 的内核级压力测试,不是"这模型能跑 380K 上下文"——27B 原生上限就是 256K,我生产也是 256K

换句话说,octave 内核在超出原生上限的超长序列下,比 fp16 快约 50×、比 TurboQuant 快 4.6-5.3×,且 MTP 验证路径比 TRITON_ATTN 快 78×——这才是 256K 真并发还守得住的底层原因。(同文件另测 380K 冷 prefill 比 fp16 快 20%、比 TurboQuant 快 2.1 倍。)

质量代价见下节实测,一句话:容量翻倍,没断崖。

2. MTP 投机解码(--spec-tokens 3)
模型自己"打草稿":每出一批字先猜 3 个再验证,猜对等于白嫖。27B 带原生 MTP 头,接受率够高,短上下文 96+ tok/s 基本是它撑起来的。关了这个,速度直接腰斩。

3. 30GB 内存 = 会话缓存,不是用来"跑"的
这块内存的定位说清楚:主角色是缓存,不是算力。多会话并发时,每个会话的 KV 状态常驻内存,切回来直接续上——热启动。前面 220K 那行"第二次问只要 5.3 秒"就是这么来的:前缀不用重算,直接命中。顺带的次要作用才是兜底:220K×6 这种超出 GPU KV 池的长会话,能被换到内存里不死掉。所以别把它理解成"借内存跑推理"——它是让 N 个长会话都能随时回来,不是让一台 48GB 显存的机器假装 78GB。

4. TP2 与 MoE 两个前瞻
词表先说透:27B 词表 248,320 token,TP2 下 embedding 和 lm_head 是每张卡各存一份全量(bf16,合计每卡约 4.7GB),不分片——别指望 TP2 切半词表,省的是 attention 和 MLP 的权重与激活。
更大的彩蛋:这个 fork 带 W4A16 冷专家 CPU offload,作者已在 2×24GB 上把 Qwen3.5-122B-A10B(256 专家 / top-8 / 48 层)端到端跑通——全量专家常驻内存,每层只换热专家进显存,一个环境变量 VLLM_MOE_EXPERT_CACHE_SIZE 控制。双 XTX 跑大 MoE 有明确路线,不用等 4 卡。

KV 压缩,质量掉了吗(同机实测对照)

10-06 同一台机器、同一个模型,KV 格式切换前后各打一轮隐藏指令探针:

容量接近翻倍,质量都在可用线内。第三方参照:上游 4×7900 XTX 的 GSM8K,k3v4 = 91.4,fp16 = 91.8,基本持平;反面教材是 TurboQuant——开 MTP 会输出垃圾(GSM8K 掉到 1% 附近),octave 把这块修好了,MTP=3 跑 256K 才有前提。

速度矩阵(2K→220K × 1~8 路并发)

口径:每格 = 该上下文 + 该并发下单条请求的 decode tok/s 中位数(你体感的速度);括号 = 各流速率加总(高并发格各流首尾不齐,当量级看)。

"-" = 没测。

怎么读:

• 2K~90K:4 路和 6 路总吞吐打平,但 6 路每路更慢,4 路是性价比顶点;
• 150K~180K:6 路略占优,但每路体感已明显变挤;
• 220K:差距拉大(162 vs 157),长文档卡 4 路;
• 单流随上下文缓降,220K 还剩 70——"一篇长文反复追问"的日常用法,体验完全在线。

等第一个字

多路共享同一份长前文时,前文只算一次,4 路 30K 并发 TTFT 1.5s 左右。这就是上一条会话缓存的价值:agent 场景基本无感。一次性的全新长文,220K 要等 50 秒,物理成本,没救,只能预热。

踩坑:EPYC 单核频率

作者是 4 卡 + 高频桌面 CPU,我这台 EPYC 7452 单核睿频只有 3.35GHz。MTP 的验证调度走 CPU,单核慢一点,单流速度会比高频平台略低。EPYC 的好处在并发宽度:64 线程拉满多路时 CPU 不拖后腿。

怎么复刻

仓库: github.com/JartX/vllm
基于 vLLM 上游的 AMD 优化分支,作者 4× 7900 XTX 自维护,持续在更新——octave KV、MTP、RDNA3 专用 attention 内核、MoE 专家 offload 都从这里长出来,上游还在 RFC/PR 阶段。带每日 watchdog,分支一动就提醒,关注仓库最新状态就行,别抱死某个旧 commit。

我跑的版本: 源码 commit 317415c5a1fd(2026-10-06 打包),生产基线分支 perf/rdna3_full_stack。复刻前先拉最新 commit 对比。

构建要点(ROCm,我用 docker 隔离编译):

# 核心环境变量,缺一不可
export PYTORCH_ROCM_ARCH=gfx1100
export VLLM_TARGET_DEVICE=rocm
# ROCm 版 torch + triton-rocm,别装成 NVIDIA 的
uv pip install torch-2.13.0+rocm7.2 triton_rocm-3.7.1
# 源码 tar 没有 git 元数据,版本手动钉
export SETUPTOOLS_SCM_PRETEND_VERSION=0.0.dev0+g317415c5a1fd
uv pip install -e . --no-build-isolation --no-deps

8 核 / 24GB 内存就够,不用 GPU 也能编(构建和部署分开)。编译完 import vllm 和 torch.ops._C.octave_cache_store 都在,就算成了。

启动命令(生产原样,一字未改):

vllm serve /path/to/Qwen3.8-27B-W4A16-AutoRound \
  --served-model-name qwen3.8-27b \
  --tensor-parallel-size 2 \
  --kv-cache-dtype octave_k3v4 \
  --attention-backend ROCM_OCTAVE \
  --max-model-len 262144 \
  --max-num-seqs 8 \
  --max-num-batched-tokens 8192 \
  --enable-prefix-caching --prefix-cache-retention-interval 3296 --prefix-match-unit 16 \
  --enable-chunked-prefill \
  --gpu-memory-utilization 0.95 \
  --spec-method qwen3_5_mtp --spec-tokens 3 \
  --enable-mamba-shared-prefix-checkpoint \
  --max-cudagraph-capture-size 16 \
  --kv-transfer-config '{"kv_connector":"SimpleCPUOffloadConnector","kv_role":"kv_both","kv_connector_extra_config":{"backend":"cpu","cpu_capacity_bytes":32212254720}}'

两个坑:

• 30GB 会话缓存是吃内存的,内存不够把 cpu_capacity_bytes 调小,或删掉这行(代价是 220K 这种超长会话兜不住);
• 换模型的话 MTP 参数(--spec-method)跟着换,不是所有模型都有原生 MTP 头,没有就删掉这两行,速度掉一截。

收个尾

AMD 卡还在升值:以前 7900 XTX 算玩具卡,现在 2 张 48G 显存 + 30G 会话缓存,27B 的 256K 上下文日常用——30K 上下文 8 路并发聚合 400tok/s,220K 长文还能 70 tok/s 不趴,多会话热启动秒回。单流速度没什么好吹的,大家都在 90~110 区间;真正的差距在长上下文和并发,这块以前是 AMD 的短板。想复刻的门槛也低:仓库现成,编译脚本半小时的事。

有问题评论区提,数字都能复现,欢迎拿自己的机器对比着测。