宜博 / 2080tiserver

Commit 03001df7c98f96378c4877133b8ab3c70cad706c

Authored by yibo
1 parent 7511ff19

排查GPU被抢占的真根因：PM2托管服务(sd-forge/embedding) + minimax-h3彻底禁用 

停 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>
Inline Side-by-side
Showing 2 changed files with 28 additions and 4 deletions
CHANGELOG.md
  View file @03001df
1 1 # 变更记录
2 2  
  3 +## 2026-08-24（晚，续）— 更正：不是"另一个并发会话"，真凶是 PM2 自动重启 + 找到彻底止血办法
  4 +
  5 +**更正上面那条记录里"另一个并发会话手动启动/又手动拉起来"的归因是错的**——用户明确说这台机器
  6 +当时只有他自己在用，没有别的同事。停了 minimax-h3 之后它反复自己重新起来，一路排查（cron/
  7 +systemd/tmux/screen/supervisor 都查过一遍确认没有）才找到真正机制：
  8 +
  9 +- `stable-diffusion-webui-forge` 和一个 embedding 服务（`m3e`）是被 **PM2**（系统级 Node.js
  10 + 进程管理器，`pm2 list` 能看到，跑了75小时，跟这次任何工作都无关，是机器本来就有的基础设施）
  11 + 托管的，子进程被 kill 掉 PM2 会自动重启——这才是"杀了又起"的真正原因。已经
  12 + `pm2 delete sd-forge m3e && pm2 save`，从 PM2 的常驻列表里彻底删掉（`pm2 save` 很关键，
  13 + 不然重启/`pm2 resurrect` 还会把它们从旧快照里救回来）。
  14 +- `minimax-h3` 的 `gateway.py`/`api.py` **不在** PM2 管理范围内（`pm2 list`/root 的 PM2 实例
  15 + 都确认过没有它），真正触发重启的机制没有查到——但既然查不到，就换一个不用管触发源是什么
  16 + 都生效的办法：把 `api.py`/`gateway.py` 直接改名成 `.disabled-20260824`，`python -m uvicorn
  17 + api:app` 这个 module import 从根上就会失败，不管是谁/什么在尝试重新拉起，都会失败。改名
  18 + 后观察 45 秒，四卡显存稳定在基线（160-162MB），没有再出现任何重启尝试。
  19 +
  20 +**结果**：GPU 彻底清空，raylight/console 全程未受影响（验证过 `/health` 一直正常）。这个
  21 +问题从"以为是同事"到"查到 PM2"再到"minimax-h3 单独用改名兜底"，全程记录留着——如果以后再
  22 +遇到类似"进程杀了又起"的情况，**先查 `pm2 list`**，比查 cron/systemd 更容易先想到。
  23 +
3 24 ## 2026-08-24 — 下线旧 H3（minimax-h3）+ 确认 LLM 早已下线，GPU 显存全部还给 raylight
4 25  
5 26 **背景**：排查一次 raylight 的 CUDA OOM 时发现 GPU1 被另一进程占着 16.7GB、98%利用率——
... ...
CLAUDE.md
  View file @03001df
... ... @@ -84,7 +84,7 @@ cat llm-setup.md | ssh -o ControlPath=~/.ssh/cm67 admin@192.168.110.67 &#39;cat &gt; /h
84 84 |------|--------|----|------|------|
85 85 | `deploy-scripts/` | Qwen3.8-27B-Q5_K_M（llama.cpp，容器 `llm38`） | 0-3 分片 | **57.3 GB**（256K 上下文，2 槽位） | 8000 → `qwen.wudaima.com` |
86 86 | `raylight/` | **2026-08-22 起 h3-console 的默认后端**：ComfyUI + Raylight 插件，4卡当一个 FSDP 集群跑 MiniMax-H3（不是4个独立worker，任何时刻只处理1个请求）。`server.py`（8100）对外契约兼容旧 `gateway.py`+`api.py`，管理常驻 ComfyUI 进程（8188，仅内部） | 0-3 全部（FSDP集群） | 832×480×64帧实测峰值约20-21GB/卡；**124帧会OOM**，见 `raylight/README.md`「已知限制」 | 8100（内部，h3-console 的 `H3_GATEWAY_URL` 指向这） |
87   -| `minimax-h3/` | **热备份（2026-08-24 起启动脚本被禁用）**。MiniMax-H3 FL2VA/Ref2VA NF4 文生视频，`api.py` 四实例（GPU0-3，端口 8010-8013）+ `gateway.py` 调度层（端口 8000），四卡各自独立能同时处理4个请求。代码/权重保留，但 `start-all.sh`/`start-gateway.sh` 已改名成 `.disabled-20260824`（见目录内 `DISABLED-README.md`）——2026-08-24 发现有人手动拉起来跟 raylight 撞 GPU，停了两次又被拉起来，直接禁掉启动脚本，别再凭记忆当"还能秒级拉回"用 | 四卡各一进程（停着，脚本已禁用） | 单卡 fp32 峰值约 9-14 GB（视时长/分辨率），另占 CPU 内存约 32 GB/worker | 8000（停着） |
  87 +| `minimax-h3/` | **热备份（2026-08-24 起彻底禁用，双重保险）**。MiniMax-H3 FL2VA/Ref2VA NF4 文生视频，`api.py` 四实例（GPU0-3，端口 8010-8013）+ `gateway.py` 调度层（端口 8000），四卡各自独立能同时处理4个请求。代码/权重保留，但 `start-all.sh`/`start-gateway.sh` 和 `api.py`/`gateway.py` 本体都已改名成 `.disabled-20260824`（见目录内 `DISABLED-README.md`）——2026-08-24 反复出现"停了又自己起来"，查了半天不是 cron/systemd，也不是 PM2（那两个是 sd-forge/embedding 的事，见下），真正触发源没查到，干脆把 `api.py`/`gateway.py` 本体也改名，`python -m uvicorn api:app` 从 import 这层就会失败，不管谁/什么在尝试重启都没用。别再凭记忆当"还能秒级拉回"用，得先把三份改名的文件都恢复原名 | 四卡各一进程（停着，彻底禁用） | 单卡 fp32 峰值约 9-14 GB（视时长/分辨率），另占 CPU 内存约 32 GB/worker | 8000（停着） |
88 88 | `h3-console/` | H3 Web 管理台：上传/生成/预览三界面 + 任务持久化。两个进程共享同一份 sqlite/assets：**8080**（局域网直连，`BASE_PATH` 空）+ **8081**（`H3_CONSOLE_BASE_PATH=/console`，专供公网子路径用）。**2026-08-22 起两个实例的 `H3_ENABLE_SUPERVISOR` 都关了**——fl2va/ref2va 弹性调度器（按partition flip某张卡）是给 minimax-h3 那套"4个独立worker"架构设计的，raylight 的FSDP集群架构下没有"单卡分区"这个维度，开着会出错 | 不占显存（自己不跑模型） | — | 局域网 `http://192.168.110.67:8080`；公网 `http://qwen.wudaima.com/console`（frp `locations=/console` 分流，`gateway.wudaima.com` 那条独立域名确认走不通，缺口在 frp 服务端 60.205.214.169，见 CHANGELOG） |
89 89  
90 90 ⚠️ **"（常驻）whisper GPU3 3.2GB"这条 2026-08-24 确认是过期信息**——当时机器上根本没有任何
... ... @@ -133,9 +133,12 @@ stable-diffusion-webui-forge`）和一个 embedding 服务（gunicorn:7590），
133 133 **2026-08-24 更新：LLM（`llm38`）和旧 H3（`minimax-h3` 的 `gateway.py`+`api.py`）都已下线，不占显存**。
134 134 `llm38` 容器 `docker ps -a` 显示 6 天前就已经停了（`Exited (0)`），不是本次操作停的，只是文档一直
135 135 没更新——`qwen.wudaima.com` 现在实际上是打不通的，上面这段"对外服务中"的描述已经过期。
136   -`minimax-h3` 的四个 worker（8010-8013）+ `gateway.py`（8000）是本次手动按端口 `kill` 停的——
137   -之前被另一个并发会话手动启动过，跟 raylight 抢过 GPU（详见 `raylight/notes.md`/`CHANGELOG.md`
138   -2026-08-24 那几条）。**现在这台机器上生产只跑 `raylight/`（h3-console 默认后端）**，代码/权重
  136 +`minimax-h3` 的四个 worker（8010-8013）+ `gateway.py`（8000）是本次手动按端口 `kill` 停的，
  137 +停完反复自己又起来——**一开始误以为是别的并发会话在手动重启，后来确认这台机器当时只有一个人
  138 +在用，排查出真正原因是 PM2（系统级进程管理器）在管另外两个不相关的服务（sd-forge/embedding），
  139 +已经 `pm2 delete`+`pm2 save` 处理掉；`minimax-h3` 本身的重启触发源没有查到，改用把
  140 +`api.py`/`gateway.py` 本体也改名的办法从根上堵死**，完整排查过程见 CHANGELOG 2026-08-24
  141 +「更正」那条。**现在这台机器上生产只跑 `raylight/`（h3-console 默认后端）**，代码/权重
139 142 都还在，两条线要拉回来都还是走各自的 `start.sh`/`docker start llm38`，没有删任何东西。
140 143  
141 144 ## 这是一台测试机（2026-08-18 用户明确）
... ...