事情本身不复杂，线索都在日志里。SGLang 0.4.1 在 24GB 卡上起 Qwen2.5-7B，加 --mem-fraction-static 0.9，启动到 KV cache 分配时报 RuntimeError: Out of memory，降到 0.8 才能起来，先清显存再起同样失败。
第一反应是「CUDA graph 捕获额外占用 1GB 以上」，验证下来不成立。
真正麻烦的地方在于，几个原因的现象几乎一样。0.9 留给权重和激活的余量不足。另一种情况是张量并行时每张卡都按同一比例计算。
还有一种情况，卡上还有别的进程占着显存。
起服务前先看显存实际占用
nvidia-smi --query-gpu=memory.used,memory.total --format=csv随后把静态比例降到 0.8 再启动
python -m sglang.launch_server --model-path Qwen/Qwen2.5-7B-Instruct --mem-fraction-static 0.8 --port 30000接着关掉 CUDA graph 释放余量
python -m sglang.launch_server --model-path Qwen/Qwen2.5-7B-Instruct --mem-fraction-static 0.85 --disable-cuda-graph压测确认并发上限没有被压太低
python bench.py --url http://127.0.0.1:30000 --concurrency 16这类改动我都写进变更记录，过两周再出问题时能对上号。
我习惯把每一步的执行时间和结果记在一边，后面复盘省事。
恢复的判定其实很直接。服务正常启动，日志里 KV cache 容量大于 20GB，16 并发压测无 OOM，首字延迟在 400ms 以内。
这个比例是静态预留，调小会直接压低并发上限，别为了能启动一路降到 0.5。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。