大模型推理服务弹性伸缩机制深度调研报告

调研主题： 大模型推理服务弹性伸缩机制 所属域： 大模型框架 调研日期： 2026-03-21 报告版本： 1.0

目录

1. 第一部分：概念剖析
2. 第二部分：行业情报
3. 第三部分：方案对比
4. 第四部分：精华整合
5. 参考文献

第一部分：概念剖析

1.1 定义澄清

通行定义

大模型推理服务弹性伸缩机制（LLM Inference Autoscaling）是指根据实时请求负载动态调整推理服务资源配置的技术体系，包括计算实例数量、GPU 显存分配、批处理大小等维度的自适应调节。其核心目标是在满足服务质量（SLO）约束的前提下，最小化资源成本和请求延迟。

常见误解

边界辨析

1.2 核心架构

┌────────────────────────────────────────────────────────────────┐
│              大模型推理服务弹性伸缩系统                          │
├────────────────────────────────────────────────────────────────┤
│                                                                │
│   ┌─────────┐     ┌──────────────┐     ┌─────────────────┐    │
│   │ 请求入口 │ ──→ │   调度层     │ ──→ │   推理引擎层    │    │
│   │ (API GW)│     │ (Scheduler)  │     │ (vLLM/TGI/SG)   │    │
│   └─────────┘     └──────┬───────┘     └────────┬────────┘    │
│                          │                      │             │
│                          ↓                      ↓             │
│   ┌─────────────────────────────────────────────────────────┐  │
│   │                    监控指标采集层                        │  │
│   │  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐ │  │
│   │  │队列深度  │  │KV Cache  │  │ TTFT/P99 │  │GPU 利用率 │ │  │
│   │  └──────────┘  └──────────┘  └──────────┘  └──────────┘ │  │
│   └─────────────────────────────────────────────────────────┘  │
│                          │                                      │
│                          ↓                                      │
│   ┌─────────────────────────────────────────────────────────┐  │
│   │                    弹性决策引擎                          │  │
│   │  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐   │  │
│   │  │ 阈值规则引擎 │  │ 预测模型     │  │ 成本控制模块 │   │  │
│   │  └──────────────┘  └──────────────┘  └──────────────┘   │  │
│   └─────────────────────────────────────────────────────────┘  │
│                          │                                      │
│                          ↓                                      │
│   ┌─────────────────────────────────────────────────────────┐  │
│   │                    资源编排层                            │  │
│   │     K8s HPA / KEDA / Ray Autoscaler / 自定义 Operator   │  │
│   └─────────────────────────────────────────────────────────┘  │
│                                                                │
└────────────────────────────────────────────────────────────────┘

组件职责说明：

1.3 数学形式化

公式 1：最优批处理大小

解释： 最优批处理大小是在吞吐、延迟和成本之间的加权最优解，λ 为成本权重系数。

公式 2：队列感知的扩缩容决策

解释： 当队列长度 Q(t) 持续超过容量 C(t) 的α阈值时扩容，低于β阈值时缩容，Δt 为持续时间约束。

公式 3：KV Cache 内存约束

解释： 总显存需容纳模型权重 + 所有序列的 KV 缓存，因子 2 来自 Key 和 Value 两个矩阵。

公式 4：SLO 违例概率

解释： 响应时间超过 SLO 阈值的概率必须控制在ε以内（通常ε< 0.01）。

公式 5：资源利用效率

解释： 资源利用效率为所有 GPU 活跃时间占总时间的比例，弹性伸缩的目标是在满足 SLO 前提下最大化η。

1.4 实现逻辑

class InferenceAutoscaler:
    """大模型推理服务弹性伸缩核心控制器"""

    def __init__(self, config):
        # 监控组件：采集实时指标
        self.metrics_collector = MetricsCollector(
            endpoints=["queue_depth", "ttft_p99", "kv_cache_utilization", "gpu_memory"]
        )
        # 预测组件：基于历史数据预测负载
        self.load_predictor = LoadPredictor(
            model="prophet", window_size="1h"
        )
        # 决策组件：执行扩缩容策略
        self.scaling_policy = ScalingPolicy(
            scale_up_threshold=0.8,
            scale_down_threshold=0.3,
            cooldown_period="120s",
            max_replicas=10,
            min_replicas=1
        )
        # 执行组件：与编排系统交互
        self.orchestrator = K8sOperator(
            namespace="inference",
            deployment="llm-service"
        )

    def core_operation(self, current_time):
        """核心弹性决策循环，每 10 秒执行一次"""
        # 1. 采集当前指标
        metrics = self.metrics_collector.collect()

        # 2. 预测短期负载趋势
        forecast = self.load_predictor.predict(
            history=metrics.history,
            horizon="5min"
        )

        # 3. 计算目标副本数
        current_replicas = self.orchestrator.get_replicas()
        target_replicas = self.scaling_policy.decide(
            current_metrics=metrics,
            forecast=forecast,
            current_replicas=current_replicas
        )

        # 4. 执行扩缩容（如果需要）
        if target_replicas != current_replicas:
            if self.scaling_policy.is_cooldown_expired():
                self.orchestrator.scale(target_replicas)
                self.scaling_policy.record_scaling_event()

        return {
            "timestamp": current_time,
            "current_replicas": current_replicas,
            "target_replicas": target_replicas,
            "metrics_summary": metrics.summary()
        }


class ScalingPolicy:
    """弹性伸缩策略，支持多种决策算法"""

    def __init__(self, scale_up_threshold, scale_down_threshold,
                 cooldown_period, max_replicas, min_replicas):
        self.scale_up_threshold = scale_up_threshold      # 80% 利用率触发扩容
        self.scale_down_threshold = scale_down_threshold  # 30% 利用率触发缩容
        self.cooldown_period = cooldown_period
        self.max_replicas = max_replicas
        self.min_replicas = min_replicas
        self.last_scaling_time = None

    def decide(self, current_metrics, forecast, current_replicas):
        """基于队列深度和预测负载计算目标副本数"""
        queue_depth = current_metrics.queue_depth
        avg_processing_time = current_metrics.avg_processing_time

        # 基于队列的即时决策
        if queue_depth > current_replicas * self.scale_up_threshold * 10:
            target = min(current_replicas + 2, self.max_replicas)
        elif queue_depth < current_replicas * self.scale_down_threshold * 10:
            target = max(current_replicas - 1, self.min_replicas)
        else:
            # 基于预测的前瞻决策
            predicted_load = forecast.peak_load
            target = self._calculate_replicas_for_load(predicted_load)

        return target

    def _calculate_replicas_for_load(self, predicted_load):
        """根据预测负载计算所需副本数"""
        requests_per_replica = 10  # 假设每副本每秒处理 10 请求
        required = math.ceil(predicted_load / requests_per_replica)
        return max(self.min_replicas, min(required, self.max_replicas))

1.5 性能指标

1.6 扩展性与安全性

水平扩展策略

垂直扩展上限

• 单 GPU 显存约束：H100 (80GB) 最多容纳 70B 模型（4bit 量化）或 30B 模型（FP16）
• 批处理上限：受 KV Cache 总大小限制，通常 batch_size < 256
• 算力约束：即使显存足够，计算密集型模型受限于 FLOPS

安全考量

第二部分：行业情报

2.1 GitHub 热门项目（18 个）

基于 2025-2026 年最新数据整理的大模型推理服务相关开源项目：

2.2 关键论文（12 篇）

经典高影响力论文（奠基性工作）

最新 SOTA 论文（前沿进展）

2.3 系统化技术博客（12 篇）

英文博客

中文博客

2.4 技术演进时间线

2020 ─┬─ TensorRT Inference Server (NVIDIA) → 首个通用推理服务框架
      │
2021 ─┼─ Triton Inference Server 开源 → 多框架支持（PyTorch/TF/ONNX）
      │
2022 ─┼─ Orca (Microsoft) → 迭代式批处理调度，LLM 专用调度开端
      │
2023 ─┼─ vLLM + PagedAttention → 显存效率革命，连续批处理成为标配
      │
2023 ─┼─ TGI (HuggingFace) → 官方推理服务，推动生产级标准化
      │
2024 ─┼─ SGLang + RadixAttention → 前缀缓存优化，RAG 场景效率提升
      │
2024 ─┼─ DistServe / Splitwise → Prefill/Decode分离，异构集群调度
      │
2025 ─┼─ Mooncake / InfiniGen → KVCache 中心架构，推测解码普及
      │
2025 ─┼─ NVIDIA NIM 全面推广 → 企业级微服务化部署
      │
2026 ─┴─ 当前状态：弹性伸缩从"资源驱动"向"负载预测驱动"演进，
           KV Cache 管理成为核心优化点，推测解码逐步成熟

第三部分：方案对比

3.1 历史发展时间线

2019 ─┬─ Kubernetes HPA → 基于 CPU/内存的通用自动伸缩
      │
2021 ─┼─ KEDA 1.0 → 事件驱动的弹性伸缩，支持自定义指标
      │
2022 ─┼─ Ray Autoscaler → 面向 ML 工作负载的动态资源分配
      │
2023 ─┼─ vLLM 连续批处理 → 请求级动态调度，LLM 专用弹性
      │
2024 ─┼─ KEDA + Prometheus 指标 → 队列深度感知的弹性伸缩
      │
2025 ─┼─ 预测式弹性（ML-based） → 基于负载预测的前瞻扩缩容
      │
2026 ─┴─ 当前状态：多指标融合 + 预测模型 + 成本约束的综合决策系统

3.2 六种方案横向对比

3.3 技术细节对比

3.4 选型建议

3.5 2026 年技术趋势与选型考量

基于当前技术演进趋势，2026 年选型需额外考虑：

1. 推测解码成熟度：InfiniGen、EAGLE 等推测解码技术可将推理速度提升 2-3 倍，建议评估支持该特性的引擎

2. KV Cache 中心化：Mooncake 等架构将 KV Cache 从计算节点解耦，支持更灵活的弹性策略

3. 成本感知调度：随着云 GPU 成本上升，支持 Spot 实例、混部调度的方案更具优势

4. 可观测性要求：生产环境需完整的指标、日志、追踪链路，优先选择 Prometheus 生态友好的方案

第四部分：精华整合

4.1 The One 公式

用一个悖论式等式概括大模型推理弹性伸缩的核心本质：

解读：弹性伸缩 = 对当前负载的快速响应 + 对未来趋势的前瞻预判 - 过度频繁扩缩容带来的震荡损耗

4.2 一句话解释

大模型推理弹性伸缩就像"智能空调系统"：当房间（队列）里人多了就自动多开几台空调（扩实例），人少了就关掉几台省电（缩实例），但不会频繁开关以免损坏设备（冷却约束）。

4.3 核心架构图

┌─────────────────────────────────────────────────────────────┐
│                    LLM 弹性伸缩全景图                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   请求 → [监控采集] → [决策引擎] → [资源编排] → 服务实例    │
│           ↓ 队列深度   ↓ 规则/预测    ↓ K8s/Ray            │
│           ↓ TTFT/P99   ↓ 冷却约束    ↓ 镜像/模型          │
│           ↓ GPU 利用   ↓ 成本约束    ↓ 健康检查          │
│                                                             │
│   核心指标：TTFT < 200ms | P99 延迟 < 2s | SLO > 99.9%    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

4.4 STAR 总结

4.5 理解确认问题

问题：为什么在大模型推理弹性伸缩中，不能简单使用 Kubernetes HPA 基于 CPU 利用率的自动伸缩？请从至少三个角度分析原因。

参考答案：

1. 指标不匹配：LLM 服务的瓶颈通常是显存（KV Cache）和请求队列长度，而非 CPU 利用率。CPU 可能只有 20% 但队列已经积压，此时 HPA 不会扩容。

2. 响应滞后：HPA 基于平均利用率，而 LLM 请求具有突发性。当 CPU 指标上升时，队列可能已经积压了数百请求，导致延迟飙升。

3. 冷启动成本：LLM 服务冷启动需要加载数 GB 的模型权重，耗时 30-120 秒。HPA 的频繁扩缩容会导致服务反复重启，无法处理请求。

4. 批处理效应：LLM 推理的吞吐高度依赖 batch size，而 CPU 利用率无法反映批处理效率。小 batch 高 CPU 和大 batch 低 CPU 可能对应相同的请求处理量。

参考文献

核心论文

1. Kwon W, et al. "Efficient Memory Management for Large Language Model Serving with PagedAttention." OSDI 2023.
2. Sheng L, et al. "SGLang: Efficient Execution of Structured Language Model Programs." MLSys 2024.
3. Agrawal A, et al. "Sarathi-Serve: High-Throughput LLM Serving." arXiv 2024.
4. Zhong Y, et al. "DistServe: Disaggregating Prefill and Decoding for LLM Serving." OSDI 2024.

开源项目

1. vLLM: https://github.com/vllm-project/vllm
2. Text Generation Inference: https://github.com/huggingface/text-generation-inference
3. SGLang: https://github.com/sgl-project/sglang
4. Ray Serve: https://github.com/ray-project/ray
5. KEDA: https://github.com/kedacore/keda

技术博客

1. UC Berkeley Sky Computing Lab. "vLLM: Easy, Fast, and Cheap LLM Serving." 2025.
2. Hugging Face. "LLM Inference Optimization Guide." 2025.
3. NVIDIA. "Efficient LLM Serving with NVIDIA NIM." 2025.
4. Chip Huyen. "Building a Production LLM Platform." 2025.

报告完成日期： 2026-03-21 总字数： 约 8500 字 数据来源： WebSearch 实时检索（2026-03-21）