• 之前撞过好几次 CUDA OOM,事后查 nvidia-smi 才发现是别的工作负载(比如旧 minimax-h3 四卡
    worker)在偷偷抢显存,提交任务前完全看不出来。raylight/server.py 的 /health 新增 gpus 字段
    (直接读 nvidia-smi,不缓存),console 的 /v1/backends 是纯透传所以不用改,前端在原来的
    "后端: ready/排队/运行中"下面加每张卡的显存占用(GB)/百分比/利用率,超过18GB标⚠。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse File »
  • 排队/取消:新增 cancelled 状态区分"排队未跑就被取消"和"运行中被打断";运行中任务现在能点
    "停止"——实测确认 ComfyUI 的 /interrupt 打断不了 Raylight 的 Ray 子进程(打断前后 GPU 一直
    100%利用率),唯一办法是硬重启整个服务,已实测两种场景(初始化阶段/满载采样阶段)都能正确
    收回 GPU。
    
    参考视频/音频:GenReq 加 reference_video_urls/reference_audio_urls,用 ComfyUI 核心节点
    LoadVideo→GetVideoComponents 接参考视频(自动带上视频自己的音轨),LoadAudio 接独立音频。
    console 上传接口按类型分级限流,"多参考图生视频"tab 加对应上传框,task.html 的参考图/视频/
    音频现在都能直接预览播放(不再只显示文件名),不再需要跳出去看。
    
    顺带修复:报错文本截取从头/尾盲截改成直接定位"XxxError: ..."模式,不会再被 traceback 里的
    超长张量 dump 淹没掉真正的报错原因;console 自己的 partition 判断补上新字段,跟 raylight 那份
    保持一致。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse File »

  • 用 Turing 版 SageAttention2 替换 TORCH_MATH 后端,解开了之前反复出现的 832×480×124帧/
    448×256×362帧/1024×576×60帧 OOM;又修复了 asyncio.CancelledError 被 contextlib.suppress
    (Exception) 漏接导致任务卡死在 running 的根因 bug。基于修复后的完成检测,实测出 4 个分辨率
    的真实 CUDA OOM 上限(448×256 是画质上限,非显存上限),写进 server.py 的提交校验和
    console 的分辨率/时长下拉联动,超上限请求直接拒绝而不是排队后才失败。详细过程和数据见
    CHANGELOG.md 和 raylight/notes.md。
    
    Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
    yibo authored
     
    Browse File »