AI 推理服务扩容：K8s HPA 与 GPU 弹性调度的生产实践

AI 推理服务扩容：K8s HPA 与 GPU 弹性调度的生产实践

一、GPU 扩容的时间困局：冷启动延迟与流量突发的矛盾

AI 推理服务的扩容面临一个独特挑战：GPU 实例的冷启动时间远超传统 CPU 服务。一个 CPU 微服务实例从启动到就绪通常只需 3-5 秒，而一个 GPU 推理实例需要加载模型权重到显存，冷启动时间通常在 30-120 秒之间。对于 70B 参数的大模型，权重加载甚至需要 2-3 分钟。这意味着当流量突发时，传统的 HPA 机制根本来不及扩容。

某 AI 对话平台在一次社交媒体传播后，流量在 5 分钟内增长 8 倍。K8s HPA 检测到 GPU 利用率超过阈值后触发扩容，但新 Pod 从调度到模型加载完成耗时 90 秒。在这 90 秒内，已有实例的推理队列深度从 5 飙升到 200，大量请求因超时被拒绝。流量高峰过后，HPA 又触发缩容，刚加载好模型的实例被销毁，GPU 资源被浪费。

二、GPU 弹性调度的核心机制：预测性扩缩容与分时复用

GPU 弹性调度的核心思想是将"被动响应"转变为"主动预测"，并通过分时复用提升 GPU 利用率。

flowchart TB A[流量指标采集] --> B[时序预测模型] B --> C{预测流量趋势} C -->|上升| D[提前扩容：预热池分配] C -->|平稳| E[维持当前容量] C -->|下降| F[延迟缩容：回收到预热池] subgraph 预热池机制 G[预热实例池] --> H[已加载模型，待命] I[缩容实例] --> G D --> G end subgraph 分时复用 J[推理服务] --> K[GPU 时间片 T1] L[训练任务] --> M[GPU 时间片 T2] N[批量推理] --> O[GPU 时间片 T3] K --> P[GPU 硬件] M --> P O --> P end subgraph 扩缩容决策引擎 Q[实时指标] --> R[GPU 利用率] Q --> S[推理队列深度] Q --> T[请求延迟 P99] Q --> U[预测流量曲线] R --> V[综合决策] S --> V T --> V U --> V V --> W{扩缩容动作} end H --> V

预测性扩缩容基于历史流量模式训练时序预测模型（如 Prophet 或 LSTM），在流量高峰到来前 5-10 分钟提前触发扩容。预测模型以过去 7 天的流量曲线为输入，输出未来 30 分钟的流量预测。预测准确率在规律性流量（如每日固定高峰）下可达 85% 以上，但对突发事件（如社交媒体传播）仍需配合实时指标兜底。

预热池机制将缩容的实例不直接销毁，而是回收到预热池保持待命状态。预热池中的实例已加载模型权重，可随时接收流量。这解决了冷启动延迟问题，但代价是预热池中的 GPU 资源被闲置占用。

GPU 分时复用在推理低峰期将 GPU 资源临时分配给训练任务或批量推理任务，推理流量上升时再回收。这需要底层支持 GPU 上下文快速切换，目前可通过 MPS（Multi-Process Service）或 MIG（Multi-Instance GPU）实现。

三、生产级 GPU 弹性调度的代码实现

3.1 预测性扩缩容引擎

""" 基于时序预测的 GPU 扩缩容引擎 为什么需要预测而非纯响应式？ 响应式 HPA 从指标超阈值到实例就需至少 90 秒， 对于流量在 5 分钟内增长 8 倍的场景根本来不及， 预测性扩容将响应时间从 90 秒压缩到 5 秒（预热池取实例） """ import numpy as np from prophet import Prophet from kubernetes import client class PredictiveGPUScaler: def __init__(self, namespace: str, deployment: str, warm_pool_size: int = 2): self.namespace = namespace self.deployment = deployment self.warm_pool_size = warm_pool_size self.k8s_apps = client.AppsV1Api() self.model = None self._train_model() def _train_model(self): """训练流量预测模型""" # 从 Prometheus 获取过去 7 天的 QPS 数据 history = self._fetch_qps_history(days=7) df = self._prepare_prophet_df(history) self.model = Prophet( changepoint_prior_scale=0.05, # 为什么设为 0.05？较小的值使模型更平滑， # 避免对噪声过度拟合，AI 推理流量通常有规律性 seasonality_prior_scale=10, daily_seasonality=True, weekly_seasonality=True, ) self.model.fit(df) def predict_qps(self, minutes: int = 30) -> np.ndarray: """预测未来 N 分钟的 QPS""" future = self.model.make_future_dataframe( periods=minutes, freq='min' ) forecast = self.model.predict(future) # 取预测上限，宁可多扩不可少扩 # 为什么取上限？扩容不足的代价（服务不可用） # 远大于扩容过度的代价（资源浪费） return forecast['yhat_upper'].tail(minutes).values def calculate_target_replicas(self, predicted_qps: np.ndarray, current_replicas: int) -> int: """根据预测 QPS 计算目标副本数""" # 单实例稳态处理能力（经压测标定） QPS_PER_INSTANCE = 25 # 安全系数 1.2：预留 20% 缓冲 SAFETY_FACTOR = 1.2 # 取未来 10 分钟的峰值 QPS（而非平均值） # 为什么取峰值？扩容必须覆盖最坏情况 peak_qps = np.max(predicted_qps[:10]) target = int(np.ceil(peak_qps * SAFETY_FACTOR / QPS_PER_INSTANCE)) # 限制扩容步长：单次最多扩 5 个实例 # 为什么限制步长？预测可能不准确， # 逐步扩容可避免过度分配 max_step = 5 target = min(target, current_replicas + max_step) return max(target, 2) # 最少 2 副本保证高可用 def scale_if_needed(self): """执行扩缩容决策""" predicted = self.predict_qps(minutes=30) current = self._get_current_replicas() target = self.calculate_target_replicas(predicted, current) if target != current: self._scale_to(target) self._log_scale_event(current, target, predicted)

3.2 预热池管理器（K8s CRD 实现）

# WarmPool 自定义资源定义 # 为什么用 CRD 而非简单的 Deployment 副本数？ # 预热池实例需要特殊标记（已加载模型、不接收流量）， # CRD 可以精确控制预热实例的生命周期和流量接入时机 apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: warmpools.scaling.ai-platform.io spec: group: scaling.ai-platform.io versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: minWarm: type: integer description: 最少预热实例数 maxWarm: type: integer description: 最多预热实例数 modelImage: type: string description: 推理服务镜像 modelPath: type: string description: 模型权重路径 healthCheckPath: type: string description: 健康检查路径 status: type: object properties: warmCount: type: integer availableCount: type: integer

""" 预热池控制器——管理预热实例的生命周期 """ class WarmPoolController: def reconcile(self, warm_pool: WarmPool): """调谐逻辑：确保预热池实例数符合期望""" current_warm = self._count_warm_instances(warm_pool) desired_warm = warm_pool.spec.min_warm if current_warm < desired_warm: # 补充预热实例 for _ in range(desired_warm - current_warm): self._create_warm_instance(warm_pool) elif current_warm > warm_pool.spec.max_warm: # 回收多余预热实例 excess = current_warm - warm_pool.spec.max_warm self._remove_warm_instances(warm_pool, count=excess) def _create_warm_instance(self, warm_pool: WarmPool): """创建预热实例""" pod = client.V1Pod( metadata=client.V1ObjectMeta( generate_name=f"{warm_pool.name}-warm-", labels={ "app": warm_pool.spec.model_image, "warm-pool": "true", # 标记为预热实例，Service 不会路由流量 "model-loaded": "pending", } ), spec=client.V1PodSpec( containers=[{ "name": "inference", "image": warm_pool.spec.model_image, "resources": { "limits": { "nvidia.com/gpu": "1" } }, # 启动时预加载模型 "env": [{ "name": "PRELOAD_MODEL", "value": warm_pool.spec.model_path }], "readinessProbe": { "httpGet": { "path": warm_pool.spec.health_check_path, "port": 8080 }, "initialDelaySeconds": 30, "periodSeconds": 10, # 为什么 initialDelaySeconds=30？ # 模型加载需要时间，过早探测会反复失败 } }] ) ) self.k8s_core.create_namespaced_pod( namespace=self.namespace, body=pod ) def acquire_warm_instance(self, warm_pool: WarmPool) -> Optional[str]: """从预热池获取一个就绪实例""" # 查找已加载模型的预热实例 pods = self.k8s_core.list_namespaced_pod( namespace=self.namespace, label_selector=f"app={warm_pool.spec.model_image}," f"warm-pool=true,model-loaded=ready" ) if not pods.items: return None pod = pods.items[0] # 移除预热标记，接入 Service 流量 self.k8s_core.patch_namespaced_pod( name=pod.metadata.name, namespace=self.namespace, body={ "metadata": { "labels": { "warm-pool": "false", "model-loaded": "serving" } } } ) return pod.metadata.name

3.3 GPU 分时复用调度

""" GPU 分时复用调度器——推理低峰期让出 GPU 给训练任务 为什么需要分时复用？ GPU 利用率统计显示推理服务日均利用率仅 45%， 低峰期（凌晨 0-6 点）利用率不足 15%， 这些闲置 GPU 可用于离线训练，节省 30% 的 GPU 采购成本 """ class GPUTimeSharingScheduler: def __init__(self): self.schedule = { # 时段配置：推理优先级 (0, 6): "training", # 凌晨：训练任务优先 (6, 9): "inference", # 早高峰前：切换回推理 (9, 22): "inference", # 白天：推理优先 (22, 24): "training", # 深夜：训练任务优先 } def should_yield_gpu(self, current_hour: int, inference_queue_depth: int) -> bool: """ 判断当前推理实例是否应该让出 GPU 不会在推理高峰期让出 GPU，即使当前利用率低 """ phase = self._get_phase(current_hour) if phase == "inference": # 推理优先时段：不让出 GPU return False if phase == "training": # 训练优先时段：仅在推理队列空闲时让出 # 为什么需要队列空闲？训练任务启动后不可中断， # 必须确保推理请求不会因 GPU 被占用而排队 return inference_queue_depth < 5 return False def switch_to_training(self, gpu_id: int, training_job: str): """将 GPU 从推理切换到训练""" # Step 1: 驱逐推理 Pod（优雅终止） self._evict_inference_pod(gpu_id, grace_period=30) # Step 2: 清理 GPU 显存 self._flush_gpu_memory(gpu_id) # Step 3: 启动训练 Pod self._launch_training_pod(gpu_id, training_job) def switch_to_inference(self, gpu_id: int): """将 GPU 从训练切换回推理""" # Step 1: 发送 checkpoint 信号给训练任务 self._signal_checkpoint(gpu_id) # Step 2: 等待 checkpoint 完成（最多 120 秒） self._wait_checkpoint(gpu_id, timeout=120) # Step 3: 驱逐训练 Pod self._evict_training_pod(gpu_id, grace_period=10) # Step 4: 从预热池取推理实例或启动新实例 self._launch_inference_pod(gpu_id)

四、GPU 弹性调度的架构权衡

预热池的成本与收益：预热池以 GPU 闲置为代价换取快速扩容能力。以 A100 为例，2 台预热实例的月成本约 10 万元。需要根据业务 SLA 严格计算：每分钟服务不可用的业务损失 vs 预热池的 GPU 成本。对于 SLA 要求 99.99% 的核心服务，预热池是必要投资；对于可容忍短暂排队的内部服务，预热池可能是过度设计。

预测模型的准确性：时序预测对规律性流量效果良好，但对突发事件（如社交媒体传播、竞品故障导致流量涌入）无法预测。预测准确率在 80%-90% 之间，剩余 10%-20% 的场景仍需响应式 HPA 兜底。

分时复用的切换开销：GPU 上下文切换需要驱逐当前 Pod、清理显存、加载新模型，整个切换过程约 2-3 分钟。频繁切换会导致 GPU 有效计算时间减少，分时复用的收益被切换开销抵消。切换频率应控制在每天不超过 2 次。

适用边界：GPU 弹性调度适用于流量有规律性波动、GPU 资源昂贵且有限、SLA 要求高的 AI 推理平台。流量稳定且 GPU 资源充足的场景，固定副本数 + 手动扩缩容即可满足需求。

禁用场景：实时性要求极高的推理服务（如自动驾驶决策），不可接受任何扩缩容导致的短暂不可用，应按峰值固定配置 GPU 资源。

五、总结

GPU 弹性调度的核心是将"被动响应"转变为"主动预测"。预测性扩缩容在流量高峰前提前准备资源，预热池消除冷启动延迟，分时复用在低峰期提升 GPU 利用率。三者协同构建了 AI 推理服务的弹性调度体系。

落地路线建议：第一步，部署 GPU 指标采集体系（DCGM Exporter + 自定义 Metrics）；第二步，实现预热池 CRD 和控制器，替代 K8s 原生 HPA；第三步，训练流量预测模型，实现预测性扩缩容；第四步，在低峰期试点 GPU 分时复用，验证切换流程的可靠性；第五步，建立扩缩容效率监控看板，跟踪扩容响应时间、预测准确率和 GPU 利用率。GPU 资源的每一分投入都应被精确调度，弹性不是浪费的借口，而是效率的保障。