Hello folks，我是 Luga，今天我們來聊一下人工智能應用場景 - 構建大模型應用架構設施底座：異構算力。

在后摩爾時代與AI爆發的雙重驅動下，計算架構正經歷一場從同構到異構的深刻變革。

以 GPU、NPU、FPGA、DPU 等加速器為代表的異構算力已成為提升系統性能和能效比的關鍵。然而，如何對這些特性迥異的算力資源進行高效、公平、穩定且智能的調度，已成為橫亙在云計算、高性能計算、邊緣計算乃至通用計算領域的一大“卡脖子”難題。

本文將從宏觀架構、微觀機制、業務場景三個維度，深入剖析高效異構算力調度面臨的挑戰，并探討其本質、根源與潛在的解決之道。

一、如何看待：從“算力紅利”到“算力瓶頸” ?

在過去十年中，算力被視為 AI 發展的燃料。從 CPU 到 GPU，從 TPU 到 NPU，計算架構的演進速度前所未有。然而，當算力類型變得越來越多樣、越來越分散時，一個被忽視多年的問題開始浮出水面：

算力的調度效率已經成為系統整體性能的瓶頸。

換句話說，我們擁有越來越多的“引擎”，但缺乏一個足夠聰明的“駕駛員”以便“駕馭”……

例如，在一個典型的 AI 計算平臺中，可能同時存在多種硬件：用于通用任務的 CPU、用于深度學習的 GPU、用于矩陣運算的 TPU 以及用于視頻編解碼的 ASIC 芯片，同時，還有可能一些用于低功耗推理的 NPU。

上述算力資源在架構層面完全不同，在編程接口上各自為政。系統如何讓這些算力協同起來?如何讓每個任務在最合適的硬件上執行?這正是“異構算力調度”的核心問題。

而“高效”二字，更意味著：在性能、能耗、成本、任務時延、資源利用率之間取得動態平衡。這不是簡單的任務分配，而是一場系統級的平衡藝術。

二、架構范式本質：從“資源池化”到“算力編排”

從架構視角看，異構算力調度的挑戰首先來自于資源的非對稱性。即宏觀架構挑戰：異構性帶來的復雜資源管理

1. 資源描述與抽象的異構鴻溝

眾所周知，不同的異構設備擁有完全不同的計算模型、內存結構、I/O 特性和編程接口。傳統的資源抽象(如 CPU 核數、內存大小)難以適用。因此，異構算力調度難的第一層原因，是底層硬件生態的割裂。

在當下的計算環境中，幾乎每一種硬件都綁定著獨立的編程模型與驅動體系，具體可參考如下：

• NVIDIA GPU 之 CUDA;
• AMD GPU 之 ROCm;
• 華為昇騰 NPU 之 CANN;
• 寒武紀 MLU 之 Cambricon SDK;
• FPGA 之 Vitis 以及 OpenCL 等編譯框架。

調度系統如果要統一管理這些設備，就必須理解這些底層棧的運行機制。而問題在于，這些體系幾乎沒有統一標準。

例如，在一個混合訓練集群中，調度器需要判斷：某個深度學習任務是否能在 NVIDIA GPU 與華為 NPU 之間遷移?遷移的代價是多少?顯存不兼容如何處理?

然而問題是：目前幾乎所有開源系統(包括 Kubernetes、Slurm、Ray)都無法直接回答這個問題。這就像一家公司擁有來自世界各地的工程師，每個人只講自己的母語，沒有統一的技術文檔。管理難度可想而知。

我們以某 AI 公司云平臺中的調度場景為例，此公司自研 AI 云平臺，底層同時部署了 NVIDIA GPU、昇騰 NPU、FPGA 加速卡。由于驅動棧不同，調度器無法統一識別硬件狀態，導致部分任務只能“手工綁定”節點。即便硬件空閑，任務也可能等待數小時，集群利用率長期低于40%。

2. 動態負載與工作負載的算法實現難題

調度器本身的“智力”仍停留在靜態規則時代。異構設備適用于特定的工作負載。將錯誤的工作負載調度到錯誤的設備上，會導致資源浪費和低效。

目前主流的調度系統(如 Kubernetes Scheduler 或 Slurm)大多基于預定義規則：資源匹配、優先級、親和性、反親和性等。這些規則在同構環境下尚可奏效，但在異構場景中卻顯得笨拙。

例如，一個 AI 訓練任務可能包含兩階段：數據預處理(CPU密集)與模型訓練(GPU密集)。若調度器只看到資源維度，而忽略任務階段特征，就可能把整個任務綁定在 GPU 節點上，導致 CPU 空轉、GPU 等待。

更復雜的場景便是混合工作負載，即同一集群中同時存在批處理任務、在線推理、圖像渲染等業務。每類業務對時延、能耗、帶寬的敏感度不同，調度器若無法動態調整策略，就會導致整體性能下降。

我們以視頻云平臺的“資源擠兌”問題為例，在多任務并發渲染時，調度系統采用靜態分配策略，優先分配 GPU 給大型任務。結果導致短時任務排隊過長、延遲飆升。后來引入基于強化學習的動態調度模型，通過實時監測任務執行特征，自動調整優先級，整體 GPU 利用率提升 25%，任務平均完成時間下降 30%。

3. 虛擬化與共享的復雜性

為了提高利用率，有的時候，我們需要基于特定的業務訴求進行必須支持多租戶共享異構資源，但問題是：異構設備的虛擬化難度遠高于CPU。

針對 GPU 虛擬化：

• 全虛擬化(vGPU)： 性能開銷大，但隔離性好;
• 而直通(Pass-through)模式： 性能好，但無法共享;
• 而細粒度共享(MIG/SR-IOV)技術： 則提高了共享粒度，但增加了調度器對物理資源的細致管理難度。

例如，在 Kubernetes 集群中，如何確保一個算力 Pod 只使用分配給它的 GPU 顯存和計算資源，而不影響同一物理 GPU 上的其他 Pod ?這要求調度器不僅與 Kubelet 交互，還需要與底層的設備驅動和 Runtime(如 NVIDIA Container Toolkit)深度集成，實施顯存超賣管理和計算搶占/隔離策略。

4. 軟硬件協同的接口鴻溝

異構算力調度不僅是軟件問題，更是軟硬件協同的系統工程。目前調度層與硬件驅動層之間缺乏統一接口。調度器雖然知道“某節點有 4 塊 GPU ”，但并不了解這些 GPU 的運行溫度、顯存占用、PCIe 帶寬或是否啟用 MIG 分區。

這種信息鴻溝使得調度決策無法做到細粒度。例如，在大模型推理中，顯存是關鍵瓶頸。如果調度器不了解每張 GPU 的顯存可用量，就可能將任務調度到“顯存不足”的設備上，導致任務頻繁失敗或被迫回退。

例如，以 AI 推理集群中的顯存爭奪案例為例，在一家 AI SaaS 企業中，多個模型共享同一 GPU 池。

由于調度器只能基于“ GPU 個數”調度，無法識別顯存分配狀態，經常出現顯存沖突。后來通過引入基于 MIG(Multi-Instance GPU)的細粒度虛擬化機制，并在調度層增加顯存感知邏輯，任務失敗率下降 90%。

5. 資源利用率與能效的平衡

算力調度不僅追求“任務跑得快”，更要在性能與能耗之間取得平衡。

在大規模 AI 集群中，GPU 常常成為能耗主力。以一個擁有 1000 塊 A100 的集群為例，峰值功耗可達 1.5 MW，單日電費超過10萬元。如果調度策略無法合理分配任務，導致 GPU 長期低負載運行，這不僅浪費資源，更直接增加運營成本。

在企業實踐中，越來越多的架構師開始關注“能效比”指標，即每瓦特算力所能完成的任務量。

以智慧城市推理節點的能效調度場景為例，在某城市級AI監控系統，邊緣節點部署了 NPU 與 GPU 混合架構。

傳統策略按固定比例分配任務，結果在夜間監控量下降時，GPU 仍保持高功耗待機。后續改造后，系統能根據負載自動將任務遷移到低功耗 NPU，GPU 進入休眠模式，整體能耗降低近 40%。

三、異構算力調度的本質與未來方向

當前，異構算力調度已超越傳統的資源分配邏輯，演進為一個復雜的系統級價值優化問題。其核心挑戰在于，如何在高度異質化、分布化的物理硬件之上，構建一個能感知業務意圖、并能動態協調時空拓撲的智能調度層。這要求我們從底層架構范式、跨域協同機制與行業生態標準三個維度進行根本性重構，以將原始的“算力”高效地轉化為“生產力”。

1. 架構內核：從均質分時到異構意圖的調度范式遷移

傳統 CPU 調度建立在“資源同構”與“進程對等”的假設之上，其核心是通過時間分片在均質資源上模擬公平性。而在異構架構中，這一范式徹底失效。調度器的核心職責不再是公平地分配“時間”，而是精準地匹配“計算意圖與硬件能力在時空維度上的拓撲關系”。

調度目標出現根本性轉變，從追求單一線程的低延遲，轉向最大化整個異構集群在單位時間內的任務吞吐量 或價值完成度。一個任務的價值，取決于其所需的各種異構資源(如 GPU、DPU、FPGA)能否被高效、協同地供給。

2. 架構演進：解耦、卸載與聯邦調度構成的下一代算力平面

為應對上述挑戰，基礎設施架構正沿著“解耦”與“聯邦”兩個方向演進，這直接重塑了調度器的設計邊界。具體體現在如下2點：

(1) 深度解耦與智能卸載：DPU/IPU的興起，標志著控制平面與數據平面的物理分離。網絡、存儲與安全功能被從主機CPU卸載，形成了獨立的“基礎設施域”。這使得調度決策必須從單一的“計算負載”視角，升級為計算、I/O與存儲的協同視角。

(2) 聯邦調度：構建邏輯統一的跨域算力池：邊緣、數據中心與混合云構成了物理上分散的“算力孤島”。聯邦調度器的架構價值在于，在物理分散的前提下，抽象出一個邏輯統一的全局資源視圖。它不直接管理底層所有資源，而是通過一套標準協議進行跨域協商與委托調度。

3. 架構基石：通過標準化接口構建可持續演進的生態

長期來看，解決異構復雜度必須通過標準化來降低系統熵增。這關乎整個軟硬件生態的構建。具體體現在如下：

(1) 硬件抽象層標準化：OAM等硬件標準試圖在物理形態、供電散熱與高速互連上形成規范，為不同廠商的加速器建立“可互換”的物理基礎。這是硬件層面的“解耦”。

(2) 軟件接口統一化：在軟件層面，需要將CRI/OCI等容器運行時接口向異構設備擴展，實現加速器資源的聲明式發現與分配。這要求設備插件模型從簡單的“數量上報”進化到能描述設備能力、拓撲關系與健康狀態的“資源畫像”。

(3) 生態集成深度：最終，所有標準與接口的價值，體現在與主流調度框架(如Kubernetes)的深度融合上。通過開發更高級的運算符或自定義資源，將異構資源的調度邏輯從“應用如何適配基礎設施”的反模式，轉變為“基礎設施如何滿足應用意圖”的正交模式，從而實現架構的長期可演進性。

因此，綜上所述，高效的異構算力調度是計算架構演進中的一個關鍵里程碑，要求我們從簡單的資源計數轉向復雜的拓撲、通信和工作負載匹配。這不僅僅是一個算法優化問題，更是一個需要系統性變革的架構設計問題。

未來的調度系統應該具備如下特性：

• 拓撲感知的： 能夠理解并利用硬件互聯優勢。
• 智能化/預測性的： 能夠利用數據預測負載并做出前瞻性決策。
• 分層解耦的： 實現資源管理與業務邏輯的清晰分離
• 可編程的： 允許用戶和管理員定義靈活的調度策略。

只有構建出這樣的新一代調度架構，才能真正釋放異構算力的巨大潛能，支撐起未來 AI 和大規模計算的需求。

今天的解析就到這里，欲了解更多關于 “大模型技術”相關技術的深入剖析，最佳實踐以及相關技術前沿，敬請關注我們的微信公眾號或視頻號：架構驛站(ArchHub)，獲取更多獨家技術洞察!

Happy Coding ~

Reference ：

[1] https://developer.nvidia.com/

[2] Dynamic GPU Fractions(動態 GPU 分配)，知多少?

Adiós !