From ccf5db19a73328e1391a3b2a20e429bb97fcebfd Mon Sep 17 00:00:00 2001 From: yibo Date: Mon, 24 Aug 2026 20:05:59 +0800 Subject: [PATCH] raylight: 记录"1344×768撑412帧不OOM"结论只对0参考图成立 --- CHANGELOG.md | 19 +++++++++++++++++++ raylight/README.md | 7 +++++++ raylight/notes.md | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 73 insertions(+), 0 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 5f8146f..4b42eb2 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,24 @@ # 变更记录 +## 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 自动重启 + 找到彻底止血办法 **更正上面那条记录里"另一个并发会话手动启动/又手动拉起来"的归因是错的**——用户明确说这台机器 diff --git a/raylight/README.md b/raylight/README.md index 6974f33..9ce2938 100644 --- a/raylight/README.md +++ b/raylight/README.md @@ -64,6 +64,13 @@ ssh admin@192.168.110.67 'cd /data/models/minimax-h3 && export H3_OFFLOAD=disk & | 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`字段。 diff --git a/raylight/notes.md b/raylight/notes.md index 16985d8..0657a92 100644 --- a/raylight/notes.md +++ b/raylight/notes.md @@ -1,5 +1,52 @@ # 踩坑记录 / 被推翻的假设 +## 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 -- libgit2 0.21.4