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

[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 这两天有空我测试下