补 docs/todo：RTX PRO 6000 int8-convrot 调研 + Raylight/ComfyUI 多卡评估

补齐 h3-rtxpro6000-setup.md（另一线程的调研，之前只在磁盘上没提交）。新增 raylight-comfyui-multi-gpu-eval.md：2K 分辨率外推显示 2080Ti 显存需求随 rows 超线性增长，DiffSynth-Studio 现有架构不支持多卡拆分单次生成；调研到 Raylight（ComfyUI 插件）支持 Turing+PCIe+MiniMax-H3 的序列并行，但要换整套推理引擎，是独立迁移项目。建议先做 quality-tuning-plan.md 里不用下载东西的两项，排除画质问题不是量化精度导致的，再决定要不要推进。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

补 docs/todo：RTX PRO 6000 int8-convrot 调研 + Raylight/ComfyUI 多卡评估
补齐 h3-rtxpro6000-setup.md（另一线程的调研，之前只在磁盘上没提交）。新增 raylight-comfyui-multi-gpu-eval.md：2K 分辨率外推显示 2080Ti 显存需求随 rows 超线性增长，DiffSynth-Studio 现有架构不支持多卡拆分单次生成；调研到 Raylight（ComfyUI 插件）支持 Turing+PCIe+MiniMax-H3 的序列并行，但要换整套推理引擎，是独立迁移项目。建议先做 quality-tuning-plan.md 里不用下载东西的两项，排除画质问题不是量化精度导致的，再决定要不要推进。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
yibo
1 parent 6b3f5a6a
Showing 3 changed files with 192 additions and 0 deletions
docs/README.md
docs/todo/h3-rtxpro6000-setup.md
docs/todo/raylight-comfyui-multi-gpu-eval.md
@@ -10,6 +10,14 @@
   参考视频功能（2026-08-20 本地写的，没有 GPU 没测过），明天回服务器第一件事要验证
 - [quality-tuning-plan.md](todo/quality-tuning-plan.md) — 为什么生成视频画质比 ComfyUI 官方
   演示差很多：分辨率/Turbo步数/CFG/negative prompt 几个待实测方向，按优先级排好了
+- [h3-rtxpro6000-setup.md](todo/h3-rtxpro6000-setup.md) — 新租的 RTX PRO 6000（Blackwell
+  96GB）装 H3 的调研：为什么不用 GGUF、精度选型对比（NF4/int8-convrot/fp8/bf16 实测文件大小）、
+  uv 环境搭建方式，还没开始下权重
+- [raylight-comfyui-multi-gpu-eval.md](todo/raylight-comfyui-multi-gpu-eval.md) — 评估要不要把
+  2080Ti 那套换成 ComfyUI + Raylight 做序列并行，把 4×22G 当一个显存池用来跑更高分辨率/更长
+  时长——调研阶段，确认现有 DiffSynth-Studio 架构不支持多卡拆分；Raylight 确认支持 Turing+PCIe+
+  MiniMax-H3，但要换整套推理引擎，是独立迁移项目不是顺手能试的，建议先做完
+  quality-tuning-plan.md 里不用下载东西的两项再决定要不要推进
  
 ## done
  
+# 新机器：RTX PRO 6000 装 H3（调研阶段，还没跑通）
+
+**背景**：新租了一台 AutoDL 容器（`connect.westd.seetacloud.com:17473`），单卡 RTX PRO 6000
+Blackwell 96GB，跟 2080Ti 那套完全不共享环境。这篇记 2026-08-20 的调研结论和待办，
+真正装完跑通后按顶层 `CLAUDE.md` 的目录约定建 `h3-rtxpro6000/` workload 目录 + CHANGELOG 一节。
+
+## 机器情况
+
+| 项 | 值 |
+|---|---|
+| GPU | RTX PRO 6000 Blackwell，96GB（`nvidia-smi` 显示 97887MiB），**compute cap 12.0（sm_120）** |
+| 驱动/CUDA | 595.58.03 / CUDA 13.2 |
+| CPU/内存 | 208 核 / 1TB |
+| 系统盘 | 30GB，**容器重启会重置，别往这儿装东西** |
+| 数据盘 | `/root/autodl-tmp`，已从免费 50GB 扩到 **100GB**（扩容需在 AutoDL 网页控制台点重启才生效，容器内 `reboot` 没用——PID1 是裸 bash 不是 init，见下） |
+| 系统 | Ubuntu 22.04，容器化（`/.dockerenv` 存在），预装 miniconda3 + torch 2.12.1+cu130 |
+| 网络 | ModelScope **直连**（`no_proxy` 已含 `modelscope.com`），HuggingFace/GitHub 需 `source /etc/network_turbo`（AutoDL 学术加速，仅限这两个域名+相关 CDN，见 https://www.autodl.com/docs/network_turbo/ ） |
+
+## 环境搭建方式（按用户要求）
+
+不用 conda 装依赖，改用 **uv**（比 pip 快几十倍，包解析方式不同）：
+
+```bash
+source /root/miniconda3/etc/profile.d/conda.sh && conda activate base   # 只为了拿到 uv 这个二进制
+pip install -q uv                                                        # /etc/pip.conf 已配好 aliyun 源
+mkdir -p /root/autodl-tmp/minimax-h3 && cd /root/autodl-tmp/minimax-h3
+export UV_INDEX_URL=http://mirrors.aliyun.com/pypi/simple
+uv venv --python 3.12 .venv && source .venv/bin/activate
+uv pip install torch          # 走 aliyun 镜像，几十秒装完 2.13.0+cu130
+```
+
+阿里云源本身就镜像了 PyPI 官方的 cu130 捆绑 wheel，不需要单独配 pytorch.org 的 index。
+
+## 精度选型（这是本次调研的主要产出）
+
+用户原话："主要是 DiffSynth-Studio + NF4 safetensors 这个模型的质量不行，我担心是模型量化不行导致的"。
+
+### 排除项：不要用 GGUF（`Abiray/MiniMax-H3-GGUF` 等）
+
+HF 上搜到的 GGUF 版本下载量最高，但 model card **没有说明配哪个推理引擎**。H3 是 DiT 扩散模型
+不是标准 LLM，GGUF 在这类模型上依赖专门的 loader（比如 ComfyUI-GGUF 自定义节点），
+需要有人专门写过 H3 这个架构的支持。我们已验证能跑通的是 DiffSynth-Studio，它不支持 GGUF 加载。
+换 GGUF＝换整条推理栈，风险和收益不对等，放弃。
+
+### 各精度组合实测文件大小（HF API 直查，非猜测）
+
+| 组件 | NF4（2080Ti 在用） | int8-convrot（本次选定） | fp8 剪枝 | bf16 原精度 |
+|---|---|---|---|---|
+| DiT (FL2VA) | 16.0 GB | **20.97 GB** | 20.96 GB（剪枝版） | 66.28 GB |
+| 文本编码器 (Qwen3-VL 32B) | 14.3 GB | **27.14 GB** | — | 51.51 GB |
+| video_vae | 1.5 GB | 5.21 GB (fp16) | 同左 | 同左 |
+| audio_vae | 0.26 GB | 0.61 GB (fp32) | 同左 | 同左 |
+| **合计** | 33.3 GB | **53.93 GB** | ~47GB（DiT剪枝+bf16文本编码器需另算）| 123.6 GB |
+
+bf16 全精度超过 100GB 数据盘，且两个大件同时常驻显存需 117GB＞96GB 显存，暂不选。
+
+### 关键发现：DiffSynth-Studio 官方文档明确支持 Comfy-Org 的 int8/fp8 权重
+
+不是只支持自家 NF4。文档原话："The int8-quantized weights released by Comfy-Org are
+supported as well, via the comfy-kitchen backend, which requires `pip install "diffsynth[quant]"`"。
+官方示例代码（`examples/minimax_h3/model_inference/MiniMax-H3-Int8-ConvRot-FL2VA.py`）：
+
+```python
+vram_config = {
+    "offload_dtype": torch.bfloat16, "offload_device": "cpu",
+    "onload_dtype": torch.bfloat16, "onload_device": "cpu",
+    "preparing_dtype": torch.bfloat16, "preparing_device": "cuda",
+    "computation_dtype": torch.bfloat16, "computation_device": "cuda",
+}
+pipe = MiniMaxH3Pipeline.from_pretrained(
+    torch_dtype=torch.bfloat16, device="cuda",
+    model_configs=[
+        ModelConfig(model_id="Comfy-Org/MiniMax-H3", origin_file_pattern="diffusion_models/minimax_h3_fl2va_int8_convrot.safetensors", **vram_config),
+        ModelConfig(model_id="Comfy-Org/MiniMax-H3", origin_file_pattern="text_encoders/qwen3vl_32b_minimax_h3_int8_convrot.safetensors", **vram_config),
+        ModelConfig(model_id="MiniMax/MiniMax-H3", origin_file_pattern="FL2VA/video_vae/source/model.safetensors", **vram_config),
+        ModelConfig(model_id="MiniMax/MiniMax-H3", origin_file_pattern="FL2VA/audio_vae/model.safetensors", **vram_config),
+    ],
+    processor_config=ModelConfig(model_id="MiniMax/MiniMax-H3", origin_file_pattern="FL2VA/processor/"),
+    vram_limit=torch.cuda.mem_get_info("cuda")[1] / (1024 ** 3) - 2,   # 单卡独占，直接按总显存留 2G
+)
+```
+
+`Comfy-Org/MiniMax-H3` 和 `MiniMax/MiniMax-H3` 在 ModelScope 上都有镜像（表格链接确认），
+预计能直连下载，不用挂 `network_turbo`。
+
+**用户已选定**：DiT + 文本编码器都用 int8-convrot（~54GB），不用 fp8/bf16 混合方案。
+理由：比 NF4 的 4-bit 精度高一倍，比全 bf16 省一半+盘，100GB 数据盘和 96GB 显存都留有余量。
+
+### 与 2080Ti 版本的关键差异（Blackwell sm_120 vs Turing sm_75）
+
+- **官方示例直接用 bf16**，不是 2080Ti 那套 fp32/fp16 折腾。2080Ti 的 `t2va.py` 里那堆
+  `_force_fp32_linear` / `_patch_dit_residual_fp32` patch 都是 Turing 无 bf16 attention kernel
+  逼出来的补丁，**这张卡上不需要**，直接抄官方示例的 bf16 配置即可。
+- **不需要 CPU offload**：2080Ti 4×22G 靠 `offload_device="cpu"` 来回倒腾权重；这张卡 96GB
+  单卡独占，54GB 权重能常驻显存，理论上更快（具体要不要照抄官方 vram_config 里的 cpu offload
+  字段留到实测时再定，反正显存够大不会是瓶颈）。
+- `t2va.py` 里 `assert prop.major == 7` 这行到这张卡上会直接炸，不能照搬脚本，得照官方
+  int8-convrot 示例重写。
+
+## 相关：`quality-tuning-plan.md` 里没提过量化精度
+
+同目录 [quality-tuning-plan.md](quality-tuning-plan.md) 是 2080Ti 那边的画质排查清单，
+列了分辨率/Turbo步数/CFG/negative prompt 四个方向，**没有把 NF4 量化本身列为嫌疑对象**。
+这次新机器的 int8-convrot 选型算是补了这一项；如果换精度后画质明显变好，说明 2080Ti 那份
+清单该加一条「量化精度」；如果没变化，说明那份清单列的四个方向才是真正的瓶颈，量化本身不是。
+
+## 还没做的事
+
+1. `uv pip install "diffsynth[quant]"` + clone DiffSynth-Studio 源码
+2. 确认 `Comfy-Org/MiniMax-H3` / `MiniMax/MiniMax-H3` 在 ModelScope 直连能下（还没实测，只是表格链接看到有镜像）
+3. 照官方 int8-convrot 示例写这张卡专用的 `t2va.py`（去掉 2080Ti 的 fp32 patch 和 sm_75 assert）
+4. 下载 ~54GB 权重，实测出片，跟 2080Ti 上的验收样本对比画质
+# 评估：把 2080Ti 那套换成 ComfyUI + Raylight，试试能不能把 4×22G 当一个显存池用
+
+**背景**：用户想知道 2K 分辨率能不能跑（`quality-tuning-plan.md` 排查画质差距的同时，也有人在问
+分辨率能不能往上提）。按 `api.py` 现成的 `_rows()` 公式外推：2K×15s 需要的 rows 是现在安全上限
+（`ROWS_LIMIT=20000`）的十几倍，且从已实测数据看显存需求在 rows 越过约 2 万这个区间之后是**加速
+增长**（不是线性）——根因是 Turing 没有高效 attention kernel，PyTorch 静默退化到 MATH 后端，
+把完整的 N×N 注意力矩阵摊在显存里。粗略外推：2K 分辨率下这批卡大概只能撑 1-2 秒，不是能用的档位。
+详细推导见跟用户的对话记录（还没搬进 CHANGELOG，这个文件先占个位）。
+
+**这不是"缺显存"能一次性解决的问题**——4 张卡合计 88G，但现在的架构（DiffSynth-Studio 的
+MiniMax-H3 pipeline）**不支持把一次生成拆到多张卡上算**，四卡只能是四个独立 worker 各跑各的
+（`gateway.py` 做的路由/并发，不是显存池化）。查过 DiffSynth-Studio 最新文档，H3 pipeline 里
+确认零序列并行/张量并行支持，这条路走不通，是架构级的，不是配置项。
+
+## 调研到的方案：Raylight（ComfyUI 插件）
+
+真正做**序列并行**（把一次生成的注意力计算拆到多卡上并行算，不是简单地把不同模块分到不同卡）。
+查到的关键点，都对我们有利：
+
+- **官方支持列表明确写了 Turing 架构**（"Volta and Turing: use latest Yunchang libs"）——
+  不是没测过，是真的适配过老卡这一档。
+- **不需要 NVLink，走 PCIe 就行**——benchmark 里专门提过消费级卡"P2P 走 SYS 路径（无 NVLink），
+  带宽降低但能用"，说的就是我们这种没有 NVLink 桥的机器。
+- **支持列表里明确写了 MiniMax-H3**（USP + FSDP，CFG 暂不支持）。
+- 通信走 NCCL（`nvidia-nccl-cu12==2.28.9`），Ray 管 worker 进程。
+
+对比之下，HuggingFace `diffusers` 库那个"多GPU"文档示例是假的——只是把文本编码器和 DiT
+分别扔到不同卡（组件级放置），不解决 DiT 自己在高分辨率下显存超限的问题，而且这功能现在
+还有 bug（CUDA 设备不匹配没修），官方示例还是照 2×80G A100 写的，跟我们的场景不是一回事，
+排除。
+
+## 代价：这是换引擎，不是装个包
+
+Raylight 是 **ComfyUI 的插件**，不是能塞进现在这套 `api.py`/`gateway.py`/`h3-console` 架构里的
+东西。真要用意味着：
+
+1. 整套换成 ComfyUI 做推理引擎——现在这套 FastAPI 队列+轮询的服务（`api.py`/`gateway.py`/
+   `console`）得重新对接 ComfyUI 的 API，或者两套并存一段时间
+2. 新依赖一整套：PyTorch 2.8.1、NCCL 2.28.9……版本跟现在这个 venv 里为 Turing 精调过的
+   torch/bitsandbytes 组合不是一回事，得单独起环境，不能直接装进现有 venv（会跟 NF4 那条线
+   互相踩版本）
+3. 工作流从现在的"prompt+参数"变成 ComfyUI 的节点图 workflow，console 前端这套三个 tab
+   的表单得重新设计怎么对接
+4. Flash Attention 2 官方标"可选但推荐"——Turing 没有 FA2 支持（这条本项目已经反复实测确认过，
+   见 `README.md`/`turing-bf16-attention-dead` 记忆），Raylight 在 Turing 上到底是用 Yunchang
+   的哪条 fallback 路径、还吃不吃得动 MATH 后端那套，**必须先小规模实测才能确认**，不能假设
+   "支持 Turing"就等于"跟现在一样快甚至更快"。
+
+**这是一个要投入几天的独立迁移项目，不是明天顺手能试完的东西**——跟 `quality-tuning-plan.md`
+里那几项（不用下载任何文件、改几个参数就能测）完全不是一个量级。
+
+## 建议的顺序（不要跳过前面直接冲这个）
+
+1. **先做 `quality-tuning-plan.md` 里的 1、2 两项**（分辨率提到接近原生 1344×768 但控制在
+   `ROWS_LIMIT` 内、Turbo开关对比）——不用下载任何东西，不用改代码，最快出结果。如果画质问题
+   主要是这两项导致的，可能根本不需要 Raylight 这条重路。
+2. 参考 RTX PRO 6000 那边的 int8-convrot 实测结果（见 `h3-rtxpro6000-setup.md`）——如果换更高
+   精度对画质有明显提升，说明量化精度也是真嫌疑，但那条路线（在 96GB 单卡上跑 int8）跟
+   Raylight（多卡序列并行）解决的是两个不同问题（画质 vs 能跑多大分辨率/多长时长），不要混着评估。
+3. 如果 1、2 都做完发现画质本来就没问题，纯粹是想要更高分辨率/更长时长——才轮到评估 Raylight。
+   第一步只做**最小验证**：单独起一个隔离环境（不动现在生产用的 venv），装 ComfyUI + Raylight，
+   用一个小 workflow 跑通 MiniMax-H3 最低配置（比如 448×256×8f）确认链路通，再谈要不要真迁移。
+
+## 还没做的事
+
+1. 明天到公司先确认服务器驱动/CUDA 版本（`nvidia-smi` 看驱动号，`nvcc --version`）——Raylight
+   要 NCCL 2.28.9，跟 RTX PRO 6000 那边 int8-convrot 依赖的 `comfy-kitchen`（要 CUDA Runtime
+   ≥13.0、驱动 ≥r580）**共享同一个风险点**，两条线都得先摸清这台机器的驱动版本能不能满足，
+   不满足要么升驱动（这台机器还跑着 Qwen LLM 生产服务，升驱动有风险）要么放弃这两条路线。
+2. 按上面「建议的顺序」，先把 `quality-tuning-plan.md` 的 1、2 两项测完再决定要不要往下推进。
+3. 如果决定推进：找一台干净的验证环境（不要污染现在的生产 venv），装 ComfyUI + Raylight，
+   跑最小 workflow 验证链路。