异构 AI 集群的统一调度：跨 NVIDIA/AMD/Intel GPU 的资源抽象与负载均衡工程实践

引言：异构现实的到来

2024-2026 年间，AI 基础设施建设正在经历一个微妙但不可逆的转变。过去，数据中心的加速计算几乎是 NVIDIA 的独角戏；而现在，AMD Instinct MI300X 已经在 Meta 和微软的数据中心大规模部署，Intel Gaudi 3 在成本效益敏感的场景中找到了自己的位置，而 Qualcomm Cloud AI 100 和各类国产 AI 芯片也在特定工作负载中发挥着作用。

对于一个 AI 平台工程师来说，这种变化带来了一个极具挑战性的问题：如何在一个集群中同时管理多种 GPU 架构，同时为上层 AI 训练和推理任务提供统一的资源抽象？

这不是一个简单的"支持多品牌"问题。不同 GPU 架构在内存层次、张量核心组织、互联拓扑、功耗特性等方面存在本质差异。真正的工程挑战在于：如何在保持调度效率的同时，避免将复杂性泄漏给 AI 框架层？

一、架构差异的本质：不仅仅是算力数字

在讨论调度方案之前，我们需要理解异构 GPU 之间到底有哪些本质差异会影响调度决策。

1.1 内存体系

NVIDIA H100/B200 采用的是 HBM3/e 内存，其中 H100 拥有 80GB 容量和 3.35TB/s 的带宽。AMD MI300X 则将 HBM3 堆叠到了 192GB，带宽约 5.3TB/s，在容量和带宽两个维度都超越了 H100。但关键区别在于：AMD 的 Infinity Fabric 将 8 个 XCD（加速计算芯片）连接在一起，跨 XCD 访问会有延迟惩罚；而 NVIDIA 的 NVLink 提供了更均匀的 GPU 间内存访问。

Intel Gaudi 3 则走了另一个方向——24GB 的 HBM2e 配合 1250TFLOPS 的 BF16 算力，强调的是高密度封装和 RDMA 网络集成。

这意味着：一个训练任务的显存需求如果超过 80GB，它天然只能被调度到 AMD MI300X 节点上；一个需要 GPU 间高带宽通信的任务可能在 NVIDIA NVLink 拓扑上表现显著更好。

1.2 计算精度谱系

不同 GPU 支持的精度格式和性能比率存在差异：

调度器必须理解"工作负载期望的精度"与"硬件能高效提供的精度"之间的匹配关系，否则可能把一个 INT8 推理任务分配到了一个 INT8 性能不佳的 GPU 上。

1.3 互联拓扑

集群的节点内互联（NVLink / Infinity Fabric / NES）和节点间互联（InfiniBand / RoCE / AI-Fabric）共同决定了分布式任务的通信开销。调度器在做放置决策时，需要让通信密集的任务尽可能落在拓扑距离更近的位置。

二、资源抽象层：构建统一视图

2.1 传统的 ResourceClaim 模型及其局限

Kubernetes 原生的扩展资源（如 nvidia.com/gpu: 1）是模型无关的——它只是告诉调度器"这个 Pod 需要一个 GPU"。这在异构环境中完全不够用：用户不会只想要"1 个 GPU"，而是想要"1 个带 192GB HBM 和 FP8 高吞吐能力的加速器"。

Kubernetes Device Plugin API 和 DRA（Dynamic ResourceAllocation，K8s 1.26+ beta）提供了更精细的资源描述能力。我们可以为每种 GPU 架构定义自定义资源属性：

apiVersion: resource.k8s.io/v1alpha2
kind: ResourceClaim
metadata:
  name: training-job-claim
spec:
  parametersRef:
    kind: ResourceClaimParameters
    name: gpu-requirements
  allocationMode: WaitForFirstConsumer
---
apiVersion: resource.k8s.io/v1alpha2
kind: ResourceClaimParameters
metadata:
  name: gpu-requirements
spec:
  requests:
    - deviceClassName: gpu.ai.example.com
      selectors:
        - cel:
            expression: |
              device.attributes["vendor"].isAMD() ||
              device.attributes["model"].matches("MI300X|MI250X")
      capabilities:
        driver: amdgpu
        apiVersion: 1.0
        attributes:
          memory.hbm: Quantity(">=128Gi")
          compute.bflops: Quantity(">=1000T")
          topology.numaAligned: "true"
    - deviceClassName: gpu.ai.example.com
      selectors:
        - cel:
            expression: |
              device.attributes["vendor"].isNVIDIA() &&
              device.attributes["model"].matches("H100|B200")
      capabilities:
        driver: nvidia
        attributes:
          memory.hbm: Quantity(">=80Gi")
          interconnect.nvlink: Quantity(">=900")

2.2 GPU Attribute Profile：标准化描述

为了让调度器理解异构硬件，我们定义一套 GPU Attribute Profile (GAP)：

from dataclasses import dataclass, field
from enum import Enum

class GPUVendor(str, Enum):
    NVIDIA = "nvidia"
    AMD = "amd"
    INTEL = "int"

class InterconnectType(str, Enum):
    PCIE = "pcie"
    NVLINK = "nvlink"
    INFINITY_FABRIC = "xflink"
    NES = "nes"
    RDMAS = "rdma"

@dataclass
class GPUAttributeProfile:
    # 基本标识
    vendor: GPUVendor
    model: str
    sku: str
    
    # 计算能力
    compute_flops_fp16: float   # TFLOPS
    compute_flops_fp8: float    # TFLOPS
    compute_flops_int8: float   # TOPS
    compute_flops_fp64: float   # TFLOPS
    
    # 内存体系
    hbm_capacity: int           # GB
    hbm_bandwidth: float        # TB/s
    l2_cache_size: int          # MB
    
    # 互联
    interconnect_node_internal: InterconnectType
    interconnect_bandwidth: float  # GB/s (per-GPU bidirectional)
    interconnect_groups: list[list[int]]  # GPU 亲和性分组
    
    # 功耗设计
    tdp_watts: int
    thermal_headroom: int       # 可在规定时间内超 TDP 的瓦数
    
    # 特性支持
    supports_mixed_precision: bool
    supports_memory_pooling: bool
    supports_confidential_compute: bool
    max_gpus_per_node: int
    
    def affinity_score(self, workload) -> float:
        """计算 GPU 对工作负载的匹配度分数"""
        score = 0.0
        
        # 显存需求是否满足
        if workload.memory_required > self.hbm_capacity:
            return 0.0  # 完全不匹配
        
        # 计算精度匹配
        prec_flops = {
            "fp16": self.compute_flops_fp16,
            "bf16": self.compute_flops_fp16,  # BF16 与 FP16 相同
            "fp8": self.compute_flops_fp8,
            "int8": self.compute_flops_int8,
        }
        target_flops = prec_flops.get(self.workload_precision, self.compute_flops_fp16)
        score += (target_flops / 3000.0) * 40  # 计算能力占 40 分
        
        # 内存带宽匹配
        score += (self.hbm_bandwidth / 6.0) * 25  # 带宽占 25 分
        
        # 互联带宽匹配
        if workload.cross_gpu_bandwidth_weight > 0:
            score += (self.interconnect_bandwidth / 900) * 20
        
        # 内存利用率奖励
        mem_ratio = workload.memory_required / self.hbm_capacity
        if 0.3 < mem_ratio < 0.9:
            score += 15  # 合理利用率奖励
        elif mem_ratio >= 0.9:
            score += 5   # 接近满显存，风险较高
        
        return score

三、调度器设计：多维度优化目标

异构 GPU 调度是一个多目标优化问题。调度器需要同时考虑：资源利用率、任务性能 SLA、功耗约束、以及公平性。

3.1 分层调度架构

我们采用三层调度架构来管理复杂性：

/// 调度器的三层架构

// L1: Cluster Placement —— 决定任务运行在哪个集群/分区
struct ClusterPlacementLayer {
    // 负责跨地域、跨集群级别的选择
    // 输入: 任务的硬件兼容性、数据位置、合规要求
    // 输出: 目标集群
}

// L2: Bin-Packing & Affinity —— 节点选择和 NUMA 亲和性 
struct BinPackingLayer {
    // 在选定集群内部选择最优节点组合
    // 输入: 任务规模、NUMA 拓扑、功耗上限
    // 输出: 目标节点和 GPU 分配方案
}

// L3: Runtime Enforcement —— 运行时 QoS 保障
struct RuntimeQoSLayer {
    // 在任务运行时持续监控和调整
    // 输入: 实时性能计数器、资源使用率
    // 输出: 资源配额调整、是否触发迁移
}

3.2 核心调度算法：Best-Fit with Awareness

异构环境中的 Bin-Packing 不能只用简单的 first-fit 或 worst-fit。我们需要一个"感知型 Best-Fit"算法，它的核心思想是：在满足硬件兼容性的前提下，选择能够让任务获得最佳性能且对碎片影响最小的节点。

struct HeterogeneousScheduler {
    node_pool: HashMap<NodeId, NodeState>,
    pending_queue: BinaryHeap<ScheduledTask>,
}

impl HeterogeneousScheduler {
    fn schedule_task(&mut self, task: &AIStrategy) -> Option<PlacementDecision> {
        // 第一阶段：筛选兼容节点
        let candidates: Vec<&NodeState> = self.node_pool
            .values()
            .filter(|node| node.is_compatible(task))
            .filter(|node| node.has_sufficient_resources(task))
            .collect();
        
        if candidates.is_empty() {
            return None;
        }
        
        // 第二阶段：多维度评分
        let mut scored: Vec<(f64, &NodeState, AllocationPlan)> = candidates
            .iter()
            .filter_map(|node| {
                let plan = node.allocate_plan(task)?;
                let score = self.score_placement(task, node, &plan);
                Some((score, node.clone(), plan))
            })
            .collect();
        
        // 按分数降序排列
        scored.sort_by(|a, b| b.0.partial_cmp(&a.0).unwrap());
        
        // 第三阶段：选择最优 + 冲突消解
        let (best_score, best_node, best_plan) = scored.into_iter().next()?;
        
        if best_score < task.min_viable_score {
            None  // 没有节点能满足最低要求
        } else {
            Some(PlacementDecision {
                task_id: task.id.clone(),
                node_id: best_node.id.clone(),
                allocation: best_plan,
            })
        }
    }
    
    fn score_placement(&self, task: &AIStrategy, node: &NodeState, plan: &AllocationPlan) -> f64 {
        let mut score = 0.0;
        
        // 性能分 (0-50): 选择的 GPU 型号对任务的性能匹配度
        let perf_score = node.gpu_profile().affinity_score(task);
        score += perf_score * 0.5;
        
        // 拓扑分 (0-25): 多 GPU 任务的互联质量
        if task.world_size() > 1 {
            let topo_score = self.evaluate_topology(task, node, plan);
            score += topo_score * 0.25;
        }
        
        // 碎片分 (0-15): 分配后残留资源的可用性
        let fragmentation = self.estimate_fragmentation(node, plan);
        score += (1.0 - fragmentation) * 15.0;
        
        // 功耗分 (0-10): 节点功耗余量
        let power_headroom = node.power_headwatts();
        if power_headroom < task.estimated_power_watts {
            score -= 20.0;  // 严重惩罚超功耗
        } else {
            score += (power_headroom as f64 / node.tdp_watts as f50) * 10.0;
        }
        
        score
    }
}

3.3 碎片管理：异构环境下的特殊挑战

异构 GPU 集群面临一个传统集群不存在的碎片问题：型号碎片。当一个节点上剩余 1 块 H100 和 1 块 MI300X 时，这两块卡无法组成一个高性能的 NVLink 或 XFLink 组——它们虽然是 GPU，但对分布式任务来说几乎是不可用的。

解决这个问题需要调度器主动进行碎片整理：

class FragmentationManager:
    """主动碎片整理器：将分散的同型号 GPU 集中到少数节点上"""
    
    def __init__(self, cluster_state: ClusterState, migration_policy: MigrationPolicy):
        self.cluster = cluster_state
        self.policy = migration_policy
        self.fragmentation_threshold = 0.3  # 碎片率超过 30% 触发整理
    
    def detect_fragmentation(self) -> list[FragmentationIssue]:
        issues = []
        for node in self.cluster.nodes:
            # 检测跨型号碎片：节点上不同型号 GPU 无法高效互联
            gpu_models = set(gpu.model for gpu in node.available_gpus)
            if len(gpu_models) > 1:
                # 检查这些 GPU 是否能组成互联组
                can_form_group = any(
                    all(gpu.model == model for gpu in node.available_gpus)
                    for model in gpu_models
                )
                if not can_form_group:
                    issues.append(FragmentationIssue(
                        node_id=node.id,
                        issue_type="cross_model",
                        severity=len(gpu_models),
                        affected_gpus=node.available_gpus
                    ))
        return issues
    
    def plan_defragmentation(self, issues: list[FragmentationIssue]) -> DefragPlan:
        """生成碎片整理计划：识别可迁移的任务，重新分配GPU资源"""
        plan = DefragPlan()
        
        for issue in issues:
            # 找出可以迁移到其他同型号节点的任务
            for gpu in issue.affected_gpus:
                for task in gpu.running_tasks:
                    target = self.find_migration_target(task)
                    if target and self.policy.allow_migration(task):
                        plan.add_migration(Migration(
                            task=task,
                            source=issue.node_id,
                            target=target
                        ))
                        break  # 只迁移一个任务就能释放一块同型号 GPU
        
        return plan

四、运行时 QoS：确保调度决策落地

调度决策如果缺乏运行时保障，就只是一张空头支票。异构 GPU 集群需要在运行阶段持续监控任务行为，确保它们不跨越资源边界。

4.1 性能计数器驱动的反馈控制

现代 GPU 提供了丰富的性能计数器，调度系统可以利用这些指标实现闭环控制：

pub struct GPUMonitor {
    collectors: HashMap<GPUVendor, Box<dyn PerfCounterCollector>>,
}

impl GPUMonitor {
    pub fn collect_metrics(&self, gpu: &GPUDevice) -> GPUMetrics {
        match gpu.vendor {
            GPUVendor::NVIDIA => {
                // 使用 DCGM/MLSNR 接口
                nvidia_metrics(gpu.device_id)
            }
            GPUVendor::AMD => {
                // 使用 ROCm SMI 接口
                amd_metrics(gpu.device_id)
            }
            GPUVendor::INTEL => {
                // 使用 Level Zero sysman API
                intel_metrics(gpu.device_id)
            }
        }
    }
}

pub fn qos_controller_loop(monitor: &GPUMonitor, tasks: &mut TaskRegistry) {
    loop {
        std::thread::sleep(Duration::from_secs(5));
        
        for task in tasks.iter_active() {
            let metrics = monitor.collect_metrics(&task.assigned_gpu);
            
            // 检测显存使用异常（超出配额）
            if metrics.memory_used > task.memory_limit * 1.05 {
                // 超过配额 5%，限制任务或标记降级
                task.apply_throttle(ThrottleAction::ReduceCache);
            }
            
            // 检测算力抢占（其他任务占用了 SM）
            if metrics.sm_utilization < task.target_sm_util * 0.5 {
                // SM 利用率不足目标的一半，可能是邻居任务干扰
                if let Some(node) = task.assigned_node() {
                    node.notify_contention(task.id());
                }
            }
            
            // 温度/功耗保护
            if metrics.temperature_c > task.thermal_limit {
                task.apply_throttle(ThrottleAction::ReducePower(90));
            }
        }
    }
}

4.2 降级与优雅退出

在资源紧张的异构集群中，不是所有任务都能获得所需的 GPU 类型。我们需要一个优雅的降级机制：

enum DegradationStrategy {
    WaitPreferred,           // 等待首选 GPU 可用（有超时）
    AcceptAlternative {      // 接受替代选项
        alternative: GPUModel,
        performance_impact: f64,  // 预估性能损失百分比
    },
    QuantizeAndReduce {      // 采用量化策略减少显存需求
        target_precision: Precision,
        expected_degradation: f64,
    },
    CheckpointAndPreempt,    // 保存 checkpoint，等待更高优先级完成
}

impl DegradationStrategy {
    fn apply(self, task: &mut AITask) -> Result<ModifiedTask, DegradationError> {
        match self {
            Self::AcceptAlternative { alternative, performance_impact } => {
                task.gpu_requirements.model = alternative;
                task.sla.latency_slo_ms *= 1.05;  // 放宽 5% 延迟 SLA
                task.qos.degraded = true;
                Ok(task.clone())
            }
            Self::QuantizeAndReduce { target_precision, .. } => {
                task.inference_config.precision = target_precision;
                task.model_config.enable_fp8_quantization = true;
                Ok(task.clone())
            }
            // ... 其他策略实现
        }
    }
}

五、实战数据与经验

5.1 混合集群的典型配比

在我们实际运行的异构集群中，GPU 型号的分布大致如下（2024-2026 年数据）：

• 70% 主力推理型：H100 SXM / MI300X（承担 80% 的推理流量）
• 20% 训练型：B200 / MI300X（承担大规模训练任务）
• 10% 利旧/专用：A100 / A10 / Gaudi 2（承担开发、测试、特定工作负载）

这种配比的关键洞察是：型号间的算力差异不会无限扩大。调度器需要根据每种型号的"性价比曲线"来决定任务分配——例如 MI300X 在 FP8 矩阵乘法上性价比最高，最适合大规模推理；而 B200 在长序列训练上由于 KV Cache 容量优势更优。

5.2 调度效果指标

引入异构感知调度后，关键指标变化如下：

5.3 教训与反模式

反模式 1：按型号完全隔离集群

最初我们将 NVIDIA 和 AMD 集群分开管理，结果遇到了"潮汐效应"—— NVIDIA 集群空闲时 AMD 集群拥堵，反之亦然。统一的资源池是必须的第一步。

反模式 2：用显存大小作为唯一指标

只看"192GB vs 80GB"做调度决策，忽略了一个事实：MI300X 的 192GB 分布在多个 XCD 上，单 XCD 有效可用显存只有 24GB。不了解硬件微架构的内部差异导致调度决策严重失误。

反模式 3：等分配完再考虑 NUMA

GPU 任务通常与 CPU 内存分配绑定，但如果 Tensor 数据需要经过 CPU 中转（如某些 CTR 场景），NUMA 对齐与否会影响高达 15% 的性能。调度器必须在做出放置决策时就考虑完整的数据流路径。

六、未来展望

异构 GPU 调度正朝着几个方向发展：

API 标准化：oneAPI、SYCL 和 OpenXLA 正在提供跨架构的编程抽象，调度器的角色将从"分配特定型号的 GPU"演进为"分配能满足性能等级的加速器池"。

AI 驱动的强化学习方法调度：传统 BF/BFD 算法对环境做了太多假设，而基于 RL 的调度器能从真实负载模式中学习，适应非稳态的异构环境。已经有了初步研究显示 RL 调度器在突发流量下比传统算法好 15-20%。

热迁移与实时重配置：真正的弹性依赖于任务在 GPU 间的无缝迁移。虽然 GPU Checkpoint/Restore 技术仍在成熟中（NVIDIA 正在研究基于的 MIG 状态迁移，AMD 通过 ROCm 容器热迁移探索），但这将是解决异构碎片问题的最终方案。

结语

异构 AI 集群的统一调度并不是一个"支持多品牌 GPU"的简单功能，它是一个涉及硬件建模、运行时控制、碎片管理和服务质量保障的系统工程。

核心要点可以归结为三点：精确建模（理解每种架构的本质差异）、感知调度（在做决策时考虑工作负载特征）、闭环控制（运行时持续保障调度决策的执行）。随着 AI 芯片生态的进一步多元化，这些能力将从"竞争优势"变成"生存底线"。

代码示例采用了 Rust 伪代码和 Python 片段，展示了调度系统的核心逻辑。完整实现涉及大量工程细节，包括 API 服务、持久化存储、高可用部署等，这里聚焦于算法和架构层面。