2026-09-10 · L1 + L2 · 已回滚

27b 服务端升级记录 —— 一次被推翻的升级

这是失败记录，不是发布说明。L1（util 0.91→0.944）+ L2（max-model-len 131072→262144）在 2026-09-10 19:45 推到生产， 19:50 被第一个真实长请求（prompt_tokens=93199）打崩，19:55 字节级回滚， 20:02 用同一请求复验通过。生产当前仍是 0.91 / 131072 / 单请求 128K。 下面所有「改后」列的 256K 数字都是已回滚、不再生效的历史值。

最贵的一条经验：启动日志那三行（Available KV cache memory / GPU KV cache size / Maximum concurrency）全绿也不能证明配置可用。 那三行只算「权重 + KV 池 + cudagraph + 非 torch 开销」，一行都没算运行期 prefill 的激活峰值。

为什么当时以为是安全的

util 0.91→0.944 不是我们拍的，是 vLLM 启动日志自己算出来的建议值：

gpu_worker:553  util 0.9100 ≡ 0.8760 (cudagraph profiling on);
                「要维持改之前同样的 KV，请设到 0.9440」

0.91 只等于「关掉 cudagraph profiling 时的 0.876」，那 0.034 是 profiler 预留的额度。 当时把它读成「引擎自己认为安全的额度，可以要回来」。

max-model-len 131072→262144 不花 1 字节显存：模型原生 max_position_embeddings=262144、rope_type="default"（不需要 yarn/linear 缩放）。 131072 是我们自己设的上限。

这两条推断单独看都对，合起来的结论错了：0.944 要回来的那 0.67 GiB 并不是「多余额度」， 而是 prefill 激活峰值的余量；而 262144 把这个余量能承受的 prefill 长度上限抬高了。

执行与实测

Canary 只验了启动日志

canary vllm-qwen38-27b-tq4（1 副本）改前是 32768 / 0.80 / 9 seqs / 8192 batched， 不是生产的同构克隆 —— 它只验证「这两个 flag 能不能在这个模型上安全落地」。 新 pod 实测（19:35:11）：

Checkpoint size: 16.19 GiB
Model loading took 8.07 GiB memory and 165.696784 seconds
Estimated CUDA graph memory: 0.44 GiB total          （该 pod capture sizes 只到 8）
Available KV cache memory: 9.01 GiB
GPU KV cache size: 965,793 tokens
Maximum concurrency for 262,144 tokens per request: 3.68x
Application startup complete.
（无 CUDA out of memory / 无 graph capture 报错）

canary 起来了、三行全绿，于是被判定为「通过」。但运行期门禁 longprefill_probe.py 没跑（当时它还不存在）。这是事故的第一层原因。

生产跳过门禁直接推

第一个新 pod vllm-qwen38-27b-lora-754758c4ff-npqv4（19:45:11）：

Checkpoint size: 16.19 GiB
Model loading took 8.07 GiB memory and 177.651499 seconds
Padding mamba page size by 167.69% ...
Setting attention block size to 8192 tokens ...
Estimated CUDA graph memory: 0.67 GiB total
Available KV cache memory: 7.98 GiB
GPU KV cache size: 855,417 tokens
Maximum concurrency for 262,144 tokens per request: 3.26x
CUDA graph pool memory: 0.61 GiB (actual), 0.67 GiB (estimated), difference: 0.05 GiB (8.6%)
Application startup complete.
（无 CUDA out of memory / 无 graph capture 报错）

崩溃：19:50:45，第一个真实长请求

对 npqv4 发 prompt_tokens=93199 → HTTP 500：

(Worker_TP0 pid=577) ERROR 09-10 19:50:45 [multiproc_executor.py:1004]
  File ".../vllm/model_executor/layers/fla/ops/chunk_delta_h.py", line 357,
       in chunk_gated_delta_rule_fwd_h
    v_new = torch.empty_like(u) if save_new_value else None
torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 96.00 MiB.
GPU 0 has a total capacity of 19.58 GiB of which 94.88 MiB is free.
Including non-PyTorch memory, this process has 19.48 GiB memory in use.

同一个请求打到旧配置 pod 755678f46c-6sbxc（0.91 / 131072）： prompt_tokens=93199 finish=stop answer='7Q3Z' —— PASS。

把每卡显存账按两个 util 各算一遍（3080，分母 20480 MiB，可用 19.58 GiB）：

单变量 A/B：肇事者是 L2，不是 util

因为 93199 < 131072，max-model-len 本身没有拒绝这个请求，所以第一嫌疑是 util。 把 canary 对齐成生产的同构克隆（48 层 skip-layers、--max-num-seqs 64、 --max-num-batched-tokens 16384、--cudagraph-capture-sizes 1 2 4 8 16 32）， 逐 flag 比对只差 --gpu-memory-utilization 与 --served-model-name， 每次只留一个变量，跑同一道门禁 longprefill_probe.py <pod> 60000 80000：

实验 A（util 0.944 / max-model-len 131072）canary ...-fz5g6 启动实测：

Available KV cache memory: 7.98 GiB
GPU KV cache size: 738,769 tokens
Maximum concurrency for 131,072 tokens per request: 5.64x

=== target=60000 ip=10.244.209.45 chars=324643 restarts_ready=0:true 20:15:00
OK prompt_tokens=93199 completion=5 finish=stop elapsed=113s answer='7Q3Z' PASS
    after: restarts_ready=0:true 20:16:53
=== target=80000 ip=10.244.209.45 chars=433247 restarts_ready=0:true 20:16:53
OK prompt_tokens=124637 completion=5 finish=stop elapsed=129s answer='7Q3Z' PASS
    after: restarts_ready=0:true 20:19:03
SUMMARY [[60000, "PASS"], [80000, "PASS"]]
DONE 20:19:03

这一步否掉了第一嫌疑：同一个 93K 请求、同样的 --max-model-len 131072，util 抬到 0.944 之后照样过，restartCount 仍是 0，且 Available KV cache memory 也是 7.98 GiB （和生产崩掉那版一模一样）。「0.944 吃掉了 prefill 安全垫」这个解释单独站不住。 顺带修正口径：738,769 ÷ 7.98 = 92,578 token/GiB，回到基线 92,913 附近。

实验 B（util 0.91 / max-model-len 262144）canary ...-4bsnt 部署 args 只改了 --max-model-len，util 保持 0.91。 启动实测（20:39:04–20:39:45）：

Available KV cache memory: 7.31 GiB
GPU KV cache size: 786,432 tokens
Maximum concurrency for 262,144 tokens per request: 3.00x
...
INFO: Application startup complete.            # 20:39:45

启动是绿的，786,432 ÷ 7.31 = 107,582 token/GiB，与生产崩掉那版基本一致。 同一道门禁：

=== target=60000 ip=10.244.218.132 chars=324643 restarts_ready=1:true 20:39:xx
93199 HTTP_500 elapsed=301s
    after: restarts_ready=2:false
SUMMARY [[60000, "HTTP_500"]]

第一步 93,199 token 就挂了。日志（kubectl logs --previous）里的崩溃链 不是 OOM，也不是 CUDA 错：

shm_broadcast.py:705        ...  ×3（20:42 / 20:43 / 20:44，每次 60s 超时）
core.py:1233                TimeoutError: RPC call to sample_tokens timed out   # 20:44:46
async_llm.py:704            EngineDeadError

即引擎在 93K prefill 上先卡死（worker 与 scheduler 之间的 sample_tokens RPC 连续三次 60s 无响应），scheduler 把引擎判死后整进程退出。控制组（实验 A 与生产 nx7mc） 在同一请求上是 113–126s 正常返回答案。

结论：--max-model-len 262144 单独就足以让 93K prefill 崩， 与 util 无关；生产那次的 OOM 主因是 L2，L1 只是把安全垫从 1.38 GiB 压到 0.70 GiB、放大了后果。

另记一笔（实验 B 首轮，非本轮门禁数据）：第一次起 exp B 时崩在 turboquant_attn.py:834 _continuation_prefill 的 k_flat = k_flat @ Pi_half → CUBLAS_STATUS_EXECUTION_FAILED（源 /tmp/expB.log）。重跑后崩点变成上面的 RPC 超时， 说明 262,144 这条路径在 prefill 阶段还有非确定性的失败面（两次崩点不同），不是单一 bug。

一条被推翻两次的口径

回滚

python3 /root/vllm_ctx_tune.py restore vllm-qwen38-27b-lora
# → deployment.apps/vllm-qwen38-27b-lora patched
# → restored ... to args snapshot from /srv/vllm-ctx-tune/vllm-qwen38-27b-lora.prev.json

回滚后复查：args[0] 与 /srv/backup-27b-mem-20260910/vllm-qwen38-27b-lora.yaml 里的 args[0] 逐字节相同（util 0.91 / max-model-len 131072 / max-num-seqs 64 / batched 16384）。 三条回滚路（本次用的是第一条）：

python3 vllm_ctx_tune.py restore vllm-qwen38-27b-lora        # 字节级回到 set 之前的 args
kubectl apply -f /srv/backup-27b-mem-20260910/vllm-qwen38-27b-lora.yaml
python3 vllm_ctx_tune.py set vllm-qwen38-27b-lora \
    --gpu-memory-utilization 0.91 --max-model-len 131072     # 反向再 set 一次

一条经验：restore 依赖 /srv/vllm-ctx-tune/<name>.prev.json， 而它只有一个坑位，每次 set 都覆盖。生产这次侥幸没受影响（它只被 set 过一次）， canary 的原始配置就丢了。

事后补齐的门禁：longprefill_probe.py

事故的直接教训是缺少一道运行期验收。补上的这道门：

python3 longprefill_probe.py <pod> 60000 80000 124000

• 构造含 7Q3Z needle 的长 prompt（目标 token 数按 ≈1.55x 放大，脚本打印真实 prompt_tokens）；
• 每步打印 PASS/FAIL、finish_reason、耗时，并在前后对比 pod 的 restartCount/ready；
• 判定：每步都 PASS（answer 含 7Q3Z）且 restartCount 不增加才算过。 HTTP_500 / answer 不含 needle / restartCount 增加，任一即为不合格 → 立刻回滚，不要「再试一次看看」。

已写进手册 §0 铁律 6 与 §5 Phase 1.5：动 util 必须跑它，启动日志三行全绿不算通过。

这次没做，以及为什么

一个提醒：先看需求，再看容量

改动前拉 9 个生产副本的 /metrics：只有 1 个副本在干活（累计 678 万 prompt token）， 其余 8 个 0 running，全集群 KV 池占用 0%。 所以这次升级不是为了当天的吞吐 —— 当前流量下它的收益 ≈ 0，是为将来的长上下文/高并发留余量。 而它把这个「为将来」的余量本身给吃掉了：省出来的 0.67 GiB 正是运行期需要的。 在 KV 池 0% 占用的现网，「给将来多留 176K token」的价值远小于「现在就把 93K 请求打崩」的代价。 → 要动容量/精度之前，先有流量指标或先有质量门禁，两者都没有就别动。