h3-rtxpro6000-setup.md 10.7 KB

Edit Raw Blame History


新机器：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 快几十倍，包解析方式不同）：
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）：
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 是 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 一起装：
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）。
还没做的事

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