大模型推理服务弹性伸缩机制深度调研报告
调研主题： 大模型推理服务弹性伸缩机制
所属域： 大模型框架
调研日期： 2026-04-11
报告版本： 3.0
目录
- 维度一：概念剖析
- 维度二：行业情报
- 维度三：方案对比
- 维度四：精华整合
- 参考文献
维度一：概念剖析
1.1 定义澄清
通行定义
大模型推理服务弹性伸缩机制（Elastic Autoscaling for LLM Inference Serving）是指在大语言模型（LLM）推理服务场景中，根据实时负载动态调整计算资源（GPU 实例数量、KVCache 分配、计算单元规模等）的系统能力。其核心目标是在满足服务等级目标（SLO）的前提下，最大化资源利用率和成本效益。
与传统的微服务弹性伸缩不同，LLM 推理弹性伸缩需要考虑以下特殊性：
- 请求异质性：不同请求的 token 数量差异巨大（从几 token 到数十万 token）
- 两阶段特性：Prefill（预填充）和 Decode（解码）阶段具有完全不同的资源特征
- 显存约束：GPU 显存是核心瓶颈资源，而非 CPU 或内存
- 冷启动延迟：模型加载和 KVCache 预热需要数秒至数十秒
- 状态依赖性：KVCache 状态需要在实例间迁移或共享，不能简单无状态扩缩容
常见误解
| 误解 |
正确理解 |
| 误解 1：弹性伸缩就是简单的 HPA（水平 Pod 自动伸缩） |
传统 HPA 基于 CPU/内存指标，而 LLM 推理需要基于队列深度、等待请求数、GPU KVCache 利用率等专用指标进行弹性决策。2025 年 KubeCon 多项研究表明，基于队列深度的 KEDA 方案响应速度比 HPA 快 3 倍以上 |
| 误解 2：伸缩粒度只能是整卡/整节点 |
现代系统支持更细粒度的弹性，包括 KVCache 池的动态分配、专家并行（Expert Parallelism）的弹性调整、以及 Prefill/Decode 阶段的独立伸缩。Mooncake 架构实现了 KVCache 与计算节点的完全解耦 |
| 误解 3：弹性伸缩只关注扩容，不关注缩容 |
缩容（Scale-down）同样重要，需要优雅地处理正在进行的请求、迁移 KVCache 状态，避免请求中断。2026 年 KevlarFlow 研究将 MTTR 降低 20 倍，核心是优雅的缩容恢复机制 |
| 误解 4：弹性伸缩是纯基础设施问题 |
弹性伸缩与调度算法、KVCache 管理、请求路由等应用层逻辑深度耦合，需要全栈协同设计。vLLM Production Stack 将指标采集深度集成到推理引擎中 |
| 误解 5：简单的实例复制即可解决扩容问题 |
LLM 推理具有状态性（KV Cache），简单的 Pod 复制会导致缓存失效和冷启动开销。现代方案采用 KV Cache 分离、Prefix Cache 共享、请求路由优化等技术 |
边界辨析
| 概念 |
核心区别 |
| 弹性伸缩 vs. 负载均衡 |
弹性伸缩关注资源数量的动态调整；负载均衡关注请求在现有资源间的分配。两者通常配合使用，但目标不同 |
| 弹性伸缩 vs. 模型压缩 |
弹性伸缩是系统层面的资源调度；模型压缩（量化、剪枝、蒸馏）是模型层面的优化。前者不影响模型精度，后者会 |
| 弹性伸缩 vs. 批处理优化 |
弹性伸缩是粗粒度的资源调整（秒级）；批处理优化（Continuous Batching）是细粒度的请求调度（毫秒级） |
| 弹性伸缩 vs. 多租户隔离 |
弹性伸缩关注资源总量调整；多租户隔离关注资源在租户间的公平分配和 QoS 保障 |
| 推理伸缩 vs. 训练伸缩 |
推理伸缩关注低延迟和高吞吐，需要快速响应负载变化；训练伸缩关注大规模并行效率，通常是静态或准静态配置 |
1.2 核心架构
┌─────────────────────────────────────────────────────────────────────┐
│ 大模型推理服务弹性伸缩系统架构 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────────────┐ │
│ │ 客户端请求 │ → │ 负载均衡器 │ → │ 请求路由器 │ │
│ └──────────────┘ └──────────────┘ └──────────┬───────────┘ │
│ ↓ │
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ 弹性伸缩控制器 │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────────┐│ │
│ │ │ 指标采集器 │ │ 伸缩决策器 │ │ 资源执行器 ││ │
│ │ │ - 队列深度 │ │ - 阈值判断 │ │ - Kubernetes HPA ││ │
│ │ │ - GPU 利用率 │ │ - 预测算法 │ │ - KEDA 事件驱动 ││ │
│ │ │ - KVCache │ │ - 冷却策略 │ │ - 自定义资源调度 ││ │
│ │ │ - P99 延迟 │ │ - 负载预测 │ │ - Ray/K8s 调度器 ││ │
│ │ └─────────────┘ └─────────────┘ └─────────────────────────┘│ │
│ └───────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ 推理服务集群 │ │
│ │ ┌─────────────────┐ ┌─────────────────────────────┐│ │
│ │ │ Prefill 节点池 │ │ Decode 节点池 ││ │
│ │ │ (计算密集型) │ ←KVCache→ │ (内存密集型) ││ │
│ │ │ - 高吞吐优化 │ 共享池 │ - 低延迟优化 ││ │
│ │ │ - A100/H100 │ Mooncake│ - T4/A10 ││ │
│ │ └─────────────────┘ └─────────────────────────────┘│ │
│ └───────────────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌───────────────────────────────────────────────────────────────┐ │
│ │ 监控与可观测性 │ │
│ │ ┌──────────────┐ ┌──────────────┐ ┌─────────────────────┐ │ │
│ │ │ Prometheus │ │ Grafana │ │ 分布式追踪 (Jaeger)│ │ │
│ │ │ 指标存储 │ │ 可视化 │ │ 延迟追踪 │ │ │
│ │ └──────────────┘ └──────────────┘ └─────────────────────┘ │ │
│ └───────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
数据流向说明：
1. 用户请求 → Gateway 入口 → 负载均衡器（基于一致性哈希或最少连接）
2. 请求路由器根据请求特征（prompt 长度、模型版本、租户 ID）路由到合适实例
3. 指标采集器实时采集队列深度、GPU 利用率、KVCache 使用率、P99 延迟
4. 伸缩决策器基于规则和预测模型做出扩容/缩容决策
5. 资源执行器通过 Kubernetes/KEDA/Ray 执行实际伸缩操作
6. KVCache 共享池支持跨节点缓存迁移和预热
各组件职责说明：
| 组件 |
职责 |
关键技术 |
| 负载均衡器 |
接收客户端请求，基于一致性哈希或最少连接数进行初步分发 |
Envoy, Nginx, Istio |
| 请求路由器 |
根据请求特征（prompt 长度、模型版本）路由到合适的服务实例 |
vLLM Router, Ray Router |
| 指标采集器 |
实时采集推理服务的核心指标（队列深度、等待请求数、GPU 显存使用率、KVCache 命中率） |
Prometheus, DCGM |
| 伸缩决策器 |
基于采集的指标，结合阈值规则或预测算法，做出伸缩决策 |
KEDA, Chiron, SageServe |
| 资源执行器 |
执行伸缩动作，如 Kubernetes HPA、KEDA 事件驱动伸缩、或自定义的资源调度 |
K8s API, Ray API |
| Prefill 节点池 |
专门处理计算密集的预填充阶段，可独立弹性伸缩 |
vLLM, TensorRT-LLM |
| Decode 节点池 |
专门处理内存密集的解码阶段，可独立弹性伸缩 |
vLLM, SGLang |
| KVCache 共享池 |
跨节点的分布式 KVCache 存储，支持预填充和解耦节点间的 Cache 传输 |
Mooncake, RDMA |
1.3 数学形式化
公式 1：弹性伸缩决策函数
\text{scale\_up} & \text{if } Q(t) > \theta_{high} \land \Delta Q > 0 \land L(t) > SLO_{latency} \\
\text{scale\_down} & \text{if } Q(t) < \theta_{low} \land t - t_{last\_scale} > T_{cooldown} \\
\text{keep} & \text{otherwise}
\end{cases}$$
**解释：** 伸缩决策基于队列深度 $Q(t)$ 与阈值的比较，同时考虑延迟 $L(t)$ 是否超出 SLO。$\theta_{high}$ 和 $\theta_{low}$ 分别为扩容和缩容阈值（通常设置滞回区间避免震荡），$T_{cooldown}$ 为防止频繁伸缩的冷却时间（通常 120-300 秒）。
---
#### 公式 2：最优资源利用率模型
$$U^* = \arg\max_{n} \left[ \frac{\sum_{i=1}^{n} T_{effective}^{(i)}}{n \cdot C_{gpu} \cdot T_{total}} \right] \quad \text{s.t.} \quad P_{slo\_violation} < \epsilon$$
**解释：** 最优资源利用率 $U^*$ 是在满足 SLO 违约概率小于 $\epsilon$（通常 0.1%）的约束下，最大化总有效计算时间 $T_{effective}$ 与总资源成本 $n \cdot C_{gpu} \cdot T_{total}$ 的比值。其中 $n$ 为实例数量，$C_{gpu}$ 为单卡单位时间成本。
---
#### 公式 3：Prefill-Decode 解耦延迟模型
$$L_{total} = L_{prefill} + L_{transfer} + L_{decode} = \frac{S_{prompt}}{B_{prefill}} + \frac{S_{kv}}{BW_{rdma}} + \frac{S_{output} \cdot T_{gen}}{B_{decode}}$$
**解释：** 总延迟由预填充时间（prompt 大小除以预填充吞吐）、KVCache 传输时间（KVCache 大小除以 RDMA 带宽）和解码时间（生成 token 数乘以每 token 时间除以解码吞吐）组成。PD 解耦的核心是独立优化 $B_{prefill}$ 和 $B_{decode}$。
---
#### 公式 4：KVCache 弹性分配
$$C_{kv}^{(i)} = \frac{M_{gpu}^{(i)} - M_{model} - M_{overhead}}{S_{layer} \cdot N_{layer} \cdot 2 \cdot \text{bytes\_per\_param}} \cdot \alpha_{dynamic}$$
**解释：** 第 $i$ 个实例的 KVCache 容量由 GPU 显存 $M_{gpu}$ 减去模型权重 $M_{model}$ 和系统开销 $M_{overhead}$ 后，除以每层 KVCache 大小（$S_{layer} \cdot N_{layer} \cdot 2$ 表示 K 和 V 两份），再乘以动态分配系数 $\alpha_{dynamic}$。
---
#### 公式 5：成本效益比
$$ROI = \frac{R_{revenue} \cdot N_{served}}{C_{gpu} \cdot N_{instances} \cdot T_{running} + C_{idle} \cdot N_{idle} \cdot T_{idle} + C_{slo} \cdot N_{violation}}$$
**解释：** 投资回报率由服务收入与总成本的比值决定，总成本包括运行中的 GPU 成本、空闲时的资源浪费成本、以及 SLO 违约的惩罚成本。弹性伸缩的目标是最大化 ROI。
---
#### 公式 6：预测性伸缩目标计算
$$N_{target}(t+\Delta t) = \left\lceil \frac{\hat{\lambda}(t+\Delta t) \cdot \mathbb{E}[T_{gen}]}{R_{max} \cdot \alpha_{util}} \right\rceil$$
**解释：** 基于负载预测 $\hat{\lambda}(t+\Delta t)$ 提前计算目标实例数，其中 $\mathbb{E}[T_{gen}]$ 为期望生成时间，$R_{max}$ 为单实例最大吞吐，$\alpha_{util}$ 为目标利用率（通常 0.7-0.8）。预测窗口 $\Delta t$ 通常设置为冷启动时间。
---
### 1.4 实现逻辑
```python
class ElasticLLMInferenceSystem:
"""
大模型推理弹性伸缩系统核心抽象
职责:
- metrics_collector: 实时采集推理服务指标
- scaling_engine: 基于指标做出伸缩决策
- resource_executor: 执行资源伸缩操作
- request_router: 请求路由与负载均衡
- cache_manager: KVCache 管理与迁移
"""
def __init__(self, config):
self.metrics_collector = MetricsCollector(
metrics=['queue_depth', 'gpu_utilization', 'kv_cache_usage', 'p99_latency']
)
self.load_predictor = LoadPredictor(
model='prophet', # 或 LSTM, Transformer
window_size=300, # 5 分钟历史窗口
horizon=60 # 1 分钟预测 horizon
)
self.scaling_engine = ScalingDecisionEngine(
scale_up_threshold=config['scale_up_threshold'], # 通常 10-20
scale_down_threshold=config['scale_down_threshold'], # 通常 2-5
cooldown_period=config['cooldown_seconds'], # 通常 120-300
predictive_scaling=config.get('predictive', True)
)
self.resource_executor = ResourceExecutor(
orchestrator=config['orchestrator'], # kubernetes, keda, ray
min_instances=config['min_instances'],
max_instances=config['max_instances']
)
self.request_router = RequestRouter(
strategy=config['routing_strategy'], # round_robin, least_connections, kv_aware
pd_disaggregation=config.get('pd_disaggregation', False)
)
self.cache_manager = KVCacheManager(
distributed=config.get('distributed_cache', True),
migration_enabled=config.get('cache_migration', True),
backend='mooncake' # 或 redis, memcached
)
def core_operation(self, request_batch):
"""
核心操作：处理请求批并执行弹性伸缩决策
流程:
1. 采集当前系统指标
2. 预测未来负载
3. 路由请求到合适的服务实例
4. 评估是否需要伸缩
5. 执行伸缩操作（如果需要）
6. 管理 KVCache 状态
"""
# Step 1: 采集指标
current_metrics = self.metrics_collector.collect()
# Step 2: 负载预测（提前 1 分钟）
predicted_load = self.load_predictor.predict(
historical_data=self.metrics_collector.get_history(window=300)
)
# Step 3: 请求路由
if self.request_router.pd_disaggregation:
prefill_requests, decode_requests = self._split_by_phase(request_batch)
self.request_router.route(prefill_requests, target='prefill_pool')
self.request_router.route(decode_requests, target='decode_pool')
else:
self.request_router.route(request_batch, target='unified_pool')
# Step 4: 伸缩决策（结合当前指标和预测）
scaling_action = self.scaling_engine.decide(
current_metrics=current_metrics,
predicted_load=predicted_load,
current_instances=self.resource_executor.get_current_count()
)
# Step 5: 执行伸缩
if scaling_action != 'keep':
if scaling_action == 'scale_up':
# 扩容前先预热 KVCache
self.cache_manager.prepare_warmup(
num_new_instances=scaling_action['num_instances']
)
elif scaling_action == 'scale_down':
# 缩容前迁移活跃缓存
self.cache_manager.migrate_from_draining(
num_draining=scaling_action['num_instances']
)
self.resource_executor.execute(scaling_action)
return self._get_serving_status()
def _split_by_phase(self, requests):
"""将请求按 Prefill/Decode 阶段分离"""
prefill_reqs = [r for r in requests if r.phase == 'prefill']
decode_reqs = [r for r in requests if r.phase == 'decode']
return prefill_reqs, decode_reqs
class MetricsCollector:
"""
指标采集器：负责采集推理服务的核心指标
关键指标:
- queue_depth: 等待队列深度（最敏感的负载指标）
- gpu_utilization: GPU 计算利用率
- kv_cache_usage: KVCache 使用率
- p99_latency: P99 请求延迟
- tokens_per_second: Token 生成速率
"""
def __init__(self, metrics):
self.metrics = metrics
self.prometheus_client = PrometheusClient()
def collect(self):
"""采集所有配置的指标"""
collected = {}
for metric in self.metrics:
if metric == 'queue_depth':
collected[metric] = self._get_queue_depth()
elif metric == 'gpu_utilization':
collected[metric] = self._get_gpu_utilization()
elif metric == 'kv_cache_usage':
collected[metric] = self._get_kv_cache_usage()
elif metric == 'p99_latency':
collected[metric] = self._get_p99_latency()
return collected
def _get_queue_depth(self):
"""获取当前等待队列深度"""
# vLLM 暴露的指标
return self.prometheus_client.query('vllm:num_requests_waiting')
def _get_gpu_utilization(self):
"""获取 GPU 利用率"""
# NVIDIA DCGM 指标
return self.prometheus_client.query('DCGM_FI_DEV_GPU_UTIL')
def _get_kv_cache_usage(self):
"""获取 KVCache 使用率"""
return self.prometheus_client.query('vllm:gpu_cache_usage_perc')
def _get_p99_latency(self):
"""获取 P99 延迟"""
return self.prometheus_client.query('vllm:request_latency_p99')
class ScalingDecisionEngine:
"""
伸缩决策引擎：基于指标和策略做出伸缩决策
支持策略:
- 反应式伸缩：基于当前指标阈值
- 预测式伸缩：基于负载预测提前扩容
- 混合式伸缩：反应式 + 预测式结合
"""
def __init__(self, scale_up_threshold, scale_down_threshold,
cooldown_period, predictive_scaling=False):
self.scale_up_threshold = scale_up_threshold
self.scale_down_threshold = scale_down_threshold
self.cooldown_period = cooldown_period
self.predictive_scaling = predictive_scaling
self.last_scale_time = None
def decide(self, current_metrics, predicted_load=None, current_instances=1):
"""基于当前指标和预测负载做出伸缩决策"""
if self._in_cooldown():
return 'keep'
queue_depth = current_metrics.get('queue_depth', 0)
# 反应式决策
if queue_depth > self.scale_up_threshold:
target = self._calculate_target_instances(queue_depth, current_instances)
self.last_scale_time = time.time()
return {'action': 'scale_up', 'target': target, 'num_instances': target - current_instances}
elif queue_depth < self.scale_down_threshold:
target = max(1, current_instances - 1)
self.last_scale_time = time.time()
return {'action': 'scale_down', 'target': target, 'num_instances': current_instances - target}
# 预测式决策（如果启用）
if self.predictive_scaling and predicted_load:
predicted_queue = predicted_load.get('queue_depth', 0)
if predicted_queue > self.scale_up_threshold:
target = self._calculate_target_instances(predicted_queue, current_instances)
if target > current_instances:
self.last_scale_time = time.time()
return {'action': 'scale_up', 'target': target, 'num_instances': target - current_instances}
return 'keep'
def _calculate_target_instances(self, queue_depth, current_instances):
"""基于队列深度计算目标实例数"""
# 每个实例处理能力约 10-20 请求
capacity_per_instance = 15
target = math.ceil(queue_depth / capacity_per_instance)
# 限制单次伸缩幅度
return min(target, current_instances * 2)
def _in_cooldown(self):
"""检查是否在冷却期内"""
if self.last_scale_time is None:
return False
return time.time() - self.last_scale_time < self.cooldown_period
class KVCacheManager:
"""
KVCache 管理器：处理分布式缓存和迁移
支持功能:
- 缓存预热：新实例启动时预加载常用前缀
- 缓存迁移：缩容时将活跃缓存迁移到其他实例
- 缓存共享：多实例共享常用前缀缓存
"""
def __init__(self, distributed, migration_enabled, backend='mooncake'):
self.distributed = distributed
self.migration_enabled = migration_enabled
self.backend = backend
def prepare_warmup(self, num_new_instances):
"""新实例启动前预热 KVCache"""
# 从共享池预加载常用前缀
pass
def migrate_from_draining(self, num_draining):
"""缩容前迁移活跃缓存"""
# 将 draining 实例的缓存迁移到其他实例
pass
```
---
### 1.5 性能指标
| 指标 | 典型目标值 | 测量方式 | 说明 |
|------|-----------|---------|------|
| **弹性延迟** | < 30 秒 | 从触发条件到实例就绪的端到端时间 | 包括冷启动时间，对突发流量的响应能力至关重要。KEDA 通常 10-30 秒，HPA 通常 30-60 秒 |
| **伸缩精度** | > 90% | 实际资源与目标资源的比值 | 避免过度伸缩造成的资源浪费。预测式伸缩可将精度提升至 95%+ |
| **SLO 满足率** | > 99% | 满足延迟 SLO 的请求占比 | 弹性伸缩的首要目标是保障 SLO。生产环境通常要求 P99 延迟 < 500ms |
| **资源利用率** | 60-80% | GPU 有效计算时间占比 | 平衡成本和性能的关键指标。静态配置通常仅 30-40% |
| **冷启动时间** | < 60 秒 | 从创建 Pod 到服务就绪的时间 | 对 scale-from-zero 场景至关重要。模型加载占大部分时间 |
| **KVCache 迁移延迟** | < 100ms | 跨节点传输 KVCache 的时间 | PD 解耦架构的关键性能指标。RDMA 网络可降至 10ms 级 |
| **成本节省率** | 30-50% | 相比静态资源配置的成本降低 | 弹性伸缩的核心价值体现。波动负载下可达 70% |
| **扩容震荡率** | < 5% | 发生频繁伸缩的次数占比 | 衡量伸缩稳定性。通过冷却期和滞回阈值控制 |
| **首 Token 延迟 (TTFT)** | < 500ms (P99) | 端到端基准测试 | Prefill 阶段耗时，直接影响用户感知 |
| **Token 生成速率** | > 50 tokens/s | 负载测试 | Decoding 阶段吞吐量，影响长文本体验 |
---
### 1.6 扩展性与安全性
#### 水平扩展（Scale-Out）
| 策略 | 说明 | 适用场景 | 扩展上限 |
|------|------|----------|---------|
| **无状态扩展** | 通过增加服务实例来线性扩展容量 | 通用场景，最简单 | 单集群 100-500 实例 |
| **PD 解耦扩展** | Prefill 和 Decode 节点池独立扩展 | 长文本、高并发场景 | 分离后可达 1000+ 实例 |
| **KVCache 池化** | 跨节点共享 KVCache，支持动态迁移 | 多轮对话、高 Cache 命中率场景 | 取决于共享池容量 |
| **专家并行弹性** | 动态调整 MoE 模型中激活的专家数量 | 大模型、多租户场景 | 取决于专家数量 |
| **多集群联邦** | 跨多个 Kubernetes 集群调度 | 超大规模、多区域部署 | 理论上无上限 |
#### 垂直扩展（Scale-Up）
| 策略 | 说明 | 上限 |
|------|------|------|
| **GPU 显存优化** | 通过量化、Offloading 等技术扩展单卡支持的最大模型 | 受限于物理显存（A100 80GB, H100 80GB） |
| **张量并行扩展** | 单请求跨多卡并行处理 | 受限于互联带宽（NVLink 600GB/s, NVSwitch 3.2TB/s），通常 2-8 卡 |
| **流水线并行** | 模型层分布在多卡上 | 受限于流水线气泡，通常 4-16 卡 |
| **CPU Offload** | 将部分模型权重 Offload 到 CPU 内存 | 受限于 PCIe 带宽，延迟增加 2-5 倍 |
#### 安全考量
| 风险 | 防护措施 | 实施难度 |
|------|----------|---------|
| **资源耗尽攻击 (DDoS)** | 请求速率限制、租户配额管理、异常检测、弹性上限 | 中 |
| **KVCache 污染** | 租户隔离、Cache 分区、TTL 过期策略、LRU 驱逐 | 中 |
| **弹性震荡攻击** | 冷却时间、滞回阈值、异常模式检测、请求验证 | 低 |
| **多租户侧信道** | 计算隔离、显存加密、时序混淆、调度随机化 | 高 |
| **模型窃取** | API 限频、输出扰动、水印技术、请求审计 | 中 |
| **数据泄露** | 加密传输、KV Cache 隔离、审计日志、访问控制 | 中 |
---
## 维度二：行业情报
### 2.1 GitHub 热门项目（18 个）
| 项目 | Stars | 核心功能 | 技术栈 | 最后更新 | 链接 |
|------|-------|---------|--------|---------|------|
| **vLLM** | ~100k+ | 高吞吐推理引擎，PagedAttention、Continuous Batching、多 LoRA 支持 | Python, CUDA, Triton | 2026-04 | [GitHub](https://github.com/vllm-project/vllm) |
| **SGLang** | ~25k+ | 高性能服务框架，RadixAttention、多轮对话优化、原生 NVIDIA ModelOpt 集成 | Python, CUDA | 2026-04 | [GitHub](https://github.com/sgl-project/sglang) |
| **Text Generation Inference (TGI)** | ~15k | Hugging Face 官方推理服务，生产级部署（维护模式） | Rust, Python, gRPC | 2026-03 | [GitHub](https://github.com/huggingface/text-generation-inference) |
| **Ray / Ray Serve** | ~35k | 分布式计算框架，LLM 应用弹性伸缩、Serve 多模型编排 | Python | 2026-04 | [GitHub](https://github.com/ray-project/ray) |
| **KServe** | ~5k | CNCF 孵化项目，Kubernetes 标准化推理服务、KEDA 集成 | Go, Kubernetes CRD | 2026-04 | [GitHub](https://github.com/kserve/kserve) |
| **BentoML** | ~18k | AI 应用部署框架，支持多种推理后端、OpenLLM 生态 | Python | 2026-04 | [GitHub](https://github.com/bentoml/BentoML) |
| **OpenLLM** | ~8k | 运行任意开源 LLM，BentoML 生态、多框架支持 | Python | 2026-03 | [GitHub](https://github.com/bentoml/OpenLLM) |
| **Mooncake** | ~5k | KVCache 中心化解耦架构，Moonshot AI 出品、支持 Kimi 服务 | C++, Python, RDMA | 2026-03 | [GitHub](https://github.com/kvcache-ai/Mooncake) |
| **DistServe** | ~3k | Prefill-Decode 解耦推理系统、goodput 优化 | Python, CUDA | 2026-02 | [GitHub](https://github.com/LLMServe/DistServe) |
| **vLLM Production Stack** | ~1k | vLLM 生产级参考架构，含 KEDA 集成、Helm Chart | Helm, Kubernetes | 2026-03 | [GitHub](https://github.com/vllm-project/production-stack) |
| **LMDeploy** | ~4k | 高效推理部署工具包，支持量化和 PD 解耦、InternLM 出品 | Python, C++ | 2026-04 | [GitHub](https://github.com/InternLM/lmdeploy) |
| **TensorRT-LLM** | ~15k | NVIDIA 官方推理优化库、FP4/FP8 量化、多 GPU 支持 | C++, CUDA | 2026-04 | [GitHub](https://github.com/NVIDIA/TensorRT-LLM) |
| **KEDA** | ~8k | Kubernetes 事件驱动自动伸缩、Prometheus 触发器 | Go, Kubernetes | 2026-04 | [GitHub](https://github.com/kedacore/keda) |
| **Ollama** | ~80k | 本地 LLM 运行工具，简化部署、支持本地 API 服务 | Go | 2026-04 | [GitHub](https://github.com/ollama/ollama) |
| **Triton Inference Server** | ~10k | NVIDIA 通用推理服务、多框架支持、动态批处理 | C++, Python | 2026-04 | [GitHub](https://github.com/triton-inference-server/server) |
| **llm-d** | ~2k | CNCF 沙盒项目，K8s 原生分布式推理、红帽主导 | Go, Python | 2026-04 | [GitHub](https://github.com/llm-d/llm-d) |
| **KAITO** | ~2k | K8s AI 工具链操作器、KEDA 集成、GPU 自动配置 | Go | 2026-04 | [GitHub](https://github.com/kaito-project/kaito) |
| **llmaz** | ~1k | K8s 上简易高级 LLM 推理平台、InftyAI 出品 | Go | 2026-03 | [GitHub](https://github.com/InftyAI/llmaz) |
---
### 2.2 关键论文（14 篇）
| 论文 | 作者/机构 | 年份 | 会议/期刊 | 核心贡献 | 影响力指标 | 链接 |
|------|----------|------|----------|---------|-----------|------|
| **Taming the Titans: A Survey of Efficient LLM Inference Serving** | Zhou et al. | 2025 | arXiv:2504.19720 | 系统性综述，覆盖实例级和集群级优化技术，包括弹性伸缩 | 高引用 | [arXiv](https://arxiv.org/abs/2504.19720) |
| **Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving** | Qin et al. (Moonshot AI) | 2025 | FAST '25 Best Paper | KVCache 中心化架构，PD 解耦，支撑 Kimi 服务，吞吐提升 525% | FAST 2025 最佳论文 | [arXiv](https://arxiv.org/abs/2407.00079) |
| **DistServe: Disaggregating Prefill and Decoding for Goodput-optimized LLM Serving** | Zhong et al. (PKU, UCSD) | 2024 | OSDI '24 | 首创 Prefill-Decode 解耦架构，优化 goodput | OSDI 接收 | [arXiv](https://arxiv.org/abs/2401.09670) |
| **Hierarchical Autoscaling for Large Language Model Serving with Chiron** | Patke et al. (IBM) | 2025 | arXiv:2501.08090 | Chiron 层次化弹性伸缩，基于背压估计，减少 40% 过度伸缩 | 新兴 SOTA | [arXiv](https://arxiv.org/abs/2501.08090) |
| **Enabling Fast Scaling for Serverless LLM Inference (λScale)** | Wang et al. | 2025 | arXiv:2502.09922 | 无服务器快速弹性系统，解决冷启动问题 | 新兴 SOTA | [arXiv](https://arxiv.org/abs/2502.09922) |
| **A Survey of LLM Inference Systems** | Liu et al. | 2025 | arXiv:2506.21901 | 从算子到系统级的推理技术综述 | 高引用 | [arXiv](https://arxiv.org/abs/2506.21901) |
| **Unlock the Potential of Fine-grained LLM Serving via Dynamic Module Migration** | Chen et al. | 2025 | arXiv:2507.18006 | 细粒度模块级迁移和复制 | 前沿研究 | [arXiv](https://arxiv.org/abs/2507.18006) |
| **Towards Resiliency in LLM Serving with KevlarFlow** | Li et al. | 2026 | arXiv:2601.22438 | KevlarFlow 弹性恢复系统，MTTR 降低 20 倍 | 最新研究 | [arXiv](https://arxiv.org/abs/2601.22438) |
| **WindServe: Efficient Phase-Disaggregated LLM Serving with Stream Scheduling** | Zhang et al. | 2025 | ACM SIGMETRICS | 基于流的阶段解耦调度 | 顶会论文 | [ACM DL](https://dl.acm.org/doi/10.1145/3695053.3730999) |
| **Prefill-Decode Aggregation or Disaggregation? Unifying Both with TaiChi** | Wang et al. | 2025 | arXiv:2508.01989 | TaiChi 统一聚合与解耦架构 | 前沿研究 | [arXiv](https://arxiv.org/html/2508.01989v1) |
| **SageServe: Forecast Aware Auto-Scaling for LLM Serving** | Microsoft Research | 2025 | arXiv:2502.14617 | 预测感知弹性伸缩，SLO 保障优化 | 被引 50+ | [arXiv](https://arxiv.org/abs/2502.14617) |
| **Autopoiesis: A Self-Evolving System Paradigm for LLM Serving** | Meta AI | 2026 | arXiv:2604.07144 | 自进化 LLM 服务范式，应对动态环境 | 最新研究 | [arXiv](https://arxiv.org/abs/2604.07144) |
| **WVA: A Global Optimization Control Plane for LLM Inference** | Google | 2026 | arXiv:2603.09730 | 全局优化控制平面，替代传统 autoscaler | 最新研究 | [arXiv](https://arxiv.org/abs/2603.09730) |
| **BiScale: Energy-Efficient Disaggregated LLM Serving** | ETH Zurich | 2026 | arXiv:2602.18755 | 双阶段能耗优化分离服务 | 最新研究 | [arXiv](https://arxiv.org/abs/2602.18755) |
---
### 2.3 系统化技术博客（12 篇）
| 博客标题 | 作者/来源 | 语言 | 类型 | 核心内容 | 日期 | 链接 |
|---------|----------|------|------|---------|------|------|
| **State of the Model Serving Communities - January 2026** | InferenceOps | 英文 | 社区动态 | vLLM、SGLang 等社区最新进展和路线图 | 2026-01 | [Substack](https://inferenceops.substack.com/p/state-of-the-model-serving-communities-3d1) |
| **A Practical Guide to LLM Inference at Scale** | The Neural Maze | 英文 | 深度教程 | 大规模推理架构模式和最佳实践 | 2025-11 | [Substack](https://theneuralmaze.substack.com/p/a-practical-guide-to-llm-inference) |
| **What goes into an inference stack?** | Nikitha's Newsletter | 英文 | 架构解析 | 现代推理栈各层组件详解 | 2025-08 | [Substack](https://nikitha.substack.com/p/what-goes-into-an-inference-stack) |
| **vLLM 2024 Retrospective and 2025 Vision** | vLLM Team | 英文 | 官方博客 | vLLM 年度回顾与 2025 路线图 | 2025-01 | [vllm.ai](https://vllm.ai/blog/vllm-2024-wrapped-2025-vision) |
| **How to set up KServe autoscaling for vLLM with KEDA** | Red Hat AI Team | 英文 | 实战教程 | KServe + vLLM + KEDA 集成配置 | 2025-09 | [Red Hat](https://developers.redhat.com/articles/2025/09/23/how-set-kserve-autoscaling-vllm-keda) |
| **Scaling LLM Workloads on Kubernetes: A Production Engineer's Guide** | Zartis Engineering | 英文 | 生产实践 | Kubernetes 上 LLM 负载的扩展经验，KEDA 最佳实践 | 2025-10 | [Zartis](https://www.zartis.com/scaling-llm-workloads-on-kubernetes-a-production-engineers-guide/) |
| **Building Production LLM Infrastructure with KServe v0.15** | Simardeep Oberoi | 英文 | 实战教程 | KServe v0.15 生产部署教程，弹性伸缩配置 | 2025-10 | [Medium](https://medium.com/@simardeep.oberoi/building-production-llm-infrastructure-with-kserve-v0-15-a5eecb2311bc) |
| **llm-d: Kubernetes-native distributed inferencing** | Red Hat Developer | 英文 | 技术解析 | CNCF 沙盒项目深度解析，分布式推理架构 | 2025-05 | [Red Hat](https://developers.redhat.com/articles/2025/05/20/llm-d-kubernetes-native-distributed-inferencing) |
| **Removing the Guesswork from Disaggregated Serving** | NVIDIA | 英文 | 官方博客 | 分离式服务最佳实践，PD 解耦配置指南 | 2025-08 | [NVIDIA Blog](https://developer.nvidia.com/blog/removing-the-guesswork-from-disaggregated-serving/) |
| **基于 vllm 自定义指标的多集群 HPA 实践** | 阿里云容器团队 | 中文 | 实战教程 | 阿里云 ACK 上 vLLM 多集群 HPA 实践 | 2025-11 | [阿里云](https://help.aliyun.com/zh/ack/distributed-cloud-container-platform-for-kubernetes/use-cases/implement-multi-cluster-hpa-with-vllm-custom-metrics) |
| **浅谈基于 Kubernetes 的 LLM 分布式推理框架架构** | 阿里云技术团队 | 中文 | 技术解析 | DistServe/Mooncake 架构解析，PD 解耦实践 | 2025-03 | [Heywhale](https://ai.heywhale.com/article/833.html) |
| **An Automatic Scaling Solution for LLM Inference Services Based on Knative** | 阿里云 | 中文 | 解决方案 | Knative 自动伸缩方案，Serverless 场景优化 | 2025-05 | [AlibabaCloud](https://www.alibabacloud.com/blog/an-automatic-scaling-solution-for-llm-inference-services-based-on-knative_602223) |
---
### 2.4 技术演进时间线
| 时间 | 事件 | 发起方 | 影响 |
|------|------|--------|------|
| **2023 Q2** | vLLM 发布，引入 PagedAttention | UC Berkeley | 开启了高效 LLM 推理的新纪元，KV Cache 管理成为标准 |
| **2023 Q3** | TGI 成为 Hugging Face 官方推理后端 | Hugging Face | 推动了 Rust 在推理服务中的应用，目前进入维护模式 |
| **2023 Q4** | Ray Serve 增强 LLM 支持 | Anyscale | 为分布式 LLM 应用提供了弹性基础 |
| **2024 Q1** | DistServe 提出 Prefill-Decode 解耦 | 北大 & UCSD | 开创了 PD 解耦架构新方向，OSDI '24 接收 |
| **2024 Q2** | KServe 成为 CNCF 孵化项目 | CNCF | 标准化了 Kubernetes 推理服务 |
| **2024 Q3** | Mooncake 架构支撑 Kimi 服务 | Moonshot AI | 验证了 KVCache 中心化架构的生产可行性，FAST '25 最佳论文 |
| **2024 Q4** | KEDA + LLM 集成成熟 | KEDA Community | 事件驱动 autoscaling 成为 LLM 服务标准实践 |
| **2025 Q1** | vLLM Production Stack 发布 | vLLM Team | 提供了生产级参考架构，含 KEDA 集成 |
| **2025 Q2** | KServe v0.15 发布，增强 KEDA 集成 | KServe Team | 改进了事件驱动弹性伸缩能力 |
| **2025 Q3** | Chiron 层次化弹性伸缩论文发表 | IBM Research | 提出了基于背压估计的新方法，减少 40% 过度伸缩 |
| **2025 Q4** | λScale 无服务器快速弹性系统 | 学术界 | 解决了 serverless 场景的冷启动问题 |
| **2025 Q4** | SageServe 预测感知弹性伸缩 | Microsoft Research | 将负载预测引入伸缩决策，SLO 保障优化 |
| **2026 Q1** | KevlarFlow 弹性恢复系统 | 学术界 | 将故障恢复时间缩短至 30 秒，MTTR 降低 20 倍 |
| **2026 Q1** | Autopoiesis 自进化服务范式 | Meta AI | 提出自进化 LLM 服务，应对动态环境 |
| **2026 Q2** | **当前状态** | 行业共识 | PD 解耦 + KEDA 事件驱动 + 预测感知成为主流实践 |
---
## 维度三：方案对比
### 3.1 历史发展时间线
```
2023 ─┬─ vLLM 发布 (PagedAttention) → 开启高效 LLM 推理新纪元
│
├─ TGI 成为 HF 官方后端 → Rust 推理服务兴起
│
2024 ─┼─ DistServe 提出 PD 解耦 → 分离 Prefill/Decode 阶段优化
│
├─ Mooncake 架构落地 (Kimi 服务) → KVCache 中心化架构验证
│
├─ KEDA + LLM 集成成熟 → 事件驱动弹性成为标准
│
2025 ─┼─ Chiron 层次化弹性发表 → 基于背压估计的精准伸缩
│
├─ λScale 无服务器快速弹性 → 解决冷启动问题
│
├─ SageServe 预测感知弹性 → 负载预测引入伸缩决策
│
├─ vLLM Production Stack 发布 → 生产级参考架构成熟
│
2026 ─┼─ KevlarFlow 弹性恢复 → MTTR 降低 20 倍
│
├─ Autopoiesis 自进化服务 → 下一代自进化范式
│
└─ 当前状态：PD 解耦 + KEDA 事件驱动 + 预测感知成为行业标准实践
```
---
### 3.2 六种方案横向对比
| 方案 | 原理 | 优点（3+） | 缺点（3+） | 适用场景 | 成本量级 |
|------|------|-----------|-----------|---------|---------|
| **Kubernetes HPA + 自定义指标** | 基于 Prometheus 采集的推理专用指标（队列深度、等待请求数）触发 Pod 伸缩 | 1. 原生 K8s 支持，无需额外组件<br>2. 配置简单，学习曲线低<br>3. 生态成熟，文档丰富 | 1. 响应延迟较高（30-60 秒）<br>2. 不支持 scale-to-zero<br>3. 指标更新频率受限（通常 15-30 秒） | 中小型生产环境，已有 K8s 基础设施的团队，原型验证 | $ |
| **KEDA 事件驱动弹性** | 基于外部事件源（Prometheus、Kafka 等）触发伸缩，支持 scale-to-zero | 1. 支持 scale-to-zero，节省空闲成本<br>2. 响应更快（10-30 秒）<br>3. 支持多种事件源，灵活性强 | 1. 需要额外部署 KEDA 组件<br>2. 配置相对复杂<br>3. 对事件源依赖性强 | 流量波动大的 ToC 场景，Serverless 部署，成本敏感业务 | $$ |
| **Ray Serve 应用级弹性** | Ray 框架内的应用级弹性伸缩，支持跨部署协调、多模型流水线 | 1. 支持复杂的多模型流水线<br>2. 细粒度的资源控制<br>3. 与 Ray 生态深度集成 | 1. 学习曲线较陡<br>2. 需要 Ray 运行时环境<br>3. 社区相对较小，资源开销较大 | 复杂 LLM 应用，多模型协同场景，研究团队 | $$$ |
| **KServe + KEDA 生产级** | CNCF 标准化模型服务 + 事件驱动弹性，生产级验证 | 1. 生产级验证，企业采用<br>2. 多框架支持（vLLM/TensorRT/Triton）<br>3. CNCF 社区活跃 | 1. 配置复杂，需要 K8s 专业知识<br>2. 组件较多，运维成本高<br>3. 定制化开发难度大 | 企业级生产环境，多团队协作，混合云部署 | $$$ |
| **PD 解耦弹性 (Mooncake/DistServe)** | 将 Prefill 和 Decode 阶段分离到不同节点池，独立弹性伸缩 | 1. 资源利用率显著提升（30-50%）<br>2. 针对两阶段特性优化<br>3. 支持长文本和高并发，SLO 保障好 | 1. 架构复杂度高<br>2. 需要 KVCache 传输机制（RDMA）<br>3. 部署运维成本高 | 长文本、高并发、生产级大规模部署，成本敏感业务 | $$$$ |
| **预测感知弹性 (SageServe/Chiron)** | 基于负载预测提前扩容，结合背压估计做出精准决策 | 1. 伸缩决策更精准，减少震荡<br>2. 提前扩容，降低 SLO 违约风险<br>3. 适应复杂负载模式 | 1. 需要训练预测模型<br>2. 实现复杂度高<br>3. 预测准确性依赖历史数据质量 | 超大规模部署，负载模式可预测场景，对 SLO 要求极高 | $$$$ |
---
### 3.3 技术细节对比
| 维度 | HPA+ 自定义指标 | KEDA | Ray Serve | KServe+KEDA | PD 解耦 | 预测感知弹性 |
|------|---------------|------|-----------|-------------|---------|-------------|
| **响应延迟** | 30-60 秒 | 10-30 秒 | 5-20 秒 | 10-30 秒 | 5-15 秒 | 5-10 秒（提前） |
| **资源利用率** | 30-40% | 50-60% | 50-60% | 50-60% | 70-80% | 60-70% |
| **易用性** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐ |
| **生态成熟度** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ |
| **社区活跃度** | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ |
| **学习曲线** | 低 | 中 | 高 | 中高 | 高 | 高 |
| **scale-to-zero** | ❌ | ✅ | ⚠️ | ✅ | ❌ | ⚠️ |
| **多集群支持** | ⚠️ | ⚠️ | ✅ | ✅ | ❌ | ❌ |
| **KVCache 感知** | ❌ | ❌ | ⚠️ | ⚠️ | ✅ | ⚠️ |
| **SLO 保障** | 中 | 高 | 高 | 高 | 极高 | 极高 |
| **冷启动优化** | ❌ | ⚠️ | ✅ | ⚠️ | ✅ | ✅ |
---
### 3.4 选型建议
| 场景 | 推荐方案 | 核心理由 | 预估月成本 |
|------|---------|---------|-----------|
| **小型项目/原型验证** | Kubernetes HPA + vLLM | 配置最简单，快速启动，适合验证 MVP | $500-2,000 (1-2 卡) |
| **流量波动大的 ToC 应用** | KEDA + vLLM | 支持 scale-to-zero，闲时成本极低，响应快 | $2,000-10,000 (2-10 卡) |
| **中型生产环境** | KEDA + vLLM Production Stack | 生产级参考架构，平衡性能和成本，社区支持好 | $10,000-50,000 (10-50 卡) |
| **企业级多模型服务** | KServe + KEDA + Ray | 标准化、多框架支持、团队协作友好、多集群 | $20,000-100,000 (20-100 卡) |
| **长文本高并发场景** | PD 解耦 (Mooncake/DistServe) | Prefill/Decode 分离，资源利用率最大化，SLO 好 | $50,000-200,000 (50-200 卡，节省 30-50%) |
| **超大规模 SLO 敏感** | 预测感知弹性 (SageServe/Chiron) | 提前扩容降低 SLO 违约，精准决策减少浪费 | $100,000+ (100+ 卡) |
| **突发负载/Serverless** | KEDA 缩容到 0 + λScale | 无请求时零成本，突发时快速扩容，冷启动优化 | 按量付费，节省 60-80% |
**成本估算假设：**
- 基于 2026 年云 GPU 价格（A100 约$3-4/小时，H100 约$5-7/小时，A10 约$1-2/小时）
- 包含实例成本、网络成本、运维人力成本估算
- 实际成本因云厂商、预留实例、竞价实例等因素浮动
- 流量基准：100 万 tokens/日，峰值/谷值比 5:1
---
### 3.5 选型决策树
```
需求分析
│
├── 是否需要生产级 SLO 保障 (>99.9%)？
│ ├── 否 → HPA + vLLM (快速验证)
│ └── 是 → 继续
│
├── 负载是否高度波动（峰值/谷值>5 倍）？
│ ├── 是 → KEDA (支持缩容到 0)
│ └── 否 → 继续
│
├── 是否需要多模型/多框架支持？
│ ├── 是 → KServe 或 Ray Serve
│ └── 否 → 继续
│
├── 成本是否为核心约束（>30% 优化目标）？
│ ├── 是 → DistServe (PD 分离) 或 Mooncake
│ └── 否 → 继续
│
├── SLO 违约代价是否极高？
│ ├── 是 → 预测感知弹性 (SageServe/Chiron)
│ └── 否 → KEDA + vLLM Production Stack (平衡方案)
│
└── 团队 K8s 专业程度？
├── 低 → KEDA + vLLM Production Stack
└── 高 → 自定义 KServe/Ray/PD 解耦方案
```
---
## 维度四：精华整合
### 4.1 The One 公式
$$\text{LLM 弹性伸缩} = \underbrace{\text{智能指标}}_{\text{队列深度 + 延迟}} + \underbrace{\text{预测模型}}_{\text{负载 forecasting}} - \underbrace{\text{伸缩震荡}}_{\text{冷却期 + 平滑}}$$
**解读：** 弹性伸缩的本质是在及时响应和避免震荡之间找到平衡点——用准确的指标感知负载（队列深度比 GPU 利用率更敏感），用预测模型提前行动（应对冷启动延迟），用冷却机制消除抖动（避免成本浪费）。
---
### 4.2 一句话解释
> **大模型推理弹性伸缩就像"智能电梯调度系统"：根据候梯人数（队列深度）和楼层分布（请求特征），动态调整运行的电梯数量（GPU 实例），既不让乘客等太久（SLO 保障），也不让电梯空跑浪费电（成本优化）。与通用伸缩不同的是，它还能预测高峰期提前调度，并且在电梯间共享乘客信息（KVCache 共享）减少重复等待。**
---
### 4.3 核心架构图
```
用户请求 → [Gateway] → [智能路由] → [推理实例池] → 响应
↓ ↓ ↓
[指标收集] [KV Cache] [伸缩决策]
↓ ↓ ↓
Prometheus Mooncake KEDA/Ray
↓ ↓ ↓
队列深度 缓存共享 预测模型
P99 延迟 前缀复用 冷却机制
```
---
### 4.4 STAR 总结
| 部分 | 内容 |
|------|------|
| **Situation（背景 + 痛点）** | 大模型推理服务面临三大挑战：(1) 请求负载高度波动，峰值谷值差异可达 10 倍以上，流量预测困难；(2) GPU 资源成本高昂，单卡月成本数千美元，闲置浪费严重，静态配置资源利用率仅 30-40%；(3) 用户对延迟敏感，首 Token 延迟超过 500ms 即影响体验，SLO 违约代价高。传统 Kubernetes HPA 基于 CPU/内存指标，无法有效应对 LLM 推理的特殊性（KVCache 状态、两阶段特性、冷启动延迟），导致要么资源过剩成本高，要么资源不足 SLO 违约。 |
| **Task（核心问题）** | 设计弹性伸缩机制需解决：(1) 选择正确的伸缩指标（队列深度、P99 延迟而非 CPU）；(2) 平衡响应速度与稳定性（避免伸缩震荡）；(3) 处理 LLM 状态性（KV Cache 迁移与预热）；(4) 在 SLO 保障与成本优化间找到最优平衡点；(5) 应对冷启动延迟（30-60 秒）提前扩容。关键约束包括 GPU 冷启动时间、KVCache 状态迁移、Prefill/Decode 阶段异质性、多租户隔离需求。 |
| **Action（主流方案）** | 技术演进历经三阶段：(1) **基础弹性 (2023)**：vLLM 引入 PagedAttention 优化单实例效率，K8s HPA 基于自定义指标伸缩；(2) **指标感知弹性 (2024)**：KEDA+Prometheus 成为事件驱动伸缩标准，DistServe 提出 Prefill-Decode 解耦，Mooncake 实现 KVCache 分离架构；(3) **预测感知弹性 (2025-2026)**：SageServe 引入预测感知伸缩，Chiron 层次化弹性基于背压估计，KevlarFlow 弹性恢复系统将 MTTR 降低 20 倍，Autopoiesis 探索自进化系统。当前最佳实践是 KEDA 基于队列深度伸缩 + 预测模型提前扩容 + KVCache 分离共享。 |
| **Result（效果 + 建议）** | 现代方案可实现：(1) SLO 达成率>99.9%；(2) 资源利用率 60-80%（较静态配置提升 2 倍）；(3) 成本较静态部署降低 30-50%，波动负载下可达 70%；(4) 弹性响应时间 10-30 秒。选型建议：小型项目用 HPA+vLLM 快速验证，中型生产用 KEDA+Prometheus 平衡成本与稳定性，大规模集群考虑 PD 解耦 (Mooncake/DistServe) 或预测感知弹性 (SageServe) 实现极致优化。未来趋势是无服务器快速弹性（λScale）、细粒度模块级迁移、和自进化系统（Autopoiesis）。 |
---
### 4.5 理解确认问题
**问题：** 为什么在 LLM 推理弹性伸缩中，基于"请求队列深度"比基于"GPU 利用率"更适合作为伸缩指标？请从指标敏感性、滞后性、和 LLM 推理特性三个角度分析。
**参考答案：**
1. **指标敏感性**：队列深度直接反映等待处理的请求数，当队列从 0 增加到 10 时，意味着已有 10 个请求在等待，延迟即将上升。而 GPU 利用率可能在高并发批处理下保持 90%+，但新请求仍需等待当前批次完成，无法敏感反映拥塞。
2. **滞后性**：GPU 利用率是滞后指标——当 GPU 利用率升高时，请求已经排队等待，延迟已经产生。此时再扩容，新实例冷启动需要 30-60 秒，SLO 已经违约。队列深度是先行指标，能在延迟恶化前（队列累积初期）触发扩容。
3. **LLM 推理特性**：
- **Continuous Batching**：vLLM 等引擎采用连续批处理，GPU 利用率可能保持高位但实际是新请求在等待批次完成
- **KVCache 约束**：GPU 利用率无法反映 KVCache 状态，高缓存命中率场景下 GPU 利用率低但实际处理能力高
- **两阶段异质性**：Prefill 阶段 GPU 利用率高，Decode 阶段 GPU 利用率低但显存占用高，单一 GPU 利用率指标无法区分
因此，队列深度 + P99 延迟的组合指标比单一 GPU 利用率更适合 LLM 弹性伸缩决策。
---
## 参考文献
### 核心论文
1. Taming the Titans: A Survey of Efficient LLM Inference Serving - arXiv:2504.19720
2. Mooncake: A KVCache-centric Disaggregated Architecture - arXiv:2407.00079 (FAST '25 Best Paper)
3. DistServe: Disaggregating Prefill and Decoding - OSDI '24
4. Hierarchical Autoscaling with Chiron - arXiv:2501.08090
5. SageServe: Forecast Aware Auto-Scaling - arXiv:2502.14617
6. Autopoiesis: A Self-Evolving System Paradigm - arXiv:2604.07144
### 开源项目
1. vLLM: https://github.com/vllm-project/vllm (~100k stars)
2. SGLang: https://github.com/sgl-project/sglang (~25k stars)
3. KServe: https://github.com/kserve/kserve (~5k stars)
4. KEDA: https://github.com/kedacore/keda (~8k stars)
5. Mooncake: https://github.com/kvcache-ai/Mooncake (~5k stars)
6. llm-d: https://github.com/llm-d/llm-d (CNCF Sandbox)
### 技术博客
1. vLLM 2024 Retrospective: https://vllm.ai/blog/vllm-2024-wrapped-2025-vision
2. InferenceOps Newsletter: https://inferenceops.substack.com
3. The Neural Maze: https://theneuralmaze.substack.com
4. Red Hat AI Blog: https://developers.redhat.com
5. NVIDIA Developer Blog: https://developer.nvidia.com/blog
---
**报告完成日期：** 2026-04-11
**总字数：** 约 10,000 字
**数据来源：** WebSearch 实时检索（2026-04-11）
**报告版本：** 3.0
评论
评论加载中...