🤖 Assistant

基于您的调研和搜索结果，我为您设计一套完整的 GPU PaaS 平台动态虚拟化方案，以 HAMi 为核心框架。

GPU PaaS 平台动态虚拟化方案（基于 HAMi）

一、方案概述

HAMi（Heterogeneous AI Computing Virtualization Middleware）是 CNCF Sandbox 项目，专为 Kubernetes 环境下的异构算力管理设计 12。它通过软件层面的 vCUDA 方案，实现 GPU 显存和算力的细粒度切分与硬隔离，无需修改应用程序即可实现资源共享 32。

核心优势对比

特性NVIDIA MIGNVIDIA Time-SlicingHAMi
显存隔离✅ 硬件级❌ 无✅ 软件级硬隔离
算力隔离✅ 硬件级❌ 无✅ 可配置（1% 粒度）
支持 GPU 型号A100/H100 仅全部全部（含 T4/A10/A100）
显存切分粒度固定规格无任意 MB 级别
多卡支持单卡内单卡内✅ 跨卡调度
性能损耗无低<10% 3

二、架构设计

2.1 整体架构图

┌─────────────────────────────────────────────────────────────────┐
│                        Kubernetes Cluster                        │
├─────────────────────────────────────────────────────────────────┤
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────────┐  │
│  │   HAMi      │  │   HAMi      │  │    NVIDIA GPU           │  │
│  │  Scheduler  │  │  Device     │  │    Operator             │  │
│  │  (扩展调度器)│  │  Plugin     │  │    (驱动/容器工具)      │  │
│  └──────┬──────┘  └──────┬──────┘  └────────────┬────────────┘  │
│         │                │                       │               │
│         └────────────────┼───────────────────────┘               │
│                          │                                       │
│         ┌────────────────▼───────────────────────────┐           │
│         │           MutatingWebhook                   │           │
│         │  (注入 LD_PRELOAD、修正资源声明)            │           │
│         └────────────────┬───────────────────────────┘           │
│                          │                                       │
│         ┌────────────────▼───────────────────────────┐           │
│         │              Pod (AI 工作负载)               │           │
│         │  ┌─────────────────────────────────────┐   │           │
│         │  │         HAMi-Core (libvgpu.so)      │   │           │
│         │  │  (拦截 cudaMalloc 等 CUDA API)       │   │           │
│         │  └─────────────────────────────────────┘   │           │
│         └───────────────────────────────────────────┘           │
└─────────────────────────────────────────────────────────────────┘

2.2 核心组件说明

组件功能部署位置
HAMi Scheduler扩展 K8s 调度器，支持显存/算力感知的 Filter/Score/Bind 4kube-system
HAMi Device Plugin上报虚拟 GPU 资源，替代官方 NVIDIA Device Plugin 4每节点 DaemonSet
MutatingWebhook拦截 Pod 创建，注入调度器名称、runtimeClassName、LD_PRELOAD 4kube-system
HAMi-Core容器内动态库，拦截 CUDA API 实现显存/算力限制 43注入到 Pod 容器

三、部署方案

3.1 前置条件

  • Kubernetes 版本 >= 1.18 2
  • NVIDIA 驱动 >= 440 2
  • Helm > 3.0 2
  • 容器运行时配置为 nvidia 2

3.2 部署步骤

步骤 1：标记 GPU 节点
kubectl label nodes <node-id> gpu=on
步骤 2：添加 Helm Repo
helm repo add hami-charts https://project-hami.github.io/HAMi/
步骤 3：配置并安装

创建 hami-values.yaml 配置文件：

# HAMi GPU 虚拟化配置文件
scheduler:
  kubeScheduler:
    imageTag: v1.27.4  # 匹配 K8s 版本

nvidia:
  # 显存虚拟化比例 (1.0 = 不超分, >1.0 = 超分)
  deviceMemoryScaling: 1.0
  # 每个 GPU 最大任务数
  deviceSplitCount: 10
  # MIG 策略 ("none" / "mixed")
  migstrategy: "mixed"
  # 是否禁用算力限制
  disablecorelimit: "false"
  # 默认显存分配 (MB, 0 = 100%)
  defaultMem: 0
  # 默认 GPU 核心百分比 (0-100)
  defaultCores: 0
  # 默认 GPU 数量
  defaultGPUNum: 1

执行安装：

helm upgrade -i hami hami-charts/hami -f hami-values.yaml -n kube-system
步骤 4：验证安装
kubectl get pods -n kube-system | grep hami
# 应看到 hami-device-plugin 和 hami-scheduler 均为 Running

3.3 重要注意事项

⚠️ HAMi Device Plugin 与 NVIDIA 官方 Device Plugin 不能共存，需卸载官方插件以避免资源冲突 4。

四、动态资源调度策略

4.1 资源申请模型

HAMi 支持三种资源维度 32：

资源类型资源名称说明
vGPU 数量nvidia.com/gpu请求的物理 GPU 数量
显存大小nvidia.com/gpumem显存限制 (MB)
算力比例nvidia.com/gpucores算力百分比 (0-100)

4.2 典型场景配置

场景 1：小模型推理（显存隔离 + 算力共享）
apiVersion: v1
kind: Pod
metadata:
  name: small-model-inference
spec:
  containers:
  - name: inference-container
    image: pytorch/pytorch:2.0-cuda11.7
    resources:
      limits:
        nvidia.com/gpu: 1        # 1 个 vGPU
        nvidia.com/gpumem: 4000  # 4GB 显存
        # 不设置 gpucores = 算力共享

适用场景： 推荐系统、实时预测等小模型，单卡可并行多个模型 4。

场景 2：大模型训练（多卡 + 显存隔离）
apiVersion: v1
kind: Pod
metadata:
  name: llm-training
spec:
  containers:
  - name: training-container
    image: pytorch/pytorch:2.0-cuda11.7
    resources:
      limits:
        nvidia.com/gpu: 4        # 4 张物理 GPU
        nvidia.com/gpumem: 20000 # 每张卡 20GB 显存
        nvidia.com/gpucores: 80  # 每张卡 80% 算力

关键说明： nvidia.com/gpu: 4 会被调度到 4 张物理 GPU 上，而非同一张卡的 4 个 vGPU 4。

场景 3：显存超分（提高利用率）
# 在 hami-values.yaml 中配置
nvidia:
  deviceMemoryScaling: 1.5  # 16GB 显存可虚拟出 24GB

适用场景： 开发/测试环境，生产环境建议保持 1.0 2。

4.3 调度策略配置

策略配置项说明
Binpack默认优先填满单卡，减少碎片
Spread调度器参数分散到多卡，提升并行度
拓扑感知企业版特性NVLink 感知，优化多卡通信 2

五、动态调整方案

5.1 运行时资源调整

⚠️ 重要限制： 目前技术（包括 HAMi/MIG/vGPU）不支持 Pod 运行中动态扩容显存。资源调整需通过以下方式实现：

方案 A：Pod 重建（推荐）
# 1. 更新 Deployment 的资源配置
kubectl edit deployment <name>

# 2. 滚动更新
kubectl rollout restart deployment <name>
方案 B：HPA + 多规格 Pod
# 定义多个 Deployment，不同显存规格
# 配合 KEDA 或自定义 HPA 根据负载切换
方案 C：弹性节点池
# 使用 Cluster Autoscaler
# 低峰期：MIG 切分为 7 片（推理）
# 高峰期：MIG 重置为整卡（训练）

5.2 节点级动态策略

通过修改节点标签和 MIG 配置实现时段化资源池：

# 白天：推理模式（7 切片）
kubectl annotate node <node> hami.io/mig-profile=7x1g.5gb

# 夜间：训练模式（整卡）
kubectl annotate node <node> hami.io/mig-profile=none

六、监控与观测

6.1 监控指标

HAMi 默认开启监控，访问端点 2：

http://<scheduler-ip>:31993/metrics

6.2 Grafana Dashboard

导入官方 Dashboard 配置 2：

  • GPU 利用率
  • 显存使用率
  • vGPU 分配情况
  • 任务排队状态

6.3 日志排查

# 查看设备注册情况
kubectl logs -n kube-system -l app.kubernetes.io/name=hami | grep "device"

# 查看 Pod GPU 分配
kubectl get pod <pod> -o jsonpath='{.metadata.annotations.hami\.io/vgpu-devices-allocated}'

七、性能考量

根据 AWS 实测数据 4：

场景配置平均算力 (GFLOPS)损耗
独占整卡15GB 显存4280-
HAMi 单 Pod7GB 显存4289~0%
HAMi 双 Pod各 7GB 显存1751/1747~18%

结论：

  • 显存隔离几乎无性能损耗
  • 多 Pod 共享算力时有约 18% 损耗，但整体利用率显著提升 4
  • 官方基准测试显示最大损耗不超过 10% 3

八、最佳实践建议

8.1 生产环境配置

nvidia:
  deviceMemoryScaling: 1.0      # 生产环境不超分
  deviceSplitCount: 5           # 根据业务调整
  migstrategy: "mixed"          # A100 节点启用 MIG
  disablecorelimit: "false"     # 启用算力限制

8.2 资源配额管理

# 使用 ResourceQuota 限制命名空间总 GPU 使用
apiVersion: v1
kind: ResourceQuota
metadata:
  name: gpu-quota
spec:
  hard:
    nvidia.com/gpu: "10"
    nvidia.com/gpumem: "80000"  # 总显存 80GB

8.3 优先级调度

resources:
  limits:
    nvidia.com/gpu: 1
    nvidia.com/gpumem: 4000
    nvidia.com/priority: 0  # 0=高优先级，1=低优先级 [3]

8.4 避免的问题

问题解决方案
Pod 使用 privileged会导致可见所有 GPU，禁止使用 2
设置 nodeName调度器无法工作，改用 nodeSelector 2
同时存在两个 Device Plugin卸载 NVIDIA 官方插件 4

九、方案总结

维度方案选择
虚拟化框架HAMi (开源/CNCF Sandbox)
显存隔离软件级硬隔离 (LD_PRELOAD 拦截)
算力隔离可配置百分比限制
动态调整Pod 重建 + 节点策略切换
监控内置 Prometheus 指标 + Grafana
适用 GPUT4/A10/A100/H100 等全系
性能损耗<10% (官方基准)

后续扩展建议

  1. 企业版功能：如需算力超分、抢占式调度、多集群管理，可考虑 HAMi 企业版 (Rise VAST) 2
  2. 调度增强：集成 Volcano 或 Kueue 实现队列管理和 Gang Scheduling 1
  3. WebUI 管理：部署 HAMi-WebUI (v2.4.0+) 实现可视化资源管理 2

此方案已在 AWS EKS 及多个生产环境验证，可支撑小模型推理与大模型训练的统一资源池管理 4。

  1. Kubernetes 上的异构 GPU 共享 | HAMi ↩︎ ↩︎

  2. HAMi：开源 GPU 虚拟化利器，让 AI 算力管理更简单 - 睿思智联 RiseUnion ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  3. 开源 vGPU 方案：HAMi,实现细粒度 GPU 切分 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  4. 基于 HAMi 的 GPU 虚拟化实践 | Amazon Web Services ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

# GPU
Logo
DeepSeek技术社区

欢迎加入DeepSeek 技术社区。在这里，你可以找到志同道合的朋友，共同探索AI技术的奥秘。

更多推荐

cover

我用 Qwen3.8-Max 做了一个采购合同风险审查工具：从能分析，到能定位、复核和交付

avatar DeepSeek技术社区
cover

我用 Qwen3.8-MAX 搭了一个教研纪要 Agent，一次集体备课几秒出七段、分歧还不被和稀泥

avatar DeepSeek技术社区

我用 Qwen3.8-Max 做了缠论结构观察员，跑完了从开发到修复的全过程

Qwen3.8-Max 没有替我判断方向，也没有把缠论包装成预测工具。它在开发过程中支持多 Agent 并行，能够理解较长的产品约束和算法边界，拆分文档与实现任务；当子任务停滞后回到主上下文继续推进；再根据“笔断裂”“中枢过宽”这种图上的具体问题，定位到算法文件并补回归测试。复杂项目不能靠一次生成直接交付。Agent Team 会卡住，初版算法也会错。模型放进开发闭环里才有意义，最后还是要靠可检查

avatar DeepSeek技术社区