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

在后摩爾時代與AI爆發(fā)的雙重驅(qū)動下，計算架構正經(jīng)歷一場從同構到異構的深刻變革。

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

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

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

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

算力的調(diào)度效率已經(jīng)成為系統(tǒng)整體性能的瓶頸。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. 動態(tài)負載與工作負載的算法實現(xiàn)難題

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

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

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

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

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

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

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

針對 GPU 虛擬化：

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

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

4. 軟硬件協(xié)同的接口鴻溝

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

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

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

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

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

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

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

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

以智慧城市推理節(jié)點的能效調(diào)度場景為例，在某城市級AI監(jiān)控系統(tǒng)，邊緣節(jié)點部署了 NPU 與 GPU 混合架構。

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

三、異構算力調(diào)度的本質(zhì)與未來方向

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

1. 架構內(nèi)核：從均質(zhì)分時到異構意圖的調(diào)度范式遷移

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

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

2. 架構演進：解耦、卸載與聯(lián)邦調(diào)度構成的下一代算力平面

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

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

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

3. 架構基石：通過標準化接口構建可持續(xù)演進的生態(tài)

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

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

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

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

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

未來的調(diào)度系統(tǒng)應該具備如下特性：

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

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

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

Happy Coding ~

Reference ：

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

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

Adiós !