DeepSeek-V4 长时运行宕机复盘 + 稳定性加固:为什么一个 5-token 请求会压垮整个服务

2026-08-20 复盘

对象: GPU4-7 实例 (容器 lvllm-ds4-tp4-ep4, 端口 8002, TP+EP 512K)。事件: 长时间运行 (48h+) 后 EngineCore fatal → API 永久挂死, 需手工重建。本文给出完整证据链根因 + 可直接落地的加固方案 (参数 / 自愈 supervisor / 监控)。配套性能演进主线见《在 8× A800 上把 DeepSeek-V4-Flash 榨到极限:从 5 倍提速到 TP+EP 双实例的完整实测》。

一句话结论: 这不是"前缀缓存清理不掉" ------ vLLM 前缀缓存是 LRU 自动淘汰。真正的根因是单个超长上下文请求的 decode 单步耗时随长度超线性增长, 最终压垮 worker, 而 vLLM 的 EngineCore 超时后不自愈, 导致服务永久僵死。

⚠️ 读前澄清(重要) : 本文分析的那次宕机是 08-19 16:14 的单次真实事故 (见§一时间线, "08-20" 是本文复盘写作日期)。事故发生后我们引入 supervisor 自愈兜底, 但早期版本把"启动宽限"设成 180s, 而 vLLM 完整启动实测要 ~6-7 分钟 → 在无真实流量、服务正常 的情况下, supervisor 连续把正在正常冷启动的进程误判为宕机并重建, 累计 940 次"重建" 。这 940 次绝大多数是启动期误杀, 不是上述宕机反复复发 ; 修复为基于容器实际启动时间的 600s 宽限后零误杀。换言之: 真实事故只有一次, 后续的"频繁崩溃"是自愈脚本自己的参数 bug。下文 §3.4 详述。

一事故时间线(依据 `docker logs`)

时间 (08-19)	事件	证据
06:25	容器启动 (本次运行第 48h)	启动日志 `06:25:38`
06:28--06:35	启动期 TileLang JIT 编译预热	6 次 shm 卡顿 (正常阶段)
06:47--07:12	长上下文请求连续 prefill	大预填吞吐日志
15:01	开始出现周期性 shm 卡顿 (60s)	`shm_broadcast.py:705`
15:01--16:13	卡顿渐密: 15:01 间隔 80-140s → 16:02 后 60-90s	18 次卡顿日志
16:07:11	KV 98.4%, Running:1, gen 1.6 tok/s	`loggers.py:273`
16:07:21	gen 0 tok/s, KV 98.4%
16:14:09	EngineCore fatal (TimeoutError)	`core.py:1204`

以下源码行号( loggers.py:273 / core.py:1204 等)对应本文所测镜像版本, 不同版本可能漂移, 定位时以关键字为准。

崩溃瞬间 dump:

bash 复制代码

SchedulerOutput(scheduled_new_reqs=[NewRequestData(req_id=..., prompt_token_ids_len=5, ...,
  sampling_params=max_tokens=16, ...),  block_ids=([17042],[6444],...))
SchedulerStats(num_running_reqs=1, num_waiting_reqs=0, kv_cache_usage=0.396,
  prefix_cache_stats=..., kv_cache_eviction_events=[], ...)

关键: 崩溃请求仅 5 token / max_tokens=16 的极小请求; 崩溃时 KV usage 0.396 (39.6%)。

二根因(证据链完整)

2.1 表象:"前缀缓存满了" → 实际不是根因

崩溃请求 KV usage 仅 39.6%, 池远未满 ------ 若前缀缓存是根因, 应在池满时崩。
kv_cache_eviction_events=[] 显示淘汰机制正常 (前缀缓存 LRU 按需淘汰冷块)。
结论 : "主动清理 KV" 是无的放矢 ------ vLLM 没有"周期性清空 prefix cache"的内置机制 (见 §3.1), 但也不需要 ------ LRU 淘汰已是常态机制。

2.2 真根因: 单请求 decode 单步耗时随上下文超线性增长 → worker 压垮

推理链 (各环均有日志/源码佐证):

一个超长上下文请求独霸 : 16:07 Running:1 且 KV 98.4% → 该请求已极长 (512K 级上下文, decode 每步要对其全部历史做稀疏 attention)。
- DeepSeek-V4 每 token KV ~46 KB, 池 ~92.9 万 token。
- 98.4% 占用 ≈ 单个请求占 ~91 万 token 历史。
decode 步耗时随长度增长 : 上下文越长, 每步 attention/索引器计算越重 → gen 1.6 tok/s, 即单步 ~数百 ms ~ 秒级, 且随生成增长继续上升。
分步分片执行 + TP/EP 卡同步 : worker 上该单步是全 TP 组同步的 (all-gather 分片, 每层同步点), 单步卡住 → 所有 worker 一起等。
EngineCore 等结果超时 : EngineCore execute_model RPC dequeue 等 worker 结果, 单步超 VLLM_EXECUTE_MODEL_TIMEOUT_SECONDS (默认 300) → TimeoutError → fatal。
60s shm 卡顿是同一现象的通信层投影 : ringbuffer 写者等所有 reader 消费完上一块才写新的; 任一 worker 卡住不消费 → 写者 (EngineCore) 就绪但等待 → 每 60s 报一条。卡顿渐密 = worker 越来越跟不上。
vLLM 不自愈 : EngineCore fatal 后容器进程仍存活 (docker running=true), 但 RestartCount=0 ------ vLLM 不会自动重建 , API 永久挂死, 残留 worker 占显存 (本次崩后 GPU4-7 停在 ~70.4 GiB, 8002 端口 http 000)。

2.3 为什么是"渐进劣化"而非"单次 JIT 秒杀"

卡顿从 15:01 起渐密 (间隔 140s → 60s), 跨度 72 分钟 ------ 不是单次编译。
启动期 JIT (06:28-35) 正常完成; 若运行期有新 shape 也会编译, 但非主因: 纵使 TileLang 编译, 单次也就秒级, 撑不到 300s。真正持续拉长的是长上下文 decode 本身。
崩前无新增 TileLang 编译日志 → 主要拉长项是长上下文计算, 不是 JIT。(启动期一次 JIT 预热已覆盖绝大多数 shape。)

2.4 关键修正 (对比早期假设)

早期假设	实证结论
"KV 打满 → 前缀缓存不清理 → 卡死"	KV 仅是受害请求的占用, LRU 淘汰正常; 崩溃时池仅 39.6%
"Triton JIT 编译是卡死主因"	实际是 TileLang JIT; 启动期已预热, 崩前无新编译 → 非主因
"某个崩溃请求 16 条输入导致"	崩溃请求仅 5 token, 是被拖累的旁观者, 不是元凶

三加固方案(可直接落地)

完整可复现脚本见系列第一篇附录(§十一): deploy_ds4_tp_ep.sh + supervisor.sh + start_trio.sh + monitor.sh 调用方式。本篇聚焦为什么 与怎么选。

3.1 "主动清理 KV" 为什么不可行 / 不必需

VLLM_PREFIX_CACHE_RETENTION_INTERVAL (以为能定时清前缀缓存):
- 源码 仅适用于 sliding-window KV group , 其它 (含 DeepSeek-V4 的 MLAAttentionSpec) 会直接抛 ValueError。
- 结论: 该变量对本实例不可用。
没有"清空 prefix cache"的内置旋钮: 前缀缓存按块哈希 LRU 自动淘汰, 无手动清空开关。
结论 : 与其制造"清理机制", 不如限制单请求 KV 上界 + 让服务可自愈 (见下)。

3.2 治本一: 限制单请求上下文上界 (可选, 需业务权衡)

参数	现状	建议	依据
`MAX_MODEL_LEN`	512K	若非刚需, 降 256K	满 512K 单请求 ≈ 池 55%; 降 256K 单请求 ≤ 池 28%, decode 单步上界显著下降, 仍有 3.1 并发度
---	---	保留 512K 则配合 supervisor	需自愈兜底单请求增长风险

若业务确有偶发 512K 需求, 保留 512K 但必须开启 supervisor (§3.4)。256K 是"稳"与"长"的折中。

3.3 治本二: 模型执行硬超时显式化

部署脚本新增 VLLM_EXECUTE_MODEL_TIMEOUT_SECONDS (默认 600, 覆盖镜像默认 300):

bash 复制代码

EXEC_MODEL_TIMEOUT=${EXEC_MODEL_TIMEOUT:-600}   # deploy_ds4_tp_ep.sh
-e VLLM_EXECUTE_MODEL_TIMEOUT_SECONDS="${EXEC_MODEL_TIMEOUT}"

作用: 这是触发 fatal 的那条 RPC 超时 (EngineCore 等 worker 结果)。
512K 超长 decode 单步可能在 300-600s 之间完成 (慢但可恢复) → 调大到 600 减少误杀。
⚠️ 真卡死不会因调大而恢复 ------ 超时只是"何时宣布死亡"窗口, 不解决卡死本身。因此必须配合外部 supervisor: 调大超时 = 给足恢复窗口, supervisor = 保证最终恢复。

3.4 治本三: 外部自愈 supervisor (本次宕机真正缺的一环)

scripts/supervisor.sh:

bash 复制代码

# 前台循环 supervisor (推荐 nohup / systemd 托管)
nohup bash scripts/supervisor.sh >/var/log/supervisor.log 2>&1 &

# 或 cron 每 1 分钟检查一次:
#   */1 * * * * /path/to/scripts/supervisor.sh once

每 INTERVAL (默认 30s) 探测 ${BASE_URL}/health;
连续 FAIL_THRESH (默认 3) 次失败 → docker rm -f + 重建;
或日志命中 EngineCore fatal | RPC timed out → 立即重建 (不等连满 3 次 HTTP 失败);
冷启动宽限 STARTUP_GRACE (默认 600s): 距容器实际启动 <600s 一律跳过健康探测, 避免把正常冷启动 (~6-7 分钟) 误判为宕机。
ENABLED=0 可只报告不动作。

⚠️ 早期版本用 180s 冷却, 而 vLLM 完整启动实测需 ~6-7 分钟 → 每次启动未完成即被判死重建, 形成无限重建循环 (曾累计 940 次重建)。已将冷却对齐为基于容器实际启动时间的 600s 宽限。

这一项直接消除本次事故的核心危害: "EngineCore fatal 后服务永久僵死"。无论 worker 因何卡死, supervisor 都保证在 ~1-2 分钟内自动恢复。

3.5 治本四: 监控前置 (卡死前兆探测)

scripts/monitor.sh 新增生成吞吐冻结探测 (watch 模式):

bash 复制代码

BASE_URL=http://127.0.0.1:8002 GEN_MIN_TPS=1.0 GEN_STALL_SEC=30 \
  AUTO_HEAL=1 nohup bash scripts/monitor.sh watch &

当 Running>0 但生成吞吐 < GEN_MIN_TPS (默认 1.0 tok/s) 持续 GEN_STALL_SEC (默认 30s) → 告警 "worker 疑似卡死" (这正是 16:07 的前兆);
AUTO_HEAL=1 时自动调 supervisor 重建;
与 KV 告警正交: KV 高 + 吞吐冻结 = 卡死高概率信号。

3.6 可选: KV offload (KV 放 CPU, 长上下文不占 GPU KV 池)

bash 复制代码

KV_OFFLOAD_SIZE=256 bash scripts/deploy_ds4_tp_ep.sh

超长上下文 (512K+) 的 KV 放 CPU 内存 (~46 KB/token × 512K ≈ 24 GiB), GPU KV 池留给并发。
代价: decode 变慢 (CPU 访问) + 增加跨 dev 通信。
适合"长上下文刚需 + 愿意牺牲速度"的场景; 否则优先 §3.2 降上限 + §3.4 supervisor。

四落地清单 (本次已改)

文件	改动
`deploy_ds4_tp_ep.sh`	新增 `EXEC_MODEL_TIMEOUT` env (默认 600) + 注入 `VLLM_EXECUTE_MODEL_TIMEOUT_SECONDS`; header 注明
`supervisor.sh`	新增自愈看门狗 (健康探测 + 日志致命关键字 → 自动重建)
`monitor.sh`	新增生成吞吐冻结探测 + `AUTO_HEAL` 联动; header 文档更新
`start_trio.sh`	新增三件套一键托管 (幂等 start/status/stop)

五运维建议 (融合)

部署 + 自愈 + 监控三件套 一起用 (一键托管):

bash 复制代码

bash scripts/start_trio.sh          # 幂等启动 supervisor + monitor (logs 落 scripts/logs/)
bash scripts/start_trio.sh status   # 查看三件套状态
bash scripts/start_trio.sh stop     # 停止守护进程

KV 高是正常信号, 不是灾难 (LRU 自动淘汰); 真正要看的是 Running>0 时吞吐是否冻结。
长上下文是天然的并发/时延风险: 要么降 MAX_MODEL_LEN, 要么保证自愈兜底。
排查卡顿先看 docker logs 里 shm_broadcast.py:705 的频率 ------ 它是 worker 跟不上的通信层显示, 频次增高即预警。

DeepSeek-V4 长时运行宕机复盘 + 稳定性加固:为什么一个 5-token 请求会压垮整个服务

DeepSeek-V4 长时运行宕机复盘 + 稳定性加固:为什么一个 5-token 请求会压垮整个服务

一 事故时间线(依据 docker logs)

二 根因(证据链完整)

2.1 表象:"前缀缓存满了" → 实际不是根因

2.2 真根因: 单请求 decode 单步耗时随上下文超线性增长 → worker 压垮

2.3 为什么是"渐进劣化"而非"单次 JIT 秒杀"

2.4 关键修正 (对比早期假设)

三 加固方案(可直接落地)

3.1 "主动清理 KV" 为什么不可行 / 不必需

3.2 治本一: 限制单请求上下文上界 (可选, 需业务权衡)

3.3 治本二: 模型执行硬超时显式化

3.4 治本三: 外部自愈 supervisor (本次宕机真正缺的一环)

3.5 治本四: 监控前置 (卡死前兆探测)

3.6 可选: KV offload (KV 放 CPU, 长上下文不占 GPU KV 池)

四 落地清单 (本次已改)

五 运维建议 (融合)

一事故时间线(依据 `docker logs`)

二根因(证据链完整)

三加固方案(可直接落地)

四落地清单 (本次已改)

五运维建议 (融合)