-
参考图列表/详情缩略图之前直接用原图（1-2MB/张），新增 GET /thumbs/{filename} 惰性生成 320px 长边的 JPEG 缩略图并落盘缓存，实测压缩到原图的0.6%；只重写本机 /assets/ 的展示用URL，job req 里喂给生成模型的原始URL不受影响。 DELETE /v1/videos/{id} 和 batch-delete 顺带改成先真正取消底层任务释放算力， 再移入回收站，避免"删了但其实还在跑"。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KJEL5jqdZR1QPToULRaTAz -
排查用户反馈的"每次刷新46个请求9237KB"：参考图缩略图直接用原图（1.4~1.7MB/张）， StaticFiles 挂载又没设 Cache-Control，每次刷新都要重新下载同一批图。文件名带 uuid、内容写完不再变，可以放心标 immutable，一行子类化搞定重复下载；缩略图本身 还是原图尺寸没缩小，留了 ponytail 注释记这个还没做的部分。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KJEL5jqdZR1QPToULRaTAz
-
已完成任务的视频文件其实早就在本机磁盘，之前无条件代理到raylight（4卡跑满时 HTTP请求要排在GPU计算后面），改成done状态直接本地FileResponse并加长期 Cache-Control，顺手给列表分页加页码按钮和跳转输入框。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KJEL5jqdZR1QPToULRaTAz
-
给要接入 MiniMax-H3 生成能力的其它项目用。覆盖全部接口（提交/查询/ 取消/插队/软删除/批量操作/上传/系统状态），字段表、错误码、真实抓取的 响应样例都是当前线上实测得到的，不是照代码抄的猜测。 重点标注几个容易踩坑但不改代码没法从接口本身看出来的地方： POST /v1/videos 校验失败也返回 202，只能靠 status 字段判断； turbo/cfg_scale/negative_prompt 目前是 no-op； 停止 running 任务=硬重启整个服务，代价是全局15-20秒不可用； 以及本次事故本身：不要绕过 console 直连 raylight(8100)提交任务。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GFw9ZBh3eVjssk6quYQ4Ki
-
清理过载事故留下的重复排队任务时发现，取消/删除都只能按单条 id 调用， 脚本化清理只能一个个来。新增 POST /v1/videos/batch-cancel 和 /batch-delete，body 传 {"ids":[...]} 或 {status,kind,q} 筛选条件二选一； 筛选条件命中数超过 300 直接 400，避免条件写宽了误伤一大片。单条 cancel/ delete 的核心逻辑抽成 _cancel_job/_delete_job 供两边复用，批量场景里 一条失败（比如已经是终态）不影响其它条，成功/失败分别列出来。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GFw9ZBh3eVjssk6quYQ4Ki -
8080(LAN)/8081(公网) 两个进程共用同一份 sqlite，各自的 reconciler_loop 每 5 秒都会对进行中的任务逐条 UPDATE。默认 journal_mode=DELETE 下同一 时刻只允许一个写者、读写还互斥，且没设连接 timeout 时 sqlite3 默认只 等 5 秒——队列一次性堆到 200+（一次 fire-and-forget 并发提交 150 个任务 撞出来的）之后，写请求频繁互相撞车，直接抛 database is locked，连 GET /v1/backends 这种只读查询都被堵到 38 秒才返回。持续了 11+ 小时。 db() 连接加 timeout=30 + PRAGMA journal_mode=WAL，允许多读者+单写者 并发，写者互相排队重试而不是直接报错。部署后 35 秒内 0 次锁错误 （此前几乎每个 reconciler tick 都报错），/v1/backends 恢复到 ~0.3 秒。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GFw9ZBh3eVjssk6quYQ4Ki
-
左侧任务列表宽度 300px→50%，每条任务加缩略图（已完成显示结果视频首帧， 未完成显示输入的首帧图/参考图）；行节点按 job id 复用，避免每 5 秒轮询 重建 DOM 把还没加载完的 <video>/<img> 连根拔掉。 无限滚动改成真分页（默认 20 条/页），/v1/videos 加 offset 参数和 total 字段——列表变慢是因为无限滚动堆积的缩略图媒体请求越滚越多，分页把并发 请求数固定住。 修复 _try_submit（提交任务给 gateway）和 _discover_from_gateway（捞取 绕过 console 直连的任务）之间的竞态：提交请求已发出但 gateway_id 还没 写回数据库的窗口内，discover 会把这个任务误判成孤儿、用 gateway_id 自己 当 console id 再插一行，导致同一个真实任务在列表里出现两条记录（同一个 comfy_prompt_id）。两段操作现在共享同一把锁，不再重叠。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GFw9ZBh3eVjssk6quYQ4Ki
-
任务详情页里的参考视频缩略图之前固定 340×200 + object-fit:cover。横屏视频还行， 竖屏参考视频（比如 480×832）会被裁得只剩中间一条窄带，看不全——参考视频本来就是 要让人核对内容对不对，裁切是硬伤。改成按视频真实宽高比等比缩放（不超过340宽/400高）， 横竖屏都不再裁切。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PA1AWh8e7wJ3vyhKBAEQux
-
2026-08-20 那节早就过期了（写的时候 minimax-h3/gateway.py 还是生产后端，raylight 还没上线）。新增最新状态节：raylight 是现在的生产后端、今天的六项改动（编码bug修复、 排队优先级插队、重启保留队列、ComfyUI健康检查、/v1/models修真实数据、详情页新字段） 都已部署验证并推送，当前各服务实测状态，以及磁盘空间收紧这个待留意项。旧节保留作历史 记录，加了架构已变更的提示。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PA1AWh8e7wJ3vyhKBAEQux
-
排查任务时经常要么去问 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
-
用户要求把新建任务默认参数改成竖屏。text/fl2va/ref2va 三个 tab 统一改，新增 DEFAULT_RES/DEFAULT_DUR 常量，initParamSelects（初次加载）和 clearForm（清空表单） 都改成读这两个常量，不再各自硬编码。480×832 下 10s(243帧) 远低于1125帧上限，安全。 已同步覆盖服务器 /data/models/minimax-h3/console/static/index.html（先确认服务器旧 文件跟本地 git HEAD 完全一致，再推），server.py 按请求读文件不缓存，无需重启， curl 已验证线上生效。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
-
- 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
-
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
-
公网审计发现 qwen.wudaima.com/console 无鉴权可直调（已知问题一直没排上），以及 comfyui.wudaima.com 也在裸奔（raylight 上线后 8188 常驻监听，旧的"隧道空挂"假设 已经过期，没人重新审计过）。两处都已实测确认修复生效：console 的 /v1/* 全部接口 要求 Authorization: Bearer <token>（H3_CONSOLE_AUTH_TOKEN 环境变量），ComfyUI 隧道 用 frp 原生的 http_user/http_pwd 加了基本认证。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SURs92UuTkFxDF4RXsEFJi
-
之前塞在 #job-list 第一行，列表一滚就跟着跑没了；挪到 #sidebar-filters 外面单独一行，选中态（新建视图时高亮）用 renderSidebar() 里同步 class 的方式保留，回收站视图沿用原来的隐藏逻辑。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JDWoVwpqrsyzv9LRszTw9d
-
/v1/videos 一直硬编码 limit=50，服务器上实际232条未删除任务，超出的 根本没请求回来——不是滚动条的问题。改成滚到底部自动翻页加载；同时给 /v1/videos 加 q/status/kind/sort 参数（向后兼容），左侧栏加对应的 搜索框/状态筛选/类型筛选/排序切换。已部署到服务器并用真实数据验证过。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JDWoVwpqrsyzv9LRszTw9d
-
服务器意外重启后 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>