7900XTX + llama.cpp Qwen3.6 27B TurboQuant + MTP 测试结果分享
-
@David-Zhang 可以請教, 為什麼你和老特都不推薦 ollama , 推llama.cpp呢? 我也是先問了AI, 它說你們應該是覺得 ollama 雖然是容易上手, 但可調教的參數太少. llama.cpp 才是真正的生產工具. 沒說錯嗎?
-
@566656661 對呀. AI也是這樣回覆我. 剛巧看到了一個reddit同樣的疑問:
https://www.reddit.com/r/LocalLLaMA/comments/1mdma9a/help_choosing_between_ollama_llamacpp_or/
說的很清楚了. 我想我也用 llama.cpp 更好
-
提示后又从头读了一遍。真是时间是一切的验证。
现在我也是小霸王学习机的拥有者。7900XTX 还真就是折腾优选之一。
经过10多天的折腾。pro 5000 72G 终于组装上了。被动赚了京东几千块。事实就是吃馅饼都是要买单的。哈哈。 -
-
-
-
-
-
我是用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 上下文大。 -
-
账你已经算对了：27B Q4 约 18GB + 128K × q8_0 KV 约 8GB = 26GB，超 24GB，KV 溢出到内存，速度暴跌到像卡死一样。「Q8 根本跑不动」就是它。
按这个顺序来，先跑通再谈长上下文：
- 先把上下文降到 32K~64K：
--ctx-size 65536。agent 日常任务 64K 足够，KV 占用立刻减半。 - KV 量化别用双 q8_0：K 参与注意力打分（金贵），V 是加权平均（可稀释）——用
--cache-type-k q8_0 --cache-type-v q4_1，比双 q8_0 省一半 KV 显存；实在要 128K 再换双 q4_0（18+4≈22GB，勉强塞下但很紧）。 - 确认你装的不是 CPU 版：llama.cpp 官方 release 分 CPU/CUDA/Vulkan 三种，Windows 下默认下载容易装成 CPU build——那样显卡完全不参与计算，怎么调都「跑不动」。跑
llama-server --version看有没有 Vulkan/CUDA 字样。 - 验证顺序：
--ctx-size 32768 -ctk q8_0 -ctv q4_1 --flash-attn先跑通，7900XTX 上应该 50-60 t/s；确认稳定了再加回 64K。 - 7900XTX 记得升级 Vulkan 驱动，论坛实测同一张卡从 34 提到 70+ t/s。
跑通了把命令和速度贴出来，卡住随时 @ 我。
- 先把上下文降到 32K~64K：
-
@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 类型必须对称）：
- 日常先用 64K 上下文：
--ctx-size 65536 --cache-type-k q8_0 --cache-type-v q8_0 --flash-attn- 18GB 权重 + 约 4GB KV ≈ 22GB，24G 卡塞得下，走快速融合路径
- 非要 128K：换成对称
--cache-type-k q4_0 --cache-type-v q4_0（K4V4）- KV 约 4GB，总占用 ~22GB 勉强放下；论坛 7900XTX 实测过 K4V4 跑 256K 正常
- q8_0 K + q4_0 V 这种不对称组合别用——快路径直接没了
顺序还是不变：32K 先跑通 → 验证速度正常（50-60 t/s）→ 再加回 64K/128K。卡住随时 @ 我。
- 日常先用 64K 上下文：
-
-
我有点疑惑，7900xtx 总共才24g ，到底是怎么可以开到264k上下文的？ 128k都不够吧？ 大佬们可以解释一下吗？
@Quanta-Magic 喊 AI 帮你搞呀. 我让 hermes+v4pro 帮我搞了一个方案菜单:
-
Rocm 不开MTP
Rocm 开MTP
Vulkan 不开MTP
Vulkan 开MTP
ctx:256k
`
ctx:4k
Rocm 不开MTP
Rocm 开MTP
Vulkan 不开MTP
Vulkan 开MTP
ctx:256k
`ctx:4k
我實測也是這樣
Vulkan的Decode比較快 Prefill慢
ROCm的Decode比較慢 但Prefill比較快
AMD不知在幹嘛搞個驅動都少一隻腳
目前我是兩個都裝，對話類的模型我丟Vulkan，Agent類的模型我丟ROCm -
-
，
D Data Wu 引用了 此主题
本帖点赞数达到自动加精门槛，已设为精华，作者 +5 积分奖励，希望再接再厉！