自研 LLM 推理平台 KV cache 显存雪崩 P99 飙 47 秒 + GPU OOM 18 次 9 天复盘:PagedAttention v2 + chunked prefill + FP8 量化 KV + PriorityScheduler + swap_space 64GB + 投机解码 + TokenQuotaLimiter 6 套修法 + 12 条 LLM 推理工程纪律

2026 年 4 月,我们一组生产环境的 LLM 推理服务(自研 Claude Sonnet 4.6 + Llama 3.3 70B 双模型 + vLLM 0.6 + Triton 25.03 + 64 张 H100,日均推理请求 4200 万、企业 RAG 文档问答场景、上下文窗口默认 32K)在一次"提升上下文窗口到 128K"的灰度发布后遭遇了显存雪崩:P99 latency 从 1.8 秒飙到 47 秒、KV cache OOM 触发模型重新加载 18 次、GPU 利用率从 78% 暴跌到 23%、87% 用户请求被排队限流、单 GPU 显存峰值从 64GB 飙到 79GB 触发 CUDA OOM。诡异之处在于推理 QPS 没增长,只是平均请求长度从 6.4K token 涨到 11.8K token。最终用 vLLM 内置 metrics + Triton perf_analyzer + nsys profile + nvidia-smi dmon 四路对账定位根因是:KV cache 显存占用与 context length 线性增长 + 没启用 PagedAttention v2 chunk prefill + 默认 block_size=16 在长上下文场景下碎片化严重 + Continuous batching scheduler 没限制最大 prefill token + vLLM swap_space 没配置 CPU offload + 没开启 quantized KV cache(FP8),这是教科书级的"LLM 推理 KV cache 治理失效 + Continuous batching 调度饥饿 + 显存碎片化"组合事故。修复路径是引入PagedAttention v2 + chunked prefill + block_size 调到 32 + max_num_batched_tokens=8192 + swap_space CPU offload + KV cache FP8 量化 + speculative decoding 6 套修法,P99 压回 2.4 秒,GPU 利用率回到 82%,显存峰值控制在 61GB,但也暴露出团队对 LLM 推理引擎内部机制 + KV cache 治理 + Continuous batching 调度的认知盲区。

这次 9 天复盘最大的收获不只是修了几个 vLLM 配置,而是重新认识了"LLM 推理服务的核心瓶颈不是算力而是 KV cache 显存"。Transformer 的注意力机制让 KV cache 占用随上下文长度线性增长(70B 模型每 1K token 约消耗 80MB 显存),在长上下文 + 多并发场景下显存比算力更早成为瓶颈,这与传统 CV / 小模型推理完全不同。这篇文章详细复盘事故时间线、5 个反模式、6 套修法、12 条 LLM 推理生产工程纪律,以及对 vLLM / TGI / Triton + TensorRT-LLM / SGLang 的横向对比与选型建议。

项目背景:企业级 LLM 推理服务规模

事故时间线:从"上下文 128K 灰度"到"显存雪崩"

反模式 1:KV cache 容量规划仅算"上下文 × 用户数"线性公式

# 出问题的容量规划代码(架构评审时使用)
def estimate_kv_cache_gb(
    model_size_b: int,        # 模型参数量(B)
    num_layers: int,           # 层数
    num_heads: int,            # 头数
    head_dim: int,             # 头维度
    context_length: int,       # 上下文长度(token)
    num_users: int,            # 并发用户数
    dtype_bytes: int = 2       # FP16 = 2 bytes
) -> float:
    # 每 token 每层 KV cache 大小
    kv_per_token = 2 * num_layers * num_heads * head_dim * dtype_bytes
    # 总 KV cache 大小
    total = kv_per_token * context_length * num_users
    return total / (1024 ** 3)

# Llama 3.3 70B: 80 层, 64 头, 128 头维度
# 假设并发 50 用户, 上下文 32K
size = estimate_kv_cache_gb(70, 80, 64, 128, 32 * 1024, 50)
# 输出: 40.96 GB,看起来 H100 80GB 完全够
# 实际:vLLM 调度 + 碎片化 + prefill 临时占用,实际占用 92%

这套公式是教科书级 KV cache 容量规划,但漏算了三大隐性占用:1) vLLM PagedAttention block_size=16 在长上下文下碎片化损失 20-30%;2) Prefill 阶段的临时 attention 中间结果占用(全 attention matrix);3) Continuous batching 的预留 buffer(用于动态 batch 拼接)。实际 KV cache 占用是理论值的 1.5-1.8 倍,而工程师们普遍只用理论值规划容量,事故必然发生。

反模式 2:vLLM 默认配置 + 长上下文不友好

# vLLM 出问题的启动配置
from vllm import LLM, SamplingParams

llm = LLM(
    model="meta-llama/Llama-3.3-70B-Instruct",
    tensor_parallel_size=8,           # 8 卡张量并行
    max_model_len=131072,             # 128K 上下文
    # 反模式:用默认 block_size=16,长上下文碎片化严重
    # block_size=16,
    # 反模式:max_num_batched_tokens 默认 None,
    # Continuous batching 无 prefill 限制,大请求阻塞小请求
    # max_num_batched_tokens=None,
    # 反模式:swap_space=4(GB),CPU offload 容量太小
    swap_space=4,
    # 反模式:gpu_memory_utilization=0.95,
    # 留给 vLLM 调度的余量太小,OOM 风险高
    gpu_memory_utilization=0.95,
    # 反模式:enable_chunked_prefill=False
    # 长 prefill 不分块,单次 attention 矩阵爆炸
    # enable_chunked_prefill=False,
)

这套默认配置在 32K 上下文下勉强能跑,但拉到 128K 立即崩盘:1) block_size=16 让长上下文需要 8192 个 block,page table 本身就消耗 1.2GB;2) max_num_batched_tokens 默认无限制,一个 128K 输入直接占满 prefill 槽位;3) swap_space=4GB CPU offload 在 70B 模型下完全不够(单 token KV ≈ 80KB,4GB 只能 offload 5 万 token);4) gpu_memory_utilization=0.95 太激进,vLLM 调度自身需要 5-10% 余量。这是 vLLM 用户最容易踩的"默认值陷阱"。

反模式 3:Continuous batching 调度无 QoS 优先级

# vLLM scheduler 出问题的调度逻辑(默认 FCFS)
# 所有请求按到达顺序进 waiting queue
# 一个 100K 输入请求会阻塞后面 100 个 1K 输入请求

# 实际生产场景的请求分布:
# - 90% 的请求是 1-4K 输入(普通问答)
# - 8% 的请求是 8-32K 输入(文档摘要)
# - 2% 的请求是 64-128K 输入(超长合同分析)

# 用 FCFS 调度的结果:
# - 一个 128K 请求 prefill 需要 30 秒
# - 这 30 秒内后面的 100 个 1K 请求全部排队
# - P99 被 2% 长请求拖垮

vLLM 默认 Continuous batching 是 FCFS(先到先服务),不考虑请求长度差异。实际生产中长请求占少数但占用大量 prefill 时间,FCFS 调度让长请求"堵在前面"拖垮整体延迟。这是 LLM 推理服务调度的核心痛点,与传统 Web API 调度模型完全不同。

反模式 4:无 KV cache 监控 + 显存指标盲区

# Prometheus + Grafana 监控(出问题版本)
# 只采集:
# - GPU 利用率(nvidia_smi_gpu_utilization)
# - GPU 显存使用(nvidia_smi_memory_used_bytes)
# - 推理 QPS(vllm_request_total)
# - 推理延迟(vllm_request_latency_seconds)

# 完全没采集 vLLM 内部 metrics:
# - vllm:gpu_cache_usage_perc(KV cache 占用百分比)
# - vllm:cpu_cache_usage_perc(CPU offload 占用百分比)
# - vllm:num_waiting_requests(等待中请求数)
# - vllm:num_running_requests(运行中请求数)
# - vllm:num_swapped_requests(已 swap 到 CPU 的请求数)
# - vllm:prompt_tokens_total(累计 prompt token 数)
# - vllm:time_to_first_token_seconds(TTFT)
# - vllm:inter_token_latency_seconds(token 间延迟 ITL)

LLM 推理服务的核心指标是KV cache 利用率 + TTFT(Time to First Token)+ ITL(Inter-Token Latency)+ swap 频次。如果只盯 GPU 利用率 / 显存占用,KV cache 占用从 60% 涨到 95% 的过程完全不可见,只能等到 OOM 才发现。事故后我们把 vLLM 内置的 50+ metrics 全部接入 Prometheus,看板从"GPU 利用率"为中心改成"KV cache 利用率"为中心。

反模式 5:无熔断降级 + 长请求直接打到 vLLM

# 网关层(出问题版本)
@app.post("/v1/chat/completions")
async def chat(req: ChatRequest):
    # 反模式:没限制 max_tokens / 上下文长度
    # 直接转发到 vLLM,任何长度都接受
    result = await vllm_client.generate(
        prompt=req.prompt,
        max_tokens=req.max_tokens,  # 客户随便传
        temperature=req.temperature,
    )
    return result

# 客户端可以传:
# - prompt: 100K token 的合同全文
# - max_tokens: 8192
# vLLM 接到这个请求后,KV cache 占用 = (100K + 8K) * 80KB = 8.6GB
# 单个请求就占满 1/9 的 H100 显存

缺乏网关层熔断让任何客户都能发起"巨型请求"打爆 vLLM,事故时一个客户上传 110K token 的合同分析请求,直接让 8 卡集群显存占用从 70% 飙到 96%,触发 OOM 链式反应。LLM 推理服务必须在网关层做"输入 token 限流 + max_tokens 限制 + 上下文长度 quota"三重保护。

问题本质:LLM KV cache 显存治理失效的因果链

修法 1:PagedAttention v2 + chunked prefill + 调优 block_size

# vLLM 修复后启动配置
from vllm import LLM, SamplingParams

llm = LLM(
    model="meta-llama/Llama-3.3-70B-Instruct",
    tensor_parallel_size=8,
    max_model_len=131072,

    # 修法 1.1: block_size 调大降低碎片化
    block_size=32,  # 16 -> 32,长上下文碎片化降低 40%

    # 修法 1.2: 启用 chunked prefill
    enable_chunked_prefill=True,
    max_num_batched_tokens=8192,  # 单次最多 8K token prefill
    # 长 prefill 自动拆分成多个 chunk,与 decoding 混合调度

    # 修法 1.3: gpu_memory_utilization 留余量
    gpu_memory_utilization=0.88,  # 0.95 -> 0.88

    # 修法 1.4: swap_space 显著扩大
    swap_space=32,  # 4 -> 32 GB CPU offload

    # 修法 1.5: 启用 PagedAttention v2
    # (vLLM 0.6+ 默认启用,显式确认)
    use_v2_block_manager=True,
)

# 验证 KV cache 容量
profiled_capacity = llm.llm_engine.model_executor.driver_worker.gpu_cache_capacity
print(f"KV cache 可容纳 token 数: {profiled_capacity}")
# 修复前: 65536(单卡可容纳)
# 修复后: 81920(碎片化减少 + util 留余 = 净增 25%)

chunked prefill 是 vLLM 0.6 引入的核心特性,把长 prefill 拆成多个 chunk 与 decoding 并发执行,避免长请求独占 GPU。block_size 调大降低 page table 开销 + 碎片化,但代价是大请求的最小调度粒度变大(可能浪费几个 block)。这套组合让 KV cache 实际可用容量提升 25%,长上下文场景的 P99 改善 60%。

修法 2:KV cache FP8 量化 + 显存压缩

# vLLM 启用 KV cache FP8 量化(0.6+)
llm = LLM(
    model="meta-llama/Llama-3.3-70B-Instruct",
    tensor_parallel_size=8,
    max_model_len=131072,
    block_size=32,
    enable_chunked_prefill=True,
    max_num_batched_tokens=8192,

    # 修法 2: KV cache 量化(FP16 -> FP8)
    kv_cache_dtype="fp8_e4m3",  # 显存减半!
    # 精度损失:perplexity 上升 < 0.5%,几乎不影响生成质量
    # 显存收益:每 token KV 从 80KB 降到 40KB
)

# 验证质量损失
# 用 lm-evaluation-harness 跑标准 benchmark
# MMLU: 76.2% -> 76.0%(下降 0.2%)
# GSM8K: 84.1% -> 83.9%(下降 0.2%)
# HumanEval: 67.5% -> 67.3%(下降 0.2%)
# 完全可接受

KV cache FP8 量化是 H100 时代的杀手锏特性:显存占用直接减半,精度损失极小。Llama 3.3 70B 在 128K 上下文下,FP16 KV cache 单 token 80KB,FP8 降到 40KB,8 卡集群可承载的总 token 量从 65 万翻到 130 万,QPS 提升 60%。但要注意:1) 需要 H100 / H800(Ampere 不支持原生 FP8);2) 模型权重仍是 FP16 / BF16,只是 KV cache 量化;3) speculative decoding 配合更佳。

修法 3:Continuous batching 加 QoS 优先级

# 自定义 vLLM scheduler(基于 vLLM 0.6 API)
from vllm.core.scheduler import Scheduler, SchedulerOutputs
from vllm.sequence import SequenceGroup

class PriorityScheduler(Scheduler):
    def _schedule(self) -> SchedulerOutputs:
        # 按请求长度 + 等待时间双因子排序
        # 短请求优先 + 长等待优先
        def priority_key(seq_group: SequenceGroup):
            prompt_len = len(seq_group.get_seqs()[0].prompt_token_ids)
            wait_time = time.time() - seq_group.arrival_time
            # 短请求 + 长等待 → 高优先级
            return (prompt_len / 1000) - (wait_time / 10)

        self.waiting = sorted(self.waiting, key=priority_key)
        return super()._schedule()

# 启动 vLLM 时注入自定义 scheduler
from vllm import AsyncLLMEngine
from vllm.engine.arg_utils import AsyncEngineArgs

engine_args = AsyncEngineArgs(
    model="meta-llama/Llama-3.3-70B-Instruct",
    tensor_parallel_size=8,
    scheduler_cls=PriorityScheduler,  # 注入
    # ...其他参数
)
engine = AsyncLLMEngine.from_engine_args(engine_args)

QoS 调度的核心是"短请求优先 + 长请求公平饥饿避免"。事故前 FCFS 调度让 2% 长请求拖垮 90% 短请求的 P99,改成"按请求长度倒序 + 长等待补偿"后,短请求 P99 从 12 秒降到 1.8 秒,长请求 P99 从 47 秒涨到 65 秒(可接受,长请求本来就是低延迟敏感度场景)。

修法 4:swap_space CPU offload + 智能换出

# vLLM swap_space 配置 + 主机内存预留
llm = LLM(
    # ...
    swap_space=64,  # 4 -> 64 GB,主机内存预留 80GB
)

# 配合主机层的内存监控
import psutil

def monitor_host_memory():
    while True:
        mem = psutil.virtual_memory()
        if mem.available < 8 * 1024 * 1024 * 1024:  # 主机内存 < 8GB
            # 告警 + 降低 vLLM swap 阈值
            logger.warning(f"Host memory low: {mem.available / 1e9:.1f}GB")
        time.sleep(10)

# swap 行为分析
# - vLLM 优先 swap "最近没被 decode 的 sequence group"
# - swap 触发条件:GPU KV cache 占用 > 95%
# - swap 回 GPU 触发条件:被重新调度 decode
# - swap I/O 速度:PCIe Gen4 ~ 32 GB/s,单次 70B 模型 swap ~ 0.3 秒

swap_space 是 vLLM 的"显存安全阀",当 KV cache 占满时把闲置 sequence group 换出到 CPU 内存,避免 OOM。配置 64GB swap + 80GB 主机预留可承载额外 80 万 token 的 KV cache(等于 8 卡 H100 集群容量的 60%)。代价是 swap I/O 引入 0.3-1 秒延迟,但比 OOM 重启模型(60 秒)好得多。

修法 5:网关层 token quota + 输入长度限流

# 网关层熔断 + token quota(基于 token bucket)
import asyncio
from collections import defaultdict
import time

class TokenQuotaLimiter:
    def __init__(self):
        # 每用户每分钟 token quota
        self.user_quota = defaultdict(lambda: {
            "tokens_used": 0,
            "window_start": time.time(),
            "max_per_min": 50000,  # 5 万 token/分钟
        })

    async def check(self, user_id: str, input_tokens: int, max_output: int):
        q = self.user_quota[user_id]
        now = time.time()
        # 窗口滑动
        if now - q["window_start"] >= 60:
            q["tokens_used"] = 0
            q["window_start"] = now

        # 单次请求上限
        total = input_tokens + max_output
        if total > 16384:  # 单次最多 16K token
            raise HTTPException(429, f"Request too long: {total} > 16384")

        # 用户分钟级 quota
        if q["tokens_used"] + total > q["max_per_min"]:
            raise HTTPException(429, "Quota exceeded")

        q["tokens_used"] += total

@app.post("/v1/chat/completions")
async def chat(req: ChatRequest, user_id: str = Depends(get_user)):
    # 估算输入 token 数
    input_tokens = await count_tokens(req.prompt, model=req.model)

    # 熔断检查
    await quota_limiter.check(user_id, input_tokens, req.max_tokens or 1024)

    # 转发到 vLLM
    return await vllm_client.generate(...)

这套熔断器的核心:1) 单次请求总 token <= 16K(input + max_output);2) 用户级分钟 quota 5 万 token;3) tier 级 quota 区分企业版/免费版;4) 熔断器优先于 vLLM 调度,避免巨型请求打入推理引擎。事故后这套熔断挡住了 8 次类似的"100K 合同分析"请求,只有真正付费的企业客户走专用集群。

修法 6:Speculative decoding + 推理加速

# vLLM speculative decoding 配置
llm = LLM(
    model="meta-llama/Llama-3.3-70B-Instruct",
    tensor_parallel_size=8,
    max_model_len=131072,
    block_size=32,
    enable_chunked_prefill=True,
    max_num_batched_tokens=8192,
    kv_cache_dtype="fp8_e4m3",
    swap_space=64,

    # 修法 6: speculative decoding(EAGLE 2 + Llama 3.2 1B draft)
    speculative_model="meta-llama/Llama-3.2-1B-Instruct",
    num_speculative_tokens=5,  # draft 模型预测 5 个 token
    use_v2_block_manager=True,
    # 1B draft 模型预测,70B target 模型验证
    # accept rate 70-85%,实际加速 1.8-2.5x
)

Speculative decoding 用"小模型预测 + 大模型并行验证"提速,1B 模型预测 5 个 token,70B 模型一次验证 5 个,accept rate 70-85% 时实际生成速度提升 2 倍。代价是显存多占 5-8GB(draft 模型加载)+ 调度复杂度上升,但在 ITL 敏感的对话场景下收益显著。我们的智能客服场景 ITL 从 35ms 降到 16ms,用户体验明显改善。

性能基准:6 套修法效果对比

我们立的 12 条 LLM 推理生产工程纪律

1. KV cache 容量规划留 30% 余量:理论值 × 1.5 才是实际容量。
2. block_size 按上下文长度调:32K 用 16、128K 用 32、256K 用 64。
3. chunked prefill 长上下文必开:max_num_batched_tokens 设为 GPU 算力上限(H100 ~ 8K)。
4. KV cache FP8 量化默认启用:H100 / H800 必上,精度损失 < 0.5%。
5. Continuous batching 加 QoS 优先级:短请求优先 + 长请求公平。
6. swap_space CPU offload 必配:推荐 4-8 倍单卡 KV cache 容量。
7. 网关层 token quota 三层:单请求 + 用户分钟 + tier 限速。
8. vLLM 内置 metrics 全采集:KV cache 利用率为核心看板。
9. 巨型请求隔离专用集群:> 32K 输入路由到专用集群,与常规流量隔离。
10. Speculative decoding 对话场景必开:ITL 减半,显存代价小。
11. gpu_memory_utilization 不超 0.9:留 10%+ 给调度器避免 OOM。
12. 灰度发布从 1% 开始:上下文窗口调整这种 KV cache 影响大的变更必须细粒度灰度。

引申一:vLLM vs TGI vs Triton+TensorRT-LLM vs SGLang 选型矩阵

选型建议:通用场景 + 模型多样 + 中等团队 → vLLM;HuggingFace 生态深度集成 → TGI;NVIDIA 硬件极致性能 + 有 ML Infra 团队 → Triton+TensorRT-LLM;RAG / Agent / 复杂 prompt 共享前缀 → SGLang。我们的主推理用 vLLM(灵活)+ RAG 子系统用 SGLang(共享前缀 RadixAttention 加速 4-7 倍)+ 内部高级用户专用集群用 Triton+TRT-LLM(极致延迟),分场景选型。

引申二:vLLM PagedAttention 原理深度

PagedAttention 是 vLLM 的核心创新,灵感来自操作系统的虚拟内存分页:1) KV cache 按固定 block(默认 16 token)分块存储,而非传统 sequence-contiguous 存储;2) 每个 sequence 维护一个 block table 映射 logical block → physical block;3) 不同 sequence 可以共享 physical block(prompt 前缀共享);4) 内存碎片化降低 60-80%;5) 支持动态 grow / shrink。理解 PagedAttention 是用好 vLLM 的前提,推荐精读原论文 SOSP 2023 "Efficient Memory Management for Large Language Model Serving with PagedAttention"。

引申三:KV cache 量化的 FP8 / INT4 / INT8 对比

量化选型:H100 / H800 优选 FP8(原生支持,精度最优);A100 / A800 用 INT8;消费级 GPU 用 INT4(精度有损但能跑)。我们的生产 H100 集群全部启用 FP8 KV cache,精度几乎无感,显存收益巨大。

引申四:LLM 推理硬件选型 - H100 / H200 / B200 对比

2026 年硬件选型趋势:新建集群直接上 B200(性能 + 显存双优);现有 H100 集群升级 H200 提升 long context 能力;A100 集群转测试 + 中小模型推理。我们 2026 Q2 上线一个 32 卡 B200 集群,Llama 3.3 70B P99 延迟比 H100 集群快 2.3 倍,长上下文承载能力提升 2.4 倍,虽然单卡贵 2 倍,但 TCO 反而降低 40%。

引申五:LLM 推理与 RAG 系统的协同优化

RAG 系统对 LLM 推理有独特优化空间:1) 检索得到的文档片段在多次问答中复用,用 SGLang RadixAttention 共享 prefix KV cache,前缀计算成本均摊;2) 系统 prompt 固定不变,用 prefix caching 跨请求复用;3) 多轮对话的历史也可以共享 prefix;4) 模型微调时把高频系统 prompt 做 LoRA prefix tuning,推理时直接用 tuned prefix。我们的 RAG 系统通过 SGLang + 系统 prompt prefix caching,平均推理成本下降 65%,QPS 提升 3 倍。

引申六:多模型推理路由 + 成本优化

2026 年企业 LLM 应用普遍采用多模型路由:1) 简单问答用 7B 小模型(成本 1/10);2) 复杂推理用 70B 中模型;3) 创作 / 代码生成用 Claude / GPT 等顶级 API;4) 用 router model(0.5B 分类器)判断请求复杂度自动路由;5) 根据 user tier 限制可用模型层级。我们的路由系统让总推理成本下降 72%,而用户感知到的质量基本无降级,这是 LLM 时代的关键工程能力。

引申七:LLM 推理的可观测性体系建设

LLM 推理可观测性的核心三层:1) 基础设施层:GPU 利用率 + 显存 + 网络 + 磁盘 IO;2) 推理引擎层:KV cache 利用率 + TTFT + ITL + queue depth + swap 频次;3) 业务层:请求成功率 + tier 级 latency + token 消耗 + 用户满意度。我们用 Prometheus + Grafana + Langfuse 构建三层看板,SRE oncall 一眼看清"是 GPU 卡瓶颈、是 vLLM 调度饥饿、还是用户行为变化",定位时间从 2 小时压到 15 分钟。

引申八:Triton Inference Server 与 vLLM 的集成

Triton 是 NVIDIA 的通用推理服务器,vLLM 提供模型推理引擎,二者集成方式:1) Triton vLLM backend(官方支持,Triton 调度 + vLLM 推理);2) 用 Triton ensemble 编排 vLLM + tokenizer + post-processing;3) Triton 的 dynamic batching 与 vLLM continuous batching 互补;4) Triton 的 model versioning 与 vLLM 模型热加载结合;5) Triton 的 metrics + Prometheus 集成统一观测。我们的生产架构是 Triton 做 API 网关 + 编排 + vLLM backend 做推理,既享受 Triton 生态又获得 vLLM 性能。

引申九:LLM 推理的灾备多活方案

LLM 推理灾备的核心思路:1) 模型权重存对象存储(S3 / OSS),集群启动时拉取,避免本地存储单点;2) 多 region 各部署一套 vLLM 集群,DNS / Service Mesh 路由按地理 + 健康度;3) 主集群故障时自动切换到备集群,RTO < 5 分钟;4) 关键业务保留 fallback 到第三方 API(Claude / GPT)的能力;5) 用 Ray Serve / KServe 做跨集群编排。我们经历过 1 次 region 整体故障(交换机问题 47 分钟),fallback 到第三方 API + 自动切换备 region,业务可用性保持 99.9%。

引申十:LLM 推理成本与企业 ROI

2026 年企业 LLM 推理成本结构:1) H100 集群 TCO 约 $0.0008 / 1K token(70B FP8 推理);2) 第三方 API 约 $0.015 / 1K token(Claude Sonnet);3) 中小规模(< 1M token/day)用 API 更划算;4) 大规模(> 100M token/day)自建 ROI 6-12 个月回本;5) 关键考量:数据合规 + 延迟 SLA + 模型定制需求。我们自建集群每月节省 API 调用成本 230 万 USD,但额外投入 40 万 USD/月运维 + 折旧,净收益 190 万 USD/月,这是大规模 LLM 应用的核心 ROI 模型。

引申十一:LLM 推理工程师的成长路径

LLM 推理工程师的成长可以分四阶段:1) 入门:理解 Transformer 架构 + KV cache 机制 + vLLM 基本使用;2) 进阶:掌握 PagedAttention + chunked prefill + 量化 + speculative decoding;3) 高级:能调优 Continuous batching scheduler + 设计多模型路由 + 解决长上下文问题;4) 专家:能主导 LLM Infrastructure 建设 + 自研推理引擎优化 + 跨集群弹性架构。从入门到专家通常需要 18-30 个月,LLM 推理工程是 2026 年最稀缺也最有前景的工程方向之一。

引申十二:LLM 推理与 Agent 系统的特殊挑战

Agent 系统对 LLM 推理有独特挑战:1) 多次推理调用(plan + act + reflect),每次都是新的 prompt,前缀缓存难;2) Tool calling 的 structured output 对 sampling 要求高;3) 长 trajectory 累积上下文,容易触发 KV cache OOM;4) Agent 失败重试导致推理负载放大 3-10 倍;5) 高并发 Agent 任务对 scheduler 公平性要求高。我们的 Agent 平台用 SGLang(共享 system prompt 前缀)+ 专用集群隔离 + per-Agent quota 限流,稳定承载 5000 并发 Agent 任务。

引申十三:LLM 推理 + 边缘部署的实践

2026 年边缘部署的 LLM 推理日益成熟:1) 端侧 7B-14B 模型(MLC-LLM / llama.cpp)直接跑在 M3 / 高通 8 Gen 4;2) 边缘节点 70B 模型用 vLLM + 多卡 RTX 4090;3) 端云协同 - 简单请求端侧、复杂请求云端;4) 网络受限场景(车载 / 工业)端侧推理必备;5) 隐私敏感场景(医疗 / 法律)端侧推理是合规要求。我们的智能客服移动 App 端侧跑 Phi-3 Mini 4B 处理 70% 简单问答,云端只处理复杂查询,带宽节省 80%、隐私合规度大幅提升。

决策树:LLM 推理引擎与硬件选型路径

引申十四:LLM 推理工程师面对生产事故的快速诊断框架

当 LLM 推理服务出现 latency 飙升 / OOM / 吞吐下降时,建议按以下顺序排查:第一步看 vLLM gpu_cache_usage_perc 是否 > 90%;第二步看 num_waiting_requests 队列堆积情况;第三步看 nvidia-smi 显存 + GPU 利用率;第四步看 num_swapped_requests 是否频繁 swap;第五步用 nsys profile 抓 GPU kernel 执行。这套五步法在过去 1 年帮我们定位过 23 次类似事故,平均定位时间从 4 小时压缩到 30 分钟。"vLLM 内部 metrics + GPU 指标双视角"是 LLM 推理工程师的核心能力,缺一不可。

引申十五:LLM 推理与 Continuous batching 调度的深度优化

Continuous batching 的核心是"动态合并多个请求的 token 到同一个 batch,GPU 算力共享",但默认实现有几个深度优化点:1) prefill 与 decode 解耦调度(disaggregated serving);2) 跨节点 KV cache 共享(prefill 节点 + decode 节点物理分离);3) Continuous batching 的 attention 计算用 FlashAttention 3 加速;4) speculative decoding 与 batching 的兼容性优化;5) Multi-LoRA serving 时 LoRA 适配器的高效切换。这些优化是 vLLM 0.7 / 1.0 路线图的核心方向,值得 LLM Infra 工程师深度关注。我们正在试点 disaggregated serving,初步数据显示 prefill 与 decode 解耦后整体 throughput 提升 2.3 倍,这是 LLM 推理工程未来 2-3 年的最重要演进方向。

引申十六:开源 LLM 推理生态全景

2026 年开源 LLM 推理生态全景:1) 推理引擎:vLLM / TGI / SGLang / LightLLM / DeepSpeed-Inference;2) 编译优化:TensorRT-LLM / MLC-LLM / TVM-LLM;3) 服务编排:Ray Serve / KServe / BentoML / Triton;4) 监控观测:Langfuse / Phoenix / Helicone / OpenLLMetry;5) 评估测试:lm-evaluation-harness / opencompass / lighteval;6) 路由调度:LiteLLM / OpenRouter / Vellum。每位 LLM 推理工程师都应该至少深度熟练 3-4 个,并对其他工具保持关注。开源生态演化极快,2026 年的事实标准与 2024 年差异巨大,需要持续学习。

引申十七:LLM 推理工程师的工具栈与高效工作流

资深 LLM 推理工程师的标配工具栈:1) nvidia-smi + nvtop + nvidia-ml-py(GPU 监控基础);2) vLLM CLI + vllm.entrypoints.openai.api_server;3) nsight systems / nsight compute(GPU profile);4) lm-evaluation-harness(质量评估);5) vllm-benchmark(性能压测);6) Triton perf_analyzer(推理压测);7) Langfuse / Helicone(LLM 应用追踪);8) Pyroscope eBPF(应用级 profile);9) Prometheus + Grafana(系统监控);10) Weights & Biases(模型实验跟踪)。这套工具栈在过去 2 年帮我们快速优化过几十次推理性能,每位工程师都值得花一个月时间逐一上手,把工具熟练度提升到肌肉记忆。

引申十八:LLM 推理社区演进的关键节点观察

LLM 推理生态的关键节点:vLLM 0.3 引入 PagedAttention、vLLM 0.5 支持 multi-LoRA、vLLM 0.6 支持 chunked prefill + FP8 KV cache、SGLang 引入 RadixAttention、TensorRT-LLM 0.10 支持 in-flight batching、即将到来的 vLLM 1.0 计划支持 disaggregated serving + multi-modal native。基本每 3-6 个月都有重大新特性能从根本上提升推理效率,建议团队保持月度评估 + 季度灰度升级,这是 LLM 推理工程师对自己技术栈持续投入与对企业 AI 基础设施长期负责的基本态度。

总结

这次 9 天 LLM KV cache 雪崩复盘,核心教训是"LLM 推理服务的工程瓶颈是显存治理,不是模型质量"。Transformer 的 KV cache 随上下文长度线性增长,在长上下文 + 多并发场景下显存比算力先成为瓶颈,这要求 LLM 推理工程师必须深入理解 KV cache 机制 + PagedAttention 原理 + chunked prefill + 量化 + swap_space 等推理引擎内部细节,而不是把 vLLM 当黑盒。

更要紧的是,我们要意识到LLM 推理工程是一个独立的工程子领域,与传统 Web API 工程完全不同。传统 API 的瓶颈是网络 + DB IO,LLM 推理的瓶颈是 GPU 显存 + KV cache + Continuous batching 调度;传统 API 的请求等价(几 KB),LLM 推理的请求差异 100 倍(1K-128K token);传统 API 的优化是连接池 + 缓存,LLM 推理的优化是 PagedAttention + chunked prefill + speculative decoding。这种 paradigm shift 要求工程师重新建立知识体系,这是 LLM 时代工程师必须主动迎接的挑战。

最后想说,LLM 推理工程走到 2026 年正在成为 AI 基础设施的核心方向,在企业 RAG + 智能客服 + 代码助手 + Agent 系统四大场景占据主导地位。每一位 ML Infra / Cloud Native / SRE 工程师都值得深入理解 Transformer 推理机制 + vLLM 内部架构 + KV cache 治理 + Continuous batching 调度 + 多模型路由 + 边缘端云协同,这是工程师在 AI 浪潮中保持核心竞争力的关键路径,也是企业级 LLM 应用长期高效运行的工程根基。愿每一位 LLM 推理工程师都能在 GPU 与 Transformer 共舞的时代找到属于自己的工程美学与系统思维,把每一段 vLLM 配置都打磨成既高吞吐又可观测的现代 AI 基础设施作品,这是技术人对自己职业生涯的真正负责与对 LLM 工程哲学的深沉热爱与执着信念,也是我们在 AI 浪潮与算力洪流中保持清醒与定力的内在底色,值得每一位工程师用持续的学习与生产实战去守护这份对工程质量的执着追求,在每一次 KV cache 配置 + chunked prefill 调优 + speculative decoding 灰度中都见证自己技术能力的不断成长与对系统稳定性的真正用心。

—— 别看了 · 2026