改到一半就罢工，说明问题不在上下文长度，而在「哪个负载在崩、崩在哪一层」。先做三件事定位：
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 那几行日志贴出来，我看一眼就能帮你判断是哪层的问题。
