大模型推理服务无服务器架构弹性伸缩深度调研报告

调研主题： 大模型推理服务无服务器架构弹性伸缩 所属域： 大模型框架 调研日期： 2026-03-30

目录

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

第一部分：概念剖析

1. 定义澄清

通行定义

大模型推理服务无服务器架构弹性伸缩是指在大语言模型（LLM）推理场景中，采用无服务器（Serverless）计算范式，根据实时请求负载自动调整计算资源（GPU/TPU 实例）的技术体系。其核心特征包括：按请求计费、毫秒级冷启动、自动扩缩容至零、以及无需用户管理底层基础设施。

该技术的本质是将 LLM 推理的高固定成本（GPU 闲置）转化为可变成本（按 Token 计费），通过请求池化和动态调度实现资源利用率最大化。

常见误解

边界辨析

2. 核心架构

┌────────────────────────────────────────────────────────────────┐
│              大模型推理无服务器弹性伸缩系统架构                  │
├────────────────────────────────────────────────────────────────┤
│                                                                 │
│  用户请求                                                        │
│     │                                                           │
│     ▼                                                           │
│ ┌───────────────┐                                               │
│ │   API Gateway │ ← 请求路由、认证、限流、计费                   │
│ └───────┬───────┘                                               │
│         │                                                        │
│         ▼                                                        │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │                    调度层 (Scheduler)                        │ │
│ │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐  │ │
│ │  │ 负载均衡器  │  │ 请求队列    │  │ 批处理调度器         │  │ │
│ │  │             │  │             │  │ (Continuous Batching)│  │ │
│ │  └─────────────┘  └─────────────┘  └─────────────────────┘  │ │
│ └─────────────────────────────────────────────────────────────┘ │
│         │                                                        │
│         ▼                                                        │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │                   弹性管理层 (Autoscaler)                    │ │
│ │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐  │ │
│ │  │ 指标收集器  │  │ 缩容策略    │  │ 扩容策略            │  │ │
│ │  │ (QPS/延迟)  │  │ (缩容冷却)  │  │ (Warm Pool 预热)    │  │ │
│ │  └─────────────┘  └─────────────┘  └─────────────────────┘  │ │
│ └─────────────────────────────────────────────────────────────┘ │
│         │                                                        │
│         ▼                                                        │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │                  推理执行层 (Inference)                      │ │
│ │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐  │ │
│ │  │ vLLM/TGI    │  │ SGLang      │  │ TensorRT-LLM        │  │ │
│ │  │ 推理引擎    │  │ 推理引擎    │  │ 推理引擎            │  │ │
│ │  └──────┬──────┘  └──────┬──────┘  └──────────┬──────────┘  │ │
│ │         │                │                     │             │ │
│ │         ▼                ▼                     ▼             │ │
│ │  ┌─────────────────────────────────────────────────────────┐│ │
│ │  │              GPU 资源池 (A100/H100/H200)                ││ │
│ │  │    ┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐             ││ │
│ │  │    │GPU 0  │ │GPU 1  │ │GPU 2  │ │GPU 3  │  ...        ││ │
│ │  │    └───────┘ └───────┘ └───────┘ └───────┘             ││ │
│ │  └─────────────────────────────────────────────────────────┘│ │
│ └─────────────────────────────────────────────────────────────┘ │
│         │                                                        │
│         ▼                                                        │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │                    存储层 (Storage)                          │ │
│ │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐  │ │
│ │  │ 模型仓库    │  │ KV Cache    │  │ 日志/监控           │  │ │
│ │  │ (S3/HF Hub) │  │ (分布式缓存)│  │ (Prometheus)        │  │ │
│ │  └─────────────┘  └─────────────┘  └─────────────────────┘  │ │
│ └─────────────────────────────────────────────────────────────┘ │
│                                                                 │
└────────────────────────────────────────────────────────────────┘

组件职责说明：

3. 数学形式化

3.1 核心延迟模型

LLM 推理的端到端延迟可形式化为：

解释： 总延迟 = 队列等待时间 + 调度开销 + 预填充时间 + 单 Token 解码时间 × 生成 Token 数

其中：

• $T_{prefill} = \frac{L_{prompt}}{Throughput_{prefill}}$，与 prompt 长度成正比
• $T_{decode} = \frac{1}{Throughput_{decode}}$，通常 prefill 吞吐远高于 decode

3.2 弹性伸缩决策函数

扩容触发条件：

缩容触发条件：

解释： 扩容当待处理请求超过阈值且过了冷却期；缩容当负载低于阈值且保留最小实例数

3.3 成本优化模型

Serverless 成本函数：

预留实例成本函数：

解释： Serverless 按实际使用计费，预留实例有固定成本但突发流量有额外费用

盈亏平衡点计算：

解释： 当资源利用率超过 $U_{target}$ 时，预留实例更经济

3.4 KV Cache 命中率

解释： Prefix Caching 命中率 = 匹配的前缀 Token 数 / 总 prompt Token 数

3.5 GPU 利用率模型

解释： GPU 利用率 = 计算时间 / (计算 + 空闲 + 数据传输时间)

4. 实现逻辑

class ServerlessLLMInferenceSystem:
    """
    大模型无服务器推理系统核心实现
    体现弹性伸缩、请求调度、批处理优化的关键抽象
    """

    def __init__(self, config):
        # 资源配置
        self.min_instances = config.get('min_instances', 0)  # 支持缩容至零
        self.max_instances = config.get('max_instances', 100)
        self.scale_up_threshold = config.get('scale_up_threshold', 0.7)
        self.scale_down_threshold = config.get('scale_down_threshold', 0.3)
        self.cooldown_seconds = config.get('cooldown', 300)

        # 核心组件
        self.request_queue = PriorityQueue()      # 请求队列，支持优先级
        self.instance_pool = InstancePool()       # GPU 实例池
        self.kv_cache_store = DistributedKVCache() # 分布式 KV Cache
        self.metrics_collector = MetricsCollector() # 指标收集
        self.batch_scheduler = ContinuousBatchScheduler()  # 批处理调度

        # Warm Pool 用于加速冷启动
        self.warm_pool = WarmPool(size=config.get('warm_pool_size', 2))

    def handle_request(self, request: InferenceRequest) -> InferenceResponse:
        """
        处理单个推理请求的核心流程
        """
        # 1. 请求入队
        self.request_queue.enqueue(request)

        # 2. 检查并触发弹性伸缩
        self.autoscaler.evaluate_and_scale(
            pending_requests=self.request_queue.size(),
            active_instances=self.instance_pool.active_count()
        )

        # 3. 获取可用实例
        instance = self.instance_pool.acquire(
            model=request.model,
            use_warm_pool=request.priority == 'high'
        )

        # 4. 批处理调度（Continuous Batching）
        batch = self.batch_scheduler.form_batch(
            request=request,
            instance=instance,
            max_batch_size=instance.max_batch_size
        )

        # 5. 执行推理
        if instance.has_kv_cache(request.prefix_hash):
            # 利用已有的 KV Cache 加速
            response = instance.incremental_decode(batch)
        else:
            # 完整预填充 + 解码
            response = instance.full_inference(batch)

        # 6. 保存 KV Cache 供后续请求复用
        if config.enable_prefix_caching:
            self.kv_cache_store.save(
                prefix_hash=request.prefix_hash,
                kv_cache=instance.get_kv_cache()
            )

        # 7. 释放实例或返回池中
        self.instance_pool.release(instance)

        return response

    class Autoscaler:
        """
        弹性伸缩控制器
        基于指标和策略决策扩缩容
        """

        def evaluate_and_scale(self, pending_requests: int, active_instances: int):
            # 计算目标实例数
            current_load = pending_requests / (active_instances * TARGET_REQUESTS_PER_INSTANCE)

            if current_load > self.scale_up_threshold:
                # 扩容
                target = min(
                    self.max_instances,
                    math.ceil(active_instances * (current_load / self.scale_up_threshold))
                )
                self.scale_to(target)

            elif current_load < self.scale_down_threshold and active_instances > self.min_instances:
                # 缩容（带冷却时间）
                if time_since_last_scale > self.cooldown_seconds:
                    target = max(
                        self.min_instances,
                        math.floor(active_instances * (current_load / self.scale_down_threshold))
                    )
                    self.scale_to(target)

        def scale_to(self, target_instances: int):
            """执行扩缩容操作"""
            current = self.instance_pool.active_count()

            if target_instances > current:
                # 扩容：优先使用 Warm Pool，不足则创建新实例
                warm_count = min(target_instances - current, self.warm_pool.size())
                for _ in range(warm_count):
                    instance = self.warm_pool.acquire()
                    self.instance_pool.add(instance)

                # 剩余需要冷启动
                for _ in range(target_instances - current - warm_count):
                    instance = self.instance_pool.create_cold()
                    # 异步加载模型
                    asyncio.create_task(self.load_model_async(instance))

            elif target_instances < current:
                # 缩容：优雅排空实例
                to_remove = current - target_instances
                for instance in self.instance_pool.select_vacant(to_remove):
                    instance.drain_and_terminate()

    class ContinuousBatchScheduler:
        """
        连续批处理调度器
        核心优化：在 decoding 过程中动态插入新请求
        """

        def form_batch(self, request, instance, max_batch_size):
            # 获取当前正在运行的请求
            running = instance.get_running_requests()

            # 计算剩余容量
            available_slots = max_batch_size - len(running)

            # 从队列中获取等待的请求
            waiting = self.request_queue.dequeue_n(available_slots)

            # 合并为批处理
            batch = running + waiting

            # 检查显存约束
            if not instance.has_memory_for_batch(batch):
                # 需要驱逐部分 KV Cache 或拒绝请求
                batch = self.optimize_for_memory(batch, instance)

            return batch

5. 性能指标

6. 扩展性与安全性

水平扩展

扩展上限： 理论无上限，实际受限于：

• 调度器单点瓶颈（可通过分片解决）
• 共享存储带宽（KV Cache 读取）
• 模型仓库分发能力

垂直扩展

安全考量

第二部分：行业情报

1. GitHub 热门项目（15+ 个）

基于 2025-2026 年最新数据整理：

筛选标准： 最近 6 个月有活跃提交，Stars > 2000 或知名团队维护

2. 关键论文（12 篇）

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

最新 SOTA 论文（前沿进展）

3. 系统化技术博客（10 篇）

4. 技术演进时间线

2020 ─┬─ GPT-3 发布 → 大模型推理需求爆发，批处理为主
      │
2022 ─┼─ Orca 论文发表 → 提出 Continuous Batching 范式
      │
2023 ─┼─ vLLM 发布 → PagedAttention 革新显存管理
      ├─ TGI 开源 → HuggingFace 官方推理方案
      │
2024 ─┼─ SGLang 发布 → 结构化生成与高效推理
      ├─ DistServe → 预填充与解码解耦
      ├─ MoonCake → KVCache 中心化解耦架构
      │
2025 ─┼─ ServerlessLLM → 优化冷启动的无服务器方案
      ├─ ElasticLLM → 专为 Serverless 设计的弹性系统
      ├─ 商业平台成熟 (Modal, Runway, Anyscale)
      │
2026 ─┴─ 当前状态：无服务器 LLM 推理成为主流，弹性伸缩
         与成本优化为核心竞争力

关键里程碑事件：

第三部分：方案对比

1. 历史发展时间线

2020 ─┬─ 简单批处理 → 单 GPU 顺序处理，无并发优化
      │
2022 ─┼─ Orca Continuous Batching → 动态合并请求，吞吐提升 10 倍
      │
2023 ─┼─ vLLM PagedAttention → 显存效率提升 2-4 倍，支持更大批
      │
2024 ─┼─ 解耦架构兴起 → Prefill/Decode 分离，KVCache 共享
      │
2025 ─┼─ Serverless 成熟 → 按需付费、自动弹性、冷启动优化
      │
2026 ─┴─ 当前状态：多方案并存，根据场景选择最优解

2. 六种方案横向对比

成本量级说明（以 7B 模型，10 万请求/天估算）：

• $$：月成本 $500-2000（Serverless 按量）
• $$$：月成本 $2000-10000（中型集群）
• $$$$：月成本 $10000+（大型 GPU 集群）

3. 技术细节对比

评分说明： ⭐⭐⭐⭐⭐ = 最优，⭐ = 最弱

4. 选型建议

成本估算假设：

• 7B-13B 模型为主，部分 70B 模型
• 日请求量 1 万 -100 万不等
• 平均每个请求 100 input + 200 output tokens
• GPU 价格按 A100 $3-4/小时，H100$5-7/小时

5. 选型决策树

                          ┌─ 需要零运维？ ──是──→ Modal Serverless
                         │
              ┌─ 负载波动大？ ──是─┤
             │                    │
             │                    └─ 否 ──→ 继续评估
             │
开始 ── 是否需要弹性？ ──否 ──→ vLLM / TGI (GPU 常驻)
             │
             │                    ┌─ 是 ──→ KubeRay + Ray Serve
             └─ 需要复杂调度？ ──┤
                                └─ 否 ──→ vLLM on K8s

第四部分：精华整合

1. The One 公式

用一个"悖论式等式"概括该领域的核心本质：

解读： 无服务器 LLM 推理的本质是通过连续批处理最大化吞吐、通过分页注意力高效管理显存，同时需要克服冷启动这一核心挑战。

2. 一句话解释

费曼技巧解释： 就像网约车平台根据乘客需求动态调度车辆一样，无服务器 LLM 推理根据用户请求自动开启或关闭 GPU 资源，用完即释放，只为实际使用付费，而不是 24 小时租用昂贵的 GPU。

3. 核心架构图

用户请求 → [API Gateway] → [弹性调度器] → [推理引擎池] → 响应
              │              │              │
              ▼              ▼              ▼
         限流/计费      扩缩容决策      Continuous Batching
                           │
                           ▼
                    [Warm Pool 预热]
                           │
                           ▼
                    [KV Cache 共享]

4. STAR 总结

5. 理解确认问题

问题： 为什么不能简单地将传统 Serverless（如 AWS Lambda）的模式直接应用于 LLM 推理？主要障碍是什么，业界如何解决？

参考答案：

主要障碍有三点：

1. 冷启动成本高：Lambda 冷启动约 100-500ms，而 70B 模型加载需 30-120 秒（下载权重 + 加载到显存）。解决： Warm Pool 预热、增量模型加载、模型权重本地缓存。

2. 状态管理复杂：Lambda 无状态设计，但 LLM 推理需要维护 KV Cache 以支持多轮对话和 Prefix Caching。解决： 分布式 KV Cache 存储、请求粘性调度、Cache 迁移机制。

3. 资源粒度粗：Lambda 按 MB-秒计费，适合 CPU 任务；GPU 资源稀缺且昂贵，无法细粒度切分。解决： 时间片复用（多请求批处理）、显存隔离、GPU 共享技术（MIG、时间分片）。

业界通过上述优化，使 Serverless LLM 的冷启动可控制在 1-5 秒（Warm Pool 命中）或 30-60 秒（冷启动），达到生产可用水平。

附录：术语表

报告完成日期： 2026-03-30 总字数： 约 8500 字

参考来源

GitHub 项目

• vLLM: https://github.com/vllm-project/vllm
• SGLang: https://github.com/sgl-project/sglang
• TGI: https://github.com/huggingface/text-generation-inference
• Ray: https://github.com/ray-project/ray
• KubeRay: https://github.com/ray-project/kuberay
• TensorRT-LLM: https://github.com/NVIDIA/TensorRT-LLM

学术论文

• Orca (OSDI 2022): https://arxiv.org/abs/2209.01643
• vLLM/PagedAttention (SOSP 2023): https://arxiv.org/abs/2309.06180
• DistServe (OSDI 2024): https://arxiv.org/abs/2401.13537
• MoonCake (2024): https://arxiv.org/abs/2407.00079

技术博客

• Chip Huyen: https://huyenchip.com/
• vLLM Blog: https://blog.vllm.ai/
• Modal Blog: https://modal.com/blog
• HuggingFace Blog: https://huggingface.co/blog