-
服务器意外重启后 raylight/h3-console 全灭才发现之前没有任何开机自启配置， 补上三个 unit（raylight.service 只管开机拉起一次，两个 h3-console 实例走 Restart=on-failure），详见 CHANGELOG。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
任务详情页(viewThumb)和上传表单缩略图(wrapWithDelete)都是同一个模式：caption跟media 的DOM顺序对调即可，.thumb-wrap是flex-direction:column，顺序决定视觉位置，不用改CSS。 顺带排查了用户反馈的另一个问题"点击图片变下载"——查了一个具体任务(1cc42a8669a1)的参考图 实际引用的是外部图床(shadiao-2d.oss-cn-aliyuncs.com)，那边响应头自己带了 Content-Disposition:attachment，是外部服务器强制的，不是咱们代码的bug；对比测试过咱们 自己/v1/assets上传的图片没有这个问题。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
批次中途被watchdog误杀重启打断的5个案例重新提交后也都跑完了，26个可提交案例 （5个结构性不支持的除外）现在全部done。剩下的是人工过一遍视频补观感评价。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
watchdog.sh按step字段判断denoise是否卡死，但没考虑到step到达total_steps(采样跑完)后 还有VAE解码+存盘这段没有独立进度信号的尾巴，step会停在最终值不变。这段被并入denoise 阶段的10分钟宽限，实测至少一个1344×768长帧数案例这个阶段本身就超过608秒，被误判卡死、 自动整机重启，打断了h3-showcase批量重跑中5个正在跑/排队的任务。修复：给这个阶段单独 一档30分钟宽限(STALL_LIMIT_POSTPROC)。已部署重启watchdog，被打断的5个任务已重新提交 (新任务ID同步进h3-showcase-cases.md)。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
之前"22已提交"从没回头核实过真实结果——查console.sqlite3发现26个已提交案例里只有10个 真的跑完(done)，其余16个(15 cancelled+1 failed)被期间的服务重启从队列里取消了，状态 停留在没人发现的地方。用存量req_json逐个重新POST /v1/videos入队（新任务ID见表格）， 没有重跑那10个已完成的。顺带发现"不支持"统计漏了1.8#2，实际是5个不是4个。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
/health 之前只读 STATE["model"]（worker()线程启动时设一次"ready"，之后再不更新）， 一次OOM把ComfyUI(8188)进程本身搞崩溃退出后，server.py这层壳没死，/health继续骗人报 ready近20分钟，期间提交的任务全部秒失败(ConnectError)才被人工发现。改成每次/health都 真的探测一次8188(GET /system_stats，2秒超时，跟start.sh自己的就绪检测用同一个端点)。 不解决actor崩溃不自愈本身（上游代码问题），只是让崩溃能被更快发现。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
跟刚才那次代码删除操作对齐文档：workload表、「MiniMax-H3脚本」一节都还在按"代码还在， 只是改名.disabled"描述，但今天已经整个删掉了（改名禁用被绕过重新手动启动过一次）。 顺带把raylight那行"124帧会OOM"的过期结论也更新掉——这是2026-08-22切SAGE_FP16前的 旧数据，一直没同步到这张表，容易误导。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
生产已全面切到 raylight（2026-08-22起），minimax-h3 的路由代码(gateway.py/api.py等) 今天已经从服务器上删除（保留console/models/venv/outputs/logs）。本地这份是同样的代码， 删前打包备份到 ~/Documents/lemonAI/2080tiserver-backups/ minimax-h3-local-repo-backup-20260824.zip，另外服务器上实际删除的文件也单独打包 下载在同目录 minimax-h3-code-backup-20260824.tar.gz（包含console/models/venv/outputs/ logs之外的全部内容，比本地这份更全，含DISABLED-README.md等本地没有的文件）。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
排查用户重跑的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>
-
之前上传后只显示 uuid 文件名，传多个参考图/视频时分不清哪个是哪个。server.py 把原始 文件名塞进存盘文件名（<aid>__<原名>.ext），前端从 URL 反解出来显示在缩略图下方，旧任务 （改动前上传的，URL里没有__分段）会退化成显示uuid，不算错误只是没有原名可用。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
pipeline 本身支持 cfg_scale/negative_prompt，之前一直裸跑默认值没传。同时补上 2026-08-21 分辨率/Turbo 对比的实测结论：原生1344×768肉眼优于832×480，但ref2va场景下 Turbo开/4步反而比关Turbo跑20步更好（跟纯T2V的旧结论相反，说明这条要按分区分别测）。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
停 minimax-h3 后反复自己重新起来，一开始误以为是有同事在用（这个归因是错的，已在文档里更正—— 用户确认当时只有一个人在用这台机器）。排查 cron/systemd/tmux/screen/supervisor 均未发现自动 重启机制，最后查到系统级 PM2（Node.js进程管理器，跑了75小时，管着这台机器本来就有的其他 基础设施）在托管 stable-diffusion-webui-forge 和一个 embedding 服务，子进程被kill会自动重启—— 已 pm2 delete + pm2 save 彻底清除。minimax-h3(gateway.py/api.py)本身不在PM2管辖范围内，真正 触发源没查到，改用把api.py/gateway.py本体也改名成.disabled-20260824的办法从根上堵死（不管 触发源是什么，python -m uvicorn api:app 的 import 直接失败）。验证45秒零重启尝试，raylight/ console全程未受影响，四卡GPU稳定在160-162MB纯基线。 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>
-
之前上传选错/传多了只能清空整个表单重来。每个预览缩略图右上角加一个×删除按钮，点击从 已选列表移除；首尾帧删除时顺带清空对应file input的值，不然重选同一个文件浏览器不会触发 change事件。setThumbs统一改成从uploaded状态重新渲染的renderRefThumbs/renderFl2vaThumbs/ renderTags，删除后重渲染逻辑一致。 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>
-
整理飞书 H3 使用手册的 26 个官方示范案例（docs/todo/h3-showcase-cases.md，含提交状态追踪）， 补充提示词方法论（raylight/h3-prompt-guide.md，含电影摄影术语表、diegetic/non-diegetic 声音分层框架）、跨模型调研（raylight/deep-research-cinematic-prompt.md）和提示词质量打分 benchmark（raylight/h3-prompt-benchmark.md），CHANGELOG 记录本轮踩的坑（自评分数虚高、 避雷词换句式复发、提示词时长要跟实际frames对齐）。配套的 h3-prompt-writer skill 在 .claude/skills/ 下，按项目约定被 gitignore，不随此提交进库。 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>
-
新建 remote-access-from-home.md 记录能用（HTTP 隧道 qwen.wudaima.com）/不能用（SSH 公网隧道 22→6000，TCP 通但 SSH 握手被断）两条路径；docs/todo/ssh-public-tunnel-broken.md 跟踪修复；CHANGELOG/CLAUDE.md 同步记一笔。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
CFG scale/negative prompt 参数入口（api.py + console 前端「高级参数」）、 参考素材点击插入 <Picture N>/<Video N> 标记、RTX PRO 6000 int8-convrot 冒烟测试成功的记录（h3-rtxpro6000/ 新目录）。这些改动之前只存在于服务器 磁盘和本地磁盘，没进 git，这次是同步不是新增功能。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
查 DiffSynth-Studio pipeline 源码确认：references 非空时 keyframes 被 静默忽略，不报错。api.py 没有校验，今天的真实任务因为 prompt 里写 @图片N 但没真的挂 reference_image_urls，误以为身份参考图生效了。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
补齐 h3-rtxpro6000-setup.md（另一线程的调研，之前只在磁盘上没提交）。 新增 raylight-comfyui-multi-gpu-eval.md：2K 分辨率外推显示 2080Ti 显存 需求随 rows 超线性增长，DiffSynth-Studio 现有架构不支持多卡拆分单次生成； 调研到 Raylight（ComfyUI 插件）支持 Turing+PCIe+MiniMax-H3 的序列并行， 但要换整套推理引擎，是独立迁移项目。建议先做 quality-tuning-plan.md 里不用下载东西的两项，排除画质问题不是量化精度导致的，再决定要不要推进。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
本地开发（脱离办公网络，只能走公网反代），未在真实 GPU 上验证，详见 docs/todo/verify-video-reference-on-gpu.md。 - minimax-h3/api.py: GenReq 加 reference_video_urls，_references() 打通到 pipeline 已支持的 video/video_audio 参考类型 - h3-console/server.py: /v1/assets 加视频上传支持（mp4/mov/webm，200MB） - h3-console/static/index.html: 参考视频多选上传 + URL 直填 + 预览， 重跑/任务详情页同步支持 新增 docs/todo 与 docs/done：把「明天要验证」和「画质改进方案」落成文档， docs/README.md 做索引，不重复 CHANGELOG 已有的细节。
-
/v1/videos/{jid}/file 两条返回路径都没设文件名，浏览器只能从 URL 猜， URL 以 /file 结尾没扩展名，猜出来都是 file.mp4，多个任务的视频存到同一个 下载目录会互相覆盖。加上 filename="h3-{任务id}.mp4"，id 天然唯一。 -
_try_submit 在 gateway_id 还是 NULL 的窗口里可能被 create_video/get_video/ reconciler_loop 并发调用，导致同一个任务被提交给 gateway 两次，两张卡各烧 一遍 GPU、其中一条变成没人追踪的孤儿任务。加进程内 _SUBMITTING 集合堵住这 个竞态窗口。 任务详情页只显示帧数不显示秒数，加一行按 24fps 折算的"时长"。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
HANDOFF.md 加了 2026-08-20 夜的最新状态一节（前置，不覆盖历史）：记录当前各服务 实际运行状态、今天做的十项改动摘要、以及一个重要发现——qwen.wudaima.com 现在 实际上是 minimax-h3 的 gateway.py 在占用（llm38 容器当前未运行），不是 Qwen LLM。 代码改动（此前几轮已分别验证部署，这次一并入库）： - h3-console/server.py、static/index.html：H3_CONSOLE_BASE_PATH 子路径支持， 用于挂到 qwen.wudaima.com/console - h3-console/README.md：同步子路径部署说明、gateway.wudaima.com 排查结论 - minimax-h3/api.py：ROWS_LIMIT 支持环境变量覆盖（边界探测用） - CLAUDE.md：当前负载表格更新 h3-console 的双实例/公网访问方式
-
API.md 加「任务记录会落盘」一节，讲清 jobs_gpu{N}.sqlite3 是什么、 in-flight 状态为什么没法恢复、只影响直连 api.py/gateway.py 的场景。 h3-console/README.md 补上用户反馈"播放/下载好像有问题"后排查出的三个坑 （download/poll 字段抄错 id、5 秒轮询冲掉播放中的 video、下载接口不支持 Range），以及回滚一节更新——这次的持久化改动碰了 api.py 本身，不再是 "kill console 就完事"。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -
worker()/create() 每次状态变化都写一份到 sqlite（四张卡各一个独立文件）， 进程启动时读回内存；in-flight 的 queued/running 记录重启后没法恢复，改判为 failed 并写清原因，不再卡成一条永远"运行中"但没人会再碰的死记录。 落地前用不依赖 torch/GPU 的独立单测验证了 done 保留/running→failed 改判/ upsert 覆盖不重复，再按"只重启空闲的那张卡"逐张滚动重启四个后端上线， 用真实任务验证过重启后 api.py 自己（不经过 console 那层兜底）能找回完整记录。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
任务行右侧「⋯」菜单可删除，左下角回收站入口可查看/恢复已删除任务。 server.py：jobs 表加 deleted_at 列，DELETE /v1/videos/{id} 软删除、 POST .../restore 恢复，GET /v1/videos?trash=true 切换视图。 不影响弹性调度器的 pending 计数（删除只隐藏，不取消底层任务）。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> -
- 从服务器同步 gateway.py、gateway-run.sh 等此前本地缺失的核心/调试脚本，修正与 服务器的漂移（此前 push 的本地副本一直缺 gateway.py 这个核心文件） - h3-console/server.py：_refresh_from_gateway 遇到 404 且任务未到终态时判 failed， 不再让后端进程重启丢失的任务永远显示"运行中" - h3-console/DESIGN.md、CHANGELOG.md 同步记录 fl2va/ref2va 默认基线改 2/2 分裂、 frames 上限改按 rows 动态判定的相关变更
-
包含 llama.cpp 部署脚本、MiniMax-H3 探查/运行脚本、h3-console Web 管理台源码， 以及运维文档（CLAUDE.md/HANDOFF.md/llm-setup.md/CHANGELOG.md）。 排除生成的图片/视频/音频产物、.venv、__pycache__ 等运行时/构建产物。