1. 拿到题目别急着写代码先把硬件的账算清楚多核调度这个题一眼看过去像个纯软件问题但实际是个硬件约束很重的规划问题。2026年华为杯A题把场景放在“通用神经网络处理器”——几乎所有参赛队都会先默认为“一个多核CPU上跑多个神经网络算子”然后照着操作系统进程调度那套思路去建模。这里我先泼一盆冷水这个默认假设大概率会让后面的模型和真实评分背道而驰。神经网络处理器和普通CPU有三个显著区别一是计算核心的粒度大一个核心往往对应一组可配置的计算阵列跑的不是通用指令流而是定点/浮点的算子级任务二是片上存储和片外传输严重不对称把权重从片外搬进片上存储的时间在很多规模下比算子本身计算时间还长三是任务之间有明确的张量依赖即使两个算子没有单步依赖它们共享的中间结果也会形成隐性同步约束。所以拿到题目之后我建议先花半天时间做三件事而不是急着读数据、写拓扑排序。第一把题目描述的硬件架构画成一张带参数的结构图。往年这类题目通常会给出核心数量、核心间互联拓扑、片上缓存容量、片外存储带宽以及“计算任务以算子为单位下发”这类描述。你可以先整理成一张表作为建模时的假设清单。硬件参数典型取值以赛题常规设定为参考对建模的影响核心数量416个决定调度解的空间规模也决定是否要考虑核间通信核心处理类型同构或异构部分核心擅长卷积决定任务与核心是否“可匹配”直接影响变量定义每核片上内存几MB到几十MB算子并行执行时会争抢存储必须作为额外资源约束通信方式共享总路线或环形互联决定是否要为跨核数据传输单独建模与计费任务粒度卷积层、全连接层、激活层等决定任务数量量级几百个节点以内模型必须可解第二把优化目标明确出来。大多数调度题目不会只让你最小化总完工时间makespan还会考虑核心利用率、能耗峰值、负载均衡甚至数据传输总量。你要做的是把这些目标统一成可比较的量纲。比如能耗如果题目没给精确功耗模型最简单实用的做法是用“核心活动时间 空转时间”的加权和作为代理指标如果题目给了每类算子的单位功耗就把功耗折成调度时长的加权项同步参与目标函数。第三估计数据规模与运行时间的边界。这是很多队翻车的地方题目附件可能给几十个任务节点也可能给上千个带复杂依赖关系的节点。如果节点数上了千你一开始就想直接用整数规划求解器拉一个全局最优基本等于把宝贵的比赛时间浪费在等待求解器跑死上。正确做法是先量化规模统计节点数、边数、平均出度、最长依赖链长度据此把问题定位为“小规模可精确求解”还是“中大规模启发式为主”。我上一届做同类问题时的经验是前半天把这三件事做完整个建模方向基本就定了。后面写模型、写代码、跑实验都只是在细化这个主干。反过来如果一开始就钻到“怎么排序更好”的细节里最后大概率会写出一个看起来像调度、实际上既没考虑存储也没考虑通信的方案这种方案在评审面前非常单薄。1.1 从计算图到调度图的转化题目里给神经网络计算结构时一般不会是“纯网络结构描述 纯执行时间表”那么干净。常见形式是给出算子之间的先后依赖以及每个算子的运算量、输出张量尺寸。你需要在建模型前把这种结构化成一张标准的DAG有向无环图节点是算子边是数据依赖节点上挂载执行时间、占用内存、可选核心类型。如果只有一个网络实例的任务这张DAG就是全部调度对象如果题目说“多个网络任务并发推理”那你还要把多个网络实例各自的DAG复制展开再在共享计算资源下统一调度。我曾经见过一个队伍把多个网络样本直接合并成一个超级DAG但里面的交叉依赖完全没处理结果调度出来前后矛盾。这类问题处理方式很简单为每个网络实例增加一个虚拟起始节点和虚拟终止节点共享资源约束仍然只发生在核心和存储层面网络内部依赖保持各自独立。另外DAG的构建千万别手工做。用脚本读题目附件的结构描述自动生成邻接表、前驱/后继集合、最长路径等信息。手工录入几百个节点的依赖关系既容易漏边也很难在后续排错时定位问题。2. 建模型的第一个决策把调度问题抽象成哪种数学形式调度问题在数学建模里最经典的抽象是“带资源约束的并行机调度”在工序排产里叫作业车间调度/柔性车间调度在分布式计算里叫任务调度。形式上虽然各家叫法不同本质上都是三个要素一组待执行任务、一组可用资源核心、一组约束依赖、存储、通信、同步。我建议在论文里呈现出两个层次的模型一个是概念上严谨、适合推导的数学规划模型另一个是实际计算中适合写代码、便于启发式算法快速求值的过程化模型。很多队伍只写第一个结果整篇论文算法设计和模型脱节也有队伍只写过程化模型评审会认为建模功底不足。两个层次都写既能证明你对问题理解得清楚又能让后文算法有直观的代码落脚点。2.1 数学规划模型的变量与约束设计假设题目给定了n个算子任务记集合Tm个核心记集合C。一个标准的连续时间模型可以这样搭决策变量( x_{ij} ) 表示任务i是否分配到核心j( s_i、f_i ) 分别表示任务i的开始时间和完成时间。依赖约束如果任务b依赖任务a那么 ( f_a \le s_b )如果a和b在不同核心上执行还需要额外加上通信时延 ( trans(a,b) )即 ( f_a trans(a,b) \le s_b )。占用约束每个任务只能分配到一个核心即 ( \sum_j x_{ij}1 )。单核串行约束同一核心上任意两个任务i和k要么i先完成再开始k要么反过来用一个大M表达互斥条件。内存约束在同一核心上同时驻留的任务内存总和不能超过核心存储容量也可以用带时间片粒度的内存占用检查来实现。这种模型可以直接交给求解器但必须清醒认识到当任务数超过100、核心数超过8时连续时间模型的变量和约束会膨胀得很快尤其是大M约束会让线性松弛很差求解时间不可控。所以论文里写这个模型是为了严谨性和可读性实际求解要用后文的启发式方法。2.2 为什么我最终用“离散时间事件推进”做评估核心真正的求解阶段我更推荐用离散事件仿真的思路来评价一个调度方案。也就是把时间切成“事件点”事件点触发条件为某个核心完成当前任务、有任务满足依赖约束可以下发。每个事件发生时系统扫描可执行任务集合按某种优先级选择任务将其指派给合适的空闲核心。用这种过程化模型的好处有几点第一它天然处理依赖和资源冲突不需要大M互斥约束第二通信时延、存储占用、负载均衡都能通过事件处理函数逐个累加非常容易调试第三它同时可以当做一个“调度仿真器”既可用于启发式算法的评估也可用于论文实验对比不同优先级策略。很多没有工程经验的队伍会直接在约束规划里写“服从性约束”试图模拟过程这没问题但在代码层面往往非常笨重。我是建议把“建模”和“仿真”视为并行双轨论文里用数学规划显示理论严谨性代码里用事件推进的仿真器承载实战计算。这种双轨安排在竞赛论文中很常见也最容易让评审跟上你的思路。2.3 约束条件的取舍哪些必须严格哪些可以软化调度问题真正难的地方是“约束太多了”。你必须学会区分硬约束和软约束。硬约束是指违反就必然不合法例如任务依赖、单核串行、核心类型匹配。这部分必须严格保证。软约束是指可以基于目标函数做权衡的例如功耗峰值、负载不均衡、存储余量。我的建议是内存约束视题目描述决定是否升级为硬约束。如果题目强调“每个算子的中间结果必须完整存在片上”那内存不足就是硬约束。如果题目只说“片上存储有限”那可以建模为“超过阈值的部分需要额外通信开销/排队”把它折算进目标这样比一刀切禁用更容易找到可行解。另外异构核心之间的“相同算子不同执行时间”我建议不要建模成复杂的多模式任务而是在评估函数里做一个映射表——每个算子类型在每个核心类型上的执行时间直接用查表实现。后面写代码时这个映射表可以来自题目数据也可以来自你根据运算量估算出来的近似值。这样模型复杂度不会因为异构而爆炸。3. 求解方向选型为什么我把重心放在构造式启发式上建模环节确认之后最核心的一步是选求解方法。很多队伍一开始就想上模拟退火、遗传算法这类元启发式觉得名字响、写起来高级。但我的经验是对于竞赛中的中大规模调度题目构造式启发式往往是性价比最高的首解方案元启发式则适合在构造式基础上做局部改进直接裸跑效果通常一般。3.1 列表调度与关键路径优先列表调度List Scheduling是最简单也最稳定的框架。核心逻辑是维护一个“就绪任务集合”即前驱任务全部完成、可以被执行的任务每次取出一个可用核心按优先级从就绪集合中挑任务分配给它没有可用核心或没有就绪任务时推进时钟到下一个任务完成时刻。在这个框架里优先级设计决定一切。从实践看最稳的优先级组合是关键路径长度节点到汇点的最长剩余耗时优先关键路径长的任务优先执行同等关键路径长度时后继节点多的任务优先再做最后一层平局打破比如编号小的优先、内存占用大的优先以便尽早释放大块存储。这种优先级组合实现简单结果也普遍优于“按编号/按执行时间”的朴素策略。关键路径优先的本质是让调度器尽量压缩整个DAG的瓶颈链和后续元启发式的邻域搜索也兼容如果一个解的makespan偏大先看关键路径上的核心利用率大概率能找到改进方向。3.2 处理器选择逻辑快核优先还是低负载优先任务选好之后接下来的问题是“把任务分给哪个核心”。我建议用“最早完成时间EFT”规则对每个空闲核心模拟把该任务放上去后的起始时间和结束时间选择产生最早完成时间的核心执行如果多个核心完成时间一样则优先选择当前已分配任务数较少的核心保证负载均衡。注意EFT规则必须考虑通信时间和内存约束。不同核心如果通过共享总线互联传输延迟可能和距离有关但竞赛题通常不会把互联拓扑细节给到那么细。按照常见设定我会先假设任意两个核心之间的通信时延固定如果题目明确给了矩阵或拓扑再改成查表。这里有个容易被忽略的小坑跨核传输时间和数据量往往呈线性关系所以我在实现EFT时会预计算一个通信开销矩阵核心间数据量大的边在依赖约束里额外加一个通信时间。实测下来忽略这个通信项会让调度结果空有“局部最优”的假象放到真实硬件设定下偏差很大。3.3 用什么方式做双核互补GA 局部搜索构造式启发式解决的是“从无到有”的问题元启发式解决的是“从有到优”的问题。我的做法是先跑若干种子策略比如关键路径优先、最短执行时间优先、最少后继优先得到几个不同的初始解再用局部搜索对每个解做改进最后取最优。最简单的局部搜索是“关键路径上的任务搬移”找出当前关键路径上的所有任务逐个尝试将其移动到其他核心看能否缩短makespan重复这个过程直到没有可改进的移动。这个操作比直接上遗传算法靠谱得多因为它精准打击瓶颈而不是盲目随机交换。如果题目规模确实大到你愿意花时间跑遗传算法我给过一个比较稳的编码方式编码每个任务对应一个基因位基因位的值是核心编号解码对给定编码按依赖关系做拓扑序使用插入式调度模拟出每个任务的开始时间从而算出目标函数初始种群用多个不同的优先级策略生成再加入随机个体交叉按任务索引的单点交叉即可因为任务编号语义稳定变异随机选一个任务将其分配到当前负载最小的核心上修复如果内存约束/核心类型不匹配变异后立即检查并回退到原分配保证每个个体都是可行解。遗传参数我常用的是种群100、迭代200代、交叉率0.8、变异率0.1。对几百个任务节点的规模这个配置在几分钟内可以得到比构造式初解好5%15%的结果。再往上增加迭代边际收益就很有限了反而显得浪费时间。3.4 不同数据规模下的算法切换策略竞赛题目通常包含多个子问题可能一部分是小规模数据一部分是大规模数据。我建议在这种多问结构下按数据规模动态切换规模特征建议求解方式任务≤30核心≤4可以尝试精确建模用求解器或穷举验证结果任务100500核心8左右构造式启发式 局部搜索 遗传算法组合任务1000核心≥16先跑快速构造式启发式再用局部搜索控制总求解时间关于时间分配我给自己定的原则是首解必须在2小时内跑出来优化迭代控制在半天内跑完。不要把一个算法的迭代次数无脑调大因为比赛后面还要留出时间做论文、画图、检查代码。好方案是“快出解慢打磨”而不是“慢出解没时间打磨”。4. 用Python快速搭一套可验证的调度求解框架代码环节我的习惯是用Python做原型验证因为数据结构灵活、调试直观、画图方便。但要注意Python在极端数据规模下性能会吃亏所以我通常把核心评估函数写成“批量数组操作”的风格而不是用大量细粒度循环需要提速的地方再用Numba或者直接转C实现同一逻辑。4.1 数据结构用dataclass组织任务和核心我用Python写调度仿真器时最稳定的数据结构是dataclass它比字典可读性好也比自定义类写起来省心。from dataclasses import dataclass, field dataclass class Task: tid: int name: str duration: int # 在当前核心类型上的基准耗时异构时用字典 memory: int # 算子需要占用的片上存储 core_type_bits: int # 位掩码表示可在哪些核心类型上运行 preds: list field(default_factorylist) succs: list field(default_factorylist) dataclass class Core: cid: int core_type: int total_mem: int busy_until: int 0 # 当前任务完成时间 schedule: list field(default_factorylist)输入解析时我会把题目附件统一转成两个表任务表和依赖表。如果题目给的是Excel/csv直接用pandas读如果给的是JSON或结构化文本用json或逐行正则解析。这里我强烈建议写一个独立的parse_data.py把输入规整成上面两个dataclass列表后续所有算法都只依赖这个统一接口。这样即使后面发现读错数据也只需修一个文件。4.2 调度模拟器事件推进 三个评估函数事件推进的核心函数可以设计成这样def simulate(schedule_plan, tasks, cores, comm_time): # schedule_plan: {task_id: core_id} # 返回: (makespan, energy_cost, max_mem_usage) ready [] # 就绪任务 remaining {t.tid: len(t.preds) for t in tasks} running {} # core_id - (task, finish_time) assigned_time {} # task_id - start_time clock 0 # 初始化所有无前驱任务进入就绪 for t in tasks: if len(t.preds) 0: ready.append(t.tid) exec_order [] while ready or running: # 找出最早完成的核心 if running: min_finish min(fin for _, fin in running.values()) else: min_finish float(inf) # 推进时钟到下一个事件 if not ready: clock min_finish finish_running_tasks(running, remaining, ready, exec_order, clock) continue # 选择一个任务执行按优先级规则 task_id select_task(ready, tasks) core_id schedule_plan[task_id] # 检查核心当前是否空闲不空闲则先推进到空闲 if running.get(core_id, (None, float(inf)))[1] clock: clock running[core_id][1] finish_running_tasks(running, remaining, ready, exec_order, clock) # 分配 start max(clock, calculate_data_ready_time(task_id, assigned_time, schedule_plan, comm_time)) running[core_id] (task_id, start tasks[task_id].duration) assigned_time[task_id] start ready.remove(task_id) exec_order.append(task_id)评估函数我通常写三个一是总完工时间makespan也就是所有任务完成的最大时刻这是最核心的指标二是能耗代理我按每个核心“运行时间×单位功耗空转时间×空转功耗”累加三是最大存储占用用来检查分配方案是否可能突破片上存储。把这三个评估结果同时打印出来能让你在调试时立刻看出一个“看起来不错”的解到底在哪一类约束上翻车。4.3 可视化用甘特图定位调度瓶颈调度结果光看数字很难发现问题我的习惯是无论如何都画一张甘特图。import matplotlib.pyplot as plt # 每个核上按时间轴画任务块 fig, ax plt.subplots(figsize(14, 6)) for core_id, tasks_on_core in enumerate(core_schedule_lists): for task_id, start, end in tasks_on_core: ax.barh(core_id, end - start, leftstart, labelNone) ax.text((start end) / 2, core_id, tasks[task_id].name, hacenter, vacenter, fontsize7) ax.set_xlabel(time) ax.set_ylabel(core id) plt.tight_layout()从甘特图里我通常看三样东西整个时间轴上有没有明显的长空闲段关键路径上的任务是否集中压在某一个核心上跨核通信多、但拓扑上不应该并行的任务有没有出现“相互等待”。这些信息比任何统计指标都直观。如果发现某个核心在关键路径长度上明显空闲但同时makespan下不来大概率是存储约束或通信约束导致无法把任务挪过去此时就要回头检查约束是不是建模过度了。4.4 用理论下界验证结果合理性调度问题很难让评委相信你的解“足够好”所以一个简单有效的手段是给出下界。最常用的两个下界关键路径下界DAG中最长路径上所有任务耗时之和。无论怎么分配总时间不可能小于这个值。资源总量下界所有任务总工作量除以核心总数再加上不可避免的通信开销。如果工作集中这个下界通常比关键路径更紧。把启发式结果和这两个下界做对比论文里给出(\text{gap} (\text{makespan} - \text{lower_bound}) / \text{lower_bound})。实战中一个结构良好的调度方案gap能控制在10%以内就算很健康如果gap超过30%就该考虑是不是优先级策略或者通信建模有明显缺陷而不是盲目调遗传算法参数。5. 从求解代码到竞赛论文图表、比较和灵敏度分析怎么做竞赛论文的目的是让评审在十几分钟里相信“你的模型对、算法有效、结果可靠”。很多队伍求解做得不错论文却写成了一本流水账列出所有公式但看不出任何决策依据。我的建议是把所有关键结论都变成可以对比的图表并用短句写明“从表x可以看出”。5.1 建立统一的符号系统和假设清单模型部分最忌讳的是符号前后不一致。我的做法是先建一个符号总表凡是后文用到的变量、常量、目标函数缩写全部先列出来。这个总表不要超过15行否则评审看着累。例如(T)任务集合(C)核心集合(x_{ij})任务-核心分配(s_i,f_i)起止时间(\tau_{ij})通信时延(M_j)核心存储容量。假设清单要尽量“是真假设”而不是“为简化而强行假设”。比如你假设“同一批算子类型在相同核心类型上耗时稳定”这种假设合理但如果你假设“通信时延忽略不计”那就非常影响模型可信度建议只在题目未给通信数据时才使用并补一句“该假设在小规模样例上通过灵敏度分析验证过影响小于x%”。5.2 实验结果展示表格对比 收敛曲线 甘特图一般赛题的论文里至少要有三组图/表第一组是“不同优先级策略的makespan对比表”。我可以列出关键路径优先、最短执行时间优先、内存大者优先、随机策略在同一组样例上的表现。这一组数据用来证明你设计优先级时有针对具体问题做比较而不是拍脑袋定一个顺序。第二组是“初始解与GA优化后的改进幅度表”。这个表最好同时给出下界和gap值评审一眼就能看出你的最优解离理论上限还有多远。第三组是“最终得到的最优调度甘特图”最好画23个子问题的结果。甘特图是论文里最直观的“成品展示”它能证明你的模型不是停留在公式层面而是真正把任务排到了每个核上。如果篇幅允许再加一条“迭代收敛曲线”展示遗传算法的适应度随代数下降的过程。注意收敛曲线不能画成一条笔直的下降线真实算法往往是阶梯状下降后进入平台期这个曲线本身就是证明你算法参数合理性的证据。5.3 灵敏度分析让模型经得起“假如”追问评审很喜欢问“如果某个参数变了你的方案还成立吗”。所以在论文里主动做灵敏度分析是性价比很高的做法。我建议至少做三组核心数量从4变到8、16看makespan是否按预期下降且下降速度合理通信时延从0变到基准值的2倍看结果和调度方案是否稳健内存容量缩小20%看是否依然有可行解以及makespan恶化多少。这三组实验不用每个都跑得很重选少量具有代表性的样例即可。比如我上一届做类似题时把通信时延作为主灵敏度变量画了一条“通信时延-相对makespan”的曲线并在论文里写明“当通信时延增长一倍makespan增长约18%说明调度方案对通信敏感实际部署时应优先优化跨核通信路径”。这样就把实验结果和工程判断连在一起了评审会觉得你的分析有闭环。6. 我做调度类赛题踩过的坑和值得保留的习惯最后分享几个我在多届数学建模竞赛里反复踩过、也终于改掉的坑。第一个坑是“数据格式即正义”。有一年我们队花了一天半写出了很漂亮的调度算法结果复盘时发现读入脚本把任务依赖边漏了一条原因是题目附件里的某个sheet列名格式不统一pandas读出来变成NaN。从那以后我要求所有成员第一步把数据校验做在前面统计节点数、检查每个任务是否只有一个直接前驱组、检查拓扑排序是否可行。校验不过后面的所有结果都等于零。第二个坑是“算法越来越复杂问题越做越偏”。调度类题目最吸引人的地方是元启发式花样很多但评委想看的往往是一个“干净、可复现、结果好”的方案。我现在写论文时有一个习惯算法部分先讲构造式启发式因为它最容易复现、也最容易解释“为什么有效”遗传算法作为改进手段放在后面占一两页篇幅即可。第三个坑是“代码和论文脱节”。竞赛评审虽然不会真的把每个队提交的代码全部跑一遍但如果你论文里声称“遗传算法迭代200代收敛”结果代码里循环只跑了50代一旦被发现整个队伍的诚信都会受到质疑。所以我的整理习惯是论文里每个数据都有对应脚本可以复现并给脚本起清晰的名字比如run_heuristic.py、run_ga.py、plot_gantt.py、sensitivity_comm.py。如果这篇A题你能坚持完成前四章的内容其实已经在“调度问题”上超过了大部分参赛队。剩下的就是保持耐心让算法慢慢跑出结果同时把论文写得让人能看懂。我个人的体会是这类题目真正的挑战不是某一项算法有多高级而是你能不能把所有环节——硬件理解、建模、启发式、仿真、可视化、论文输出——串成一个完整闭环。把每个环节打磨稳了哪怕用的方法并不花哨最后的名次通常也不会差。如果你正在备赛建议现在就找个DAG样例把第4章的模拟器框架跑通再逐渐加入通信和内存约束。跑通第一版你就有底气去和队友讨论“要不要上GA”这类进阶问题了。祝顺利。
