raylight: 记录"1344×768撑412帧不OOM"结论只对0参考图成立

排查用户重跑的ref2va任务(1344×768×362帧×3参考图)时发现同一配置当天5次提交4次失败，查到已有的分辨率/帧数安全上限sweep表全部是0参考图(partition:text)测出来的，从没验证过带参考图时是否成立。这次任务的真实失败根因是FSDP初始化阶段GPU2/GPU3 OOM（不是一直以来 "GPU0先炸"的老结论），证实带参考图的conditioning张量广播到每个FSDP rank后显存开销明显更高。写进 raylight/README.md 已知限制第1条、raylight/notes.md、CHANGELOG.md。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

raylight: 记录"1344×768撑412帧不OOM"结论只对0参考图成立
排查用户重跑的ref2va任务(1344×768×362帧×3参考图)时发现同一配置当天5次提交4次失败，查到已有的分辨率/帧数安全上限sweep表全部是0参考图(partition:text)测出来的，从没验证过带参考图时是否成立。这次任务的真实失败根因是FSDP初始化阶段GPU2/GPU3 OOM（不是一直以来 "GPU0先炸"的老结论），证实带参考图的conditioning张量广播到每个FSDP rank后显存开销明显更高。写进 raylight/README.md 已知限制第1条、raylight/notes.md、CHANGELOG.md。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
yibo
1 parent 47cf8fbd
Showing 3 changed files with 73 additions and 0 deletions
CHANGELOG.md
raylight/README.md
raylight/notes.md
 # 变更记录
  
+## 2026-08-24（晚，续2）— 【发现】"1344×768撑412帧不OOM"结论只对0参考图成立，带参考图会OOM
+
+**背景**：用户重启了一个卡住/报错的任务（`task.html/b659b60c6cbc`，1344×768×362帧、ref2va
+3张参考图），让盯着看会不会再报错。查`console.sqlite3`任务历史发现同一个精确配置当天5次
+提交4次失败（1次成功是`d71c09a38248`），远不是稳定档位。
+
+**结果**：确认根因是显存不够，但不是老结论"GPU0先炸"那种模式——这次是FSDP/USP初始化阶段
+`rank2`/`rank3`（物理GPU2/GPU3）先报`CUDACachingAllocator`OOM（只剩8-10MB free时还要申请
+20MB），Ray actor被SIGTERM杀死，任务标记`failed`。`raylight/README.md`已知限制第1条那份
+"1344×768能撑412帧"的sweep表，提交时用的是`partition: text`（0张参考图）——**从没验证过
+带参考图时是否成立，这次实测证明不成立**：参考图的conditioning张量会广播到每张FSDP rank，
+显存开销明显更高，且压力点可能落在GPU0以外的卡。已把这条补充记录写进`raylight/README.md`
+已知限制第1条和`raylight/notes.md`。
+
+**被推翻的假设**：不能把"文生视频（0参考图）测出的分辨率/帧数安全上限"直接套用到带参考图
+的ref2va/fl2va请求上，两者显存开销结构不一样。目前没有专门针对参考图数量×帧数做过sweep，
+这是文档空白，以后要单独测。**当前建议**：1344×768 + 3张参考图时，362帧不安全，想稳定跑
+建议降到200-250帧或减少参考图数量。
+
 ## 2026-08-24（晚，续）— 更正：不是"另一个并发会话"，真凶是 PM2 自动重启 + 找到彻底止血办法
  
 **更正上面那条记录里"另一个并发会话手动启动/又手动拉起来"的归因是错的**——用户明确说这台机器
@@ -64,6 +64,13 @@ ssh admin@192.168.110.67 &#39;cd /data/models/minimax-h3 &amp;&amp; export H3_OFFLOAD=disk &amp;
    | 1024×576 | 743帧（约62分钟） | 787帧真实CUDA OOM |
    | 1344×768（官方默认分辨率） | 412帧（约55分钟） | 431帧真实CUDA OOM |
  
+   ⚠️ **【2026-08-24补充，重要】上面这张表全部是0张参考图（`partition: text`）测出来的，
+   带参考图（ref2va/fl2va）不能直接套用**——参考图的conditioning张量会广播到每个FSDP
+   rank，显存开销明显更高。实测"1344×768×362帧×3参考图"这个精确配置当天5次尝试4次失败
+   （1次OOM在GPU0，1次OOM在FSDP初始化阶段的GPU2/GPU3，不再是"只有GPU0会先炸"），完整
+   证据见`notes.md`「2026-08-24（晚）」一节。**带参考图时别直接信这张表的帧数上限**，
+   目前没有专门测过参考图数量×帧数的边界，这是个空白。
+
    所有真实OOM都是GPU0先炸（跟之前"GPU0同时扛文本编码器+DiT分片"的结论一致），且都在提交后
    30秒内报错（采样刚开始分配显存就失败，不会跑到一半才炸）。每个`done`结果都额外SSH核实过
    视频文件真实存在、大小合理，不是只信API的`status`字段。
 # 踩坑记录 / 被推翻的假设
  
+## 2026-08-24（晚）— 【被推翻】"1344×768 撑到412帧不OOM"这份结论不适用于带参考图的请求
+
+### 背景
+
+`README.md`已知限制第1条、本文件下方"2026-08-23（凌晨）"那份sweep表里"1344×768 412帧done/
+431帧OOM"的结论，提交时用的是`partition: text`（纯文生视频，**0张参考图**，跟
+`task.html/29a99dc412b2`同款prompt，`reference_image_urls`为空）。这份表被当成"1344×768
+撑到412帧都安全"的通用结论在用，但**从没验证过带参考图（ref2va）时是否成立**。
+
+### 实测：同一个"1344×768×362帧×3参考图"配置，今天5次尝试4次失败
+
+查`console.sqlite3`的`jobs`表按时间排：
+
+| job id | 提交时间 | 结果 | 报错 |
+|---|---|---|---|
+| `d71c09a38248` | 16:12 | **成功** | — |
+| `c53f8d3ad7e2` | 18:57 | **OOM** | `CUDA out of memory`，GPU0 21.48GB只剩几MB free |
+| `1a764bc79895` | 19:17 | **OOM** | `Tried to allocate 148.00 MiB. GPU 0 ... 14.25 MiB is free` |
+| `642b82111d28` | 19:24 | **失败** | `ncclUnhandledCudaError`（这次是重启服务时把它硬杀掉导致的次生错误，不算独立样本） |
+| `b659b60c6cbc` | 19:38（服务`bash start.sh`重启后，干净状态重新提交） | **失败** | 见下，FSDP初始化阶段OOM，非GPU0 |
+
+同一个精确配置，5次里1次成功4次失败（其中3次是独立的、非连锁的失败）——不是稳定档位，是在
+显存边界反复横跳，成功靠运气。
+
+### `b659b60c6cbc`失败的完整根因（从`comfyui-server.log`拿到真实traceback，不是靠DB里
+### 被截断的错误字段——那个字段这次存的是一坨裸tensor dump，看不出真实原因）
+
+失败发生在**FSDP/USP初始化阶段**（"Model Initializing"进度条，不是采样阶段），而且这次是
+**rank2/rank3（物理GPU2/GPU3）先炸，不是一直以来"GPU0最先顶到天花板"的老结论**：
+
+```
+[rank2]:[W824 19:41:48...] CUDACachingAllocator.cpp:508] expandable_segments: memory mapping
+failed with OOM on device 0 while trying to map 20971520 bytes (free: 10813440, total: 23068868608).
+[rank3]:[W824 19:41:48...] 同上，free: 8716288
+```
+
+只想再扩20MB显存池，但两张卡分别只剩~10MB/~8.7MB free。卡在初始化15%两分多钟后，
+`RayWorker:2`被SIGTERM杀掉退出，Ray判定actor已死（`ActorDiedError`），任务整体标记`failed`。
+
+### 结论
+
+带参考图（ref2va/fl2va）时，参考图的conditioning张量会广播/复制到每个FSDP rank，显存开销
+比纯文生视频高一截，且压力点可能落在GPU0以外的卡（这次是GPU2/GPU3）。**"1344×768能撑412帧"
+这条结论只对0参考图成立，不能套用到带参考图的请求上**——目前没有专门针对ref2va做过参考图
+数量×帧数的sweep，这是个空白，以后要单独测。**当前建议**：1344×768 + 3张参考图时，362帧
+不是安全档位，想稳定跑建议降帧数（如200-250帧）或减参考图数量。
+
 ## 2026-08-22/23：切换到 SAGE_FP16，彻底解开旧的OOM边界；三个新bug（两个查清一个修复）
  
 ### 根因：不是显存不够，是环境里从来没装过Turing版SageAttention