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