宜博 / 2080tiserver

排查任务时经常要么去问 sqlite 里存的原始请求参数，要么去查 ComfyUI 自己的 /history
拿实际发给模型的完整 workflow graph——两者详情页都没有，只能手动 SSH 上去查。

- raylight/server.py 加 GET /v1/videos/{jid}/comfy_history，透传 ComfyUI 的
  /history/{prompt_id}（这份数据在 ComfyUI 进程内存里，没有落盘，ComfyUI 重启后
  查不到，接口会给出明确提示而不是裸错误）。
- h3-console/server.py 加对应代理。
- 详情页底部加两个默认折叠的区块：原始参数（req 原样 JSON，纯前端渲染，不用额外
  请求）、ComfyUI History（懒加载，点开才去问后端，避免 queued/running 状态每次
  轮询详情都多打一次 ComfyUI）。
- 顺带把生成结果视频从页面底部挪到状态/操作按钮那一行下面，不用再滚到底部看结果。

已在服务器重启验证：接口对已经清空 history 的任务（ComfyUI 重启后）正确返回明确
错误而不是裸 500；重启期间 14 条排队任务原样保留。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PA1AWh8e7wJ3vyhKBAEQux

/v1/models 之前硬编码3个预设，模型文件名对应的是已删除的 api.py/gateway.py 那套旧
架构（minimax-h3-fl2va-nf4.safetensors 等），跟 raylight 现在实际加载的模型
（minimax_h3_fl2va_pruned_int8_convrot.safetensors 等）完全对不上，档位也只有3个，
跟前端下拉框实际支持的8个分辨率（RESOLUTION_CEILINGS）不一致——外部调这个接口查
"支持哪几档"拿到的是错的过期数据。

raylight/server.py 加 GET /v1/resolutions，返回 RESOLUTION_CEILINGS 的实时内容；
h3-console 的 /v1/models 改成实时调这个接口拼 presets，顺带把 partitions 里的模型
文件名也换成当前实际使用的。

已在服务器上重启验证：/v1/resolutions 返回全部8档，h3-console /v1/models 端到端
拿到一致数据；重启过程中17条排队任务全部保留（用到了上一次改的排队恢复逻辑）。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PA1AWh8e7wJ3vyhKBAEQux

任务 f2de718e1e30（参考视频文件名带中文）秒失败：h3-console 上传时的文件名清洗用了
Python 3 默认的 Unicode \w，中文被当合法字符保留，资源 URL 里带着原始中文传给
urllib.request.urlopen，http.client 构造请求行要求纯 ASCII 直接炸了。改成请求前对
URL 的 path 部分 quote 一遍。

排查时发现 raylight 重启会把所有排队中的任务直接标记 cancelled（内存队列重启即清空，
sqlite 里的 queued 记录没有任何路径被重新入队）。改成 Job 加 queue_seq、Q 换成
PriorityQueue，重启时排队任务原样保留、按序重新入队；顺带加了 POST
/v1/videos/{jid}/prioritize 插队接口和对应的 h3-console 代理 + 前端"优先插队"按钮。

另外把 8月24日提交过、但实际从未部署到服务器的 ComfyUI 存活探测（_comfyui_alive）
重新加回，并解决了 raylight/server.py 和 raylight/scripts/server.py 长期分叉的问题。

已在服务器上验证：重启后 17 条排队任务原样保留、顺序不变；插队接口直接测试和通过
console 代理都验证通过；/health 的 comfy_alive 检查确认生效。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PA1AWh8e7wJ3vyhKBAEQux

MiniMax-H3 竖屏走的还是 width/height 机制，没有单独的 orientation 字段。给4个已实测
横屏档位（1344×768/832×480/448×256/1024×576）各配一个宽高互换的竖屏选项，帧数上限
沿用对应横屏档位的实测值（同总像素数，显存/耗时特征预期一致，但没有专门重跑过竖屏
OOM 边界测试）。前端 RESOLUTIONS 和后端 RESOLUTION_CEILINGS 保持同步。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EhWwz7mLf5PLBn6noJoAcG

服务器意外重启后 raylight/h3-console 全灭才发现之前没有任何开机自启配置，
补上三个 unit（raylight.service 只管开机拉起一次，两个 h3-console 实例走
Restart=on-failure），详见 CHANGELOG。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

重置显存：raylight/server.py 加 /admin/reset-gpu（不挂在具体任务上的通用硬重启入口，应对
actor崩溃不自愈、显存卡在高位但JOBS里没有running任务的情况）。h3-console/server.py 加对应
代理端点 + 一个25秒的"重置中"窗口锁——硬重启期间端口直接连不上，提交新任务只会拿到一个费解
的连接失败，改成明确的409告诉用户还要等多久。前端加"重置显存"按钮，触发后禁用提交按钮、
轮询/health直到真正恢复。停止运行中任务(cancel)同样会触发这个锁。

下线旧接口：排查一次OOM发现GPU1被另一进程占着——另一个并发会话手动拉起了旧的
minimax-h3/gateway.py+api.py四个worker，测试他们改的代码，跟raylight抢卡。按端口停掉，
停了两次都被重新拉起（没有cron/systemd/supervisor在自动重启，是手动执行start-all.sh），
所以把start-all.sh/start-gateway.sh改名成.disabled-20260824，留DISABLED-README.md说明
原因和恢复方法，代码权重都没删。

顺带查到两处过期文档：LLM(llm38)容器实际6天前就已经Exited了，qwen.wudaima.com早就打不通，
不是本次操作停的；"（常驻）whisper GPU3"这条也是过期信息，当时机器上根本没有whisper进程，
实际常驻的是stable-diffusion-webui-forge和一个embedding服务，跟本仓库两条工作线都无关，
已经一并停掉。CLAUDE.md/CHANGELOG都同步更新了。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

之前撞过好几次 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>

排队/取消：新增 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>

用 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>