1. 這次調(diào)研的起點AI-RAN和O社的ATR項目最近一直在追AI-RAN方向的資料我把它當(dāng)作接下來幾年移動通信最有變量的一塊來研究。整理到后面O社的ATR項目成了繞不開的樣本公開材料反復(fù)出現(xiàn)幾個標(biāo)簽基于ARM架構(gòu)的GPU平臺、同時覆蓋集中式和分布式AI-RAN、面向5G-A和6G演進。這幾點放在一起就是一次完整的架構(gòu)換代不是某個基站部件的小修小補。AI-RAN全稱是AI-Radio Access Network字面意思是“人工智能無線接入網(wǎng)”。但這個詞在行業(yè)里其實有三層理解容易混。第一層是AI for RAN用AI做信道估計、波束管理、網(wǎng)絡(luò)節(jié)能相當(dāng)于給無線算法加了一個“智能調(diào)度大腦”第二層是AI on RAN把基站機器變成邊緣AI算力節(jié)點讓原本閑置的資源對外輸出推理能力第三層是AI and RAN強調(diào)AI和無線通信真正共享底層計算資源。ATR項目做的最關(guān)鍵事情就在第三層讓5G基帶處理和AI推理跑在同一塊GPU上用一個硬件平臺同時承擔(dān)通信和算力兩種角色。換句話說傳統(tǒng)基站的基帶處理是交給專用芯片的ASIC、FPGA、DSP好用是好用但只能做無線這一件事。AI服務(wù)器又是另外一臺設(shè)備GPU常年開著利用率卻經(jīng)常不到百分之二十。AI-RAN想改變的是這種浪費。它把無線接入的功能“軟”下來跑在通用GPU上閑時算力再給AI任務(wù)用?；緩耐ㄐ旁O(shè)備變成了“能通信的計算節(jié)點”這是整個產(chǎn)業(yè)邏輯變化的核心。ATR項目為什么值得單獨拎出來看主要因為兩點。第一這是運營商自己下場做RAN軟件棧而不是買設(shè)備商的整機O社動的其實不是射頻還是天線而是把基帶處理整個搬到GPU上重新做一遍第二它同時定義了集中式和分布式兩種部署方式不是實驗室里演示一把就完而是給了實際組網(wǎng)的路線圖。這次調(diào)研我主要就是圍繞這兩點展開的。1.1 一個通俗的比喻把AI-RAN說清楚基站流量是典型的潮汐曲線白天寫字樓區(qū)域流量拉滿凌晨基本空閑。傳統(tǒng)方案里BBU設(shè)備不管有沒有流量整塊電路板都在通電待命就像一家餐廳固定開著一個大廚房但一天只有兩個飯點有人來吃飯。AI-RAN的思路是把廚房變成可以外接訂單的中央廚房。人少的時候廚師們做外賣、做其他餐食把設(shè)備和場地利用起來。到了飯點信號處理任務(wù)優(yōu)先級最高所有算力立刻切給業(yè)務(wù)。同一個廚房不同時間做不同的事。CPU、GPU這類通用計算資源天然適合這種“彈性分工”而專用芯片做不到ASIC的邏輯在出廠時就焊死了。這個比喻還能往下走一層。集中式AI-RAN相當(dāng)于把幾個餐廳的廚房合并到一個中央廚房統(tǒng)一采購、統(tǒng)一排班效率更高但距離遠了菜送過去路上一慢會涼分布式AI-RAN相當(dāng)于每家店保留一個中廚單店響應(yīng)快但每家店的設(shè)備使用率不如中央廚房。這兩種模式?jīng)]有絕對的優(yōu)劣要看現(xiàn)場條件。1.2 AI-RAN要解決的不只是成本問題很多人以為運營商做AI-RAN就是為了省電、省設(shè)備其實這只是最表層。另一個更深的原因是現(xiàn)網(wǎng)設(shè)備的軟件化比例太低。傳統(tǒng)基站里協(xié)議棧大部分跑在封閉環(huán)境里想新增一個AI優(yōu)化功能需要依賴設(shè)備商升級版本周期非常長。O社這種體量的運營商既有用戶規(guī)模優(yōu)勢又有AI研發(fā)能力自然想打破這個閉環(huán)。把RAN跑在GPU上以后很多以前不敢想的場景就通了?；颈旧砭褪且粋€帶AI能力的推理節(jié)點可以本地做視頻結(jié)構(gòu)化分析、工業(yè)設(shè)備異常監(jiān)測、自動駕駛的低時延協(xié)同。以前這些東西需要單獨在邊緣機房部署AI服務(wù)器再把結(jié)果通過網(wǎng)絡(luò)送到用戶一來一回時延至少幾十毫秒?，F(xiàn)在基站的GPU直接把AI服務(wù)開在離用戶最近的地方時延壓到個位數(shù)毫秒這是5G-A和6G場景里非常重要的一張牌。ATR項目選的硬件路線也很有意思它沒有走傳統(tǒng)設(shè)備商最熟悉的x86 CPU加FPGA加速卡路線而是直接用ARM CPU和GPU融合的平臺。這個選擇背后是好幾筆賬我在下一節(jié)詳細算。2. 硬件底座為什么是ARM架構(gòu)GPU平臺2.1 三種硬件方案的對比我在調(diào)研中把當(dāng)前RAN加速方案分成了三類放在一起做對比這樣才能看清ARM加GPU這套組合的位置。第一類是傳統(tǒng)ASIC/FPGA方案。典型場景是現(xiàn)網(wǎng)中大量早期5G基站基帶L1層走專用芯片性能和功耗都很好但問題也很明顯開發(fā)周期長迭代一次物理層算法要按年來算AI能力基本為零除非額外掛一臺AI服務(wù)器否則這塊加速卡無法承接任何AI業(yè)務(wù)運維上也是黑盒出了問題只能交給設(shè)備商定位。第二類是x86 CPU加FPGA加速卡的方案。這也是不少廠商在5G中后期采用的路線。FPGA做L1高性能流程x86跑協(xié)議?？刂泼姹華SIC靈活但AI生態(tài)仍然弱。FPGA上部署深度學(xué)習(xí)模型需要專門做量化、編譯和布線人力成本極高沒法像NVIDIA那樣用CUDA生態(tài)快速落地。更重要的問題是x86本身功耗高基站站點通常只給幾千瓦的電力預(yù)算一臺x86服務(wù)器放上去電源、散熱、機房空間都要重新設(shè)計。第三類就是ARM加GPU。ARM CPU負責(zé)協(xié)議?？刂坪屯ㄓ糜嬎鉍PU承擔(dān)L1物理層同時也作為AI推理引擎。GPU的好處是同一塊硬件天然能跑AI生態(tài)極其完整從訓(xùn)練框架到推理引擎全都現(xiàn)成。ARM CPU的好處是功耗低單核能效遠好于x86而且ARM在電信設(shè)備里其實是老熟人很多基站的控制面早就在用ARM核兼容性不是問題。三類方案的關(guān)鍵差異我用一張簡表列出來后面講參數(shù)方便一點。維度ASIC/FPGAx86 FPGAARM GPU基帶處理性能高中高中高AI負載承接差差好開發(fā)迭代速度慢中快功耗低高中資源池化能力弱中強生態(tài)基礎(chǔ)封閉封閉開放2.2 ARM和GPU之間那根“高速管道”是關(guān)鍵很多沒做過RAN的人第一次看ARM加GPU方案會有一個疑問ARM CPU和GPU是兩個東西數(shù)據(jù)在這兩者之間來回搬運會不會成為瓶頸這里就涉及平臺本身的設(shè)計。ATR方案里選的是某GPU廠商的服務(wù)器級加速平臺它把ARM CPU和GPU做成了緊密耦合的一顆大芯片CPU與GPU之間不是走傳統(tǒng)的PCIe總線而是通過高帶寬的一致性互聯(lián)通道直接相連。PCIe的典型雙向帶寬在數(shù)十GB每秒這個平臺的一致性互聯(lián)在規(guī)格上高出一個量級。更重要的是它支持緩存一致性CPU和GPU訪問內(nèi)存時不需要頻繁做數(shù)據(jù)拷貝和驅(qū)動同步這對毫秒級信號處理尤其關(guān)鍵?；鶐幚淼谋举|(zhì)是實時數(shù)據(jù)流天線端收到信號經(jīng)過前傳接口進入GPU做FFT變換、信道估計、解調(diào)再交回ARM CPU做協(xié)議處理。整個過程要在幾毫秒內(nèi)完成任何一個環(huán)節(jié)出現(xiàn)DMA拷貝延遲和數(shù)據(jù)等待都可能拖壞空口指標(biāo)。ARM和GPU融合成一顆芯片后數(shù)據(jù)路徑短延遲可控這是它和“x86服務(wù)器插一塊GPU卡”最大的區(qū)別。很多公開技術(shù)資料里還提到了配套的DPU網(wǎng)卡。這塊卡在AI-RAN里的作用很多人忽略了其實非常關(guān)鍵?；厩皞鹘涌诔休d的是樣本數(shù)據(jù)需要高精度的時間同步傳統(tǒng)方案里靠BBU里的獨立時鐘模塊解決但在GPU平臺里這個功能被卸載到DPU上由DPU完成eCPRI協(xié)議解析、時間戳打標(biāo)、同步和流量整形。DPU還順帶承擔(dān)了網(wǎng)絡(luò)虛擬化的負載把容器間通信、OVS轉(zhuǎn)發(fā)這些開銷從CPU上解放出來。2.3 功耗與實時性這筆賬RAN工作負載和普通AI推理有一個本質(zhì)區(qū)別無線信號處理是有硬性實時要求的符號級任務(wù)必須在微秒級時間窗口內(nèi)完成過了這個窗口物理層的幀結(jié)構(gòu)就錯了用戶直接掉線。GPU本身就是為吞吐量設(shè)計的一個任務(wù)排隊等幾百微秒很正常所以直接在GPU上跑L1基帶會出問題必須有軟件棧做實時調(diào)度。O社的ATR方案里軟件層面的玩法是把L1處理切成兩類任務(wù)。一類是高優(yōu)先級實時任務(wù)例如每個時隙內(nèi)的核心符號處理用GPU的專用硬件隊列來做嚴格鎖定執(zhí)行窗口另一類是低優(yōu)先級非實時任務(wù)怎么做都行后臺慢慢跑比如測量上報、日志分析。AI推理任務(wù)則被放在最低優(yōu)先級只能占用RAN任務(wù)不用的計算資源。功耗賬更要細算。服務(wù)器級GPU芯片功耗不低一塊卡就要幾百瓦到上千瓦放在中頻基站站址常常超過機房的單機柜供電上限。所以ATR項目在分布式部署場景里直接推出了低功耗版本的設(shè)計GPU的時鐘頻率被鎖定到較低檔位同時采用外置散熱整機整機功耗控制在1千瓦以內(nèi)。這個數(shù)字放到傳統(tǒng)基站里依然偏高但已經(jīng)逼近機柜能接受的范圍了。集中式部署則可以把功耗壓力轉(zhuǎn)移到邊緣機房用液冷解決這也是集中式架構(gòu)在實踐中更好落地的原因之一。2.4 為什么這套平臺適合做“運營商級”AI-RAN我個人的判斷是ARM加GPU這個組合技術(shù)上有取舍但商業(yè)上很聰明。GPU的AI生態(tài)是現(xiàn)成的不用重新推動產(chǎn)業(yè)ARM的授權(quán)生態(tài)又是開放的運營商可以自己選處理器、選網(wǎng)卡、選服務(wù)器不用被單一設(shè)備商綁定。O社這樣做等于把原本封閉的RAN產(chǎn)業(yè)從“賣整機”變成了“組裝機”。代價是系統(tǒng)集成難度極高。傳統(tǒng)設(shè)備商交付的基站是經(jīng)過整體測試的整機運營商插上電就能用現(xiàn)在ARM服務(wù)器、GPU卡、DPU、前傳光模塊、實時操作系統(tǒng)、容器平臺都要自己拼運維團隊的要求一下子被拉高了。這也是ATR方案目前更多停留在大型項目合作和PoC驗證階段的原因真正大面積替換現(xiàn)網(wǎng)基站還有一段距離。3. 兩種架構(gòu)形態(tài)集中式與分布式怎么用3.1 集中式AI-RANGPU資源池化的優(yōu)勢集中式架構(gòu)可以理解成把多個基站的基帶處理集中到邊緣機房機房里的GPU服務(wù)器組成一個資源池通過前傳網(wǎng)絡(luò)連接分布在遠處的射頻單元。這個概念本質(zhì)上脫胎于C-RAN也就是云化無線接入網(wǎng)但ATR方案里的核心變化是資源池不僅能做基帶還能同時跑AI。集中式的第一個好處是資源利用率高。十個基站放在一起負載高峰時間各不相同如果每個基站各自配備一塊GPU必然出現(xiàn)有的滿負荷有的閑置。集中后十個小區(qū)的算力可以共享同一批卡按業(yè)務(wù)量動態(tài)調(diào)度總卡數(shù)能省下三成以上。第二個好處是便于升級GPU卡可以集中替換不用爬鐵塔、進站點一臺一臺換。第三個好處是AI服務(wù)更容易規(guī)?；渴饳C房里的GPU資源池直接統(tǒng)一調(diào)度一個模型可以在池子里隨意分配任何一個基站覆蓋區(qū)域的用戶都能就近獲得AI推理能力不用在每個站點重復(fù)部署。需要特別注意前傳網(wǎng)絡(luò)。集中式把基帶處理拉到遠處后射頻單元和基帶單元之間的前傳時延必須嚴格受控尤其是L1處理對時延極敏感一般要求單跳傳輸時延在微秒級所以集中式機房通常距離遠端站點幾十公里以內(nèi)并且需要高質(zhì)量的光模塊和精確時間同步協(xié)議。前傳帶寬同樣需要預(yù)留信道光模塊速率不夠或者抖動過大空口指標(biāo)立刻劣化。3.2 分布式AI-RAN把算力直接推到站點分布式架構(gòu)則是另一幅圖景每個基站站點部署一套一體化的ARM加GPU設(shè)備整臺設(shè)備直接掛在接入機房甚至塔上基帶處理和AI推理都在本地完成。這種形態(tài)解決集中式最頭疼的兩個問題前傳時延超高標(biāo)準(zhǔn)和高帶寬依賴。分布式方案在低時延場景里有天然優(yōu)勢。以工業(yè)場景為例機器人的運動控制周期一般在幾毫秒如果控制決策要發(fā)回中心機房一來一回再考慮網(wǎng)絡(luò)排隊很難穩(wěn)定達標(biāo)。站點內(nèi)嵌GPU之后推理計算本地完成時延基本就一次DMA的距離穩(wěn)定在極低水平。這個優(yōu)勢適合真正硬實時的工業(yè)互聯(lián)網(wǎng)場景是集中式替代不了的。代價也很明顯分布式站點的環(huán)境比中心機房惡劣得多冬天沒有暖氣夏天沒有空調(diào)白天暴曬灰塵和潮氣無孔不入。GPU這類高功耗設(shè)備放在這種環(huán)境里對退熱設(shè)計、防塵過濾、供電保障都是大考驗。另一個問題是算力浪費站點流量有高峰有低谷低谷時GPU完全空閑但不像集中式還可以把資源給別的小區(qū)用只能白白閑著。所以分布式架構(gòu)更適合那些本地AI業(yè)務(wù)占用本身就比較穩(wěn)定的場景比如智慧園區(qū)、港口、礦山AI負載能和通信負載錯峰互補。3.3 同一套軟件棧如何覆蓋兩種模式ATR項目規(guī)劃里最有價值的部分不是單獨支持集中式或分布式而是用一個軟件架構(gòu)同時覆蓋了兩種模式。這意味著運營商不需要在兩種方案之間做非此即彼的選擇而可以根據(jù)地域、業(yè)務(wù)類型、機房條件靈活組合比如城區(qū)寫字樓區(qū)域用集中式郊區(qū)工廠用分布式。要做到這點關(guān)鍵在于把RAN功能拆分成可編排的原子能力。L1物理層處理、L2協(xié)議處理、L3控制面這些功能模塊全部做成可獨立部署的軟件容器。部署集中式時這些容器都跑在中心機房的GPU服務(wù)器上部署分布式時本地站點跑L1和一部分L2L3等高時延容忍的功能仍可送回中心機房。資源調(diào)度的策略也完全復(fù)用。無論集中還是分布底層都有一位GPU資源調(diào)度器負責(zé)給不同任務(wù)分配計算資源RAN任務(wù)擁有最高優(yōu)先級AI任務(wù)使用空閑窗口。這套調(diào)度邏輯和部署方式無關(guān)集中式調(diào)度的是一大池子分布式調(diào)度的是一小池子策略相同顆粒度不同。這就是軟硬件解耦設(shè)計帶來的最大收益一套軟件、兩種形態(tài)、多處復(fù)用。4. 從紙面到落地部署步驟與算力測算4.1 算力測算一個節(jié)點需要幾塊GPU調(diào)研要從紙面落到實操第一步就是算算到底需要多少GPU資源。這個數(shù)字不能拍腦袋要按小區(qū)配置、帶寬、天線數(shù)量、業(yè)務(wù)模型逐步推。以一個典型中頻宏站小區(qū)為例100兆赫茲帶寬、4T4R天線配置、TDD制式下行小區(qū)峰值吞吐量約在1.5Gbps左右L1物理層處理需要完成FFT變換、信道估計、均衡、編解碼等操作每毫秒處理一個時隙的數(shù)據(jù)。按該GPU廠商公開演示的性能單個加速卡大概可以支撐3至4個這樣配置小區(qū)的L1處理再疊加一部分L2處理實際能力會降到2至3個還要為突發(fā)流量保留余量。如果集中式機房里規(guī)劃接入10個小區(qū)就需要4塊以上加速卡。這里有個常見的誤算直接把10除以3向上取整成4張卡但實際還要考慮L2開銷、AI業(yè)務(wù)預(yù)留和故障冗余更穩(wěn)妥的是按“每小區(qū)占用0.35卡”計算再預(yù)留20%算力峰值緩沖和一塊卡的N加1備份最終結(jié)果是6塊卡左右。算力規(guī)劃寧多勿少因為無線RAN任務(wù)一旦超載不是變慢的問題是直接掉線。AI業(yè)務(wù)的資源預(yù)留可以單獨計數(shù)。如果機房里還要運行30路視頻分析每路按一個輕量模型推理需要大約一定比例的GPU實例算就得增加對應(yīng)數(shù)量的卡。RAN和AI需求放在同一個資源池里調(diào)度器在保證RAN不超閾值的前提下把剩余算力盡量分配給AIAI資源總量應(yīng)該在峰值算力基礎(chǔ)上再打個折扣。4.2 一套可復(fù)制的PoC部署流程我建議第一次做AI-RAN項目驗證的團隊按下面的順序走這樣可以盡可能規(guī)避翻車。先定拓撲和場景。明確是要驗證集中式還是分布式或者混合式。建議第一次做集中式機房條件可控問題排查也方便。然后做資源估算參考上一小節(jié)的方法把基站數(shù)、小區(qū)帶寬、天線端口、預(yù)計AI業(yè)務(wù)類型和路數(shù)全部列出來算出GPU卡數(shù)。這一步一定要多算一點富余量軟件層的損耗會在壓力測試里暴露出來。再準(zhǔn)備硬件環(huán)境。ARM加GPU的服務(wù)器網(wǎng)卡交換機前傳光模塊時鐘同步設(shè)備逐一上架。時鐘同步這一步經(jīng)常被忽視AI-RAN機房里基站前傳和普通數(shù)據(jù)中心不太一樣必須要走精確時間同步協(xié)議否則空口幀對齊不了。軟件層則是部署容器平臺、實時操作系統(tǒng)的配置、基帶加速棧和AI推理框架。然后是單站驗證先不在多站并發(fā)場景下跑只接一個射頻拉遠單元驗證一塊GPU跑L1處理看空口能不能穩(wěn)定建立連接吞吐量能不能達到理論值的八成以上。最后壓力測試逐步增加小區(qū)數(shù)同時混入AI推理任務(wù)觀察GPU利用率、時延和空口性能的變化曲線找到資源峰值邊界。這一步做完才算從“能用”到了“夠用”。4.3 資源切分和SLA保障策略AI-RAN系統(tǒng)里最重要的一條原則是RAN任務(wù)必須有絕對優(yōu)先權(quán)。這不是靠程序員自覺而是靠底層調(diào)度機制硬保證的。具體實現(xiàn)上GPU實例切片的使用方式值得借鑒。一塊物理GPU可按算力比例切分成多個實例每個實例擁有獨立計算單元和顯存互相之間隔離?？梢越oRAN任務(wù)分配一個獨占實例這個實例不參與AI推理專職保證基帶處理的實時性。AI任務(wù)跑在另一個實例上哪怕它把實例占滿也不會對RAN造成直接沖擊最多是等資源時間變長。在實例內(nèi)部還可以加時間片隔離。實時無線任務(wù)長期占著隊列的一部分固定窗口AI任務(wù)只能在剩余窗口里運行。這有點像高速公路上給應(yīng)急車輛留出專用通道日常行駛非常自由但應(yīng)急車輛一來其他車必須立刻讓行。5. 實測中遇到的問題和幾套排查思路5.1 實時任務(wù)在GPU上“跑飛”的處理第一次跑L1處理時最常見的問題是GPU任務(wù)時延抖動。傳統(tǒng)基站的基帶處理跑在專用芯片上時間行為幾乎是確定的而GPU的任務(wù)調(diào)度天然帶著不確定性。實測時最容易看到的現(xiàn)象是某個時隙的符號處理偶爾超時超時不超過幾十微秒但對空口來說已經(jīng)構(gòu)成一次小中斷。我要特別提醒不要一上來就優(yōu)化代碼先開GPU實時調(diào)度日志把超時分布抓出來看。大多數(shù)情況下問題不在算法而在任務(wù)排隊。GPU上有多個計算隊列如果RAN任務(wù)和AI任務(wù)默認使用同一個計算流AI的密集型計算會把RAN任務(wù)擠到隊尾。解決思路很直接把RAN任務(wù)分配到獨立的高優(yōu)先級計算流并配合固定時間片搶占機制同時把AI任務(wù)壓成低優(yōu)先級的后臺流。這屬于平臺級配置不需要改一行算法代碼。如果配置完成后仍然抖動下一步檢查顯存分配。GPU實例之間如果共享顯存帶寬大量的顯存拷貝會拖慢RAN處理。給RAN實例預(yù)留足夠多的顯存駐留空間盡量避免運行時頻繁申請能顯著改善時延穩(wěn)定性。5.2 前傳鏈路和資源沖突問題速查前傳鏈路是集中式架構(gòu)最容易出問題的地方。我整理了一份實測中最常踩坑的問題清單給正在做同類項目的團隊參考。問題現(xiàn)象定位思路解決辦法前傳光模塊誤碼率升高空口吞吐下降檢查光模塊速率和鏈路預(yù)算看是否在長距離場景用錯模塊等級換成更高等級光模塊縮短前傳距離空口幀偏移不穩(wěn)定檢查同步源是否所有射頻單元都同步到同一時鐘統(tǒng)一同步協(xié)議配置增加時鐘源冗余GPU利用率不滿但空口指標(biāo)差檢查CPU和GPU之間數(shù)據(jù)搬運路徑是否走了低速接口確認使用高帶寬一致性互聯(lián)通道關(guān)閉不必要的數(shù)據(jù)拷貝AI推理啟動后RAN時延升高查看GPU任務(wù)隊列是否使用了同一計算流將RAN任務(wù)固化到獨立計算流并設(shè)為最高優(yōu)先級站點功耗超限導(dǎo)致掉電查看整機功耗曲線是否GPU長期滿載設(shè)置功耗上限AI任務(wù)降頻必要時鎖GPU工作頻率最容易被忽略的一個問題是AI模型預(yù)熱帶來的瞬時CPU和顯存沖擊。很多AI框架在推理服務(wù)冷啟動時要加載模型會有一段很明顯的資源峰值如果剛好趕上RAN的忙時就可能引發(fā)資源爭搶。我建議在系統(tǒng)里做AI服務(wù)的資源配額限制并把模型加載放在RAN任務(wù)低峰期執(zhí)行AI容器啟動后先空載運行一段時間再接入實際業(yè)務(wù)流量。5.3 一小段真實調(diào)試經(jīng)歷供你參考我印象最深的一次調(diào)試是分布式站點GPU溫度過高導(dǎo)致頻率降到非常低整個系統(tǒng)的空口吞吐直接掉了三成。一開始還懷疑是前傳問題排查了半天才發(fā)現(xiàn)是散熱系統(tǒng)沒有適配好。GPU在降頻保護狀態(tài)下不會報錯只會在日志里提示功耗和溫度限制但現(xiàn)網(wǎng)運維如果不關(guān)注這部分日志根本發(fā)現(xiàn)不了。那個教訓(xùn)讓我養(yǎng)成了一個習(xí)慣在AI-RAN環(huán)境里做任何性能排查第一件事不是看空口指標(biāo)而是看GPU的實時狀態(tài)包括溫度、功耗、算力利用率、顯存占用、計算流隊列深度。這五個指標(biāo)先看完再判斷是不是無線側(cè)的問題。傳統(tǒng)無線工程師做RAN排查時只看空口AI工程師做系統(tǒng)性能時只看GPU利用率這個項目最考人的恰恰是兩邊對齊。我個人的體會是AI-RAN這個方向的工程難點不在“GPU跑得動跑不動基帶”而在“當(dāng)一個系統(tǒng)里同時存在實時通信和彈性AI兩類任務(wù)時怎么讓它們互相不拖累”。ARM加GPU的硬件平臺提供了一個足夠開放的底座但真正決定項目能不能落地的還是軟件調(diào)度、資源隔離、運營維護這些細節(jié)。從現(xiàn)網(wǎng)角度看ATR項目目前最有參考價值的也不是那塊GPU卡而是它能不能把這套調(diào)度邏輯做成可復(fù)用的行業(yè)標(biāo)準(zhǔn)。這個方向后續(xù)值得持續(xù)跟蹤尤其是從5G-A走向6G以后基站架構(gòu)的軟件化程度會越來越高今天的ARM加GPU方案很可能就是未來整個接入網(wǎng)的主流底座。