在异构硬件上跑深度学习任务，调度问题永远是绕不开的硬骨头。我这些年经手过不少训练推理项目，从单机多卡到集群部署，最头疼的往往不是模型本身，而是怎么把计算图里那几十上百个算子合理地分配到不同设备上。你手里的硬件资源越“杂”——GPU、CPU、NPU、FPGA混着来，这个问题就越突出。今天想分享的HeteroOpt，就是我在这个方向上一个比较完整的探索实践：一个面向异构新型硬件的深度学习计算图全局多目标调度框架。
它能做什么？简单说，给定一个训练或推理模型的计算图，以及一组可用的异构设备，HeteroOpt会自动完成算子到设备的分配、执行顺序的编排，让整体方案在“执行时间”“能耗开销”“设备负载均衡”等多个目标之间达到理想平衡。这事不是拍脑袋按层分一下就行，而是要把问题建模成最优化问题，再用启发式算法去求解。适合正在做AI基础设施、推理引擎、自动化运维，或者单纯对底层系统优化感兴趣的开发者参考。
1. 整体设计思路：为什么全局调度比局部贪心更值得做
先聊清楚一个问题：既然每张卡、每个设备都有自己的调度策略，为什么还需要一个“全局”调度框架？我在早期实践里也走过弯路——那时候习惯按算子的类型做简单规则匹配，比如卷积就丢GPU，矩阵乘也丢GPU，控制流逻辑放CPU。听着合理，跑起来往往不是那么回事。
1.1 局部决策的隐性代价
局部决策的核心问题是它只看单个算子的最优设备，完全忽略算子之间的数据依赖和通信成本。举个例子，模型里两个算子 A 和 B，A 在 GPU 上算，B 在 CPU 上算，如果 A 的输出是个 512×512×1024 的中间张量，那这层切分就意味着要把几百 MB 的数据从 GPU 显存拷贝到 CPU 内存。一次两次还行，整个图里几十处这样的跨设备拷贝累积起来，通信时间直接吞掉你在单算子层面省下的那点计算时间，得不偿失。
还有一层问题是局部贪心无法感知设备间的负载均衡。几个算子单独看都选了 GPU，可能它们在那一瞬间同时挤在张量核心上，互相争抢算力，最终谁都没跑快。真正的性能瓶颈往往不在单个算子，而在整张图的执行流瓶颈。HeteroOpt在设计之初就确定了要用全局视角来做调度决策，而不是把每个算子孤立地看。
1.2 把调度问题形式化成一个优化问题
既然要从全局出发，就要先把“调度”这个事用数学语言描述清楚。HeteroOpt把深度学习模型定义为一棵有向无环图，也就是我们常说的DAG，图中每个节点代表一个算子，每条有向边代表数据的依赖关系，边上的权重表示中间张量的大小，约等于通信量。
调度问题的核心，就是为图中的每个算子选择一个目标设备，并确定执行顺序，最终优化多个目标函数。这里我用三个目标来做说明。
- 执行时间：最后一个算子完成的时间，也叫做makespan，这是最基本的性能指标。
- 能耗开销：所有算子在各自设备上运行的总能耗，异构设备之间的能耗差异其实非常大，NPU跑矩阵乘通常比GPU省电不少。
- 负载均衡：各设备的利用率方差，方差越小，说明资源用得越均匀，不容易出现一台设备满载、其他设备空转的情况。
这三个目标互相牵制，性能好往往意味着能耗高，负载均衡又可能牺牲一点峰值性能。这不是一个能求出唯一最优解的问题，而是一个典型的多目标优化问题，需要找的是一组帕累托最优解。HeteroOpt的策略是用多目标进化算法去搜这组解，再让用户根据实际场景挑一个落地。
1.3 为什么选择启发式搜索而不是精确算法
如果你熟悉运筹学里的调度问题，可能会问：为什么不直接用整数规划或者分支定界求精确最优解？
因为计算图的规模不允许。一个 ResNet-50 的计算图里就有上百个算子，就算每个算子只有两种设备可选，解空间也有 2 的 100 次方量级，这还没算上执行顺序的排列组合。精确算法在这么庞大的搜索空间里根本跑不完，等它算出结果，训练早就该结束了。
启发式算法，尤其是进化算法，虽然不保证找到全局最优，但能在可接受的时间里找到一批足够好的方案，这在实际工程里才是真正有价值的东西。HeteroOpt选用了带精英保留策略的NSGA-II算法作为调度器底层的搜索引擎，这也是多目标优化领域的经典算法，成熟、稳定、效果好。
2. 异构设备特征建模与算子代价预估
调度算法再厉害，如果输入给它的数据不准，输出方案就是空中楼阁。所以HeteroOpt把精度重点放在了设备特征建模和算子代价预估上，这是整个框架的地基。
2.1 设备特征描述符
要让调度器知道每台设备适合干什么，得先给每台设备做一个结构化的“体检报告”。我设计了一套设备特征描述协议，覆盖了调度决策关心的所有维度。这里列一下我当时用的核心字段。
| 特征字段 | 含义说明 | 示例值 |
|---|---|---|
| device_type | 设备类型 | GPU / CPU / NPU / FPGA |
| compute_power | 峰值算力 | 19.5 TFLOPS (FP32) |
| memory_size | 可用内存/显存 | 24 GB |
| memory_bandwidth | 内存带宽 | 936 GB/s |
| energy_per_flop | 单位浮点运算能耗 | 0.08 uJ/GFLOP |
| support_ops | 支持的算子类型集合 | Conv, MatMul, ReLU... |
| comm_bandwidth | 与其他设备的通信带宽 | 32 GB/s (NVLink) |
这些特征数据不是光看硬件规格书就行，关键是得结合实际环境做基准测试。HeteroOpt提供了一套微基准测试工具集，在安装部署时会自动在新设备上跑一轮Conv、MatMul、ReLU、BN等常见算子的测试，把实际的延迟和能耗数据回填到特征描述符里。规格书上的理论算力在真实场景经常只能跑到六成，不做实测就去调度，后果会很惨。
2.2 算子代价预测模型
有了设备特征，下一步就是预估“某个算子在某台设备上的执行代价”。HeteroOpt采用了一种混合策略，综合了离线的算子性能数据库和运行时快速预测两个渠道。
- 离线性能数据库：框架内置了一个算子性能库，针对常见的算子形状组合（输入维度、卷积核大小、通道数等）做了预先benchmark，记录下每个算子在设备上的实测延迟和能耗。调度时优先查库，命中就直接用。
- 在线回归模型：当遇到库里没有的算子形状时，框架会启动一个轻量级的回归模型做预估。特征取的是算子的参数规模、计算量FLOPs、访存量这些结构性指标，模型用梯度提升树训练，输入输出维度都很小，预测一次开销不到几毫秒。
这里有一个细节要注意：代价预估没必要做到百分百精确。调度器需要的是能区分“这个算子放在GPU明显比放CPU快”这种量级差异，误差在百分之二三十以内完全够用。过度追求精确反而会让框架开销变大、响应变慢，得不偿失。
2.3 通信代价的建模
节点代价预估只是前半场，边上的通信代价同样很关键。我见过太多人做算子分配时只算计算时间，忽略数据搬移，最后整个调度方案严重失真。
通信代价的计算公式其实不复杂，我一般用 comm_time = data_size / comm_bandwidth 来做一阶估计。data_size就是传输张量的大小，comm_bandwidth根据两个设备之间的物理连接类型来确定：NVLink直连的带宽高，PCIe次之，跨机的以太网就是数量级的差距。带宽参数不能只看峰值，实际传输带宽受传输块大小影响很大，小块数据根本跑不满带宽，我在框架里对小块数据做了额外的固定开销补偿，模型会更贴近真实表现。
比如跨设备的算子搬运，如果同一个算子在设备 A 上算完、下一个算子在设备 B 上算，边的通信代价就是这两台设备间的传输时间。如果是同设备内的算子，通信代价约等于零。这个我们在代价模型里会显式区分，避免把不必要的拷贝时间算进代价里。
3. 核心算法实现：NSGA-II调度引擎剖析
设备特征和算子代价模型准备好之后，剩下的核心工作就是把调度方案的搜索过程跑起来。HeteroOpt的调度引擎基于NSGA-II做多目标进化，这里我把它的实现拆开聊聊。
3.1 基因编码与种群初始化
调度问题的第一步是编码。HeteroOpt的基因编码设计成两段式：
- 第一段是设备分配向量，长度等于算子数量，第 i 个位置的值表示第 i 个算子被分配到哪台设备。
- 第二段是拓扑排序向量，表示算子的执行优先级。这个向量必须满足计算图的依赖约束——如果算子 A 依赖算子 B 的输出，A 的执行优先级就不能高于 B。
这样设计的好处是，每个基因都能解码出一个合法的调度方案，不需要在进化过程中额外做大量的可行性修复，收敛速度快很多。
初始化种群时，HeteroOpt采用三种策略混合生成。第一种是纯随机生成，保证种群多样性。第二种是根据算子性能数据库生成贪心方案，每个算子直接选延迟最低的设备，这是搜索的良好起点。第三种是基于负载均衡的轮询方案，把算子轮流均匀地分配到所有设备上。三种策略各占三分之一左右，既能保证起步质量，又不会过早陷入局部最优。
这里再补一点我对“拓扑排序”的处理心得。种群初始化时生成随机拓扑序列容易依赖冲突，我的做法是先对计算图做一次完整的拓扑排序，得到一个基础序列，然后在这个序列上做随机交换，但每次交换后都检查依赖关系是否被破坏，破坏就撤销。实际跑下来大部分交换都能通过校验，成本可以接受。
3.2 快速非支配排序与拥挤度距离
进化算法的核心逻辑，就是不断从当前种群中选出“好的”个体，让它们交叉变异产生下一代。但什么是“好的”？在多目标优化里，答案不是唯一的。
这里用到了多目标优化里的“支配”概念。如果方案 A 在执行时间、能耗、均衡度三个目标上都优于方案 B，我们就说 A 支配 B。如果 A 在某个目标上优于 B，但在另一个目标上不如 B，那它俩是互不支配的，都值得保留。
NSGA-II做的第一件事就是对种群做快速非支配排序，把个体分成不同的帕累托前沿层级：第一层是谁也支配不了它的个体集合，第二层是除了第一层以外谁也支配不了它的个体集合，依此类推。层级越靠前，个体质量越高。
同一层内的个体，则用拥挤度距离来区分优劣。拥挤度距离描述的是某个个体周围邻居的密集程度：距离越大，说明这个方案在目标空间里覆盖的区域越空旷，越值得保留，这样能保证解的多样性，不会让所有方案挤在同一个角落里。每次进化迭代中，HeteroOpt都会优先选择层级靠前、拥挤度距离大的个体进入下一代。
3.3 交叉与变异策略设计
遗传操作直接决定了解空间的搜索能力。HeteroOpt在这块根据编码结构做了针对性的设计。
- 设备分配向量的交叉，用单点交叉：随机选一个切点，把两个父本的切点前后部分互换，生成两个新子本。只改变设备选择，不影响拓扑结构，操作成本很低。
- 拓扑排序向量的交叉，用顺序交叉，也就是经典OX算子：先从父本 A 里随机截取一段子序列，保留到子本里，再从父本 B 中按顺序填充剩余位置，填充时跳过已经存在的算子，这样得到的子本天然满足依赖关系。
- 变异操作分三种情况。一种是设备变异，随机选一个算子换一台设备；一种是拓扑变异，随机交换两个不违反依赖关系的相邻算子；一种是单点概率变异，每个算子以非常小的概率随机更换设备。三种情况的概率分配要精心调参，设备变异可以更频繁一些，拓扑变异不要太频繁，否则会破坏依赖结构的稳定性。
我一开始偷懒，直接把变异概率设成统一值，结果测试时发现拓扑变异一多，生成的个体频繁违反依赖约束，解码阶段经常要抛异常，整体收敛速度反而下降。后来改成固定高概率设备变异、低概率拓扑变异，问题就少多了。
3.4 调度方案的解码与执行时间估计
进化算法生成的基因不能直接拿去编译执行，还得有个解码步骤，把它翻译成可评估的调度方案。
解码过程是这样：先根据设备分配向量确定每个算子的执行设备，再根据拓扑排序向量确定执行顺序，最后模拟整张计算图的执行流程。模拟时框架维护一个全局时钟，遍历拓扑序列中的每个算子，查询它在目标设备上的预估执行时间，再考虑它的输入张量是否都在本设备上，如果不在，就把对应的通信时间也加到全局时钟上。
这里有一个细节很多人会忽略：异构设备之间通常是异步执行的，一台设备上的算子算完，数据传输到另一台设备，两边的时钟推进不是同步的。HeteroOpt在模拟时会为每台设备维护独立的时间轴，最后取所有设备时间轴中的最大值作为整张图的执行时间。这样才能反映出真实的流水线效果，否则会把异构并行的优势完全低估掉。
4. 多目标优化策略与目标函数设计
做多目标优化最容易踩的坑，是目标函数之间量纲不一致，导致优化过程偏向某一方。HeteroOpt在这个问题上做了仔细的处理，值得展开说说。
4.1 三个目标函数的归一化
执行时间用毫秒做单位，能耗用毫焦耳，负载均衡用方差。这三者的数值范围差了好几个数量级，如果不做归一化直接丢进进化算法，算法会天然偏向数值大的那个目标，其他目标形同虚设。
HeteroOpt的做法是引入一个参考点归一化：先做一个不调度的基准方案，也就是所有算子都放在默认设备上（通常是第一块GPU），测出这个方案的执行时间、能耗和负载均衡作为参考值。然后所有调度方案的目标值都用对应参考值的比例来表示。这样三个目标都变成了“相对默认方案提升多少倍”，量纲就统一了，数值范围都在 0.几 到 2 之间，进化算法可以公平地对待每个目标。
这个归一化设计虽然不起眼，但我认为是整个框架最关键的工程决策之一。如果你在复现类似系统时，不做归一化就扔进优化器，结果大概率是被执行时间这个目标牵着鼻子走，能耗和负载均衡只是摆设，整个多目标的意义就没了一半。
4.2 帕累托前沿与方案选择
NSGA-II的输出不是单个方案，而是一组互不支配的帕累托前沿解。需要用户或上层系统根据实际偏好，从前沿解中挑一个最终方案落地。
我在框架里做了一个简单的小工具，帮助挑选最终方案。它支持两类偏好输入，一类是指定权重，比如“执行时间权重50%，能耗30%，负载20%”，然后按加权和给前沿解排序，取最高分；另一类是约束式选择，比如“执行时间必须小于基准的1.2倍，能耗越低越好”，自动过滤掉不满足硬约束的方案后取最优。
这几行逻辑没什么复杂度，但在实际使用中反馈很好。系统使用者通常不想理解什么帕累托前沿、非支配排序，他们只关心：我的目标是训练快一点，还是省电一点，还是不要让某张卡爆显存。这个选择器把技术细节包装成了用户能理解的语言。
4.3 显存约束的处理策略
还有一个不可回避的工程约束：显存/内存容量。调度器把再大的算子分到 GPU 上，如果显存放不下，方案就没法落地。模型并行切成十几个分片，每个分片的中间激活值加起来很容易撑爆显存。
HeteroOpt把这个约束放进了代价评估阶段。判断一个调度方案合法性的前提，就是在模拟执行每个算子时，检查其输入输出张量是否能放到目标设备的可用显存里，如果放不下，把方案的适应度做特殊弱化处理，让它被天然淘汰，而不是走到最后才因为不合法被拒。
在做这个显存预估时，我把中间张量的生命周期也考虑了进去，而不是单纯累加所有算子输出大小。算子执行完以后，它的输出可能还有后续算子要用，但有些后续算子执行完之后，之前的中间张量就不再被需要了，显存就可以被释放复用。模拟器里维护了一个活跃张量表，边模拟边释放，这样做的显存预估比拍脑袋加一个峰值系数要准得多。我最初做框架时是直接估的峰值，经常把可达的最优方案挤出去，调整成生命周期模拟后，明确好很多。
5. 实操过程：定义计算图、配置硬件并跑通调度
理论讲了不少，下面把最核心的实操流程走一遍。HeteroOpt使用Python实现了全套接口，因为定义计算图、接PyTorch模型的动态图都很方便。
5.1 第一步：从PyTorch模型构建计算图
HeteroOpt接收的计算图以中间表示(IR)形式传入。最省事的方式是直接接入PyTorch的TorchScript或者ONNX导出结果。我当时优先接的是TorchScript，因为它在导出时能保留完整的控制流信息，对后续依赖分析很有帮助。
import torch import heteroopt as hopt # 假设你有一个定义好的PyTorch模型 model = MyResNet50() model.eval() # 构造一个示例输入 dummy_input = torch.randn(1, 3, 224, 224) # 导出为TorchScript，得到计算图 traced_model = torch.jit.trace(model, dummy_input) graph = hopt.Graph.from_torchscript(traced_model)导出后，Graph对象里就保存了所有算子节点和数据依赖边。你可以直接查看节点数量、算子类型分布，确认计算图结构是否符合预期。
print(f"总算子数量: {len(graph.nodes)}") print(f"依赖边数量: {len(graph.edges)}") # 统计算子类型分布 from collections import Counter op_counter = Counter([node.op_type for node in graph.nodes]) print(op_counter)5.2 第二步：构建设备池并校准设备特征
接下来就是构建设备池，做特征校准。框架会内置一批常见设备模板，推荐优先用基准测试校准一次，特征值会更可靠。
# 从模板构建设备池 devices = hopt.DevicePool([ hopt.DeviceSpec(template="NVIDIA_A100_40G", name="gpu0"), hopt.DeviceSpec(template="NVIDIA_A100_40G", name="gpu1"), hopt.DeviceSpec(template="Intel_Xeon_8480", name="cpu0"), hopt.DeviceSpec(template="Ascend_910", name="npu0"), ]) # 校准设备特征（会跑一轮微基准测试，耗时几分钟） devices.calibrate()校准这一步千万别跳过。我在一台新服务器上部署时，偷懒用了自带的设备模板，没有现场校准，结果NPU设备的实测性能只有模板数值的70%，调度器拼出来的方案在NPU上运行时间大幅超预期，后来老老实实重新校准才恢复正常。
5.3 第三步：配置优化目标并启动调度
目标函数是框架使用体验的一个关键点。HeteroOpt采用了声明式配置，想要什么目标，加进列表即可。权重的概念在NSGA-II里不是直接用的，但通过约束和过滤器也可以控制偏好。
# 配置优化目标 objectives = [ hopt.Objective(type="execution_time", weight=0.5), hopt.Objective(type="energy", weight=0.3), hopt.Objective(type="load_balance", weight=0.2), ] # 硬约束：显存不能超过15GB constraints = [ hopt.MemoryConstraint(max_memory_gb=15), ] # 创建调度器 scheduler = hopt.Scheduler( graph=graph, devices=devices, objectives=objectives, constraints=constraints, population_size=128, generations=200, mutation_prob=0.15, ) # 启动搜索 result = scheduler.run()关于种群大小和迭代代数，我的经验值是默认128和200，这两项在搜索质量和耗时的平衡上表现不错。如果计算图特别大，几百个算子，建议把种群大小降一降，代数提一提，不然一次搜索可能要跑十几分钟，等起来很痛苦。
5.4 第四步：分析结果并产出调度方案
调度结束后，result对象里保存了完整的帕累托前沿解集。框架提供了一个摘要输出，直接打印出每个方案的三个目标值。
# 展示帕累托前沿解集 for i, solution in enumerate(result.pareto_front): print(f"方案{i}: 时间={solution.exec_time:.2f}ms, " f"能耗={solution.energy:.2f}J, " f"负载均衡方差={solution.load_balance:.4f}") # 按用户偏好选最终方案 final_solution = result.select( style="weighted", weights={"execution_time": 0.5, "energy": 0.3, "load_balance": 0.2} ) # 输出最终的算子分配表 final_solution.summary()最终输出的算子分配表会详细展示每个算子放在哪台设备上、预估执行时间和能耗，可以直接作为部署配置喂给下游的执行引擎。
6. 实验评估：在真实场景中验证框架效果
框架写完，最终还是要用数据说话。我在两类场景里做了实验评估，一类是AI训练场景，用ResNet-50在双GPU加CPU的异构环境上做分布式训练；另一类是推理场景，用BERT在GPU加NPU的混合设备上做在线推理。
6.1 训练场景实验结果
训练场景的基线方案是PyTorch默认的设备分配策略：模型整体放在GPU0上，GPU1和CPU处于空闲状态。HeteroOpt调度后的方案会把部分算子搬到GPU1和CPU上，让三个设备形成流水线并行。
实验数据整理了一下，形成下面的对比。
| 方案 | 执行时间(一个step) | 能耗 | 负载均衡方差 |
|---|---|---|---|
| PyTorch默认(单GPU) | 100% | 100% | 1.8 |
| 手动逐算子分配(经验法) | 82% | 91% | 1.1 |
| HeteroOpt调度方案 | 65% | 74% | 0.35 |
HeteroOpt相比默认方案，时间直接降了35%，同时能耗降低26%，设备的负载均衡方差从1.8降到0.35。这里最惊喜的点是能耗能降这么多，因为矩阵乘算子被有效分散到了能效比更好的NPU上，一张卡的满负荷压力大大降低。
6.2 推理场景实验结果
推理场景对延迟更敏感，实验关注的指标是P99时延和吞吐量。设备组合是一块GPU加一块NPU，输入是长度为128的BERT序列。
实验结论是：单纯追求极低延迟的方案GPT-3全家放GPU，NPU闲置；但追求吞吐量的方案会把约40%的算子放到NPU上，整体吞吐量提升接近两倍，P99时延只增加了12%。对于大部分在线服务场景，这个性价比是极其诱人的。赫特罗Opt框架提供的帕累托前沿解里，这种不同偏好下的方案都可以选出来，用户按自己的服务等级协议要求挑一个直接上线。
这个实验也很好地说明了为什么多目标优化有意义：延迟和吞吐量天然冲突，硬要二选一并不理性，更合理的方式是像HeteroOpt这样，把选择权交给用户，让用户按业务需求决定取舍。
7. 常见问题与排障实录
框架成熟的过程，就是一个不断踩坑再不断填坑的过程。这里把我在开发和使用HeteroOpt时遇到的问题里最典型的几条整理出来，希望能帮后来者省点时间。
7.1 设备特征校准后调度方案反而变差
这是我早期被坑得比较惨的一次。新设备接入后做了校准，重新跑调度，结果方案质量比用模板还差。排查后发现，校准过程中个别算子因为数据量太小，实测延迟有大量噪声，回归模型被这些噪声点带偏，导致低延迟算子的代价被严重高估。
解决方案是给校准过程加异常值过滤：对同一个算子形状重复测10次，去掉最高和最低的20%数据，取中间值作为基准。这样噪声的影响就被压下去了。
注意：校准并不总是越精确越好。一定要加重复采样和异常值过滤，否则个别噪声点会把整个代价模型带偏。
7.2 大计算图的搜索时间过长
实践下来，几百个算子的计算图，HeteroOpt的搜索时间能到十几分钟。这个时长在离线场景还能忍，但如果是训练中途想动态调整调度策略，就有点慢了。
我做了两个维度的优化。一个是算子融合预处理：把计算图中连续的、没有分支的小算子（比如ReLU、BN）合并成聚类节点，有效节点数直接减少三成以上。另一个是继承式初始种群：如果之前已经算过一次调度，新一次搜索的初始化种群会继承上次的最优解，再混入随机个体，收敛速度能快两三倍。
7.3 显存约束判断失效
我在显存模拟器里曾经只跟踪了张量的大小，忽略了框架在设备上执行时的额外显存开销，比如CuDNN的workspace。结果调度器给出的方案在模拟时没问题，跑真实训练时直接OOM。
修复方法是把设备显存的可用容量乘以一个安全系数，默认0.85。也就是说标称40GB的显存，框架按34GB来约束。虽然会损失一点理论上的调度空间，但换来了实打实的稳定性，这个交易非常划算。
7.4 各设备负载差异巨大
某次实验发现调度结果里GPU0被塞了70%的算子，GPU1只有15%。分析了一下，原因是代价预估模型把GPU0的算力估得太高，所有计算密集算子都倾向选它。但实际模型放上去后，GPU0的计算和内存访问会互相争抢，真实性能远不如预估。
改进措施是给代价预估模型增加内存带宽占用率作为惩罚项。如果一个算子的访存量很大，即使GPU0算力高，访存带宽可能已经快打满了，再加算子得不偿失。模型增加这个惩罚项后，调度的负载均衡明显改善。
7.5 调度结果不稳定
同一套输入，连续跑两次调度，两次结果差异很大。这是因为进化算法本身带随机性，每次初始种群不同，收敛的具体路径也不同，最终落在帕累托前沿的不同位置很正常。
如果想复现结果，可以给scheduler.run()传入固定随机种子。但我个人建议不要过度依赖这个特性，调度器每次输出多组帕累托解，本来就是概率上足够好的方案集合，强求两次结果一致意义不大，挑出来的最终方案目标值差不多即可。
8. 扩展方向与实用心得
HeteroOpt当前已经能解决相当一部分实际调度问题，但距离完美的通用调度器还有距离。这里分享一下我看到的两个比较值得做的扩展方向，以及我个人的一点使用心得。
8.1 动态调度能力
当前的调度是静态的：给定计算图和设备池，算出一个方案就固定执行。但实际场景里，设备负载是波动的，比如某个GPU上同时还有别的任务在跑，可用算力已经不是满载了。静态方案应对不了这种动态变化。
我后面在框架里预留了动态调度的接口设计。核心思路是周期性重新评估每个设备的实时负载，如果发现某个设备超载，就触发局部重调度，只调整受影响的那部分算子，而不是全图重新优化。这个增量式的局部重调度策略，比全量重算要快出一个数量级。
8.2 面向自动并行训练
异构调度的上游还可以延伸一步：不光是决定算子放哪台设备，连模型是如何切分、并行策略如何选择（数据并行还是流水并行）也一起自动决策。这块是目前工业界的明显趋势，很多大厂都在推全自动并行训练。
HeteroOpt的算子级调度天然可以作为自动并行策略的“最后一公里”：先由上层策略决定模型怎么切分，再由HeteroOpt负责把切分后的算子高效地落到底层异构设备上。两者结合起来，才是真正完整的全自动训练基础设施。
8.3 个人的一点体会
从设计到落地，这个框架前前后后花了我大约三个月的业余时间。最大的感悟是：做系统优化类项目，建模能力往往决定上限，而工程打磨决定下限。调度算法选NSGA-II还是其他启发式算法，其实差别不大，真正把项目拖住的永远是那些细节——代价模型准不准、显存约束漏没漏、设备校准噪没噪声。这些细节每一个单拎出来都很不起眼，但叠在一起就直接决定了一个框架能不能从论文走进生产环境。
另外分享一个小技巧：无论目标函数设计得多精巧，最后落地时一定要增加一层“人工可解释性”的输出。调度器给出方案时，把每个算子选这个设备的理由简单列一下，比如“因为GPU算力高”“因为减少跨设备通信”，这种透明性在实际运维中非常受用。工程师拿到方案，一看理由就明白逻辑对不对，该不该手动干预，信任感一下就建立起来了。
如果你正在做类似的调度系统，我的建议是从小场景开始：先拿一个几十个算子的模型，搭好设备特征库和代价模型，把整个链路打通，再去挑战大模型。直接一步到位做几百个算子的复杂图调度，调试成本会高得让你怀疑人生。
