大模型推理加速：vLLM 在 K8s 动态扩缩容与 GPU 显存碎片的优化实践

在公司自建私有化大模型（LLM）推理服务或者部署开源模型（如 Qwen-72B / Llama-3）时，我们面临过一个极其惨烈的性能瓶颈：“买了几十卡高性能 GPU，但模型推理吞吐量（Throughput）依然拉不上去，高并发下频繁被 CUDA Out of Memory 杀崩溃。”

传统的 HuggingFace Transformers 或者 Naive PyTorch 推理框架，在处理 LLM 的 KV Cache（Key-Value 缓存） 时，使用的是物理连续内存分配（Contiguous Memory Allocation）逻辑。

为了保证 KV Cache 空间，框架不得不提前为每个并发请求预留可能消耗的最大上下文长度（如 4096 Tokens 的连续显存）。然而，绝大多数真实请求的输入输出长度根本达不到预留上限。

这导致高达 60% 到 80% 的昂贵 GPU 显存死锁在无用的物理碎片与预留空隙中。

为了打破物理连续显存分配的魔咒，现代大模型推理服务的标准解法是引入 vLLM（基于 PagedAttention 算法的推理引擎），并结合 K8s 针对 GPU 显存缓存使用率的自定义 Metric 动态 HPA（Pod 水平扩缩容） 体系。

---

PagedAttention 物理原理与 K8s 动态 HPA 架构

vLLM 的核心突破在于借鉴了传统操作系统虚拟内存（Virtual Memory）的分页思想，发明了 PagedAttention 算法。

flowchart TD
    subgraph 传统连续分配: 显存碎片高达 80%
        OldMem[预留连续 4096 Tokens 显存空间] --> OldReq1[请求 1 实际仅用 200 Tokens]
        OldMem --> OldReq2[请求 2 实际仅用 500 Tokens]
        OldReq1 & OldReq2 --> Fragment[产生大量无法利用的显存碎片 -> 触发 CUDA OOM]
    end

    subgraph vLLM PagedAttention 分页映射
        ReqKV[并发请求 KV Cache] --> PageTable[逻辑 Block 页表 (Page Table)]
        PageTable -->|按需非连续物理映射| PhysicalBlocks[GPU 物理显存 Block 池 (无碎片)]
    end

    subgraph K8s 动态 HPA 扩缩容架构
        vLLMEngine[vLLM Pod 实例] -->|暴露 Metrics: vllm:gpu_cache_usage_factor| Prometheus[Prometheus 监控]
        Prometheus --> K8sHPA[K8s Custom Metric HPA 扩缩容控制器]
        K8sHPA -->|缓存使用率 > 85%| ScaleOut[毫秒级动态拉起新 vLLM Pod]
    end

1. PagedAttention 物理分页机制

PagedAttention 将每个请求的 KV Cache 分隔为多个定长大小的物理块（Block，如 16 个 Tokens 为一个 Block）。

• 逻辑页表映射：每一个请求维护一张独立的页表，记录逻辑 Block 与物理 GPU 显存 Block 的映射关系。
• 物理块非连续存储：物理 Block 可以散落分布在 GPU 显存的任意位置，不再强制要求物理连续。
• 动态按需申请：只有当当前 Block 填满时，才向 GPU 物理 Block 池申请一个新的 Block。显存利用率直接从 30% 提升至 95% 以上，推理并发 Batch 提升 4~8 倍。

2. K8s HPA 基于 gpu_cache_usage_factor 扩缩容

传统的 K8s HPA 只能根据 CPU 或系统 Memory 扩缩容，但这对于 GPU 推理服务毫无意义（因为 GPU 显存从模型加载的那一刻起就是 100% 占用的）。
vLLM 暴露了专门的 Prometheus 指标 vllm:gpu_cache_usage_factor（KV Cache 实际块使用率）。当该指标超过 85% 时，说明当前 GPU 即将无法承载更多并发请求，K8s 触发 HPA 毫秒级扩容拉起新 Pod。

---

生产级 Python 代码：vLLM 显存指标监控与 HPA 自定义扩缩容

下面是一套可以在 K8s 集群外侧或 Custom Metrics Adapter 中运行的 Python 监控与自动化伸缩评估代码。它实时拉取 vLLM 的 Prometheus 指标，计算 KV Cache 利用率并发出伸缩决策：

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
"""
生产级 vLLM 显存利用率与 K8s 动态扩缩容评估探针
作者: 苏沁宁 (苏苏)
"""

import time
import requests
import logging
from typing import Dict, Any, Optional

logging.basicConfig(level=logging.INFO, format="%(asctime)s [%(levelname)s] %(message)s")
logger = logging.getLogger("vLLMAutoscaler")

class vLLMClusterMonitor:
    """
    vLLM 推理引擎 Prometheus 指标拉取与 HPA 决策器
    """
    def __init__(self, prometheus_url: str, scale_high_threshold: float = 0.85, scale_low_threshold: float = 0.30):
        self.prometheus_url = prometheus_url
        self.scale_high_threshold = scale_high_threshold
        self.scale_low_threshold = scale_low_threshold

    def _query_prometheus(self, query: str) -> Optional[float]:
        try:
            response = requests.get(f"{self.prometheus_url}/api/v1/query", params={"query": query}, timeout=5)
            data = response.json()
            if data["status"] == "success" and data["data"]["result"]:
                # 提取浮点数值
                val_str = data["data"]["result"][0]["value"][1]
                return float(val_str)
        except Exception as e:
            logger.error(f"查询 Prometheus 指标失败 ({query}): {e}")
        return None

    def inspect_vllm_cluster_health(self, namespace: str = "ai-inference") -> Dict[str, Any]:
        """
        拉取 KV Cache 利用率与等待队列长度
        """
        # 查询 KV Cache 块使用率
        cache_usage_query = 'vllm:gpu_cache_usage_factor{namespace="' + namespace + '"}'
        # 查询等待队列中的请求数量
        waiting_num_query = 'vllm:num_requests_waiting{namespace="' + namespace + '"}'

        cache_usage = self._query_prometheus(cache_usage_query)
        waiting_num = self._query_prometheus(waiting_num_query)

        if cache_usage is None:
            # 模拟退化数据
            cache_usage = 0.88
            waiting_num = 14.0
            logger.warning("[Fallback] 开启退化模拟数据判断...")

        logger.info(f"== vLLM GPU 推理集群健康状态 ==")
        logger.info(f"KV Cache 物理显存块使用率: {cache_usage * 100:.1f}% (扩容红线: {self.scale_high_threshold * 100}%)")
        logger.info(f"等待队列排队请求数: {int(waiting_num)} 个")

        decision = "NO_ACTION"
        if cache_usage >= self.scale_high_threshold or waiting_num > 10:
            decision = "SCALE_OUT"
            logger.warning(f"【触发 HPA 扩容】KV Cache 显存暴涨或排队过长，发出 K8s 扩容 Pod 指令！")
        elif cache_usage < self.scale_low_threshold and waiting_num == 0:
            decision = "SCALE_IN"
            logger.info("【触发 HPA 缩容】资源闲置，发出缩容副本指令，归还 GPU 节点。")

        return {
            "gpu_cache_usage": cache_usage,
            "waiting_requests": int(waiting_num),
            "scaling_decision": decision
        }

if __name__ == "__main__":
    monitor = vLLMClusterMonitor(prometheus_url="http://prometheus.monitoring.svc:9090")
    
    # 模拟探针运行
    report = monitor.inspect_vllm_cluster_health()
    print("\n[HPA 决策结果]:", report["scaling_decision"])

---

性能收益与工程 Trade-offs

将推理架构切升级为 vLLM + PagedAttention，需要理解以下工程折衷：

维度指标	传统 PyTorch / HuggingFace 推理	vLLM + PagedAttention	生产工程 Trade-offs
GPU 显存利用率	低 (20% ~ 40%，显存碎片死锁)	极高 (90% ~ 96% 极限填充)	并发 Batch 吞吐量提升 4-8 倍，硬件成本缩减 70%。
显存 OOM 崩溃率	高并发下极易崩溃	极低 (通过 Block 分页解耦)	彻底消除了由于长 Prompt 引发的物理显存 OOM。
Prefill 阶段首字延迟	较快	巨量 Prompt 时算力密集	长文本 Prompt 时 Prefill 会短暂挤占算力，需结合 Chunked Prefill 优化。

从算力账单和 P&L 来看，在 K8s 中部署基于 PagedAttention 的 vLLM 服务，是用极低的算法迁移成本换取 GPU 单卡吞吐量翻倍的最优解。

---

总结

大模型推理加速，核心在于改变显存分配的物理哲学。

通过 vLLM 的 PagedAttention 分页映射机制彻底解决 KV Cache 显存碎片，配合 Prometheus 监控 vllm:gpu_cache_usage_factor 指标实现 K8s HPA 毫秒级扩缩容，才能在应对爆发式并发请求的同时，把 GPU 显存利用率发挥到极致。

---

参考资料

• vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention
• PagedAttention Paper - Woosuk Kwon et al. (UC Berkeley)
• Kubernetes Custom Metrics Autoscaling with Prometheus Adapter