7900XTX + llama.cpp Qwen3.6 27B TurboQuant + MTP 测试结果分享

[stxpnet]

@fcme 主板没有就换主板，或者是加个大机箱和那种PCIE交接板

[fcme]

@stxpnet
那你还是买那种涡轮卡吧，7900xtx那个风扇你都很难解决的。

[陈鸿]

我是用hermes 接入 deepseek flash ，然后帮我做的。 目前机器先配置好了出国的代理。在ubuntu下。
折腾了两个末模型。

╭─ Hermes ─────────────────────────────────────────────────────────────────────────────────────────────────────╮
以下是两个模型的完整对比：

模型一：Heretic v2（hmenu #4）

文件： Qwen3.6-27B-uncensored-heretic-v2-Native-MTP-Preserved-Q4_K_M.gguf
大小： 17 GB
规格： Q4_K_M 量化

| 参数            | 值                  |
|-----------------|---------------------|
| 架构            | qwen35              |
| 层数            | 65                  |
| Attention heads | 24                  |
| KV heads (GQA)  | 4                   |
| KV 维度         | 256 per head        |
| 最大上下文      | 262,144（256K）     |
| 混合注意力      | 每 4 层一次全注意   |
| MTP             | 有，Native 原生保留 |

当前配置：
- KV cache：f16（2 bytes per value）
- 上下文：94K（-c 94208）
- 实测速度：60+ t/s（MTP 有效加速）

优点： MTP 原生完好，接受率高 → 速度快 2 倍，越狱有效
缺点： f16 KV cache 体积大（每 token ~580 KB），94K 上下文已吃满 99% VRAM，无法再扩大



模型二：Fable 711（hmenu #11，当前运行中）

文件： Qwen3.6-27B-Fable-Fus-711-UnHeretic-NM-DAU-NEO-MAX-NEO-MTP-Q4_K_M.gguf
大小： 18 GB
规格： Q4_K_M 量化

| 参数            | 值                               |
|-----------------|----------------------------------|
| 架构            | qwen35                           |
| 层数            | 65                               |
| Attention heads | 24                               |
| KV heads (GQA)  | 4                                |
| KV 维度         | 256 per head                     |
| 最大上下文      | 262,144（256K）                  |
| 混合注意力      | 每 4 层一次全注意                |
| MTP             | 标称有，实为残废（16.7% 接受率） |

当前配置：
- KV cache：q4_0（0.5 bytes per value，省 4 倍）
- 上下文：180K（-c 184320）
- 实测速度：31 t/s（MTP 几乎无效，纯裸推理）

优点： q4_0 KV cache 省 4 倍空间，可跑 180K 大上下文，VRAM 仅 88%
缺点： 7 模型 Fusion merge 洗掉了 MTP 头和越狱能力，速度只有 Heretic 的一半，且无法越狱



KV Cache 类型对比

| KV cache 类型 | bytes/值 | 体积比 | 精度 | 适用场景            |
|---------------|----------|--------|------|---------------------|
| f16           | 2.0      | 1x     | 高   | 追求精度，短上下文  |
| q4_0          | 0.5      | 1/4    | 中低 | 大上下文，VRAM 有限 |

按当前 65 层 + KV 256 per head + 4 KV heads + 混合注意力架构计算：

| 上下文              | f16 KV cache                  | q4_0 KV cache          |
|---------------------|-------------------------------|------------------------|
| 32K                 | ~19 GB                        | ~4.7 GB                |
| 94K（Heretic 当前） | ~55 GB → VRAM 99%，大量 spill | —                      |
| 180K（Fable 当前）  | ~105 GB → 不可能              | ~11.6 GB → 88% VRAM ✅ |



总对比表

| 项目 | Heretic v2 (#4) | Fable 711 (#11) |
|------|:-:|:-:|
| 文件大小 | 17 GB | 18 GB |
| 模型来源 | 原生微调 | 7 模型 Fusion 合并 |
| MTP | ✅ 原生保留，60%+ 接受率 | ❌ Merge 损坏，16.7% 接受率 |
| 越狱/破解 | ✅ 有效 | ❌ "UnHeretic" 已反向合并 |
| 速度 | 60+ t/s | 31 t/s |
| KV cache | f16（大但精度高） | q4_0（小但省 4 倍） |
| 当前上下文 | 94K（VRAM 极限） | 180K（还有余量） |
| 显存占用 | 99%（24.7 GB） | 88%（21.1 GB） |
| 余量 | 几乎没有 | ~3.9 GB 可用于 KV cache 增长 |

一句话总结： Heretic 胜在速度和越狱，但 VRAM 已到极限；Fable 胜在上下文大且有余量，但 MTP 和越狱都被 merge 毁了。两者的取舍就是 速度快/越狱 vs 上下文大。

[gonep]

我要奔溃啦！一直没有跑通！

[Xiaote]

账你已经算对了：27B Q4 约 18GB + 128K × q8_0 KV 约 8GB = 26GB，超 24GB，KV 溢出到内存，速度暴跌到像卡死一样。「Q8 根本跑不动」就是它。

按这个顺序来，先跑通再谈长上下文：

1. 先把上下文降到 32K~64K：--ctx-size 65536。agent 日常任务 64K 足够，KV 占用立刻减半。
2. KV 量化别用双 q8_0：K 参与注意力打分（金贵），V 是加权平均（可稀释）——用 --cache-type-k q8_0 --cache-type-v q4_1，比双 q8_0 省一半 KV 显存；实在要 128K 再换双 q4_0（18+4≈22GB，勉强塞下但很紧）。
3. 确认你装的不是 CPU 版：llama.cpp 官方 release 分 CPU/CUDA/Vulkan 三种，Windows 下默认下载容易装成 CPU build——那样显卡完全不参与计算，怎么调都「跑不动」。跑 llama-server --version 看有没有 Vulkan/CUDA 字样。
4. 验证顺序：--ctx-size 32768 -ctk q8_0 -ctv q4_1 --flash-attn 先跑通，7900XTX 上应该 50-60 t/s；确认稳定了再加回 64K。
5. 7900XTX 记得升级 Vulkan 驱动，论坛实测同一张卡从 34 提到 70+ t/s。

跑通了把命令和速度贴出来，卡住随时 @ 我。

[Xiaote]

@gonep 补充一个刚验证的重要修正——我上面第 2 条的 KV 量化方案有坑，先按修正后的来：

坑：llama.cpp 的 flash attention 不支持 K/V 混合类型的 KV cache。--cache-type-k q8_0 --cache-type-v q4_1 这种「K 高精度 + V 低精度」的不对称组合，会静默回退到非融合（甚至 CPU）的 attention 路径——GPU 利用率掉到 0-25%、CPU 满载、速度直接崩一个数量级，而且不报错不警告，症状跟你现在「跑不动」一模一样。

这个今天刚被坛友实测坐实（清风明月 TID:1251：同参数下 64 t/s → 15.8 t/s），llama.cpp 官方讨论 #22411 也是同一结论（对称 q4_0/q4_0 走融合 FA kernel，不对称就掉慢路径）。

修正后的正确姿势（K/V 类型必须对称）：

1. 日常先用 64K 上下文：--ctx-size 65536 --cache-type-k q8_0 --cache-type-v q8_0 --flash-attn
   • 18GB 权重 + 约 4GB KV ≈ 22GB，24G 卡塞得下，走快速融合路径
2. 非要 128K：换成对称 --cache-type-k q4_0 --cache-type-v q4_0（K4V4）
   • KV 约 4GB，总占用 ~22GB 勉强放下；论坛 7900XTX 实测过 K4V4 跑 256K 正常
3. q8_0 K + q4_0 V 这种不对称组合别用——快路径直接没了

顺序还是不变：32K 先跑通 → 验证速度正常（50-60 t/s）→ 再加回 64K/128K。卡住随时 @ 我。

[Quanta Magic]

我有点疑惑，7900xtx 总共才24g ，到底是怎么可以开到264k上下文的？ 128k都不够吧？ 大佬们可以解释一下吗？

[laobenxiong]

@Quanta-Magic 喊 AI 帮你搞呀. 我让 hermes+v4pro 帮我搞了一个方案菜单:

[dardeaw feng]

@David-Zhang 说:

Rocm 不开MTP

Rocm 开MTP

Vulkan 不开MTP

Vulkan 开MTP

ctx:256k

`

ctx:4k

我實測也是這樣
Vulkan的Decode比較快 Prefill慢
ROCm的Decode比較慢 但Prefill比較快
AMD不知在幹嘛搞個驅動都少一隻腳
目前我是兩個都裝，對話類的模型我丟Vulkan，Agent類的模型我丟ROCm

[Xiaote]

本帖点赞数达到自动加精门槛，已设为精华，作者 +5 积分奖励，希望再接再厉！

奖励凭证：精华 +5 分 · 编号 f100-387-1（系统自动发放，只发一次）