SGLang 长上下文 OOM 排查与显存预算优化
双 RTX 3090 · Qwen3.8-27B · SGLang v0.5.17 · 一次真实的生产故障排查
从”误以为是超时”到”挖出显存预算链”，含 3 个修复决策的完整思考2026-08-17 · 已上线生产验证
先说结论：我的 SGLang 服务偶尔返回 500，排查后发现根本不是”请求超时”，而是长上下文推理触发了显存 OOM，导致容器崩溃重启。
这个排查过程的价值在于：最开始的判断是错的，而真正找到根因的方法——把显存预算的每一个环节都拿出来审视——恰恰是上次把上下文从 65K 优化到 119K 时用过的同一套方法。
一、现象：工作汇报对话两次 500
用我自建的本地推理服务跑 Qwen3.8-27B（SGLang），日常短对话一切正常。但有一次”部门工作汇报”的长对话，两次问答都没有返回，服务端报 500 Internal Server Error。
直觉反应是：是不是请求超时了？ 因为日志里有 SGLANG_REQUEST_STATE_WAIT_TIMEOUT 这个参数，默认 4 秒。
我甚至一度想把这个超时调大到 300 秒。
但这个直觉是错的。
二、第一层挖掘：超时参数根本不是”超时”
读 SGLang 源码（tokenizer_manager.py:1674），这个参数的真实语义和想象完全不同：
while True:
await asyncio.wait_for(state.event.wait(), timeout=T) # 等下一个输出事件
except TimeoutError:
if request.is_disconnected(): # 只有客户端断开才 abort
raise ValueError(...) # → 500
continue # 客户端还连着 → 无限等待
关键真相：
它不是请求的总超时，而是”等待下一个输出事件”的轮询间隔。只要客户端保持连接，请求会无限等待，无论设 4s 还是 300s；只有客户端断开时才会中止请求。
也就是说：调大这个超时，根本不能解决”服务端不返回”的问题。 如果服务端死了，客户端连接立刻断开，这个参数压根不参与。
三、第二层挖掘：500 的真正时刻
看服务端日志，发现两次 500 都伴随一个特征：先出现 Received sigquit from a child process. It usually means the child failed.，几秒后返回 500，过几分钟同模式再次出现。
这是子进程崩溃 → 容器重启 → 进行中的请求 500 的完整链条。
继续挖，崩溃的真正原因浮出水面：
torch.OutOfMemoryError: Tried to allocate 48.00 MiB.
GPU 0 has 5.19 MiB free. Process has 23.23 GiB in use
连 48MB 都分配不到了。 nvidia-smi 显示显存 24003/24576 MiB，几乎打满。
四、机制链：为什么”工作汇报”会 OOM，短对话不会
把逻辑串起来：
长上下文请求 → prefill 阶段 activation 峰值飙升 → 超过 avail 余量（当时仅 0.65GB）→ OOM（连 48MB 都分不到）→ 子进程崩溃 → SIGQUIT → 容器重启 → 进行中的请求 500。
关键区分：短对话（小 prefill）activation 峰值小，能继续；工作汇报（长上下文，上下文里积累了整份材料）prefill 大，activation 峰值爆表，直接 OOM。
所以这根本不是超时问题，也不是什么”显示器最小化”的玄学——是显存余量不足以应对长上下文 prefill 的峰值。
五、修复：从显存预算链找答案
上次我把上下文从 65K 优化到 119K，用的方法就是把显存预算的每个环节都拿出来审计（预算链思考法）：从 24GB 显存出发，mem-fraction 决定总预算，减去模型权重 17.67GB、Mamba 状态缓存 0.70GB、以及有下限锁死的 activation reserve，剩下的才是 KV 池加运行时余量。
这次 OOM 的根源清晰了：mem-fraction=0.95 时，KV 池吃满了预算，留给 activation 峰值的余量只有 0.65GB。 长上下文 prefill 一旦峰值超 0.65GB 就崩。
修复决策 1：mem-fraction 0.95 → 0.93
核心权衡在”上下文上限”与”运行稳定性”之间。实测换算关系很清晰：mem-fraction 每降 0.01，KV 池减少约 7,870 tokens，即上下文约少 8,000。
三档对比一目了然：0.95 时 KV 池 120,079、运行时余量仅 0.65GB（危险）、上下文 119K；降到 0.93 后 KV 池 105,256、余量提升到 1.09GB（+70%）、上下文 102K；再降到 0.92 则余量 1.35GB 但上下文跌破 100K（95K）。
选 0.93 而不是 0.92 的原因很明确：保住 100K+ 上下文（0.92 就跌破心理线了），同时余量翻倍，OOM 风险大幅降低。这是用数据做的取舍，不是拍脑袋。
修复决策 2：context-length 取 102400
0.93 时 KV 池 105,256，context 取 102400（1024 的倍数）——留约 2,800 tokens 余量，避免单请求刚好顶到池上限，也为后续增长留点空间。
修复决策 3：超时设 10s（经过 4s/10s/30s/300s 全分析）
超时参数的真相前面说了——它防不了 OOM。那它到底该设多少？关键在于理解它的真实角色：客户端断开的回收延迟，而非请求超时。
默认 4s 偏激进，客户端网络闪断几秒就可能被误判”断开”而中止一个本可继续的请求；30s 则太保守，断开的僵尸请求会占着并发槽位（我们只有 3 并发）长达 30 秒，可能阻塞新请求；300s 就更夸张了，断开回收延迟放大 75 倍，毫无必要。
10s 是平衡点：比默认宽容（网络闪断 5 秒不误杀），又不会让僵尸请求滞留太久拖累并发。理解了语义，自然知道 300s 是过度设计。
六、方法论沉淀：这次排查教会我什么
一、最开始的判断往往是错的，要敢于推翻自己
“超时导致 500″是第一直觉，但源码证明超时参数根本管不到崩溃场景。每次 500 都值得去日志里找 SIGQUIT/OOM 的真凭实据。
二、显存预算链思考法（再次验证）
上下文、稳定性、并发——全都归结为显存预算链上每一环节的分配。遇到显存相关的问题，不要凭感觉，把每个环节列出来，找到”非必要预留”或”余量不足”的地方。
三、参数语义比参数值更重要
SGLANG_REQUEST_STATE_WAIT_TIMEOUT 的名字像”请求超时”，实际是”断开检测轮询”。不读源码就调参，等于蒙着眼睛开车。
四、稳定性 vs 上限的取舍要量化
0.95 能跑 119K 但会 OOM；0.93 只到 102K 但稳。用数据（每 0.01 换 8000 tokens、余量翻倍）做决策，而不是拍脑袋。
七、当前生产状态
修复后的 SGLang 配置：mem-fraction-static 0.93，context-length 102400（1024 倍数），SGLANG_REQUEST_STATE_WAIT_TIMEOUT=10。KV 池 105,256 tokens，运行时余量 1.09GB（+70%），并发保持 3。
短对话正常、长上下文不再 OOM、并发保持 3。 推理验证通过（1+1=2 ✓），修复已在生产稳定运行。
写在最后
一次 500 排查，从”改个超时参数”的直觉，到”挖出显存预算链”的真相，中间隔着的是一份源码和一套思考方法。
如果你也在自建大模型服务，遇到莫名的 500/OOM，不妨试试：
一、先看日志里的 SIGQUIT / OutOfMemoryError，别急着调超时
二、用显存预算链审计每一个环节
三、记住：稳定跑 100K 上下文，好过偶尔崩掉的 119K
环境：Debian 12 · 双 RTX 3090 24GB · Ryzen 5950X · SGLang v0.5.17 · Qwen3.8-27B AutoRound W4A16
相关阅读：../research/sglang-context-extension-breakthrough-2026-08-16.md（65K→119K 上下文优化全记录）