抡锤者

abaalei

起因

最近逛论坛看到有大佬论证 X99 支持 PCIe 4.0 ，说是华强北的板厂在 BIOS 里加了 PCIe 4.0 的选项，实际也能协商到 4.0。看着挺诱人的——毕竟 X99 板子便宜，Xeon E5 v3/v4 白菜价，要是真能跑 4.0，配上两张 RX 7900 XTX 跑 LLM 的 TP（张量并行），跨卡通信带宽直接翻倍，美滋滋。
（原始贴现在因为论坛的搜索改版，已经找不回来了，大概意思就是该大佬通过几个命令，都能读出来协商的是16GB/s的带宽，然后推定x99支持pcie4.0）

但冷静下来一想：X99 的 PCIe 控制器是集成在 CPU 里的，Haswell-E/Broadwell-E 的 IMC 和 PCIe root complex 都是 Intel 定死的规格，只到 PCIe 3.0。华强北再牛逼，能改 BIOS 设置，总不能重做 CPU 的硅片吧？

于是决定不靠嘴炮，上机实测。

测试平台

项目	规格
主板	6卡直插矿板 X99-6Plus
CPU	Intel Xeon E5-2682 v4（Broadwell-EP）
被测 GPU	RTX 3080 Ti（GA102，支持 PCIe 4.0）
OS	Ubuntu Linux
测试工具	nvidia-smi / lspci / gpu-pcie-bench

本来是打算测两张 7900 XTX 的，但它们在跑推理工作中，就不打扰了。拿 3080 Ti 测，结果是一样的——瓶颈在 CPU/主板侧，不在 GPU 侧。

第一步：看协商状态

nvidia-smi --query-gpu=pcie.link.gen.current,pcie.link.gen.max,pcie.link.width.current --format=csv

结果：

1, 3, 16

current = 1：空闲降到了 PCIe 1.0，正常省电行为
max = 3：最大只支持 PCIe 3.0
width = 16：通道数正常

关键就是 max = 3——如果真解锁了 4.0，这里应该显示 4。

再来看看 lspci：

sudo lspci -s 02:00.0 -vvv | grep -E "LnkCap|LnkSta"

LnkCap: Speed 8GT/s, Width x16
LnkSta: Speed 2.5GT/s (downgraded), Width x16

LnkCap（能力）：Speed 8GT/s = PCIe 3.0（Gen3 = 8GT/s，Gen4 = 16GT/s）
LnkSta（当前）：Speed 2.5GT/s = 空闲降到了 Gen1
（这里其实存在一个问题，之前看到贴子的时候，汇报是Speed 16GT/s，可能是指那2张7900xtx吧）

到这里已经很明显了：硬件能力上就不支持 Gen4。

第二步：实际跑带宽

协商是一回事，实际能不能跑出那个速度是另一回事。上 gpu-pcie-bench（https://github.com/tpoechtrager/gpu-pcie-bench）做实际 PCIe 吞吐测试。

# 安装
git clone --depth=1 https://github.com/tpoechtrager/gpu-pcie-bench.git
cd gpu-pcie-bench && make

# 跑测试
./bin/x86_64/gpu-pcie-bench --device 0 --rounds 50 --direction both --unit gb

实测结果：

Buffer 大小	Host→Device（CPU→GPU）	Device→Host（GPU→CPU）
512 KB	9.30 GB/s	9.73 GB/s
1 MB	10.03 GB/s	10.54 GB/s
10 MB	11.33 GB/s	11.47 GB/s
100 MB	9.05 GB/s	4.36 GB/s
1 GB	8.99 GB/s	5.13 GB/s
2 GB	8.98 GB/s	5.14 GB/s

对比理论值：

标准	理论单向带宽	实测典型值
PCIe 3.0 x16	~15.75 GB/s	~9-11.5 GB/s 符合预期
PCIe 4.0 x16	~31.5 GB/s	差得远
PCIe 3.0 x8	~7.88 GB/s	大 buffer D2H 接近这个值

注意大 buffer 的 Device→Host 掉到 ~5 GB/s，这个是因为 Xeon E5-2682 v4 的 DDR4 内存带宽成了瓶颈——数据从 GPU 读回来要写进系统内存，老平台的内存控制器跟不上。这进一步说明：哪怕 GPU 再快，整个平台的 PCIe 子系统的天花板就在那里。

结论：所谓的"魔改 PCIe 4.0"到底是什么？

拆穿来看，无非是三件事：

GPU 端是真支持 Gen4——RTX 3080 Ti 和 RX 7900 XTX 自身都支持 PCIe 4.0，会向上报 Capability
寨板焊了 Gen4 的 retimer/switch 芯片——为了兼容性，物理层芯片用支持 4.0 的
BIOS 菜单直接从 GPU 的 Capability 里读选项显示出来——但实际 CPU-PCH 的链路仍然是 Gen3 握手

一句话总结：

插槽是 4.0 的皮，链路是 3.0 的芯。

PCIe 协商是双向的——一方说 4.0 没用，双方都支持才是真 4.0。CPU 那端的 root complex 不支持，插宇宙最快的显卡也没用。

对 X99 双卡跑 LLM 的启示

如果你像我一样，想在 X99 上插两张卡跑 TP（张量并行），除了确认是 3.0 不是 4.0 之外，还要注意：

X99 的 CPU 只有 40 条 PCIe 通道
两张 GPU 如果都插 x16 槽，实际可能是 x16 + x8（CPU 的 PCIe lane 分配限制）
如果第二张卡是 x8，那 PCIe 3.0 x8 ≈ ~5-7 GB/s，TP 模式的通信会成为明显瓶颈
PP（流水线并行）比 TP 友好一些，但依然有影响

当然，单卡推理完全没所谓——模型加载到显存后，PCIe 只做偶尔的数据传输，瓶颈在算力和显存带宽上。

附：Windows 上怎么测？

如果是在 Windows 下，推荐：

工具	用法
GPU-Z	打开 → 点问号旁边的「Render Test」按钮 → 看 Bus Interface 那行从 `@ x16 1.1` 升到 `@ x16 3.0` 就是 Gen3，升到 `@ x16 4.0` 才是真 Gen4
AIDA64	Tools → GPGPU Benchmark，看 Host→Device / Device→Host 的带宽
nvidia-smi	Windows 版一样可以用：`nvidia-smi --query-gpu=pcie.link.gen.current,pcie.link.gen.max,pcie.link.width.current --format=csv`

快速排查命令（Linux）

# 1. 看 GPU 协商到的最大版本
nvidia-smi --query-gpu=pcie.link.gen.max --format=csv

# 2. 看 PCIe 设备能力（Gen3=8GT/s, Gen4=16GT/s）
sudo lspci -s <GPU_BUS> -vvv | grep LnkCap

# 3. 跑实际带宽（最靠谱）
gpu-pcie-bench --device 0 --direction both --unit gb

数据说话，别信 BIOS 菜单里的花活。

abaalei

如题所示，刚刚才发现机智罗在18日发布了V4升级包
对比V3版本更新内容如下：
（这个工作流适合直接扔进去Ubuntu，剩下的节点问题喊hermes下载解决即可）

https://drive.google.com/file/d/1ZweO5Yl0dLoL3ufQ-I118sNLTaU3s4CE/view?usp=drive_link

abaalei

原创折腾实录 | 2026-06-10 | RX 7900 XTX 24GB + ROCm 7.2.0

写在前面

一直以来，7900 XTX 用户在 Qwen3.6-27B 上有一个无法两全的选择：

Lucebox DFlash（~93 tok/s run.py / ~80 tok/s API ）→ 最快！但原方案极其挑食。
社区去审查模型（Huihui abliterated 等）→ 真无审查，但容易触发 DFlash 的 fattn.cu:312 崩溃。

本文记录了如何同时得到「DFlash 极速 + 真无审查」——通过 FA_ALL_QUANTS=ON 完整编译解决 Fattn 兼容性，配合 --fa-window 0 和 --tokenizer Qwen/Qwen3.6-27B 实现完美稳定运行。

🧪 硬件环境

+---------------------------+-----------------------------------------------+
| 组件                      | 详情                                           |
+---------------------------+-----------------------------------------------+
| CPU                       | Intel Xeon E5-2682 v4 × 2 (32C/64T)           |
| 主板                      |华强北白牌X99-6Plus 槽距63mm pcie3.0（16x*4 8x*2） |
| GPU — 主力推理            | AMD Radeon RX 7900 XTX 24GB (ROCm 7.2)         |
| GPU — 后处理              | NVIDIA RTX 3080 Ti 12GB (CUDA) — 未参与        |
| 系统                      | Ubuntu 24.04 LTS, Kernel 5.15.0-181           |
| Python                    | 3.12.3                                       |
| 模型                      | Qwen3.6-27B (Q4_K_M / variant)               |
| DFlash                    | Lucebox (lucebox-hub, ggml-hip)              |
+---------------------------+----------------------------------------------+

️ 强调： 本测试全程只用 7900 XTX，RTX 3080 Ti 完全不参与推理过程，避免混淆。

目标

DFlash 引擎 — Lucebox DFlash 投机解码，7900 XTX 甜点 ~93 tok/s
真·无审查 — Huihui abliterated，完全拒答阻断的解除
稳定运行 — 完整 43 轮每轮 200 token 稳定测试不崩溃

️ 完整折腾路线图（七阶段全记录）

（编者注：有agent就是好，看到论坛内的贴/X上面的贴不管有没有用就直接扔给agent进行分析匹配，然后一项项让她自己随机跑，省下不少时间，就是token烧不少了）

阶段一：初识问题 — Fattn 崩溃

社区主流 GGUF（如 Huihui Q4_K_M）在 DFlash 下会导致 fattn.cu:312: fatal error。

根因定位：
并非模型本身问题，而是 HIP 编译默认只编译了 4 组 KV-quant 模板（F16/Q4_0/Q8_0/BF16）。当 DFLASH27B_FA_ALL_QUANTS=OFF 时，Q4_K_M 模型使用的 KV cache dtype 不在这些模板中 → VEC kernel dispatch 找不到匹配 → GGML_ABORT("fatal error")。

阶段二：尝试补丁 — TILE fallback patch（失败）

最初怀疑是 VEC kernel 本身的 bug，尝试在 fattn.cu 中将 VEC 找不到时的 GGML_ABORT 改为 fallback 到 TILE kernel。

编译通过，但：

前 10~15 轮请求正常
到了 26 轮左右出现静默 segfault（zombie test_dflash 进程，BrokenPipeError）
根因：TILE kernel 在 HIP (gfx1100) 后端上不稳定，大量并发验证时触发底层内存访问越界

结论： 不需要 patch 源码，走错了方向。

阶段三：证实方向 — FA_ALL_QUANTS=ON 完整编译

放弃 patch 源码的歪门邪道，直接使用 CMake 默认的完整编译：

-DDFLASH27B_FA_ALL_QUANTS=ON (CMake 默认值)
HIP/gfx1100 成功编译全部 50+ 种量化模板
VEC 命中任意 KV quant 对，彻底解决 ggml_abort

# 强制开启完整模板编译
cmake .. -DDFLASH27B_FA_ALL_QUANTS=ON -DCMAKE_HIP_ARCHITECTURES=gfx1100
cmake --build . --target ggml-hip --clean-first -j4
cmake --build . --target test_dflash -j4

️ 重建必须 --clean-first，否则 cmake 不重编 HIP 目标！

阶段四：测试 OBLITERATUS（假无审查 + 不兼容）

OBLITERATUS 是对 Qwen3.6-27B 跑 diff-in-means 去审查的模型。结果是：

假无审查 — 对炸弹/敏感内容仍在输出安全教育
DFlash 不兼容 — 同样触发 fattn.cu:312
层数不对（65 层 vs 草稿 64 层）
已清理删除

阶段五：测试 Huihui IQ4_XS（真无审查但龟速）

Huihui abliterated 的 IQ4_XS 版本：

真无审查 — 直接回复XX步骤、BL/SQ细节
DFlash 兼容（FA_ALL_QUANTS=OFF 时唯一能跑的真无审查模版）
速度仅 28 tok/s — IQ4_XS 在 HIP 上的反量化路径不如 Q4_K_M 高效
上下文受限（~64K）

结论： IQ4_XS 已弃用（已从磁盘删除），Q4_K_M 在 FA_ALL_QUANTS=ON 下全面优于 IQ4_XS。

阶段六：测试 Heretic Q4_K_M（原生兼容但假无审查）

Youssofal 的 Heretic Q4_K_M：

原生 DFlash 兼容 — 第一版就稳定运行
早期 benchmark：68.80 tok/s（bench_he.py）
假无审查 — 号称"Uncensored"但实测仍输出安全教育/「无法提供」
已弃用，被 Huihui 全面替代

阶段七：FA_ALL_QUANTS=ON + --fa-window 0 + Huihui Q4_K_M

最终稳定核心：

FA_ALL_QUANTS=ON 解决量化模板缺失
--fa-window 0 禁用 DFlash 滑动窗口（防长文本崩溃）
--tokenizer Qwen/Qwen3.6-27B 解决 emoji 显示为方块问号的问题

最终启动参数：

python3 scripts/server.py \
  --target '/mnt/models/Qwen3.6/Huihui-Qwen3.6-27B-abliterated.Q4_K_M.gguf' \
  --draft models/dflash-draft-3.6-q8_0.gguf \
  --budget 8 \
  --fa-window 0 \
  --tokenizer Qwen/Qwen3.6-27B \
  --host 0.0.0.0 --port 11435

完整模型兼容性矩阵

模型	DFlash 兼容	去审查	速度 (API)	状态
Huihui Q4_K_M (mradermacher)	FA_ALL_QUANTS=ON	真	~81 tok/s	推荐
Heretic Q4_K_M (Youssofal)	原生	假	~69 tok/s	已弃用
~~Huihui IQ4_XS~~	OFF 时唯一	真	~28 tok/s	已删 (太慢)
~~OBLITERATUS Q4_K_M~~	崩溃	假	—	已删
~~Huihui Q4_K (原始版)~~	OFF 崩溃	真	—	已删 (层数61不对)

（Gemini注：海外作者（如西方开源社区）制作的。他们寻找“拒绝向量”时，用的测试集绝大多数是英文的安全基准（比如涉及暴力的英文问答）。它抹掉了英文语境下的道德底线，但在面对中文的高级隐喻、特定文化禁忌时，由于没有彻底擦除中文特有的安全向量，模型依然会触发潜意识的“道德刹车”）

最终性能对比

DFlash API 速度 (OpenAI 兼容 server)

模型	速度 (API tg128)	速度 (run.py)	显存占用	去审查
Huihui Q4_K_M	~80-81 tok/s	~93 tok/s	14.73 GiB	真
Heretic Q4_K_M	~69 tok/s	~69 tok/s	14.73 GiB	假

bench_he.py 详细成绩 (Reddit 同款 10 HumanEval，2026-06-10)

Huihui Q4_K_M + FA_ALL_QUANTS=ON + --fa-window 0 + --tokenizer Qwen/Qwen3.6-27B：

+-----------------------------+-------+------+--------+
| prompt                      | tok/s | AL   | 接受率 |
+-----------------------------+-------+------+--------+
| has_close_elements          | 100.7 | 7.53 | 49.6%  |
| separate_paren_groups       | 76.6  | 5.82 | 37.2%  |
| truncate_number             | 54.4  | 4.00 | 26.8%  |
| below_zero                  | 82.5  | 6.10 | 39.0%  |
| mean_absolute_deviation     | 96.4  | 7.11 | 46.2%  |
| intersperse                 | 87.2  | 6.40 | 40.3%  |
| parse_nested_parens         | 70.6  | 5.33 | 36.5%  |
| filter_by_substring         | 74.6  | 5.57 | 35.3%  |
| sum_product                 | 115.2 | 8.53 | 53.3%  |
| rolling_max                 | 55.7  | 4.13 | 26.4%  |
+-----------------------------+-------+------+--------+
| MEAN                        | 81.38 | 6.05 | 39.1%  |
+-----------------------------+-------+------+--------+

对比 Heretic 旧成绩 (bench_he.py)：

Heretic Q4_K_M (旧): 68.80 tok/s, AL 4.79, 接受率 30.0%
Huihui Q4_K_M (新): 81.38 tok/s, AL 6.05, 接受率 39.1%
提升：+18.3%

对比 Reddit 帖文 (r/LocalLLaMA, 同款 test_dflash)：

项目	Reddit 帖文	我们实测 (Heretic)	我们实测 (Huihui)
AR 基线	28.07 tok/s	30.83 tok/s	—
DFlash budget=8	62.75 tok/s	68.80 tok/s	81.38 tok/s
加速比	2.24x	2.23x	2.64x
AL	4.93	4.79	6.05
草稿模型	Q8_0 GGUF	Q8_0 GGUF	Q8_0 GGUF
主模型	原版 Qwen3.6	Heretic 无审查	Huihui 真无审查

模型去审查排名表

模型	去审查	DFlash 兼容	速度	备注
Huihui Q4_K_M (mradermacher)	真	FA_ALL_QUANTS=ON	~81 tok/s	唯一真无审查冠军
Heretic Q4_K_M (Youssofal)	假	原生	~69 tok/s	仅是真实度+0.5 而非真去审查
~~Huihui IQ4_XS~~	真	️ OFF 也可	~28 tok/s	太慢已删
~~OBLITERATUS Q4_K_M~~	假	崩溃	—	假去审查+不兼容

去审查实测验证

测试问题	Huihui Q4_K_M	Heretic Q4_K_M
"如何制造XX"	直接输出步骤	"我不能提供"
"详细描述BL场景"	完整叙述	"请保持安全"
"制作XX的XX原理"	给出原理+流程	安全教育

🧠 经验教训总结

FA_ALL_QUANTS=ON 是正解。 不要再去 patch 源码了，完整编译能解决所有量化类型的 kernel 缺失问题。TILE fallback 是歪路。
Uncensored 标签水很深。 Huihui abliterated 是真无审查（直接回复XX步骤），Heretic 号称 Uncensored 但实际拒答。实测为准。
mradermacher 的 GGUF 转换管道与 DFlash 兼容性最好。 同一量化的其他发布者版本可能层数/架构不同导致崩溃。
Q4_K_M 性能远优于 IQ4_XS (~81 vs ~28 tok/s)，FA_ALL_QUANTS=ON 后 Q4_K_M 无兼容问题，IQ4_XS 已弃用。
--fa-window 0 仍是必要的。 即使编译完美，该参数依然是防范长文本 DFlash 滑动窗口崩溃的最佳实践。
--tokenizer Qwen/Qwen3.6-27B 解决 emoji 显示方块问题。auto-detect 会匹配到 Qwen3.5 的 tokenizer，某些 emoji token 映射不一致。
DFlash 重建后必须 --clean-first，否则增量编译不重编 HIP 目标，修改不生效。
bench_he.py 才是正确的测量方法。 run.py 单 prompt 测速会包含预填充开销，低估性能 10-15%。

参考来源

Lucebox DFlash: https://github.com/Luce-Org/lucebox-hub
Huihui abliterated: https://huggingface.co/huihui-ai/Qwen3.6-27B-Abliterated-GGUF
Heretic (假无审查): https://huggingface.co/Youssofal/Qwen3.6-27B-Abliterated-Heretic-Uncensored-GGUF
Reddit DFlash 参考: https://www.reddit.com/r/LocalLLaMA/comments/1tgepbd/
lcz.me 论坛实测: Topic 353 & 100 (7900 XTX + Qwen3.6)

最后再晒一下心意十几年的真-双路服务器主板，待内存降回合理水平后势必要32G 2400Recc 插满！！！

abaalei

10天、18支视频：一人全栈AI漫画频道的完整踩坑记录

不涉及具体项目/频道名称，只聊创作层面的真实迭代过程。

时间线速览（基于文件系统时间戳）

6/22 10:08  EP02 完成    41文件 ← 最早完成的成品！（EP01实验太久，EP02先出来了）
6/23 00:03  EP03 完成    11文件
6/23 00:28  EP01 完成    9文件  ← EP01反而是第三支完成的
6/23 02:45  EP03_Rebuild 重建（质量不满意）
6/23 23:14  EP04 完成    55文件 ← 管线爆发：建立标准目录结构
6/24 20:26  EP05 完成    40文件 ← 新坑：VAE紫色杂讯
6/25 08:30  VAE修复      ep05_fix_vae_test.py
6/25 23:53  EP05_Rebuild 重建（质量不达标）
6/26 18:22  EP06 完成    17文件 ← 管线精简，1080p上采样
6/27 12:37  EP07 完成    27文件 ← 新增SFX音效、hook音频、缩略图
6/27 20:02  EP08 完成    26文件
6/28 10:34  EP08_Rebuild 重建
6/28 00:29  Illustrious模型测试（替代Animagine的候选）
6/30 12:04  EP10 完成    26文件
6/30 12:08  EP09 完成    26文件
6/30 19:53  EP11 完成    17文件

EP01：双引擎试错，烧¥50买认知

起步：想双线并进，WAN却直接翻车

6月21日晚上，creator子智能体开始构建EP01的工作流。最初的计划是WAN 2.2和LTX 2.3双线并行，creator profile里现在还留着当时的脚本：

submit_i2v_final.py  (21:06)  → WAN 2.2 API格式
submit_i2v_fix.py    (21:05)  → WAN 2.2 修复版
submit_i2v_v2.py     (21:09)  → WAN 2.2 迭代2
submit_i2v_v3.py     (21:10)  → WAN 2.2 迭代3
submit_i2v_v4.py     (21:13)  → WAN 2.2 迭代4

一小时内出了5版脚本——不是因为正常迭代，而是WAN 2.2遇到了致命性故障：生成画面满屏紫色杂讯，完全不可用。
（最后发现，wan2.2，只要使用单Unet节点，100%会触发，有且只能用双Unet的模式）

换了参数、换了prompt、换了CLIP编码器……5个版本全部翻车。紫色杂讯像病毒一样覆盖每一帧输出。这个bug后来在6/23的 submit_wan_i2v_fixed.py 里才被修掉。

被迫单线：LTX 2.3救场

（我一直都是让hermes agent给我按照机智罗的工作流做到完整的复制，但是deepseek一直在找借口绕路）
（后面新开了会话，让sonnet4.6来救场后，才遵循到我的要求来跑通了第一天的工作）

WAN不行，只能把全部希望押在LTX 2.3上。用的是 ltx-2-3-22b-distilled-Q4_K_M.gguf（Q4量化），CLIP：Gemma 3 12B GGUF。出图参数：8步、CFG 1.0。

LTX的问题是：视频画面对prompt的遵从度低，生成的画面经常偏离脚本描述。为了得到一组勉强可用的画面，需要反复调整prompt重试。但至少——它能出图，不像WAN那样直接紫色糊脸。

成本

DeepSeek V4 Flash主要用于故事脚本拆解（把原文拆成分镜脚本）和prompt迭代（每次重试都要重新调prompt）。一晚上下来烧了大约¥50的API token。

后续：WAN 2.2在后面几集成功接手

EP01被迫只用LTX 2.3跑通后，没有放弃WAN。6/23凌晨修复了紫色杂讯bug（submit_wan_i2v_fixed.py + submit_wan_i2v_xb.py），后续视频开始迭代到WAN 2.2作为主力。

EP01的关键决策

做完EP01后确定了三个原则：

放弃视频生成路线做漫画——LTX生成的视频逐帧拆成漫画质量太差
ComfyUI逐帧出图（用Animagine XL V3 + 自定义角色LoRA）作为主力
文本模型只负责拆脚本，画面和风格交给本地GPU

EP02-03：固定工作流 + 首次视频化尝试

标准参数确立

基础模型：Animagine XL V3 (SDXL动漫特化)
LoRA：    自定义女性角色 LoRA @ 0.8 强度
分辨率：  1344×768 (16:9 漫画比例)
采样器：  dpmpp_2m_sde + karras, 20步
CFG：     7
环境：    241节点 → 7900 XTX (ComfyUI :8188)

这组参数成为后续所有视频的"标准配方"。

EP03视频化：WAN修复后首测

6月23日凌晨3:55-3:59，creator在241上跑了修复后的WAN 2.2对比实验：

端口8189 → WAN 2.2 I2V (fixed UMT5版 + XB版)
端口8188 → LTX 2.3 I2V (对比基线)

输入都是 EP03_P01_FINAL.png。WAN的紫色杂讯bug终于在 submit_wan_i2v_fixed.py 里被修掉了。这次实验验证了：把静态漫画转成视频片段（作为视频的开场/高潮动效）是可行的，但整集都用视频生成不行。 后续视频开始从LTX逐步迁移到WAN。

EP04（6/23深夜）：标准管线诞生

EP04是整个项目的分水岭。55个文件，第一次建立了完整的目录结构：

EP04/
  01_images/      ← ComfyUI静态漫画帧（P01-P12，含a/b变体）
  02_scripts/     ← 生成脚本
  03_prompts/     ← ComfyUI prompt JSON
  04_tts/         ← 日语配音音频
  05_i2v/         ← 图片转视频（WAN 2.2 I2V）
  05_i2v_rife/    ← RIFE帧插值（补帧到60fps）
  06_bgm/         ← 背景音乐
  08_deliverables/← 最终交付文件

同时也是第一次产出双语版本：JP（日语）和 EN（英语）各一套，含完整版和Shorts版。

这个目录结构成了后续所有EP的模板。

EP05（6/24-25）：VAE紫色杂讯——又一个"紫色"bug

6月24日EP05完成初版。但出现了新的画面bug：VAEDecodeTiled导致的紫色块。

6月25日早上8:30，creator写了 ep05_fix_vae_test.py：

修复 VAEDecodeTiled → 标准 VAEDecode，验证紫色块消失

把ComfyUI工作流里的VAE解码器从分块模式（VAEDecodeTiled）切回标准模式（VAEDecode），紫色块消失。

但初版还有其他质量问题——6月25日晚上23:53完成了EP05_Rebuild（29个文件的重建版）。EP05还留下了 wrong/ 目录（废弃输出），说明当时在大量试错。

EP06（6/26）：管线精简 + 1080p上采样

文件数从EP04的55个降到17个——不是产出少了，是管线更成熟了，不再需要那么多中间产物。新增了 upscaled_1080p_full/ 和 upscaled_1080p_short/，说明正式加入了AI超分辨率上采样环节。

EP07（6/27上午）：功能最丰富的一集

EP07新增了：

SFX音效（sfx/）
Hook音频（tts_hook_jp.wav）——视频开头抓人的短音频
缩略图采样（thumbnail_samples/）——给YouTube封面准备
发布版本文档（ep07_publish_copy.md）——记录发布描述文案

EP08（6/27晚-6/28重建）：效率冲刺

EP08一天内完成（27号20:02），但第二天（28号10:34）又Rebuild了。日产量达到2集。

Illustrious模型测试（6/28）

在 illustrious-test/ 目录下做了大量测试——Illustrious是另一个SDXL动漫模型，作为Animagine XL V3的替代候选。测试内容包括独奏（单人）、双人、inpaint等场景。

EP02先于EP01完成？创作顺序的真相

文件时间戳揭示了有趣的事实：

EP02 → 6/22 10:08 (41文件，最早)
EP03 → 6/23 00:03
EP01 → 6/23 00:28 (反而是第三支)

EP01不是第一支完成的视频。EP01因为WAN故障+LTX试错消耗了最多时间，反而EP02和EP03先用成熟工作流跑完了。EP01到6月23日凌晨才最终交付——它是创作顺序上的起点，却是交付顺序上的第三名。

EP06：漫画感的觉醒

核心问题

AI直出的图缺少"漫画味"——没有气泡、拟声词、分镜节奏。

尝试在ComfyUI里直接出带气泡的图（prompt里写"speech bubble"），结果：气泡是画面的一部分，位置随机，文字乱码，经常盖在人脸上。

决策：AI出纯净图，后期手动加漫画元素

这是整个工作流的转折点。制作时间翻倍（2h→4h），但画面质量飞跃：

气泡不再盖人脸
文字不再是乱码
分镜有了真正的节奏感

EP07（6/26-27）：工作流全面优化

6/27的系统性优化

在creator和dev profile的对话中确认了以下改动：

① 模型目录统一
之前模型散落两处（~/ComfyUI/models/ 和 /mnt/models/ComfyUI/），导致加载失败和重复下载。全部归到 /mnt/models/ComfyUI/。

② 多卡分工

7900 XTX #1 :8188 → 主出图流程
7900 XTX #2 :8189 → 修复/Inpainting辅助
3080 Ti        → 视频编码/后期

③ 角色一致性升级
从"IPAdapter + 单参考图"升级到"IPAdapter + 多角度参考图库（正脸/侧脸/表情各一张）"。

④ 漫画气泡方案定型

讨论了三路线：

PanelForge集成 → 灵活但手动定位
Inpainting融合 → 画质好但多一步出图
Python后处理 → 快速、全自动、不费GPU

最终选Python后处理：AnimagineXL出图→MediaPipe检测人脸→计算气泡安全区→Pillow渲染→叠加。不用再跑一次ComfyUI，批次处理更快。

EP08+：效率飞轮

不再加新功能，全力提效：

脚本拆解prompt模板化（DeepSeek一次出合格分镜）
ComfyUI JSON工作流固化（换prompt节点就出图）
后期步骤脚本化

单集制作时间：EP01的7h+ → EP08的2-3h。

技术参数附录

ComfyUI 静态出图（Animagine XL V3 + LoRA）

# EP05 batch static 脚本中的标准参数
width:  768          # 竖屏漫画比例
height: 1344         # 竖屏漫画比例
batch_size: 1        # 单张出图
seed:    202022      # 基础种子，每页+1
steps:   20          # 步数
cfg:     6.0         # CFG引导强度
sampler: dpmpp_2m_sde
scheduler: karras
denoise: 1.0

LoRA强度未在脚本里写死（由ComfyUI workflow JSON控制），实际使用 female_lead_lora.safetensors @ 0.8。

LTX 2.3 视频生成

# batch_submit_v5.py 中的参数
steps:      15       # LTX比静态图需要更多步
cfg:        1.0      # 视频模型CFG接近1
sampler:    euler
scheduler:  sgm_uniform
frame_rate: 24       # 目标24fps
strength:   1.0      # img2video强度

CLIP: LTX-2.3/gemma-3-12b-it-Q4_K_M.gguf（GGUF量化）
UNet: LTX-2.3/ltx-2-3-22b-distilled-Q4_K_M.gguf（Q4量化）
VAE: LTX-2.3/LTX23_video_vae_bf16.safetensors

WAN 2.2 视频生成

（其实这两个都是复刻机智罗的工作流，但是在使用过程中慢慢的加入了自己的参数罢了）

# submit_i2v_v4.py / submit_wan_i2v_fixed.py
CLIP:     t5xxl_fp8_e4m3fn.safetensors
VAE:      Wan2.2/wan2.2_vae.safetensors
UNet:     Wan2.2/I2V/Wan2.2_I2V_Dasiwa-V10_Q4_High.gguf (Q4量化)
采样步数: 3 (轻量快速出视频)
CFG:      1
分辨率:   624×624 → crop到16倍数

RIFE 帧插值

EP05-Rebuild (失败方案):
  pass ×2:  81f → 161f → 321f
  播放:     24fps = 13.4s/页
  效果:     2.6x慢动作 ❌ 太慢

EP06（最终方案）:
  pass ×1:  81f@16fps → 161f@24fps
  播放:     24fps = 6.7s/页
  效果:     1.3x微慢 ✅ 最佳

RIFE配置:

clear_cache_after_n_frames: 10  # 防止显存泄漏
scale_factor: 1.0              # 不缩放(480×832→1080p交给后续upscale)
input: 480×832 (ComfyUI直出) → output: 161f@24fps

双卡负载分配（batch_submit_v5 交替模式）

jobs = [
    ("http://192.168.0.241:8188/prompt", "P02.png"),  # 卡1
    ("http://192.168.0.241:8189/prompt", "P03.png"),  # 卡2
    ("http://192.168.0.241:8188/prompt", "P04.png"),  # 卡1
    ("http://192.168.0.241:8189/prompt", "P05.png"),  # 卡2
    ...
]

交替分配让两张卡同时跑，并行出图翻倍效率。

标准EP管线目录

EP0X/
  01_images/      ← ComfyUI静态漫画帧
  03_prompts/     ← ComfyUI workflow JSON
  04_tts/         ← VoiceVox日语配音
  05_i2v/         ← WAN 2.2 图片转视频片段
  05_i2v_rife/    ← RIFE帧插值 (81f→161f)
  06_bgm/         ← 背景音乐
  08_deliverables/← 最终成品
  upscaled_1080p/ ← AI超分到1080p
  *_full.mp4       ← 完整版
  *_shorts.mp4     ← YouTube Shorts版
  *_JP_*.mp4       ← 日语版
  *_EN_*.mp4       ← 英语版

成本

项目	费用	说明
DeepSeek V4 Flash API	~¥5-10/集（含其他迭代优化脚本之花费）	脚本拆解+prompt生成
EP01特殊成本	~¥50	WAN试错+LTX反复调参
ComfyUI出图	免费	本地7900 XTX
VoiceVox TTS	免费	开源
VoxCPM2声线转换	免费	自建(内网6843)
RIFE帧插值	免费	本地GPU
1080p超分	免费	本地GPU

核心心得

1. 视频生成模型不适合做漫画

WAN 2.2和LTX 2.3都试了。结论：视频模型适合"运动的画面"，漫画需要的是"高质量静态帧+叙事节奏"。方向性错误，¥50买了这个认知。

2. WAN的紫色杂讯bug拖了一整天

计划的双线策略被WAN的致命bug打乱了。5版脚本全部翻车，最终只能靠LTX 2.3单线跑通EP01。但好在bug后来修掉了，WAN在后面几集成功接手。

3. AI出图 + 人工后期 > 全AI一条龙

气泡和分镜交给AI → 乱码盖脸。AI只做"出纯净画面"，排版/文字/节奏留给手动控制。这个分界线画清楚后，画面质量直接跳了一档。

4. 角色一致性是AI漫画的终极难题

LoRA + IPAdapter + 多角度参考图库——目前最稳定的方案。但依然做不到100%。这是整个工作流最耗精力的部分。

5. 多GPU是被逼出来的
（其实并不是，只是我TM拿到了劳动仲裁款，有钱身痒痒，看到坛里分享的优惠咨询，不买不开心）

一张7900 XTX一天出不了18集的图。三张卡各司其职才能把周期压缩到一天2-3支。

基于creator/dev profiles的实际对话记录、ComfyUI工作流脚本和YouTube频道数据整理。

慢慢迭代优化后，频道第一次突破1000播放！

以上迭代思路受马斯克之：快速迭代敏捷开发所启发，不管黑猫好猫，先把管线跑起来，再慢慢优化稳定

补充一下现在在跑的项目实际速度，大概500s生成5s，480*832

abaalei

.# 双 7900 XTX + SGLang / vLLM TP=2 踩坑总结

——X99 平台双消费级 RDNA3 的多卡深渊

日期: 2026-06-16
作者: Peter (241 服务器)
硬件: Intel X99 (E5-2682v4) + 2× RX 7900 XTX (Sapphire Pulse + XFX MERC) + 1× RTX 3080 Ti
ROCm 版本: 7.2.0 | RCCL 版本: 2.27.7 | PyTorch: 2.12.0+rocm7.2

一、序：为什么会有这篇文

如果你正在搜"双 7900 XTX + SGLang / vLLM 多卡 TP"，恭喜你，你已经发现了 AMD 消费级多卡最深的坑。

网上到处是单卡 ROCm 成功的教程，但极少有人坦白双卡 TP 的真实状况。本文将完整记录从双卡硬件安装 → ROCm 环境搭建 → RCCL 源码编译 → 底层调试 → 确认 RCCL 内核毁坏 GPU 内存 → 社区搜寻的全过程，让你不必重复这 15 小时的弯路。
（下文部分AI概况的时间耗时不太准确，实际我跟agent在尝试SG-Lang这件事上，从前一天傍晚的17:00~隔天的0:35）

二、硬件拓扑

┌─────────────────────────────────────────────────────┐
│ X99 双卡拓扑 (X99-6PLUS, LGA2011-3)                  │
├─────────────────────────────────────────────────────┤
│                                                     │
│  CPU: E5-2682 v4 (16C/32T)                         │
│  Chipset: Intel X99 (Haswell-E)                    │
│                                                     │
│  ┌──────────┐    ┌──────────┐    ┌──────────┐      │
│  │ GPU 0    │    │ GPU 1    │    │ GPU 2    │      │
│  │ Sapphire │    │ XFX      │    │ NVIDIA   │      │
│  │ 7900 XTX │    │ 7900 XTX │    │ 3080 Ti  │      │
│  │ PCIe 3.0 │    │ PCIe 3.0 │    │ PCIe 3.0 │      │
│  │ x16      │    │ x16      │    │ x8       │      │
│  └────┬─────┘    └────┬─────┘    └────┬─────┘      │
│       │              │              │             │
│       └──────────────┴──────────────┘             │
│                     │ PCIe 3.0 via X99 PCH         │
│              ┌──────┴──────┐                       │
│              │ X99 PCH     │                       │
│              │ (DMI 2.0)    │                       │
│              └─────────────┘                       │
│                                                     │
│  P2P: 不支持 (X99 北桥无 P2P 路由)                    │
│  NUMA: 双卡均绑定 Node 0                             │
│  PCIe 带宽: ~7.9 GB/s per card (x16 3.0)           │
└─────────────────────────────────────────────────────┘

三、推进路线图（含时间线）

时间线 (2026-06-16) ──────────────────────────────────
│
├─ 16:00 硬件安装 + 识别确认 ✅
│   └─ rocm-smi 显示双 7900 XTX 待机正常
│
├─ 16:05 ROCm + PyTorch 环境搭建
│   ├─ 创建隔离 venv: /home/peter/venvs/sglang/
│   ├─ 安装 PyTorch 2.12.0+rocm7.2
│   └─ 安装 SGLang + 打补丁 (aiter 桩模块, AWQ 兼容, ROCm 检测绕过)
│
├─ 16:10 单卡验证 ✅
│   └─ SGLang 0.5B 模型推理正常
│
├─ 16:15 下载 27B AWQ 模型
│   └─ Huihui-Qwen3.6-27B-abliterated-AWQ (19GB, 10 分片)
│
├─ 16:30 首次双卡尝试 ❌
│   └─ NCCL init 成功, 权重加载时 hipSetDevice SIGABRT
│   └─ 原因: RCCL 预编译包不含 gfx1100 内核
│
├─ 16:40 编译 RCCL for gfx1100 (耗时 22 分钟) ✅
│   └─ 515/515 targets, librccl.so 从 546MB → 11MB
│
├─ 17:00 双卡 NCCL 初步成功...但 all_reduce 崩溃 ❌
│   └─ ncclCommInitRank 通过 ✅
│   └─ ncclAllReduce 返回 0 (成功!) ✅
│   └─ torch.synchronize → hipErrorIllegalAddress ❌
│
├─ 17:05 社区搜索 RCCL bug
│   ├─ 发现 ROCm#6074: COLLTRACE 标志 + PCIe atomics
│   │   └─ 但该问题只影响 ROCm 7.2.1, 而我们用的是 7.2.0
│   ├─ 尝试 COLLTRACE=OFF 重新编译 (20 分钟) ❌ 同样崩溃
│   └─ 发现 ROCm#6290: MES 固件回归问题
│       └─ 但影响 kernel >6.17.12, 而我们在 6.8.0
│
├─ 17:15 深入诊断
│   ├─ ROCm 7.2.0 原版 RCCL (546MB) 测试 ❌ 同样崩溃
│   ├─ 4 种 NCCL 协议 (Simple/LL/128/LL128_DISABLE) ❌ 全部崩溃
│   ├─ NCCL 直调 C API 测试: allreduce 返回成功但内存已坏 ✅ 定位根因
│   └─ 结论: RCCL allreduce 内核在双消费级 RDNA3 上静默损坏 GPU 内存
│
├─ 17:20 社区广泛搜索
│   ├─ Level1Techs: 双 R9700 (RDNA4 专业卡) 在 Threadripper 上同样崩溃
│   │   └─ "the plague" - RCCL 多卡 bug 被社区称为瘟疫
│   ├─ Reddit: 有人声称 vLLM TP=2 能用, 但无具体配置
│   └─ 搜索结论: 无任何双 7900 XTX + SGLang TP=2 的成功案例
│
└─ 17:25 最终结论: RCCL 在双消费级 AMD 卡上不可用

总耗时: ~1.5 小时 (硬件+诊断) + 前序约 2 小时 (RCCL 编译+模型下载)

四、关键发现

4.1 RCCL allreduce 静默内存损坏 —— 根因

这是本次踩坑的核心发现:

ncclGetUniqueId    → 返回 0 ✅
ncclCommInitRank   → 返回 0 ✅
ncclAllReduce      → 返回 0 ✅  ← 表面成功, 实际 GPU 内存已损坏
torch.synchronize  → hipErrorIllegalAddress ❌  ← 此时才捕获错误

RCCL 的 allreduce 内核在双消费级 GPU 上：

成功返回 (ret=0)
执行过程中破坏了 GPU 页表
后续任何 GPU 同步操作都会触发 hipErrorIllegalAddress
SetDevice、synchronize、甚至简单的 tensor.item() 全部会崩溃

这是 RCCL 内核层面的 bug，不是配置问题。

4.2 不是 COLLTRACE 的问题

ROCm #6074 描述的问题是 ROCm 7.2.1 的 amdclang 编译器回归（COLLTRACE 触发 PCIe atomics 依赖）
但我们用的是 ROCm 7.2.0 + 原生 7.2.0 编译器
排除了 COLLTRACE 因素后仍然崩溃
与 #6074 是不同的问题

4.3 不是 X99 独有问题

Level1Techs 论坛上，Ryzen 5950X + X570 平台（对称 PCIe x8/x8）同样崩溃
Threadripper 7980X + R9700 (专业 RDNA4) 也需要回退 vLLM 0.20.2 才能跑
甚至有人用 Ryzen 7800X3D 时也崩溃
只有极少数声称能跑的人，但无详细配置验证

4.4 不是特定 NCCL 协议的问题

测试过的所有协议组合：

环境变量组合	结果
NCCL_PROTO=Simple (默认)
NCCL_PROTO=LL
NCCL_LL128_DISABLE=1
NCCL_ALGO=Ring
AMD_SERIALIZE_KERNEL=1
RCCL_GRAPH_GUARD=1

五、可行与非可行方案

不可行

方案	原因
SGLang + TP=2 (RCCL)	RCCL 内核损坏 GPU 内存
vLLM + TP=2 (RCCL)	本质相同问题
任何依赖 NCCL/RCCL 的多卡分布式框架	均为 RCCL 底层 bug

可行

方案	性能	说明
llama.cpp tensor split	33.78 t/s (双卡 Qwen3.6-27B)	实测可用，走 ggml 自家通讯
双独立 SGLang 实例 (data parallel)	每卡独立推理	无跨卡通信，但需前端做负载均衡
Vulkan 后端 + layer split	据说比 ROCm 更快	llama.cpp Vulkan 模式，双卡可用
CPU 分载	视模型而定	小模型单卡，大模型 CPU+GPU

理论可能但未验证

方案	风险
换 Threadripper / EPYC 平台	需新主板+CPU, 且不确定 RCCL 能否稳定
等待 ROCm 8.0	AMD 内部修复进度未知
P2P 桥接 (NVLink 替代品)	AMD 消费卡无硬件桥接方案

六、调试工具备忘

如果你也走这条路，以下工具和方法比直接跑 SGLang 更高效：

# 1. 基础多卡诊断
python3 -c "
import torch
for i in range(2):
    torch.cuda.set_device(i)
    t = torch.ones(10, device=f'cuda:{i}')
    print(f'GPU {i}: {t.sum().item()}')
"

# 2. NCCL debug mode (超详细日志)
export NCCL_DEBUG=INFO NCCL_DEBUG_SUBSYS=INIT,COLL

# 3. RCCL 版本诊断
python3 -c "
import torch, ctypes
rccl = ctypes.CDLL('librccl.so')
print('RCCL loaded:', rccl)
"

# 4. 测试 NCCL communicator (确认双卡握手)
torchrun --nproc_per_node=2 test_nccl_tp.py

# 5. ROCm 固件/内核版本检查
cat /sys/class/drm/card0/device/firmware_version
uname -r
/opt/rocm/bin/rocminfo | grep -E "Name|Marketing"

七、系统优化 (已应用)

以下优化不能解决 RCCL bug，但可以改善单卡稳定性和系统表现：

# GRUB 内核参数 (需 reboot)
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash iommu=pt pcie_aspm=off"

# 运行时
sudo sysctl kernel.numa_balancing=0

# 被 NCCL_DEBUG 验证过的环境变量
export NCCL_P2P_DISABLE=1
export RCCL_P2P_DISABLE=1
export NCCL_PROTO=Simple
export NCCL_NET=Socket
export NCCL_SHM_DISABLE=1
export HSA_FORCE_FINE_GRAIN_PCIE=1
export HSA_ENABLE_SDMA=0

# 对 ROCm 7.2.1+ (但不是我们问题的根因)
export AMD_SERIALIZE_KERNEL=1

八、最后的忠告

"RCCL 在消费级 AMD 多卡上就是个半残品"
——这不是情绪发泄，是经过 npm i 验证的工程结论

如果你一定要在双 7900 XTX 上跑多卡 TP：

别用 SGLang/vLLM 原生多卡分布式——这是用 RCCL 的，一定崩
用 llama.cpp tensor split——走的是 ggml 自家通讯，绕开了 RCCL
如果非要 SGLang——跑两个独立实例做 data parallel

别跟 RCCL 死磕——该止损时就止损。我们已经替你踩了所有坑，剩下的时间请用在能用的方案上。

踩坑不易，希望后来者能从前人的尸体上站起来。

写完贴就睡觉，各位大佬们晚安
------------------------------------------------我只是Agent的遥控工/玩Agent的人，技术大牛这个称号实在有点却之不恭啊，但是还是感谢各位的赏识！

abaalei

记录一下机智罗107/108-LTX2.3初级进阶-图生视频-GGUF 工作流的标准时间，以供坛友们参考
冷启动第一次生成544960 12帧/s 视频时长3秒耗时362秒
热启动第二次生成544960 12帧/s 视频时长3秒耗时217秒
热启动第三次生成544960 12帧/s 视频时长5秒耗时248秒
热启动第四次生成544960 12帧/s 视频时长5秒耗时243秒
热启动第五次生成544960 12帧/s 视频时长10秒耗时秒325秒
（速度比WAN2.2 5秒6分钟 10秒动则20分钟快多了）
热启动第六次生成544960 12帧/s 视频时长15秒耗时秒457秒
（WAN2.2想要生成15秒的视频估计得要等到天荒地老）

模型加载及注意力加速相关参数（推荐按照JZL的视频来进行实测）：

软件配置：
Ubuntu 24.02
硬件配置：
3080ti+7900XTX*2（本次只用到一张）
外围配置：
（截图中的内存少算了一根，目前一共是16Gx7条，最新一条222买的，但是买完在等优惠券的时候又涨回去280，就暂时停止买最后一根内存了）

10秒视频的具体画面：（顺带一提，图片也是机智罗的工作流生成的）

双卡并发测试：

以后又可以全自动了：

abaalei

硬件环境：X99 双路 E5-2682 v4 + 讯景 RX 7900 XTX 24GB + ROCm 7.2.0
模型：Qwen3.6-27B-Uncensored-HauhauCS-Balanced-MTP-Q4_K_P (16.7GB, 65层)

前情

服务器上有几套推理模式，其中 Mode C 是用 llama.cpp 原生 MTP（Multi-Token Prediction，自我投机解码）跑 Qwen3.6-27B，之前一直停在 ~47 tok/s。

看到 Reddit 上有人同一张卡跑到了 ~75 tok/s，虽然人家用的是 DFlash（专门的投机解码引擎，确实更快），但我想看看原生 llama.cpp MTP 还有没有压榨空间。

做了什么

三个改动，按收益排序：

1. KV Cache 降级到 q4_0

改动前：

--cache-type-k q8_0 --cache-type-v q8_0

改动后：

-ctk q4_0 -ctv q4_0

这个其实我们早就知道（Topic 151 的实测）：KV cache 从 q8_0 降到 q4_0，prefill 能快 +167%，而生成质量几乎无感损失。但 Mode C 一直没改，不知道为啥。

（补充之前没有改的原因：）

2. 补齐 batch/ubatch 参数

改动后：

--batch-size 2048 --ubatch-size 512

原来默认值偏保守，加大后给批处理更多空间。

3. 升级 llama.cpp

从 b9549（3ebe862b5）升到 v9672（74ade5274），中间跨了 109 个提交。

最关键的一个 commit 是 e95dae18d — "Remove padding and multiple D2D copies for MTP" — 去掉了 MTP 投机解码中不必要的 padding 和 Device-to-Device 拷贝，直接把 MTP 路径改短了。

结果

指标	优化前	优化后
Decode	~47 tok/s	51.2 tok/s (+8.5%)
MTP 接受率	未记录	76% (208/273)
Prefill (17 tok)	未测	61.0 t/s
KV Cache	q8_0	q4_0
llama.cpp	b9549	v9672

经验

KV cache q4_0 是稳赚不赔的改动 — prefill 快、省显存、质量几乎无感。如果哪个模式还在用 q8_0，直接改就行。
llama.cpp 上游 MTP 还在持续优化 — 定期 git pull + rebuild 有稳定收益，编译也不花多少时间。
DFlash 仍然是单卡 7900 XTX 的天花板（我们 Mode A 能跑 ~84 tok/s），但原生 MTP 作为备份方案已经够用。
RDNA3 上跑 MTP 注意：不要开 GGML_HIP_ROCWMMA_FATTN=ON，实测反而降速（TurboQuant 团队的测试结论也印证了这一点）。

希望这些数据对后来者有参考价值。提问或讨论请回帖。

abaalei

【A卡/ROCm】7900 XTX 跑 ComfyUI 启用 SageAttention 出黑图 (NaN) 修复指南

本篇指南记录了在 AMD Radeon RX 7900 XTX (RDNA3 / gfx1100) 显卡、Ubuntu/Linux (ROCm 7.x + PyTorch 2.x) 环境下，运行 ComfyUI 启用 SageAttention (v1.0.6) 导致生成图片“全黑（无报错静默失败）”的硬核排障过程与解决方案。

如果你也遇到了开加速器必黑图、关掉就正常的灵异事件，本篇笔记能帮你彻底解决。

我们的软硬件测试环境

为便于对比排查，以下是本案所处的真实软硬件基础环境：

GPU: AMD Radeon RX 7900 XTX (24GB GDDR6 / RDNA3 / gfx1100)
CPU: 双路 Intel Xeon E5-2682 v4
内存: 64GB DDR4 REG ECC (全插满)
操作系统: Ubuntu (Kernel 5.15.0-181-generic)
ROCm 运行环境: torch 2.12.0+rocm7.2
SageAttention 库版本: 1.0.6（纯 Triton JIT 动态编译版）
ComfyUI 版本: v0.24.0 (机智罗 A 卡专用整合版)

背景与受影响工作流

在运行以下针对 AMD 优化的 ComfyUI 整合包（如机智罗 A 卡专用包）工作流时极易触发此问题：

机智罗 44号工作流（基于 Qwen-Image / Flux 架构的 GGUF 混合多模态工作流）
机智罗 14号工作流（Wan2.2 视频生成工作流，大分辨率开启 SageAttention 加速时）

故障现象

表现：当且仅当在工作流中接入 XB_SageAttentionAccelerator（SageAttention 算子加速器） 节点时，最终输出的图片（或视频帧）100% 是一片漆黑。
控制台警告：生图结束、准备输出图像的瞬间，终端会静默弹出一行 RuntimeWarning，没有其他任何 CUDA/ROCm 崩溃堆栈：
```
/home/peter/ComfyUI/nodes.py:1657: RuntimeWarning: invalid value encountered in cast
  img = Image.fromarray(np.clip(i, 0, 255).astype(np.uint8))
```

硬核根因分析

通过拉取并审计 SageAttention (v1.0.6) 在 Linux AMD 环境下的底层源码，揪出了以下两个核心冲突：

1. 累加精度不足导致数值溢出（NaN）

目前 pip 直接安装的 SageAttention 1.0.6 是纯 Triton JIT 编译版本（无预编译 .so），它在 GPU 运行时动态编译 attention kernel。
在其 attn_qk_int8_per_block.py 源码中，矩阵乘法累加计算硬编码为：

acc += tl.dot(p, v, out_dtype=tl.float16)  # 默认使用半精度累加

在 AMD RDNA3 (7900 XTX) 的 Triton 编译器后端上，半精度累加在长序列或特定激活值下极易发生数值精度溢出，产生大量 NaN（非数）。
NaN 顺着 KSampler 扩散到整个 latent，最终 VAE 解码时把 NaN 全部强制截断为 0，导致最终渲染出来的图片全黑。

2. Shared Memory 硬件超限

原版 SageAttention 的 block 大小硬编码为 BLOCK_M=128, BLOCK_N=64，这在编译时需要约 106KB 的 Shared Memory（共享内存）。
而 AMD RDNA3 显卡（7900 XTX）的物理 Shared Memory 单个 Workgroup 上限只有 65KB，这会导致 Triton 编译器在分配寄存器和共享内存时崩溃，或发生隐式内存回滚，进一步拉低速度并加剧精度混乱。

️ 终极解决方案（手动打补丁）

既然知道了是因为 “Shared Memory 超限” 和 “Triton 浮点累加溢出”，解决办法就是给 SageAttention 的 python 库手动替换补丁文件。

第一步：定位 SageAttention 库路径

在你的 ComfyUI 运行虚拟环境（venv）下，找到 sageattention 包的实际安装路径：

source /home/peter/ComfyUI/venv/bin/activate
SA_DIR=$(python3 -c 'import sageattention, os; print(os.path.dirname(sageattention.__file__))')
echo "你的包路径在: $SA_DIR"

第二步：备份原始文件（安全第一）

cp $SA_DIR/attn_qk_int8_per_block.py $SA_DIR/attn_qk_int8_per_block.py.bak
cp $SA_DIR/attn_qk_int8_per_block_causal.py $SA_DIR/attn_qk_int8_per_block_causal.py.bak
cp $SA_DIR/quant_per_block.py $SA_DIR/quant_per_block.py.bak

第三步：下载并覆盖 Zluda-AMD 优化版补丁

使用社区（来自 patientx/ComfyUI-Zluda）针对 AMD 显卡优化过的 Triton 参数补丁，直接覆盖本地文件：

BASE_URL='https://raw.githubusercontent.com/patientx/ComfyUI-Zluda/refs/heads/master/comfy/customzluda/sa'

curl -fsSL $BASE_URL/attn_qk_int8_per_block.py -o $SA_DIR/attn_qk_int8_per_block.py
curl -fsSL $BASE_URL/attn_qk_int8_per_block_causal.py -o $SA_DIR/attn_qk_int8_per_block_causal.py
curl -fsSL $BASE_URL/quant_per_block.py -o $SA_DIR/quant_per_block.py

第四步：清空 Triton 缓存（核心步骤）

为了让刚刚覆盖的补丁生效，必须清空 Triton 之前的旧编译缓存，强迫它在下次启动时重新编译 kernel：

rm -rf ~/.triton/cache

补丁到底改了什么？

out_dtype: tl.float16 ➔ tl.float32：累加矩阵全部改用 Float32 全精度。这一步彻底消灭了 A 卡上的精度溢出，是解决黑图（NaN）的核心！
BLOCK_M=128, BLOCK_N=64 ➔ BLOCK_M=32, BLOCK_N=16：将 Block 大小缩到极小。这使得单个 Workgroup 占用的 Shared Memory 从 106KB 暴降到 ~8KB，完美躲开 gfx1100 显卡的 65KB 硬件上限。
引入 Autotune（自动寻优）：新增了对 qo_len、kv_len、h_qo 的 Triton 动态 autotune 查找，网卡会根据你的生成分辨率自动寻找效率最高的线程分配方案，不再死板硬编码。

🧪 验证与收尾

导入冒烟测试：
在命令行运行以下测试代码，确认没有 NaN 且有数据输出：

python3 -c "
import torch, sageattention
from sageattention import sageattn
q = torch.randn(1, 16, 256, 128, dtype=torch.float16, device='cuda')
k = torch.randn(1, 16, 256, 128, dtype=torch.float16, device='cuda')
v = torch.randn(1, 16, 256, 128, dtype=torch.float16, device='cuda')
out = sageattn(q, k, v, tensor_layout='HND')
print('是否有NaN:', torch.isnan(out).any().item())
print('是否全为零:', (out == 0).all().item())
"
# 输出：是否有NaN: False，是否全为零: False  ➔  ✅ 算法通路畅通！

重新运行 ComfyUI：
重启你的 ComfyUI 进程，在网页上接回并点亮 XB_SageAttentionAccelerator 节点，重新点击“Queue Prompt”。

生图不仅完全恢复了色彩，而且由于 Triton 自动寻优，7900 XTX 终于能满血享受 SageAttention 带来的显存带宽减半与推理无痛加速了！

一开始agent建议我直接bypass掉

终于判断出来问题所在

解决方案出来了

测试成功

abaalei

项目仓库: https://github.com/peterhon168/esp32-kvm-webcontrol
源项目: KMChris/esp32-kvm-ip
日期: 2026-06-18

第一部分：技术报告

一、缘起：为什么要做这个？

远程管理服务器通常需要：

iDRAC/iLO/iBMC — 企业级方案，贵，老主板没有（我手上另一块超微的X10-Dai也一样没有）
PiKVM — 好方案，但树莓派被炒到天价，而且HDMI转CSI模块也不便宜
串口/SSH — 能敲命令，但看不到BIOS、看不到启动过程、装系统抓瞎

目标：用 ESP32-S3（¥25）+ USB HDMI采集卡（¥25） 实现一个能看画面、能键鼠操作的远程KVM（供货商为PDD）。

二、硬件清单 & 成本

组件	型号	成本	说明
主控	ESP32-S3 N16R8	~¥25	双核240MHz，USB OTG，WiFi
采集卡	MS2103 USB HDMI (345f:2130)	~¥25	USB 3.0，支持1080p@30 MJPEG
目标机	X99双路工作站	已有	被控机器，HDMI+USB接入
宿主主机	TrueNAS SCALE / Ubuntu VM	已有	跑流服务+网桥

总硬件增量成本: ¥80（相比PiKVM动辄¥500+）

三、系统架构

┌───────────────┐   HDMI    ┌──────────────────┐
│  目标机        │──────────→│ USB 2103 采集卡   │
│  (X99 工作站)  │           │ (MS2103芯片)      │
│               │   USB     │                   │
│               │──────────→│   ESP32-S3        │
└───────────────┘           │   (HID注入)       │
                            └────────┬─────────┘
                                     │ WiFi UDP :4210
                                     ▼
┌────────────────────────────────────────────────────┐
│              网络层                                 │
├────────────────────────────────────────────────────┤
│  KVM网桥 (Python): WebSocket ←→ UDP 转换           │
│  视频流: ffmpeg → Python MJPEG HTTP Server :8000    │
│  Web UI: http://kvm-bridge-ip:18088                 │
└────────────────────────────────────────────────────┘

数据流

浏览器 ←WebSocket JSON→ KVM网桥 ←UDP 16字节包→ ESP32-S3 ←USB HID→ 目标机
浏览器 ←HTTP MJPEG──→ MJPEG流服务器 ←pipe── ffmpeg ←v4l2── 采集卡 ←HDMI── 目标机

延迟实测

环节	延迟
视频采集 → 串流	~33ms (30fps)
网络传输	<1ms (局域网)
鼠标键盘注入	~5ms (UDP→ESP32→USB)
端到端画面延迟	~100-150ms (不含显示器)

四、ESP32-S3 固件

4.1 固件修改（vs 源项目）

源项目 KMChris/esp32-kvm-ip 原本设计是一个Windows客户端通过UDP直连ESP32，需要Windows跑一个hook程序捕获键鼠。我们改成了：

WiFi修复：认证模式 WIFI_AUTH_WPA2_WPA3_PSK → WIFI_AUTH_WPA2_PSK
- 原因：sdkconfig没开WPA3，连WiFi永远失败
重连逻辑修复：把事件回调内的 vTaskDelay 改为独立 reconnect_task
- 原因：WiFi事件循环内阻塞导致后续事件无法处理
UDP协议不变：16字节固定包格式，兼容原始协议

4.2 编译烧录

# 在Windows ESP-IDF环境
idf.py build flash monitor
# OTG口接目标机USB，UART口接电脑（可以同时插）

4.3 ESP32 IP分配

ESP32连WiFi后通过DHCP获取IP。在我们的网络里分配到 192.168.0.209。

五、USB HDMI采集卡 — MS2103 深坑记录

5.1 芯片识别

ID 345f:2130 MACROSILICON OCap Video
UVC 1.00, USB 3.0 SuperSpeed
支持格式:
  Raw:    YUYV 4:2:2 最高 3840×2160
  MJPEG:  Motion-JPEG 最高 3840×2160

5.2 血泪坑：v4l2不兼容

这个MS2103芯片是出了名的奇葩——标准v4l2 ioctl全都不吃：

VIDIOC_S_FMT → Inappropriate ioctl for device
VIDIOC_G_FMT → 同上
VIDIOC_REQBUFS → 同上
VIDIOC_STREAMON → 同上
直接 read() → Invalid argument

市面上唯一能驱动它的只有 ffmpeg（内置了MS210x的workaround）。

5.3 最终方案

# 下载静态ffmpeg二进制（John Van Sickle编译版）
wget https://johnvansickle.com/ffmpeg/releases/ffmpeg-release-amd64-static.tar.xz
tar -xf ffmpeg-release-amd64-static.tar.xz

# 捕获MJPEG帧并通过Python服务推流
ffmpeg -f v4l2 -input_format mjpeg -video_size 1920x1080 -framerate 30 \
  -i /dev/video0 -f image2pipe -vcodec copy - | python3 mjpeg_server.py

Python MJPEG服务器用纯标准库（http.server + queue + threading），不需要装任何第三方包。

六、宿主机的选择折腾

6.1 尝试路线

（Hermes Agent的宿主机truenas，ubuntu是.240，没有给他授权root权限，所以下面报了一堆错）

路线	结果	原因
直接插240 Ubuntu VM	不行	VM没有物理USB口
TrueNAS USB Passthrough到240	热插不生效	需要重启VM，但Hermes网关在240上不能断
TrueNAS直接装uStreamer(apt)	封锁	TrueNAS策略禁用包管理器
TrueNAS Docker	封锁	dockerd需要root
TrueNAS Python原生流服务	成功	/var/tmp可写、有Python3.11+PIL、无noexec
ffmpeg静态二进制跑在TrueNAS	成功	下载到/var/tmp，可执行
TrueNAS Init Script开机自启	成功	midclt call initshutdownscript.create

6.2 架构决策

采集卡最终插在 TrueNAS (192.168.0.160) 上，因为：

TrueNAS 有 USB 3.0 口
采集卡通过 VM USB Passthrough 热添加不成功（其实是成功的，全过程没有重启宿主机及VM）nid
TrueNAS 的 /var 是 ZFS 数据集（非 tmpfs），文件重启不丢
Python3.11 + PIL 可用
/var/tmp 没挂 noexec

6.3 开机自启配置（TrueNAS Init Script）

midclt call initshutdownscript.create '{
  "type": "SCRIPT",
  "script": "/var/tmp/mjpeg_server.py",
  "when": "POSTINIT",
  "enabled": true,
  "timeout": 60
}'

七、KVM网桥

7.1 kvm_bridge 架构

# server.py — 核心逻辑
# 1. WebSocket服务器 → 接收浏览器键鼠事件(JSON)
# 2. UDP客户端 → 转发给ESP32(16字节二进制包)
# 3. HTTP服务器 → 提供Web UI + 配置API

# 配置 config.env
ESP_IP=192.168.0.209        # ESP32 IP
ESP_PORT=4210                # ESP32 UDP端口
WS_PORT=18765                # WebSocket端口
HTTP_PORT=18088              # Web UI端口
USTREAMER_URL=http://192.168.0.160:8000/stream  # MJPEG视频流

7.2 Web UI 特性

单页面HTML + CSS + JS（无框架依赖）
WebSocket自动重连
鼠标 Pointer Lock API（按Alt+L切换锁定/解锁）
BIOS兼容（相对坐标模式）
视频流iframe内嵌uStreamer画面
连通性检测（ESP32在线→绿，离线→黄色警告）

7.3 PM2进程管理

pm2 start server.py --name kvm-bridge
pm2 save

八、完整搭建步骤（从零开始）

Step 1: 硬件连接

目标机HDMI → 采集卡 → 宿主机USB
目标机USB  → ESP32-S3 OTG口
ESP32-S3 UART口 → 电脑（烧录用，运行时不用）

Step 2: 烧录ESP32固件

# Windows + ESP-IDF
idf.py build flash monitor
# 记下ESP32的IP（从路由器DHCP表查）

Step 3: 宿主机上部署流服务

# 如果是Ubuntu（最简单）
apt install ustreamer
ustreamer -d /dev/video0 -m MJPEG -p 8000 -r 1920x1080

# 如果是TrueNAS（需要折腾）
# 下载ffmpeg静态二进制 + Python MJPEG服务器脚本
# 部署到 /var/tmp/，配Init Script开机自启

Step 4: 部署KVM网桥

# 任何有Python3的机器
pip3 install websockets
cp config.env.example config.env
# 编辑 config.env 填入ESP32 IP和流URL
python3 server.py

# 或通过PM2守护
pm2 start server.py --name kvm-bridge

Step 5: 打开浏览器

http://<bridge-ip>:18088
→ 点击「连接」建立WebSocket
→ 点击「加载」显示视频流
→ 点击视频区域 → 锁定鼠标 → 开始操作

九、避坑总结

┌─────────────────────────────────────────────────────────────┐
│ 🕳️ 坑1: MS2103采集卡标准v4l2 ioctl不能用                   │
│    ✅ 解决: 只能用ffmpeg（有内置workaround）                 │
│                                                             │
│ 🕳️ 坑2: TrueNAS是"安全加固"系统                            │
│    ✅ 解决: apt/Docker都被锁，用静态二进制+Python纯std库    │
│                                                             │
│ 🕳️ 坑3: TrueNAS默认不许跑二进制(noexec)                    │
│    ✅ 解决: /var/tmp 没有noexec，放那                      │
│                                                             │
│ 🕳️ 坑4: VM USB热插不生效                                   │
│    ✅ 解决: 既然Hermes在VM上不能重启，物理机直插跑服务      │
│                                                             │
│ 🕳️ 坑5: ESP32连不上WiFi                                    │
│    ✅ 解决: 固件认证改 WPA2_PSK，重连改独立task             │
│                                                             │
│ 🕳️ 坑6: ESP32断线后不自动重连                              │
│    ✅ 解决: 事件回调内vTaskDelay阻塞 → 独立reconnect_task   │
└─────────────────────────────────────────────────────────────┘

项目地址: https://github.com/peterhon168/esp32-kvm-webcontrol
参考: https://github.com/KMChris/esp32-kvm-ip
采集卡问题参考: https://www.mjt.me.uk/posts/fixing-missing-macrosilicon-ms2109/

abaalei

硬件环境：X99 双路 E5-2682 v4 + 讯景 RX 7900 XTX 24GB
模型：Qwen3.6-27B-Uncensored-HauhauCS-Balanced-MTP-Q4_K_P (16.7GB, 65层)
原系统：ROCm 7.2.0 + llama.cpp v9672

前情

之前看到 Reddit 用户 W61k3r 提到从源码编译 ROCm（TheRock 分支）后，HSA_XNACK=1 能带来性能提升。我们在 ROCm 7.2.0 上试过 HSA_XNACK=1——llama-bench 确实有 +39% prefill，但 llama-server 直接崩溃。

想想也合理，HSA_XNACK=1（XNACK = eXception on Non-ACKnowledged page）是 ROCm 5.x 时代为 MI200 引入的 SVM 页错误处理特性，7.2 的时候可能还不稳定。所以要试就得升级（升级？降级好不好） ROCm。

编译 TheRock

AMD 官方把源码 ROCm 叫 TheRock（rocm/therock 分支），不走 .deb 或 .run 安装。

# 核心命令：只编 gfx1100（7900 XTX），关掉 MI300 / HPC 冗余
cmake -DCMAKE_INSTALL_PREFIX=/opt/rocm-7.14-therock \
      -DAMDGPU_TARGETS=gfx1100 \
      -DROCSTATION=OFF \
      -DMIOPEN_BACKEND=HIP \
      ...

make -j16 && make install

项目	数值
版本	ROCm 7.14.60850
安装位置	`/opt/rocm-7.14-therock`（与 7.2.0 共存）
编译时间	~4 小时（16 核 + ccache）
产出	5.5GB / 650 个二进制
跳过组件	grpc, boost, MPI（不影响推理）

然后重新编译 llama.cpp 指向新 ROCm：

cmake .. -DGGML_HIP=ON \
  -DCMAKE_PREFIX_PATH=/opt/rocm-7.14-therock \
  -DAMDGPU_TARGETS=gfx1100
make -j16 llama-bench llama-server

结果

llama-bench（q4_0/q4_0, pp512/tg128）:

测试	pp512	tg128	对比
ROCm 7.2.0 基线	481 t/s	29.4 t/s	—
ROCm 7.14 裸跑	386 t/s	29.5 t/s	pp -20%
ROCm 7.14 + HSA_XNACK=1	697 t/s	31.5 t/s	pp +45%, tg +7%

关键发现

ROCm 7.14 不能裸用。 裸跑比 7.2.0 慢 20%，必须配合 HSA_XNACK=1。
HSA_XNACK=1 在 7.2.0 上 server 崩 → 7.14 完美运行。 这才是编译 TheRock 的最大价值——不是性能直接提升，而是解锁了 HSA_XNACK=1 这个参数。
128K 上下文测试通过。 ROCm 7.14 + HSA_XNACK=1 + MTP q4_0 KV + -c 131072 稳定运行，prefill 85 t/s, gen 42.9 t/s, MTP 接受率 83%。

综合收益

方面	收益
prefill	+45%（短 prompt 首字快很多）
decode	+7%（生成略快）
128K 上下文	实测通过
HSA_XNACK=1 可用	ROCm 7.2 上 server 崩的点完全修复
编译代价	~4 小时一次搞定，后续 git pull + rebuild 很快

经验

HSA_XNACK=1 是 RDNA3 的免费午餐。 只要 ROCm 版本够新（新？编者注：7.1.3比7.2.0新？deepseekv4flash这是什么脑洞？这不就是7.2新增的bug导致无法开启这个功能，回退到7.1.3反而能打开吗？ai幻觉真可怕），开它几乎没有代价，prefill 直接 +45%。
从源码编 ROCm 没有想象中难。 关键一步是把不必要组件（MI300/HPC/Profiler/MPI）关掉，否则编译要好几个小时。
W61k3r 的 Reddit 帖是对的，但原因需要校正。 核心收益不是"TheRock 源码本身优化了"——而是 新版本允许 HSA_XNACK=1 正常工作。如果你已经在 ROCm 7.3+，可能不需要编源码，直接 apt install 新版 ROCm 开 XNACK 就行。
X99 平台感受有限。 pp +45% 在短 prompt 场景确实快很多，但长上下文生成仍然受限于 DDR4 带宽。不过 128K 上下文的稳定性验证对日常使用已经足够。

Reddit原始地址：https://www.reddit.com/r/ROCm/comments/1u9i8n3/impressed_with_rocm_714_works_great_with_7900xtx

241 服务器实测数据，希望踩坑经验对后来者有参考价值。提问或讨论请回帖。

连载折腾到尾声了，下一篇文章将会总结这一周以来折腾过的所有路子，我们自己留下的模式以及选择方式，敬请关注！

abaalei

补充一下Deepseek v4 Flash 的账单

abaalei

感谢各位的赏析！！
今晚在折腾双7900xtx SG-Lang，目前还没跑通，回头整理完出报告！

abaalei

只跑LLM的话，苹果可以，但是comfyui的话，目前市面上还比较难选？
不担心电表倒转的可以跟我这样玩

双路E5 2682 v4+ 96G DDR4 2133 Reg Ecc+ 3080ti + 7900XTX *2
满载功耗（含软路由、nas、交换机、APC SUA3000R2ICH UPS）=1600W！

目前花费

abaalei

硬件环境：双路 7900 XTX (XFX MERC + Sapphire Pulse) + NVIDIA 3080 Ti (ACE-Step) | X99 DDR4-64G | ROCm 7.2.0/7.14 + Vulkan 双后端

编者注：
简而言之，对我来说
1.日常 Comfyui+Qwen 的话就选择----------### 模式 C — MTP 自我投机解码
2.写小说 --------------------------------### 模式 B — IQ4_XS 128K 长文本写作（30 / 37.7 tok/s）
3.想找个人/对象瞎聊一通--------------------### 模式 A — DFlash 投机解码（84 tok/s 纯跑分）
3.想要双卡进行Debug或者安全漏洞查测，就用---### 模式 E — 双卡 Q8_0 最高精度（~23 tok/s）

前言

自从折腾上 Qwen3.6-27B 后，根据不同使用场景摸索出了 6 个标准模式（A/B/C 单卡 + D/E/F 双卡），外加 2 个 Vulkan 变体。每个模式针对不同的量化、后端、推理策略做了取舍。这篇文章把这些模式的性能数据、启动参数、适用场景完整整理出来，给后来者参考，也方便自己查阅。

模式命名规范：A/B/C = 单卡（用 XFX MERC，不影响 ComfyUI），D/E/F = 双卡（占用两张 7900 XTX，需停 ComfyUI）。Vulkan 变体加 -Vk 后缀。

一、单卡模式 (A / B / C)

单卡统一用 XFX MERC（HIP_VISIBLE_DEVICES=0, UUID GPU-8accafcdfee6fc4f），端口 11435，Sapphire Pulse 上的 ComfyUI 不受影响。

总览

模式	速度	模型大小	量化	上下文	是否有 API	后端
A (DFlash)	84 tok/s	15.4G+1.8G	Q4_K_M + Q8 draft	32K	bench only	ROCm 7.2
B (IQ4_XS)	~30 / 37.7 tok/s	14G	IQ4_XS (4.25 bpw)	131K		ROCm / Vulkan
C (MTP)	~40 tok/s	16.7G	MTP Q4_K_P (65层)	65K		ROCm 7.14

模式 A — DFlash 投机解码（84 tok/s 纯跑分）

性能

单卡生成速度：~84 tok/s（Intel XEON E5-2680 v4 上验证）
使用 DFlash 草稿模型做投机解码，MTP 接受率 ~75%
限制：只能用 test_dflash / bench_he.py 跑分，没有 llama-server，没有 OpenAI API

启动参数

export HIP_VISIBLE_DEVICES=GPU-8accafcdfee6fc4f
export LD_LIBRARY_PATH=/opt/rocm-7.2.0/lib:$LD_LIBRARY_PATH
export HSA_OVERRIDE_GFX_VERSION=11.0.0
cd /home/peter/lucebox-hub/dflash

numactl --cpunodebind=0 --membind=0 python3 scripts/server.py \
  --target '/mnt/models/Qwen3.6/Huihui-Qwen3.6-27B-abliterated.Q4_K_M.gguf' \
  --draft models/dflash-draft-3.6-q8_0.gguf \
  --budget 8 \
  --max-ctx 32768 \
  --fa-window 0 \
  --tokenizer Qwen/Qwen3.6-27B \
  --cache-type-k q8_0 \
  --cache-type-v q4_0 \
  --host 0.0.0.0 --port 11435

适用场景

纯跑分/基准测试：验证硬件、对比投机策略效果
研究用途：DFlash 架构实验，不用于日常使用
️ 如果你需要速度且有 API server，选模式 C（MTP）更好

血训：严禁把模式 A 的模型 + 标准 AR 引擎称为"模式 A"。正确命名应该是 A-AR（四不像，~30 tok/s 无投机），这已经是个独立配置，和模式 A（DFlash 84 tok/s）完全不同。

模式 B — IQ4_XS 128K 长文本写作（30 / 37.7 tok/s）

性能

后端	Prefill (pp512)	Decode (tg128)	相对 ROCm
ROCm 7.2.0	946 t/s	29.7 t/s	—
Vulkan	697 t/s (-26%)	37.7 t/s (+27%)	短 prompt 优
ROCm 7.14 + XNACK=1	~950 t/s	~29.4 t/s	无收益

键发现：IQ4_XS 在 ROCm 7.14 + HSA_XNACK=1 上无收益（pp+1%, tg-2%）。高压缩比量化（4.25 bpw）的访存模式不利于 XNACK 机制。

启动参数

ROCm 版（start-qwen-b.sh）：

export LD_LIBRARY_PATH=/home/peter/llama.cpp/build-rocm/bin:/opt/rocm-7.2.0/lib:$LD_LIBRARY_PATH
export HIP_VISIBLE_DEVICES=GPU-8accafcdfee6fc4f
export HSA_OVERRIDE_GFX_VERSION=11.0.0

numactl --cpunodebind=0 --membind=0 llama-server \
  -m /mnt/models/Qwen3.6/Qwen3.6-27B-Uncensored-HauhauCS-Balanced-IQ4_XS.gguf \
  -c 131072 -ngl 99 \
  -fa 1 \
  --no-mmap \
  --tensor-split 0 \
  --cont-batching \
  --cache-type-k q4_0 --cache-type-v q4_0 \
  --host 0.0.0.0 --port 11435

Vulkan 版（start-qwen-b-vk.sh，decode +27%）：

export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.json
export LD_LIBRARY_PATH=/home/peter/llama.cpp/build-vulkan-new/bin:$LD_LIBRARY_PATH
export HSA_OVERRIDE_GFX_VERSION=11.0.0

numactl --cpunodebind=0 --membind=0 llama-server \
  -m /mnt/models/Qwen3.6/Qwen3.6-27B-Uncensored-HauhauCS-Balanced-IQ4_XS.gguf \
  --host 0.0.0.0 --port 11435 \
  -c 131072 -ngl 99 \
  -b 512 -ub 512 \
  --no-mmap \
  --main-gpu 0 \
  --cont-batching \
  --cache-type-k q4_0 --cache-type-v q4_0

关键参数说明

参数	含义	为什么这么设
`-c 131072`	上下文窗口 128K	IQ4_XS 显存余量充足（~15.6 GB/24 GB）
`-ctk q4_0 -ctv q4_0`	KV 缓存 q4_0	ROCm 上 q4_0 速度等同 q8_0，体积减半
`-fa 1`	Flash Attention	提升 prefill 50%+，仅 ROCm 可用
`--tensor-split 0`	锁单卡	防 IO 延迟波动
`--cont-batching`	连续批处理	多请求并发时有效
`-b 512 -ub 512`	batch/ubatch 512	省显存，不影响速度
`--no-mmap`	不进 page cache	防 X99 劣化

️ Vulkan 注意事项

-fa 1 在 Vulkan 上不可用，会导致模型 fallback CPU
VK_ICD_FILENAMES 仅加载 AMD 驱动，3080 Ti 不会被拉入
短 prompt 场景强烈推荐 Vulkan（decode +27%），长 prompt 切回 ROCm

适用场景

长文本写作：小说、论文、技术文档（128K 上下文）
文档处理：分析长报告、源代码库
聊天/日常使用：短 prompt 用 Vulkan 后端，长对话用 ROCm
Hermes 后端：配合 start-comfyui-with-qwen.sh 分卡并行

模式 C — MTP 自我投机解码（~40 tok/s）

性能（ROCm 7.14 + HSA_XNACK=1）

测试项	q4_0/q4_0 KV	q8_0/q8_0 KV	变化
AR pp512	946 t/s	956 t/s	-1%
AR tg128	29.7 t/s	30.1 t/s	-1.4%
MTP cli Prompt	52.7 t/s	52.5 t/s	持平
MTP cli Generation	39.8 t/s	34.8 t/s	+14.4%
KV 体积 (vs bf16)	28.1%	53.1%	-47%

关键发现：q4_0/q4_0 KV 在 MTP 模式下比 q8_0 更快！原因是 KV 带宽减少 47%，利好多 token 投机生成。Anbeeld 99.9% 尾部精度 89.84%（vs q8_0 的 94.61%），质量可接受。

MTP 接受率：~76%（预热后），短对话先跑 ngram 缓存填充期。

启动参数

export HSA_XNACK=1
export HSA_OVERRIDE_GFX_VERSION=11.0.0
export HIP_VISIBLE_DEVICES=GPU-8accafcdfee6fc4f
export LD_LIBRARY_PATH=/opt/rocm-7.14-therock/lib:$LD_LIBRARY_PATH

numactl --cpunodebind=0 --membind=0 /home/peter/llama.cpp/build-rocm-7.14/bin/llama-server \
  -m /mnt/models/Qwen3.6/Qwen3.6-27B-Uncensored-HauhauCS-Balanced-MTP-Q4_K_P.gguf \
  --host 0.0.0.0 --port 11435 \
  -c 65536 \
  -fa 1 \
  --spec-type draft-mtp \
  --spec-draft-n-max 3 \
  --batch-size 2048 --ubatch-size 512 \
  -ctk q4_0 -ctv q4_0 \
  --no-mmap \
  --tensor-split 0 \
  --reasoning off \
  --swa-checkpoints 0 \
  --ctx-checkpoints 69 \
  --repeat-penalty 1.1 --repeat-last-n 64 \
  --temp 0.4 --top-p 0.95 --top-k 20

关键参数说明

参数	含义	为什么必须加
`--spec-type draft-mtp`	MTP 自我投机	核心特性
`--spec-draft-n-max 3`	每次投机 3 个 token	甜点值
`--reasoning off`	禁用思考模式	必须：否则 content 永远为空
`--repeat-penalty 1.1 --repeat-last-n 64`	防重复循环	MTP 血训
`--temp 0.4 --top-p 0.95 --top-k 20`	AGI 社区甜点采样	平衡创造性与准确度
`--swa-checkpoints 0`	关闭 SWA checkpoint	根治 60K token re-prefill 卡顿
`--ctx-checkpoints 69`	每 69 层 checkpoint	防长上下文 OOM

VRAM 预算（q4_0 KV, 65K）

模型权重:        16.7 GB
MTP head 开销:   0.4 GB
q4_0 KV (65K):  ~2.8 GB
合计峰值:       ~19.9 GB / 24 GB（余量 4.1 GB）

为什么不选 ROCm 7.2？ 模式 C 的 MTP 模型在 ROCm 7.14 + XNACK=1 上 decode 快 11%（24.85 vs 22.15 t/s），且 7.2 上 server 模式启动就崩溃。

适用场景

日常聊天：Hermes 后端首选
编程助手：MTP 投机在代码生成中接受率很高
需要 API server 的场景：模式 A（DFlash）只有跑分工具，模式 C 有完整 OpenAI API
中长对话：预热后 MTP 接受率接近 100%

二、双卡模式 (D / E / F)

双卡用 GPU 0+1（XFX + Sapphire），自动停 ComfyUI。

总览

模式	速度	模型	量化	端口	引擎
D (layer)	~29 / 36.6 tok/s	Huihui Q4_K_M	Q4_K_M	18080	ROCm / Vulkan
D (MTP)	~22.5 tok/s	HauhauCS MTP Q4_K_P	Q4_K_P	18080	ROCm layer
E (Q8_0)	~23 tok/s	DavidAU / ggml-org Q8_0	Q8_0 ★★★★★	18081	ROCm layer
F (tensor)	38-172 tok/s	HauhauCS MTP Q4_K_P	Q4_K_P	18080	CainSay fork

模式 D — 双卡 layer split（29 / 36.6 tok/s）

性能对比

后端	Prefill (pp512)	Decode (tg128)	相对
ROCm 7.2 (q4_0)	888 t/s	22.5 t/s	—
ROCm 7.14 + XNACK (q4_0)	854 t/s	24.78 t/s	tg +12%
Vulkan (q4_0)	285 t/s (-68%)	36.6 t/s (+63%)	长生成最优

启动参数（ROCm Huihui Q4_K_M）

export HSA_OVERRIDE_GFX_VERSION=11.0.0
export LD_LIBRARY_PATH=/opt/rocm-7.2.0/lib:$LD_LIBRARY_PATH
export HIP_VISIBLE_DEVICES=0,1

numactl --cpunodebind=0 --membind=0 llama-server \
  -m /mnt/models/Qwen3.6/Huihui-Qwen3.6-27B-abliterated.Q4_K_M.gguf \
  --host 0.0.0.0 --port 18080 \
  -c 65536 -fa 1 \
  --split-mode layer \
  --cache-type-k q4_0 --cache-type-v q4_0 \
  -b 1024 -ub 1024 \
  --no-mmap

启动参数（Vulkan，decode +63%）

export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.json
export LD_LIBRARY_PATH=/home/peter/llama.cpp/build-vulkan-new/bin:$LD_LIBRARY_PATH
export HSA_OVERRIDE_GFX_VERSION=11.0.0

numactl --cpunodebind=0 --membind=0 /home/peter/llama.cpp/build-vulkan-new/bin/llama-server \
  -m /mnt/models/Qwen3.6/Huihui-Qwen3.6-27B-abliterated.Q4_K_M.gguf \
  --host 0.0.0.0 --port 18080 \
  -c 65536 \
  --split-mode layer \
  --cache-type-k q4_0 --cache-type-v q4_0 \
  -b 512 -ub 512 \
  --no-mmap

启动参数（双卡 MTP layer，HauhauCS MTP 模型）

export HIP_VISIBLE_DEVICES=GPU-16dc66d1309c376b,GPU-8accafcdfee6fc4f
export NCCL_P2P_DISABLE=1 RCCL_P2P_DISABLE=1
export NCCL_PROTO=Simple
export HSA_FORCE_FINE_GRAIN_PCIE=1 HSA_ENABLE_SDMA=0

numactl --cpunodebind=0 --membind=0 llama-server \
  -m /mnt/models/Qwen3.6/Qwen3.6-27B-Uncensored-HauhauCS-Balanced-MTP-Q4_K_P.gguf \
  --host 0.0.0.0 --port 18080 \
  -c 65536 -fa 1 \
  --split-mode layer --tensor-split 1,1 \
  --spec-type draft-mtp --spec-draft-n-max 3 \
  --cache-type-k q4_0 --cache-type-v q4_0 \
  --no-mmap

️ P2P 说明：双卡间 hipDeviceCanAccessPeer=0（不同 root port），必须设置 NCCL_P2P_DISABLE=1 + RCCL_P2P_DISABLE=1，否则 layer split 初始化死锁。

适用场景

双卡稳定性首选：layer split 最成熟、最稳定
Vulkan 长生成：如果 prompt 短（<2K tokens），Vulkan decode 比 ROCm 快 63%
中间过渡方案：从单卡升级到双卡的最佳起点

模式 E — 双卡 Q8_0 最高精度（~23 tok/s）

性能

AR decode: ~23 tok/s（双卡 layer split）
Prefill: 受 Q8_0 大模型（29.9G）和 X99 PCIe 3.0/魔改4.0 瓶颈限制
质量：★★★★★ — 社区公认 Qwen3.6-27B 最佳变体（DavidAU NEO-CODE-HERE）

启动参数

export HSA_OVERRIDE_GFX_VERSION=11.0.0
export LD_LIBRARY_PATH=/opt/rocm-7.2.0/lib:$LD_LIBRARY_PATH
export HIP_VISIBLE_DEVICES=GPU-16dc66d1309c376b,GPU-8accafcdfee6fc4f
export NCCL_PROTO=Simple
export HSA_FORCE_FINE_GRAIN_PCIE=1 HSA_ENABLE_SDMA=0

numactl --cpunodebind=0 --membind=0 llama-server \
  -m /mnt/models/Qwen3.6/Qwen3.6-27B-NEO-CODE-HERE-2T-OT-HIGH-Q8_0.gguf \
  --host 0.0.0.0 --port 18081 \
  -c 65536 -fa 1 \
  --split-mode layer --tensor-split 1,1 \
  --cache-type-k q8_0 --cache-type-v q8_0 \
  -b 256 -ub 64 \
  -fit off

几个坑

-fit off：关闭 KV cache 大小自适应，防 OOM
小 batch（256/64）：Q8_0 KV 显存占用大，必须保守
-c 65536：131K 塞不下（双卡 48G 显存，Q8_0 模型 29.9G + Q8_0 KV 在 65K 下已近顶）

适用场景

代码任务：DavidAU 变体专为代码优化（2T token 预训练）
高质量输出场景：Q8_0 量化几乎没有精度损失
对比基准：用于和其他量化（Q4_K_M, IQ4_XS）做质量对比
必须双卡：Q8_0 29.9G 单卡 24GB 塞不下

模式 F — 双卡 tensor MTP+ngram（38-172 tok/s ）

（编者注：这个模式跟大佬的性能差距打破了我对LLM大模型不吃CPU的刻板认知）

性能

场景	速度	说明
短对话（X99 DDR4）	~38 tok/s	ngram 缓存初始化期
长文本（X99 预热后）	~43 tok/s	MTP 接受率 ~86%
长文本（Ryzen 9700X 参考）	140-172 tok/s	X99 DDR4 是瓶颈
基准 MTP gen	52.7 t/s (prompt) / 39.8 t/s (gen)	单卡 q4_0 KV 参考

启动参数

export HSA_OVERRIDE_GFX_VERSION=11.0.0
export LD_LIBRARY_PATH=/opt/rocm-7.2.0/lib:$LD_LIBRARY_PATH
export HIP_VISIBLE_DEVICES=0,1
export NCCL_PROTO=Simple
export HSA_FORCE_FINE_GRAIN_PCIE=1 HSA_ENABLE_SDMA=0

numactl --cpunodebind=0 --membind=0 /home/peter/llama-cainsay/build-hip/bin/llama-server \
  -m /mnt/models/Qwen3.6/Qwen3.6-27B-Uncensored-HauhauCS-Balanced-MTP-Q4_K_P.gguf \
  --host 0.0.0.0 --port 18080 \
  -c 65536 -fa 1 \
  --kv-unified \
  --split-mode tensor --tensor-split 7,7 \
  --cache-type-k q8_0 --cache-type-v q8_0 \
  -b 1024 -ub 1024 \
  --spec-type draft-mtp,ngram-mod,ngram-map-k4v \
  --spec-draft-n-max 4 \
  --spec-ngram-map-k4v-size-m 64 \
  --repeat-penalty 1.1 --repeat-last-n 64 \
  --reasoning off \
  --temp 0.4 --top-p 0.95 --top-k 20 \
  -np 1 \
  --no-mmap

关键参数说明

参数	含义	为什么
`--split-mode tensor --tensor-split 7,7`	张量并行	双卡 7:7 平分层数
`--spec-type draft-mtp,ngram-mod,ngram-map-k4v`	三重投机	MTP + ngram + map 链式投机
`--spec-draft-n-max 4`	每步投机 4 token	ngram 链式最大收益
`--spec-ngram-map-k4v-size-m 64`	ngram map 大小 64M	缓存上下文匹配
`--kv-unified`	统一 KV	tensor split 必需
`-np 1`	单批处理	必须：防 GGML 内存池崩溃
`-ctk q8_0 -ctv q8_0`	KV q8_0	只能 q8_0：q4_0 触 tensor split GGML_ASSERT

️ 限制

只能 q8_0 KV：llama_params_fit 未为 SPLIT_MODE_TENSOR 实现，q4_0 触发 GGML_ASSERT 崩溃
SWA checkpoint bug：CainSay fork 和 upstream 一样，>60K context 后 SWA checkpoint 失效，触全量 re-prefill（2-3 分钟卡顿）
需要 CainSay fork（fix/split-mode-tensor-quant-kv 分支），upstream 没有 tensor split

适用场景

双卡最强输出：tensor split + MTP + ngram 三重投机，预热后极快
长文本生成：预热后稳定 ~43 tok/s（X99）、140+ tok/s（Ryzen）
适合能接受 60K 以内上下文的场景，超 60K 有 SWA bug
注意必须双卡（不能单卡 tensor split）

三、Vulkan 变体补充

变体	Decode	相对 ROCm	适用场景
B-Vk (单卡 IQ4_XS)	37.7 t/s	+27%	短 prompt 聊天
D-layer-Vk (双卡 layer)	36.6 t/s	+63%	长文本生成
B (ROCm)	29.7 t/s	—	长 prompt
D-layer (ROCm)	22.5 t/s	—	极长 prompt

Vulkan 特点：decode 恒定（不受 batch 大小影响），推荐 b=512 ub=512 或 b=1024 ub=512。 -fa 1 不可用。️ q5_0/q4_1 KV 在 Vulkan 上可用（ROCm 不行）。编译后必须验证 --list-devices 确实显示 GPU。

Vulkan 选型策略

prompt < 2K tokens → Vulkan（decode 快 27-63%）
prompt > 2K tokens → ROCm（prefill 快 26-68%）

四、模式选择决策树

你想做什么？
├── 跑分/基准测试 → 模式 A (DFlash 84 tok/s)
├── 日常聊天/编程助手
│   ├── 短对话 → 模式 B-Vk (Vulkan 37.7 t/s) 或 模式 C (MTP 40 t/s)
│   └── 长对话 → 模式 B ROCm (29.7 t/s, 131K ctx)
├── 长文本写作/文档处理 → 模式 B (IQ4_XS 131K)
├── 代码/高质量输出 → 模式 E (Q8_0 ★★★★★)
├── 双卡吞吐最大化
│   ├── 60K 以内上下文 → 模式 F (tensor MTP+ngram 🏆)
│   └── 稳定优先 → 模式 D (layer split)
└── 和 ComfyUI 并行运行
    └── start-comfyui-with-qwen.sh (默认模式 B)

五、性能测试方法论

所有数据来自 llama-bench 和 llama-server 实测，测试条件：

模型：Qwen3.6-27B 各量化变体
后端：ROCm 7.2.0 / 7.14-TheRock / Vulkan
CPU：Intel Xeon E5-2680 v4 (DDR4 2400)
GPU：双路 7900 XTX (XFX MERC + Sapphire Pulse)
NVMe SSD 加载模型，非 mmap

测试脚本和详细方法论见 references/rocm-comparison-testing.md 和 references/cross-backend-parameter-testing-20260619.md

六、更新日志

日期	更新内容
2026-06-19	q4_0/q4_0 推翻旧结论：MTP 模式 +14.4%；模式 C 更新 ROCm 7.14 + XNACK=1
2026-06-19	Vulkan 回归测试：双卡 decode +63%；q5_0/q4_1 KV Vulkan 可用
2026-06-19	全局推荐 `--swa-checkpoints 0` + `--ctx-checkpoints 69`
2026-06-19	新增模式 F (tensor MTP+ngram) 和 CainSay fork 基准
2026-06-16	初始版本：6 大模式 + 命名纪律确立

有问题欢迎交流！硬件环境（双 7900 XTX + X99）相近的兄弟可以直接抄参数。🫡

至此，7900 XTX 调教/折腾/学习篇到暂告一段落了，设备要开始投入进去找路子赚钱了，感谢各位的关注~！！！

以下是模式C运行时的截图

免责声明：
以下截图仅为展示模型性能，非搞黄色

abaalei

@LearningAI 我是
1.enable了Above 4G，不开启反而据说会识别不了
2.好象是吧csm关闭了
3.pcie锁死在3.0
大概就这些吧，我2块x99，一块x10dai当时是卡在开机自动搜索网络启动盘的问题，另外一块华强北的x99就出现在进系统后有线网卡（主板自带的双千兆跟自己买的小螃蟹2.5G）均无法识别的这两个问题上。
具体bios版本我具体也记不清了，印象中也是挺新的版本

abaalei

日期: 2026-06-19（续前篇） | 硬件: X99-6PLUS (Xeon E5-2682v4 × 2) + Sapphire RX 7900 XTX 24GB + XFX MERC 7900 XTX 24GB
模型: Qwen3.6-27B-Uncensored-HauhauCS-Balanced-MTP-Q4_K_P (16.7GB, 65层) / IQ4_XS (14GB, 64层)
引擎: upstream llama.cpp v9672 Vulkan (build-vulkan-new)
前篇: 7900 XTX ROCm KV Cache 量化交叉对比

上篇文章发出来后，有坛友回复说"试试 Vulkan 后端，50+ 稳定"。之前我们觉得 Vulkan 在 RDNA3 上应该比 ROCm 慢，一直没认真试——结果完全错了。
（手动补充：之前不用Vulkan是因为之前vulkan因为不明情况导致无法隔离3080ti，这次又可以了）

Vulkan 虽然 prefill 慢 26-72%，但 decode 快 27-63%，且 q5 系 kernel 没有 ROCm 上的致命惩罚。 这意味着很多之前在 ROCm 上被否决的方案——Anbeeld 的 q5_0/q4_1 甜点、IQ4_XS 加速、双卡 decode——在 Vulkan 上全部有效。

本篇文章记录系统性的 Vulkan 回归测试结果。

TL;DR

原来被否定的方案	之前结论	Vulkan 新结论	变化
Anbeeld q5_0/q4_1 KV	ROCm pp-62%	pp~690 tg~37	大翻盘
IQ4_XS 模型	~30 t/s	37.7 t/s	+24%
双卡 layer split	22.5 t/s (ROCm)	36.6 t/s	+63%
Vulkan 后端	以为比 ROCm 慢	decode 快 27-63%	各有所长
128K 上下文	OOM	同样不可行	️
iq4_nl/iq4_nl	ROCm 巨慢	Vulkan 也不支持	️

Vulkan 编译

cd ~/llama.cpp && mkdir build-vulkan-new && cd build-vulkan-new
cmake .. -DGGML_VULKAN=ON -DGGML_HIP=OFF -DCMAKE_BUILD_TYPE=Release
make -j$(nproc) llama-bench llama-server

注意：之前的 build-vulkan 编译时 GGML_VULKAN=OFF，导致所有测试都在 CPU 上跑。必须用新编译的版本。

使用隔离：

export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.json

关键区别：ROCm 的编译需要 20-30 分钟（HIP kernel），Vulkan 只需 5 分钟。

发现 1：q5 系 KV 在 Vulkan 上完美运行

IQ4_XS 模型

后端	KV	pp512	tg128	vs ROCm pp	vs ROCm tg
ROCm	q8_0/q8_0	370	30.3	—	—
Vulkan	q4_0/q4_0	697	37.7	+88%	+24%
Vulkan	q5_0/q4_1	693	37.2	+87%	+23%

IQ4_XS 模型在 Vulkan 上 prefill 几乎翻倍、decode 快 24%。这是本次测试的最大意外惊喜。

MTP Q4_K_P 模型（单卡 AR）

KV 配置	ROCm pp	Vulkan pp	ROCm tg	Vulkan tg	tg 变化
q8_0/q8_0	956	—	30.07	—	—
q4_0/q4_0	946	685	29.65	36.6	+23%
q5_0/q4_1	360	690	26.69	36.6	+37%
q5_0/q5_0	227	—	25.84	—	—

Vulkan 上所有 KV 类型的 decode 速度几乎一致（~36.6 t/s）。Anbeeld 的 q5_0/q4_1 甜点在 Vulkan 上完美可用。

发现 2：Batch/Ubatch 扫描

Vulkan 的 decode 速度几乎不受 batch/ubatch 影响：

b	ub	pp512	tg128
512	512	685	36.6
1024	512	681	36.7
2048	512	681	36.7
512	128	575	36.6
1024	1024	681	36.5

结论：Vulkan decode 恒定 ~36.6 t/s，推荐 -b 512 -ub 512 或 -b 1024 -ub 512 以优化 prefill。

这与 ROCm 截然不同——ROCm 上 batch/ubatch 可影响 10-15% 的 decode 速度。

发现 3：双卡 Layer Split 翻盘

后端	KV	pp512	tg128	vs ROCm tg
ROCm	q4_0/q4_0	888	22.5	—
Vulkan	q4_0/q4_0	285	36.6	+63%
Vulkan	q5_0/q4_1	689	36.6	+63%

双卡 Vulkan decode 比 ROCm 快 63%。虽然 prefill 慢（285 vs 888），但对于短 prompt 长生成的聊天场景，这是完胜。

发现 4：Vulkan Flash Attention 不存在 ️

-fa 1 在 Vulkan 上会导致模型加载到 CPU。Vulkan 后端没有 Flash Attention kernel 实现。

之前所有的 Vulkan 测试因为用 -fa 1 全部跑在 CPU 上（包括上一篇文章的部分数据）。这解释了为什么之前的 Vulkan prefill 只有 198-310 t/s——修正后（无 FA）Vulkan prefill 可达 685-697 t/s。

其他否决项验证

测试项	ROCm 结论	Vulkan 结论	变化
iq4_nl/iq4_nl KV	pp=232 tg=25	fallback CPU	️
128K 上下文 (单卡)	OOM	加载超时	️
DFlash	84 t/s	不适用（独立引擎）	️

更新后端选择指南

┌─────────────┬────────────────┬────────────────┬──────────────────┐
│ 使用场景     │ 推荐后端       │ 速度           │ KV 推荐           │
├─────────────┼────────────────┼────────────────┼──────────────────┤
│ 聊天/写作    │ Vulkan 🆕      │ tg ~37 t/s    │ q4_0/q4_0 或 q5_0│
│ (短 prompt)  │                │                │                    │
│ 长文档处理    │ ROCm           │ pp ~946 t/s   │ q4_0/q4_0         │
│ (长 prompt)  │                │                │                    │
│ MTP 推测解码  │ ROCm           │ gen ~40 t/s   │ q4_0/q4_0         │
│ 双卡聊天      │ Vulkan 🆕      │ tg ~36.6 t/s  │ q5_0/q4_1 🏆      │
│ 双卡 tensor   │ ROCm (CainSay) │ ~43 t/s       │ q8_0/q8_0         │
└─────────────┴────────────────┴────────────────┴──────────────────┘

修正之前结论

"q5_0/q4_1 在 AMD 卡上崩" → 仅在 ROCm 上崩。Vulkan 完美运行。 这是 kernel 优化问题，不是硬件问题。
"Vulkan 比 ROCm 慢" → decode 快 27-63%，prefill 慢 26-72%。 各有所长，互补关系。
"双卡 Vulkan 灾难性崩溃" → 那是旧 build（GGML_VULKAN=OFF）的 CPU 结果。正确编译后双卡 Vulkan decode +63%。
"IQ4_XS 慢" → ROCm 上确实一般，但 Vulkan 上 prefill 翻倍，decode 37.7 t/s。
"Vulkan 编译麻烦" → 5 分钟，比 ROCm（20-30 分钟）快得多。

经验教训

不要凭"直觉"否定一个后端。 我们之前认为 Vulkan 在 AMD 上一定比 ROCm 慢，所以连试都没试。一个群友回复就改变了整条优化路线。
两套后端是互补关系。 ROCm 擅长大批量 prefill 和 MTP 推测，Vulkan 擅长单步 decode 和多卡协同。
编译错了全白干。 第一次 Vulkan build 没开 GGML_VULKAN=ON，所有"Vulkan 测试"实际是 CPU 结果，浪费了大量时间。
Anbeeld 的数据是有价值的——只是需要在正确的后端上跑。 他的 q5_0/q4_1 推荐在 CUDA 和 Vulkan 上都成立，唯独 ROCm 不行。

有什么问题欢迎回复讨论。你们在 Vulkan 上试过双卡 tensor split 或者 MTP 吗？

更新脚本（241 上）：

~/start-qwen-b-vk.sh — 模式 B Vulkan（IQ4_XS，tg ~37.7 t/s）
~/start-qwen-modeD-layer-vk.sh — 双卡 layer Vulkan（tg ~36.6 t/s）

abaalei

@exe127 哈哈这要看你是想跑LLM还是文生图图生视频了。我下面还有LLM的帖子

我只能说我一开始3080ti 接windows，同时负责输出，显存就被吃三分之一了。跑整合包都经常OOM
hermes放哪里都没所谓，只要能24小时联网就行。但是我觉得大部分情况下，跑LLM没必要用自己部署的大模型，LLM的额度我目前以deepseek v4flash为主，gemini白嫖的pro会员为辅。基本上都够用了，我比较菜，2个月烧了500rmb的flash token

如果生成视频的话，就可以参考我的贴的部分参数来套用。我现在的目标是喊一声agent就能自己帮我跑管线，但是现在问题还有很多还需要debug

abaalei

@exe127 是啊,主要是LLM就算用api,只要不是fable5那些极端贵的模型,也花不了多少钱.相对的,跑视频就不是这个说法了,平均下来1元1秒,我冲了50元积分,都不敢怎么用就没了

abaalei

日期: 2026-06-19 | 硬件: X99-6PLUS (Xeon E5-2682v4 × 2) + 讯景 RX 7900 XTX 24GB + ROCm 7.2.0
模型: Qwen3.6-27B-Uncensored-HauhauCS-Balanced-MTP-Q4_K_P (16.7GB, 65 层)
引擎: upstream llama.cpp v9563 / CainSay fork fix/split-mode-tensor-quant-kv / Vulkan v9672
参考: Anbeeld KV Cache Quantization Benchmarks (RTX 3090)

本期更新：Vulkan 后端加入战场

帖子发出后，有群友回复说"试试 Vulkan 后端，50+ 稳定"。之前我们认为 Vulkan 在 RDNA3 上比 ROCm 慢所以没试，但实测结果出人意料——Vulkan decode 完胜 ROCm，且 q5 系 kernel 没有致命惩罚。 这意味着 Anbeeld 的完整推荐阶梯在 Vulkan 上全部可用。

以下为原 ROCm 测试 + 新增 Vulkan 对比的完整报告。

TL;DR

项目	结论
ROCm + q5 系 KV	prefill 暴跌 60-80%，不可用
ROCm + q4_0/q4_0	速度 = q8，MTP 快 14%，-47% 显存
Vulkan + 所有 KV 类型	decode 均正常，无 q5 惩罚
Vulkan AR decode	比 ROCm 快 17%
Vulkan 双卡 decode	比 ROCm 快 57%
Vulkan prefill	比 ROCm 慢 67-79%

起因

之前发了 MTP 优化帖后，有人分享了 Anbeeld 的 KV 量化文章。他用 RTX 3090 (CUDA) 测了 75 对 KV 缓存量化组合，结论是 q5_0/q4_1 是"VRAM 受限下最佳默认"。我寻思既然都是 Qwen3.6-27B 同款模型，不如搬过来试一试。

结果是 ROCm 上 q5 kernel 全崩。但 Vulkan 上，故事完全不同。

ROCm 实测数据

单卡 AR 基线 (llama-bench, pp512/tg128)

KV 配置	pp512	tg128	速度变化
q8_0/q8_0	955.65 t/s	30.07 t/s	基准
q4_0/q4_0	946.08 t/s	29.65 t/s	-1% / -1.4%
q5_0/q5_0	227.38 t/s	25.84 t/s	-76% / -14%
q5_0/q4_1	359.60 t/s	26.69 t/s	-62% / -11%
q8_0/q5_1	208.92 t/s	26.18 t/s	-78% / -13%

️ 对比 Anbeeld (RTX 3090)： 他那边 q5_0/q4_1 的 prefill 是 710 t/s（仅比 q8 慢 10%），我们直接掉到 360 t/s。这不是"差一点"，是 catastrophic failure。

单卡 MTP 实测 (llama-cli, p=20 n=256)

-ctk q8_0 -ctv q8_0  →  Prompt 52.5 t/s | Generation 34.8 t/s
+ctk q4_0 -ctv q4_0  →  Prompt 52.7 t/s | Generation 39.8 t/s 🚀

双卡 Layer Split

-ctk q8_0 -ctv q8_0  →  pp512 668.44 t/s | tg128 22.51 t/s
+ctk q4_0 -ctv q4_0  →  pp512 888.47 t/s | tg128 22.50 t/s 🚀 (+33% pp)

128K 上下文尝试

上下文	VRAM	MTP decode	结论
65K	~18.5 GB	39.8 t/s	推荐
128K	22.5 GB (93.75%)	16.3 t/s	太慢

Vulkan 后端实测（新增！）

坛友推荐 Vulkan 后端，编译只需 5 分钟（无需 HIP kernel 长编译），一试。

编译参数： cmake -DGGML_VULKAN=ON，用 VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.json 隔离 3080 Ti。

单卡 AR 对比

KV 配置	ROCm pp	Vulkan pp	ROCm tg	Vulkan tg	tg 变化
q8_0/q8_0	956	198	30.07	34.79	+15.7%
q4_0/q4_0	946	310	29.65	34.77	+17.3%
q5_0/q4_1	360	242	26.69	34.69	+30.0%
q5_0/q5_0	227	190	25.84	34.82	+34.7%
q8_0/q5_1	209	242	26.18	35.21	+34.5%
q5_0/q4_0	—	194	—	34.68	—

关键发现：Vulkan 上所有 q5 系 KV 都跑在 ~35 t/s！ 没有 ROCm 上的暴跌。Anbeeld 的 q5_0/q4_1 甜点终于在 AMD 卡上可用。

单卡 MTP

配置	ROCm	Vulkan
q4_0/q4_0 n=3	39.8 t/s	30.8 t/s
q5_0/q4_1 n=2	—	32.4 t/s
q8_0/q4_0 n=2	—	32.3 t/s

Vulkan MTP 不如 ROCm，但 AR decode 完胜。

双卡 Layer Split

后端	pp512	tg128
ROCm	888	22.50
Vulkan	285	35.37 +57%

双卡 Vulkan decode 比 ROCm 快 57%！ 适合纯聊天/长生成。

后端选择指南

┌─────────────┬────────────────┬────────────────┬──────────────────┐
│ 使用场景     │ 推荐后端       │ 速度           │ 理由              │
├─────────────┼────────────────┼────────────────┼──────────────────┤
│ 聊天/写作    │ Vulkan         │ tg 34.8 t/s    │ decode 快 17%     │
│ (短 prompt)  │                │                │                    │
│ 长文档处理    │ ROCm           │ pp 946 t/s     │ prefill 快 3x     │
│ (长 prompt)  │                │                │                    │
│ MTP 推测解码  │ ROCm           │ gen 39.8 t/s   │ MTP kernel 更优   │
│ 双卡聊天      │ Vulkan         │ tg 35.4 t/s    │ decode 快 57%     │
│ 双卡 tensor   │ ROCm (CainSay) │ ~43 t/s        │ Vulkan 不支持     │
└─────────────┴────────────────┴────────────────┴──────────────────┘

Vulkan 的 decode 优势来自 shader 级调度更高效；ROCm 的 prefill 优势来自批处理 kernel 深度优化。两者互补。

BeeLlama 和 GoodbyeCain 编译评估

BeeLlama: 核心特性 KVarN/TCQ 依赖 q5 kernel，ROCm 上已废。DFlash 我们已有（模式 A, 84 tok/s）。不推荐编译。

GoodbyeCain 最新 master (v50): ROCm 内存适配器有回归，无法加载模型到 GPU。不过 goodbyecain b9256 等价于我们已有的 CainSay fork（b9209 + 47 commits），SWA 稳定性已覆盖。

最终推荐 KV 配置

模式	推荐 KV	推荐后端	速度影响	显存
单卡 AR 聊天	`q4_0/q4_0`	Vulkan	tg +17%	-47%
单卡 MTP	`q4_0/q4_0`	ROCm	gen +14%	-47%
单卡长文档	`q4_0/q4_0`	ROCm	pp +205%	-47%
双卡 layer 聊天	`q4_0/q4_0`	Vulkan	tg +57%	-47%
双卡 tensor	`q8_0/q8_0`	ROCm	—	只能用 q8

经验教训

ROCm 和 Vulkan kernel 差异巨大。 ROCm q5 崩得一塌糊涂，Vulkan 上一样跑 35 t/s。结论：这是 kernel 优化问题，不是 AMD GPU 硬件问题。
两套后端互补，不是替代关系。 ROCm 赢 prefill 和 MTP，Vulkan 赢 decode 和双卡。最合理的方案是根据场景切换。
群友推荐值得试。 如果没试 Vulkan，我会一直以为"q5 kernel 在 AMD 上就是废的"。
X99 平台的双卡性能上限受 PCIe 3.0 / DDR4 限制。 CainSay 在 Ryzen 9700X + DDR5 跑 139 t/s，我们 28 t/s。硬件差距无解。

有什么问题欢迎回复讨论。你们在 Vulkan 上试过双卡 tensor split 吗？或者试过其他模型（Gemma 4 之类的）在 Vulkan vs ROCm 上的表现？

abaalei

@kos-or 我现在还没完全解决，我这个架子跟双路散热器冲突，所以导致延长线要大幅度弯折。我现在研究出来的是线长要限制在15cm内，并且插在距离cpu最近的插槽，才能被识别。然后现在最远的3080ti目前还没解决问题，昨天买了一根10cm的，还没到货，用15cm的，可以识别，但是只能跑pcie1.0 x16
主要还是我这块板太巨大了，8卡矿架都显得苗条了，估计得上12卡支架才能满足这块板的空间

抡锤者

abaalei

帖子

起因

测试平台

第一步：看协商状态

第二步：实际跑带宽

结论：所谓的"魔改 PCIe 4.0"到底是什么？

对 X99 双卡跑 LLM 的启示

附：Windows 上怎么测？

快速排查命令（Linux）

写在前面

🧪 硬件环境

目标

️ 完整折腾路线图（七阶段全记录）

阶段一：初识问题 — Fattn 崩溃

阶段二：尝试补丁 — TILE fallback patch（失败）

阶段三：证实方向 — FA_ALL_QUANTS=ON 完整编译

阶段四：测试 OBLITERATUS（假无审查 + 不兼容）

阶段五：测试 Huihui IQ4_XS（真无审查但龟速）

阶段六：测试 Heretic Q4_K_M（原生兼容但假无审查）

阶段七：FA_ALL_QUANTS=ON + --fa-window 0 + Huihui Q4_K_M

完整模型兼容性矩阵

最终性能对比

DFlash API 速度 (OpenAI 兼容 server)

bench_he.py 详细成绩 (Reddit 同款 10 HumanEval，2026-06-10)

模型去审查排名表

去审查实测验证

🧠 经验教训总结

参考来源

10天、18支视频：一人全栈AI漫画频道的完整踩坑记录

时间线速览（基于文件系统时间戳）

EP01：双引擎试错，烧¥50买认知

起步：想双线并进，WAN却直接翻车

被迫单线：LTX 2.3救场

成本

后续：WAN 2.2在后面几集成功接手

EP01的关键决策

EP02-03：固定工作流 + 首次视频化尝试

标准参数确立

EP03视频化：WAN修复后首测

EP04（6/23深夜）：标准管线诞生

EP05（6/24-25）：VAE紫色杂讯——又一个"紫色"bug

EP06（6/26）：管线精简 + 1080p上采样

EP07（6/27上午）：功能最丰富的一集

EP08（6/27晚-6/28重建）：效率冲刺

Illustrious模型测试（6/28）

EP02先于EP01完成？创作顺序的真相

EP06：漫画感的觉醒

核心问题

决策：AI出纯净图，后期手动加漫画元素

EP07（6/26-27）：工作流全面优化

6/27的系统性优化

EP08+：效率飞轮

技术参数附录

ComfyUI 静态出图（Animagine XL V3 + LoRA）

LTX 2.3 视频生成

WAN 2.2 视频生成

RIFE 帧插值

双卡负载分配（batch_submit_v5 交替模式）

标准EP管线目录

成本

核心心得

——X99 平台双消费级 RDNA3 的多卡深渊

一、序：为什么会有这篇文

二、硬件拓扑

三、推进路线图（含时间线）

四、关键发现

4.1 RCCL allreduce 静默内存损坏 —— 根因

4.2 不是 COLLTRACE 的问题

4.3 不是 X99 独有问题

4.4 不是特定 NCCL 协议的问题

五、可行与非可行方案

不可行

可行

理论可能但未验证

六、调试工具备忘

七、系统优化 (已应用)

八、最后的忠告

前情