直出的视频截图，看着还行，都不用超分了

视频超过2M上传不了，一会压缩下

《重构人生》H3 视频 —— 跑通环境配置 & 时间基准

日期：2026-08-31 凌晨（最终跑通版）
结论：Ref2VA 测试片（含中文台词 + 字幕）已跑通，此文档记录可复现的环境配置与实测耗时。

---

一、硬件

• CPU：Intel Ultra 7 270K Plus（24 核 / 62GB 内存）
• GPU：2× AMD Radeon AI PRO R9700 32GB（gfx1201 / RDNA4，PCIe 5.0 x8+x8，无 P2P）
• 系统：Ubuntu 24.04

---

二、软件栈（关键版本）

组件	版本
torch	2.11.0+rocm7.2（勿用 2.10+rocm7.0=挂死黑屏，勿用 2.12+rocm7.14=DynamicVRAM 卡死）
torchvision / torchaudio	0.26.0+rocm7.2 / 2.11.0+rocm7.2
ComfyUI	0.33.0
comfy-kitchen	0.2.31（HIP 后端）
comfy-aimdo	0.4.13（DynamicVRAM 未启用，健康态）
Python	3.11.16（venv: ~/comfy-h3/venv）

关键软链（comfy-kitchen HIP 原生内核）：

ln -sf libamdhip64.so libamdhip64.so.7   # 在 venv/.../torch/lib/ 下

---

三、启动参数（ComfyUI）

export HSA_XNACK=0
python main.py --listen 127.0.0.1 --port 8188 --reserve-vram 1.0

• 不带 --gpu-only（DiT 20GB 会因显存碎片 OOM）
• HSA_XNACK=0 抑制 SVM 页迁移开销
• 启动脚本：~/comfy-h3/start-comfy-rocm7.sh

---

四、模型文件

角色	文件	大小
DiT 主模型	minimax_h3_fl2va_pruned_int8_convrot.safetensors	20G
文本编码器 TE	qwen3vl_32b_minimax_h3_int8_convrot.safetensors（INT8，必用，勿用 nvfp4）	26G
视频 VAE	minimax_h3_video_vae_fp16.safetensors	4.9G
音频 VAE	minimax_h3_audio_vae_fp32.safetensors	578M
8步 turbo LoRA	minimax_h3_fl2v_turbo_8step_v1.0_comfyui_bf16.safetensors	1.9G

---

五、双卡摆放（ComfyUI-MultiGPU）

组件	设备	节点
DiT	cuda:0	UNETLoaderMultiGPU(device=cuda:0)
文本编码器 TE	cuda:1	CLIPLoaderMultiGPU(device=cuda:1)
视频 VAE	cuda:1	VAELoaderMultiGPU(device=cuda:1)
音频 VAE	cuda:1	VAELoaderMultiGPU(device=cuda:1)

---

六、工作流参数（8步 turbo）

• 采样器 res_multistep + scheduler simple + steps=8 + denoise=1.0 + LoRA strength 1.0
• 提交：~/comfy-h3/gen_h3.sh（T2V）/ ~/comfy-h3/gen_h3_ref2va.py（Ref2VA）
• 帧网格 17k+5：5s=124帧、10s=243帧

Ref2VA 测试片参数：768×1344 竖屏 / 243帧(10s) / 8步 / ref-size=match / 3 参考图（林远/赵天成/会议室）

---

七、实测时间基准

任务	分辨率/时长	采样速度	全程耗时
H3 T2V 冒烟	864×480 / 5s(124帧)	11.6s/it	176s（约 3 分钟）
Krea-2 生图	768×1344	1.35s/it	30s
Ref2VA 测试片	768×1344 / 10s(243帧)	190s/it	27分03秒

• 竖屏 768×1344 像素 ≈ 864×480 的 2.5 倍，加上 Ref2VA 参考图参与每个采样步，故 190s/it（T2V 横屏的 16 倍/步）。
• 加载阶段（TE 26GB + DiT 20GB + 参考图）约 1.5 分钟；采样 8 步约 25 分钟；VAE 解码约 2 分钟。
• dmesg SVM 计数全程 0（无卡死、无页迁移死循环）。

---

八、跑通验证

1. TE 加载：loaded completely; 30714.80 MB usable, 25883.83 MB loaded, full load: True（健康态，非 DynamicVRAM 分阶段）
2. 身份三锚定：林远（侧分短发/细框眼镜/深灰T恤）、赵天成（中分油头/金丝眼镜/圆脸/藏青西装）、会议室（玻璃桌/红色 SYSTEM FAILURE 屏/冷白光）全部照图生成，零漂移、无第三人。
3. 中文台词：<d>[Chinese] 林远，数据库是你动的吧？</d> + <d>[Chinese] 我没碰过生产数据。</d>，人声时段音量 +3~4dB 确认念出。
4. 字幕：ASS（Noto Sans CJK SC，白字黑边）时间轴对齐台词。

---

九、一句话可复现

torch 2.11.0+rocm7.2 + ComfyUI 0.33 + INT8 TE + HSA_XNACK=0 + 8步 turbo + 双卡 MultiGPU，Ref2VA 竖屏 10s 约 27 分钟出片。

再就是 我现在双卡R9700 跑Q8的速度跟单卡跑Q4的速度差不多 >_<

差不多，我也测了一下单卡r9700
════ 单卡 Qwen3.8-27B Q4_K_M 速度实测 ════

测试配置（单卡卡0，HIP_VISIBLE_DEVICES=0）：
· 引擎：llama.cpp build-714（commit 70adb1b，ROCm 7.14，链接 7.14 库）
· 模型：Qwen3.8-27B-UD-Q4_K_M.gguf（Q4_K_M 量化，16G）
· MTP 草稿：mtp-Qwen3.8-27B-Q4_0.gguf（--spec-draft-n-max 4）
· 视觉：mmproj-Qwen3.8-27B-Q8_0.gguf → 支持图文
· 其他：-fa on、-ngl 999、-np 1

实测矩阵（生成 300 token，long-form 中文 / 确定性数学）：

上下文 KV量化 MTP 开放内容t/s 数学t/s MTP接受率
128k f16 ON 39.12 58.18 0.40 / 0.72
128k f16 OFF 29.33 29.19 —
128k q8_0 ON 43.42 59.80 0.47 / 0.75
256k q8_0 ON 40.78 59.88 0.44 / 0.75

各参数影响（控制变量）：

1. MTP 开关（128k f16）：开 39 vs 关 29 → MTP 帮约 +34%；数学题因接受率 0.72-0.75 能拉到 58-60（+100%）
2. KV 量化（128k MTP on）：f16 39.1 vs q8_0 43.4 → q8_0 快约 10%（KV 传输省带宽），且显存更省
3. 上下文（q8_0 MTP on）：256k 40.8 vs 128k 43.4 → 256k 略慢约 6%（更大 KV 注意力），但它放得下是重点
4. 显存：128k f16 ≈ 28.8G；256k q8_0 ≈ 31.2G（贴边，只余 ~3G）——256k 必须用 q8_0 KV，f16 在单卡 31G 放不下（约需 40G+，会 OOM）
5. prompt 处理：数学 pp 到 80-102 t/s（确定性短prompt 快）

你这是真快啊。。。

查了一下 llama.cpp双卡调度可能不如vllm，晚上跑了一下单卡 27BQ4量化 +64k上下文+mtp+kvq4量化 速度50+t/s 明天再试试vllm跑双卡的；一个人用无并发 主要还是考虑输出质量

@Xiaote 把你的结论让hermes拿去验证了一下，似乎提升不大
【一、当前稳定配置（最终状态）】
主模型: UD-Q6_K_L (24.19GB) —— 维持现状, Q8_K_L 暂缓(断点保留)
草稿器: MTP Q4_0, n-max 3 (实测甜点)
视觉: mmproj-Q8_0 (0.63GB) 已启用, 实测通过
并行: 双卡 PP (Vulkan0 + RPC 第二卡), 128K 上下文
速度: 34.5 t/s 稳定, 接受率 0.52
显存: ~36GB / 62GB 可用
新增组件: 任务栏托盘 (llama-tray, 启停/显存监控/开机自启)

【二、速度优化实测 (A/B, 固定prompt贪心256tok, 3次中位数)】
MTP n-max 3 (基线) 34.5 t/s accept 0.52 保持
MTP n-max 4 30.0 t/s accept 0.39 -13%
MTP n-max 5 27.3 t/s accept 0.33 -21%
DFlash2 Q4_K_M 无法加载 - 等 llama.cpp 更新

结论: n-max 3 是甜点(草稿第4个token起猜不中, 白跑还拖慢);
DFlash2 文件完好(sha256 官方一致)但 b10568 主线版不兼容
Inco AI 的 GGUF(官方 issue #25116 确认是普遍问题, 等更新)。

【三、问题诊断结论】

1. "Agentic turn limit reached" —— 不是模型问题:
   llama.cpp --agent 内置工具系统不识别 Qwen 的 <tool_call> XML 文本格式,
   模型反复尝试调工具但执行不了 → 撞上防死循环上限。
   纯聊天/发图完全正常; 标准 OpenAI tools API 链路实测完美(对照实验)。
2. dsh 接入: 不会有此问题 —— dsh 走标准 tools API (实测验证的链路),
   llama.cpp 只当纯推理后端。建议届时去掉 --agent, 各司其职。

【四、专家方案逐条验证】
真实: --split-mode tensor 参数(b8738起)、qwen35 支持 TP、DFlash2、
MTP n-max A/B 必要性、换后端重测
修正: RCCL 默认禁用且官方称非普遍有益; Vulkan 版 tensor 模式官方
明示"长上下文差+不稳定"; ROCm tensor 实测(官方)也差于 layer;
"fused Gated Delta Net 被禁用"本机日志无法复现(Vulkan 库里有这些核);
129K 缩短 1/3 无出处。

【五、待办/后续方向】

1. 监控 llama.cpp 更新, DFlash2 兼容版一出即可 --dflash 切换实测(已就绪)
2. 中期可选: 自编译 HIP 版 (GGML_HIP_RCCL=ON) 实测 -sm tensor, 拿自家
   数据说话(预期放低, 官方 AMD 数据不利)
3. Q8_K_L 断点保留在 ~/models/ (7GB .part), 想换随时续传
4. dsh 接入时: base_url=http://localhost:8080/v1, 并去掉 --agent

一句话: 当前配置已是 Vulkan 路线上的实测甜点(质量无损前提下), 剩余提速
空间在 DFlash2 兼容更新和 HIP/TP 两条外部路线上, 均已就绪待验证。

@williamlouis 别那么乐观

之前玩AI入的N卡看涨价厉害卖了。。。但实在又想玩AI本地部署（文本和视频都想玩），又入了两张r9700，今天刚点亮，跑个qwen3.8 27b给大家分享下

硬件配置：

操作系统:Ubuntu 24.04,内核 7.0.0-30-generic

CPU:Intel Core Ultra 7 270K Plus(Arrow Lake)

• 24 核,最高频率 5.5 GHz

内存:64GB(系统识别 62GiB,当前空闲约 29GB)

显卡:2× AMD Radeon AI PRO R9700(工作站版,RDNA4/gfx1201)

• 单卡 32GB GDDR6,可用显存各 31.9 GiB
• PCI ID 1002:7551
• 双卡拓扑:PCIe 5.0 板内拆分 x8 + x8(主板 BIOS 启用)
  • card1 = 04:00.0(本地直连,承担显示输出)
  • card2 = 07:00.0(经 RPC 挂载,纯计算)
• 驱动:Mesa RADV 25.2.8(Vulkan),内核 amdgpu
• 未安装 ROCm(因此 llama.cpp 走 Vulkan 后端)

主板:铭瑄 iCraft Z890 Pacific(Intel Z890 芯片组)

工具

【一、当前工具/部署栈】 │
│ - llama.cpp b10568(Vulkan 预编译版)+ ggml-rpc-server(RPC 双卡桥) │
│ - 模型:Qwen3.8-27B unsloth UD-Q6_K_L(6-bit 动态量化,22.5GB) │
│ - 草稿模型:mtp-Qwen3.8-27B-Q4_0(1.37GB,MTP 投机解码用) │
│ - GPU:Mesa RADV 25.2.8 驱动(RDNA4 gfx1201 原生支持) │
│ - 服务器参数:128K 上下文、-cram 40000、-fa on、-np 1、--agent、--jinja │
│ │
│ 【二、已生效的加速机制】 │
│ 1. MTP 投机解码:--spec-type draft-mtp + Q4 草稿模型(--spec-draft-n-max 3)。效果最显著:生成从 21 → 36-49 tok/s(约 1.6-2.3x),接受率实测 0.41-0.88 │
│ 2. 双卡并行:layer split 流水线 + RPC,权重和 128K KV cache 按显存比例分摊(card1 1/3、card2 2/3),两卡实测负载 30%/69% │
│ 3. Flash Attention:-fa on(注意:日志显示 fused Gated Delta Net 被禁用,flash-attn 正常) │
│ 4. UD 动态量化:unsloth 的 Q6_K_L 质量接近 Q8、体积只有 24GB,带宽友好 │
│ 5. KV cache 双卡分摊:128K 上下文 KV 全在显存(无 RAM 回退),这是 128K 下仍保持 36 tok/s 的关键 │
│ 6. Prompt caching(自动):日志 graphs reused / LCP similarity 显示上下文复用已在工作,重复 prompt 命中缓存 │
│ 7. 单槽位(-np 1):避免多槽 KV 碎片 │
│ 8. 模型 mmap 加载:启动 17 秒,内存映射零拷贝 │
│ │

效果

│ - 生成(tg):36 tok/s 稳定,短对话峰值 49 tok/s
│ - prompt 处理(pp):短 prompt 497 t/s,长 prompt(375 tokens)280 t/s
│ - 这是 27B 稠密模型 Q6 在双 R9700 上的成绩