大模型部署架构：从推理引擎到弹性扩缩容的工程实践

一、大模型推理服务的部署困局：GPU 昂贵与流量波动的尖锐矛盾

大模型推理服务的部署成本堪称后端架构中最昂贵的挑战之一。以 Llama-70B 为例，FP16 精度下需要 4 张 A100-80GB 显卡才能加载模型权重，单台推理服务器月成本超过 5 万元。然而推理请求的流量分布极不均匀——白天高峰 QPS 可达夜间的 10 倍以上，且对话类请求的输入输出 token 长度差异巨大，导致单次推理耗时从百毫秒到数十秒不等。

某 AI 平台在部署大模型对话服务后，面临两难境地：按峰值配置 GPU 资源，低峰期利用率不足 15%，资源浪费严重；按均值配置，高峰期请求排队超时，用户体验急剧恶化。更棘手的是，模型冷启动加载权重需要 30-60 秒，传统基于 CPU 利用率的 HPA 机制根本来不及响应流量波动。

二、大模型推理部署的核心机制：连续批处理与显存管理

大模型推理的性能瓶颈不在计算而在显存带宽。理解这一点，才能设计出合理的部署架构。

flowchart TB
    A[推理请求到达] --> B[请求队列]
    B --> C{连续批处理调度器}

    subgraph 推理引擎核心
        C --> D[Prefill 阶段：处理输入 token]
        D --> E[Decode 阶段：逐 token 生成]
        E --> F{生成完成?}
        F -->|否| G[加入下一批次继续 Decode]
        F -->|是| H[返回结果]
    end

    subgraph 显存管理
        I[KV Cache 池] --> J[PagedAttention]
        J --> K[显存页表映射]
        K --> L[物理显存块]
    end

    D --> I
    E --> I
    G --> C

    subgraph 弹性调度
        M[指标采集] --> N[GPU 利用率 + 队列深度]
        N --> O{扩缩容决策}
        O -->|扩容| P[预热池取实例]
        O -->|缩容| Q[实例回收到预热池]
    end

    H --> M
    B --> M

连续批处理（Continuous Batching） 是推理引擎的核心优化。传统静态批处理必须等批次中所有请求完成后才能处理下一批，长请求会拖慢整个批次。连续批处理允许已完成的请求立即退出、新请求动态加入，将 GPU 利用率从 30%-40% 提升到 80% 以上。

PagedAttention 解决了 KV Cache 的显存碎片问题。KV Cache 是推理过程中存储注意力键值对的显存区域，传统实现需要预分配连续显存，导致严重的显存碎片和浪费。PagedAttention 借鉴操作系统的虚拟内存分页机制，将 KV Cache 划分为固定大小的页，按需分配物理显存块，显存利用率提升 40% 以上。

预热池机制 是解决冷启动延迟的关键。预先加载模型权重的实例池保持在待命状态，流量增长时直接从预热池取出实例，将扩容响应时间从 60 秒压缩到 5 秒以内。

三、生产级大模型部署架构的实现

3.1 基于 vLLM 的推理服务部署

"""
大模型推理服务启动配置
为什么选择 vLLM 而非原生 Transformers？
vLLM 内置 PagedAttention 和连续批处理，
单卡吞吐量比 Transformers 提升 3-5 倍，
且兼容 OpenAI API 协议，降低客户端接入成本
"""
from vllm import LLM, SamplingParams
from vllm.entrypoints.openai.api_server import run_server

# 推理引擎配置
ENGINE_CONFIG = {
    "model": "/models/llama-70b-chat",
    "tensor_parallel_size": 4,      # 4 卡并行推理
    "gpu_memory_utilization": 0.90,  # 预留 10% 显存给系统开销
    # 为什么只用到 90%？CUDA 内核和框架本身需要额外显存，
    # 超配会导致 OOM，这是生产环境常见的踩坑点
    "max_model_len": 4096,          # 最大序列长度
    "max_num_seqs": 256,            # 最大并发序列数
    "enable_prefix_caching": True,   # 开启前缀缓存
    # 为什么开启前缀缓存？对话场景中系统提示词重复率高，
    # 缓存共享前缀的 KV Cache 可减少 30% 的 Prefill 计算
}

# 采样参数配置
SAMPLING_CONFIG = SamplingParams(
    temperature=0.7,
    top_p=0.9,
    max_tokens=2048,
    # 为什么限制 max_tokens？防止单次推理占用过长时间，
    # 影响其他请求的调度公平性
)

3.2 预热池管理器

"""
推理实例预热池——解决模型冷启动延迟
为什么需要预热池而非依赖 K8s 原生 HPA？
模型权重加载需要 30-60 秒，原生 HPA 从触发扩容到
实例就绪至少需要 2 分钟，无法应对秒级流量波动
"""
import threading
import time
from dataclasses import dataclass
from typing import Optional

@dataclass
class WarmInstance:
    """预热完成的推理实例"""
    pod_name: str
    endpoint: str
    ready_time: float
    last_health_check: float

class WarmPoolManager:
    """预热池管理器"""

    def __init__(self, min_warm: int = 2, max_warm: int = 5,
                 health_check_interval: int = 10):
        self.min_warm = min_warm       # 最少保持的预热实例数
        self.max_warm = max_warm       # 最多预热实例数（成本约束）
        self.health_check_interval = health_check_interval
        self.pool: list[WarmInstance] = []
        self.lock = threading.Lock()

    def acquire(self) -> Optional[WarmInstance]:
        """从预热池获取一个就绪实例"""
        with self.lock:
            if self.pool:
                instance = self.pool.pop(0)
                # 异步补充预热实例
                self._replenish_async()
                return instance
            return None
        # 池为空时返回 None，调用方需走常规扩容流程

    def _replenish_async(self):
        """异步补充预热实例"""
        def _create_warm_instance():
            # 调用 K8s API 创建 Pod 并等待模型加载完成
            pod_name = k8s_client.create_inference_pod()
            endpoint = wait_for_model_loaded(pod_name, timeout=120)
            instance = WarmInstance(
                pod_name=pod_name,
                endpoint=endpoint,
                ready_time=time.time(),
                last_health_check=time.time()
            )
            with self.lock:
                if len(self.pool) < self.max_warm:
                    self.pool.append(instance)
                else:
                    # 超出上限，回收多余实例
                    k8s_client.delete_pod(pod_name)

        thread = threading.Thread(target=_create_warm_instance,
                                  daemon=True)
        thread.start()

    def health_check_loop(self):
        """定期健康检查，移除异常实例"""
        while True:
            time.sleep(self.health_check_interval)
            with self.lock:
                alive = []
                for inst in self.pool:
                    if self._is_healthy(inst):
                        inst.last_health_check = time.time()
                        alive.append(inst)
                    else:
                        # 不健康的实例直接回收
                        k8s_client.delete_pod(inst.pod_name)
                self.pool = alive

                # 保持最低预热数量
                deficit = self.min_warm - len(self.pool)
                for _ in range(deficit):
                    self._replenish_async()

    def _is_healthy(self, instance: WarmInstance) -> bool:
        """检查预热实例是否健康"""
        try:
            resp = requests.get(
                f"http://{instance.endpoint}/health",
                timeout=5
            )
            return resp.status_code == 200
        except Exception:
            return False

3.3 GPU 感知的弹性伸缩策略

"""
基于推理队列深度和 GPU 利用率的弹性伸缩
为什么用队列深度而非 CPU 利用率作为主要指标？
GPU 推理服务中 CPU 利用率始终很低（< 20%），
无法反映真实负载；队列深度直接反映请求积压程度
"""
from kubernetes import client

class InferenceScaler:

    def __init__(self, namespace: str, deployment: str):
        self.namespace = namespace
        self.deployment = deployment
        self.k8s_apps = client.AppsV1Api()
        self.prometheus = PrometheusClient()

    def scale_decision(self) -> int:
        """计算目标副本数"""
        # 获取当前指标
        queue_depth = self.prometheus.query(
            'inference_request_queue_depth'
        )
        gpu_util = self.prometheus.query(
            'DCGM_FI_DEV_GPU_UTIL'
        )
        current_replicas = self._get_current_replicas()

        # 扩容条件：队列深度 > 50 且 GPU 利用率 > 70%
        if queue_depth > 50 and gpu_util > 0.70:
            # 按队列深度计算所需实例数
            # 假设单实例稳态处理能力为 20 QPS
            target = max(
                current_replicas + 2,
                int(queue_depth / 20) + 1
            )
            return min(target, 20)  # 上限 20 实例

        # 缩容条件：队列深度 < 5 且 GPU 利用率 < 40%
        if queue_depth < 5 and gpu_util < 0.40:
            # 缩容步长保守，每次最多缩 1 个
            return max(current_replicas - 1, 2)

        return current_replicas

    def execute_scale(self, target_replicas: int):
        """执行扩缩容"""
        self.k8s_apps.patch_namespaced_deployment_scale(
            name=self.deployment,
            namespace=self.namespace,
            body={"spec": {"replicas": target_replicas}}
        )

四、大模型部署架构的权衡与边界

显存与吞吐的矛盾：PagedAttention 通过分页管理提升了显存利用率，但页表映射引入了额外的显存访问开销。在短序列（< 512 tokens）场景下，PagedAttention 的性能优势不明显，甚至可能因页表开销略低于连续显存方案。

预热池的成本代价：预热池始终保持一定数量的空闲 GPU 实例，这些实例虽然不处理请求，但仍然占用 GPU 资源并产生费用。以 4 卡 A100 配置为例，每台预热实例月成本约 5 万元，2 台预热实例的月成本即 10 万元。成本敏感场景需要精细权衡预热池大小与冷启动容忍度。

连续批处理的延迟尾部：连续批处理提升了吞吐量，但长请求会挤占批次资源，导致短请求的尾部延迟增加。在混合长短请求的场景中，需要实现请求优先级调度，但优先级调度又会降低整体吞吐量。

适用边界：此架构适用于对话类、生成类大模型推理服务，特点是请求流量波动大、单次推理耗时长、GPU 资源昂贵。对于 Embedding 等轻量级推理服务，单卡即可满足需求，无需复杂的部署架构。

禁用场景：实时性要求极高的流式推理（如实时语音合成，延迟要求 < 100ms），连续批处理的调度开销不可接受，应采用独占 GPU 的单请求推理模式。

五、总结

大模型推理部署的核心矛盾是 GPU 成本与流量波动的冲突。连续批处理和 PagedAttention 从引擎层面压榨 GPU 性能，预热池从调度层面消除冷启动延迟，GPU 感知的弹性伸缩从资源层面实现按需分配。三者协同构成了大模型推理服务的生产级部署架构。

落地路线建议：第一步，选用 vLLM 作为推理引擎，开启 PagedAttention 和前缀缓存；第二步，基于 OpenAI API 协议封装推理服务，统一客户端接入方式；第三步，部署预热池管理器，根据流量模式设定预热池大小；第四步，实现 GPU 感知的弹性伸缩策略，替代原生 HPA；第五步，建立推理延迟、队列深度、GPU 利用率的三维监控看板，持续优化部署参数。架构的每一步优化都必须以数据为依据，而非凭经验猜测。