簡介移動邊緣計算的卸載算法實現(xiàn)包面向研究邊緣計算任務(wù)卸載的開發(fā)者與算法工程師重點解決計算任務(wù)在本地與邊緣服務(wù)器之間如何分配的問題以降低時延和能耗、提升服務(wù)質(zhì)量。壓縮包共18個文件以9個Python腳本為主體涵蓋卸載策略實現(xiàn)、測試與結(jié)果分析另含4張結(jié)果圖、2個最優(yōu)解結(jié)果文件及說明文檔整體約77KB目錄清晰便于快速上手。目前已有2524人學(xué)習(xí)下載。資源提供了多種優(yōu)化思路的代碼實現(xiàn)如貪心、遺傳、粒子群以及深度強化學(xué)習(xí)等并配有測試模塊、最優(yōu)解保存與結(jié)果可視化可幫助讀者理解任務(wù)相關(guān)性、網(wǎng)絡(luò)帶寬與能量效率的權(quán)衡也便于在此基礎(chǔ)上擴展自己的策略。適合課程設(shè)計、論文實驗或入門移動邊緣計算算法研究。1. 移動邊緣計算的卸載算法一個能直接復(fù)現(xiàn)的開源代碼庫移動邊緣計算MEC把云計算能力下沉到網(wǎng)絡(luò)邊緣終端設(shè)備把計算任務(wù)卸載給附近的邊緣服務(wù)器這在物聯(lián)網(wǎng)、5G通信和車聯(lián)網(wǎng)場景中直接決定了服務(wù)時延的上限。卸載算法的核心問題是哪些任務(wù)留在本地、哪些卸載到邊緣、卸載任務(wù)如何分配信道和算力資源才能在帶寬受限、服務(wù)器負(fù)載波動、任務(wù)實時性要求各不相同的條件下把延遲和能耗的加權(quán)和降到最低。MECOptimalOffloading-master 正是圍繞這個核心研究問題搭建的開源代碼庫里面包含環(huán)境模擬、多種卸載策略實現(xiàn)和實驗結(jié)果輸出模塊并且預(yù)留了深度強化學(xué)習(xí)的擴展空間。對正在做邊緣計算課程設(shè)計、算法性能對比或想從零搭建卸載仿真平臺的開發(fā)者來說這套代碼提供了能直接復(fù)現(xiàn)基準(zhǔn)算法、改參并二次開發(fā)的路徑。2. 卸載決策的基礎(chǔ)任務(wù)特征、網(wǎng)絡(luò)條件與目標(biāo)函數(shù)2.1 卸載決策的數(shù)學(xué)模型與目標(biāo)函數(shù)任務(wù)卸載問題的建模方式?jīng)Q定了后續(xù)算法的設(shè)計空間。常規(guī)做法是把卸載決策定義為一個帶約束的組合優(yōu)化問題每個任務(wù)只能選擇本地執(zhí)行或卸載到邊緣服務(wù)器執(zhí)行決策變量是一個二元向量0 表示本地1 表示卸載同時還有一個連續(xù)變量表示任務(wù)上傳時分配到的帶寬比例或者任務(wù)可以被切分后部分卸載的比例。目標(biāo)函數(shù)通常取延遲和能耗的加權(quán)和延遲由本地計算時間、上傳傳輸時間、邊緣排隊時間和邊緣計算時間四段組成能耗由本地計算能耗和無線傳輸能耗兩段組成。權(quán)重系數(shù)根據(jù)業(yè)務(wù)場景調(diào)整電池供電的移動設(shè)備把能耗權(quán)重調(diào)高車聯(lián)網(wǎng)這類實時性敏感的場景把延遲權(quán)重調(diào)高。約束條件是建模的另一半。每個任務(wù)有一個最大允許延遲deadline任何卸載決策的總延遲一旦超過它決策就是無效的多個任務(wù)共享上行信道分配給各任務(wù)的帶寬相加不能超過信道容量邊緣服務(wù)器的計算能力有限同一時刻能處理的 CPU 周期數(shù)有上限服務(wù)器排隊等待時間必須被顯式建模。這三類約束把問題從簡單的排序問題變成了真正的組合優(yōu)化難題卸載算法存在的意義也正在于此。表卸載問題建模的核心參數(shù)參數(shù)符號典型范圍說明任務(wù)數(shù)據(jù)量D0.110 Mbit決定上傳傳輸時間任務(wù)計算量C0.5100 Mcycles決定本地與邊緣計算耗時最大延遲T_max0.011 s超時則決策無效上行帶寬B550 Mbps共享資源需分配邊緣算力S550 GHz影響邊緣排隊時長權(quán)重系數(shù)α、β01αβ1延遲與能耗的平衡實際建模時α 和 β 的取值直接決定算法偏好。如果只調(diào)低能耗權(quán)重算法會傾向于把所有任務(wù)推到邊緣服務(wù)器以節(jié)省終端電量代價是邊緣排隊延遲飆升反過來只調(diào)高延遲權(quán)重終端本地 CPU 會被過度使用能耗上升。一個可接受的初始設(shè)定是 α0.6、β0.4先把結(jié)果跑出來再根據(jù)實驗數(shù)據(jù)迭代調(diào)整。2.2 經(jīng)典優(yōu)化算法選型貪心、遺傳與模擬退火的適用邊界有了數(shù)學(xué)模型下一步是選算法。貪心算法是最直接的基線策略——把任務(wù)按某個啟發(fā)式指標(biāo)排序依次決定是否卸載。常見的啟發(fā)式指標(biāo)是緊迫度數(shù)據(jù)量與截止時間的比值或者“本地計算時間 減去 預(yù)計卸載時間”的差值。貪心算法的計算復(fù)雜度在 O(n log n)處理幾百個任務(wù)毫無壓力適合作為對比實驗的基準(zhǔn)線。但貪心只著眼當(dāng)前任務(wù)不考慮多個任務(wù)之間的帶寬競爭在任務(wù)密集到達(dá)時通常拿不到最優(yōu)解。遺傳算法把一個卸載方案編碼成個體一個長度為任務(wù)數(shù)的 0/1 向量用適應(yīng)度函數(shù)評估方案整體質(zhì)量再通過選擇、交叉、變異迭代更新種群。它的優(yōu)勢在于不依賴目標(biāo)函數(shù)的梯度信息能跳出局部最優(yōu)劣勢是收斂較慢且每次迭代要評估整個種群任務(wù)數(shù)超過 300、種群規(guī)模到 50 時單輪迭代就要做一萬多次方案評估運行時間明顯拉長。模擬退火則是用溫度參數(shù)控制隨機接受劣解的概率溫度高時跳躍范圍大溫度低時逐步收斂到穩(wěn)定解。它比遺傳算法占內(nèi)存少適合中等規(guī)模100200 個任務(wù)的卸載決策但溫度衰減曲線需要反復(fù)調(diào)參——降溫太快會早早陷入局部最優(yōu)降溫太慢則運行時間成倍增加。三個算法的選型邊界可以粗略劃定任務(wù)數(shù)少于 50、對實時性要求極高時用貪心任務(wù)數(shù)在 50200 且需要近似全局最優(yōu)時用模擬退火任務(wù)數(shù)超過 200、能接受分鐘級離線計算時用遺傳算法。MECOptimalOffloading 代碼庫的 algorithms 目錄也正是按這一思路組織的每個算法獨立成文件方便替換和批量對比。2.3 深度強化學(xué)習(xí)的引入狀態(tài)空間與獎勵設(shè)計經(jīng)典優(yōu)化算法的共同短板是場景參數(shù)一變就得重新求解難以應(yīng)對邊緣網(wǎng)絡(luò)中任務(wù)到達(dá)的動態(tài)變化。深度強化學(xué)習(xí)被引入后問題的表述方式變成了馬爾可夫決策過程智能體在每個時隙觀察系統(tǒng)狀態(tài)輸出卸載決策環(huán)境反饋延遲與能耗并折算出獎勵值智能體通過與環(huán)境持續(xù)交互學(xué)習(xí)最優(yōu)策略。狀態(tài)空間的構(gòu)建直接影響訓(xùn)練效果。常見的狀態(tài)元組是 (channel_gain, task_size, required_cpu_cycles, server_load, battery_level)其中信道增益反映當(dāng)前無線環(huán)境質(zhì)量任務(wù)大小和所需計算周期描述任務(wù)特征服務(wù)器負(fù)載和電量決定卸載收益。五個特征通常做 min-max 歸一化避免量綱差異讓神經(jīng)網(wǎng)絡(luò)訓(xùn)練不穩(wěn)定。獎勵函數(shù)的設(shè)置建議在任務(wù)完成時給正獎勵延遲超限或卸載失敗時給負(fù)獎勵獎勵本身可以稀疏但不能缺失。動作設(shè)計上離散動作卸載/不卸載配合 DQN 結(jié)構(gòu)實現(xiàn)最簡單如果任務(wù)是可切分的連續(xù)卸載比例配合 DDPG 或 PPO 效果更好。訓(xùn)練中常遇到的一個陷阱是延遲和能耗的量綱差距過大——延遲是 0.1 秒量級能耗是 1 焦耳量級獎勵函數(shù)如果不做縮放網(wǎng)絡(luò)學(xué)到的策略會被數(shù)值更大的那項主導(dǎo)。解決方案是在獎勵里給延遲和能耗各乘一個縮放系數(shù)讓兩個量綱落在相近的數(shù)值區(qū)間。2.4 任務(wù)依賴約束從獨立卸載到DAG調(diào)度上面討論的都是任務(wù)相互獨立的情況但真實應(yīng)用里很少有這么干凈的場景。一個視頻分析任務(wù)可以拆成數(shù)據(jù)預(yù)處理、特征提取、結(jié)果融合三個階段后一個階段必須等前一個階段完成才能開始。把每個階段看作一個子任務(wù)它們之間的先后關(guān)系就構(gòu)成一個有向無環(huán)圖DAG。DAG 約束下子任務(wù) A 在本地執(zhí)行、子任務(wù) B 依賴 A 的輸出且被卸載到邊緣時B 的啟動時間必須加上 A 的完成時間和 A 到邊緣服務(wù)器的結(jié)果傳輸時間。這種跨設(shè)備依賴讓卸載決策的搜索空間急劇擴大貪心算法基本失效。常見處理方式是按 DAG 的層次順序遍歷先決策入口節(jié)點再逐層傳播約束配合遺傳算法或動態(tài)規(guī)劃求解。代碼庫里如果包含依賴建模通常在 mecoptimaloffloading 環(huán)境的任務(wù)生成器里能看到一個 tasks_with_dependencies 開關(guān)打開后任務(wù)會攜帶 predecessors 字段算法實現(xiàn)里就需要判斷前序任務(wù)的完成位置。3. MECOptimalOffloading代碼庫模塊結(jié)構(gòu)與復(fù)現(xiàn)流程3.1 目錄解析algorithms、tests、results 各自負(fù)責(zé)什么打開 MECOptimalOffloading-master 之后根目錄下的 .gitignore、README.md、LICENSE 是工程元文件真正的業(yè)務(wù)代碼集中在 mecoptimaloffloading、tests、algorithms、results 四個目錄里。mecoptimaloffloading 是主包放的是卸載問題環(huán)境的定義包括任務(wù)生成器、信道模型、邊緣服務(wù)器模擬器和能耗模型algorithms 目錄放各卸載策略的實現(xiàn)每個算法一個文件tests 目錄放單元測試和基準(zhǔn)實驗?zāi)_本results 目錄默認(rèn)存放運行結(jié)果輸出。表MECOptimalOffloading 核心目錄職責(zé)目錄/文件職責(zé)定位常見內(nèi)容mecoptimaloffloading核心環(huán)境包定義卸載問題場景任務(wù)生成、信道模型、服務(wù)器模擬、能耗與延遲計算algorithms卸載策略實現(xiàn)greedy.py、genetic.py、simulated_annealing.py 等tests基準(zhǔn)實驗與正確性驗證run_benchmark.py、test_constraints.py 等results結(jié)果輸出目錄按算法和場景命名的 CSV、日志文件拿到代碼庫后建議先讀 tests/test_constraints.py這個文件驗證算法輸出的決策是否滿足 deadline、帶寬和服務(wù)器容量三類約束。如果這些測試沒過說明算法決策本身就有問題后續(xù)跑出來的指標(biāo)沒有參考價值。3.2 環(huán)境準(zhǔn)備與依賴安裝我習(xí)慣先建一個干凈的虛擬環(huán)境再裝依賴。這套代碼基于 Python 3 編寫核心依賴是 numpy 和 pandas如果深度強化學(xué)習(xí)模塊被啟用還會依賴 stable-baselines3 或 tensorflow。安裝的常見流程如下cd MECOptimalOffloading-master python -m venv .venv source .venv/bin/activate # Windows 下是 .venv\Scripts\activate pip install numpy pandas python -m pytest tests/ -v上面命令的邏輯是先創(chuàng)建虛擬環(huán)境隔離依賴然后安裝數(shù)值計算和數(shù)據(jù)處理相關(guān)的包最后用 pytest 跑一遍 tests 目錄下的全部測試。如果測試全部通過說明環(huán)境和源碼匹配如果某個測試失敗優(yōu)先檢查 numpy 版本是否過新導(dǎo)致接口行為變化再檢查缺失的依賴。首次跑測試建議關(guān)注“多少 passed、多少 failed”而不是直接看細(xì)節(jié)。3.3 快速運行一個基準(zhǔn)實驗tests 目錄下通常有一個基準(zhǔn)實驗入口腳本用于在指定任務(wù)數(shù)量、帶寬和服務(wù)器算力下運行某個算法并輸出結(jié)果。常見調(diào)用方式是傳入算法名和場景參數(shù)python -m tests.run_benchmark --algorithm greedy --num-tasks 100 --bandwidth 20 --server-cpu 10參數(shù)說明--algorithm 選擇算法greedy 表示貪心genetic 表示遺傳sa 表示模擬退火--num-tasks 是任務(wù)數(shù)量決定問題規(guī)模--bandwidth 是上行信道帶寬單位是 Mbps--server-cpu 是邊緣服務(wù)器計算能力單位是 GHz。運行完成后results 目錄下會生成該算法對應(yīng)的結(jié)果文件通常包含每輪實驗的總延遲、總能耗、卸載任務(wù)數(shù)量、平均任務(wù)完成時間等字段。剛拿到代碼庫時優(yōu)先跑默認(rèn)參數(shù)確認(rèn)流程通順再把 --num-tasks 從 50 逐步增加到 200觀察運行時間的增長趨勢。這個操作能快速判斷代碼庫在當(dāng)前機器上的可用性也為后面做多算法對比提供了基線數(shù)據(jù)。結(jié)果文件是 CSV 格式的話可以直接用 pandas 讀進(jìn)來做分組聚合。3.4 核心算法代碼走讀以貪心卸載策略為例algorithms/greedy.py 是理解整個代碼庫的入口。它的核心結(jié)構(gòu)通常是按啟發(fā)式指標(biāo)對任務(wù)排序然后依次決定是否卸載實現(xiàn)如下import numpy as np def greedy_offloading(tasks, bandwidth, server_cpu, deadline_weight0.7): 貪心卸載決策按緊迫度排序逐個決定是否卸載。 tasks: list of dict, 每個任務(wù)包含: task_id, data_size(Mbits), required_cpu(cycles), deadline(s) bandwidth: 上行信道帶寬(Mbps) server_cpu: 邊緣服務(wù)器算力(GHz) deadline_weight: 排序時任務(wù)緊迫度的權(quán)重 decisions [] # 緊迫度 data_size / (deadline * required_cpu) # 值越大表示任務(wù)越“急”優(yōu)先處理 sorted_tasks sorted( tasks, keylambda t: t[data_size] / (t[deadline] * t[required_cpu]), reverseTrue ) local_load 0.0 # 本地排隊總計算量 edge_load 0.0 # 邊緣排隊總計算量 for task in sorted_tasks: local_time task[required_cpu] / 1.0 local_load # 本地算力 1GHz upload_time task[data_size] / bandwidth edge_time task[required_cpu] / server_cpu edge_load if upload_time edge_time local_time: decisions.append((task[task_id], 1)) # 卸載到邊緣 edge_load task[required_cpu] / server_cpu else: decisions.append((task[task_id], 0)) # 留在本地 local_load task[required_cpu] / 1.0 return decisions這段代碼的邏輯分三步先按“緊迫度”對任務(wù)排序貪心排序的核心是讓 deadline 更緊、計算量更大的任務(wù)優(yōu)先決策再依次估算每個任務(wù)的本地預(yù)計完成時間和邊緣預(yù)計完成時間最后選預(yù)計耗時較短的一側(cè)執(zhí)行。local_load 和 edge_load 兩個變量分別記錄排隊累積的任務(wù)量模擬了本地和邊緣的排隊效應(yīng)這是容易漏掉的部分——很多簡化版貪心只算單任務(wù)耗時不考慮排隊導(dǎo)致大批量任務(wù)時決策失真。理解了這個貪心實現(xiàn)再看 genetic.py 和 simulated_annealing.py 就輕松很多它們的差異只在決策搜索方式上任務(wù)模型、時間估算、結(jié)果記錄都是共用同一套環(huán)境邏輯。這也是卸載代碼庫的常見設(shè)計環(huán)境與算法解耦環(huán)境負(fù)責(zé)模擬與計算算法只負(fù)責(zé)搜索決策。3.5 擴展一個新算法從接口設(shè)計到接入基準(zhǔn)測試要在這個代碼庫上驗證自己的卸載策略關(guān)鍵是對齊基準(zhǔn)實驗的調(diào)用約定。常見做法是新建一個文件實現(xiàn)一個入口函數(shù)然后在 run_benchmark.py 的算法選擇分支里加入新算法名。示例如下# algorithms/my_algorithm.py import numpy as np def offloading_decision(tasks, bandwidth, server_cpu, params): 自定義卸載算法入口返回 [(task_id, decision)] 列表。 params 是外部傳入的字典可以用 params.get(threshold, 0.5) 這種方式讀取自己的超參。 decisions [] # 這里實現(xiàn)你的算法邏輯 return decisions接入基準(zhǔn)測試的步驟一般是先在 run_benchmark.py 里加一個 if 分支把 --algorithm my_algorithm 映射到上述函數(shù)再跑一遍 tests 目錄下的約束測試確認(rèn)返回的決策滿足 deadline 和帶寬約束最后用一個固定的小規(guī)模任務(wù)集對比同參數(shù)下新算法和貪心算法的輸出。整個過程不涉及環(huán)境模擬部分的修改改動集中在 algorithms 和 run_benchmark.py 兩個文件如果代碼庫支持注冊機制改動會更小。4. 避坑指南卸載算法實現(xiàn)中的常見問題與排查4.1 隨機種子不固定多次實驗結(jié)果對不上現(xiàn)象同一命令連續(xù)跑兩遍results 里的總延遲差 15% 以上深度強化學(xué)習(xí)曲線每次形狀都不一樣。原因卸載仿真里的隨機性來源很多——任務(wù)生成時的到達(dá)間隔和任務(wù)大小是隨機的信道增益每個時隙在波動遺傳算法的初始種群和變異操作同樣依賴隨機數(shù)。常見誤區(qū)是只調(diào)了 random.seed 忘了 numpy.random.seed導(dǎo)致部分隨機源還在震蕩。解決實驗?zāi)_本開頭統(tǒng)一固定所有隨機源并把種子作為命令行參數(shù)傳入import random import numpy as np def fix_seed(seed42): random.seed(seed) np.random.seed(seed)固定種子之后同一命令在同一環(huán)境下應(yīng)輸出完全一致的結(jié)果。需要留意的是不同 Python 或 numpy 版本的隨機數(shù)算法可能有差異所以對比實驗必須在同一解釋器環(huán)境下進(jìn)行否則即使種子相同結(jié)果也可能對不上。4.2 遺傳算法任務(wù)規(guī)模一大就內(nèi)存溢出現(xiàn)象num-tasks 從 100 加到 300遺傳算法腳本直接報 MemoryError進(jìn)程被系統(tǒng)殺掉。原因常見的是用列表套列表存儲整個種群每個個體是一個長度為任務(wù)數(shù)的 0/1 列表再加上適應(yīng)度緩存和多輪迭代的中間副本內(nèi)存占用成倍膨脹。另一個隱藏問題是評估適應(yīng)度時逐個體調(diào)用 Python 循環(huán)臨時數(shù)組反復(fù)創(chuàng)建垃圾回收跟不上。解決用 numpy 的二維 0/1 矩陣承載整個種群替代列表套列表評估適應(yīng)度時做向量化計算用矩陣運算替代 for 循環(huán)適當(dāng)縮小種群規(guī)模并提高迭代次數(shù)上限。定位內(nèi)存熱點用 memory_profiler 逐函數(shù)分析重點看哪個環(huán)節(jié)的臨時數(shù)組占用最大。4.3 強化學(xué)習(xí)訓(xùn)練不收斂卸載率來回震蕩現(xiàn)象DQN 訓(xùn)練了 5000 個 episode獎勵曲線沒有穩(wěn)定上升卸載率在 0.20.8 之間來回跳不同隨機種子下測試表現(xiàn)差異很大。原因三個常見原因。第一狀態(tài)特征未歸一化信道增益在 1e-3 到 1 之間波動、任務(wù)大小在 0.1 到 100 之間波動未歸一化的狀態(tài)輸入讓 Q 網(wǎng)絡(luò)訓(xùn)練極不穩(wěn)定第二獎勵函數(shù)中延遲的單位是秒、能耗的單位是焦耳數(shù)值差距跨了幾個量級網(wǎng)絡(luò)被數(shù)值更大的獎勵項主導(dǎo)第三經(jīng)驗回放池容量開得太大舊策略產(chǎn)生的經(jīng)驗長期占主導(dǎo)新策略學(xué)不動。解決對狀態(tài)空間的每個特征做 min-max 歸一化獎勵函數(shù)里給延遲和能耗各乘一個縮放系數(shù)讓兩部分的量級接近經(jīng)驗回放池容量控制在 1000050000 條之間小批量大小選 32 或 64。改完這三處多數(shù)不收斂問題都能明顯改善。4.4 能耗模型參數(shù)與文獻(xiàn)數(shù)據(jù)對不上現(xiàn)象用代碼庫默認(rèn)參數(shù)跑出的單任務(wù)能耗是 0.02 焦耳目標(biāo)論文里同場景是 0.5 焦耳差了 25 倍。原因能耗模型通常按“傳輸功率 × 傳輸時間 本地計算功率 × 計算時間”計算但不同文獻(xiàn)對傳輸功率、信道增益公式、本地 CPU 有效開關(guān)電容的取值完全不同。比如傳輸功率有的取 0.1W有的取 1W本地計算功率有的按 P κ·f3 計算有的直接給固定值。代碼庫默認(rèn)參數(shù)大概率對應(yīng)原作者的實驗配置直接套進(jìn)自己的場景必然失真。解決先確認(rèn)目標(biāo)文獻(xiàn)的能耗公式和參數(shù)取值再把能耗模型里的常量替換成對應(yīng)數(shù)值。比較穩(wěn)妥的做法是把傳輸功率、信道帶寬、CPU 頻率全部做成命令行可配置參數(shù)跑實驗前單獨驗證能耗模型的輸出是否落在合理區(qū)間。4.5 所有任務(wù)都卸載到邊緣本地算力閑置現(xiàn)象實驗結(jié)果里卸載率始終接近 1.0邊緣服務(wù)器負(fù)載打滿但本地 CPU 完全空閑總延遲反而比全本地方案更高。原因目標(biāo)函數(shù)里延遲和能耗的權(quán)重設(shè)置不平衡——能耗權(quán)重過高、帶寬又充裕時算法傾向于把所有任務(wù)都推到邊緣服務(wù)器來節(jié)省終端電量忽略了邊緣排隊延遲另一種可能是約束條件里漏掉了邊緣服務(wù)器每時隙的處理上限排隊只有計算時間、沒有排隊等待時間卸載看起來總是更快。解決檢查權(quán)重系數(shù)把延遲權(quán)重調(diào)高或者引入帶寬競爭懲罰項同時確認(rèn) edge_load 的疊加邏輯是否正確邊緣排隊延遲有沒有被算進(jìn)總延遲。如果問題依舊可以手動構(gòu)造全本地、全卸載、混合三個方案分別輸出總延遲做對比看算法有沒有明顯違背直覺的決策。5. 驗證卸載算法的有效性從仿真到指標(biāo)分析的完整流程5.1 單算法驗證跑通基準(zhǔn)場景先固定一個簡單場景任務(wù)數(shù) 50、帶寬 20 Mbps、服務(wù)器算力 10 GHz用貪心算法跑通整個流程。這一步的目的不是看性能而是確認(rèn)環(huán)境模擬、算法執(zhí)行、結(jié)果落盤三個環(huán)節(jié)沒有斷裂。驗證標(biāo)準(zhǔn)是 results 目錄下生成了完整的 CSV 文件文件里每一行有總延遲、總能耗、卸載任務(wù)數(shù)且沒有 NaN 或明顯越界值。5.2 多算法對比控制變量與結(jié)果匯總接下來做批量對比。用兩層嵌套循環(huán)遍歷算法名和任務(wù)規(guī)模其他參數(shù)保持不變for algo in greedy sa genetic; do for tasks in 50 100 200; do python -m tests.run_benchmark \ --algorithm $algo \ --num-tasks $tasks \ --bandwidth 20 \ --server-cpu 10 \ --seed 42 done done腳本跑完后用 pandas 匯總所有結(jié)果文件import pandas as pd import glob dfs [] for f in glob.glob(results/*.csv): dfs.append(pd.read_csv(f)) df pd.concat(dfs) summary df.groupby([algorithm, num_tasks]).mean() print(summary)看到匯總表之后重點關(guān)注兩個趨勢任務(wù)數(shù)增長時各算法的總延遲和總能耗是否同步增長遺傳算法相比貪心的優(yōu)勢是否隨規(guī)模擴大而體現(xiàn)如果遺傳算法在 50 個任務(wù)時反而比貪心差很可能是收斂條件設(shè)置太早需要增大迭代次數(shù)。5.3 參數(shù)敏感性分析一個批量復(fù)現(xiàn)的小技巧驗證算法有效性不能只看一個帶寬值。帶寬從 5 Mbps 變到 50 Mbps卸載收益完全不同。我常用的做法是單獨寫一個循環(huán)腳本把 bandwidth 作為外層變量algorithm 作為內(nèi)層變量固定 seed跑完后再把同一算法在不同帶寬下的曲線畫在一起。觀察卸載率隨帶寬的變化是否符合直覺帶寬小時卸載率低、帶寬充足時卸載率升高。如果曲線是亂跳的基本可以判定是約束條件沒寫全或者隨機源沒固定。從那以后我每次拿到新的卸載算法代碼庫都會先固定種子、跑通三個算法的基準(zhǔn)實驗再控制變量逐步放寬任務(wù)規(guī)模確認(rèn)這些基礎(chǔ)驗證都通過之后才會放心地在這個庫上做自己的策略改進(jìn)。希望幫到你。本文還有配套的精品資源點擊獲取