5090算力租赁实战：如何构建高性价比的分布式GPU资源池

1次阅读

没有评论

共计 2103 个字符，预计需要花费 6 分钟才能阅读完成。

最近几年 AI 模型的训练需求呈现爆发式增长，但 GPU 资源的高昂价格和固定采购模式让很多中小团队望而却步。传统方式下，企业需要直接购买整块显卡，但实际使用中经常遇到两个典型问题：

资源浪费严重：训练任务往往具有周期性，非高峰时段 GPU 利用率可能不足 30%
成本居高不下：A100/H100 等旗舰卡单块价格超过 5 万元，而实际训练时可能只需要部分算力

相比之下，NVIDIA 5090 显卡展现出了独特的性价比优势：

单卡 FP32 算力达到 60TFLOPS，接近上代旗舰 90% 性能
支持 PCIe 5.0 和 NVLink 4.0，带宽瓶颈显著改善
价格仅为旗舰卡的 1 /3，特别适合做算力切分

在评估各类调度系统时，我们重点对比了三种方案：

Slurm：传统 HPC 领域的王者，但对容器化支持较弱
YARN：大数据生态成熟，但 GPU 调度功能简陋
Kubernetes：云原生标准，具备声明式 API 和丰富扩展机制

最终选择 K8s 的核心原因包括：

标准化接口：通过 Device Plugin 机制可以统一管理各类加速器
弹性伸缩能力：配合 Cluster Autoscaler 实现真正按需分配
生态工具链：Prometheus、Grafana 等监控组件开箱即用

通过实现 K8s Device Plugin，我们将 5090 显卡抽象为可调度资源。关键代码片段如下：

type Nvidia5090Plugin struct {devs   []*pluginapi.Device
    socket string
}

func (m *Nvidia5090Plugin) ListAndWatch(e *pluginapi.Empty, s pluginapi.DevicePlugin_ListAndWatchServer) error {
    for {res := make([]*pluginapi.Device, 0)
        // 通过 nvml 库获取设备状态
        devices, _ := nvml.GetAllDevices() 
        for _, dev := range devices {
            res = append(res, &pluginapi.Device{
                ID:     dev.UUID,
                Health: statusToString(dev.Status),
            })
        }
        s.Send(&pluginapi.ListAndWatchResponse{Devices: res})
        time.Sleep(5 * time.Second)
    }
}

我们设计了带权重的多租户配额系统，核心配置示例：

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: gpu-high-priority
value: 1000000
globalDefault: false
description: "用于抢占式 GPU 任务"

---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-gpu
spec:
  hard:
    requests.nvidia.com/gpu: "8"
  scopes:
  - PriorityClass

vGPU 切分方案：
1. 使用 MIG 技术将单卡分为 7 个实例
2. 每个实例可独立分配 1 / 8 显存
3. 通过 cgroup 限制计算单元占用

RDMA 网络配置：

# 加载 RDMA 驱动
modprobe ib_uverbs
# 创建 GPU 直通网络
kubectl create -f https://raw.githubusercontent.com/Mellanox/k8s-rdma-shared-dev-plugin/master/deployment/k8s-rdma-shared-dev-plugin-ds.yaml

在项目落地过程中，我们踩过两个大坑：

显存泄漏问题：
现象：任务结束后显存未释放
解决方案：在 docker 启动参数中添加--kernel-memory=16G
计费时间不同步：
现象：调度器记录时长与实际使用偏差
修复：采用分布式事务时钟 (TSO) 统一时间戳

部署 Prometheus 监控的关键配置：

- job_name: 'gpu-metrics'
  scrape_interval: 15s
  static_configs:
  - targets: ['nvidia-dcgm-exporter:9400']
  metrics_path: /metrics

rules:
- alert: GPUOverheat
  expr: nvidia_temp > 85
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "GPU {{$labels.instance}} 温度过高"

最后留个开放问题：当不同优先级的任务同时申请资源时，如何设计分级计费模型？建议尝试修改 kube-scheduler 的 Score 插件，给不同优先级的 Pod 赋予不同权重值。

期待大家在实践中探索更多可能性，也欢迎分享你的实现方案。

正文完