异构计算调度：负载均衡

可视化演示

通过静态分配、动态调度与设备利用率对比，直观展示异构计算系统如何均衡分配任务以最大化吞吐量。

1. 负载均衡概念

周五晚高峰，后厨乱成一锅粥。张师傅的爆炒台前只排了 3 张单，王师傅的甜品台前却摞了 30 张舒芙蕾订单。老陈一拍脑门：“我明明按 1、2、3 号顺序轮流派单，怎么乱成这样？”问题就出在“轮流”上——张师傅颠一锅菜只要 1 分钟，王师傅做一份甜品要 5 分钟，两人拿到同样数量的单，慢的那位必然越积越多。忙的忙死，闲的闲死，整条出菜通道被最慢环节卡死。

这套后厨场景搬到计算机里，就是异构计算调度面临的核心问题。AI 系统里通常同时存在 GPU、CPU、NPU 等算力差异巨大的设备，它们各自的处理速度、擅长任务都不同。如果调度器只是机械地轮流分配任务，快的设备会闲等，慢的设备会堆积，系统整体吞吐量被短板设备死死拖住。负载均衡要解决的，正是“如何让每台设备都忙起来，且忙得恰到好处”。

从工程定义看，负载均衡是指调度器根据设备算力差异、当前负载和任务特性，动态地为每个新任务选择落地设备，使各设备利用率维持在合理区间，最终最大化系统吞吐量和资源利用效率。衡量一台设备忙不忙，最直接的指标是利用率——统计周期内设备真正干活的时间占比：

老陈后来换了思路：不再机械轮流，而是先看每位师傅手头还有多少菜，再把新单子塞给最空的人。几位师傅的灶台终于同时动了起来，出菜速度翻倍。这个朴素的道理，就是负载均衡最底层的直觉——让每一份资源都物尽其用。

2. 异构设备差异

老陈心里有一本“厨师能力手册”：张师傅管 8 个爆炒灶，火力猛、翻锅快，最适合做快炒；李师傅的灶台慢些但什么菜系都会；王师傅的甜品炉虽小，做起招牌舒芙蕾却比谁都专业。给张师傅派红烧肉、给王师傅派爆炒腰花，都是在浪费人才。

异构系统的设备差异也是如此。GPU 拥有数千个计算核心，擅长大规模并行矩阵运算，是深度学习训练和推理的主力；CPU 核心少但逻辑控制能力强，适合处理调度、数据预处理等串行任务；NPU 是专为神经网络算子设计的加速器，处理量化后的推理任务时功耗低、速度快。三者就像能力画像完全不同的三位厨师。

调度器眼里，每台设备有三个关键属性：峰值算力 $C_i$（单位时间能完成多少计算）、内存带宽（原料搬运速度）、任务亲和度（这个活它干得快不快）。真正能交付的吞吐，不是峰值算力，而是峰值、利用率、亲和度三者的乘积：

老陈分配单子前，先翻能力手册再估当前忙闲：爆炒交给张师傅，甜品交给王师傅，没人有空才让李师傅顶上。调度器同样在“谁适合”和“谁有空”之间做权衡，这正是负载均衡的第二层智慧。

3. 调度器架构

后厨墙上钉着一排订单夹，新客人的单子先挂在夹子上排队；老陈站在订单夹前，眼睛不停扫过三个灶台，心里盘算下一单交给谁。这个“看单—判断—派发—再看”的循环，从早到晚没有停过一秒。

在 AI Runtime 系统里，扮演老陈的就是调度器（Scheduler）。它的架构通常由三部分构成：全局任务队列（订单夹）、设备状态表（老陈的记忆）、分发引擎（派单的手）。任务到达后先进入队列，调度器周期性读取各设备状态，计算分发决策，把任务派给目标设备。

调度器的工作可以抽象成一个决策循环：每个时间片，从队列取任务 → 查询各设备负载 → 计算最合适的目标 → 派发并更新状态。这个循环的数学表达，就是“选择当前相对负载最低的设备”：

老陈的循环看似简单，难在坚持：哪怕只有一桌客人，他也会实时关注每位师傅的灶台变化。调度器同样以毫秒级周期不停运转，因为负载是流动的，平衡也必须是动态的。

4. 负载度量方法

老陈不只看灶台上的火苗，他还会数每位师傅手边没做完的订单张数、估算每道菜还要几分钟。对他来说，“忙”不是一个模糊感觉，而是一把能量化的尺子：把灶台前所有订单做完，还要多少分钟？

计算机里的负载度量，同样不能只看单一指标。设备利用率反映的是“过去一段时间”的状况，有滞后性；队列长度反映积压，但没考虑任务大小；平均执行时间反映成本，但缺少实时性。工程上把它们合成一个负载指数。

一种常用的负载指数，把积压任务数、平均执行时间和设备能力结合起来：

有了这把尺子，老陈不再凭感觉分单，而是时刻在心里给每位师傅打一个“清空时间分”。调度器的负载度量，就是它心里那把永远在更新的尺——尺子准，平衡才有基础。

5. 调度算法策略

面对新到的订单，老陈有三种派法：第一种，按厨师编号轮流来，一人一张；第二种，谁手头最空就给谁；第三种，根据每位师傅的出菜速度按比例分配——张师傅快，多给他，王师傅慢，少给他。当过领班的都知道，第一种最省事也最容易翻车。

调度算法也有同样的阶梯：轮询调度（Round-Robin）实现简单但不考虑设备差异；最少负载调度（Least-Loaded）实时找最闲的设备，已经比轮询聪明；加权调度（Weighted）则把设备算力差异直接变成分配比例，是工程上的主流选择。

加权调度的核心，是把新任务按设备算力占比来分发。设系统有 $n$ 台设备，设备 $i$ 的算力为 $C_i$，则它应获得的长期任务份额为：

老陈把三种派法都试过之后，最终采用了“加权 + 实时修正”的组合拳：平时按速度比例分，某位师傅临时积压时立刻把新单转给别人。纯比例是蓝图，实时修正才是让蓝图落地的方向盘。

6. 动态负载调整

周五晚上 8 点，甜品区突然爆单——10 桌客人同时点了舒芙蕾。王师傅的甜品炉前订单从 3 张涨到 20 张，而张师傅的爆炒台已经闲下来了。老陈立刻把一部分舒芙蕾单子抽出来，交给受过甜品培训的备用小灶去做。这一抽一补，就是后厨版的“任务迁移”。

现实中的推理负载同样会突发：某个大模型突然被大量用户访问，专属 GPU 显存吃紧、队列飞涨，而其他设备还在空转。仅仅靠静态加权分配远远不够，系统必须动态感知失衡并主动调整，这就是动态负载均衡。它包含四件事：实时监控、失衡判定、任务迁移、反馈调节。

失衡判定的量化方法是：计算设备 $i$ 的相对负载与系统平均相对负载的偏差，超过阈值 $\theta$ 就触发调整：

老陈并不会为一张订单的波动就大叫“迁移”，只有当甜品区明显积压时才动手。迁移本身有成本——抽单、交接、重新备料都需要时间。好的动态调整，是在“不平衡的损失”和“迁移的成本”之间找到平衡点。

7. AI推理应用

周末的餐厅迎来了最真实的考验：上百位客人同时涌进来，点的菜五花八门，而且每个人都有心理底线——等超过 15 分钟就摔门走人。后厨必须做到：出菜要快（低延迟），同时尽量接更多客人（高吞吐），还要保证每桌都能上菜（公平性）。

这正是 AI 推理服务部署的日常。多模型推理集群上，每秒钟都有大量请求到达，调度器要把它们分发给 GPU/CPU/NPU 上的模型副本。常用优化手段包括：按亲和度选择最合适的设备、动态调整批处理大小（batch size）、在设备过载时迁移请求。批处理就像同时烤 12 个舒芙蕾——吞吐倍增，但第一批客人要多等一会儿。

吞吐与延迟之间的权衡，可以用排队论中的 Little's Law 描述：系统中的在途请求数等于请求到达率乘平均处理时间。

当老陈学会“批量做同款菜 + 动态平衡灶台”这套打法，后厨才能在爆满的周末既保住翻台率又守住客人的耐心。AI 推理集群的负载均衡，做的正是同一件事：让每一块芯片都像被合理安排的大厨，忙而不乱，持续出菜。

AI 应用场景

Python 演示

class Device:    """异构设备: 算力不同, 当前积压任务量也不同."""     def __init__(self, name, capacity):        self.name = name        self.capacity = capacity        self.load = 0.0     def ratio(self):        """相对负载 = 积压 / 能力, 越低越空闲."""        return self.load / self.capacity     def finish(self, rate):        """每个时间片完成一部分任务, 负载自然回落."""        self.load = max(self.load - rate, 0.0)  class LoadBalancer:    """调度器: 新任务派给相对负载最低的设备, 失衡时迁移任务."""     def __init__(self, devices):        self.devices = devices        self.total = 0     def dispatch(self, amount=0.06):        best = min(self.devices, key=lambda d: d.ratio())        best.load = min(best.load + amount, 1.0)        self.total += 1        return best.name     def rebalance(self, threshold=1.2):        """最忙设备相对负载超阈值时, 把部分任务迁给最闲设备."""        src = max(self.devices, key=lambda d: d.ratio())        if src.ratio() <= threshold:            return None        dst = min(self.devices, key=lambda d: d.ratio())        moved = src.load * 0.3        src.load -= moved        dst.load = min(dst.load + moved, 1.0)        return (src.name, dst.name)  def main():    balancer = LoadBalancer([        Device("GPU", 0.5),        Device("CPU", 0.3),        Device("NPU", 0.2),    ])    print("step\tGPU\tCPU\tNPU")    for t in range(60):        balancer.dispatch()        for d in balancer.devices:            d.finish(0.02)        balancer.rebalance()        if t % 10 == 9:            ratios = [int(d.ratio() * 100) for d in balancer.devices]            print("%d\t%d%%\t%d%%\t%d%%" % (t + 1, ratios[0], ratios[1], ratios[2]))  if __name__ == "__main__":    main()

1. class Device:定义异构设备，capacity 是算力，load 是当前积压任务量。
2. def ratio(self):计算相对负载 = 积压 ÷ 能力，这是调度比较的核心尺子。
3. best = min(self.devices, key=lambda d: d.ratio())找出相对负载最低的设备，负载均衡的核心决策。
4. best.load = min(best.load + amount, 1.0)新任务加到目标设备上，上限 1.0 防止负载溢出。
5. def rebalance(self, threshold=1.2):动态调整：找出最忙设备，判断是否超过迁移阈值。
6. moved = src.load * 0.3把最忙设备 30% 的任务抽出来，迁给最闲设备。
7. balancer.rebalance()每个时间片检查一次失衡，形成“监控—判定—迁移”反馈闭环。
8. print("%d\t%d%%\t%d%%\t%d%%" % ...)打印三台设备的负载比，观察它们是否逐渐趋平。

常见误区

面试题