大模型推理服务的弹性伸缩架构——基于 GPU 指标的 HPA 策略-育师

大模型推理服务的弹性伸缩架构——基于 GPU 指标的 HPA 策略

一、问题背景与核心矛盾

大模型推理服务与传统的无状态 Web 服务在资源需求上存在本质差异。传统服务以 CPU 和内存为核心指标，通过 Kubernetes HPA（Horizontal Pod Autoscaler）即可实现较为准确的弹性伸缩。然而，大模型推理服务的核心瓶颈在于 GPU 显存占用和计算利用率，CPU 使用率与服务质量之间并不存在线性映射关系。

在实际生产环境中，曾经出现这样一个典型场景：某对话服务的 GPU 利用率已经接近 95%，但 CPU 使用率仅为 30%，按照默认的 CPU-based HPA 策略，系统并不会触发扩容，导致请求排队时间从 200ms 飙升至 5s 以上。这说明基于 CPU 的伸缩策略在面对 GPU 密集型工作负载时存在根本性缺陷。

核心矛盾可以归纳为以下三点：

GPU 利用率与 CPU 利用率不耦合，CPU 指标无法反映 GPU 瓶颈。
模型加载时间较长（数十秒到分钟级），冷启动延迟严重影响弹性响应速度。
GPU 资源成本高昂，过度扩容会造成显著的资源浪费。

二、GPU 指标的采集与暴露

要实现基于 GPU 指标的 HPA，第一步是在 Kubernetes 集群中采集并暴露 GPU 相关指标。在技术选型层面，DCGM（NVIDIA Data Center GPU Manager）是目前较为成熟的方案。

/** * GPU指标采集器——通过 DCGM Exporter 的 Prometheus 接口拉取 GPU 指标， * 并将其转换为 Kubernetes Metrics API 可消费的格式。 * * 为什么用 Pull 模式而非 Push 模式：避免 GPU 节点上的采集 Agent 成为性能瓶颈， * 同时保持指标采集链路与现有 Prometheus 体系的一致性。 */ @Service public class GpuMetricsCollector { private static final Logger log = LoggerFactory.getLogger(GpuMetricsCollector.class); private final RestTemplate restTemplate; private final String dcgmExporterUrl; public GpuMetricsCollector( @Value("${monitor.dcgm.exporter.url}") String dcgmExporterUrl, RestTemplateBuilder builder) { this.dcgmExporterUrl = dcgmExporterUrl; // 为什么设置较长超时：GPU 指标采集涉及硬件查询，响应时间可能超过默认的 1s this.restTemplate = builder .connectTimeout(Duration.ofSeconds(5)) .readTimeout(Duration.ofSeconds(10)) .build(); } /** * 采集指定 GPU 设备的利用率指标。 * * @param gpuDevice GPU 设备编号（如 nvidia0） * @return GPU 利用率（0.0~1.0），采集失败返回 -1 表示不可用 */ public double collectGpuUtilization(String gpuDevice) { try { String query = String.format( "DCGM_FI_DEV_GPU_UTIL{device=\"%s\"}", gpuDevice); String url = dcgmExporterUrl + "/api/v1/query?query=" + URLEncoder.encode(query, StandardCharsets.UTF_8); ResponseEntity<PrometheusResponse> response = restTemplate.getForEntity( url, PrometheusResponse.class); if (response.getStatusCode() == HttpStatus.OK && response.getBody() != null) { return parseGpuUtilization(response.getBody()); } } catch (RestClientException e) { // 为什么记录 WARN 而非 ERROR：单次采集失败不影响整体伸缩决策， // 多次失败后会通过指标缺失自动触发告警 log.warn("GPU指标采集失败, device={}, 原因={}", gpuDevice, e.getMessage()); } return -1.0; } private double parseGpuUtilization(PrometheusResponse response) { if (response.getData() == null || response.getData().getResult() == null || response.getData().getResult().isEmpty()) { return -1.0; } try { String value = response.getData().getResult().get(0).getValue()[1]; return Double.parseDouble(value); } catch (NumberFormatException e) { log.warn("GPU利用率数值解析异常, rawValue={}", response.getData().getResult().get(0).getValue()[1]); return -1.0; } } }

DCGM Exporter 将 GPU 指标暴露为 Prometheus 格式，再通过 Prometheus Adapter 转换为 Kubernetes Custom Metrics API。Prometheus Adapter 的配置决定了哪些指标可供 HPA 使用。

三、HPA 策略设计

基于 GPU 指标的 HPA 不能简单地照搬 CPU-based HPA 的配置模式，需要针对业务场景进行差异化设计。

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: llm-inference-hpa namespace: ai-inference spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: llm-inference-service minReplicas: 2 maxReplicas: 10 metrics: # GPU利用率指标 —— 在70%时扩容，避免GPU算力瓶颈导致排队 - type: Pods pods: metric: name: gpu_utilization_avg target: type: AverageValue averageValue: "70" # 请求队列长度指标 —— 兜底策略，防止GPU指标滞后导致的响应延迟 - type: Pods pods: metric: name: inference_request_queue_depth target: type: AverageValue averageValue: "5" behavior: scaleUp: stabilizationWindowSeconds: 60 policies: - type: Pods value: 2 periodSeconds: 60 scaleDown: stabilizationWindowSeconds: 300 policies: - type: Pods value: 1 periodSeconds: 120

上述配置中包含两个关键设计：

GPU 利用率作为主指标，目标值设为 70% 而非更高，预留 30% 的缓冲空间以吸收突发流量。
请求队列深度作为辅助指标，在 GPU 指标尚未反映压力时提前触发扩容（例如模型切换导致单请求耗时增加的情况）。

缩容策略设计上，stabilizationWindowSeconds设为 300s（5分钟），避免因流量短暂回落后立即缩容而导致反复的模型加载。

四、冷启动优化与模型预热

大模型推理服务的一个显著痛点是冷启动时间。容器启动后需要加载模型权重到 GPU 显存，对于 7B 参数级别的模型，加载时间通常在 30~90 秒之间。

为解决这一问题，引入模型预热机制（Model Pre-warming）：

/** * 模型预热调度器——在 HPA 扩容完成后自动触发模型加载， * 确保新 Pod 在接收流量前已完成模型初始化。 * * 为什么在 PostConstruct 中执行而非构造函数： * Spring 依赖注入完成后才能获取 Service 引用，构造函数阶段依赖尚未就绪。 */ @Component public class ModelPreWarmScheduler { private static final Logger log = LoggerFactory.getLogger(ModelPreWarmScheduler.class); private final InferenceService inferenceService; private final PodMetadataProvider podMetadataProvider; public ModelPreWarmScheduler( InferenceService inferenceService, PodMetadataProvider podMetadataProvider) { this.inferenceService = inferenceService; this.podMetadataProvider = podMetadataProvider; } @EventListener(ContextRefreshedEvent.class) public void onApplicationReady() { String podName = podMetadataProvider.getCurrentPodName(); log.info("容器启动完成, pod={}, 开始模型预热加载", podName); try { // 为什么设置 180s 超时：7B 模型加载一般在 90s 内完成， // 保留 2 倍 margin 应对峰值负载下的 GPU 驱动排队 boolean success = inferenceService.loadModelWithTimeout( "qwen-7b-chat", Duration.ofSeconds(180)); if (success) { log.info("模型预热完成, pod={}, 准备接收流量", podName); } else { log.error("模型预热超时, pod={}, 容器将被驱逐重建", podName); // 为什么主动退出而非等待重试： // 加载超时说明 GPU 驱动或显存存在问题，继续运行只会接收流量后返回错误 System.exit(1); } } catch (Exception e) { log.error("模型预热异常, pod={}, 原因={}", podName, e.getMessage(), e); System.exit(1); } } }

此外，配合 Kubernetes 的 Readiness Probe，只有模型加载完成后才将 Pod 标记为就绪状态。

五、架构总览

graph TD A[Prometheus] -->|Pull Metrics| B[DCGM Exporter] B -->|Query GPU Stats| C[NVIDIA GPU Driver] D[Prometheus Adapter] -->|Custom Metrics API| E[Kubernetes API Server] A -->|Remote Write| D E -->|Metrics Query| F[HPA Controller] F -->|Scale Decision| G[llm-inference Deployment] G -->|Create Pod| H[New Inference Pod] H -->|Readiness Gate| I[Model PreWarmScheduler] I -->|Load Model| C I -->|Ready Signal| J[Service Endpoint] J -->|Route Traffic| K[Ingress / Gateway] style F fill:#f9f,stroke:#333,stroke-width:2px style I fill:#bbf,stroke:#333,stroke-width:2px

六、总结

大模型推理服务的弹性伸缩是一项需要综合考虑 GPU 特性、模型加载时间、成本控制与服务质量保障的系统工程。基于 GPU 指标的多维度 HPA 策略配合模型预热机制，能够在保障服务可用性的同时，将 GPU 资源利用率维持在合理区间。

在实际落地过程中，还需要根据业务流量特征持续调优 HPA 的扩缩容参数，建议配合混沌工程手段验证极端场景下的弹性能力。同时，对于成本敏感的场景，可以考虑配合 Spot 实例或竞价实例来降低 GPU 使用成本。

GPU 显存利用率的监控与优化

GPU 利用率指标并不完全等于显存利用率。一个常见误区是 GPU 利用率 70% 就认为还有 30% 的扩容空间，但实际上可能是 GPU 计算单元闲置但显存已满——新的模型加载或新请求的 KV Cache 分配被显存不足阻断。DCGM 提供的DCGM_FI_DEV_FB_USED（Frame Buffer Used）和DCGM_FI_DEV_FB_FREE（Frame Buffer Free）指标是显存监控的关键。我们在 HPA 中额外增加了显存使用率指标作为扩容信号：当显存使用率超过 85% 且 GPU 利用率未达到扩容阈值时，触发扩容而非缩容——因为显存已饱和意味着模型无法处理更多并发请求。

HPA 与 VPA 的配合策略

对于推理服务的 Batching 场景，HPA 的横向扩容和 VPA（Vertical Pod Autoscaler）的纵向扩容可以互补。HPA 增加 Pod 数量提升并发吞吐，VPA 增加单 Pod 的 GPU 显存配额提升批处理上限（更大的 KV Cache 空间可容纳更大的 Batch Size）。两者的配合策略是：优先使用 HPA 扩容到 maxReplicas，若仍无法满足吞吐需求（GPU 利用率持续 >85% 且显存已满），则触发 VPA 提升单 Pod 的 GPU 规格。