From 13984e324f709bce988e7aaea735b383f61223d0 Mon Sep 17 00:00:00 2001 From: yibo Date: Tue, 1 Sep 2026 17:03:46 +0800 Subject: [PATCH] 文档同步：删除 gateway.wudaima.com 隐患隧道记录 + FastH3 调研结论 --- CHANGELOG.md | 16 ++++++++++++++++ h3-console/README.md | 15 ++++++++++++++- llm-setup.md | 5 +++-- raylight/notes.md | 87 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 120 insertions(+), 3 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 1a2c8b5..9566ae1 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,21 @@ # 变更记录 +## 2026-08-29（续）— 删掉 gateway.wudaima.com 的 frp 隧道客户端配置 + +上一节修完 console/ComfyUI 鉴权后审计时留了个尾巴：`frpc.qwen.ini` 里的 +`[qwen-gw-20260610]`（`gateway.wudaima.com` → 本机 8080，即 h3-console **局域网**实例， +开着弹性调度器）一直没删，只是因为 frp 服务端 `60.205.214.169` 没配对应 vhost 才没打到我们， +这是"目前观测到的状态"不是"保证"——服务端配置不归这台机器管，谁都能在我们不知情的时候补上。 +直接删了这条客户端配置，不再赌它一直保持"走不通"： +- 服务器 `/home/admin/llm/frp/frpc.qwen.ini` 删前备份成 `.bak-20260829`，只删了 + `[qwen-gw-20260610]` 那一段，`[qwen-llm]`/`[qwen-console-subpath]` 不动。 +- `pm2 restart frpc-qwen-client` 生效，日志确认只剩 `[qwen-llm qwen-console-subpath]` + 两个 proxy 注册成功。 +- 公网实测：`qwen.wudaima.com`（根路径，llm38停着，404）、`qwen.wudaima.com/console` + （h3-console，200/401符合预期）都不受影响；`gateway.wudaima.com` 依旧打不到我们 + （行为跟删之前一致，符合预期——本来就没在依赖这条隧道）。 +- `llm-setup.md`（本地+服务器都同步）、`h3-console/README.md` 更新掉了过期的"走不通"描述。 + ## 2026-08-29 — h3-console 加 Bearer token 鉴权，comfyui.wudaima.com 补基本认证 **背景**：审计公网暴露面时发现两个真实问题，都是**实测确认**，不是猜测： diff --git a/h3-console/README.md b/h3-console/README.md index 27727ec..8e0061b 100644 --- a/h3-console/README.md +++ b/h3-console/README.md @@ -119,7 +119,10 @@ setsid nohup ./run.sh > console-subpath.log 2>&1 < /dev/null & **2026-08-20 实测坐实这条线路走不通**，缺口在 frp 服务端 `60.205.214.169` 那边（本机这边 `frpc-qwen-client` 配置是对的、早就 `start proxy success` 注册上了，问题不在这台机器，详见 顶层 `CHANGELOG.md`「排查清楚：gateway.wudaima.com 公网转发为什么一直不通」）——**不是这台 -机器能改的**，需要能登录 `60.205.214.169` 的人补上，暂不等它。 +机器能改的**，需要能登录 `60.205.214.169` 的人补上，暂不等它。**2026-08-29 已放弃这条线**， +`frpc.qwen.ini` 里的 `[qwen-gw-20260610]` 那段客户端配置直接删了（走不通只是"目前观测到的 +状态"，留着是个隐患——服务端哪天补上 vhost 就会瞬间暴露开着弹性调度器的 8080 局域网实例）， +不再等它，永久走下面的子路径方案。 **改走 `qwen.wudaima.com/console` 子路径**（同一天改的，详见 CHANGELOG「h3-console 公网访问 改走 qwen.wudaima.com/console 子路径」），已验证可用： @@ -179,3 +182,13 @@ console 本身是独立进程，出问题直接 `kill` console 进程即可， - 磁盘：`/` 只剩 29G，`/data` 83% 满，上传接口目前只做单文件 20MB 上限校验，没做磁盘余量检查， 真到磁盘紧张时会和其他生成任务一样直接写失败，没有额外保护——按 DESIGN.md「开放风险」记录的， 真出问题再加。 +- **参考图/视频/音频的 URL 必须走专门字段，写进 prompt 文本里不生效**：`prompt` 走文本编码器， + 跟 `reference_image_urls`/`reference_video_urls`/`reference_audio_urls`（ref2va）、 + `first_frame_url`/`last_frame_url`（fl2va）是完全独立的通道（`raylight/server.py` 的 + `build_ref2va_graph`/`build_fl2va_graph`），后端不会去 `prompt` 字符串里扫描/下载 URL。 + 三个 reference 字段都留空时 `_partition_of()` 直接判成 `partition: "text"` 纯文生，不会报错， + 只是参考图完全不起作用。**2026-08-30 已用两条真实任务对照验证**：`683ab2fd4681`（URL 放进 + `reference_image_urls`，参考图生效）vs `1fa40bca47f5`（同一份 prompt，URL 写进文本里、 + 三个字段留空，`partition` 变成 `"text"`，人物/场景确认没参考上）。 + newtask 页面（`static/index.html`）2026-08-30 已加"或粘贴 URL"输入框，就是为了让外部 + 已托管的图片/视频/音频链接能走正确字段，不用先下载再重新上传。 diff --git a/llm-setup.md b/llm-setup.md index 660e676..19c5e12 100644 --- a/llm-setup.md +++ b/llm-setup.md @@ -335,7 +335,8 @@ curl http://localhost:8000/v1/models # 预期 qwen2.5-72b | 配置文件 | section | 域名 | 本地端口 | 状态 | |----------|---------|------|----------|------| | `frpc.qwen.ini` | `[qwen-llm]` | `qwen.wudaima.com` | 8000 | ✅ 大模型 API | -| `frpc.qwen.ini` | `[qwen-gw-20260610]` | `gateway.wudaima.com` | 8080 | ⚠ **8080 无监听，隧道空挂** | +| `frpc.qwen.ini` | `[qwen-console-subpath]` | `qwen.wudaima.com/console` | 8081 | ✅ h3-console 公网入口，要 Bearer token | +| ~~`frpc.qwen.ini` `[qwen-gw-20260610]`~~ | ~~`gateway.wudaima.com`~~ | ~~8080~~ | **2026-08-29 已删除**：这条隧道客户端配置指向 8080（h3-console 局域网实例），域名一直没打到我们（frp 服务端 `60.205.214.169` 没配对应 vhost，实测落在一个无关的默认 nginx 页面），但客户端配置本身是活的隐患——一旦服务端哪天补上 vhost 就会瞬间暴露开着弹性调度器的局域网实例。删前备份在服务器 `/home/admin/llm/frp/frpc.qwen.ini.bak-20260829` | | `frpc.ini` | `[m3e]` | `m3e.embedding.wudaima.com` | 7590 | ✅ 嵌入服务 | | `sd.frpc.ini` | `[stable-diffusion-web]` | `stable-diffusion.wudaima.com` | 7860 | ✅ SD WebUI | | `comfyui.frpc.ini` | `[comfyui-web]` | `comfyui.wudaima.com` | 8188 | ✅ **2026-08-22 起 raylight 常驻监听 8188，隧道其实一直是活的**（旧结论"无监听隧道空挂"已过期）；**2026-08-29 补了 `http_user`/`http_pwd` 基本认证**（ini 里的原生字段，不用改 ComfyUI 代码），之前裸奔过一段时间见 `CHANGELOG.md` | @@ -346,7 +347,7 @@ pm2 list # 需先 export PATH 或用绝对路径 pm2 logs frpc-qwen-client --lines 50 ``` -> ⚠ **安全**：`qwen.wudaima.com` 无任何鉴权，公网可直接调用本机 27B 推理（llm38 目前已停，暂时不可利用）。`gateway.wudaima.com → 8080` 这条客户端隧道配置一直在、且 8080 现在确实有服务在监听（h3-console 局域网实例），但域名在 frp 服务端 `60.205.214.169` 没配对应 vhost，实测会打到一个无关的默认 nginx 页面，不是我们的服务——**这不是保证，只是目前观测到的状态，服务端配置随时可能被改，别把它当长期安全边界**。`qwen.wudaima.com/console`（h3-console 公网入口）**2026-08-29 起要求 `Authorization: Bearer `**，token 见 `h3-console/README.md`。SSH 映射到公网 6000 且允许密码登录、admin 在 sudo 组。 +> ⚠ **安全**：`qwen.wudaima.com` 无任何鉴权，公网可直接调用本机 27B 推理（llm38 目前已停，暂时不可利用）。`qwen.wudaima.com/console`（h3-console 公网入口）**2026-08-29 起要求 `Authorization: Bearer `**，token 见 `h3-console/README.md`。`gateway.wudaima.com → 8080` 那条隐患隧道 2026-08-29 已删除，见上表。SSH 映射到公网 6000 且允许密码登录、admin 在 sudo 组。 ### 8.2 Nginx diff --git a/raylight/notes.md b/raylight/notes.md index 0657a92..9c7d296 100644 --- a/raylight/notes.md +++ b/raylight/notes.md @@ -1,5 +1,92 @@ # 踩坑记录 / 被推翻的假设 +## 2026-08-31 — 调研 FastVideo/FastH3（MiniMax H3 的 4-step 蒸馏版），结论：暂不可行，不建议投入 + +### 是什么 + +`https://huggingface.co/collections/FastVideo/fastvideo-fasth3`——Hao AI Lab（FastVideo项目） +把 MiniMax H3 做的 DMD2 蒸馏：复用 H3-Base 的文本编码器/VAE/tokenizer/scheduler，去噪步数从 +49 步蒸馏到 4 步，号称 B200 上最高 14x 加速。collection 里 5 个 checkpoint，核心是 +`Dense-DataFree`（33B，标准dense attention）和几个 `VSA-*`（35B，带90%稀疏attention， +需要额外的 VSA kernel）。还有一个单独的 LoRA 版本（只需下载蒸馏adapter，不用整份权重）。 + +### 卡我们的三条，不是单独一条，是三条一起卡死 + +1. **只发布 BF16，没有量化版本**。跟 `turing-bf16-attention-dead.md` 是同一个坑：sm_75 没有 + 高效 bf16 attention kernel，PyTorch 会静默掉到 MATH 后端物化整个attention矩阵然后 OOM。 + 对照组：FastVideo 家的另一个模型 FastHunyuan 是发了 NF4/LLM-INT8（bitsandbytes）量化版的， + 单张 RTX 4090 20GB 就能跑——**但 FastH3 没有这个待遇**，NF4/量化目前只在官方 roadmap 里 + （跟 NVFP4、RTX/DGX Spark/Apple MLX 优化写在一起，都是"未来工作"，不是现在能下载到的东西）。 +2. **VSA 加速的 kernel 是 Blackwell 专属**。官方发布的是 `sm100a`（B200）编译产物，非 + Blackwell 多卡系统建议 fallback 到 `--vsa-kernel triton`，但这条路径官方自己都没验证过 + Turing——roadmap 原文把 "RTX GPUs" 列为未来工作，不是当前支持范围。`Dense-DataFree` 这个 + 不依赖 VSA 的版本理论上绕开了这条，但绕不开第1条（bf16）。 +3. **不是 drop-in checkpoint，是要接官方 FastVideo 推理栈**。官方原话："FastH3 is a + FastVideo-stack release rather than a drop-in checkpoint"——依赖 FastVideo 自己的 + VSA-H3 backend + launcher（`uv` 装包、CUDA 13、Python 3.12），不是通用 LoRA loader， + 也**不是 ComfyUI-native**（官方原话：ComfyUI-compatible 路径"worth watching"，即还没做）。 + 这意味着即使解决了前两条，也没法直接塞进我们现有的 `raylight/` FSDP + ComfyUI 管线， + 得单独起一套 FastVideo 自己的推理服务，工作量不是换个权重文件那么简单。 + +### 结论 + +**三条骨牌效应**：没有量化权重 → bf16 在 Turing 上跑不动 attention；VSA 加速官方明确只支持 +Blackwell；就算只用不依赖 VSA 的 dense 版本绕开第2条，还是绕不开第1条的 bf16 问题，而且还得 +额外接一套跟 `raylight/` 不兼容的独立推理栈。三条里任何一条单独都可能想办法workaround（比如 +当年给base H3装社区版SageAttention2解决了bf16问题），但三条叠在一起、且其中两条依赖上游 +还没发布的东西（量化权重、ComfyUI适配），现在投入去啃性价比很低。 + +**什么时候值得重新看**：FastVideo 官方 roadmap 里的 NVFP4量化/RTX支持 或 ComfyUI-compatible +路径任一项实际发布之后，可以重新调研一次——那时候可能只需要解决 bf16→fp16 这一条， +跟当年 base H3 上 SAGE_FP16 那次工作量类似。在此之前不建议投入，我们已经有 `raylight/` +跑通的 base MiniMax H3（4-step蒸馏能省的时间，比不上现在这套稳定管线的确定性）。 + +### 补充：即使上面三条全部解决，目标"N秒视频在1）。算了一下 +数量级差距,这条比兼容性问题更硬,不是"肯搞"就能绕过去的： + +**FastH3官方自己的benchmark（B200，最理想情况）也没稳定做到 RTF>1**： +| 时长 | 配置 | 生成耗时 | RTF | +|---|---|---|---| +| 5s | 1×B200 | 16.2s | 0.31x | +| 10s | 1×B200 | 31.1s | 0.32x | +| 15s | 1×B200 | 47.2s | 0.32x | +| 15s | **8×B200** | 15.5s | **0.97x**（最接近，但仍不到1） | + +即数据中心顶配单卡也只做到约1/3实时速度，要8张B200堆到接近（仍未越过）实时线。 + +**我们现有 base H3（raylight, 4×2080Ti, 49步）的RTF**（从`README.md`已知限制表反推， +帧数/24fps=视频时长，除以实测耗时）：1344×768是**0.0052x（慢192倍）**，1024×576是 +0.0083x（慢120倍），832×480是0.0114x（慢88倍），448×256是0.0774x（慢13倍）。 + +**假设FastH3的三条全部被我们解决，只拿"4步蒸馏"这一项（12.25x步数缩减，VSA那部分 +Blackwell专属加速不算，因为在我们卡上用不了）套到现有耗时上**：1344×768推算269s +（RTF=0.064x，仍慢15.7倍）、1024×576推算304s（RTF=0.10x，仍慢9.8倍）、832×480推算335s +（RTF=0.14x，仍慢7.2倍）、**448×256推算53s（RTF=0.95x，接近但仍不到1）**。 + +**结论**：只有画质已知有妥协（448×256，`README.md`已知限制第1条记过"这是画质限制的 +分辨率"）这一档,乐观推算下勉强逼近实时,其余可用分辨率（832×480起步）哪怕拿到FastH3 +全部好处也还差一个数量级（7-16倍）。这不是靠攒工程投入能补的差距,是2080Ti算力本身的 +天花板——**在这台机器上,"N秒视频