通用神经网络处理器核内调度优化：建模、算法与参赛资源库

简介：调度优化是计算系统设计中的经典问题，尤其在资源受限的异构计算场景下，如何高效分配计算单元、缓存与访存带宽，直接决定系统整体性能。从最基础的资源约束项目调度问题（RCPSP）原理出发，其NP-hard本质催生了从整数规划到启发式算法的多层次求解思路。关键路径分析提供下界，列表调度与局部搜索在大规模问题上给出工程可行解，这类技术广泛适用于神经网络处理器（NPU）编译器、算子调度与异构计算等工业场景。针对华为杯研究生数学建模竞赛A题提出的通用神经网络处理器核内任务调度需求，本文以完整参赛视角，详细拆解问题建模、算法实现、数值实验与资源库打包全流程，并整理踩坑记录与实用经验，为类似组合优化问题提供可直接参考的解决方案。 我得先說一句：看到「华为杯研究生数学建模竞赛A题通用神经网络处理器核内调度优化解决方案与资源库」這個標題的時候，我第一反應是「這玩意兒光名字就夠勸退的」。但真正把賽題拆開讀完，會發現它本質上就是一個披着硬件外衣的經典調度問題。2025年第二十二屆競賽把「通用神經網絡處理器架構下的核內任務調度」當作A題，表面上是在考AI芯片知識，骨子裡其實是在考你怎麼把一個實際工程問題抽象成數學模型，再用算法把它解掉。這篇文章我打算從一個完整參賽者的視角，把建模思路、算法實現、數值實驗和資源庫打包這條線全部講透，重點說說那些文檔裡不會寫、只有自己踩過坑才知道的細節。

適合看這篇的人主要有三類：一是準備參加華為杯或者同類建模競賽的研究生，想找一份能直接參考的A題完整解法；二是做NPU編譯器、算子調度、異構計算調度方向的工程師，想看看競賽題和工業界真實問題的差距；三是單純對組合優化算法感興趣，想找一個有意思的練手場景的人。我盡量把每一步「為什麼這麼做」也講清楚，而不是只甩代碼。

1. 賽題拆解：核內調度到底在調什麼

1.1 問題背景：通用神經網絡處理器裡的那個「核」

先說清楚題目背景。通用神經網絡處理器（General Neural Network Processor，簡稱GNNP）不是一個具體芯片型號，而是一類架構的統稱。它通常包含多個計算核（Core），每個核內部有乘加陣列（MAC Array）、激活單元、池化單元、片上緩存（SRAM/Scratchpad）、數據搬運引擎（DMA）等部件。我們常說的神經網絡推理加速，本質上是把卷積、全連接、池化、激活這些算子映射到這些硬件單元上執行。

「核內調度」這個詞容易把人繞暈。它不是操作系統裡說的進程調度，也不是集群層面的任務分配，而是指 在單個計算核內部 ，決定一組算子以什麼順序、佔用哪些資源、在什麼時間點開始執行。舉個生活化的例子：你把一個廚房（計算核）交給一個廚師（調度器），廚房裡有灶台、烤箱、料理機、水池（硬件單元），你要做一桌菜（神經網絡），每道菜有固定的步驟（算子），有些步驟必須先做（依賴關係），有些步驟可以同時做（並行），但灶台只有那麼幾個（資源限制）。你怎麼安排才能讓這桌菜最快上齊？這就是核內調度。

賽題一般會給你一個計算圖，節點是算子，邊是數據依賴關係，每個算子帶有計算量、中間結果大小、所需硬件資源等屬性。你的任務是給出每個算子的開始執行時間和結束執行時間，使得整體完成時間（makespan）最小，同時滿足所有依賴約束和資源容量約束。

1.2 從題目文字到數學語言：約束與目標的歸納

把賽題翻譯成數學語言，是整個參賽過程中最關鍵的一步。很多隊伍死磕算法，結果連模型都沒建對，後面全白搭。我當時讀完題目後，把它歸納成以下幾類要素。

第一個是 依賴約束 。算子之間存在前驅後繼關係，比如卷積的輸出要進激活函數，那激活算子必須在卷積算子完成之後才能開始。這在數學上寫成：如果算子 $j$ 依賴算子 $i$，那麼 $S_j \geq S_i + D_i$，其中 $S$ 是開始時間，$D$ 是執行時長。

第二個是 資源約束 。核內資源包括計算單元數、片上緩存容量、訪存帶寬等。在任意時刻，所有正在執行的算子對某類資源的佔用總量不能超過該資源容量。這個約束是調度問題的核心難點，也是它和普通拓撲排序的區別所在。

第三個是 非搶占約束 。一個算子一旦開始執行，就不能被中斷，必須連續執行完畢。這讓問題變成一個離散時間優化問題，而不是連續時間問題。

第四個是 數據搬運時間 。算子執行前需要把輸入數據從片外DRAM搬到片上緩存，執行完後要把輸出寫回。這部分時間可以建模成一個「搬運算子」，也可以併入算子本身的執行時長，取決於賽題給的數據粒度。

目標函數最常見的是最小化總完成時間，有的賽題會加上能耗目標或者資源利用率目標，做成多目標優化。我當時果斷選擇了最小化 makespan 作為主目標，因為這是最直觀、也最好評判的指標。

把這些要素寫清楚之後，你會發現這道題本質上就是作業調度領域非常經典的「帶資源約束的項目調度問題（RCPSP）」。RCPSP 是一個 NP-hard 問題，這意味著賽題大概率不會只給你一個小規模案例，一定會有中大型測試數據，逼著你上啟發式算法。

2. 建模思路：三層遞進，從精確解到可行解

2.1 第一層：整數規劃模型，小規模數據的「標準答案」

建模的第一步，我建議先寫一個精確模型。哪怕你知道它跑不動大規模數據，它也至少有兩個作用：一是幫你理清約束條件，確保後面寫啟發式算法的時候不會漏掉關鍵限制；二是可以用來驗證小規模測試數據的結果，作為啟發式算法的基準答案。

整數規劃模型的經典寫法有兩種：一種是基於時間離散化的變量定義，另一種是基於事件點（event point）的模型。時間離散化最直觀：把時間軸切成單位長度，定義決策變量 $x_{i,t}$ 表示算子 $i$ 是否在時刻 $t$ 開始執行。約束包括：

• 每個算子只能開始一次：$\sum_t x_{i,t} = 1$
• 依賴約束：$\sum_t t \cdot x_{j,t} \geq \sum_t (t + D_i) \cdot x_{i,t}$
• 資源約束：對任意時刻 $t$ 和資源 $r$，$\sum_{i: S_i \leq t < S_i + D_i} \text{req}_{i,r} \leq C_r$
• 目標：最小化 makespan $M$，其中 $M \geq S_i + D_i$ 對所有 $i$ 成立

你往代碼裡一寫就會發現，這種建模方式在算子數量超過五十個、時間跨度超過幾百個單位之後，變量數量會爆炸。比如一百個算子、五百個時間步，那就是五萬個 $x_{i,t}$ 變量，再加上約束，商業求解器也得跑半天。

所以這個精確模型不要指望拿它跑大規模數據，它的定位是「小規模驗證器」。我當時的做法是：先手搓幾個只有幾個到十幾個算子的小案例，用 OR-Tools 的 CP-SAT 求解器跑出最優解，把這個結果存下來，後面所有啟發式算法的結果都要跟它對比。

這裡有一個容易忽略的細節：CP-SAT 求解器雖然本質上也是整數規劃求解器，但它對「調度類問題」的建模方式比傳統 MIP 求解器更友好。你可以直接用 AddNoOverlap 、 AddCumulative 這些約束來表示資源佔用，代碼寫起來簡單很多。下面是一段骨架代碼：

from ortools.sat.python import cp_model

model = cp_model.CpModel()
starts = {}
ends = {}
intervals = {}

for i in tasks:
    starts[i] = model.NewIntVar(0, horizon, f"start_{i}")
    ends[i] = model.NewIntVar(0, horizon, f"end_{i}")
    intervals[i] = model.NewIntervalVar(starts[i], tasks[i].duration, ends[i], f"interval_{i}")

# 依賴約束
for i, j in edges:
    model.Add(starts[j] >= ends[i])

# 資源約束
for r in resources:
    model.AddCumulative(
        [intervals[i] for i in tasks if r in tasks[i].resource_types],
        [tasks[i].resource_demand[r] for i in tasks if r in tasks[i].resource_types],
        capacity[r],
    )

makespan = model.NewIntVar(0, horizon, "makespan")
for i in tasks:
    model.Add(makespan >= ends[i])
model.Minimize(makespan)

2.2 第二層：圖論加關鍵路徑，快速算出下界和初始解

精確模型跑不動的時候，圖論視角就該上場了。調度問題裡有一個很樸素但極其有用的概念：關鍵路徑。沿著依賴圖從起點到終點，計算每一條路徑上的算子執行時長之和，最長的那條就是關鍵路徑。關鍵路徑的長度是 makespan 的一個天然下界，因為這條路徑上的算子必須一個接一個地執行，沒有任何並行空間。

關鍵路徑的計算方法就是我們熟悉的拓撲排序加動態規劃。先對 DAG 做拓撲排序，然後按拓撲序更新每個算子的最早可能開始時間（Earliest Start, ES）和最早結束時間。再反向做一遍，得到最晚開始時間（Latest Start, LS）。一個算子的機動時間定義為 LS - ES，機動時間越短，說明它越「關鍵」，應該賦予更高的調度優先級。

我把這個思想寫成了一個基礎調度器：每次從所有可調度算子（前驅都已完成）中，選出機動時間最小的算子優先執行。這種策略在調度領域叫「最短路徑優先」的變體，實際效果相當不錯，尤其在資源約束不緊張的場景下，它幾乎能逼近最優解。

這個階段的輸出有兩個：一是關鍵路徑長度作為下界，二是這個貪心調度得到的可行解作為上界。有了上下界，你就能評價後面優化算法的好壞——gap = (上界 - 下界) / 下界，這是一個非常直觀的指標，寫論文的時候評委也愛看。

2.3 第三層：啟發式搜索，應對大規模數據的殺手鐧

有了貪心解之後，下一步是把它變好。我當時試了兩種路徑：一種是元啟發式（遺傳算法、模擬退火），另一種是改進型列表調度。最後的結論是： 在競賽時間內，與其花大力氣調一個華麗的元啟發式，不如把列表調度的優先級策略做得扎實一些，再用局部搜索做後處理。

列表調度（List Scheduling）的基本邏輯非常簡單：維護一個就緒隊列（所有前驅已完成、且資源能容納的算子），按照某種優先級規則排序，依次取出算子安排到最早可用時間。優先級規則有很多種，常見的有：

• 關鍵路徑長度（CP）：後續最長路徑越長，優先級越高
• 後續節點數（LNS）：後續依賴的算子越多，優先級越高
• 最長處理時間（LPT）：執行時間越長，優先級越高
• 最早完成時間（EFT）：貪心選擇能使當前部分解最早完成的算子

沒有任何一種規則能通吃所有場景。比如資源緊張時，LPT 通常表現好，因為把長任務先塞進去能避免後面碎片化；依賴鏈很深時，CP 表現更好，因為它本質上是在保護關鍵路徑不被阻塞。我最後的做法是動態權重組合：優先級 = α × CP + β × LNS + γ × LPT，然後用一小部分測試數據做參數搜索，找出最合適的 α、β、γ 組合。

如果時間允許，後處理可以用「鄰域搜索」：隨機選擇幾個非關鍵算子，把它們的執行順序打亂重排，如果 makespan 變短就保留，否則回退。這個操作相當於對解做微擾，能跳出貪心算法的局部最優陷阱。我當時在 500 個算子的測試集上，用這種「貪心 + 局部搜索」的組合，比單純貪心平均提升了 8% 左右。

3. 算法實現：從偽代碼到能跑通的代碼

3.1 數據結構設計：DAG 表示與調度表

建模完成後，第一件事是把數據結構定義好。我見過太多隊伍在比賽第二天還在為鄰接表還是鄰接矩陣糾結，其實這種問題根本不該花超過十分鐘。我的建議是：節點數在幾千以內，直接用鄰接表；依賴關係查詢頻繁的場景，外加一個布爾矩陣做輔助。

每個算子節點我建議用一個字典或者 dataclass 存儲以下屬性：

@dataclass
class Task:
    id: int
    duration: int                # 執行時長
    resources: dict              # {資源類型: 需求量}
    successors: list             # 後繼算子id列表
    predecessors: list           # 前驅算子id列表
    es: int = 0                  # 最早開始時間（動態更新）
    ls: int = 0                  # 最晚開始時間
    critical: bool = False       # 是否在關鍵路徑上

調度結果用「時間段表」來存，而不是用二維數組存每個時刻的資源佔用。時間段表的思路是：維護一個列表，每個元素是一個時間區間 [start, end) 以及該區間內各種資源的剩餘量。安排一個新算子時，遍歷時間段表找到最早能容納它的位置，插入後更新區間。這種實現比逐時刻模擬要快得多，尤其在時間跨度大的時候。

3.2 核內調度主流程：事件驅動的列表調度

調度主流程可以寫成一個事件驅動的循環。核心邏輯如下：

1. 初始化：把沒有前驅的算子加入就緒隊列。
2. 從就緒隊列中按優先級取出一個算子。
3. 在資源時間段表中查找該算子最早可開始時間（要滿足所有資源需求）。
4. 分配時間段，更新資源佔用。
5. 更新該算子後繼的「前驅完成數」計數器，如果某個後繼的所有前驅都已完成，把它加入就緒隊列。
6. 重複 2~5，直到所有算子都被調度。

這裡有兩個細節特別容易出問題。第一個是「查找最早可開始時間」的實現。很多人簡單地認為，只要資源還有餘量就可以開始，但實際上有個隱藏條件：算子的所有前驅雖然已經完成，但它的輸入數據可能還需要從片外搬運到片上緩存。如果賽題把數據搬運時間單獨建模，你需要在算子開始前預留搬運時間，這實際上相當於一個隱式的搬運算子。我當時的處理方式是把搬運時間直接加在依賴邊上，讀者可以理解為邊權。

第二個細節是優先級排序的時機。就緒隊列不是一次性排好序就行，因為每調度完一個算子，可能會有新的算子加入就緒隊列，而且某些算子的關鍵路徑長度會因為前驅完成而更新。所以優先級排序應該在每輪循環中重新計算，或者至少做增量更新。

下面是列表調度的核心骨架代碼：

def list_schedule(tasks, priority_func):
    ready = [t for t in tasks if not t.predecessors]
    remaining_pred_count = {t.id: len(t.predecessors) for t in tasks}
    schedule = {}
    timeline = [(0, float("inf"), {r: cap for r, cap in caps.items()})]

    while ready:
        ready.sort(key=lambda t: priority_func(t), reverse=True)
        task = ready.pop(0)
        start_time = find_earliest_start(task, timeline)
        end_time = start_time + task.duration
        schedule[task.id] = (start_time, end_time)
        update_timeline(timeline, task, start_time, end_time)

        for succ in task.successors:
            remaining_pred_count[succ.id] -= 1
            if remaining_pred_count[succ.id] == 0:
                ready.append(succ)

    return schedule

3.3 複雜度控制與加速技巧

說一個競賽中很實際的問題：你的算法要在規定的時間內跑完所有測試數據，而不是理論上能跑完就行。我第一版代碼在 1000 個算子的案例上跑了將近一分鐘，後來優化到一秒以內。關鍵在於幾個點。

第一，資源時間段表的查找不要暴力遍歷。我最初是從時間 0 開始逐個區間試，遇到不滿足條件的就往後推。後來改成維護一個「最早可行時間」的指針，每次從上次的指針位置開始查找，複雜度從 O(n²) 降到了接近 O(n)。

第二，依賴關係的存儲用位運算。當節點數不超過 64 時，用一個 Python 整數的位來表示每個節點的前驅集合和後繼集合，判斷「某個節點的所有前驅是否都已完成」只需要一次位運算 (finished_mask & pred_mask) == pred_mask 。這個優化在節點數多、依賴關係密的場景下效果非常明顯。

第三，優先級計算裡用到「後續節點數」和「關鍵路徑長度」，這兩個值在 DAG 不變的情況下是固定的，應該提前預計算，而不是每次調度都重新遞歸算一遍。只需要在算子前驅完成、加入就緒隊列時更新一次。

我也試過用多進程並行跑多組參數組合，比如同時跑三種優先級規則取最好結果。但要注意，Python 的多進程在 Windows 下要用 if __name__ == "__main__" 守護，不然跑起來會無限遞歸報錯。這個坑我當時也踩了，後面第 5 章會細說。

4. 數值實驗：測試用例設計與結果解讀

4.1 測試數據生成器：最容易被低估的一環

很多隊伍把精力全放在算法上，結果數據生成器寫得很隨意，導致算法測試完全不充分。我建議數據生成器要儘量模擬賽題可能出現的幾類典型場景。

場景一： 鏈式依賴 。一個算子只依賴前一個，形成一條長鏈。這種場景下調度空間很小，關鍵路徑就是下界，任何算法都能做到最優，它主要用來驗證模型正確性。

場景二： 寬並行 。大量算子互相獨立，沒有依賴關係，瓶頸全在資源容量上。這種場景考驗的是資源分配能力，好的調度器應該能把資源用滿。

場景三： 混合結構 。部分區域密集、部分區域稀疏，類似真實神經網絡中的卷積塊與全連接層混合。這是最接近賽題真實數據的類型。

我寫了一個隨機生成器，控制三個參數：節點數 N、每個節點平均後繼數、每個算子的資源需求範圍。生成後會自動做拓撲排序，確保依賴圖無環。同時生成一個驗證函數，檢查輸出的調度是否滿足所有依賴和資源約束，避免算法有 bug 還不自知。

4.2 基線與對比：沒有對比的實驗等於沒做

實驗部分一定要有基線。我設了三組基線：一是「隨機調度」，也就是每次從就緒隊列裡隨機選一個算子，完全不看優先級；二是「拓撲序貪心」，按拓撲排序依次調度；三是關鍵路徑下界。然後拿我的三個優先級變體（CP、LNS、CP+LPT 混合）去對比。

直接說結果。在 N=100、資源中等緊張的混合結構測試集上，隨機調度的 makespan 平均是 1200 左右，拓撲序貪心是 980，CP 優先級是 860，混合優先級是 810，關鍵路徑下界是 720。混合優先級相對基線的改進是 32.5%，相對下界的 gap 是 12.5%。在資源極度緊張的場景下，混合優先級的優勢更明顯，因為它既保證了關鍵路徑不被耽誤，又能把長任務提前塞進資源窗口。

下面是當時一組測試結果的簡表：

這個表格說明一個問題：節點數越大、結構越複雜，貪心和最優之間的差距就越大，也越需要後續的局部搜索來補救。

4.3 結果分析：為什麼有的場景算法失效了

我調試時發現一個很有意思的現象：在資源非常緊張的場景下，純 CP 優先級反而會變差。原因是，CP 優先級高的算子往往聚集在關鍵路徑上，而它們的資源需求量可能也很大，如果把它們全部提前執行，會把資源窗口擠爆，導致一些本來可以並行的小算子被迫延後。這就像廚房裡烤箱和灶台都被一道大菜佔著，其他小菜只能乾等。

這個現象讓我意識到，優先級函數裡必須加入「資源佔用成本」的考量。我最後的混合優先級函數實際上是一個線性加權： priority = w1 * CP_length + w2 * LNS + w3 * duration - w4 * resource_volume ，其中 resource_volume 是算子對各類資源需求量的加權和。負號表示資源消耗越大的算子越應該靠後，除非它的關鍵路徑長度非常高。

參數 w1~w4 的整定我沒有用太複雜的方法，就是用一小部分驗證集做簡單的網格搜索。這裡要提醒一句：參數是在驗證集上調的，千萬不要拿測試集去調參，否則就是數據洩漏，寫論文會被人詬病。

5. 資源庫打包：zip結構、使用說明與踩坑記錄

5.1 資源庫的文件佈局與使用方式

這份方案的最終交付是一個 zip 資源庫，包含建模文檔、算法代碼、測試數據和實驗結果。文件結構我建議這樣組織：

gnnp_scheduler/
├── README.md
├── docs/
│   ├── 問題重述與假設.md
│   ├── 建模與算法說明.md
│   └── 實驗報告.md
├── data/
│   ├── generate_cases.py
│   └── cases/
│       ├── chain_50.json
│       ├── wide_200.json
│       └── mixed_500.json
├── src/
│   ├── model.py
│   ├── scheduler.py
│   ├── ilp_solver.py
│   ├── heuristics.py
│   └── verify.py
├── results/
│   ├── summary.csv
│   └── gantt/
└── requirements.txt

我強烈建議所有數據都用 JSON 存，不要用自定義的 txt 格式。JSON 有現成的解析庫，而且結構清晰，導出成表格也更方便。每個案例文件裡至少包含 tasks 和 edges 兩個字段， tasks 裡每個元素有 id 、 duration 、 resources ， edges 裡是 [predecessor_id, successor_id] 的列表。

使用方式很簡單。解壓後在根目錄執行：

pip install -r requirements.txt
python src/scheduler.py --input data/cases/mixed_500.json --output results/summary.csv

verify.py 會讀取調度結果，檢查所有約束是否滿足，並輸出驗證報告。我建議在提交之前一定要跑一遍驗證，這是防止「算法跑出結果但結果不合法」的最後一道防線。

5.2 zip解壓與環境配置容易踩的坑

說幾個我實際遇到過的坑，這些都是血淚教訓。

第一個坑是「file is not a zip file」。這個錯誤十有八九是下載不完整導致的。比賽最後提交的時候，文件往往有幾百 MB，網絡一抖就下載了一半，解壓當然報錯。我的建議是下載完先看文件大小是否和頁面標註一致，或者用壓縮軟件自帶的「測試壓縮檔」功能檢查完整性。

第二個坑是 Windows 下解壓後文件名的編碼問題。如果用系統自帶的資源管理器解壓含中文文件名或中文文件夾的 zip，偶爾會出現亂碼。後續導入 Python 模塊時，如果路徑含中文，部分第三方庫會報編碼錯誤。最穩妥的辦法是解壓後把文件夾改名成純英文路徑，比如 D:\Work\gnnp_scheduler 。

第三個坑是依賴版本衝突。 ortools 這個庫在不同版本之間 API 有改動， requirements.txt 裡一定要鎖定版本號，而不是寫 ortools>=9.0 。我當時就在複現別人代碼的時候，因為 CP-SAT 的 AddCumulative 接口差異卡了半天。鎖定版本看似小細節，其實能省下大量時間。

第四個坑和 Python 多進程有關。如果你要在 Windows 上並行跑多組參數，必須把並行代碼放在 if __name__ == "__main__": 塊裡，否則會無限創建子進程，最後內存爆炸。這個問題在 Linux 上不明顯，但 Windows 上必現。

5.3 版本管理：別讓「最終版」真的變成最終版

競賽時間緊張，代碼迭代特別快。我第一天寫的是精確模型，第二天改成貪心，第三天加局部搜索，到了第四天已經有了七八個版本的腳本。如果文件名寫的是 scheduler_final.py 、 scheduler_final_v2.py 、 scheduler_final_真的最終版.py ，那基本等著翻車。

我建議哪怕再趕，也要用 git 做版本管理。比賽前先在本地 git init ，每個穩定版本打一個 tag，實驗結果和代碼版本對應起來。這樣萬一某個優化方向越調越差，可以隨時回滾。

另外，生成結果時一定要把用的模型參數、優先級權重、測試集文件名一起記到 CSV 裡。沒有這個「實驗日誌」，到寫論文的時候你根本不知道那張漂亮的表格是用哪組參數跑出來的。

6. 參賽複盤：時間分配、論文寫作與評審關注點

6.1 四天三夜的節奏：前期可以慢，後期必須穩

華為杯的賽制是四天三夜，時間看起來很長，但實際非常緊張。我觀察到很多隊伍的前兩天都在「讀題、討論、推翻、重讀」，真正寫代碼只有一天，最後寫論文只剩幾個小時，質量自然不行。

我的建議是：第一天上午必須完成題目解讀和模型假設，下午寫出精確模型的代碼，哪怕只是小規模能跑的版本。第二天必須完成基線貪心算法，並在小規模數據上驗證正確性。第三天做優化和實驗，同時每天都要固定留出晚上兩個小時寫論文草稿。第四天上午整合實驗數據，下午集中寫論文，晚上打磨圖表和格式。

這裡有一個反直覺的經驗： 前期花越多時間在文檔上，後期越省時間。 我第一天就把問題重述、模型假設、符號說明寫成了 markdown，後續所有討論都在這個文檔上增量更新。到最後寫論文時，一份幾千字的初稿已經在眼前了。

6.2 論文最核心的三塊：模型、算法、實驗

評委看論文的節奏通常是一分鐘掃結構、五分鐘看模型、十分鐘看實驗。所以這三塊必須寫得無可挑剔。

模型部分，符號表一定要完整，變量定義要精確到「它是連續變量還是離散變量」「取值範圍是什麼」。約束條件不能只寫公式，每個約束都要配一句中文解釋，說明它在物理意義上對應硬件裡的哪個限制。評委裡可能有做硬件出身的老師，他會死死盯住「你的模型是不是真的反映了硬件行為」。

算法部分，偽代碼比提供整段源代碼更重要。偽代碼要寫清楚輸入、輸出、初始化、每步操作、時間複雜度。建議複雜度的分析寫在偽代碼的註釋裡，讓評委一眼知道你的算法在什麼規模下能跑。

實驗部分，最重要的不是展示你的方法有多好，而是展示你的方法在各種場景下都穩定。建議至少做四組實驗：正確性驗證（小規模對比最優解）、不同優先級規則的對比、不同資源緊張度的敏感性分析、大規模案例的運行時性能。每張表都要有文字解讀，講清楚「這個結果說明了什麼」。

6.3 對後來參賽者的幾點實在建議

第一，不要過度迷信複雜算法。一個寫得乾乾淨淨、每一行都能講清楚的啟發式算法，比一個黑盒深度強化學習模型得分高得多。評委最怕看到那種「我們用了改進的深度 Q 網絡，但因為時間不夠沒有調好」的論文。

第二，模型和代碼要對得上。我見過一些論文，模型裡寫的是整數規劃，附錄代碼裡卻是一個完全不相干的貪心算法。這種不一致在答辯時會被一票否決。我建議在論文裡明確寫一句「代碼中的 ilp_solver.py 對應第三章的精確模型， heuristics.py 對應第四章的啟發式算法」，讓評委的檢查路徑暢通。

第三，數據可復現是加分項。如果你能提供一份測試數據生成器，並在 README 裡寫清楚隨機種子怎麼設，評委會覺得你的工作非常紮實。這個細節的性價比極高。

第四，圖表一定要清潔。調度問題最好的可視化是甘特圖，x 軸是時間，y 軸是資源或者算子，不同顏色區分不同算子類型。一張乾淨的甘特圖比一千字文字描述更有說服力。用 matplotlib 畫甘特圖不難，就是把每個算子的執行區間畫成一個水平條。

最後再分享一個小技巧：遇到調度類題目，先判斷它是否帶資源約束。如果只是單純的 DAG 調度且資源無限，那麼關鍵路徑長度就是最優解，任何算法都不會超出這個下界。一旦引入資源容量，問題才真正變成 NP-hard。這個判斷能讓你在建模初期就避開「把簡單問題想複雜」或者「把複雜問題想簡單」兩個極端。

我個人在這次比賽裡最大的收穫不是獎項，而是徹底理解了「調度問題的難點不在找解，而在建模」這句話。資源約束調度、關鍵路徑、列表調度這套工具箱，後面做任何系統設計都能用上。這份資源庫我後續還會繼續完善，如果你也做到這道題，歡迎拿我的代碼跑一跑，看看在你的數據上表現如何。

本文还有配套的精品资源，点击获取