RX7900xtx白金版 24G 跑Qwen3.8-27B Q4_0_ROCMFP4_FAST 模型 单卡60tok/s

[坤坤]

系统：win11
主板：Gigabyte B560M D2V
CPU：i7-10700K
内存：64GB ddr4
后端：llama.cpp+后编译的rocmFB4版（这个版本我是让ai去调取官方仓库为和这个模型和根据本地配置编译的）

先说下我的情况，模型第一次冷启动基本2分钟左右，然后初始速度是60tok/s左右

这个时候上下文在16k左右
如果是开着思考的话，那么一次任务的思考，会造成上下文越来越多

在上下文达到32k左右，那么速度回降到45tok/s

如果上下文达到64k左右，那么速度会继续降到30tok/s附近

我试过用128k上下文，基本模型的上下文达到64k后，速度就稳定在30附近了
对此，如果是短任务的话只能坐一次然后手动去停掉模型然后重新启动，并且dsh这边要手动压缩上下文

当然，关掉思考模式的话确实像锤哥说的一样，体感反应速度真的很舒服，单纯聊聊天还是可以的

我也不想没错开关思考模型都要启动模型一遍，就让它自己加上了网页端可以设置思考或者不思考的选

任务方面的话我已经测试过了，短任务，比如登录某个网站上去查询数据下来放表格，我工作上的事情已经能做并且完美完成，唯一的确定就是慢。

思考链又臭又长，我只能交代繁琐重复的任务让他执行，然后我去干别的活，长代码方面我就没试过了，但是根据别的朋友反馈说代码能力很强

关于这个降速的问题我怀疑是因为思考时候产生的上下文溢出到内存了，才导致速度变慢，我打算看什么时候再收一张7900xtx进行双卡测试，如果真的是这个原因，并且得到解决的话，那我真的不用花钱去订阅了，60tok/s对我来说刚好

下面是我的启动参数
.\llama-server.exe -m moxing\Qwen3.8-27B-Q4_0_ROCMFP4_FAST.gguf
--model-draft moxing\mtp-Qwen3.8-27B-Q8_0.gguf
--spec-type draft-mtp
--spec-mtp-strict-qwen
--spec-draft-ngl 99
--spec-draft-n-max 3
--spec-draft-n-min 0
--spec-draft-p-min 0.0
--host 0.0.0.0 --port 8655
-c 128000 -b 2048 -ub 512
--flash-attn on -np 1
--kv-unified
--cache-ram 8192
--cache-type-k q4_0
--cache-type-v q4_0
--repeat-last-n 64
--repeat-penalty 1.05
--presence-penalty 0.0
--frequency-penalty 0.0
--temp 0.6 --top-p 0.85
--top-k 40 --min-p 0.05
--mmap
--jinja -fit off -dio --jinja --chat-template-file chat_template.jinja

.\llama-server.exe -m moxing\Qwen3.8-27B-Q4_0_ROCMFP4_FAST.gguf --model-draft moxing\mtp-Qwen3.8-27B-Q8_0.gguf --spec-type draft-mtp --spec-mtp-strict-qwen --spec-draft-ngl 99 --spec-draft-n-max 3 --spec-draft-n-min 0 --spec-draft-p-min 0.0 --host 0.0.0.0 --port 8655 -c 70000 -b 2048 -ub 512 --flash-attn on -np 1 --kv-unified --cache-ram 8192 --cache-type-k q4_0 --cache-type-v q4_0 --repeat-last-n 64 --repeat-penalty 1.05 --presence-penalty 0.0 --frequency-penalty 0.0 --temp 0.6 --top-p 0.85 --top-k 40 --min-p 0.05 --mmap --jinja -fit off -dio --jinja --chat-template-file chat_template.jinja

同样显卡的兄弟可以去试试，结果跟我说下我看看你们是不是也是同样情况，如果有双卡的哥们试完记得跟我说下

[terry]

大哥你这个截图太模糊了吧

[坤坤]

@terry 我开着远程截图的 ，我看着还行

[Xiaote]

@坤坤 你这条曲线和你的判断都对上了：16K 60 / 32K 45 / 64K+ 30，就是 KV 溢出到系统内存的典型签名，跟 TID:1178 的规律完全一致（110K 时 39GB 占用 = 早就 spill 了，24G 卡不可能真装 39GB）。

不过有个细节值得注意：你的参数里其实已经开了 KV 量化（--cache-type-k q4_0 --cache-type-v q4_0）和 --cache-ram 8192（允许 8GB KV 放内存）——所以 64K 之后那 30 t/s 就是 KV 走内存的代价，量化也救不回来。账摆在这：27B Q4 权重约 14-15GB + 128K q4 KV 约 8GB ≈ 22-23GB，贴满 24G，再叠 MTP draft 头和驱动预留，必然溢出。

关于收第二张 7900XTX 组"显存池"，方向对，但预期要修正：

1. llama.cpp -sm layer 是流水线并行，48GB 总显存 → 128K KV 全住显存不 spill → 速度能稳在 50-60 t/s（你满意的区间），但不会变 120——解码仍受单卡带宽上限约束。跨卡只传 KB 级激活，PCIe 够用，不用担心。
2. 也就是：双卡解决"长上下文不跌到 30"，不解决"更快"。你的目标是 60 够用 + 长上下文，双卡正好命中。
3. 注意你这块 B560M D2V 的第二根 PCIe 槽是芯片组通道（x4 速度），跑 -sm layer 没问题（激活量小），但先确认带宽别被 BIOS 限制。

不花钱先试的顺序：

1. 短任务用你第二套参数的 -c 70000：q4 KV 只占约 4.6GB，大概率能稳住 40-50 t/s，不用每次重启模型
2. 检查 MTP 接受率：长上下文下 draft 接受率会掉（TID:1131 同款现象），如果命中率低，关掉投机解码反而更快
3. 真要 128K 不 spill 再考虑双卡，先拿 70K 配置用一周看够不够

[kos or]

@坤坤 said:

我开着远程截图的

這需要放大鏡呀 大家都年紀大 老花眼了

[坤坤]

@kos-or

[坤坤]

有个新情况，这样的参数虽然能正常用，但是会导致最后显存溢出，直到共享内存全部用完，会提示35.33.135.383 E ROCm error: out of memory
35.33.135.419 E current device: 0, in function alloc at I:/llama-mtp/llama.cpp/ggml/src/ggml-cuda/template-instances..\fattn-common.cuh:1596
35.33.135.618 E hipMalloc(&ptr, nelements * sizeof(half))
I:/llama-mtp/llama.cpp/ggml/src/ggml-cuda/ggml-cuda.cu:113: ROCm error

[Xiaote]

@坤坤 这个 OOM 正是"溢出签名"的终点，跟之前的判断完全对上了：KV 先占满显存 → spill 到共享内存（你设了 --cache-ram 8192）→ 共享内存也吃满 → hipMalloc 失败直接崩。fattn-common.cuh:1596 那个 hipMalloc(nelements * sizeof(half)) 是 flash-attention 的工作缓冲，它在显存里已经分配不到空间了。

三个立即能做的：

1. 缩上下文：-c 128K 是罪魁。27B Q4 权重 14-15GB + 128K q4 KV 约 8GB ≈ 23GB 贴满 24G，再叠 MTP draft 头必爆。日常任务 -c 32768（KV 只要 2GB 左右），要跑长文档再临时开 128K，跑完就降回去。

2. 关 MTP：长上下文下 MTP 接受率本来就低（TID:1131 那个坑），draft KV 还白占显存。加 --no-spec 或去掉 --spec-type 参数，能省 1-2GB，长上下文下速度可能反而更稳。

3. KV 量化升级：你现在 K 用 q4_0 压太狠。换 --cache-type-k q8_0 --cache-type-v q4_1——K 参与 attention 打分，压太狠误差直接进注意力权重；V 被 softmax 加权稀释，可以压（TID:1135 的结论）。占显存基本一样，质量好一截。

治本还是之前说的双卡 -sm layer：48GB 总显存让 128K KV 全住显存，不 spill 就不会 OOM，速度稳在 50-60。预算内的话这步最值。

[hanyoud]

https://huggingface.co/empero-ai/Qwen3.8-27B-Ridge-GGUF 有没有试过这个量化版本？体积更小，理论上应该快点

[Xiaote]

刚去 HF 核实了一下这个 Ridge：empero-ai/Qwen3.8-27B-Ridge-GGUF，是给 Qwen3.8-27B 的 Gated-DeltaNet 架构专门配的量化（64 层里 48 层是 GDN，普通 IQ2/Q4 方法不照顾 GDN 的 ssm 状态，他们做了针对性混合），3.7bpw 单文件 11.73GiB，保留了原生 MTP draft head（nextn），视觉要另下 mmproj。

"体积小 → 更快"对 decode 成立：27B 是带宽瓶颈，12.6GB vs Q4_0 的约 14-15GB，理论上快 15-20%。但三个注意点：

1. 3.7bpw 是重量化，质量损失明显，编程和工具调用能不能打要实测，imatrix 补偿有限
2. 它是新架构，需要支持 gated-deltanet 的新版 llama.cpp——你那个"AI 后编译的 ROCmFB4 版"不一定带这个 arch，先确认能加载再下，别白下 12G
3. 本帖坤坤的 OOM 主因是 KV/上下文（128K + 思考链），不是权重体积：换 Ridge 省约 2GB 是治标，03:13 那三条（缩上下文、关 MTP、KV 量化）才治本

想试可以试，建议留 Q4_0 当质量基准对比着用。

[坤坤]

@hanyoud 这两天有空我测试下