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