多云 GPU 算力纳管与混合调度落地实录-育师

多云 GPU 算力纳管与混合调度落地实录

在企业自建 AI 智能体与大模型私有化推理集群的演进中，算力成本与 GPU 资源调度是摆在云原生基础设施团队面前最棘手的现实难题。

随着业务扩张，企业通常会采购多家公有云的 GPU 算力券，同时机房里还散落着早期的自建物理机。面对跨云厂商（阿里云、腾讯云、AWS）、多卡型异构（NVIDIA A100、H800、L40S、RTX 4090 以及国产算力卡）、显存与 NVLink 互联带宽各异的复杂现状，传统的 Kubernetes 调度器（Kube-Scheduler）显得力不从心：

调度碎片化：不同部门各自为政，显卡闲置率常年高于 60%；
扩缩容失控：基于传统 CPU/GPU-Util 指标做 HPA 扩缩容，但 vLLM 推理框架在启动阶段就会把整张卡的显存申请占满作为 KV Cache 池，导致指标常年 100% 误报；
冷启动缓慢：拉起一个 70B 模型的容器需要从远端镜像仓库下载数十 GB 权重，耗时动辄 15 分钟，根本无法应对突发业务流量。

本文将复盘我们工作室在真实生产中，如何基于 Kubernetes + Volcano 调度器 + Keda 自定义指标，构建一套高弹性、低成本的多云异构 GPU 统一调度系统。

一、多云异构 GPU 统一纳管架构拓扑

为了统一纳管物理上分散在多机房与多云的 GPU 算力，我们构建了三层混合纳管拓扑：

┌─────────────────────────────────────────────────────────────┐ │ 统一控制面 (Multi-Cluster Control Plane / Karmada) │ │ - 跨云流量路由与模型负载全局均衡 │ └──────────────────────────────┬──────────────────────────────┘ │ ┌───────────────┴───────────────┐ ▼ ▼ ┌─────────────────────────────┐ ┌─────────────────────────────┐ │ 边缘/自建机房 集群 │ │ 公有云弹性算力 集群 │ │ (NVIDIA RTX 4090 / L40S) │ │ (NVIDIA A100 / H800) │ │ ┌─────────────────────────┐ │ │ ┌─────────────────────────┐ │ │ │ Volcano 拓扑感知调度器 │ │ │ │ Volcano 拓扑感知调度器 │ │ │ └─────────────────────────┘ │ │ └─────────────────────────┘ │ │ ┌─────────────────────────┐ │ │ ┌─────────────────────────┐ │ │ │ JuiceFS 分布式缓存挂载 │ │ │ │ JuiceFS 分布式缓存挂载 │ │ │ └─────────────────────────┘ │ │ └─────────────────────────┘ │ └─────────────────────────────┘ └─────────────────────────────┘

核心技术组件分工：

Volcano 智能调度器：替换原生 Kube-Scheduler，支持 GPU 拓扑感知（NVLink 亲和性分配）、Gang Scheduling（组调度）与显存精细化切分（vGPU/MPS）；
Keda 弹性伸缩器：直接抓取 vLLM 推理框架的 Prometheus 业务指标（如请求等待队列长度vllm:num_requests_waiting）作为真实扩缩容依据；
JuiceFS 分布式模型缓存：基于对象存储 + 本地 NVMe SSD 构建多级权重缓存，将数十 GB 模型权重拉取时间从 15 分钟压缩至25 秒。

二、生产级 K8s 调度与自动弹性伸缩配置实战

1. 基于 Volcano 的 GPU 拓扑感知 Deployment 配置

在运行大参数量模型（如 70B 多卡 Tensor Parallelism）时，必须确保 Pod 调度在物理机内通过 NVLink 直连的 GPU 插槽上，避免跨 NUMA 节点通信导致推理吞吐腰斩。

apiVersion: apps/v1 kind: Deployment metadata: name: vllm-deepseek-inference namespace: ai-inference spec: replicas: 2 selector: matchLabels: app: vllm-deepseek template: metadata: labels: app: vllm-deepseek spec: schedulerName: volcano # 指定 Volcano 高性能调度器 containers: - name: vllm-worker image: vllm/vllm-openai:v0.6.2 command: ["python3", "-m", "vllm.entrypoints.openai.api_server"] args: - "--model=/models/deepseek-70b" - "--tensor-parallel-size=4" - "--gpu-memory-utilization=0.92" - "--max-num-seqs=256" resources: limits: nvidia.com/gpu: "4" # 申请 4 张 GPU memory: "64Gi" cpu: "32" volumeMounts: - name: model-cache mountPath: /models readOnly: true volumes: - name: model-cache persistentVolumeClaim: claimName: juicefs-model-pvc

2. 基于 Keda 的真实推理队列弹性伸缩（ScaledObject）

严禁使用 GPU 利用率做 HPA！正确的做法是监控 vLLM 内部的排队等待队列。当积压请求数超过阈值时立刻拉起新实例：

apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: vllm-queue-autoscaler namespace: ai-inference spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: vllm-deepseek-inference minReplicaCount: 1 maxReplicaCount: 8 cooldownPeriod: 300 # 冷却时间 5 分钟，防止推理抖动缩容 triggers: - type: prometheus metadata: serverAddress: http://prometheus-k8s.monitoring.svc:9090 metricName: vllm_num_requests_waiting # 当平均每个副本等待排队的请求数超过 5 个时触发扩容 query: sum(vllm:num_requests_waiting{app="vllm-deepseek"}) / count(kube_deployment_status_replicas_available{deployment="vllm-deepseek-inference"}) threshold: '5'

三、生产落地的三大降本与容灾实践

在跨云管理数百张 GPU 的过程中，以下三套策略为我们帮客户节省了超过 55% 的算力账单：

1. 潮汐混合调度（Tidal Scheduling）

企业的业务流量呈现明显的“昼高夜低”规律：

白天高峰期（09:00 - 20:00）：将 80% 的 GPU 节点划入实时推理池，满足企业 Agent 亚秒级交互；
夜间低峰期（20:00 - 次日 08:00）：推理集群自动缩容，空闲算力被批量离线调度器（Volcano Queue）自动接管，挂载执行知识库 Embedding 向量构建、长文档离线解析与小模型微调（Fine-Tuning）任务，实现算力 24 小时满载榨取。

2. GPU 硬件故障实时自愈与节点隔离

GPU 属于高发热易损坏硬件，显卡掉卡（XID 错误）极易导致推理服务假死。

部署dcgm-exporter实时监听 GPU 硬件状态；
当捕获到DCGM_FI_DEV_XID_ERRORS关键错误（如 XID 31, 45 显存翻转）时，K8s DaemonSet 自动给物理节点打上node.kubernetes.io/gpu-unhealthy=true污点（Taint）；
立即驱逐受损 Pod 到备用可用区节点，将故障对业务的影响控制在秒级。