抡锤者

Ben Lee

7900 XTX 双卡跑 Qwen3.8-27B：vLLM vs SGLang 最终测试对比报告（基于自己的工作流）

全部数据：2026-09-18 本机实测 · 双 RX 7900 XTX + Ryzen 5 9600X + 64G DDR5 RAM
图：fig_g1_v3_white.png（主图）· fig_g1_split_white.png（左右分栏备选）

先说结论

我这台机器：双 RX 7900 XTX（24G显存 ×2）+ Ryzen 5 9600X + 64G DDR5，Ubuntu 原生，ROCm 7.2。双卡走 PCIe 4.0 x8（不是 x16，这点后面会影响结论）。

模型 Qwen3.8-27B（text architecture：64 层 / 48 linear_attention / 16 full_attention / dense，不是 MoE），SGLang 和 vLLM 用 W4A16-AutoRound-GPTQ，KV 精度各自默认（vLLM int8_per_token_head，SGLang fp16）。

这张帖子是致敬@ flyer666 大神的魔改 SGLang，同时把自己的测试成绩分享出来供大家参考。上面的测试图里的数字很清楚，大神的魔改SGLang嘎嘎乱杀

备注：所有数字都是同一天、同一台机器、我用同一个模型实测出来的，不是从别处搬的，也不是复述别人的。另外我的测试方法跟我的个人使用方向和习惯高度定制（见3.1），不代表适用所有场景。

第一点：vLLM 和 SGLang，到底谁快

prefill（冷启动）

这一项四家几乎没有差别：

上下文	vLLM	SGLang 官方	SGLang 魔改	SGLang + DFLASH
32K	1624 t/s (20.2s)	1608 (19.9s)	1575 (20.3s)	1546 (20.7s)
64K	1354 t/s (48.4s)	1337 (47.9s)	1332 (48.1s)	1317 (48.6s)
96K	1173 t/s (83.8s)	1151 (83.4s)	1155 (83.1s)	1142 (84.1s)

差异不到 3%。喂长文本这件事，两家一样快。 加投机解码也不会让 prefill 变快（反而慢 1–2%，因为 draft 模型也要占一点算力）。

decode（单流输出）

这里才是分水岭。先把「投机」和「不投机」分开看。

不投机：

上下文	vLLM（无 MTP）	SGLang 魔改版	SGLang 官方版
d0	52.79	54.04	44.66
32K	53.05	48.80	39.80
64K	46.30	44.86	35.77
96K	40.91	41.71	32.72
128K	36.46	38.83	29.97

vLLM 裸机和 SGLang 魔改版几乎是同一个水平（53 对 54）。

这是应该的 —— 同一个模型、同样的卡、都关掉投机，瓶颈都是显存带宽读权重，谁来都跑不出花来。

差距出现在「魔改版 vs 官方版」：魔改版 d0 快 21%，32K 快 23%，64K 快 25%，96K 快 27%，128K 快 30%。越长越明显。

投机：

vLLM 用模型自带的 MTP 头：

d0 112.93 · 32K 86.08 · 64K 71.33 · 96K 58.71 · 128K 46.39
相对自己基线：2.14 倍 → 1.62 倍 → 1.54 倍 → 1.43 倍 → 1.27 倍

SGLang 魔改版用专门训练的 DFLASH draft 模型（1.2G）：

d0 103.82 · 32K 179.87 · 64K 155.38 · 96K 132.19 · 128K 128.64
相对自己基线：1.92 倍 → 3.69 倍 → 3.46 倍 → 3.17 倍 → 3.31 倍

这是整张表最值得看的地方：

vLLM 的投机收益随上下文增长而衰减（2.14 → 1.27 倍）
DFLASH 的收益随上下文增长反而变强（1.92 → 3.31 倍）

原因不难理解：

MTP 是模型自带的草稿头，上下文越长它的预测质量越差（实测接受长度从 3.9 掉到 1.3 附近）
DFLASH 是专门训练的 draft 模型，长上下文下仍然保持 3.5 左右的接受长度

所以 32K 那一格：DFLASH 179.87，是 vLLM+MTP（86.08）的 2.09 倍。
128K 那一格：DFLASH 128.64，是 vLLM+MTP（46.39）的 2.77 倍。

第二点：vLLM 的三个硬伤

说 vLLM 快，是单流快。但实际用起来，有三个问题很致命。

2.1、并发是串行的

96K 上下文，同时发 1 / 2 / 3 个请求，看完成时间：

配置	1 路	2 路	3 路
vLLM	88.63s	190.84s	293.90s
SGLang 官方	9.36s	9.51s	9.36s
SGLang 魔改	6.43s	7.42s	9.12s
SGLang + DFLASH	3.55s	5.51s	6.74s

vLLM 的 wall time 是线性翻倍的 —— 第 2 个请求的 TTFT 是 185.5s，第 3 个是 289.2s，几乎全程在等。它不是「并发」，是「排队」。

3 路 96K：vLLM 要 293.9 秒，SGLang 只要 6.74 秒。差 43 倍。

2.2、前缀缓存没有生效

同一个 prompt 问第二次（理论上应该命中缓存，TTFT 接近 0）：

配置	32K	64K	96K
vLLM	20.215s	48.482s	83.777s
SGLang 魔改	0.127s	0.214s	0.310s
SGLang + DFLASH	0.133s	0.223s	0.315s

vLLM 的热恢复时间 = 冷启动时间。缓存开了但没起作用。

这个在日常使用里影响巨大：Agent 反复读同一份代码库、反复问同一份文档，SGLang 是 0.1 秒，vLLM 是 20–80 秒。

2.3、没有 prefill / decode 隔离

场景：正在生成一段长输出，这时插入一个新请求。

配置	插入干扰最大间隔
vLLM	6087.2 ms
SGLang 官方	341.9 ms
SGLang 魔改	193.1 ms
SGLang + DFLASH	256.0 ms

vLLM 在跑新请求的 prefill 时，会把正在生成的那一条完全堵住 —— 长输出的 decode 从 96 t/s 掉到 8.57 t/s，最大间隔 6 秒卡顿。

SGLang 的 chunked prefill 机制要好得多。

一句话：vLLM 单流很快（靠 MTP），但多用户、多轮、边聊边取数据的场景，SGLang 明显更顺。

不过我必须声明一下：在我从单卡 Vulkan 升级到 vLLM 双卡的这几个星期里，体会到了巨大的提升和乐趣。不是 vLLM 不能打，实在是还有高手 —— 魔改 SGLang 不讲武德，嘎嘎乱杀。

第三点：为什么我最后切到了 SGLang

3.1 我平时怎么用这台机器

先说清楚我的使用场景，不然下面的数字没法对号入座。

我这台机器不是拿来跑 benchmark 的，是我日常在用的：

· 长文档处理 —— 一份几万字的材料丢进去，来回问十几轮
· Agent 干活 —— 同一个代码库/同一份资料，反复读、反复改
· 一次开机一整天 —— 服务不重启，对话不中断
· 多任务并行 —— 一边写东西一边让它在后台跑别的

具体到工具链，我用的是 Hermes，本地三个 Agent 并行。
我希望的目标环境是这样：

Hermes：三个 Agent 并行
上下文：256K
压缩阈值：65%（约 16.6 万 token 触发压缩）

这个 65% 是压缩机制：上下文用到约 16.6 万 token 时，
它会自动把前面的内容总结压缩，腾出空间继续跑，
这样一天下来可以连着聊几十轮不断线。

这就是为什么我这么在意「长上下文还能跑多快」——

我不是偶尔塞一份长文档就完事，我是几十轮对话、长期挂在高水位：
前面讨论过的数字、贴过的材料，几十轮之后还要能准确地调出来、迅速重现。
这就要靠前缀缓存一直命中，而不是每轮从头算一遍。

所以我看重的不是「单次极限速度」，而是这三件事：

① 热恢复快不快（第二遍问同一个东西，要不要重新算）
② 并发会不会互相堵（同时来几个请求，是不是排队）
③ 长上下文掉不掉速（聊到 12 万 token 还跑不跑得动）

这三条，就是下面所有测试的出发点。

3.2 我的测试方法，对应的是我实际会遇到什么

我测的	对应我日常遇到的事
冷启动 prefill	第一次把长材料喂进去，要等多久
单流 decode	它开始回答以后，吐字快不快
并发 1/2/3 路	同时开几个任务，会不会互相等
热恢复 TTFT	同一个问题几十轮后问第二遍，是不是秒回
插入干扰	它正在写，我插一个新请求，会不会卡死
长输出 gen512	让它写一篇长东西，中途会不会掉速

上下文选 32K / 64K / 96K / 128K 四档，是因为
我的实际用法就落在这个区间 —— 不是短 prompt，
也不是打到 200K 的极限。

3.3 SGLang 真正的三个杀手锏

下面这三个是 SGLang 相对 vLLM 的结构性优势，也是我最终切过来的原因。

① RadixAttention（前缀树缓存）

这是那个「0.127 秒」的来源。

原理不复杂：SGLang 把所有请求的前缀建成一棵树（radix tree），
相同的开头只存一份。所以第二次问同一个东西、
或者 Agent 第二轮带着前一轮的上下文再来，
它不用重新算 —— 直接从树上接上去。

实测：

同一个 prompt 问第二次的 TTFT
32K：0.127s（vLLM 20.215s） —— 快 159 倍
64K：0.214s（vLLM 48.482s） —— 快 227 倍
96K：0.310s（vLLM 83.777s） —— 快 270 倍

vLLM 那边我也开了前缀缓存，但实测热恢复时间 = 冷启动时间，
等于没生效。

这个差距在日常使用里是致命的：
Agent 每轮都要带着全部上下文重来一遍，
SGLang 是 0.1 秒接上，vLLM 是 20-80 秒从头算。

② HiCache 三级缓存：L1 显存 / L2 内存 / L3 磁盘

这是 SGLang 另一个独门设计。它把 KV 缓存分成三层：

L1 = GPU 显存最快，容量最小（24G ×2 里切一块）
L2 = Host 内存次快，容量大（我们有 64G）
L3 = 本地磁盘最慢但最大，理论上是「无限上下文」

数据在这三层之间自动流动：
显存不够了往下压到内存，内存也不够再压到磁盘；
下次需要的时候再逐级拉回来。

我们的实测结论是：

L1 → L2 这条路径：完全跑通
实测 13 分钟后回放，wall = 0.443 秒，
对比冷启动 15.068 秒 —— 约 34 倍加速。
而且交叉验证过：客户端拿到的 cached-token 数 12032
和服务端记录的 full_kv_hit_length 12032 逐字一致，
不是自证。

L3（磁盘）这条路径：️ 我们测下来没跑通
写入是可以的（262 次 write 成功落盘），
但读取路径没打通。
根因已经定位到源码级：L3 restore 之后，
请求侧的 node identity 没有和新生成的 node 重新对齐
（re-anchor / node identity split）。

所以这一帖里所有「热恢复 0.1 秒」的成绩，
是 L1/L2 的功劳，不是 L3。

我把这段如实写出来，是想说：
HiCache 的机制没问题，L2 就已经很香了；
但 L3 这条路我们踩过，暂时走不通，
别看到「三级缓存」就以为磁盘那层能白用。

③ DFLASH 投机解码（专门训练的草稿模型）

这是最猛的一项，也是 flyer666 魔改版的核心。

先说原理。投机解码就是「先猜后验」：

用一个小的草稿模型先猜出接下来 8 个 token，
然后目标模型一次性验证这 8 个。
猜对了就白赚，猜错了就退回重来。

关键在于草稿模型的质量。这里有两种做法：

vLLM 用的是 MTP —— 模型自带的草稿头
SGLang + DFLASH 用的是专门训练的 5 层草稿网络

差别在长上下文下极其明显：

短上下文：两家差不多（MTP 接受长度 3.9，DFLASH 3.5）
长上下文：MTP 掉到 1.3 附近，DFLASH 还能保持 3.5

这就解释了为什么：

vLLM 的投机收益随上下文增长而衰减
2.14 倍 → 1.62 → 1.54 → 1.43 → 1.27（128K）

DFLASH 的收益反而随上下文变强
1.92 倍 → 3.69 → 3.46 → 3.17 → 3.31（128K）

DFLASH 的草稿模型只有 1.2G（W4A16），
占用很小，但收益巨大：
32K 下 179.87 t/s，是 vLLM+MTP（86.08）的 2.09 倍。

3.4 但我必须说清楚两件事

一、DFLASH 有精度代价

这不是我发现的，是 flyer666 自己在帖子里写的：
投机解码的分块验证和逐 token 解码并非逐位等价。

具体表现：约 1/4 的接受边界上，
top-2 logit 的间距小于 0.5 —— M=8 的验证批里，
数值误差足以让 argmax 落到另一个 token 上。

他自己实测的 GSM8K #1 就答错了（答 96，正确是 72）。

所以：要绝对确定性输出的场合（比如代码生成要精确复现、
或者做数学题要严格），
要么关掉投机，要么知道自己在承担这个风险。

二、L3 那层我们没跑通

上面已经说了，不重复。写在这里是因为
「我正式切到了 SGLang」这句话的前提是：
我切的是 L1/L2 这条路，
不是因为它有个看起来更厉害的 L3。

3.5 我的正式生产参数

下面是我实际在跑的配置，可以直接抄。
两套并列：一套是我们这边实测的，
一套是 flyer666 仓库 README 里的最新推荐。

A. 我们的配置（跑出本文所有数字的那套）

环境 / 栈：
ROCm 7.2.3
SGLang 源码树：/data/sglang-dflash2-f84475c（flyer666 魔改版）
模型：/data/models/Qwen3.8-27B-W4A16-AutoRound-GPTQ
草稿：/data/models/Qwen3.8-27B-DFlash2-W4A16

启动参数：
--model-path /data/models/Qwen3.8-27B-W4A16-AutoRound-GPTQ
--tp-size 2 --quantization gptq
--dtype bfloat16 --mamba-ssm-dtype bfloat16
--kv-cache-dtype auto
--attention-backend triton
--context-length 196608
--mem-fraction-static 0.80
--max-running-requests 4
--max-total-tokens 300000
--chunked-prefill-size 8192
--max-mamba-cache-size 24
--cuda-graph-bs-decode 1 2 4
--triton-attention-num-kv-splits 16
--reasoning-parser qwen3 --tool-call-parser qwen3_coder
--default-chat-template-kwargs '{"enable_thinking": false}'
--stream-interval 1

HiCache（只用到了L1/L2两级缓存）

--enable-hierarchical-cache
--hicache-size 12
--hicache-ratio 2.0
--hicache-io-backend kernel
--hicache-host-memory-mode cache

DFLASH

--speculative-algorithm DFLASH
--speculative-draft-model-path /data/models/Qwen3.8-27B-DFlash2-W4A16
--speculative-num-draft-tokens 8
--speculative-draft-window-size 2048

实测资源占用（启动日志原文）：
Mamba Cache（每卡）：
conv_state 0.03 GB + ssm_state 0.88 GB
开 DFLASH 后额外：intermediate_ssm_state 1.41 GB + conv_window 0.02 GB
Tree cache：UnifiedRadixCache，hybrid_ssm=True，hicache_attached=True

调参说明：mem-fraction-static 我试过 0.80 / 0.85 / 0.90，
0.90 会 OOM（gptq_kernels.py:167），0.80 是稳定点。
hicache-size 也试过 20，host 内存会紧张，12 更稳。

B. flyer666 仓库 README 的最新推荐（2026-09-11 实测）

环境 / 栈：
ROCm 7.14（HIP 7.14.60850）
PyTorch 2.11.0（ROCm 7.2 官方构建 wheel）
构建版本：65b16b3df7（含 GDN/WMMA Prefill 调优 + 热 L2 Autotune 修复）
草稿模型：Qwen3.8-27B-DFlash2（5 层草稿网络，
HF 上 incoai/Qwen3.8-27B-DFlash2）

环境变量：
export SGLANG_KV_CACHE_DTYPE=bfloat16
export SGLANG_DTYPE=bfloat16
export SGLANG_RDNA_CUSTOM_AR=1 ← RDNA3 专用 All-Reduce（我们没有）
export SGL_RDNA_NO_FUSED=1
export SGL_RDNA_GEMMA_TRITON=1
export SGL_RDNA_VLLM_VERIFY=1

启动参数：
--tp-size 2 --quantization gptq --dtype bfloat16
--mamba-ssm-dtype bfloat16
--kv-cache-dtype bfloat16 ← 我们用 auto
--attention-backend triton
--context-length 196608
--mem-fraction-static 0.90 ← 我们用 0.80
--max-running-requests 4
--max-mamba-cache-size 20 ← 我们用 24
--chunked-prefill-size 2048 ← 我们用 8192
--cuda-graph-bs-decode 1 2 4
--triton-attention-num-kv-splits 16
--speculative-algorithm dflash
--speculative-draft-model-path /path/to/Qwen3.8-27B-DFlash2
--speculative-draft-model-quantization unquant
--speculative-num-draft-tokens 8
--speculative-draft-window-size 2048
--stream-interval 1

他那边额外的优化（我们还没上）：
· RDNA Custom All-Reduce（scripts/rdna_ar）
RDNA3 没有 CDNA 的 MUBUF/peer-IPC 硬件集合通信，
他写了一阶段点对点 PCIe 专版，靠 SGLANG_RDNA_CUSTOM_AR=1 开启
· 草稿模型换 W4A16 量化版（syvai/Qwen3.8-27B-DFlash2-W4A16）
草稿显存 2.09 → 1.04 GiB/卡，KV 容量 189,172 → 217,746（+15.1%）
· --sleep-on-idle 空闲休眠

他 README 里给的实测（2026-09-11，双卡 TP=2，W4A16 草稿版）：
数学 CoT 约 193 tok/s（GSM8K/MATH-500，3/4 正确）
120k Agentic 会话回放平均约 119 tok/s（中位数 113，最差轮 57）
Prompt 处理约 1,950 tok/s（llama-benchy PP=2048）
depth 0 128 tok/s、16k depth 109 tok/s（保持率 84.8%）

两套配置的差异一览

项目我们 flyer666
ROCm 栈 7.2.3 7.14
mem-fraction-static 0.80 0.90
kv-cache-dtype auto bfloat16
max-mamba-cache-size 24 20
chunked-prefill-size 8192 2048
HiCache 开未提及
RDNA Custom AR 用标准 RCCL 开
草稿模型 DFlash2-W4A16 DFlash2（unquant）/ W4A16 量化版
草稿量化 gptq（继承） unquant / 或继承
sleep-on-idle

3.6 一句总结

我最后选 SGLang，不是因为它单流最快 ——
单流关投机两家差不多（53 对 54）。

是因为它在「反复读同一份材料」这个场景下，
把「重新算一遍」变成了「接上去就行」：

前缀命中：0.127 秒 vs 20 秒
多请求并发：6.74 秒 vs 293.90 秒
长上下文 decode：DFLASH 128.64 vs vLLM+MTP 46.39

我这台机器日常就在干这件事，所以这个差别对我是决定性的。

但前提说清楚：这是「我的场景」的结论。
如果你只是短 prompt 写代码，vLLM 的单流速度也很好，
没必要折腾。

第四点：致敬三个人

在说数据之前，有三个人必须先感谢。

机智罗_LX（B站）

如果你用 AMD 显卡玩过出图和出视频，你大概率用过他的「机智整合包」。ComfyUI 一键装好、工作流内置、连 SageAttention 都给你配好参数。

在他之前，A 卡玩出图是一种折磨：装环境三天，出图三分钟。现在？下载、解压、双击。V1 到 V5，工作流从 24 个到 182 个。

他简介里写的是「爱折腾，目前专注AMD显卡本地玩转AI，希望可以帮助更多人」。就这一句话，把多少人从「A 卡出图」的坑里拉了出来。

抡锤者老特（油管 / lcz.me）

推理这条路，是他一直在前面趟。

《7900XTX双卡TP，SGLang多并发飞速响应，本地AI神卡最后短板被补齐！》
《平民AI神卡：7900 XTX突然真香了？单卡/双卡TP + llama.cpp》

他不只是做视频，他自己建了个论坛（lcz.me），把 A 卡玩家聚在一起，大家把踩过的坑、测出来的数、调通的参数摊在明面上。

我自己也是跟着他的视频才走上 SGLang 这条路 —— 包括这次测试的怀疑方向，源头就在他说过的一句话：SGLang 相比 vLLM 是更高一档的存在。

flyer666（Steven 大神）

这个帖子的核心数据，全部建立在 flyer666 的魔改 SGLang 上。

9 月 6 日，他发布了「魔改 SGLANG 支持 7900XTX 双卡 TP」—— 这是一份高含金量的原创工作，不是小修小补。

他做了什么？把官方拿掉的 RDNA3 补丁链重新补了回来，让 7900 XTX 重新能跑 DFLASH。

先把话说清楚：这不是「官方版慢」，是官方版根本跑不起来。

在官方 main 树上加载 DFLASH，直接报错：

compressed_tensors_wNa16.py:250
NameError: name 'gptq_marlin_repack' is not defined

原因是官方把 RDNA3 的补丁链拿掉了（涉及 5 个 commit：160913a88 / 0ffda9d43 / dc4a2e63b / 7f396e561 / 2862cd451）。flyer666 的魔改版把这套补丁补了回来。

补回来意味着什么？就是下面这张表的差别：

32K  decode：179.87 vs 39.80  → 快 4.5 倍
64K  decode：155.38 vs 35.77  → 快 3.5 倍
128K decode：128.64 vs 29.97  → 快 3.3 倍

补丁做完的效果，用一句话形容就是：杀疯了，嘎嘎乱杀。

179.87 这个数字，比全场任何配置都高一倍以上。这不叫「修复」，这叫「把不可能变成了可能」。

对我们这些买了 7900 XTX 的人 —— 说得直白点，不富裕的人 —— Steven 就是活菩萨。

PS：这三个人，AMD 官方真应该给他们发奖状。正是他们凭一己之力，扭转了「AMD 在出图、出视频、推理生态上不能打」的偏见。他们不是在帮 AMD 做市场，他们是在给 AMD 收拾烂摊子。

第五点：官方抛弃 RDNA3，其实也无可厚非

夸完魔改版，另一面也得站到 SGLang 官方这边说句公道话。官方为什么放弃 RDNA3？数据说话。

Steam 2026 年 8 月硬件调查：

AMD Radeon RX 7900 XTX      0.45%
AMD Radeon RX 7900 XT       0.45%

对比一下：

RX 9070 XT（RDNA4，后出的）   1.46%   ← 是 7900 XTX 的 3.2 倍
NVIDIA RTX 3060              3.92%
NVIDIA RTX 5070              3.77%
NVIDIA RTX 5080              1.71%
NVIDIA RTX 4090              0.77%
NVIDIA RTX 5090              0.43%   ← 比 7900 XTX 还低（当然玩儿推理的不一定玩儿游戏，我自己就是，玩AI开始就戒游戏了）

7900 XTX 在全体 Steam 玩家里的占比是 0.45%。在 AMD 大约 18.7% 的总盘子里，7900 XTX 只占约 2.4%。

而且 RDNA3 产线已经收尾了（RDNA5 预计 2026 年底到 2027 年初）。7900 XTX 2022首发 999 美元，2025 年底跌到 799，现在回到 899–949（缺货挤压）—— 存量不再增长。

站在这个前提下：为了 0.45% 的用户维护一套 RDNA3 补丁链，投入产出比确实不划算。从商业角度看，官方这个决定是合理的。

这正是魔改版存在的意义：官方算不过来的账，社区来补。 老特给大家提供了 7900 XTX 这个极高高性价比的选择，flyer666 把 7900 XTX 的性能发挥到了几乎极限 —— 两位都是活菩萨。

我个人：五月份听了老特的视频买了第一张二手的7900XTX，八月份看了flyer666的帖子（也是先听老特的视频然后查的）买了第二张二手的，赚了！

附：完整数据表（全部 2026-09-18 本机实测）

decode 单流，tokens/s

配置	d0	32K	64K	96K	128K
vLLM 双卡 + MTP	112.93	86.08	71.33	58.71	46.39
vLLM 双卡（无 MTP）	52.79	53.05	46.30	40.91	36.46
SGLang 魔改 + DFLASH	103.82	179.87	155.38	132.19	128.64
SGLang 魔改版无投机解码	54.04	48.80	44.86	41.71	38.83
SGLang 官方版无投机解码	44.66	39.80	35.77	32.72	29.97

冷启动 prefill，tokens/s（括号为 TTFT）

配置	32K	64K	96K
vLLM	1624 (20.2s)	1354 (48.4s)	1173 (83.8s)
SGLang 官方	1608 (19.9s)	1337 (47.9s)	1151 (83.4s)
SGLang 魔改	1575 (20.3s)	1332 (48.1s)	1155 (83.1s)
SGLang + DFLASH	1546 (20.7s)	1317 (48.6s)	1142 (84.1s)

并发 96K 完成时间，秒

配置	1 路	2 路	3 路
SGLang + DFLASH	3.55	5.51	6.74
SGLang 魔改	6.43	7.42	9.12
SGLang 官方	9.36	9.51	9.36
vLLM	88.63	190.84	293.90

热恢复 TTFT，秒

配置	32K	64K	96K
SGLang 魔改	0.127	0.214	0.310
SGLang + DFLASH	0.133	0.223	0.315
SGLang 官方	—	—	0.449
vLLM	20.215	48.482	83.777

插入干扰（冷 prefill 打断长输出）最大间隔

配置	最大间隔
vLLM	6087.2 ms
SGLang 官方	341.9 ms
SGLang 魔改	193.1 ms
SGLang + DFLASH	256.0 ms

长输出 gen512

配置	t/s
SGLang + DFLASH	97.38
vLLM	91.75
SGLang 魔改	44.85
SGLang 官方	35.76

测试口径声明（防止有人对不上数字）

硬件：双 RX 7900 XTX（24G）+ Ryzen 5 9600X + 64G DDR5
PCIe：4.0 x8 ×2（根桥限制，不是 x16 —— 双卡会降速）
系统：Ubuntu 原生，ROCm 7.2.3，核显（gfx1036）已排除
模型：Qwen3.8-27B，SGLang/vLLM 用 W4A16-AutoRound-GPTQ
KV：vLLM = int8_per_token_head，SGLang = fp16
上下文上限：196,608
prompt 构造：用 "The quick brown fox jumps over the lazy dog. " 填充（约 10.006 token/句）
decode 测法：流式请求 + stream_options={"include_usage": true} 取真实 completion_tokens

️ 这里有个坑要提醒大家：MTP 模式下 1 个 stream chunk 约等于 3.9 个 token，如果拿 chunk 数当 token 数，测出来的数字会低 3.9 倍。我一开始就踩了这个坑，差点得出「vLLM 退化」的错误结论。

测试卫生：每条测试之间重启服务、清 /dev/shm/nccl-*、显存归零
重复次数：每个数字至少 3–5 次，波动 <1% 才采用

补充一句：这张表里的数字，是我为「长上下文 + 多轮Hermes Agent」这个场景调的，我不写代码，也不会用DSH。如果你只是短 prompt 写代码、做数学题，数字会更好看（轻负载下 decode 能更高），但那是另一个场景，不在这张表的范围内。

常用指标与术语

缩写	英文全称	中文解释	主要看什么
PP	Prompt Processing	提示词处理 / Prefill	模型处理输入上下文的速度，通常以 tok/s 表示
TG	Text Generation	文本生成 / Decode	模型持续生成输出 Token 的速度，通常以 tok/s 表示
TTFT	Time To First Token	首 Token 延迟	从发出请求到收到第一个输出 Token 的时间
TPOT	Time Per Output Token	平均每个输出 Token 的耗时	反映持续生成阶段的平均延迟，通常以 ms/token 表示
ITL	Inter-Token Latency	Token 间延迟	相邻流式输出之间的时间间隔，用于观察卡顿和尾延迟
TPS	Tokens Per Second	每秒 Token 数	模型每秒生成多少 Token
E2E	End-to-End Latency	端到端总耗时	从请求发出到完整响应结束的总时间
C1 / C2 / C4 / C8	Concurrency 1 / 2 / 4 / 8	并发数 1 / 2 / 4 / 8	同时存在多少个推理请求
QPS / RPS	Queries / Requests Per Second	每秒请求数	Serving 场景下单位时间能处理多少请求
Goodput	Goodput	有效吞吐量	在满足延迟或 SLO 要求前提下真正有效完成的吞吐量
VRAM	Video Random Access Memory	显存占用	模型、KV Cache 和推理过程占用多少 GPU 显存

简单理解：**PP 看“吃得快不快”，TTFT 看“多久开口”，TG/TPS 看“说得快不快”，ITL 看“会不会卡”，E2E 看“整件事多久做完”。

引言

今年 AI 大爆发，各种新模型、推理框架和新玩法层出不穷。

作为一个非技术专业的 AI 爱好者，我很依赖论坛里的实测数据来减少自己摸索和试错的时间。但看得越多，也越发现一个问题：

大家测速的口径并不统一。

很多时候，如果只看到一句——特别是视频网站里为了吸引眼球的标题：这个模型跑到了150 t/s

但不知道：

Prefill 还是 Decode？
Context 多长？
Output 多长？
Cache 有没有命中？
Concurrency 是多少？

这个数字其实很难横向比较。

甚至我自己不同时期测出来的数据，Agent 都会时不时提醒我：

测试口径不同，不能直接横向比较。

于是我认真找了一圈现成方案，发现 GitHub 上其实已经有几套相当成熟的测速Benchmark。

所以我的想法变成了：

完全没必要自己重新发明一套“大一统标准”，而应该根据不同测试目的，直接引用成熟工具。

结论先行

先看自己想测什么，再选择对应 Benchmark。

测 GPU / 量化 / Kernel 裸性能
→ llama.cpp / llama-bench

测 OpenAI API / 实际聊天体验
→ GuideLLM

测多并发 / Serving / 饱和点
→ Kubernetes SIG inference-perf

测最终客户端体验
→ MLPerf Client

本地大模型测速 Benchmark 指南.png

1. 裸性能：llama-bench

llama.cpp 官方的 llama-bench，本身就明确区分：

PP：Prompt Processing
TG：Text Generation

支持指定 Context Depth、重复测试，并报告平均 tok/s 和标准差；默认每项重复 5 次。官方还明确说明，它不把 tokenization 和 sampling 时间计入测试。

GitHub：
llama.cpp / llama-bench

https://github.com/ggml-org/llama.cpp/tree/master/tools/llama-bench

所以如果只是想知道：

换了 GPU、量化、Backend、Kernel 后，到底快了多少？

我觉得直接用 llama-bench 最合适。

报告范例

Context	PP / Prefill	TG / Decode	VRAM
4K	3,250 tok/s	101.2 tok/s	40.8GB
8K	3,180 tok/s	100.1 tok/s	41.3GB
16K	3,020 tok/s	98.7 tok/s	42.2GB
32K	2,850 tok/s	96.4 tok/s	44.2GB
64K	2,510 tok/s	91.8 tok/s	46.0GB
128K	2,020 tok/s	82.5 tok/s	47.1GB

测试环境：

项目	设置
模型	Qwen3.8-27B
量化	Q4_K_M
推理框架	llama.cpp
GPU	RX 7900 XTX 24GB ×2
CPU	Ryzen 5 9600X
内存	64GB
Backend	ROCm
Output	512 tokens
重复次数	5

2. API / 实际使用：GuideLLM

GuideLLM 是 vLLM 项目下的独立 Benchmark 工具，主要面向真实 LLM Deployment 测试，支持不同 Backend、Dataset、Metrics 和输出格式。

GitHub：
GuideLLM

https://github.com/vllm-project/guidellm

这类测试更适合看：

TTFT
Decode / TPS
TPOT
ITL
E2E

也就是：

用户点 Send 以后多久开始回答、回答多快、会不会卡顿。

报告范例

Context	TTFT	Decode / TPS	TPOT	ITL P50	ITL P99	E2E	VRAM
4K	0.21s	121 tok/s	8.3ms	8.1ms	12.4ms	4.5s	41.0GB
8K	0.34s	120 tok/s	8.3ms	8.2ms	13.1ms	4.7s	41.8GB
16K	0.84s	118 tok/s	8.5ms	8.3ms	14.7ms	5.2s	43.0GB
32K	1.61s	113 tok/s	8.8ms	8.7ms	17.9ms	6.1s	44.7GB
64K	3.42s	104 tok/s	9.6ms	9.4ms	23.8ms	8.4s	46.1GB
128K	7.10s	91 tok/s	11.0ms	10.7ms	35.2ms	13.0s	47.3GB

测试条件：

项目	设置
Output Length	512 tokens
Concurrency	C1
Requests	10 / 档
Warm-up	1
Cache	Cold
API	OpenAI-compatible

3. 多并发 / Serving：inference-perf

Kubernetes SIG 的 inference-perf 更进一步，本身就是为了标准化推理 Benchmark 工具和指标。

它直接支持：

TTFT
TPOT
ITL
Input / Output TPS
Goodput
并发 / QPS
Saturation Sweep

并支持 vLLM、SGLang、TGI 和 OpenAI-compatible Endpoint。

GitHub：
Kubernetes SIG / inference-perf

https://github.com/kubernetes-sigs/inference-perf

如果测：

C1 / C2 / C4 / C8

或者想知道一台机器到底能扛多少并发，我觉得直接用这个更合适。

报告范例

固定一个典型 Context，例如 8K 或 16K：

Concurrency	TTFT	Output TPS	TPOT	ITL P99	Goodput	备注
C1	0.42s	121	8.3ms	13ms	100%	正常
C2	0.51s	214	9.4ms	17ms	100%	正常
C4	0.93s	318	12.6ms	31ms	96%	基本稳定
C8	2.70s	352	22.8ms	86ms	71%	明显排队

测试条件：

项目	设置
Context	8K
Output	512 tokens
Cache	Cold
Test Duration	60s / 档
推理引擎	vLLM
GPU	RX 7900 XTX ×2

测试结论：

项目	结果
推荐稳定并发	C4
饱和区间	C4–C8
最大吞吐	352 output tok/s
明显排队开始	C8

4. 最终用户体验：MLPerf Client

MLPerf Client 是 MLCommons 面向个人电脑和客户端 AI 推理的 Benchmark，支持 Windows、Linux、macOS，也覆盖 LLM、本地硬件和不同 Execution Backend 的测试。

GitHub：
MLPerf Client

https://github.com/mlcommons/mlperf_client

这类测试更接近：

最终用户实际感觉到底快不快。

报告范例

项目	结果
设备	Desktop PC
操作系统	Windows 11
CPU	Ryzen 5 9600X
GPU	RX 7900 XTX
内存	64GB
Backend / Execution Provider	本地执行
Warm-up	1
Iterations	5
TTFT	0.61s
TPS	82.7 tok/s
E2E	7.1s
峰值 VRAM	22.6GB

那论坛大家发帖分享什么？

我个人的想法是，不管用了哪一种 Benchmark，至少把下面这些信息写出来：

类别	项目
硬件	GPU / CPU / 内存 / 主板
模型	模型名 / 量化 / 推理引擎
测试条件	Context / Output Length / Concurrency / Cache 状态
结果	Prefill / TTFT / Decode / VRAM

如果用了 MTP / Speculative Decoding，再加：

项目	结果
Acceptance Rate
Accepted Tokens

Context 建议

单用户测试，我比较倾向：

4K / 8K / 16K / 32K / 64K / 128K

这样不仅能看到“最高速度”，还能观察：

Context 从哪里开始明显掉速。

并发则不一定每个 Context 都跑，可以单独选一个典型 Context，比如 8K 或 16K：

C1 / C2 / C4 / C8

摘要表

无论用哪套 Benchmark，一张摘要应该是大家喜闻乐见的：

模型	Quant	Engine	GPU	Context	Output	C	Cache	Prefill	TTFT	Decode	VRAM
Qwen3.8-27B	W8A8	SGLang	7900 XTX ×2	4K	512	C1	Cold	3,250 t/s	0.22s	122 t/s	41GB
Qwen3.8-27B	W8A8	SGLang	7900 XTX ×2	8K	512	C1	Cold	3,180 t/s	0.35s	121 t/s	42GB
Qwen3.8-27B	W8A8	SGLang	7900 XTX ×2	16K	512	C1	Cold	2,900 t/s	0.84s	118 t/s	43GB
Qwen3.8-27B	W8A8	SGLang	7900 XTX ×2	32K	512	C1	Cold	2,730 t/s	1.62s	113 t/s	45GB
Qwen3.8-27B	W8A8	SGLang	7900 XTX ×2	64K	512	C1	Cold	2,410 t/s	3.41s	104 t/s	46GB
Qwen3.8-27B	W8A8	SGLang	7900 XTX ×2	128K	512	C1	Cold	1,980 t/s	7.08s	91 t/s	47GB

这样即使后面的完整报告格式不同，最关键的数据仍然可以快速横向比较。

总之

本地模型测速可以不需要重新发明 Benchmark。更合理的做法，是根据不同场景和需求直接引用成熟工具，再用大家喜闻乐见的基本格式分享成果。

具体怎么跑，请参见附件：

《本地模型测速一键执行指南》

本地模型测速一键执行指南_SOP完整版_2026-10-13.md

其中分别提供：

llama-bench
GuideLLM
inference-perf
MLPerf Client

的一键复制 Agent Prompt 和测试模板，其中也结合了本人在实际测试中的一些经验教训。。

友情提示：网络下载任何文件，请注意安全。

本文仅分享一些个人对本地模型测速的思考，暂不涉及模型质量评测部分。抛砖引玉，欢迎大家补充、指正和交流。

2026-10-13

Ben Lee

7900 XTX 的可能性探索｜单卡篇（五）：与时俱进！hipfire DFlash 实测 Qwen3.8-27B MQ4-XTS：8K Decode 169.4 tok/s，Prefill 2682 tok/s

前言/致谢

首先真心感谢 hipfire 团队为 AMD / RDNA 社区做出的贡献。(还有hipEngine，BridgeSpec，llama-cpp-rdna-boosts，KVMem，MoE4All，AMD-AIM / sglang-radeon，Paiton vLLM plugin，以及更多长期为 AMD 本地 AI 推理生态默默投入时间和精力的开发者、研究者和社区大神们）

项目地址：https://github.com/warpfront/hipfire

最近感受到了来自于N卡阵营满满的“敌意” ，尤其是类似于nInfer这类的定向优化让我“醋意满满”（其实我也有N卡，哈哈）；甚至RDNA4 PRO R9700的优化也一日千里 —— 这个真么有，曾经买过一块又让我给退了，各种羡慕嫉妒恨。

昨天终于等到了 hipfire 的更新。连夜在单张 RX 7900 XTX 上测试 Qwen3.8-27B，hipfire DFlash 的表现惊艳，也让我感觉7900XTX终于又可以扬眉吐气，与时俱进了。

测试摘要

参考我之前关于本地模型测速口径的帖子：https://lcz.me/topic/2303

Model	Quant	Engine	GPU	Context	Output	C	Cache	Prefill	TTFT	Decode	VRAM
Qwen3.8-27B	MQ4-XTS	hipfire DFlash	RX 7900 XTX ×1	4K	256	C1	Cold	3026	1.36s	76.9	~17.5GB
Qwen3.8-27B	MQ4-XTS	hipfire DFlash	RX 7900 XTX ×1	8K	256	C1	Cold	2682	3.05s	169.4	~17.9GB
Qwen3.8-27B	MQ4-XTS	hipfire DFlash	RX 7900 XTX ×1	16K	256	C1	Cold	2758	5.95s	157.2	~17.6GB
Qwen3.8-27B	MQ4-XTS	hipfire DFlash	RX 7900 XTX ×1	32K	256	C1	Cold	2377	13.79s	134.6	~17.6GB
Qwen3.8-27B	MQ4-XTS	hipfire DFlash	RX 7900 XTX ×1	64K	256	C1	Cold	1913	34.27s	119.5	~17.7GB
Qwen3.8-27B	MQ4-XTS	hipfire DFlash	RX 7900 XTX ×1	128K	256	C1	Cold	1267	103.44s	67.9	~17.9GB
Qwen3.8-27B	MQ4-XTS	hipfire DFlash	RX 7900 XTX ×1	196K	256	C1	Cold	OOM	OOM	OOM	OOM

Highlights

8K：2682 tok/s Prefill + 169.4 tok/s Decode

32K：2377 tok/s Prefill + 134.6 tok/s Decode

64K：1913 tok/s Prefill + 119.5 tok/s Decode

8K DFlash 相对 AR：3.39×

高速甜点区：8K–64K

叠甲：本帖首先看的是推理引擎本身的 Cold Context 性能，不代表长期 Agent 的最终实际体验。实际 Agent 测试会另开一帖。

RX 7900 XTX DFlash Benchmark Infographic.png

一、测试环境

项目	设置
GPU	AMD Radeon RX 7900 XTX 24GB ×1
GPU Arch	gfx1100
模型	Qwen3.8-27B
Quant	MQ4-XTS
Engine	hipfire v0.4.2.1
KV Cache	Q8
VMM	Enabled
Speculative	DFlash
Output Length	256 tokens
Concurrency	C1
Cache	Cold / 无跨请求 Prefix Cache 命中
Warm-up	1
Formal Runs	3 / 档
结果	Formal median

注：同一 Context 档三条路线使用完全相同的 Prompt；表中 Actual Prompt 为 hipfire daemon 最终报告的 framed prompt_tokens。

二、DFlash 单卡完整结果

Context	Actual Prompt	Prefill	TTFT	Decode	τ¹	VRAM sampled peak
4K	4,107	3,025.5 tok/s	1.36 s	76.9 tok/s	6.00	约 17.5 GB
8K	8,173	2,681.9 tok/s	3.05 s	169.4 tok/s	8.80	约 17.9 GB
16K	16,405	2,757.9 tok/s	5.95 s	157.2 tok/s	8.80	约 17.6 GB
32K	32,770	2,376.8 tok/s	13.79 s	134.6 tok/s	8.80	约 17.6 GB
64K	65,553	1,912.7 tok/s	34.27 s	119.5 tok/s	11.25	约 17.7 GB
128K	131,066	1,267.1 tok/s	103.44 s	67.9 tok/s	8.80	约 17.9 GB
196K	196,627	OOM	OOM	OOM	N/A	N/A

¹ τ（tau）为官方hipfire daemon 报告的“每个 speculative cycle 平均接受的草稿 token 数”。数值越高，通常表示 speculative decoding 一次能连续接受更多草稿 token，但它 不等同于 acceptance rate，也不是 acceptance 百分比。

三、AR / MTP / DFlash 横向对比

为了看清 speculative decode 到底带来了多少提升，我同时测试了普通 AR 和 Native MTP K=8。

Decode

Context	AR Decode	MTP K=8 Decode	DFlash Decode
4K	50.2	51.5	76.9
8K	50.0	133.6	169.4
16K	48.9	144.6	157.2
32K	46.7	125.3	134.6
64K	43.1	87.8	119.5
128K	36.6	OOM	67.9
196K	32.3	OOM	OOM

Prefill

Context	AR Prefill	MTP K=8 Prefill	DFlash Prefill
4K	2,034.7	1,927.0	3,025.5
8K	2,252.6	2,124.3	2,681.9
16K	2,841.5	2,643.7	2,757.9
32K	2,429.4	2,197.8	2,376.8
64K	1,850.3	1,754.0	1,912.7
128K	1,250.8	OOM	1,267.1
196K	942.2	OOM	OOM

几个比较明显的现象：

AR 的基础 Decode 随 Context 增长下降得比较平缓；
MTP 在 128K 已经因为 VRAM OOM 无法完成；
DFlash 在 128K 仍然能维持 67.9 tok/s；
到 196K，MTP 和 DFlash 都在 Prefill 阶段 OOM，只有 AR 仍能运行；
DFlash 的优势最明显地集中在 8K–64K；
Prefill 并不是所有档位都由 DFlash 领先，16K 和 32K 的 AR Prefill 略高，但 DFlash 的整体 Decode 优势非常明显。

四、长上下文表现

从实测来看，我会把这套 DFlash 的高速甜点区暂时定在：

8K–64K

其中：

8K：169.4 tok/s
16K：157.2 tok/s
32K：134.6 tok/s
64K：119.5 tok/s

尤其是 64K，单卡 RX 7900 XTX 仍然可以做到：

1913 tok/s Prefill + 119.5 tok/s Decode

我认为这一点比单纯的 8K 峰值更有意义。

128K 仍然可以正常运行：

1267 tok/s Prefill + 67.9 tok/s Decode

不过从 64K 到 128K 已经出现明显掉速。

196K 下 DFlash 在 Prefill 阶段发生 HIP VRAM OOM，因此没有有效性能结果。本轮也没有通过降低 KV 精度、修改量化格式或源码来进一步压缩显存。实际生产环境里，可以把 Agent 的最大上下文限制在一个低于 OOM 边界的值；目前已确认 128K 可以正常运行，128K–196K 之间的具体安全上限后续还可以继续摸索，配合合理的 Context 压缩机制即可避免 Agent 撞上显存墙。

五、关于 τ、VRAM 和测试口径

这里特别说明几个口径问题。

1. τ 不是 Acceptance Rate

hipfire daemon 报告的 τ 是：

每个 speculative cycle 平均接受的草稿 Token 数

它不是 Acceptance 百分比。

当前 hipfire bench 汇总 JSON 没有提供 drafted / accepted 的原始总数，因此本文不推算 Acceptance Rate。

2. VRAM 是采样参考值

本文 VRAM 来自 hipfire daemon 遥测采样中的最大值。

它可以作为不同配置之间的参考，但：

不是独立高频显存监控得到的绝对峰值。

3. 测试是 Cold Context

这次主要测试模型和推理引擎本身的性能。

没有依赖 Radix Cache、Prefix Cache 或类似 KVMem 的跨请求上下文复用机制。

因此这些结果更接近：

一次新的真实 Prompt 送进模型后，Engine 本身能够做到什么速度。

这一点对后续 Agent 实测非常重要。

因为真实长期 Agent 场景下，除了 Prefill 和 Decode，本质上还要看：

Prefix reuse
Cache hit
多轮历史复用
Tool latency
整体任务 wall time

这也是我准备下一篇实际使用测试重点看的内容。

六、部署与启动参数

参见附件：
7900 XTX 的可能性探索单卡篇(五) 之部署与启动参数.md

七、最后的说明和一点个人感想

单张 RX 7900 XTX，在 hipfire 的专项优化下，Qwen3.8-27B 的跑分表现达到了我历次 7900 XTX 单卡测试中的新高度。

从 Benchmark 看，目前数字确实相当惊艳：

8K Decode 169.4 tok/s，64K 仍有 119.5 tok/s；8K Prefill 2682 tok/s。

不过 Benchmark 成绩当然不等于真实生产体验。

本帖首先测试的是 Cold Context 下推理引擎本身的性能。下一步我会把这套模型真正接入 Agent 工作流，再单独分享实际使用中的表现，包括：

Tool Calling
Coding / Debug
多轮任务
实际任务完成时间
长上下文下的响应体验
Prefix / Cache 缺失对实际 Agent 的影响（注：官方已经有 PR 在提升 Prefix/Cache）
与我目前另一套单卡 FN IQ3 Agent 方案进行 A/B 对比

到时候再继续更新。

个人一点感想

先看看 RX 7900 XTX 和 RTX 3090 的硬件底子：

规格	RX 7900 XTX	RTX 3090
架构	RDNA 3 / Navi 31	Ampere / GA102
显存	24GB GDDR6	24GB GDDR6X
显存位宽	384-bit	384-bit
显存带宽	960 GB/s	936 GB/s
FP32	约 61.4 TFLOPS	约 35.6 TFLOPS
PCIe	PCIe 4.0 ×16	PCIe 4.0 ×16
TBP / TGP	355W	350W
AI 软件生态	ROCm / HIP	CUDA

两张卡都有 24GB 显存、384-bit 总线、接近 1TB/s 的显存带宽，功耗也处于同一级别。

7900 XTX 的硬件规格本身一直不弱。过去在本地 AI 推理上的主要差距，更多来自 CUDA、Tensor Core，以及 NVIDIA 阵营长期积累的 AI kernel 和软件生态。

所以这次 hipfire 最让我欣慰的地方，是：

终于开始有软件真正把 RDNA3 本身的硬件潜力往 AI 推理方向挖出来。

Newegg 当前新卡价格参考

GPU	Newegg 当前可见价格	备注
RX 7900 XTX 24GB	约 $1,399–$1,499	新卡
RTX 3090 24GB	约 $2,099–$2,399	多为老库存 / 第三方卖家

这里比较的是 当前 Newegg 新卡挂牌价，不能代表二手市场。

3090 有 NVLink 和成熟 CUDA 生态的天然优势；7900 XTX 则胜在仍有新卡保修、24GB 显存，以及相对更低的新卡价格。

而随着 Strata 的应运而生，以及 hipfire 这类面向 RDNA3 的专项优化逐渐成熟，7900 XTX 的 24GB 显存、接近 1TB/s 的显存带宽，也终于开始越来越充分地转化为实际的本地 AI 推理性能。

这也是我持续更新这个“7900 XTX 的可能性探索”系列的动力之一：把自己的折腾和测试结果分享出来，回报论坛和社区，也顺便看看这张卡的潜力究竟还能被挖到哪里。

无它，不是哥们买不起( ），而是折腾7900 XTX 更有性价比。

Ben Lee

先感谢 KVMem 的作者和贡献者

首先一定要特别感谢 KVMem 项目的作者和贡献者。

KVMem 是一个很有意思的长上下文 KV 管理方案，由 Di Chai、Leye Wang、Zeshen Su、Zhiguo Xia、Zhihang Yu 等作者开发。

项目地址：

https://github.com/kvmem/kvmem-llama.cpp

作者相关 Bilibili 介绍视频：

https://www.bilibili.com/video/BV1r2ey6EEh5/

也感谢作者把这套方案和实现公开出来，给消费级显卡探索超长上下文提供了一个很有价值的方向。

1. 为什么我又来折腾 KVMem

最近本地推理的新技术和新玩法层出不穷，我自己最感兴趣的几个方向里，就包括 NInfer、KVMem 和 JEV。

之前我已经在 NVIDIA 显卡上测试过 KVMem，对这个方案一直很感兴趣。前两天突然看到项目开始支持 AMD / ROCm，我一下又来劲了，于是连续肝了两天，把单卡 7900 XTX 下的适配、排错和长上下文测试基本完整跑了一遍。

下面就是这轮测试的阶段性结果。

2. KVMem 到底解决什么问题？

传统 Full-KV 的问题很直接：

Context 越长，KV Cache 占用的显存越大。

消费级显卡即使模型权重能放进去，Context 继续往上拉以后，最后很容易撞到显存墙。

KVMem 的思路不是要求整个超长历史的 KV 全部长期驻留在 GPU。

简单理解：

GPU 只维持一个有限大小的 active KV working set
更大的历史状态放到 Host RAM
需要时再进行 retrieval / restore
因此逻辑 Context 可以远远超过传统 Full-KV 能容纳的范围

所以它解决的核心问题不是：

“怎么让模型本身变快”

而是：

“怎么用有限的 GPU 显存，维持远大于显存容量本身能承载的上下文。”

众所周知，7900XTX先生威猛但是显存略短，对于24GB的它来说，这个方向非常有吸引力。

3. 测试环境、部署方法和参数

硬件与环境

项目	配置
GPU	AMD Radeon RX 7900 XTX 24GB
GPU 数量	1
CPU	AMD Ryzen 5 9600X
主板	GIGABYTE B850 AI TOP AMD AM5 ATX
系统内存	64GB DDR5
PCIe	PCIe 4.0 x8（主机安装双卡，本篇仅使用 GPU0 单卡）
OS	Linux
ROCm	7.2.3
Backend	llama.cpp HIP
Model	Qwen3.8-27B Q4_K_M
GPU offload	Full GPU offload
Flash Attention	ON
KV	`q8_0`
KVMem budget	32K
MTP	模型自带 nextn head
GPU arch	gfx1100

KVMem 版本

这轮测试使用的是 KVMem 官方 AMD / ROCm Beta 分支：

rc3-rocm-beta2

项目地址：

https://github.com/kvmem/kvmem-llama.cpp

我没有直接使用通用多架构 build，而是在本机针对 gfx1100 重新编译。

主要编译方向：

HIP / ROCm
gfx1100 only
Native build
Ninja 并行编译
针对 RX 7900 XTX 使用本地优化参数

本轮测试使用的主要编译参数包括：

GGML_NATIVE=ON

GGML_OPENMP=ON

以及：

CMAKE_HIP_FLAGS="-mllvm --amdgpu-unroll-threshold-local=600"

这样做的目的很简单：

尽量减少和本机 RX 7900 XTX 无关的通用架构开销，把测试环境固定在 gfx1100。

推理参数

本轮长上下文测试统一使用：

参数	设置
GPU	单张 RX 7900 XTX
Model	Qwen3.8-27B Q4_K_M
KV	`q8_0`
KVMem budget	`32768`
Flash Attention	ON
Batch	`2048`
UBatch	`512`
Threads	`6`
Output cap	`512 tokens`
MTP	OFF / ON 两组
Context	128K / 256K / 512K

这里的 32768 不是最大 Context。

它表示：

GPU 侧 KVMem active working set 的预算约为 32K。

真正测试的逻辑 Context 分别为：

128K
256K
512K

也就是说，512K 测试并不是让 512K KV 全部常驻显存，而是：

用约 32K 的 GPU active KV budget，配合 Host RAM 中更大的历史状态，通过 retrieval / restore 机制维持 512K 逻辑 Context。

为什么 KV 继续使用 q8_0

上一篇传统 Full-KV 测试里，我已经对 q8_0 和 q4_0 KV 做过对比。

在我的机器和这套模型上，两者对 Prefill 性能影响很小。

因此这篇为了减少变量，继续统一使用：

q8_0 KV

不再同时展开 q4 KV 测试。

测试口径

所有 Context 档位都使用实际 tokenizer token 数，不使用字符数估算。

标称 Context	Actual Prompt
128K	130,942
256K	261,875
512K	523,744

测试要求不是单纯：

“服务能启动”
“ctx-size 能设置成功”
“模型没有立刻 OOM”

而是必须完成：

完整 Prompt Prefill → 正常进入 Decode → 正常输出

下面直接看完整测试结果。

4. 长上下文完整测试结果

Context	Actual Prompt	MTP	Prefill	Decode	TTFT	Acceptance
128K	130,942	OFF	557.63 tok/s	26.98 tok/s	235 s	—
128K	130,942	ON	533.94 tok/s	36.59 tok/s	246 s	50.8%
256K	261,875	OFF	532.61 tok/s	26.94 tok/s	493 s	—
256K	261,875	ON	511.73 tok/s	36.38 tok/s	513 s	50.0%
512K	523,744	OFF	520.34 tok/s	26.85 tok/s	1009 s	—
512K	523,744	ON	500.34 tok/s	39.81 tok/s	1049 s	58.4%

其中 512K 档实际完成：

523,744-token Prompt → 完整 Prefill → 正常进入 Decode

这里不是单纯把 ctx-size 设置成 512K，也不是只完成模型加载，而是真正把超过 52 万 token 的 Prompt 完整跑完并正常生成。

测试结果图

ChatGPT Image Sep 27, 2026, 01_05_42 AM.png

从表格和图里已经可以比较直观看到：

Context 从 128K 一路增加到 512K 后，Prefill throughput 仍然保持在较高水平；
MTP OFF 的 Decode 基本稳定在约 27 tok/s；
MTP ON 后，Decode 提升到约 36～40 tok/s；
512K 实际 Prompt 达到 523,744 tokens，整轮测试正常完成。

后面不再重复展开 Prefill 曲线，重点看 KVMem 真正带来的几个实际变化。

5. VRAM 与 Host RAM：24GB 为什么能跑到 512K

这其实是我认为 KVMem 最核心的价值。

在 128K / 256K / 512K 的测试过程中，VRAM Peak 基本维持在：

约 18.2～19.5 GiB

Context	VRAM Peak
128K	约 18～19 GiB
256K	约 18～19 GiB
512K	约 19 GiB

逻辑 Context 从 128K 增长到 512K，GPU 显存并没有跟着线性增加。

上一篇同一个 Qwen3.8-27B Q4_K_M、q8_0 KV 的传统 Full-KV 测试中，128K 实际 Prompt 为 130,941 tokens：

MTP OFF VRAM Peak：21,168 MiB
MTP ON VRAM Peak：23,008 MiB

也就是说，在传统 Full-KV 下，128K 已经开始明显逼近 24GB 显存上限。

而 KVMem 并不是把这些 KV “变没了”。

更准确地说，它是在做一种资源交换：

减少 GPU VRAM 中长期驻留的 KV，用 Host RAM 承载更大的历史状态。

GPU 侧只维持有限的 active KV working set，需要时再进行 retrieval / restore。

因此：

更少的 VRAM 压力更多的 Host RAM 使用

这台测试机一共只有 64GB DDR5 系统内存。

所以随着逻辑 Context 继续扩大，GPU VRAM 不再是唯一的容量边界，Host RAM 也会逐渐成为新的限制因素。

这里需要特别说明：

这次测试停在 512K，不代表 KVMem 的最大能力就是 512K。

我没有继续把正式测试推到 1M，主要有两个原因：

512K 已经足够验证单张 24GB RX 7900 XTX 上 KVMem 的长上下文扩展能力；
继续向 1M 推进会进一步增加 Host RAM 和整机资源压力，而这台测试机只有 64GB 系统内存，继续追求最大 Context 已经偏离本轮测试重点。

本文能够严谨确认的是：

这套配置实际完整验证到了 523,744-token Prompt。

至于 1M 或更高，本轮没有完整验证，因此不做结论。

所以 KVMem 解决的首先是：

Context Capacity。

它不是把 24GB 显存“变成了 48GB”，也不是把 50 万 token 的计算成本变没。

它改变的是：

“全部历史 KV 必须长期驻留在 GPU 显存里”这个前提。

6. KVMem Budget 到底控制什么？

这一点我觉得有必要单独讲。

本文性能测试统一使用：

KVMem budget = 32768

这里的 32768 并不是最大 Context，而是 GPU 侧允许保留的 active KV working set 大小。

简单理解：

Budget 越大，GPU 里同时保留的 KV 越多；Budget 越小，就越依赖 Host RAM 和 retrieval / restore。

所以 KVMem budget 本质上控制的是一个资源平衡：

KVMem Budget	GPU VRAM	Retrieval 依赖	Recall 潜力
较小	更低	更高	极端场景更容易出现 miss
较大	更高	更低	通常更有利于 Recall

这也是为什么：

KVMem budget = 32768

并不意味着只能跑 32K Context。

本轮测试里，GPU active KV budget 固定在约 32K，但实际逻辑 Context 分别跑到了：

128K
256K
512K

也就是说：

Context 可以继续增长，但 GPU 侧 active KV 的预算基本保持固定。

超出 active budget 的历史状态更多地由 Host RAM 承担，需要时再通过 retrieval / restore 重新带回。

为什么这篇统一使用 32K Budget？

这轮测试的目的不是找“最大 Recall”，而是想回答一个更直接的问题：

如果把 GPU 侧 active KV 固定在一个比较小的范围内，单张 24GB RX 7900 XTX 到底能把逻辑 Context 推多远？

所以我统一使用：

32768

最终实测：

32K active KV budget → 523,744-token Prompt 完整跑通

同时 GPU VRAM Peak 基本仍维持在约：

18.2～19.5 GiB

这正是 KVMem 最有意思的地方之一。

Budget 不是越小越好

Budget 越小，确实越省 GPU KV 空间，也更有利于把逻辑 Context 往上推。

但代价也很明确：

更依赖 retrieval。

而 retrieval 越频繁、active working set 越小，在极端长上下文场景下，就越有可能暴露 Recall 边界。

我们之前的测试也已经观察到：

提高 active KV budget 后，极端 needle Recall 会改善。

所以实际部署时不能只追求最小 budget。

更合理的选择是根据用途做平衡：

追求最大 Context / 节省 VRAM：budget 可以偏小
更重视 Recall：budget 可以适当增大
系统内存有限：还要同时考虑 Host RAM 压力

最终实际上是在四个变量之间找平衡：

VRAM / Host RAM / Context Capacity / Recall Quality

所以 KVMem 的真正玩法，并不是单纯问：

“最大能跑多少 K？”

而是：

“在我能接受的显存和内存占用下，需要多大的 active KV budget，才能获得足够可靠的 Recall？”

7. MTP：可以和 KVMem 叠加，但要看实际 E2E

KVMem 和 MTP 可以正常一起使用。

Decode 实测：

Context	MTP OFF	MTP ON	Decode 提升
128K	26.98 tok/s	36.59 tok/s	+35.6%
256K	26.94 tok/s	36.38 tok/s	+35.0%
512K	26.85 tok/s	39.81 tok/s	+48.3%

512K 下：

26.85 → 39.81 tok/s

Decode 提升还是很明显的。

不过超长 Context 下有一个需要特别注意的问题：

不能只看 Decode。

512K 时：

MTP OFF

TTFT：约 1009 s
Decode：26.85 tok/s

MTP ON

TTFT：约 1049 s
Decode：39.81 tok/s

MTP ON 的 TTFT 增加了大约 40 秒。

而这轮测试的输出上限只有 512 tokens。

所以在这种：

超长 Prompt + 短输出

的场景里，虽然 MTP 明显提高了 Decode，但节省下来的生成时间还不足以覆盖前面增加的 TTFT 成本。

本轮 512K 测试中：

MTP ON 的 E2E 反而慢约 34 秒。

按照当前实测速度粗略计算，512K 这一档大概要输出：

约 3,320 tokens

MTP 才可能开始进入 E2E 正收益区间。

这里特别说明：

3,320 tokens 是根据当前实测速度推算出的 break-even，不是已经完成的实测点。

所以我目前对两者的理解很简单：

KVMem 主要解决容量。

MTP 主要解决生成速度。

两者可以叠加，但 MTP 到底值不值得开，需要结合 Prompt 长度和最终输出长度来看。

8. Retrieval：还有一点瑕疵，但整体已经可用

除了性能和显存，我也专门做了超长上下文 Recall 测试。

测试方法比较简单：

在超过 52 万 token 的长文本里，人工埋入 20 个彼此独立的 needle；
needle 大多是随机编号、数字或者孤立事实，本身几乎没有语义关联；
然后在超长上下文末尾逐个提问；
最后检查 20 个事实能不能准确找回来。

这其实是一个故意把 Retrieval 推向极端的 needle-in-a-haystack 测试：

信息只出现一次、距离非常远、语义线索很弱，然后要求在 50 多万 token 后精确找回。

我此前用同类 Recall 方法测试的结果：

SGLang：100%
NInfer：100%
KVMem：18 / 20，90%

所以 KVMem 目前还不能说完全无损，确实还有少量 retrieval miss。

不过我不会把这个 90% 理解成：

“日常使用有 10% 概率出错。”

这种测试本身就是人为构造出来放大 Retrieval 边界的极端场景。

正常 Agent、多轮对话、代码分析和长文档处理中，重要信息通常会有更多语义关联、上下文线索和重复引用，与这种“几十万 token 前只出现一次随机数字，然后最后精确追问”的情况并不完全相同。

所以我的阶段性评价是：

和 SGLang、NInfer 的 100% Recall 相比，KVMem 目前还有一点瑕疵；但考虑到它已经能在 24GB RX 7900 XTX 上把 Context 推到 512K，我认为整体已经可用，瑕不掩瑜。

9. 长上下文真正带来的好处是什么？

把 Context 从 128K 推到 256K、512K，真正有价值的地方并不是“数字更大”。

对实际 Agent 和长 Session 来说，更重要的是：

更多历史可以继续留在可访问范围内，而不用那么早就做 Context Compression、截断旧消息或者丢弃前面的工作状态。

这一点和我之前测试 SGLang HiCache、NInfer Prefix Cache 时感受到的价值有一些相似，但三者的机制并不一样。

SGLang HiCache / NInfer Prefix Cache 更偏向：已经计算过的 KV 尽量复用，Cache 命中后可以减少重复 Prefill；
KVMem 更偏向：让远大于 GPU active KV budget 的历史状态仍然可以被保存，并在需要时 retrieval / restore。

所以不能简单把 KVMem 等同于 SGLang HiCache 或 NInfer Prefix Cache。

但对于长期运行的 Agent，它们最终都在改善同一个现实问题：

不要因为 Context 很快装满，就频繁压缩、截断或者丢掉已经积累的工作历史。

比如一个 Agent 已经连续工作了几个小时，前面累计了：

大量对话历史
工具调用结果
日志
文档内容
中间分析
已经做过的决策

传统 Context 不够时，就不得不开始：

压缩历史
删除较早内容
重新总结
重新构造工作上下文

这些操作不仅增加管理成本，也可能造成信息损失。

而更大的可用 Context，配合 KVMem 这类 KV 管理机制，可以让 Agent 更长时间保持连续工作状态。

所以对我来说，512K 的意义并不只是：

“能塞进去 52 万 token。”

更重要的是：

让一个长 Session 能保留更多已经发生过的事情，晚一点再被迫压缩和截断。

这才是超长 Context 在实际使用里的价值。

10. 512K 和 Qwen3.8-27B 原生 256K Context 到底是什么关系？

这里需要单独解释一下，不然很容易把两个概念混在一起。

Qwen3.8-27B 的原生 Context Length 是：

262,144 tokens，也就是约 256K。

而本文测试的：

512K / 523,744 tokens

首先证明的是另外一件事情：

KVMem 可以让 24GB RX 7900 XTX 在运行时承载并处理超过 52 万 token 的逻辑历史，而不会因为传统 Full-KV 的显存需求直接 OOM。

也就是说，KVMem 主要解决的是：

KV Capacity

它解决的是：

这么长的历史能不能装得下、能不能继续运行。

512K 是总 Context，不是额外再加 512K

这里还有一个很容易误解的地方。

本文说的：

512K Context

指的是整个当前逻辑上下文的总长度约为 512K。

不是：

模型原生 256K + KVMem 再额外增加 512K

所以不存在：

256K + 512K = 768K

这样的关系。

更准确地理解：

概念	长度
Qwen3.8-27B 原生 Context	约 256K
本文 KVMem 测试的总逻辑 Context	约 512K
512K 档实际 Prompt	523,744 tokens

其中超过原生 256K 的部分，已经进入模型的长上下文扩展区域。

所以：

512K 能跑，不等于模型原生 Context 变成了 512K。

超过模型原生 256K 后，还可能涉及模型本身的长上下文扩展机制和外推质量，例如：

RoPE Scaling
YaRN
超出原生训练长度后的 Recall / Reasoning Quality
长距离信息关联能力

因此需要把两个问题分开看：

问题	KVMem 能解决吗？
24GB 显存能不能承载 512K 逻辑历史	可以，本文已实测
Full-KV 会不会因为 512K 直接把 VRAM 撑爆	KVMem 主要解决这个问题
模型原生 Context 是否因此变成 512K	不是
模型在 512K 下质量是否和原生 256K 一样	不能仅靠 KVMem 保证
512K 下 Recall 是否可靠	需要实际测试，本文已做初步验证

所以从工程角度看：

KVMem 负责解决“装不装得下、跑不跑得起来”。

而模型本身的 Context Extension、RoPE Scaling 和长上下文能力负责回答：

“跑到这么长以后，还能不能答得准。”

这也是为什么前面我没有因为“512K 跑通”就直接宣布“512K 完全无损”，而是另外做了 Recall 测试。

所以本文里的 512K，最准确的理解应该是：

在 KVMem 帮助下，在我的机器上（64G系统内存），24GB RX 7900 XTX 已经具备承载约 512K 总逻辑 Context 的能力；但超过模型原生 256K 之后的最终质量，还要结合模型本身的长上下文扩展能力和实际 Recall 测试一起判断。

11. 一句话总结

这个 KVMem 是我最近做的一大堆乱七八糟测试中，唯一让我产生爽感的好东西。

跑到 512K 以后，依然还能保持：

Prefill：520.34 tok/s
Decode：26.85 tok/s
VRAM：约 18～19.5 GiB

逻辑 Context 从 128K 增长到 512K，扩大了 4 倍，而 Decode 基本没有变化。

对于一张只有 24GB VRAM 的 RX 7900 XTX 来说，这已经把可用的 Context 空间向前推了很大一步。

24GB 显存，512K Context，能跑、能用，而且速度还没有塌，真牛。

这就是我这两天折腾 KVMem 以后最直观的感受。

Ben Lee

@terry @flyer666 @farmer-node 各位大佬

好消息：PR #34058 实测有效，`N=1` 基本解决 long-prefill starvation

https://github.com/sgl-project/sglang/pull/34058

前面说周末准备测一下，结果没忍住，上班摸鱼已经全部跑完了

测试环境还是 双 7900 XTX + SGLang gfx1100 + TP2 + MTP3 + BF16 KV，严格 C2（双并发）：

模拟 A 64K 已经在 decode → 5 秒后 B 加入 64K fresh prefill。

--max-consecutive-prefill-batches 实测结果：

N	A 最大断流	B 64K TTFT
0（原版）	47.23s	49.43s
1	4.04s	49.48s
2	7.70s	49.21s
3	11.70s	49.05s
4	13.80s	49.37s
8	25.76s	49.24s
16	47.05s	49.24s

最关键的是：

N=1：47.2s → 4.04s，断流下降 91.4%
B 的 TTFT 和 prefill throughput 基本完全没损失
（说人话就是：双 7900 XTX 这套配置，第二个对话B的64K fresh prefill 本来就是要大约 49 秒才能出第一个 token，这是7900XTX规格上限决定的；加了新参数后，这个 49 秒几乎没变，但 A 不再陪着 B 一起“饿死”，N=1的情况下，B的性能没有损失）
N 越大，越逐渐退回原来的 prefill-first
N=16 已经几乎等于 N=0

所以这个参数本质上就是一个 prefill / decode fairness 旋钮。在我的 workload 下，N=1 是明显甜点位。

C3（三并发）也补测了：原来 A/B 最大断流 67.7s / 18.5s，N=1 后变成 4.11s / 3.03s，三路正常跑，没有再出现几十秒冻结。

理论上讲，这下终于有点真正 1+1>2 的味道了。但是我周末还是要模拟实际操作再仔细测试一遍。

顺便把 ROCm 版本也重新测了一遍

这次统一使用 PR #34058 + N=1，所以 C2/C3（双并发 / 三并发）不再被原来的 starvation 干扰。

测试上下文大致是：

C1：约 64K / 65.5K tokens
C2：A ~65.5K + B ~65.5K fresh
C3：A ~65.5K + B ~65.5K + C 32.7K fresh

指标	ROCm 7.2.3	ROCm 7.14	ROCm 10
C1 64K prefill	1338 tok/s	1351	1146
C2 prefill	1343	1358	1156
C3 prefill	1331	1349	1155
C2 B TTFT	49.78s	49.23s	57.35s
C3 C TTFT	65.99s	64.85s	75.33s
C2 A max gap	4.07s	4.04s	4.95s
C1 decode	62.2 tok/s	66.4	74.1

注：以上C1 decode 单并发的推理速度是在64K长上下文条件下测得，对于7900XTX来说已经是相当能打了。

说下初步结论：

SGLang这个新参数：实测有效，改善明显。
ROCm 7.14：整体比 7.2.3 略快，尤其 decode +6.8%，我准备把我的生产环境搬迁到这个版本。
ROCm 10：decode 非常猛，+19%；但 64K cold prefill 慢约 13–14%，TTFT 也多约 14–15%。

所以 ROCm 10 是很典型的decode benchmark 更快，但 long-context Agent 反而更慢。 但是毕竟ROCm10 才刚发布不到一个月，未来可期，持续关注中。

目前我的生产还是 ROCm 7.2.3 + PR #34058 + N=1。下一步准备升级到7.14再直接跑真实 2 个高频 + 2 个偶发 Agent，看看长期体感。

这次最大的好消息就是：

之前 SGLang 那个“新 long prefill 一进来，其他 Agent 全冻几十秒”的问题，至少在我的机器上的理论测试已经从 47 秒压到约 4 秒了。多并发实战体验待我测完在做进一步汇报

Ben Lee

@flyer666 谢谢回复和指导。您这个思路很有道理，我这边同时跑着两个 Hermes 本地 AI Agent基本都是发散性任务，所以 fresh prefill 确实很多。

关于您的第一点建议：

我这边实测下来，感觉不只是 7900 XTX 的算力瓶颈。测试时先让 A 完成 64K prefill 并进入正常 decode，单路大约 80 tok/s。5 秒后再让 B 加入一个 64K fresh prefill，结果 A 会连续 47.2 秒完全没有 token 输出，也就是从约 80 tok/s 直接掉到 0，等 B 的 prefill 结束后才恢复正常.

这其实已经意味着，在我的实际 workload 下，长上下文双并发基本失败了：两路虽然都处于 running 状态，但第二路一做长 prefill，第一路几乎被冻结。更关键的是，当时 waiting=0，KV 使用率还不到 50%。后面我又分别关了 MTP、ROCm 7.2→10、chunk 4096→2048，结果 A 还是会停 45–54 秒，所以我更倾向这是 SGLang 的 long prefill / decode starvation，而不只是单纯算力不够。

关于您的第二点建议：

KV 我后来也调到了 265,950 tokens，C3 峰值才 62%，所以这次看起来也不像是 radix eviction。HiCache 我在5090 128G内存的另一台机器上上试过确实好用，但这台机器只有64G，而且还分了一半跑虚拟机，内存不够了，后面有机会加内存了我再试试。

我的部署基本完全让DSF按照您的帖子和推荐指南来的，但是我自己其实是个纯小白，所以现在也不敢百分之百确定是不是我这边某个配置还有问题。不过至少 SGLang 跑短上下文是真的香。刚开始测试的时候，会话很快，堪比DeepSeek Flash，四路并发也非常丝滑，所以一开始我其实挺惊喜的。只是上下文一长，特别是出现 fresh prefill 以后，实际体验就完全变了。我最近这一两个月学习到的东西比过去一年还多，CUDA，oneAPI，Level Zero，SYCL，OpenVINO，RCOm，Vulkan，llama.cpp, vLLM，SGLang这些遥远的名词居然也都亲自实践测试体验过了，在这个论坛真是大有收获了。

再次感谢大神的分享和热心回复。以后还要继续抱大神大腿，少走弯路！

Ben Lee

@flyer666 顶礼膜拜flyer666 大神，上次看了您 8/23 发的帖子《双卡 7900 XTX VLLM 跑 Qwen3.8，爽玩 Agent，PP1600 / TG160+（附 MTP / 7900 XTX 全攻略）》之后，我也照着折腾了一套双卡部署。

从之前单卡 llama.cpp Vulkan，到现在双 7900 XTX TP2，体感真的是“一步登天”。不光速度上去了，并发、长上下文、Agent 实际使用体验也完全不是一个级别，确实让我第一次很直观地体会到 1+1 > 2 的感觉。

听老特周末的视频，马上搜到了这个帖子，花了三天时间狠狠折腾了一轮 SGLang，短 benchmark 一度非常惊艳，但真实多 Agent 长上下文用下来踩了一个挺大的坑，也顺手做了一轮比较完整的排查，想把结果发出来给大家参考，也希望有高人能够指点一二。

SGLang 的短 benchmark 确实非常漂亮，C4 aggregate decode 能跑到 200 tok/s 左右，一开始我还挺满意。

但真正拿去跑 Hermes / 多 Agent 以后，体验完全不是一回事：一个长上下文请求开始 prefill，另外一个正在回复的 Agent 会直接“冻住”几十秒。反复优化排查，甚至尝试了最新的RCOM10，问题依旧，表现就是一开始三并发甚至四并发都是飞一般的速度，堪比DSF，但是对话和跑任务几轮后就体会到了明显的卡顿，甚至所有的并发全部卡死（假死，后台排队但是token速度降到10几甚至个位数）。

我后来折腾ChatGPT和DeepSeek做了一系列测试，ChatGPT告诉我基本把问题钉死了。所以目前我的选择很简单：生产切回前一个帖子介绍的vLLM，目前是Int8 KV 192K上下文三并发，设置65%的压缩阈值，可以做到两个并发跑满，另外一个并发用作本地识图（小上下文）。为什么不用Int4 KV？是因为开满三并发或者四并发的速度体验下降太大，而且测下来Int8反而是速度上的甜点，反正我两个本地推理+1个本地识图服务足够了。

说回到SGLang我踩得坑，我的环境大概是：

2× RX 7900 XTX，TP2
Qwen3.8-27B W4A16 GPTQ
SGLang gfx1100 fork
BF16 KV
192K context
MTP3 / EAGLE
FCFS scheduler
chunked prefill 4096

最典型的一组测试

先让 A：64K prefill → 开始正常 decode

等 5 秒，再让 B 加入：64K prefill

结果：

A 最大无 token gap：47.226 秒
B TTFT：49.434 秒
A 的停顿覆盖了 B prefill 时间的 95.5%
waiting=0
KV peak 只有 49.76%

也就是说：

不是 KV 不够，也不是请求排队。B 在做 64K prefill 的时候，A 基本整整 47 秒不吐一个 token。

这就完全解释了为什么 benchmark 看着很猛，实际多 Agent 用起来却很“卡”。

三并发更明显：

A 最大停顿：67.736 秒
B 已经开始回复后又停了：18.468 秒
C TTFT：64.945 秒
KV peak 也才 62.22%

所以这不是“显存撑爆了”的问题。

我又把几个最可能的原因逐个排了一遍

MTP？

关掉 MTP/EAGLE，其他不动：

MTP3：A gap 47.226s
MTP OFF：A gap 45.051s

只改善大约 4.6%。

所以 MTP 不是主因。

chunk 太大？

把：

4096 → 2048

结果：

4096：47.226s
2048：48.913s

基本没区别。

ROCm 版本？

这个我也折腾得比较彻底，7.2、7.14、ROCm 10 nightly 都实际跑过。

短 benchmark 里 ROCm 10 hot run 有时候确实快一点，之前 C4 decode 大约能看到几个百分点的优势；7.14 没表现出什么特别明显的好处。

但放到真正有问题的 long-context workload：

ROCm 7.2：A gap 47.226s
ROCm 10 nightly：A gap 54.234s

ROCm 10 这次反而更慢，因为 64K prefill 本身更慢，结果 A 被“冻住”的时间也跟着变长。

所以至少在我这套环境里：

升级 ROCm 并不能解决这个问题。

它可能改变 prefill/kernel 的原始速度，但没有改变“prefill 期间 concurrent decode 被饿死”这个行为。

网上也有一些很接近的 SGLang issue

我后来查了一圈，发现这个方向并不是完全没人碰到。

比较值得看的有：

SGLang #32549：持续 chunked prefill 时出现 decode starvation，和我的现象最接近。
Discussion #27762：讨论新 prefill 如何严重影响正在运行的 decode，以及如何优先保护 decode。
#35537：chunked-prefill scheduler 里也出现过 starvation / waiting request 长时间得不到调度的问题。
#34676：Hybrid/Mamba 模型的 prefill/cache/scheduler 路径也有相关问题。
#38319：Qwen3.8 + chunked prefill + Radix Cache 还有另外的 race/cache 问题。

这些 issue 不一定和我这个 47 秒 stall 是完全同一个 bug，但至少说明 SGLang 最近这一块 scheduler / chunked-prefill / hybrid model 的路径确实还有不少边角问题。

我最后的结论：

我现在比较确定的一点是：短 PP + C4 aggregate tok/s，不能代表真实多 Agent 体验。

以前我测：

PP≈2K
C4

数字非常好看。和帖子里的数值基本一致。

但现实是：

A 已经在长上下文里回复
+
B 突然带着 64K/100K 历史进来，然后两边卡几分钟。。。

这才是 Agent 的真实 workload。

所以以后我测 serving engine，一定会加这一条：

A: 64K → 开始 decode
5 秒后
B: 64K prefill

然后看：A max no-token gap

我的 SGLang 现在实测的结果是：47 秒。就是说我的B会话要等将近一分钟。这还只是64K，大家都知道Hermes启动阶段可能就不止这个数量级了，何况是几轮后上下文滚动到100K+。

所以这一轮的学习，就是这个实测数字对我来说，已经比“C4 200 tok/s”实用得多了。

罗嗦一大圈，最后总结一下：

之前 vLLM 已经连续用了两个星期，和云端大模型搭配着用，整体效果其实已经非常满意了。同样是多 Agent、长上下文的使用方式，vLLM 基本没有出现过这种“一个长 prefill 一进来，另外一路直接冻住几十秒”的情况，日常体感明显更顺。

这段时间在论坛里跟老特和各位高手确实学到了太多东西。7900XTX就是给老特给安利买的。R9700我嫌声音太吵让我给退了然后价格猛涨后悔不迭，然后最近学到单卡 Vulkan 能把本地模型更顺滑得在7900XTX上跑起来，我就已经喜出望外了；看了flyer666大神的帖子马上又买了一张7900XTX组双卡折腾 vLLM、TP2、MTP、长上下文和多并发，才发现这张2022年发布的AMD显卡居然还能玩得这么溜，性价比拉满。

大家可能都比我先知道，SGLang 对 RDNA3 一直算是个“黑洞”，坑不少、但是诱惑大，潜力也摆在那儿。我这次折腾完最大的感受就是：既然现在 vLLM 已经能把双 7900 XTX 跑到这个程度，而且实际 Agent 体验也够稳，确实有点“还要什么自行车”的意思了，先把vLLM用好了，坐等科技日新月异。

备注：不会排版，不知不觉罗列了这么长，卡到这儿的兄弟们您受累了。

附：硬件环境

CPU：AMD AM5 平台
主板：GIGABYTE B850 AI TOP
GPU：2 × Radeon RX 7900 XTX 24GB
PCIe：CPU 直连 x8/x8
系统内存 64GB
PSU：1200W
系统：Ubuntu 24.04
ROCm 主力版本：7.2.3   另外测试过：ROCm 7.14 / ROCm 10 nightly

模型
Qwen3.8-27B GPTQ / W4A16
TP2 双卡
context：196608 tokens（192K）
thinking：关闭
主要用途：Hermes / 多 Agent / tool calling / 长上下文并发

=========================================
SGLang 参数

模型：

--model-path /data/models/Qwen3.8-27B-W4A16-AutoRound-GPTQ
--served-model-name SGLang-27B

核心参数：

--tp-size 2
--quantization gptq
--dtype bfloat16
--mamba-ssm-dtype bfloat16

--kv-cache-dtype auto
--context-length 196608
--mem-fraction-static 0.94

--max-running-requests 4
--max-mamba-cache-size 20

--attention-backend triton

--speculative-algorithm EAGLE
--speculative-draft-model-path /data/models/Qwen3.8-27B-W4A16-AutoRound-GPTQ
--speculative-num-steps 3
--speculative-eagle-topk 1
--speculative-num-draft-tokens 4

--cuda-graph-bs-decode 1 2 4
--triton-attention-num-kv-splits 16

--reasoning-parser qwen3
--tool-call-parser qwen3_coder
--default-chat-template-kwargs '{"enable_thinking": false}'

--sleep-on-idle
--trust-remote-code

--host 0.0.0.0
--port 8082

当前实际：

KV dtype: BF16
KV pool: 265,950 tokens
max running: 4
context: 192K
MTP3

scheduler 相关：

schedule_policy = fcfs
chunked_prefill_size = 4096
priority scheduling = off

=============================================

vLLM 参数

模型：

--model /data/models/Qwen3.8-27B-Uncensored-GPTQ-MTP
--served-model-name vLLM-27B

核心参数：

--tensor-parallel-size 2

--max-model-len 196608

--kv-cache-dtype int8_per_token_head

--max-num-seqs 128
--gpu-memory-utilization 0.95

--max-cudagraph-capture-size 128

--enable-auto-tool-choice
--tool-call-parser step3p5
--reasoning-parser qwen3

MTP：

method: qwen3_5_mtp
num_speculative_tokens: 3

其他：

attention backend: TRITON_ATTN
thinking: false
TP2
INT8 KV
192K context

SGLang 我还是会保留，毕竟 gfx1100 这版性能潜力确实很好。等以后 scheduler / chunked-prefill 这块有更新，我再拿这套 64K + 64K staggered test 回来复测。

Ben Lee

7900 XTX 的可能性探索｜单卡篇（四）：魔法打败魔法

Qwen3.8 Flash-Next：Strata 引擎快得让我怀疑人生

️ 本文全部为我自己机器上的实测。

硬件：RX 7900 XTX 24GB + Ryzen 5 9600X + 64GB DDR5
系统：Ubuntu 24.04.4 / ROCm 7.2.3

本文后半部分会同时列出 llama.cpp、MoE4All infr 和 Strata 三套结果，但三套使用的量化不同，不能把绝对数字当成严格 apples-to-apples 比较。

0. 这次有点离谱

AI界有句名言 - 学得慢，就不用学了。

这两周一直在琢磨7900XTX跑Flash-Next甚至DeekSeek Flash本地大模型。结果忽然发现我测的速度实在是赶不上新技术冒出来的速度。请看我这两周都经历了什么 ->

路线	引擎	量化 / 模型	GPU	结果概况
1	llama.cpp + Vulkan	GSQ-RCO Q2_0	单 7900 XTX	Prefill ~29.3，Decode ~13.2 t/s
2	MoE4All / infr	UD-Q2_K_XL	单 7900 XTX	Prefill ~248.9，Decode 16.57 t/s
3	llama.cpp + Vulkan	IQ4_XS	单 7900 XTX	最优 Prefill 150.8，Decode 17.88 t/s；长期服务约 8–14
4	MoE4All / infr 0.8/0.9	AD-4.27bpw Q4_K_M-M64	单 7900 XTX	131K：Prefill 672，Decode 32.2–35.3
5	Strata 0.1.27 + HIP	Orca / orcarouter IQ3_XXS	单 7900 XTX	Prefill 841–1271，Decode 50.9–59.2，254K 仍 841.5 / 52.1

之前的感觉一直是：

这种超大 MoE 能在单张 7900 XTX 上跑起来已经不错了。不求快，能用就行。

直到这两天我试了 Strata。结果： Decode 50～59 t/s。 更离谱的是 Prefill：最高 1270 t/s。 单卡，呀兄弟们，这是7900XTX单卡！

而且不是只有短 Context 跑得快。

上下文一直拉到： 254K Context 稳定得一匹

还能做到：

Prefill：841.5 t/s
Decode：52.1 t/s

我第一反应就是：

这是125B！这不是当年弱不禁风的Qwen3.6 35B A3B。

我第二反应就是：

TNND，测得慢，就不用测了。。。就好比起得晚，就不用起了。。。咳咳

1. 测试环境

项目	配置
GPU	AMD RX 7900 XTX 24GB
GPU 数量	单卡 GPU0
CPU	Ryzen 5 9600X，6C/12T
RAM	64GB DDR5 （除了显卡外的最大瓶颈）
OS	Ubuntu 24.04.4
ROCm	7.2.3
Strata	v0.1.27
Backend	HIP / gfx1100
Model	Qwen3.8-Flash-Next Uncensored
Quant	IQ3_XXS
GGUF 总大小	85.2 GB
Max Context	262144

模型：

orcarouter/Qwen3.8-Flash-Next-Uncensored-GGUF

实际使用：

Qwen3.8-Flash-Next-Uncensored-IQ3_XXS-00001-of-00002.gguf
Qwen3.8-Flash-Next-Uncensored-IQ3_XXS-00002-of-00002.gguf
Qwen3.8-Flash-Next-Uncensored-MTP-draft.gguf

Strata 官方 ORCA 文档指定的也是：

IQ3_XXS

2. Strata 编译方法

仓库：

https://github.com/Niko1221/Strata

版本：

v0.1.27

git clone https://github.com/Niko1221/Strata.git
cd Strata
git checkout v0.1.27

我的 HIP 编译参数：

cmake -S <worktree> -B <worktree>/build-hip-mmq \
  -DCMAKE_BUILD_TYPE=Release \
  -DSTRATA_ENABLE_HIP=ON \
  -DSTRATA_ENABLE_CUDA=OFF \
  -DSTRATA_HIP_ARCH=gfx1100 \
  -DSTRATA_NATIVE_EXPERTS=ON \
  -DSTRATA_PREFILL_MMQ=ON \
  -DSTRATA_GGML_DIR=<repo>/third_party/llama.cpp \
  -DCMAKE_PREFIX_PATH=/opt/rocm-7.2.3 \
  -Dhip_DIR=/opt/rocm-7.2.3/lib/cmake/hip \
  -DHIP_ROOT_DIR=/opt/rocm-7.2.3

cmake --build <worktree>/build-hip-mmq -j$(nproc)

这里要注意：

Strata pinned llama.cpp 的 CUDA/MMQ 源码位置是：

third_party/llama.cpp/ggml/src/ggml-cuda/

不是：

third_party/llama.cpp/ggml-cuda/

路径搞错，configure 阶段就会报错。

3. IQ3_XXS 需要先做 Strata Pack

我先用官方工具把模型转换成 Strata 原生 pack：

python tools/iq_pack.py \
  --gguf <model>-00001-of-00002.gguf \
  --out <pack-dir>/iq3_xxs \
  --compat-bf16

生成内容包括：

experts.bin
native_experts.txt
index.txt
dense.bin
extra.bin
tokenizer/

其中：

experts.bin ≈ 53.5 GB

核心目的就是：

把专家权重整理成 Strata 自己适合高速访问的格式。

4. AMD 上还有一个关键步骤：hipBLASLt 本地校准

官方有 gfx1100 的 hipBLASLt tuning table。

但我这里：

ROCm：7.2.3
hipBLASLt runtime：100202

官方的：

100100
100200

都会因为版本不匹配被拒绝。

所以我在本机重新校准了一张：

gfx1100-hipblaslt-100202-local.txt

最终：

27 rows，全部校验 PASS。

启动前确认日志里出现：

hipBLASLt tuning enabled

否则不能算完整性能配置。

5. 我的最终运行参数

环境变量：

export LD_LIBRARY_PATH=/opt/rocm-7.2.3/lib:/opt/rocm-7.2.3/lib64

export ROCR_VISIBLE_DEVICES=0
export HIP_VISIBLE_DEVICES=0

export STRATA_PREFILL_MMQ=1
export STRATA_HIPBLASLT_TUNING=<本地校准表>
export STRATA_PREFILL_RING=96
export STRATA_IO_THREADS=32

关键 Strata 参数：

参数	我的配置
`--pack`	IQ3_XXS Strata pack
`--native`	Orca IQ3_XXS GGUF
`--ple-gguf`	Orca IQ3_XXS GGUF
`--expert-profile`	官方 expert profile
`--expert-cache`	auto
`--mmap-experts`	开
`--resident-cpu-experts`	开
`--prefill`	8192
`--spec`	4
`--spec-min-p`	0.5
`--mtp`	MTP runtime
`--max-context`	262144
`--kv`	int8
`--kv-resident`	32768
`--pool-workers`	5
`--adapt-every`	0
`--pcie-frac`	0
`--vram-reserve-mib`	1024

这里最关键的参数：

--resident-cpu-experts

它让专家真正常驻系统内存。

6. Strata 最终成绩

先看短 Prompt：

Prompt	Prefill	Decode
4210 tok	555.3 t/s	56.8 t/s
8830 tok	865.5 t/s	55.0 t/s
4210 tok	919.7 t/s	54.0 t/s
8830 tok	1017.2 t/s	57.9 t/s

真正让我觉得离谱的是长 Context 曲线。

实际 Context	Prefill	Decode
1,557	526.4 t/s	57.8 t/s
6,076	1131.9 t/s	57.3 t/s
12,100	1109.3 t/s	58.3 t/s
24,153	1270.7 t/s	51.7 t/s
48,254	1211.5 t/s	58.3 t/s
96,456	1164.2 t/s	59.2 t/s
190,516	1112.8 t/s	54.6 t/s
222,312	880.5 t/s	50.9 t/s
254,105	841.5 t/s	52.1 t/s

几个重点：

24K Prefill：1270.7 t/s
96K Prefill：1164.2 t/s
190K Prefill：1112.8 t/s
254K Prefill：841.5 t/s

Decode 从 1.5K 到 254K：

50.9～59.2 t/s

也就是说：

Context 拉到 25 万 token，Decode 仍然保持在 50 t/s 以上。

哦，你问我这个Flash-Next效果怎么样？下面两张图，一摸一样的数据，一摸一样的要求，左边的图是本次测试的Flash-Next Orca IQ3_XXS生成的，右边是我用27B Q4_K_M生成的，你更喜欢哪个？

7. 资源占用

Resident 模式：

项目	实测
CPU 常驻专家	31.95 GiB
专家数量	8812
Prefill 临时借用	3.92 GiB
GPU 显存	25.19 / 25.75 GiB
系统可用内存要求	约 49.8 GiB

所以这套配置虽然是：

单张 RX 7900 XTX

但真正工作的组合是：

24GB VRAM + 大约 32GB Resident Expert RAM

系统最好有：

64GB RAM

如果 resident 模式退化回 mmap / 磁盘读取，速度会明显下降。

8. 一个需要说明的小补丁

我的 Orca IQ3_XXS 是普通 GGUF quant。

Strata v0.1.27 对：

blk.1.ple_key.weight

的类型判断会误判。

因此我在独立 worktree 里做了一个很小的兼容修正：

- return include_ple_key && (tensor.type == 42 || tensor.type == 18 || tensor.type == 23);
+ return include_ple_key && tensor.type == 42;

生产 tree 没动。

这个补丁只用于：

让普通 IQ3_XXS GGUF 的 BF16 fallback 正确加载。

以后如果官方已经修正，就不需要再打。

9. 另外两套引擎成绩

为了知道 Strata 大概处于什么水平，我还测试过另外两条 Flash-Next 路线。

再次强调：

三套使用的量化不同，下面只是我自己机器上的实际结果汇总，不是严格公平跑分。

llama.cpp + Vulkan

模型：

IQ4_XS，97.5 GB

最优 bench：

指标	成绩
Prefill	150.80 t/s
Decode	17.88 t/s

实际长期服务：

8～14 t/s Decode

MoE4All infr 0.8 / 0.9 + Vulkan

模型：

AD-4.27bpw-Q4_K_M-M64，89 GB

131K Context：

指标	成绩
Prefill	672.0 t/s
Decode	32.2～35.3 t/s
TTFT	约 194 s

10. 三套放在一起

引擎	量化	Prefill	Decode	Context
llama.cpp + Vulkan	IQ4_XS	150.8	17.9	短 Context
MoE4All infr	4.27bpw Q4	672.0	32～35	131K
Strata 0.1.27	IQ3_XXS	841～1271	50.9～59.2	254K

还是那句话：

不同量化，不做严格横评。

但从我自己实际跑下来的结果看：

Strata 确实快得有点不讲道理。

11. 总结

本来以为我的单卡DanielMTP 27B已经够快的了。魔法打败魔法，Strata 横空出世，用Flash-Next 在7900XTX上跑出了真正生产力。

Ben Lee

@terry @flyer666 @farmer-node @laobenxiong @墙内人
各位大佬，今天继续给大家汇报一下这两天折腾 SGLang 的进展。

先说句实话，我现在都不知道自己哪来的勇气。一个纯小白，在这个论坛里混了三个月，现在居然就敢大包大揽接下这么一个技术含量挺高的测试，回头想想，多少有点自不量力。结果这两天果然被现实狠狠地打脸。各种之前根本没想到的问题一个接一个冒出来，搞得我抓耳挠腮、鼻青脸肿，折腾了一天一夜多，整个人都有点焦头烂额了。

首先就是ROCm 7.2 升级到 7.14 带来的编译问题和系统兼容问题，vLLM的识图也一度崩了，最离谱的是，后来发现硬件这边居然也在捣乱。先是 CPU 温度超过警戒值，后来排查下来，怀疑和散热器压紧程度、接触状态有关；接着两张显卡温度也一度冲得很高，又牵扯出上下卡位、风道以及两张卡之间热量互相影响的问题。这些因素叠在一起，导致我最开始跑出来的结果甚至有点违反预期。

老特前不久的视频里很明确地说过，SGLang 相比 vLLM 是更高一档的存在。我第一轮测出来 vLLM 更占优势，更不用说vLLM可以Int8 KV量化，SGlang只能BF16。要不是我一直紧跟特哥的视频，我当时可能还真就信了，所以第一反应不是下结论，交作业，而是立马警惕，是不是我哪里搞错了？

带着这个怀疑，我训着AI（也是跟老特学的）把整套测试重新审了一遍，结果还真发现了降频、温度干扰以及测试方案本身的一些漏洞。后来又花了很多时间，把温度、驱动、配置、测试方法这些干扰项一个一个排掉。折腾到刚才，总算拿到了一组我自己看完以后比较放心能拿得出手的结果。毕竟发出来的东西还是要负责的，不能随便浪费大家时间。

下面直接上数据。

一、先汇报 PR #34058 / N=1 的实际结果

先把上次大家比较关心的这件事交代一下。

我这次实际按 PR #34058 对应的 N=1 路线继续用了下来。

结论很直接：

目前已经达到我认为可以投入实际生产使用的状态。双 7900 XTX 的 SGLang 路线正式打通，flyer666大神牛B！！！

而且不是“能启动、能跑请求”这种意义上的可用。在我后面重新做完的正式测试里，SGLang 已经不只是恢复正常，很多和我真实 Agent 工作负载相关的项目，实际表现已经超过了之前我用的很顺手的vLLM。（这个也是跟着flyer666大神的帖子 ”双卡7900xtx VLLM qwen3.8 爽玩agent pp1600 tg 160+ (附 mtp/7900xtx全攻略）” 学到的。 Respect！https://lcz.me/topic/1363 ）

尤其是：

长期 Agent 追加轮
多个 64K 请求并发
文本→图片→再返回文本
64K decode

所以在我现在这套双 7900 XTX / ROCm 7.14 / Qwen3.8-27B 环境里，我已经把SGLang正式部署为我的生产环境。

注： N=1 后，64K fresh prefill 不再把正在 decode 的 Agent 完全饿死，但重 prefill 仍会造成显著性能下降。这其实也很合理。B 的 64K fresh prefill 本身就是一个非常重的 GPU 任务，它进来以后会大量占用算力和带宽。双卡总资源固定，A 的 decode 被挤压是正常的；N=1 做到的是不让 A 完全没饭吃。

下面汇报测试细节，欢迎批评指正

二、测试平台

硬件环境

项目	配置
CPU	AMD Ryzen 5 9600X
主板	GIGABYTE X870E AORUS Xtreme AI TOP
内存	64GB DDR5
GPU 1	ASRock Radeon RX 7900 XTX 24GB
GPU 2	Sapphire PULSE Radeon RX 7900 XTX 24GB
并行方式	双卡 TP=2
系统	Ubuntu
ROCm	7.14
模型	Qwen3.8-27B-W4A16-AutoRound-GPTQ
最大上下文	196,608 tokens（约 192K）

两套生产配置

项目	SGLang	vLLM
Tensor Parallel	TP=2	TP=2
模型	同一 W4A16 AutoRound checkpoint	同一 W4A16 AutoRound checkpoint
KV dtype	BF16 / auto	INT8 `int8_per_token_head`
最大上下文	196,608	196,608
Attention	Triton	TRITON_ATTN
Speculative	EAGLE	MTP=3
最大并发设置	4 running requests	max-num-seqs=128
GPU Memory	生产配置	0.95
ROCm	7.14 / gfx1100 适配	7.14 / gfx110x 独立 MM 环境

这里先声明一下：这不是完全归一化的学术 benchmark。 我测的不是“把所有参数强行改成完全一样以后，哪一个 scheduler 理论上更强”。

打通这条 SGLang 路线以后，我真正想测的其实很简单：同样的硬件、同样的模型、同样的 196K 上下文目标，SGLang 和 vLLM 到底哪个更适合我真实的 Agent 使用场景。

三、我的真实使用场景

这个部分其实比单纯的 benchmark 数字更重要。我的机器不是拿来给多个人同时跑 API 的。大多数时间，我就是自己用两个长期 Agent。

Agent A：分析 / 推理

主要做：

分析
调研
公司报告
长文本
学习资料
各类推理任务

Agent B：创意 / 多模态

主要做：

图片
视频
多模态
创意任务
偶尔回到文本分析

偶尔的 Agent C

第三个 Agent 在我的NAS上，主要负责：

系统监控
系统管理
检查所有机器状态
远程唤醒
家庭智能助手
一些比较轻量的后台任务（邮件，提醒，定期搜寻资料等）

但三路长期重负载不是我的常态。

为什么我最终把 Context 定在 196K？

每一个 Agent 我都配置到：196,608 tokens，约 192K。

这个数字不是随便拍脑袋定的。主要是结合双 7900 XTX 的实际 KV 容量，反复讨论以后选出来的生产平衡点。

在我现在的配置下：

SGLang

因为还是 BF16 KV，所以 KV 空间比较紧。196K 65%压缩阈值这个设定下：

两个长期 Agent 基本是比较安全的。

再加入第三个大 Context session，就开始很容易发生 eviction。

vLLM

vLLM 使用 INT8 KV，KV 容量明显大一些。从这次实际测试表现看，大致可以理解成：

比 SGLang 多出半个到一个 session 的余量。

也就是大约 2.x 个类似长期上下文的空间，而不是无限增加。

所以最终对我来说，196K + 双 Agent 本身就是一个经过取舍以后比较合理的生产点。（注意，Qwen3.8 27B的雷霆大思考是病，得治，网上有药）

后端	KV dtype	可用 KV 池
SGLang	BF16 / auto	约 263K tokens
vLLM	INT8 `int8_per_token_head`	约 295K tokens

而且我的 Agent 不会真的一路堆到 196K

我的Hermes Agent压缩机制大约到 65% context 左右就会压缩。压缩以后回落到大约 25%，同时保留：

最近约 20–30 条重要消息
最早 1–2 条关键内容
压缩后的长期摘要

所以现实里我根本不会经常跑到 190K+。这也是为什么这次 196K 极限测试因为测试载荷多了几个 token 而作废以后，我没有再专门补测。对我的生产场景意义不大。

我的 workload 和 Coding Agent 其实不太一样

还有一点必须特别说明。我的工作比较发散，两个Agent大多数时间都算是“脉冲式”推理，基本没有双路满载的情况。具体来说 -

一个 Agent 可能正在做：

公司分析、报告、调研、长文本推理

另一个 Agent 可能已经跑去：

做图、做视频、看图片、多模态

所以这并不像很多 Coding Agent：

system prompt 类似
tool schema 类似
repository 内容高度重复
大量代码 prefix 可以反复共享

我的两个主 Agent 之间，真正完全相同的大段业务 prefix 并没有那么多。所以从这个角度讲：

我的 workload 其实并不是特别“照顾”SGLang prefix cache 的 workload。远远没有发挥SGLang高效缓存命中的实力

同一个 Agent 自己继续聊天，cache reuse 当然非常明显。但跨 Agent 的共享命中率不会像 Coding / 大规模同质 Agent 那么高。我平时使用两个 Agent 的任务内容差异较大，因此跨 Agent 可复用的大段 prefix 不多，新任务更容易表现为 fresh prefill，而不是高比例 prefix hit，如果你的 workload 是：

Coding Agent
多个 Agent 共用同一套 tools
大量相同 system prompt
大量重复 repository/context
显存又比我的双 24GB 更充裕

那么我认为 SGLang 的 prefix cache 优势反而可能比我这里体现得更充分。

四、核心结果

1. 单流：两边差距其实不大

32K Cold Prefill

指标	SGLang	vLLM
TTFT	20.00s	20.30s
Prefill	1,640 tok/s	1,615 tok/s
Decode	99.0 tok/s	94.5 tok/s

32K 基本可以认为打平。

64K Cold Prefill

指标	SGLang	vLLM
TTFT	48.26s	48.50s
Prefill	1,358 tok/s	1,352 tok/s
Decode	88.8 tok/s	77.2 tok/s

Prefill 还是几乎一样。但 64K Decode：> SGLang 领先大约 15%。

2. 长期 Agent：这里开始真正拉开

两个 64K 长期 Session 建好以后，继续原来的会话：

指标	SGLang	vLLM
64K 冷启动	~48.2s	~48.5s
后续轮 TTFT	0.402s	2.254s
后续轮 Decode	86–96 tok/s	81–83 tok/s

这是我最看重的项目之一。

0.402 秒 vs 2.254 秒。

SGLang 后续轮响应大约快：

5.6 倍。

这已经不是 benchmark 表格上好看一点的问题。

长期 Agent 每天真正用的时候，0.4 秒和 2.2 秒的体感完全不一样。

3. 一个 Agent 正在 Decode，另一个突然进来一个 64K 重任务

指标	SGLang	vLLM
原 Agent Decode	15.4 tok/s	13.9 tok/s
新 64K TTFT	65.4s	72.1s
最大单次停顿	4.0s	1.79s
Token Gap P95	35ms	1.38s

vLLM 最大那一下停顿更短。

但 SGLang：

原 Agent 吞吐更高
新任务完成更快
大多数 token 输出更连续

所以综合下来，我还是判 SGLang 略胜。

不过这个测试也证明了一件很现实的事情： 显存能解决“装不装得下”，解决不了无限算力。

三路、四路都同时真正 Decode 的时候，两张 7900 XTX 的总算力就在那里，不可能每一路都保持单流速度。我自己用短上下文的三个Agent实测时，已经感觉到明显卡顿了，算力瓶颈开始显现。

4. KV Retention：这一项 vLLM 明确赢

加入第三个 Agent 后：

SGLang

两个原来的 64K Session 回来：

~48.4s
~48.4s

基本都需要重新 Prefill。

vLLM

一个大部分被驱逐。

另一个还能：

~2.29s

所以这一项：

vLLM 明显胜出。

但这里要再次提醒：

vLLM = INT8 KV
SGLang = BF16 KV

这很大程度上就是 KV 容量的直接差异。

如果以后 SGLang 的 8-bit KV 在 gfx1100 / ROCm 上稳定打通，这一项我认为非常值得重新测。顺带说一句，这两天折腾的时候倒是误打误撞把 FP8 KV 给跑通了，只不过现在速度慢得比较明显，肯定还有坑，暂时谈不上实用，flyer666大神也尝试过了也还没搞定，但是AMD社区发展很快，后面我继续盯着看有没有大神们的分享。

5. 2 / 3 / 4 个 64K 同时进入

这是我这轮最惊讶的结果之一。

并发	SGLang 整批完成	vLLM 整批完成
2	48.2s	97.4s
3	48.3s	100.3s
4	48.5s	102.9s

SGLang 基本是：

大家一起进来，差不多一起出去。

vLLM 则出现明显 TTFT 阶梯：

2 并发：48 → 97s
3 并发：48 → 97 → 100s
4 并发：48 → 97 → 100 → 103s

至少在我这套双 RX 7900 XTX TP2 环境下：

SGLang 并发 Prefill 调度明显占优。

注：这一组输出只有 2 tokens，因此主要衡量 64K 并发 prefill、TTFT 和整批 wall-clock，不代表 2/3/4 路持续 decode 吞吐。

6. 多模态

单独看一张图片：

指标	SGLang	vLLM
TTFT	0.174s	0.152s
总耗时	0.363s	0.311s

纯视觉：vLLM 略快。 但是我真正的 Agent 工作方式通常是：

长文本 → 看图识图 → 再回原来的长文本

图片之后返回原文本：

SGLang：0.233s
vLLM：20.268s

这里差距就完全不是一个量级了。所以：

单图：vLLM 略胜。

真实文本 + 视觉长期 Agent：SGLang 明显胜。

五、最后结论

先声明：

这个结论只代表我的硬件和 workload，不代表所有人。

如果你的显存更大、长期并发 session 更多，而且 KV retention 的优先级高于交互延迟，那么 vLLM 的 INT8 KV 路线依然非常有吸引力。我的结论并不是“vLLM 不行”，而是在我的 workload 权重下，SGLang 更合适。我的真实使用前提已经决定了选择：

常态就是两个长期 Agent
第三个 Agent 只是偶发监控/管理，用云端模型花不了多少钱
每个 Agent 虽然设到 196K，但 65% 左右就会主动压缩
工作内容发散，不是大量重复 Coding Prefix
更在意长期 Session 返回速度和双并发体验

在这个前提下：

我最后选择 SGLang 做主力。

因为对我最常发生的场景来说，它已经表现出：

64K Decode 更快
长期 Session 返回明显更快
双/三/四 64K 并发 Prefill 更强
文本→图片→文本工作流明显更顺

而 vLLM 最大的优势：KV retention 在我的生产策略里反而不是最高优先级。如果以后 SGLang 能把 gfx1100 下稳定的 INT8 KV 打通，那我认为它目前最明显的短板也基本补上了。

最后还有一个问题我后面很想继续测： > 1 个双卡 TP2 SGLang > vs > 2 个单卡独立实例 到底双卡协同能不能真正做到：

1 + 1 > 2

这个我觉得比继续追几十个 tok/s 更有意思。对了，这次主要围绕 SGLang、vLLM 和 llama.cpp 三条本地推理路线展开。当前这一轮先完成了 SGLang vs vLLM 的正式对比，llama.cpp 因为双卡实现方式不同（layer split，不是 TP=2），我准备单独开一轮测试，避免混在一起造成误导。特哥一直鼓励我发新帖，我正在弄，弄好了我一起发我的本论坛处女楼主贴。

最后聊点题外话。

感谢 AI 治好了我的“电子阳痿”。无比怀念当年天天晚上工会活动，我法师准时上线，和一帮兄弟姐妹一起开荒魔兽世界的日子——美好、热血，也确实挺不务正业。现在年纪大了，游戏买了一大堆，全躺在硬盘里吃灰，删又不舍得删，打开玩又确实意兴阑珊。

结果这几个月折腾 AI，居然又找回了当年那种感觉：白天上班，晚上回来折腾机器、编译、跑模型、改参数、看视频、查日志，一不小心又干到下半夜。

区别只是当年开荒的是副本，现在开荒的是 ROCm、SGLang、vLLM、llama.cpp，还有各种自建 Skill。

更妙的是，这次在家天天熬夜的理由还格外冠冕堂皇——“学习 AI、研究新技术、提升生产力”。连申请显卡经费审批都顺利了不少，居然和当年的高手们“名正言顺申请 5090以便在特殊时期更好的上网课”那种窃喜和偷感共情了。

仔细想想，人其实没怎么变，只是当年折腾装备、插件和副本，现在折腾显卡、推理框架和 Agent。还是那个毛病：一旦找到新坑，就总想往深里挖。

搞不懂就查，跑崩了就重来，偶尔折腾出一个能用的结果，那个爽感还真和当年首杀 Boss 有点像。

游戏还是继续吃灰吧。现在这个“副本”，感觉还够我开荒一阵子。

Ben Lee

上一篇介绍了 Hipfire 在 RX 7900 XTX 上的推理性能，单卡 8K 上下文实现了 2682 t/s Prefill 和 169.4 t/s Decode，64K 上下文仍有 119.5 t/s Decode。

部署到实际使用环境后，这次继续测试四个方面：框架功能与限制、Hermes Agent 实际运行、标准题集质量，以及不同思考档位的效果。最后再让模型交几份有趣的编程作业。

结论优先，跑了三天测试，没有出现死循环，未发现影响主要功能的严重 Bug，能用，够用，单卡7900XTX好用，我已经把自己单卡的生产环境换了这个推理框架。

一、Hipfire 框架与专属 MQ4-XTS 模型

1. 测试环境

项目	配置
GPU	RX 7900 XTX 24GB，单卡
GPU 架构	AMD RDNA3 / gfx1100
推理框架	Hipfire v0.4.2.1
Commit	`6b363a56a1ae`
模型	Qwen3.8-27B MQ4-XTS
KV Cache	Q8
显存管理	HIP VMM
推测解码	DFlash
API	OpenAI-compatible
Agent	Hermes

Hipfire 是针对 AMD GPU 优化的推理框架。与常见的通用模型运行方案相比，其特色是专属 MQ4-XTS 模型格式、VMM 显存管理和 DFlash 推测解码。

这里测试的不是普通 GGUF Q4 文件，而是 Hipfire 框架与 MQ4-XTS 模型组合的整体表现。

2. 主要功能和实测情况

功能	测试情况
DFlash 推测解码	8K 下 169.4 t/s，约为 AR 的 3.39 倍
Q8 KV Cache	已用于所有主要长上下文性能测试
VMM 显存管理	已启用，支持按需映射
上下文	128K、160K 实测成功，约 176K OOM
Prompt Cache	前缀复用已验证
视觉输入	简单图片、色块和示意图测试通过
Tool Calling	已接入 Hermes 并完成实际工具调用
思考档位	支持请求 Off / Low / Medium
并发	主要性能测试为 C1，尚无充分多并发验收

3. Prompt Cache

早期测试中，曾关注过 Hipfire 的前缀缓存能力。

后续生产环境验证确认，重复请求能够复用前缀 KV。在一次测试中：

指标	首次请求	重复请求
命中缓存 tokens	—	6656
墙钟耗时	约 2.9s	约 0.3s

这是一次特定测试的结果，不代表所有任务都能获得相同加速，也不意味着模型具备无限容量的历史 KV 存储。

4. 实际限制

KV 显存硬边界

当前单卡 24GB、MQ4-XTS、Q8 KV 配置下：

128K：通过
160K：通过
约 176K：OOM （Q8KV下24G显存有点捉襟见肘这是硬伤，但是实测Q4 KV会严重损失速度，只能Q8)

因此，较高的逻辑上下文配置不等于对应长度一定能够实际运行。这个边界是当前模型及显存配置的实测限制，而不是 Hipfire 框架通用的固定上限。

并发能力

已有吞吐成绩主要来自 C1 单并发、Cold Context 测试。多并发吞吐、延迟以及显存压力尚无充分验证。

量化格式与兼容性

MQ4-XTS 是这套框架的专属模型格式。普通 Q4/GGUF 量化和 MQ4-XTS 不能直接等同；此前其他四位量化路径的失败现象也不能据此归因于 MQ4-XTS。

二、部署生产环境：Hermes Agent 能不能真正干活？

完成性能测试后，将 Hipfire 27B 接入 Hermes，作为实际 Agent 的推理后端。

这部分没有停留在简单问答，而是测试文件读写、工具调用、调查分析、代码调试、多轮执行和视觉输入。

1. 基础功能验收

测试	结果
基础 Tool Calling	PASS
文件读取与调查	PASS
多步骤工具调用	PASS
Coding / Debug	PASS
视觉图片输入	PASS
Prompt Cache 命中	PASS
动态思考请求	PASS（请求切换）
多轮 Agent 工作流	PASS

2. Coding / Debug

在预设问题的代码与配置调查中，模型成功定位三处缺陷。

一次 Medium 测试记录：

指标	实测
找到的问题	3 处
思考 tokens（测试记录）	约 10,558
墙钟时间	约 34s

3. 多轮 Agent 工作流

一次完整任务的执行记录：

指标	结果
LLM 调用	5 次
工具调用	6 次
工具重试	0 次
总耗时	413s
最终状态	PASS

这一结果说明模型能够驱动 Hermes 完成多轮工具链任务，但单次成功不能等同于长期 Agent 可靠性统计。

4. 视觉能力

启用视觉组件并设置 vision_mode=auto 后：

任务	结果	耗时
纯红图片识别	PASS	—
RGB 三色带识别	PASS	2.5s
双框技术示意图	PASS	5.31s

三、模型质量：标准题集实测

本次使用五套标准题集，共 3,711 道题，考察数学、知识、科学推理及代码生成能力。测试使用本地固定题集和自定义评分脚本。

1. 题集及特点

题集	测试重点
GSM8K	多步骤数学应用题
MMLU	多学科知识与理解能力
GPQA	高难度科学知识与推理
AIME 2025	竞赛级数学推理
HumanEval	Python 代码生成与实际执行

2. 已完成成绩

题集	Hipfire 27B MQ4-XTS	说明
GSM8K	1283/1319，97.3%	完整评分
MMLU	1773/2000，88.7%	固定 2000 题子集
GPQA	158/194，81.4%	198 题中 4 题未评分
AIME 2025	26/30，86.7%	4 题截断
HumanEval	153/164，93.3%	修正执行评分，Off

测试方法说明：

temperature = 0
原始输出上限 = 16,384 tokens
GPQA/AIME 部分原始截断题选择性以 32,768 tokens 补测
历史全量运行缺少逐请求思考档位记录
使用本地题集及自定义评测脚本

因此，GPQA 和 AIME 表中的成绩含有混合输出预算，不应理解成全部题目在完全统一的 16K 上限下取得。

四、这个27B模型思考档位差别有多大？Off、Low、Medium

为了观察开启思考后的收益，又进行了两组独立测试。

1. 60 题综合推理专项

包括数学、知识、科学推理及部分代码生成题。五道代码生成题没有在这一组执行评分。

指标	Off	Low	Medium
正确/有效评分	42/55	49/54	50/54
正确率	76.4%	90.7%	92.6%
中位耗时	1.6s	17.8s	15.4s
P90 耗时	97.8s	85.2s	99.0s
中位 completion tokens	71	372	439

Off 到 Low 提升明显，Low 到 Medium 的正确率差距较小。

2. HumanEval 164 题完整测试

同一套 164 道编程题分别使用 Off、Low、Medium 生成，并用修正后的同一评分器执行。

指标	Off	Low	Medium
通过数	153	156	157
Pass@1	93.3%	95.1%	95.7%
中位耗时	0.79s*	2.69s	3.04s
P90 耗时	1.46s*	5.20s	6.67s
中位 completion tokens	151	527	633
请求错误	0	0	0
输出截断	0	0	0

Off 耗时来自服务恢复后保存完整计时记录的 143 题，正确率按完整 164 题统计。

逐题比较：

对比	前者独胜	后者独胜	同分
Off vs Low	4	7	153
Off vs Medium	3	7	154
Low vs Medium	1	2	161

Low 比 Off 多通过 3 题，Medium 比 Low 再多通过 1 题。

Medium 的中位 completion tokens 比 Low 增加约 20%，中位耗时增加约 13%。

对于这组编程题，Low 显示出比较好的质量与耗时平衡。但独立函数生成不能代替长期 Agent 工程任务测试。

总体来看，模型质量符合一款 27B、约 4-bit 量化模型的正常预期水平。Hipfire 更突出的优势仍然是释放了7900XTX单卡推理性能并提高了实际运行效率。

五、实际案例：让 Hipfire 27B 画图、编程，做游戏

标准题集之外，还让模型生成一些可以直接在浏览器中查看和运行的作品。

这些测试更直观，也能暴露单纯选择题不容易发现的问题。

可视化 Agent 实战总结

最后使用 Hermes Agent，让 Hipfire 27B 完成四类可视化编程任务：模拟时钟、鹈鹕骑自行车、贪吃蛇游戏和动态太阳系。

每项分别请求 Off、Low、Medium 三档，共进行 12 项独立测试。

项目	Off	Low	Medium
模拟时钟	PASS（修复后）	PASS	PASS
鹈鹕骑自行车	PASS（两轮修复）	PASS（修复后）	PASS（修复后）
贪吃蛇游戏	PASS	PASS	PASS
动态太阳系	PASS（8 行星）	PASS（6 行星）	PASS（8 行星）

最终 12/12 项通过，成功率 100%。

这些作品均由 Hermes Agent 使用文件工具生成，并在离线 Chromium 中进行结构、视觉或功能验收。贪吃蛇的增长、计分、碰撞及重启逻辑通过测试；动态太阳系的行星运动、暂停、继续和速度调节同样通过。

需要说明，测试发送了不同的思考档位请求，但未获得实际生效档位的充分证明，因此不依据这 12 项结果判断 Off、Low、Medium 的真实性能差异。

这组结果主要说明：Hipfire 27B 已能够驱动 Hermes 完成具有一定复杂度的可视化开发任务，包括生成文件、调用工具和自主修复。

1. 鹈鹕骑自行车：SVG 与 HTML 动画

首先要求模型画一只骑自行车的鹈鹕。

静态 SVG 测试：

指标	Thinking Off	Thinking Medium
生成耗时	13.65s	28.11s
Completion tokens	2372	3942
文件大小	4617 B	4538 B
渲染	PASS	PASS

两个版本都具备基本的鹈鹕与自行车结构。Medium 版本增加了更完整的车架、车座、双踏板与背景元素。

以下插图从上到下分别是思考模式 off，low，medium

ChatGPT Image Oct 18, 2026, 09_28_42 PM.jpg

随后要求模型生成动态 HTML 页面。

指标	结果
生成耗时	44.98s
Completion tokens	5578
HTML 大小	约 5.97 KB
外部依赖	无
SVG + JavaScript	是
Chromium 截帧	PASS

动画实现了车轮旋转、双腿踩踏板、车辆横向移动和鹈鹕身体轻微起伏。

Pelican on a Bicycle.html

2. SVG 模拟时钟：10:10:30

让 Hermes Agent 生成一个带 12 个数字、60 个刻度以及时分秒三根指针的模拟时钟。

模型档位	最终结果	备注
27B Off	PASS	修复后通过
27B Low	PASS	144 秒，6 次文件工具调用
27B Medium	PASS	结构和视觉检查通过

三个版本均已完成渲染验收。验收标准包括刻度数量、数字位置与指针角度。

3. 贪吃蛇：从代码到可玩的游戏

接下来是经典的 Snake 游戏。

要求生成单文件 HTML，支持方向键控制、随机食物、蛇身增长、得分、碰撞判断和重新开始。

指标	Off	Low	Medium
最终结果	PASS	PASS	PASS
总耗时	43s	125s	76.31s
工具调用	3 次	4 次	3 次
输出 tokens	3,784	4,012	7,609

离线 Chromium 验收确认两个版本的游戏逻辑能够运行。

测试为可重复验证碰撞与计分，采用手动推进游戏步进的方法，不作为真实连续帧率测试。

snake_27b_off.html
snake_27b_low.html

4. 动态太阳系

最后一项要求生成动态太阳系页面，包含多个行星、不同轨道半径与运动速度，以及暂停和速度调节功能。

27B_Off_Solar_System.html
27B_Low_Solar_System.html
27B_Medium_Solar_System.html

注：搞笑啦，居然是思考off模式最好，图像好看，行星速度差值表现也靠谱的多。这道题上，开思考没带来更好的成品。

结语

从最初的 Prefill、Decode 性能测试，到生产环境部署、Hermes 工具调用、标准题集及实际编程作品，Hipfire 27B MQ4-XTS 在单张 RX 7900 XTX 上展现了相当完整的本地推理能力。

最有代表性的几个数字：

2682 t/s Prefill、169.4 t/s Decode：8K 上下文 DFlash 实测
160K：当前 Q8 KV 配置下的已验证长上下文长度（据此我设的Hermes 192K 上下文， 75%压缩阈值。DSH则自用许多）
97.3% GSM8K、88.7% MMLU
93.3% / 95.1% / 95.7%：HumanEval Off / Low / Medium
Hermes 工具调用、Coding/Debug、多轮任务和基础视觉均已通过验证

与此同时，长上下文显存边界、多并发能力、特定量化路径兼容性、服务异常及长期 Agent 稳定性仍存在明确的工程限制。

对 RX 7900 XTX 而言，Hipfire 的价值不只是某一个 Benchmark 数字，而是通过针对 gfx1100 的软件优化，让一张 24GB RDNA3 显卡在速度、模型质量和实际应用之间取得了新的平衡。

Ben Lee

这个帖子本来是发在 @flyer666 大佬的《魔改 SGLANG 支持 7900XTX 双卡 TP，TTFT <1s，平均 TG 80–100，4 并发 TG 200/sec》这篇神级帖子下面的一条我的水贴：

https://lcz.me/topic/1532?_=1789171714063

受宠若惊，被老特分叉置顶到了这里。既然单独成帖了，我也顺手把前面几处容易误导大家的地方补充和勘误一下。

首先要特别说明，魔改 SGLANG 支持 7900XTX 双卡 TP 这条路线，是 @flyer666 9 月 6 日发的高含金量原创，链接就是上面这篇。大家一定要先去拜读，然后狠狠点赞。
其次，回复 @geekyang 和 @懒人烘培两位朋友：不好意思哈，我前面把主板型号写错了。我的实际主板是 GIGABYTE B850 AI TOP，当时大约 $320，并不是 GIGABYTE X870E AORUS Xtreme AI TOP（约 $1070）。
我选 B850 AI TOP 最主要的原因，就是双显卡同时插上以后，两条槽可以跑 x8/x8，对双 7900 XTX 这种玩法比较合适。缺点也很明显：DDR5 现在这个价格确实有点离谱。不过考虑到后面本地部署，尤其是 MoE、CPU offload、HiCache 这类玩法都会越来越吃系统内存，最后还是狠狠心上了 2×32GB，总共 64GB DDR5。现在回头看，这 64GB 还真没白上。要是只有 32GB，后面很多新玩法，包括大模型 CPU offload、长上下文缓存、HiCache L2 这类东西，基本就玩不开了。

然后补充下上面那个帖子的背景，希望对感兴趣的朋友有所参考和帮助。

我原来一直用的是7900XTX双卡 + vLLM，也是跟着 @flyer666 大佬之前这篇帖子折腾的：https://lcz.me/topic/1363 。用得非常顺手。

上周末看到 @flyer666 大佬这篇双 7900 XTX + SGLang 的帖子，测试数据实在太漂亮，当时确实有点兴奋，马上就想把自己的双卡也迁过去试试。结果 SGLang 部署起来以后，很快就碰到了一个特别明显的问题：

一个 Agent 正在正常输出时，另一个 Agent 一旦进来做长 prompt prefill，前面的 Agent 会出现几十秒完全没有 token 输出。也就是说我的两个Hermes Agent同时卡死无反应，短则几十秒，长达几分钟。但是单Agent完全没有问题，提升明显。

对我自己的使用场景来说，这个问题很严重。我平时不是只跑一个请求，而是有两个长期 Hermes Agent。一个 Agent 正在正常工作的时候，另一个 Agent 很可能突然带着很长的上下文进来。双卡跑不了并发，钱岂不是白花了？

最开始我还以为是双 7900 XTX 的算力不够，或者是 TP、ROCm、speculative decoding 哪一层出了问题。后来一路查资料、翻 issue 和 PR，才发现 SGLang 上游其实已经有人专门处理过这个问题。关键就是：PR #34058 https://github.com/sgl-project/sglang/pull/34058

这里面有一条和 scheduler 调度有关的改动，同时还有一个刚刚发布的的新参数：

--max-consecutive-prefill-batches N

它的作用可以简单理解为：

限制 scheduler 连续执行 prefill 的次数，给已经处于 decode 状态的请求留出调度机会。

这个开关对我的实际使用体验产生了非常明显的变化。我当时专门设计了一个双并发测试来模拟自己的真实场景。

测试环境：

双 7900 XTX + SGLang gfx1100 + TP2 + MTP3 + BF16 KV

场景是：

Agent A 已经带着 64K 上下文持续 decode
→ 5 秒后 Agent B 加入
→ Agent B 执行 64K fresh prefill

在原始状态下（不加这个参数，或者这个参数N=0），A 会出现非常明显的 starvation(算力饿死），就是卡死不动了。对我这种双长期 Agent 的工作方式来说，这基本就等于：

SGLang 在默认调度下不可用。

找到 PR #34058 以后，我把 --max-consecutive-prefill-batches 从 N=1 一直测试到 N=16。

实测结果如下：

N	A 最大断流	B 64K TTFT
0（原版）	47.23s	49.43s
1	4.04s	49.48s
2	7.70s	49.21s
3	11.70s	49.05s
4	13.80s	49.37s
8	25.76s	49.24s
16	47.05s	49.24s

结果非常直观可观。

N=1 基本就是我这个场景下的甜点位。

B 的 64K TTFT 几乎没有受到明显影响：

原版：49.43s
N=1：49.48s

但 A 的最大断流时间：

原版：47.23s
N=1：4.04s

等于从接近 50 秒，直接压到了约 4 秒。也就是说，现在我的B Agent如果带着64K上下文进来，原来的A只卡顿4秒，然后恢复吐字，这几乎不可察。

当然了，这里有一点我觉得特别值得强调。

打开 N=1 以后，并不是说 A 就完全不受影响了。B 在做 64K fresh prefill 的时候，两张 7900 XTX 的算力还是要被抢走，所以 A 的 decode 速度还是会明显下降（实测值 80 tok/s 降到 15 tok/s）。

也就是说：

N=1 解决的是 starvation，不是 compute contention。

但是，它解决的是行不行的问题：

“另一个长 prefill 一进来，我这个 Agent 几十秒完全不出字。”

至此确定SGLang在我的这种“双7900XTX”加“双Hermes Agent各196K上下文”这个环境中完全可用了，这才引发了上面那个帖子的定量分析，到底vLLM和SGLang哪个更适合我，以及数据是多少。

换个说人话的版本，请勿对号入座哈

老特当年也风光过，坐奔驰，开宝马，最爱秋天的第一杯奶茶。

所谓时来天地皆同力，运去英雄不自由。如今龙游浅水，潜龙伏渊，论成败，人生豪迈，大不了重头再来。

于是招兵买马，雇了帅哥小特跑业务，请了一个漂亮小姐姐做财务。

一个负责挣钱，一个负责管钱。这算是 -- 双卡并行？

小特是真正的劳动模范，财务小姐姐也是秀外慧中。按理说，这男女搭配，干活不得效率翻倍？

都怪老特太抠门，不舍得团建投入，破冰不到位，怪不得小特这两天总是浮想联翩。

从大门到小姐姐工位的距离大约是49秒。每天早晨财务小姐姐带着一阵小香风款款经过，小特的CPU就瞬间被某个高优先级进程劫持。

小姐姐49秒不入座，小特的心49秒不降落。

财务小姐姐也是宝宝心里有苦倒不出。

每当小特经过，小姐姐的心里也总是一阵七上八下，小特又不是老特，他要是来加微信，我是拒绝呢，还是拒绝呢？

小特的工位到厕所的距离是49秒，小姐姐的魂也跟着柳飘飘了49秒。

感情你俩互相给自己心里加戏，让老子我的钱包白白受到一万点暴击是吧。

老特的人生，本来已经修炼到了莫听穿林打叶声，何妨吟啸且徐行的新境界。谁怕？怕谁？老子花钱雇了你们两个人，怎么着加法还变成减法了？是可忍，孰不能忍？

老特于是口吐莲花，感化得小特心服口服，心悦诚服。小特也是很有潜质的好苗子，老特本来的大招是老子蜀道山，结果根本不用数到三，数到一小特就已经脱胎换骨，改头换面，重新做人了。

从此小姐姐再进办公室，小特的心坚硬到只会跟着高跟鞋清脆的咔哒声动 4 秒。剩下的 45 秒里，风动，心不动。小特心无旁骛的样子——那真是，认真的男人最帅。

小特这一投入，小姐姐对他也顿时另眼相看。以后走过路过不怕错过，相看两不厌，只有敬亭山。

从此天下太平，工作融洽。男女搭配，终于成果加倍。

老特端着泡满枸杞的保温杯站在门口，看着两个人终于各司其职，露出了资本家久违的微笑。

这，就叫结构化浪起来(SGLang) 的管理调度。

这，就是我 Scheduler 的硬实力。

Ben Lee

@Geekyang 对，我用的开放式机架

Ben Lee

双 7900 XTX + SGLang：我们把 Qwen Hybrid 的 L3 / NVMe Cache 推到了最后一道墙

过去的一周我一直在折腾HiCache L3在7900XTX里的实现问题：

能不能让 Qwen 这类 Hybrid 模型，把长期不用的上下文从显存 / 内存下沉到 NVMe SSD，需要时再恢复回来？也就是让HiCache的L3真正发挥作用。但是目前的状况是L3只写不读，功能失效。

我的目标其实很简单：

显存贵，DDR5 也越来越贵，SSD 相对便宜。

如果能把SSD拉入KV池的媒介列，然后把缓存做成：

VRAM → 小量 RAM 缓冲 → 大容量 NVMe

那么多 Agent、长上下文的本地推理成本会低很多。这意味着什么？随着AI模型的进步，模型给定的上下文可能越来越多，显存要求也越来越大。但是众所周知显卡和内存目前的价格有多离谱和疯狂，如果能用相对便宜的SSD提供替代解决方案，那么就给很多目前受限制的个人消费级PC提供了新的可能。

我个人觉得这个思路像“混合硬盘”：

快的介质做缓存，慢但便宜的大容量介质做仓库。

只是这里存的不是普通文件，而是模型的 KV Cache 和 MAMBA / Linear Attention 状态。

但是，目前卡在了SGLang的HiCache L3这一步。@enigma 大佬在他的含金量很高的帖子 https://lcz.me/topic/1620 里也碰到了和我一摸一样的问题，L3只写不读。

我花了大概一个星期时间，烧了几十亿Token（不算本地算力），感觉几乎走到了最后一步，虽然不成功，但是想记录下来，给感兴趣的人分享一下过程和思路。

一、我们的环境（我们=我和我的AI Agent）

测试平台：

2 × RX 7900 XTX 24GB
ROCm 7.x
SGLang
Qwen Hybrid 模型
TP=2
GPTQ 4bit
File backend 作为 L3 / NVMe cache

这个环境本身就有一点特殊。

SGLang upstream 后来逐步淘汰了旧 GPTQ 路径，原因也很好理解：

软件要往前走，就要不断简化旧代码、适配新的硬件和新的量化后端。

问题是，7900 XTX / RDNA3 恰好还依赖这条老 GPTQ 路线。

所以不是 RDNA3 kernel 不能跑，而是 upstream “轻装上阵”时，把这条 legacy 路径一起拿掉了。

最后我们确认：

底层 gptq_gemm_rdna3 kernel 其实还在，只是 Python 注册、白名单和旧 GPTQ dispatch 被移除了。

把这部分接回来以后，latest main 可以重新在 7900 XTX 上启动 GPTQ。

事实上，从某个以前的版本上找到适配模块，也确实嫁接成功了。

二、旧版本为什么 L3 一直跑不通

我们最早是在较老的 SGLang 版本上做 HiCache。

L1 / L2 都能正常工作：

GPU → RAM → GPU

MAMBA state 也可以正常写进 SSD。

问题出在真正的 L3 restore。

旧架构里：

Host cache node 被淘汰以后，会被直接从 radix tree 删除。

于是出现一个很尴尬的情况：

SSD 上的数据还在，
但是指向它的 node / metadata 已经没了。

结果就是：

数据在 SSD 上，但新请求已经不知道该去哪里找它。

我们把这个问题称为：

L3 payload orphan

这也是旧路线最后的结构性 blocker。

三、latest main 出现了一个非常关键的新设计：buffer_only

后来我重新看 SGLang 最新 main，发现 upstream 已经换了思路。

新增的 buffer_only 模式，本质上就是：

RAM 不再承担完整 L2 Cache，
只做 GPU SSD 之间的临时 staging buffer。

也就是说，架构从：

GPU → 大 RAM Cache → SSD

变成更接近：

GPU → 小 RAM staging → SSD

这正好符合我们最开始的目标。

更重要的是：

它不再依赖 Host node 长期存活。

所以旧版本那个 “Host node 一删，SSD payload 变孤儿” 的问题，被新架构绕过去了。

四、MAMBA 居然真的走到了 L3 restore

这部分是这几天最大的突破。

我们已经实测证明：

MAMBA 可以写进 L3
storage key 正确
L3 read 命中
Host staging 正常
MAMBA payload 可以 H2D
device slot 可以 commit
server 不再像旧版本那样直接崩

一度我们甚至拿到了完整的链路：

L3 key
→ Host staging slot
→ Device slot
→ MAMBA commit
→ Decode

这已经说明：

MAMBA 并不是“完全不能做 L3”。

真正的问题已经缩到最后一层。

五、最后卡在哪里？

最后经过大量 trace，我们把问题压到了一个非常具体的位置：

Node Identity Split

同一个 request：

prefix match 认为自己挂在旧 node，例如 node 19
L3 restore 后，MAMBA payload 被 materialize 到一个新 node，例如 node 32
payload 在 device slot 27
但 decode 最后使用的是另一个 slot，例如 slot 28

也就是说：

数据恢复成功了，但 request 仍然握着旧的“身份”。

恢复后的新 node 和 request 当前 anchor 没有重新对齐。

简单说就是：

仓库把货送回来了，
但系统把货放到了新货架，
而取货单还指向旧货架。

这已经不是简单的 memcpy、slot clear 或同步问题了。

它开始涉及：

radix node identity
request re-anchor
scheduler admission
MAMBA CoW / handoff

也就是从“小修 wiring”进入了架构语义层。

六、所以最后我们选择停手

我们一开始给自己定了一个原则：

优先找最短路径。
如果只是几个局部 wiring bug，就修。
如果开始进入 scheduler / radix tree / request lifecycle 的重构，就停。

现在正好到了这个边界。

所以最终结论不是：

“失败了。”

而是：

我们已经证明 latest main 的 buffer_only 架构，确实可以把 Hybrid 模型的 MAMBA state 推到 NVMe L3 restore 的最后一公里。

真正还缺的是：

L3 restore 后，request-side node identity 如何重新和 materialized node 对齐。

七、这件事为什么值得继续关注

我觉得这个方向对本地 AI 很有价值。

未来模型上下文从 256K 走到 512K、1M，并不奇怪。

但显存和大容量 DDR5 都很贵。

如果 cache hierarchy 能真正变成：

VRAM
↓
小量 RAM staging
↓
大容量 NVMe

那么多 Agent 长期共存会现实很多。

尤其是 4 卡、8 卡、本地工作站这类机器：

计算能力可能够，
真正限制多 Agent 的反而会变成上下文驻留成本。

所以我很看好 L3 / NVMe cache 这条路线。

当前最终状态

已经验证：

双 7900 XTX + latest SGLang main
GPTQ RDNA3 路径恢复
Hybrid FULL + MAMBA
buffer_only
MAMBA L3 write
MAMBA L3 read
Host staging
H2D
device commit
双请求 ownership
abort / cleanup
85 分钟 soak
无资源泄漏

最后剩余 blocker：

L3 restore 后的 node re-anchor / identity handoff

所以暂时收工。

如果 upstream 后续补上 MAMBA buffer_only 的 re-anchor / state handoff，这套东西很可能就真的能完整闭环。

届时我会继续回来测试。

即使L3不工作，但是在上一篇帖子里我介绍了，我目前7900XTX双卡在SGLang+HiCache L1/L2 上跑Hermes双Agent 256K 上下文非常流畅丝滑，几乎不输云端模型体验。具体技术细节，推荐大家参考 https://lcz.me/topic/1620 里面干货满满。

Ben Lee

感谢版主和 Neo 分享 HiCache 方案！我们今天也在 RTX 5090 上做了一次复现实测，反馈一下结果。

之前的 SGLang 测试

我们之前已经成功跑通：

RTX 5090 32GB
SGLang 0.5.17
RadixArk Qwen3.8-27B NVFP4
131K/160K 配置、双并发、原生视觉

实测 Radix Cache 效果很好：50K 前缀命中后，首字延迟从约 7.6 秒降到 0.34 秒。

但当时无法实际应用，主要因为：

32GB 显存下实际共享 KV Pool 只有约 121K tokens
两个 Agent 同时使用时，大约只能各分配 45–55K
单会话生成约 66 tok/s，低于现有 llama.cpp+MTP 的约 85–97 tok/s
现有 llama.cpp 方案已能提供单 Agent 224K 长上下文，除了单并发其它完美符合本地要求。

因此，SGLang 虽然多会话和 Radix Cache 很优秀，但在 5090 32GB 上，长上下文容量不足，暂时没有替换现有生产方案。

也正因为这个原因，我们看到 HiCache 可以把被淘汰的 KV 放进内存后，觉得它可能正好补上这块短板，所以马上进行了测试。

本机环境

Windows 11 + WSL2
CPU：i7-12700K
内存：128GB，WSL 分配约 62GB
GPU：RTX 5090 32GB
SGLang：0.5.17
PyTorch：2.11 + CUDA 13.0
模型：RadixArk Qwen3.8-27B NVFP4
上下文：131K，FP8 KV，双并发

HiCache 测试

我们依次运行三个不同的 50K 会话，总量超过 GPU KV Pool，再回访第一个会话：

测试过程和结果：

第一次打开会话 A
- 缓存命中：0
- 首字延迟：7.73 秒
立即回访会话 A
- GPU 缓存命中：约 49K tokens
- 首字延迟：0.44 秒
依次运行 B、C 两个 50K 会话后，再回访 A
- 缓存命中：0
- 首字延迟：7.86 秒

这说明 GPU Radix Cache 工作正常：立即回访时，首字延迟从 7.73 秒降至 0.44 秒；运行 B、C 后，A 的缓存已经被 GPU KV Pool 淘汰。

开启 24GB HiCache 后，服务可以正常启动，并成功分配：

约 12.8GB 普通 KV 缓存
约 11.2GB Mamba 缓存
/health 正常，日志显示 hierarchical=True

但第一条 50K 请求在把 KV 从显存写入内存时崩溃。

两种官方 I/O 模式都测试了：

kernel：CUDA illegal memory access
direct：程序段错误退出

因此，当前这套 RTX 5090 + SGLang 0.5.17 + Qwen3.8 NVFP4 Hybrid 组合暂时还不能稳定使用 HiCache。

这不代表 HiCache 方案本身有问题。文章实测是 4090D 48GB + FP8 模型，与我们的 5090/NVFP4 环境不同。

如果版主或 Neo 有已经跑通 RTX 5090 的具体 SGLang、CUDA、PyTorch、模型版本和启动参数，麻烦分享一下，我们可以继续复测。

再次感谢分享！HiCache 如果能在 5090 上稳定运行，正好可以解决我们之前 SGLang 已经跑通、但因多 Agent 长上下文容量不足而无法实际应用的问题。

Ben Lee

为什么还要折腾这个“缝合怪”？

前两篇分别解决了两个问题：

daniel-mtp：负责快
KVMem：负责大

传统 Full-KV 在我的单张 24GB RX 7900 XTX + Qwen3.8-27B 上，实际验证到 128K。

而 KVMem 已经让我把完整 Context 推到了 512K。

所以第三篇的问题很简单：

能不能把 daniel-mtp 的速度和 KVMem 的 512K 放到一起？

答案：

可以。

1. 硬件与软件环境

项目	配置
GPU	AMD RX 7900 XTX 24GB
GPU 数量	单卡，GPU0
CPU	Ryzen 5 9600X
RAM	64GB DDR5
PCIe	PCIe 4.0 x8
OS	Linux
ROCm	7.2.3
Backend	llama.cpp HIP
Model	Qwen3.8-27B Q4_K_M
KV	q8_0
Flash Attention	ON

编译方向：

gfx1100
GGML_NATIVE=ON
GGML_OPENMP=ON
CMAKE_HIP_FLAGS=-mllvm --amdgpu-unroll-threshold-local=600
KVMem enabled
NVMe offload disabled

2. 主要运行参数

-ngl 99
-b 2048
-ub 512
-t 6
-tb 6
--kv-dtype q8_0

--kvmem
--kvmem-budget 32768
--kvmem-gen-reserve 16384
--kvmem-block-tokens 128
--kvmem-query-policy user

MTP ON：

--spec-type draft-mtp

测试 Context：

64K：n=3
128K：n=3
256K：n=1
512K：n=3

64K / 128K / 512K 以下均使用 median of 3。

3. 最终成绩

MTP OFF

Context	Prefill	Decode
64K	774.65 t/s	28.00 t/s
128K	724.72 t/s	27.76 t/s
256K	706.54 t/s	27.87 t/s
512K	696.78 t/s	27.87 t/s

MTP ON

Context	Prefill	Decode	Acceptance
64K	741.14 t/s	41.82 t/s	49.9%
128K	697.70 t/s	41.93 t/s	50.2%
256K	678.96 t/s	41.72 t/s	49.5%
512K	669.10 t/s	39.57 t/s	45.5%

64K → 512K：Context 扩大 8×
Prefill：774.65 → 696.78 t/s
Prefill 只下降：10.05%
Decode：28.00 → 27.87 t/s
Decode 只下降：0.46%
512K VRAM Peak：18,683 MiB

ChatGPT Image Sep 27, 2026, 03_19_22 PM.png

4. 重点比较-512K：新旧 KVMem 对比

512K	rc3 KVMem	daniel-mtp × KVMem
Prefill	520.34 t/s	696.78 t/s
Decode	26.85 t/s	27.87 t/s
TTFT	1009 s	754.14 s

Prefill：+33.9%
TTFT：−25.3%
VRAM：仍然约 18.7～19.6 GiB

最终的结果是几乎没有损失得继承了两者的优点，所以KVMem × daniel-mtp不仅仅是“缝合怪”，更是强强联合。

编译建议

建议不要直接使用通用预编译包，而是在本机按 gfx1100 重新编译。我的口径是：

ROCm 7.2.3
AMDGPU_TARGETS=gfx1100
GGML_NATIVE=ON
GGML_OPENMP=ON
CMAKE_HIP_FLAGS=-mllvm --amdgpu-unroll-threshold-local=600
LLAMA_KVMEM=ON
KVMEM_BUILD_LLAMA=ON
KVMEM_ENABLE_NVME=OFF

核心思路就是：

以 daniel-mtp 高性能源码树为底座，把 KVMem patch 移植进去，再针对 gfx1100 本机重新编译。

不建议把两个已经编译好的 binary 当插件式方案直接拼接。

5. 放进 Hermes 以后

实测：

Chat：✓
Streaming：✓
Tool Calls：✓
500K append-only Session：2.6～4.3 s / turn
Compression 后继续：2.59 s
VRAM Peak：19,584 MiB

第一次长 Context 建立以后：

正常只追加的长会话，后续交互速度完全可以接受。

但目前有一个很重要的限制：

前缀不能随便改。

任何：

System Prompt 改写
历史消息修改
中段插入
前缀发生变化

都可能触发整段 re-prefill。

176K 实测：

289 s，约 4.8 分钟

另外：

/v1/embeddings：暂不支持
并发请求：目前表现为串行排队
多 Agent 可以等，但没有真正并行

所以目前最合适的使用方式就是：

把完整长文件建立成基态，然后持续追加提问。

6. Recall发现的问题

500K 级极端 Recall：

budget 32768

15 / 20 = 75%

budget 65536

18 / 20 = 90%

主要错误形式：

错针 / value binding confusion

目前观察到：

40～60% 中段相对较弱
增大 KVMem budget 后 Recall 有改善
但还不是 100%

另外又做了主 KV 精度 A/B：

KV	Recall
q8_0	18/20
f16	18/20

而且错针完全相同。

f16 代价：

VRAM 多约 2,326 MiB

所以至少在这一组测试里：

q8_0 并不是 Recall 损失的主要原因。

我继续用：

q8_0 + KVMem

7. 为什么我觉得 KVMem 值得折腾？

它最大的意义并不是：

“512K 这个数字看起来很大。”

而是它可以完成 Traditional Full-KV 在这张 24GB 卡上做不到的事情。

我的实测：

Traditional Full-KV：实际验证到 128K
256K / 512K Traditional：没有跑过，不做性能结论
KVMem：512K 已实际跑通

所以严谨一点说：

在我这套单张 24GB RX 7900 XTX + 27B 的测试里，超过 256K 的完整文件，目前只有 KVMem 这条路线被我实际跑通。

分块和 RAG 当然也能处理大文件，但那是另一种思路。

我这里想要的是：

让完整文件直接处在同一个长 Context 里。

KVMem 买到的核心东西就是：

用有限的 active KV window，换取更长的完整 Context。

当然，500K Recall 仍然存在错针，KVMem 不是无损长上下文，也就是说上下文取回的准确率还不是100%。这一点我会发一个ticket跟作者沟通。

8. Hermes 压缩设置注意事项

我目前 Hermes 的配置：

context_length = 230000
compression.threshold = 0.75
target_ratio = 0.25
protect_last_n = 30
protect_first_n = 3

Compression 触发点看的是 Hermes 自己的 context_length。

所以即使后端已经支持 512K，如果这里仍然是：

Hermes 还是会大约在 166K 左右开始压缩。

如果以后同步改成：

按当前公式推算，第一次 Compression 可以推迟到大约：

378K

所以对 Hermes 来说，KVMem 的实际价值不是取消 Compression，而是：

让 Agent 在压缩之前，可以保留更长的原始历史。

9. 总结

64K：774.65 / 28.00
128K：724.72 / 27.76
512K：696.78 / 27.87
512K VRAM：约 18.7 GiB
64K → 512K：Prefill −10.05%
Decode：−0.46%
512K 对 rc3：Prefill +33.9%
Hermes append-only：2.6～4.3 s / turn
Recall：32K budget 75%，64K budget 90%

**7900XTX 24GB 单卡，Qwen3.8 27B，完整 512K 上下文，能不分块处理超过256K大小的文件 ——这就是 KVMem 对我的意义。 **

Ben Lee

@terry 特哥，花了两天时间，把底座调优了，加上DFlash2，原地起飞了，

https://lcz.me/topic/1814

Ben Lee

补充更新（10 月 1 日）：Strata 升级 + RDNA3 WMMA，Prefill提升约 18%

上一篇测试使用的是：

Strata v0.1.27

搜到了一个好东西RDNA3 WMMA 优化。又肝了一晚，把测试环境升级到了：

Strata v0.1.31 + PR #313

原来的生产 tree 没动，另外开了独立 worktree 编译测试。

结果相当直接：

单卡 RX 7900 XTX，192K Context

Prefill：1081.3 → 1268.5 t/s

Decode：58.2 → 58.7 t/s

也就是说：

Prefill +17.3%，Decode 基本不变。

而且这不是某一个短 Context 的偶然高点。

我按统一口径重新跑了：

8K / 32K / 64K / 128K / 192K

每档：

2 次 warmup
3 次正式测试
使用引擎自报纯 Prefill
Context 按整数档重新构造
其它运行参数保持一致

结果如下：

Context	实际 Prompt	原版 Prefill	WMMA Prefill	提升
8K	8,095	1209.2	1413.6	+16.9%
32K	32,416	1211.8	1438.9	+18.7%
64K	64,836	1206.8	1417.8	+17.5%
128K	129,677	1143.8	1351.6	+18.2%
192K	194,517	1081.3	1268.5	+17.3%

五档平均提升大约：

+17.7%

这次优化是什么？

这次用的是 Strata 的：

RDNA3 WMMA PR #313

它的前身是 PR #260，后来重新整理并以新的方式实现。

核心目的很直接：

把 RX 7900 XTX / gfx1100 上的 RDNA3 v_wmma_* 矩阵指令真正用起来。

主要包括两条路径：

Dense WMMA GEMM
WMMA Prompt Attention

也就是说，这次不是单纯改几个参数，也不是换一个更激进的 benchmark 配置。

而是：

让 gfx1100 原本没有充分利用的矩阵计算能力真正参与 Prefill。

特别感谢这条优化的作者和 Strata 维护者

为什么这次 +18% 我觉得很有价值？

因为我的 baseline 本身已经不是一个没有调过的 Strata。

上一篇那套已经包括：

gfx1100 HIP 编译
MMQ
Resident CPU Experts
本地 hipBLASLt 100202 tuning table
27 rows 全部校验 PASS
Prefill chunk 8192
5 个 CPU worker
int8 KV
32K KV resident budget

也就是说：

这不是拿一个慢 fallback 去和 WMMA 比。

而是在我上一篇已经优化过、已经跑到 1000+ Prefill 的配置上：

再稳定叠加约 18%。

这个结果比单点高分对我更有意义。

怎么开启？

PR #313 的 WMMA 默认关闭。

需要手动开启：

export STRATA_WMMA_GEMM=1
export STRATA_PA_WMMA=1

我最终使用的是：

STRATA_WMMA_GEMM=1
STRATA_PA_WMMA=1

在我这套配置上，两个开关必须一起开

我专门测试过：

只开：

STRATA_WMMA_GEMM=1

但不开：

STRATA_PA_WMMA

32K 反而变慢：

原版：1211.8 t/s

只开 GEMM：916 t/s

所以至少在我当前这套：

RX 7900 XTX
Orca IQ3_XXS
Strata v0.1.31 + PR #313

上，我最终采用的是：

WMMA GEMM + WMMA Prompt Attention 两个一起开。

不要根据“GEMM 是主要优化项”就想当然地只开一个。

编译

编译参数和上一篇第 2 节基本一致：

HIP
gfx1100
MMQ
ROCm 7.2.3

区别只是：

上一篇：Strata v0.1.27

本次补测：Strata v0.1.31 + PR #313

我是在独立 worktree 上重新编译测试的。

原来的生产 tree完全没动。

Ben Lee

️注：本文仅代表我自己机器上的实测结果，以及我自己不同配置之间的对比。肯定还有高手，欢迎分享您的方案

AMD Radeon RX 7900 XTX 是一张很有特点的显卡：24GB 显存、960GB/s 显存带宽，运行安静，放到今天看性价比依然有一定优势。

在老特的感召下，我前后买了两张这个卡，自己用了三个多月，也陆续折腾和尝试了不少不同的本地大模型部署方案，想看看这张卡到底还能挖出多少潜力。

这次准备把自己这段时间的一些测试、配置和踩坑经验分几篇整理出来，算是抛砖引玉，给同样在折腾 AMD 7900 XTX 的朋友做个参考。

也欢迎大家分享自己的配置、测试结果和优化思路，有更好的方案也请多提宝贵意见。

1. 新的 HIP build 来源

本次主要性能提升来自新的 HIP build / 编译路径

特别感谢：

llama.cpp 项目 https://github.com/ggml-org/llama.cpp
daniel-mtp 分支，HEAD 6fcaa16f4（2026-09-21），基于 llama.cpp upstream + MTP PR #28243
AMD ROCm / HIP 社区针对 gfx1100 的持续优化

2. 测试硬件与环境

项目	配置
GPU	AMD Radeon RX 7900 XTX 24GB
GPU 数量	1
CPU	AMD Ryzen 5 9600X
主板	GIGABYTE B850 AI TOP AMD AM5 ATX Motherboard
系统内存	64GB DDR5
PCIe	PCIe 4.0 x8（主机安装双卡后该槽位工作在 x8；本篇测试仅使用 GPU0 单卡）
OS	Linux
ROCm	7.2.3
Backend	llama.cpp HIP
Model	Qwen3.8-27B Q4_K_M
GPU offload	`-ngl 99`
Flash Attention	`-fa on`
Batch	`-b 2048`
UBatch	`-ub 512`
KV	q8_0 主测，128K Full-KV 已完整验证；更大上下文可考虑 `q4_0`
MTP	模型自带 nextn head
GPU arch	gfx1100
Compiler	ROCm clang
`GGML_NATIVE`	ON
`GGML_OPENMP`	ON
HIP flag	`-mllvm --amdgpu-unroll-threshold-local=600`

3. Cold Prefill 性能

Server 实测

Context	Prompt tokens	Prefill
32K	32,741	882.98 tok/s
64K	65,474	763.74 tok/s
128K	130,941	607.22 tok/s

llama-bench 独立复核

Context	Prefill	样本稳定性
32K	886.13 tok/s	σ = 2.81
64K	764.87 tok/s	σ = 0.58
128K	606.43 tok/s	σ = 0.11

Server 与 llama-bench 基本重合，这说明测试结果具有较好的可重复性：

32K: 882.98 vs 886.13
64K: 763.74 vs 764.87
128K: 607.22 vs 606.43

llama-bench 更接近底层纯性能测试，用来观察模型和后端本身的 Prefill 吞吐；llama-server 则更接近实际部署场景，还包含服务端请求、tokenization、调度等额外路径。

两套独立测试在 32K / 64K / 128K 三档都高度一致，说明这里的 Prefill 数字不是单一 benchmark 工具或服务端计时方式造成的偶然结果，可以作为后续配置对比的稳定基线。

4. 对比我之前的旧 build-rocmfp4 路线。

已确认的主要差异：

项目	旧 baseline	当前配置
GPU	RX 7900 XTX 24GB，单卡	RX 7900 XTX 24GB，单卡
Model	Qwen3.8-27B Q4_K_M	Qwen3.8-27B Q4_K_M
Backend	llama.cpp / ROCm HIP	llama.cpp / ROCm HIP
Build	`build-rocmfp4`	`daniel-mtp` HIP build
ROCm	7.2.x 环境	7.2.3
KV cache	`q4_0`	`q8_0` 主测；`q4_0` 可根据情况自行配置
Flash Attention	ON	ON
GPU offload	Full GPU offload	`-ngl 99`
当前编译目标	旧 build 原配置	`gfx1100` 单架构
Compiler	旧 build 工具链	ROCm clang
`GGML_NATIVE`	旧 build 原配置	ON
`GGML_OPENMP`	旧 build 原配置	ON
HIP compile flag	旧 build 原配置	`-mllvm --amdgpu-unroll-threshold-local=600`

注：旧 build 与当前 build 并不是严格的单变量源码 A/B，因此本文把结果表述为“旧部署 build → 当前 HIP build 的整体提升”，不把全部增益强行归因给某一个单独编译参数。

后续我又在当前同一个 build下补做了 q4_0 vs q8_0 KV A/B，结果 Prefill 几乎完全一致，因此可以排除“这次提升主要来自 KV dtype 改变”这一解释。

Prefill 对比

Context	9/25 旧 build	当前 build	提升
32K	725.98	882.98	+21.6%
64K	574.16	763.74	+33.0%
128K	~406	607.22	约 +49.6%

上图可以看出，新 build 不仅整体 Prefill 更高，随着 Context 增长，性能衰减也明显更缓。

最后附一张对比图结尾。

后面的帖子里，我会继续介绍基于这套底座延伸出来的新玩法；这也是这篇帖子里 KV 只以 q8_0 为主测的原因。

Ben Lee

@farmer-node 看的这么仔细啊，感谢关注哈～这个参数确实是我之前加过的。后来升级到新版 SGLang（f84475c）之后，官方把它移除了，我当时的第一反应真的就是"天塌了" 不过好在找到了替代方案 --enable-mixed-chunk，思路类似但实现更干净，效果还略好一丢，所以现在的 production 就没再单独加回那个参数了。

这段过程我在续一里写过，在测试数据后面的"附录：小白折腾记"那部分，第一节”一、N=1 没了，天塌了“，有兴趣可以翻一下：https://lcz.me/topic/1740

Ben Lee

7900 XTX 的可能性探索｜双卡篇（一）：魔改 SGLang + DFlash2 + HiCache，200+ t/s 与多 Agent 的丝滑体验

之前发的是单卡篇，现在开始水7900XTX双卡篇。

话说我给自己的双卡7900XTX这台机器目前配有四套日常生产配置，各有各的场景。但是我日常最愿意挂着的，还是魔改 SGLang + DFlash2 + HiCache这套。

场景	用哪套
日常主力、多文档切换、多Agent并发	魔改 SGLang 27B（跟以前发的帖子比，这是升级版，最新生产配置见末尾）
单卡推理，另一张卡出图	单卡 DanielMTP 27B（单卡篇一，最新生产配置见末尾）
要一个大模型做深度推理	Flash Next 125B（单卡篇四）
27B和Flash Next既要又要	双卡独立（双卡篇二）

这篇的重点不是"双卡比单卡快多少"——倒也不是说不快——但是我一两个月使用下来觉得真正决定体验的，是 SGLang 高并发速度和高速缓存命中带来的丝滑流畅的使用体验。

测试硬件与环境

项目	配置
CPU	AMD Ryzen 5 9600X
主板	GIGABYTE B850 AI TOP AMD AM5 ATX
系统内存	64GB DDR5
GPU	AMD Radeon RX 7900 XTX 24GB × 2
PCIe	PCIe 4.0 x8（安装双卡后该槽位工作在 x8）
OS	Linux
ROCm	7.2.3

两个后端在同一台机器上分别测试，模型不同：

	单卡 DanielMTP	魔改 SGLang DFlash2
后端	llama.cpp HIP	SGLang
模型	Qwen3.8-27B-Uncensored Q4_K_M（GGUF）	Qwen3.8-27B W4A16 AutoRound GPTQ
卡	GPU0 单卡（测试成绩是 PCIe 4.0 x8 下测的，单插还能更快些）	双卡 TP=2
视觉	支持（mmproj-F16）	模型带 vision_config

一、先看测试成绩

1.1 生成速度（TG）与首处理速度（PP）

列表同一脚本、同一测量方法（但是很奇怪我发现SGLang的DFlash2对中英文敏感，英文prompt掉速）：

上下文	PP 单卡	PP SGLang	TG 单卡 (EN)	TG SGLang (EN)	TG SGLang (ZH)	TG SGLang (CODE)
8K	886 t/s	1,766 t/s	90.3 t/s	250.4 t/s	250.4 t/s	250.2 t/s
32K	770 t/s	1,530 t/s	80.3 t/s	231.0 t/s	231.1 t/s	230.8 t/s
64K	593 t/s	1,294 t/s	69.8 t/s	76.0 t/s	208.8 t/s	209.5 t/s
128K	459 t/s	995 t/s	54.9 t/s	74.6 t/s	172.5 t/s	172.4 t/s

素材口径：EN = 英文段落重复拼接，ZH = 中文段落重复拼接。单卡侧只测了 EN。SGLang 在 EN 素材 64K 之后 TG 掉到 76 t/s（我也不理解为什么会这样），换成中文素材或测coding则不掉档（208.8 / 172.5）。

1.2 缓存容量对比

单卡 DanielMTP 27B	魔改 SGLang DFlash2 27B
显存内KV	246K tokens	166K tokens
宿主内存	`--cache-ram 24576`（24 GB）	hicache 332K tokens
合计	约 246K tokens	缓存池理论合计容量：约 498K tokens
超容量行为	CPU 空转卡死（原因不明）	优雅淘汰

两者的机制不同：llama.cpp 的 --cache-ram 是把历史提示词的 KV 副本放在宿主内存（PR #16391 描述为 "extra slots"），命中时热插回显存，省掉重算；SGLang 的 HiCache 是分级缓存（L1 显存 + L2 宿主内存）。单卡"合计"取显存上限 246K，不与内存副本相加。

二、实测对比

同一套测试脚本、同一组提示词、同样的测量方法，两边各跑一遍。

测试 1：连续处理 10 个不同的 3 万字文档，然后回头重问

单卡 DanielMTP	魔改 SGLang
第 1 轮（10 个文档）	每个约 39–40 秒	每个约 20 秒
第 2 轮（回头重问）	第 8 个卡死	10/10 全部命中
缓存命中后响应	无法测	0.35 – 0.52 秒

photo_2026-10-05_22-32-29 (3).jpg

测试 2：同一个 3 万字提示重复请求

单卡 DanielMTP	魔改 SGLang
首次（无缓存）	38.8 秒	21.4 秒
第 2 次（命中）	1.10 秒	0.56 秒
加速比	约 35 倍	约 38 倍

photo_2026-10-05_22-32-29 (2).jpg

测试 3：并发（8K 提示，各生成 128 token）

并发数	单卡 DanielMTP	魔改 SGLang
1	24.9 t/s	24.9 t/s
2	82.0 t/s	307.0 t/s
4	82.1 t/s	353.0 t/s

三、为什么我最后最常用的是 SGLang

不是因为它生成快——虽然它确实快（8K 有 250 t/s）。

是因为多并发，还有缓存命中后那个响应速度。

关于SGLang的多并发： N=4 时聚合 353 t/s，而单卡到 N=2 之后基本封顶在 82 t/s——因为它只有一张卡、一个 slot，请求只能排队。

关于高速缓存命中： 我上传一个 30K 文档，问一个问题，第一次要等 20 秒（模型算完 3 万个 token）。第二次再问同样的东西，缓存命中后约 0.35–0.52 秒完成响应。差了将近 40 倍。丝滑无感的体验。我双开的时候，经常要怀疑是不是 fallback 到 Deepseek Flash 了，输入 /status 一看，妥妥的还是在本地 27B 上。

这个差别在实际用的时候很直观：同一份文档反复问、多轮对话、切换几份材料——前面的内容基本都还在，不用重新算。而且吐字很快，响应迅速。SGLang 的这个高速缓存命中和响应速度真的很赞。

我的单卡 27B 那套加了 --cache-ram 24576 其实缓存机制也有（约 35 倍加速），但容量小（24GB 宿主内存大约装 7 个 30K-token 文档）——而且我在测到第 8 个文档时它挂住了，进程 CPU 空转，只能强杀。 当然 27B 单卡在日常生活中不太容易碰到我这么变态的选手，一次非要喂它 10 个 30K 的大文件。饭要一口一口吃，单卡跑 27B 大家都知道怜香惜玉的，文件肯定会悠着点来喂，卡死这种极端的情况其实不常见。

️ 这里要诚实说明三点：

SGLang 我只测到 10 个文档，没测出它的上限。 准确说法是"至少能装 10 个"，不是"上限就是 10 个"。

单卡那边 7 个是挂住点，不是"优雅淘汰点"。 这是 llama.cpp 超容量时的行为，跟 SGLang 的淘汰机制不一样。

这个挂住我还没定位到根因。 我最初的测试脚本里有大量短请求（tokenize）和长生成混跑，可能诱发了这个问题；后续需要干净的脚本复现才能下结论。这里先如实记录现象，不当结论。

四、几点踩坑记录

1. KV 量化必须对称。 K 和 V 要用同一种类型（q4_0 + q4_0，或 q8_0 + q8_0）。混搭会让 flash-attn 静默回退，慢 17–24%，而且不报错不警告。

2. 单卡 llama.cpp 跑长上下文时，--cache-ram 对多文档反复切换很有价值。 它不是把当前 active KV 从显存溢出到内存，而是在宿主内存保存可复用的 KV cache 副本，后续命中时避免重新计算。我的配置给了 24GB RAM cache。

3. -fa on 不能省。 不开会导致 KV 布局劣化 + 显存吃紧。

五、详细配置

5.1 魔改 SGLang 27B DFlash + HiCache（仅开 L1 和 L2，需要机器最好 64G 内存以上）

--model-path /data/models/Qwen3.8-27B-W4A16-AutoRound-GPTQ
--tp-size 2 --quantization gptq
--dtype bfloat16 --mamba-ssm-dtype bfloat16
--kv-cache-dtype auto --attention-backend triton
--mamba-backend triton --linear-attn-backend triton
--context-length 262144 --mem-fraction-static 0.83
--max-running-requests 4 --max-total-tokens 300000
--max-mamba-cache-size 24
--chunked-prefill-size 8192
--hicache-size 16 --hicache-ratio 2.0
--hicache-io-backend kernel
--hicache-host-memory-mode cache
--hicache-write-policy write_through
--enable-hierarchical-cache
--cuda-graph-bs-decode 1 2 4
--triton-attention-num-kv-splits 16
--reasoning-parser qwen3 --tool-call-parser qwen3_coder
--default-chat-template-kwargs '{"enable_thinking": false}'
--stream-interval 1 --trust-remote-code

# Speculative (DFLASH2)
--speculative-algorithm DFLASH
--speculative-draft-model-path /data/models/Qwen3.8-27B-DFlash2-W4A16
--speculative-num-draft-tokens 8
--speculative-draft-window-size 2048

5.2 单卡 DanielMTP（开了 `--cache-ram`，内存至少 32G）

SERVER=/data/llamacpp-danielmtp-hipbuild/bin/llama-server

-m /data/AI/models/llm/qwen38-27b-uncensored/Qwen3.8-27B-Uncensored-Q4_K_M.gguf
--mmproj /data/AI/models/llm/qwen38-27b-uncensored/mmproj-F16.gguf
--no-mmproj-offload

--host 127.0.0.1 --port 8084
--ctx-size 245760 --parallel 1
-ngl 999 -dev ROCm0
--fit off

--cache-type-k q4_0 --cache-type-v q4_0
--cache-ram 24576
--flash-attn on -b 1024 -ub 256

--spec-type draft-mtp --spec-draft-n-max 6

--jinja --chat-template-file /data/AI/models/llm/qwen-chat-template-fixed/chat_template.jinja
--reasoning auto --reasoning-format deepseek

--temp 0.2 --top-k 20 --top-p 0.9 --min-p 0.03 --repeat-penalty 1.05
--alias qwen38-27b-mtp-240k

模型：Qwen3.8-27B-Uncensored Q4_K_M（15.65 GB，自带 MTP 头）

两个后端的模型与引擎来源

	单卡 DanielMTP	魔改 SGLang
模型	Qwen3.8-27B-Uncensored Q4_K_M（GGUF，自带 MTP 头）	Qwen3.8-27B W4A16 AutoRound GPTQ
模型基础	Qwen3.8-27B（去审查版）	Qwen/Qwen3.8-27B
引擎	llama.cpp（daniel-mtp 分支编译）	SGLang
MTP 机制来源	ggml-org/llama.cpp 的通用 NextN/MTP 投机框架<br>PR #27836 · PR #28243	—
Draft 模型	内置（GGUF 自带 `blk.64.nextn.*`，无需单独文件）	incoai/Qwen3.8-27B-DFlash2

如果你也在折腾 7900 XTX，欢迎交流。我的水贴有不足之处或是您有更好的方案也请多提意见。

抡锤者

Ben Lee

帖子

7900 XTX 双卡跑 Qwen3.8-27B：vLLM vs SGLang 最终测试对比报告（基于自己的工作流）

先说结论

第一点：vLLM 和 SGLang，到底谁快

prefill（冷启动）

decode（单流输出）

第二点：vLLM 的三个硬伤

2.1、并发是串行的

2.2、前缀缓存没有生效

2.3、没有 prefill / decode 隔离

第三点：为什么我最后切到了 SGLang

3.1 我平时怎么用这台机器

3.2 我的测试方法，对应的是我实际会遇到什么

3.3 SGLang 真正的三个杀手锏

① RadixAttention（前缀树缓存）

② HiCache 三级缓存：L1 显存 / L2 内存 / L3 磁盘

③ DFLASH 投机解码（专门训练的草稿模型）

3.4 但我必须说清楚两件事

一、DFLASH 有精度代价

二、L3 那层我们没跑通

3.5 我的正式生产参数

A. 我们的配置（跑出本文所有数字的那套）

HiCache（只用到了L1/L2两级缓存）

DFLASH

B. flyer666 仓库 README 的最新推荐（2026-09-11 实测）

两套配置的差异一览

3.6 一句总结

第四点：致敬三个人

机智罗_LX（B站）

抡锤者老特（油管 / lcz.me）

flyer666（Steven 大神）

第五点：官方抛弃 RDNA3，其实也无可厚非

附：完整数据表（全部 2026-09-18 本机实测）

decode 单流，tokens/s

冷启动 prefill，tokens/s（括号为 TTFT）

并发 96K 完成时间，秒

热恢复 TTFT，秒

插入干扰（冷 prefill 打断长输出）最大间隔

长输出 gen512

测试口径声明（防止有人对不上数字）

相关链接

常用指标与术语

引言

结论先行

1. 裸性能：llama-bench

报告范例

2. API / 实际使用：GuideLLM

报告范例

3. 多并发 / Serving：inference-perf

报告范例

4. 最终用户体验：MLPerf Client

报告范例

那论坛大家发帖分享什么？

Context 建议

摘要表

总之

7900 XTX 的可能性探索｜单卡篇（五）：与时俱进！hipfire DFlash 实测 Qwen3.8-27B MQ4-XTS：8K Decode 169.4 tok/s，Prefill 2682 tok/s

前言/致谢

测试摘要

一、测试环境

二、DFlash 单卡完整结果

三、AR / MTP / DFlash 横向对比

Decode

Prefill

四、长上下文表现

五、关于 τ、VRAM 和测试口径

1. τ 不是 Acceptance Rate

2. VRAM 是采样参考值

3. 测试是 Cold Context

六、部署与启动参数

七、最后的说明和一点个人感想

个人一点感想

Newegg 当前新卡价格参考

1. 为什么我又来折腾 KVMem

2. KVMem 到底解决什么问题？

3. 测试环境、部署方法和参数

硬件与环境

KVMem 版本

好消息：PR #34058 实测有效，`N=1` 基本解决 long-prefill starvation