# 新机器：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 那份
清单该加一条「量化精度」；如果没变化，说明那份清单列的四个方向才是真正的瓶颈，量化本身不是。

## 已完成：2026-08-21 00:23 首次冒烟测试成功

脚本：`h3-rtxpro6000/scripts/t2va-rtxpro6000.py`（本地副本，服务器上是
`/root/autodl-tmp/minimax-h3/t2va-rtxpro6000.py`，顶层平铺，不在 `scripts/` 下，
跟 2080Ti 那边 `run.sh` 的路径不一致是同一种情况，见 minimax-h3/README.md 末尾）。

配置：832×480×124f，50 步全量（不开 Turbo LoRA），int8-convrot，seed=0。

| 项目 | 实测 |
|---|---|
| 权重加载 | 83s |
| 生成耗时 | **183s（3.7s/步）** |
| 峰值显存 | **33.9G**（96G 卡里绰绰有余，全程没触发 CPU offload） |
| 视频 | h264 832×480 · 24fps · **124 帧**（无截断） |
| 音频 | aac 32kHz 立体声 · mean **-35.6dB** · max **-17.9dB**（静音应为 -91dB，非静音） |
| 脚本内建有限性/纯色检查 | 通过（无 `[FAIL]`，退出码 0） |
| 产物 | `outputs/t2va_20260821-002322.mp4`，2.5MB，已下载到本地待人工看画质 |

**对比 2080Ti**：fp32 50 步是 107.3s/步（单步耗时不随分辨率/步数变化，见 minimax-h3/README.md
验收记录），这张卡 **3.7s/步，快 ~29×**。差距来源是架构代差（Blackwell 原生 bf16 tensor core +
高效 attention kernel）叠加不用 CPU offload（2080Ti 权重要在 CPU/GPU 间来回倒腾）。

画质是否真的比 NF4 好，需要人眼看这条视频后才能下结论——脚本自带的检查只能排除"全黑/NaN"这类
硬故障，测不出"能不能看"。

### 装环境踩的坑：`diffsynth[quant]` 不够，还要 `[audio]`

第一次冒烟测试连续炸了两次 `ModuleNotFoundError`（先 `torchaudio` 后 `av`）。查
`DiffSynth-Studio/pyproject.toml` 才发现 `av`/`torchaudio`/`torchcodec`/`librosa` 是单独一个
`audio` extras 分组，跟 `quant`（`bitsandbytes`/`comfy-kitchen`/`torchao`）是分开的。
正确装法是两个 extras 一起装：

```bash
uv pip install -e './DiffSynth-Studio[audio,quant]'
```

### 装环境另一个坑：uv 通过 SSH 套 Tcl expect 调用时方括号会被 Tcl 当命令替换

`uv pip install -e "./DiffSynth-Studio[quant]"` 这类命令直接塞进 `expect -c '...'` 的
spawn 字符串会报 `invalid command name "quant"`——Tcl 把 `[quant]` 解析成命令替换语法，
不是 shell 语法层面的问题，转义方括号本身也容易在多层引号里出错。稳定做法是把要跑的命令
写成本地 `.sh` 文件，`scp` 上去再 `ssh ... "bash script.sh"` 执行，彻底绕开这层转义。

### 下载速度踩的坑：ModelScope 单连接慢，多连接不是线性提升但仍值得用

实测对比（见下方，这次调研前测过）：
- ModelScope 单连接：1.5–4 MB/s（不稳定，随时间波动，后段测到过 11MB/s）
- hf-mirror.com：0.5 MB/s（比 ModelScope 还慢）
- HF 官方 + AutoDL 学术加速代理：0.3 MB/s（最慢，文档自己也说"不承诺稳定性"）
- **aria2c 16 连接单文件**：5.1–11 MB/s（比单连接快，但不是线性——测过两个文件各 8 连接
  同时跑，合计吞吐反而比一个文件 16 连接更低，说明限速在 ModelScope 端是整体限速不是
  单连接限速，多开文件并不能叠加带宽）

最终 ~71GB（DiT int8-convrot 32G + 文本编码器 27G + video_vae 9.8G + audio_vae 0.6G）
从 ModelScope 用 aria2c 下完，全程 setsid nohup 脱离 SSH 会话。

### 之前算错的数字（已更正）

上一版这份文档写 DiT int8-convrot 是 20.97GB——那其实是**剪枝版**
（`pruned_int8_convrot`）的大小，非剪枝版实际是 **34.04GB（aria2c 实测 31GiB）**。
实际总下载量是 ~71GB，不是最初估的 54GB。100GB 数据盘依然够用（用了约 75GB）。

## 还没做的事

1. **人工看画质**——本地视频文件：`t2va_rtxpro6000_smoketest.mp4`，跟 2080Ti NF4 的样本对比，
   确认这次换 int8-convrot 是否真的解决了画质问题
2. 如果画质OK：补齐 `h3-rtxpro6000/README.md`（按顶层 `CLAUDE.md` 的目录约定）、
   把这篇文档挪到 `docs/done/`
3. 如果画质仍不理想：回到 `quality-tuning-plan.md` 列的其他方向（分辨率/CFG/negative prompt），
   量化精度就不是瓶颈了
4. 还没测 Turbo LoRA 在 int8-convrot 权重上是否能正常挂载（脚本里 `--turbo` 参数还没跑过）