宜博 / 2080tiserver

  • 文档同步：删除 gateway.wudaima.com 隐患隧道记录 + FastH3 调研结论 ...
    13984e32 
    - CHANGELOG/h3-console/README/llm-setup：frpc.qwen.ini 里 [qwen-gw-20260610]
  （gateway.wudaima.com → 8080）2026-08-29 已删除，服务器上备份为
  frpc.qwen.ini.bak-20260829，三处文档同步更新，去掉过期的"走不通"描述。
- raylight/notes.md：调研 FastVideo/FastH3（H3 的4步蒸馏版），结论暂不可行——
  没有量化权重导致 bf16 在 Turing 上跑不动 attention、VSA 加速官方只支持
  Blackwell、且不是 ComfyUI-native。另外实测算了 RTF，现有 base H3 在这台
  机器上离"N秒视频<N秒生成"差1-2个数量级，FastH3 全量落地乐观推算也摸不到
  实时线，不建议投入。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EhWwz7mLf5PLBn6noJoAcG
    yibo authored
     
    Browse File »
  • raylight: 记录"1344×768撑412帧不OOM"结论只对0参考图成立 ...
    ccf5db19 
    排查用户重跑的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 authored
     
    Browse File »
  • Raylight 扶正为生产默认后端：SAGE_FP16 修复 OOM、修完成检测 bug、实测上限写进代码强制生效 ...
    8cf2545d 
    用 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 »