硬件环境：X99 双路 E5-2682v4 / DDR4 2133 / Sapphire Pulse 7900 XTX + XFX MERC 7900 XTX + RTX 3080 Ti / ROCm 7.2.0 / CainSay llama.cpp fork

前言

之前搞 CainSay MTP+ngram 双卡推测解码时一切顺利，结果这次在**单卡模式 C（MTP Q4_K_P）**上栽了三个连环坑。记录一下，后人别踩。

坑一：模式定义混乱（都是AI/Deepseek v4 Flash的锅，自作主张）

背景：原有的单卡三模式：

• A：Huihui Q4_K_M + DFlash（84 tok/s，bench only）
• B：HauhauCS IQ4_XS（30 tok/s，128K）
• C：MTP Q4_K_P + MTP n=3（~47 tok/s）

踩坑：我想给 Hermes 找个 API server 可用的模式，自作主张搞了个"四不像"——Huihui Q4_K_M + 标准 AR 自回归。既没 DFlash 加速（丢掉了模式 A 的 84 tok/s），又没 MTP 推测加速（不如模式 C 的 47 tok/s），也没 IQ4_XS 的 128K 上下文（不如模式 B）。30 tok/s 的四不像毫无存在意义。

教训：已有清晰定义的不要乱改，先问用户（给各位用hermes的留一个经验吧）。

坑二：ComfyUI 抢占 GPU

背景：241 上有三张卡——2×7900 XTX + 1×3080 Ti。设计分配：

• GPU 0（Sapphire Pulse）→ Qwen 单卡
• GPU 1（XFX MERC）→ ComfyUI

踩坑：之前测试模式 C 时长久不用的 ComfyUI 跑在了 GPU 1（XFX）上，占了 6.7GB VRAM。而模式 C 脚本也指定 GPU 1（UUID GPU-8accafcdfee6fc4f），导致加载 16.7GB MTP 模型时 OOM：

E ggml_backend_cuda_buffer_type_alloc_buffer: allocating 1995.00 MiB on device 0: cudaMalloc failed: out of memory

排查过程：

1. rocm-smi --showpids 发现 PID 138160（python = ComfyUI）吃了 GPU 1 的 6.7GB
2. ROCm 拓扑映射：GPU[0]=PCI 04:00.0=card1=Sapphire、GPU[1]=PCI 07:00.0=card3=XFX
3. ComfyUI 用 HIP_VISIBLE_DEVICES=1（索引号指向 GPU 1 XFX），模式 C 用 UUID GPU-8accafcdfee6fc4f（也是 XFX）

修复：用 start-comfyui-with-qwen.sh 正确分卡：

ComfyUI → HIP_VISIBLE_DEVICES=1 → XFX MERC (GPU 1)
Qwen    → HIP_VISIBLE_DEVICES=0 → Sapphire Pulse (GPU 0)

分卡后各自正常：

Sapphire: 21.6GB / 24GB（Qwen MTP）
XFX:       0.3GB / 24GB（ComfyUI 空载）

教训：start-comfyui-with-qwen.sh 才是可靠的分卡方案，不要手动 kill/start。

坑三：MTP 模型的思考模式

最大坑。HauhauCS-Balanced-MTP-Q4_K_P 这个模型内置了思考/推理模板，默认输出格式：

{
  "role": "assistant",
  "content": "",
  "reasoning_content": "Here's a thinking process:\n\n1. Analyze User Input..."
}

所有输出都塞进 reasoning_content，content 字段永远为空。Hermes 只读 content，所以收到空回复。

尝试修复：

1. --reasoning-format deepseek-legacy → 依然 content 为空
2. 加大 max_tokens=300 → 仍然全部在 reasoning_content，最终回答草稿也写在 reasoning 里
3. 结论：这是模型训练时固定的输出格式，没有 分隔，无法分离"思考"和"回答"

最终方案：加 --reasoning off 关闭思考模式，content 恢复正常：

{
  "content": "你好！👋 请问有什么我可以帮你的吗？",
  "reasoning_content": "no reasoning"
}

教训：社区微调模型可能改了输出格式，--reasoning off 对 Hermes 这类只读 content 字段的客户端是必备参数。

最终配置（可复现）

┌──────────────────────────────────────────────────────────┐
│  241 最终分卡方案                                        │
│  ComfyUI → GPU 1 (XFX)     端口 8188                    │
│  Qwen 模式C → GPU 0 (Sapphire) 端口 11435               │
├──────────────────────────────────────────────────────────┤
│  Qwen 启动参数：                                          │
│  --spec-type draft-mtp --spec-draft-n-max 3              │
│  -ctk q8_0 -ctv q8_0                                    │
│  -fa 1 -b 2048 -ub 512                                  │
│  --reasoning off                                          │
│  --repeat-penalty 1.1 --repeat-last-n 64                 │
├──────────────────────────────────────────────────────────┤
│  性能：短提示(13 tokens) 17 tok/s                        │
│        长提示(14 tokens) 29 tok/s                        │
│  接受率：短提示 38%，长提示 100%                           │
└──────────────────────────────────────────────────────────┘

问：MTP 模式下能同时跑 ComfyUI 吗？
答：可以，前提是用 start-comfyui-with-qwen.sh 正确分卡。ComfyUI 至今没加载模型所以只有 0.3GB 占用，如果加载大模型要注意两卡各自的 VRAM 余量。

问：模式 A（DFlash）和模式 C（MTP）哪个快？
答：模式 A 单卡 bench 84 tok/s 但无 server，模式 C 有 server 但 17-29 tok/s 受 CPU/DDR4 瓶颈限制。两码事不能直接比。

（其实这件事还有下文，就是被hermes弄乱了单卡模式，导致comfyui一直OOM，后面再水文了）