HANDOFF.md 8.13 KB

Edit Raw Blame History


交接文档 · 2026-08-18

给下次进来的人（或进程）。先读这份，再读 CLAUDE.md。
权威细节在 llm-setup.md（整机）和 minimax-h3/README.md（视频线），
时间线在 CHANGELOG.md。这里只写「现在是什么状态、下一步该干什么」。

一句话
今天做了两件事：llm38 单请求上下文 32K → 256K（已完成、已验收、已恢复），
MiniMax-H3 文生视频从零部署到出片 + 封了 HTTP API（已出片、已验收，服务当前在跑，环境未恢复）。
2026-08-19 16:30 更新：断连 13 小时后重连

50 步全质量已完成并验收（6.4 MB · 5364 s · 107.3 s/步 · 峰值 9.1 G · 帧间差异 7.366 · 音频 −27.2 dB）。
两档都出片，详见 minimax-h3/README.md 验收记录。
断连原因是本地网络：Mac 到 192.168.110.x 的路由被 VPN 隧道（utun7 / 198.18.0.1）劫持。
期间 nc -z 对所有端口都返回成功（连 9999 和只听 127.0.0.1 的 7860 也"通"）——
那是假阳性，别据此判断服务状态。用 ping + route -n get 确认路径。
期间另有进程在这台机器上工作：两个 H3 API 实例常驻（8010 → GPU1 13.0 G / 8011 → GPU2 7.7 G，
两者 /health 均 ok），api.py 被改过（新增 PARTITION 字段），新增 restart-8010.sh，
outputs/ 里有 6 个非本次生成的视频。

★ 当前是用户指定的目标状态：只留 H3 ★
2026-08-19 16:40 用户明确：「停止 llm38」「只留着 h3 即可」。
所以下面这四个停着是对的，不要"顺手"起回来：


服务
状态
说明


llm38（8000）
停
配置已是 256K 单请求上下文并验收过，需要时 docker start llm38


whisper（8002）
停
docker start whisper


PM2 m3e（7590）
停
/usr/local/node/bin/pm2 start m3e


PM2 sd-forge（7860）
停
/usr/local/node/bin/pm2 start sd-forge


H3 API 8010 / 8011
运行中
唯一保留的负载，占 GPU1+GPU2 共 20.8 G


GPU0 与 GPU3 全空（各 22002 MiB）。恢复命令详见 deploy-scripts/RESTORE-GPU.md。


⚠️ 要恢复 llm38 时注意：它跑 256K 需四卡各约 14.3 G，而 GPU1 现被 8010 占着只剩 8.95 G。
要共存就用 --parallel 1 --ctx-size 262144（单请求仍 256K，并发降为 1，省 16 G），
或先停一个 H3 实例。

⚠️ 立刻要知道的三件事

四个服务当前是停的，而这是用户要的状态（见上一节），不是未完成的收尾。
需要时按 deploy-scripts/RESTORE-GPU.md 恢复，恢复后验 7590 / 7860 / 8000 / 8002 四个端口。
m3e 和 sd-forge 由 PM2 托管（God Daemon PID 1467）。kill 它们没用，
60 秒内会被拉回来；必须 /usr/local/node/bin/pm2 stop m3e sd-forge。恢复是 pm2 start。
pm2 不在默认 PATH 里，非交互 shell 下写全路径。
一条 50 步全质量视频还在跑（GPU2，22:22 启动，约 90 分钟，预计 23:50 左右完），
H3 的 API 服务也在跑（GPU1，端口 8010）。恢复环境前先确认这两个结束/停掉。

状态速查


东西
状态
位置


llm38（Qwen3.8-27B）
已停。配置已改成 256K 单请求上下文，验收过
deploy-scripts/ctx256k.sh


llm38 旧容器 llm38_prev
保留着（32K 配置），确认稳定后可 docker rm
/ 只剩 29 G，别忘


whisper / m3e / sd-forge
已停
deploy-scripts/RESTORE-GPU.md


MiniMax-H3 权重 34 GB
下载完 + 字节级校验 ALL GOOD
/data/models/minimax-h3/models/


H3 出片
成功，已验收（见下）
outputs/t2va_20260818-223136.mp4


H3 API
在跑，GPU1:8010
minimax-h3/API.md


50 步全质量
进行中，结果未验
logs/real-full50.log


今天最重要的一条结论
minimax-h3/README.md 原第一节写「bfloat16 → float16（致命）」是错的。
改成 fp16 才是这条线一直出不了片的原因。

对照实验（唯一变量是 dtype，448×256×28f）：


fp32
fp16


视频
mean 140.9 std 50.6
mean 0 std 0


音频
finite
NaN


结果
出片 ✅
纯黑 ❌


原因：模型按 bf16 训练（bf16 有 fp32 的动态范围），sm_75 没有 bf16，
fp16 的 65504 上限装不下——dit.blocks.0 输入 absmax 89 就放大到 38176，50 层残差累积必爆。

逐点修 fp16 是行不通的，我试了四条弯路全部失败（--fp32-accum 无效、替换 forward 绕过换入、
转换处溢出、钳位到上限反而自造故障），细节和实测数据都在 minimax-h3/README.md。
t2va.py 的 --dtype 现在默认 fp32，保留 fp16 只为复现故障。
验收数据（都是实测，没有推测）
H3 出片：832×480 · 24fps · 124 帧 · 5.17 s · 7.5 MB ·
像素 std 57.85 · 帧间差异 16.99（证明是动态视频） ·
音频 aac 32 kHz 立体声 mean −34.0 dB / rms 0.0199（证明不是静音）。

性能（fp32，单任务）：全分辨率 Turbo 4 步约 107 s/步，峰值显存 12.2 G，
首次加载 238 s，page cache 命中后 12–20 s。fp16 是 36.8 s/步但出不了片。

llm38 256K：n_ctx_slot = 262144（模型原生上限，GGUF 元数据 qwen35.context_length），
150 K token 大海捞针 truncated=0 通过，显存 57.3 G，并发从 4 降到 2，
256 K 提示 prefill 约 4.5 分钟。
下一步（按优先级）

收尾：等 50 步跑完 → 验收（bash /tmp/verify-out.sh <文件>，脚本在服务器 /tmp，
要长期用得挪到 scripts/）→ 补 README.md 验收记录 → 恢复四个服务并验端口。
决定 llm38 与 H3 的共存策略。两者显存放不下（57.3 + 12.3 > 单卡余量）。
选项：H3 按需起停；或 llm38 降到 --parallel 1 --ctx-size 262144（保 256 K 单请求，
并发降为 1，省 16 G）；或换卡。这是产品决策，需要用户拍板。
安全：qwen.wudaima.com 公网无鉴权可直调 27B；H3 API 也无鉴权。
SSH 22 经 FRP 映射到公网 6000 且允许密码登录、admin 在 sudo 组。都没动，等授权。
可选：t2va.py:47 的 max(6.0, ...) 地板值在空闲显存 

踩过的坑（别重踩）

退出码不可信：原 t2va.py 只查 audio，全黑视频照样 [done] + 退出码 0。
已补 video 纯色检查，坏产物退出码 3。API 的 worker 也会验 std 和音频有限性。
诊断配置必须和故障配置逐项一致：我用中文 prompt 诊断、英文默认 prompt 复现，
溢出点不同，白跑几轮。
prompt 必须从文件读：ssh … bash -c "…" 三层 shell 会吃掉引号，传进去是空串，
报错是 cannot reshape tensor of 0 elements——看着像 transformers 的 bug，实际是输入为空。
cmd1 && cmd2 & 的 & 作用于整条链：cat > file && ... & 会让文件写入和执行竞争，
我因此跑了一个 0 字节的脚本还以为它成功了。上传和启动要分两步。
pgrep -f "gunicorn.*7590" 会匹配到你自己那条 SSH 命令行，照着 kill 会误杀。
用 nvidia-smi --query-compute-apps=pid 反查。
ffmpeg -af volumedetect 的输出容易被 grep 漏掉，误报"无音频流"。
用 PyAV 直接解码算 rms 更可靠。
合成小张量的 probe 测不出真问题：probe-nf4-fp16.py 验证「单层 NF4 fp16 不溢出」通过，
但推不出「50 层残差不溢出」。

本地与服务器的对应


本地
服务器


deploy-scripts/
/home/admin/qwen38-deploy/


llm-setup.md
/home/admin/llm-setup.md


minimax-h3/scripts/、API.md、README.md
/data/models/minimax-h3/（run.sh/api.py/realrun.sh 在顶层）


服务器那份才是运行的那份，两边会漂移。今天就因为只在服务器上修了导入、
本地那份没同步，重新生成脚本时把旧 bug 带了回去，白跑一轮。