# 评估：把 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 验证链路。