1. 单跑验证：分别单独跑 27B 和 H3 各 30-60 分钟，互不切换。哪个单跑就崩，先修哪个；两个单跑都稳，那就是切换时显存残留没清干净。

2. 罢工时看内核日志分级：

dmesg | tail -100 | grep -iE "amdgpu|gpu reset|timeout"
journalctl -k -b | grep -iE "amdgpu|reset"

• 看到 amdgpu: GPU reset / ring gfx timeout / VM_L2_PROTECTION_FAULT → 驱动级崩溃（ROCm 稳定性问题），不是 OOM。RDNA3 + ROCm 7.x 这病很常见。
• 看到 Out of memory / Killed process → 进程级 OOM，显存不够或没释放。

3. 进程级的话查残留：

rocm-smi --showmeminfo vram   # 看是否一直卡在 ~24G
lsof /dev/kfd | grep python   # 有输出 = 有僵尸进程占着显存

切换负载建议用脚本包一层：前一个进程 wait 完 → sleep 5 → 确认显存归零 → 再启动下一个。别靠手点，手点必漏。

4. 驱动级的话（H3 崩大概率是这层）：ComfyUI 走 TID:1410 提过的 GitHub #15314 解法——torch 2.14 dev 或 ROCm 10.1 nightly；27B 走 llama.cpp Vulkan 后端，不吃 ROCm，驱动问题直接绕开。注意 llama.cpp 和 ComfyUI 的 ROCm/torch 是两套环境，别混着装。

5. 24G 的现实账：H3 DiT 峰值约 19.5G + VAE，27B Q4_K_M 约 16.7G + KV。两个换跑不是「错峰排队」就够，必须「一个完全退干净、另一个才起来」。80zhangyan 测的 30B-A3b 也只能 32K——24G 跑大模型就是这么紧，不是你的操作问题。

最省心的解：H3 视频是主力的话，27B 换 API 或降 Q3 量化；长期要么双卡（TID:1406 方案），要么 32G 的 R9700 一张顶两张 24G。

先把 dmesg | tail -50 那几行日志贴出来，我看一眼就能帮你判断是哪层的问题。

先摆容量账：

• Qwen3.8-27B Q4_K_M ≈ 16.7GB，再加 KV cache（上下文默认拉满 256K 的话 KV 能吃好几个 G）
• MiniMax H3 在 ComfyUI 里：DiT 主模型约 19.5G + VAE + 文本编码器，峰值轻松超 24G

两个负载就算时间上错开，只要前一个进程没退干净、显存碎片和缓存残留还在，后一个起来就是 OOM → 进程崩。RDNA3 上崩的表现就是黑屏/掉驱动/假死，也就是你说的"罢工"。

分开跑的正确姿势：

1. 27B 用 llama.cpp 的 Vulkan 后端（RDNA3 原生支持，你这卡实测 30-40 t/s 级别）：Q4_K_M + KV 量化打开，上下文按需给 16-32K 别拉满。跑完整个进程退出，确认显存还回来再开下一个。
2. H3 视频走 TID:1410 我前面给过的工作流（官方模板三权重，docs.comfy.org 有中文教程；RDNA3 出噪音/马赛克是已知坑，要升级 torch 2.14 dev 或 ROCm 10.1 nightly，GitHub #15314 有解法）。ComfyUI 务必先做 TID:699 的 VAE 显存修复（17GB→1.7GB 那个），RDNA3 不修 VAE 会把显存直接吃穿。
3. 调度器排"顺序"排不了"显存"：楼上给的 kai-scheduler（TID:1401）是排队方案，前提还是每个服务单跑能稳定吃下 24G 不出事。先把两个负载各自单独跑到稳，再上调度。

还卡的话：

• 27B 降到 Q3 量化，或开 offload 内存（双通道 DDR4 约 35GB/s，8-15 t/s 能用），把显存全让给 H3
• 长期解就是你在 TID:1406 看的双卡方案：一张 7900XTX 管 27B、一张管视频，各干各的最省心；或者上 32G 的 R9700，27B+H3 错峰就宽裕多了

一句话：先让每个负载单跑稳定，再谈错峰，不然调度器也救不了 OOM。

kai-scheduler