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

[exe127]

@David-Zhang 可以請教, 為什麼你和老特都不推薦 ollama , 推llama.cpp呢? 我也是先問了AI, 它說你們應該是覺得 ollama 雖然是容易上手, 但可調教的參數太少. llama.cpp 才是真正的生產工具. 沒說錯嗎?

[566656661]

@exe127

Ollama本體就是一個llama.cpp的Fork

[exe127]

@566656661 對呀. AI也是這樣回覆我. 剛巧看到了一個reddit同樣的疑問:

https://www.reddit.com/r/LocalLLaMA/comments/1mdma9a/help_choosing_between_ollama_llamacpp_or/

說的很清楚了. 我想我也用 llama.cpp 更好

[williamlouis]

提示后又从头读了一遍。真是时间是一切的验证。
现在我也是小霸王学习机的拥有者。7900XTX 还真就是折腾优选之一。
经过10多天的折腾。pro 5000 72G 终于组装上了。被动赚了京东几千块。事实就是吃馅饼都是要买单的。哈哈。

[fcme]

5000多人民币能买到带三年质保的新卡，还有24g高带宽显存的卡也就它了吧，这性价比其实已经爆棚了
可以关注一下27b的IQ量化系列，体积小一点，质量和速度都不差的。尤其是编译的时候，把wmma开启了的话，用hip llamacpp的PP速度能提示30%以上，实用度暴增。
我双路服务器，所以都有点儿后悔买9700了，没搞两张7900XTX，容量更大，速度应该比9700快将近一倍。

[stxpnet]

我在想这卡3路或者4路叠起来是啥效果

[fcme]

@stxpnet
你电脑得有那么多的pice槽位啊，而且物理上不打架才行，除非你有当年4卡的那种矿机，我自己拿HP Z220改过4卡的，但是AI时代不行了吧，那种用的是USB。

[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都不够吧？ 大佬们可以解释一下吗？