1. 这次调研的起点AI-RAN和O社的ATR项目最近一直在追AI-RAN方向的资料我把它当作接下来几年移动通信最有变量的一块来研究。整理到后面O社的ATR项目成了绕不开的样本公开材料反复出现几个标签基于ARM架构的GPU平台、同时覆盖集中式和分布式AI-RAN、面向5G-A和6G演进。这几点放在一起就是一次完整的架构换代不是某个基站部件的小修小补。AI-RAN全称是AI-Radio Access Network字面意思是“人工智能无线接入网”。但这个词在行业里其实有三层理解容易混。第一层是AI for RAN用AI做信道估计、波束管理、网络节能相当于给无线算法加了一个“智能调度大脑”第二层是AI on RAN把基站机器变成边缘AI算力节点让原本闲置的资源对外输出推理能力第三层是AI and RAN强调AI和无线通信真正共享底层计算资源。ATR项目做的最关键事情就在第三层让5G基带处理和AI推理跑在同一块GPU上用一个硬件平台同时承担通信和算力两种角色。换句话说传统基站的基带处理是交给专用芯片的ASIC、FPGA、DSP好用是好用但只能做无线这一件事。AI服务器又是另外一台设备GPU常年开着利用率却经常不到百分之二十。AI-RAN想改变的是这种浪费。它把无线接入的功能“软”下来跑在通用GPU上闲时算力再给AI任务用。基站从通信设备变成了“能通信的计算节点”这是整个产业逻辑变化的核心。ATR项目为什么值得单独拎出来看主要因为两点。第一这是运营商自己下场做RAN软件栈而不是买设备商的整机O社动的其实不是射频还是天线而是把基带处理整个搬到GPU上重新做一遍第二它同时定义了集中式和分布式两种部署方式不是实验室里演示一把就完而是给了实际组网的路线图。这次调研我主要就是围绕这两点展开的。1.1 一个通俗的比喻把AI-RAN说清楚基站流量是典型的潮汐曲线白天写字楼区域流量拉满凌晨基本空闲。传统方案里BBU设备不管有没有流量整块电路板都在通电待命就像一家餐厅固定开着一个大厨房但一天只有两个饭点有人来吃饭。AI-RAN的思路是把厨房变成可以外接订单的中央厨房。人少的时候厨师们做外卖、做其他餐食把设备和场地利用起来。到了饭点信号处理任务优先级最高所有算力立刻切给业务。同一个厨房不同时间做不同的事。CPU、GPU这类通用计算资源天然适合这种“弹性分工”而专用芯片做不到ASIC的逻辑在出厂时就焊死了。这个比喻还能往下走一层。集中式AI-RAN相当于把几个餐厅的厨房合并到一个中央厨房统一采购、统一排班效率更高但距离远了菜送过去路上一慢会凉分布式AI-RAN相当于每家店保留一个中厨单店响应快但每家店的设备使用率不如中央厨房。这两种模式没有绝对的优劣要看现场条件。1.2 AI-RAN要解决的不只是成本问题很多人以为运营商做AI-RAN就是为了省电、省设备其实这只是最表层。另一个更深的原因是现网设备的软件化比例太低。传统基站里协议栈大部分跑在封闭环境里想新增一个AI优化功能需要依赖设备商升级版本周期非常长。O社这种体量的运营商既有用户规模优势又有AI研发能力自然想打破这个闭环。把RAN跑在GPU上以后很多以前不敢想的场景就通了。基站本身就是一个带AI能力的推理节点可以本地做视频结构化分析、工业设备异常监测、自动驾驶的低时延协同。以前这些东西需要单独在边缘机房部署AI服务器再把结果通过网络送到用户一来一回时延至少几十毫秒。现在基站的GPU直接把AI服务开在离用户最近的地方时延压到个位数毫秒这是5G-A和6G场景里非常重要的一张牌。ATR项目选的硬件路线也很有意思它没有走传统设备商最熟悉的x86 CPU加FPGA加速卡路线而是直接用ARM CPU和GPU融合的平台。这个选择背后是好几笔账我在下一节详细算。2. 硬件底座为什么是ARM架构GPU平台2.1 三种硬件方案的对比我在调研中把当前RAN加速方案分成了三类放在一起做对比这样才能看清ARM加GPU这套组合的位置。第一类是传统ASIC/FPGA方案。典型场景是现网中大量早期5G基站基带L1层走专用芯片性能和功耗都很好但问题也很明显开发周期长迭代一次物理层算法要按年来算AI能力基本为零除非额外挂一台AI服务器否则这块加速卡无法承接任何AI业务运维上也是黑盒出了问题只能交给设备商定位。第二类是x86 CPU加FPGA加速卡的方案。这也是不少厂商在5G中后期采用的路线。FPGA做L1高性能流程x86跑协议栈控制面比ASIC灵活但AI生态仍然弱。FPGA上部署深度学习模型需要专门做量化、编译和布线人力成本极高没法像NVIDIA那样用CUDA生态快速落地。更重要的问题是x86本身功耗高基站站点通常只给几千瓦的电力预算一台x86服务器放上去电源、散热、机房空间都要重新设计。第三类就是ARM加GPU。ARM CPU负责协议栈控制和通用计算GPU承担L1物理层同时也作为AI推理引擎。GPU的好处是同一块硬件天然能跑AI生态极其完整从训练框架到推理引擎全都现成。ARM CPU的好处是功耗低单核能效远好于x86而且ARM在电信设备里其实是老熟人很多基站的控制面早就在用ARM核兼容性不是问题。三类方案的关键差异我用一张简表列出来后面讲参数方便一点。维度ASIC/FPGAx86 FPGAARM GPU基带处理性能高中高中高AI负载承接差差好开发迭代速度慢中快功耗低高中资源池化能力弱中强生态基础封闭封闭开放2.2 ARM和GPU之间那根“高速管道”是关键很多没做过RAN的人第一次看ARM加GPU方案会有一个疑问ARM CPU和GPU是两个东西数据在这两者之间来回搬运会不会成为瓶颈这里就涉及平台本身的设计。ATR方案里选的是某GPU厂商的服务器级加速平台它把ARM CPU和GPU做成了紧密耦合的一颗大芯片CPU与GPU之间不是走传统的PCIe总线而是通过高带宽的一致性互联通道直接相连。PCIe的典型双向带宽在数十GB每秒这个平台的一致性互联在规格上高出一个量级。更重要的是它支持缓存一致性CPU和GPU访问内存时不需要频繁做数据拷贝和驱动同步这对毫秒级信号处理尤其关键。基带处理的本质是实时数据流天线端收到信号经过前传接口进入GPU做FFT变换、信道估计、解调再交回ARM CPU做协议处理。整个过程要在几毫秒内完成任何一个环节出现DMA拷贝延迟和数据等待都可能拖坏空口指标。ARM和GPU融合成一颗芯片后数据路径短延迟可控这是它和“x86服务器插一块GPU卡”最大的区别。很多公开技术资料里还提到了配套的DPU网卡。这块卡在AI-RAN里的作用很多人忽略了其实非常关键。基站前传接口承载的是样本数据需要高精度的时间同步传统方案里靠BBU里的独立时钟模块解决但在GPU平台里这个功能被卸载到DPU上由DPU完成eCPRI协议解析、时间戳打标、同步和流量整形。DPU还顺带承担了网络虚拟化的负载把容器间通信、OVS转发这些开销从CPU上解放出来。2.3 功耗与实时性这笔账RAN工作负载和普通AI推理有一个本质区别无线信号处理是有硬性实时要求的符号级任务必须在微秒级时间窗口内完成过了这个窗口物理层的帧结构就错了用户直接掉线。GPU本身就是为吞吐量设计的一个任务排队等几百微秒很正常所以直接在GPU上跑L1基带会出问题必须有软件栈做实时调度。O社的ATR方案里软件层面的玩法是把L1处理切成两类任务。一类是高优先级实时任务例如每个时隙内的核心符号处理用GPU的专用硬件队列来做严格锁定执行窗口另一类是低优先级非实时任务怎么做都行后台慢慢跑比如测量上报、日志分析。AI推理任务则被放在最低优先级只能占用RAN任务不用的计算资源。功耗账更要细算。服务器级GPU芯片功耗不低一块卡就要几百瓦到上千瓦放在中频基站站址常常超过机房的单机柜供电上限。所以ATR项目在分布式部署场景里直接推出了低功耗版本的设计GPU的时钟频率被锁定到较低档位同时采用外置散热整机整机功耗控制在1千瓦以内。这个数字放到传统基站里依然偏高但已经逼近机柜能接受的范围了。集中式部署则可以把功耗压力转移到边缘机房用液冷解决这也是集中式架构在实践中更好落地的原因之一。2.4 为什么这套平台适合做“运营商级”AI-RAN我个人的判断是ARM加GPU这个组合技术上有取舍但商业上很聪明。GPU的AI生态是现成的不用重新推动产业ARM的授权生态又是开放的运营商可以自己选处理器、选网卡、选服务器不用被单一设备商绑定。O社这样做等于把原本封闭的RAN产业从“卖整机”变成了“组装机”。代价是系统集成难度极高。传统设备商交付的基站是经过整体测试的整机运营商插上电就能用现在ARM服务器、GPU卡、DPU、前传光模块、实时操作系统、容器平台都要自己拼运维团队的要求一下子被拉高了。这也是ATR方案目前更多停留在大型项目合作和PoC验证阶段的原因真正大面积替换现网基站还有一段距离。3. 两种架构形态集中式与分布式怎么用3.1 集中式AI-RANGPU资源池化的优势集中式架构可以理解成把多个基站的基带处理集中到边缘机房机房里的GPU服务器组成一个资源池通过前传网络连接分布在远处的射频单元。这个概念本质上脱胎于C-RAN也就是云化无线接入网但ATR方案里的核心变化是资源池不仅能做基带还能同时跑AI。集中式的第一个好处是资源利用率高。十个基站放在一起负载高峰时间各不相同如果每个基站各自配备一块GPU必然出现有的满负荷有的闲置。集中后十个小区的算力可以共享同一批卡按业务量动态调度总卡数能省下三成以上。第二个好处是便于升级GPU卡可以集中替换不用爬铁塔、进站点一台一台换。第三个好处是AI服务更容易规模化部署机房里的GPU资源池直接统一调度一个模型可以在池子里随意分配任何一个基站覆盖区域的用户都能就近获得AI推理能力不用在每个站点重复部署。需要特别注意前传网络。集中式把基带处理拉到远处后射频单元和基带单元之间的前传时延必须严格受控尤其是L1处理对时延极敏感一般要求单跳传输时延在微秒级所以集中式机房通常距离远端站点几十公里以内并且需要高质量的光模块和精确时间同步协议。前传带宽同样需要预留信道光模块速率不够或者抖动过大空口指标立刻劣化。3.2 分布式AI-RAN把算力直接推到站点分布式架构则是另一幅图景每个基站站点部署一套一体化的ARM加GPU设备整台设备直接挂在接入机房甚至塔上基带处理和AI推理都在本地完成。这种形态解决集中式最头疼的两个问题前传时延超高标准和高带宽依赖。分布式方案在低时延场景里有天然优势。以工业场景为例机器人的运动控制周期一般在几毫秒如果控制决策要发回中心机房一来一回再考虑网络排队很难稳定达标。站点内嵌GPU之后推理计算本地完成时延基本就一次DMA的距离稳定在极低水平。这个优势适合真正硬实时的工业互联网场景是集中式替代不了的。代价也很明显分布式站点的环境比中心机房恶劣得多冬天没有暖气夏天没有空调白天暴晒灰尘和潮气无孔不入。GPU这类高功耗设备放在这种环境里对退热设计、防尘过滤、供电保障都是大考验。另一个问题是算力浪费站点流量有高峰有低谷低谷时GPU完全空闲但不像集中式还可以把资源给别的小区用只能白白闲着。所以分布式架构更适合那些本地AI业务占用本身就比较稳定的场景比如智慧园区、港口、矿山AI负载能和通信负载错峰互补。3.3 同一套软件栈如何覆盖两种模式ATR项目规划里最有价值的部分不是单独支持集中式或分布式而是用一个软件架构同时覆盖了两种模式。这意味着运营商不需要在两种方案之间做非此即彼的选择而可以根据地域、业务类型、机房条件灵活组合比如城区写字楼区域用集中式郊区工厂用分布式。要做到这点关键在于把RAN功能拆分成可编排的原子能力。L1物理层处理、L2协议处理、L3控制面这些功能模块全部做成可独立部署的软件容器。部署集中式时这些容器都跑在中心机房的GPU服务器上部署分布式时本地站点跑L1和一部分L2L3等高时延容忍的功能仍可送回中心机房。资源调度的策略也完全复用。无论集中还是分布底层都有一位GPU资源调度器负责给不同任务分配计算资源RAN任务拥有最高优先级AI任务使用空闲窗口。这套调度逻辑和部署方式无关集中式调度的是一大池子分布式调度的是一小池子策略相同颗粒度不同。这就是软硬件解耦设计带来的最大收益一套软件、两种形态、多处复用。4. 从纸面到落地部署步骤与算力测算4.1 算力测算一个节点需要几块GPU调研要从纸面落到实操第一步就是算算到底需要多少GPU资源。这个数字不能拍脑袋要按小区配置、带宽、天线数量、业务模型逐步推。以一个典型中频宏站小区为例100兆赫兹带宽、4T4R天线配置、TDD制式下行小区峰值吞吐量约在1.5Gbps左右L1物理层处理需要完成FFT变换、信道估计、均衡、编解码等操作每毫秒处理一个时隙的数据。按该GPU厂商公开演示的性能单个加速卡大概可以支撑3至4个这样配置小区的L1处理再叠加一部分L2处理实际能力会降到2至3个还要为突发流量保留余量。如果集中式机房里规划接入10个小区就需要4块以上加速卡。这里有个常见的误算直接把10除以3向上取整成4张卡但实际还要考虑L2开销、AI业务预留和故障冗余更稳妥的是按“每小区占用0.35卡”计算再预留20%算力峰值缓冲和一块卡的N加1备份最终结果是6块卡左右。算力规划宁多勿少因为无线RAN任务一旦超载不是变慢的问题是直接掉线。AI业务的资源预留可以单独计数。如果机房里还要运行30路视频分析每路按一个轻量模型推理需要大约一定比例的GPU实例算就得增加对应数量的卡。RAN和AI需求放在同一个资源池里调度器在保证RAN不超阈值的前提下把剩余算力尽量分配给AIAI资源总量应该在峰值算力基础上再打个折扣。4.2 一套可复制的PoC部署流程我建议第一次做AI-RAN项目验证的团队按下面的顺序走这样可以尽可能规避翻车。先定拓扑和场景。明确是要验证集中式还是分布式或者混合式。建议第一次做集中式机房条件可控问题排查也方便。然后做资源估算参考上一小节的方法把基站数、小区带宽、天线端口、预计AI业务类型和路数全部列出来算出GPU卡数。这一步一定要多算一点富余量软件层的损耗会在压力测试里暴露出来。再准备硬件环境。ARM加GPU的服务器网卡交换机前传光模块时钟同步设备逐一上架。时钟同步这一步经常被忽视AI-RAN机房里基站前传和普通数据中心不太一样必须要走精确时间同步协议否则空口帧对齐不了。软件层则是部署容器平台、实时操作系统的配置、基带加速栈和AI推理框架。然后是单站验证先不在多站并发场景下跑只接一个射频拉远单元验证一块GPU跑L1处理看空口能不能稳定建立连接吞吐量能不能达到理论值的八成以上。最后压力测试逐步增加小区数同时混入AI推理任务观察GPU利用率、时延和空口性能的变化曲线找到资源峰值边界。这一步做完才算从“能用”到了“够用”。4.3 资源切分和SLA保障策略AI-RAN系统里最重要的一条原则是RAN任务必须有绝对优先权。这不是靠程序员自觉而是靠底层调度机制硬保证的。具体实现上GPU实例切片的使用方式值得借鉴。一块物理GPU可按算力比例切分成多个实例每个实例拥有独立计算单元和显存互相之间隔离。可以给RAN任务分配一个独占实例这个实例不参与AI推理专职保证基带处理的实时性。AI任务跑在另一个实例上哪怕它把实例占满也不会对RAN造成直接冲击最多是等资源时间变长。在实例内部还可以加时间片隔离。实时无线任务长期占着队列的一部分固定窗口AI任务只能在剩余窗口里运行。这有点像高速公路上给应急车辆留出专用通道日常行驶非常自由但应急车辆一来其他车必须立刻让行。5. 实测中遇到的问题和几套排查思路5.1 实时任务在GPU上“跑飞”的处理第一次跑L1处理时最常见的问题是GPU任务时延抖动。传统基站的基带处理跑在专用芯片上时间行为几乎是确定的而GPU的任务调度天然带着不确定性。实测时最容易看到的现象是某个时隙的符号处理偶尔超时超时不超过几十微秒但对空口来说已经构成一次小中断。我要特别提醒不要一上来就优化代码先开GPU实时调度日志把超时分布抓出来看。大多数情况下问题不在算法而在任务排队。GPU上有多个计算队列如果RAN任务和AI任务默认使用同一个计算流AI的密集型计算会把RAN任务挤到队尾。解决思路很直接把RAN任务分配到独立的高优先级计算流并配合固定时间片抢占机制同时把AI任务压成低优先级的后台流。这属于平台级配置不需要改一行算法代码。如果配置完成后仍然抖动下一步检查显存分配。GPU实例之间如果共享显存带宽大量的显存拷贝会拖慢RAN处理。给RAN实例预留足够多的显存驻留空间尽量避免运行时频繁申请能显著改善时延稳定性。5.2 前传链路和资源冲突问题速查前传链路是集中式架构最容易出问题的地方。我整理了一份实测中最常踩坑的问题清单给正在做同类项目的团队参考。问题现象定位思路解决办法前传光模块误码率升高空口吞吐下降检查光模块速率和链路预算看是否在长距离场景用错模块等级换成更高等级光模块缩短前传距离空口帧偏移不稳定检查同步源是否所有射频单元都同步到同一时钟统一同步协议配置增加时钟源冗余GPU利用率不满但空口指标差检查CPU和GPU之间数据搬运路径是否走了低速接口确认使用高带宽一致性互联通道关闭不必要的数据拷贝AI推理启动后RAN时延升高查看GPU任务队列是否使用了同一计算流将RAN任务固化到独立计算流并设为最高优先级站点功耗超限导致掉电查看整机功耗曲线是否GPU长期满载设置功耗上限AI任务降频必要时锁GPU工作频率最容易被忽略的一个问题是AI模型预热带来的瞬时CPU和显存冲击。很多AI框架在推理服务冷启动时要加载模型会有一段很明显的资源峰值如果刚好赶上RAN的忙时就可能引发资源争抢。我建议在系统里做AI服务的资源配额限制并把模型加载放在RAN任务低峰期执行AI容器启动后先空载运行一段时间再接入实际业务流量。5.3 一小段真实调试经历供你参考我印象最深的一次调试是分布式站点GPU温度过高导致频率降到非常低整个系统的空口吞吐直接掉了三成。一开始还怀疑是前传问题排查了半天才发现是散热系统没有适配好。GPU在降频保护状态下不会报错只会在日志里提示功耗和温度限制但现网运维如果不关注这部分日志根本发现不了。那个教训让我养成了一个习惯在AI-RAN环境里做任何性能排查第一件事不是看空口指标而是看GPU的实时状态包括温度、功耗、算力利用率、显存占用、计算流队列深度。这五个指标先看完再判断是不是无线侧的问题。传统无线工程师做RAN排查时只看空口AI工程师做系统性能时只看GPU利用率这个项目最考人的恰恰是两边对齐。我个人的体会是AI-RAN这个方向的工程难点不在“GPU跑得动跑不动基带”而在“当一个系统里同时存在实时通信和弹性AI两类任务时怎么让它们互相不拖累”。ARM加GPU的硬件平台提供了一个足够开放的底座但真正决定项目能不能落地的还是软件调度、资源隔离、运营维护这些细节。从现网角度看ATR项目目前最有参考价值的也不是那块GPU卡而是它能不能把这套调度逻辑做成可复用的行业标准。这个方向后续值得持续跟踪尤其是从5G-A走向6G以后基站架构的软件化程度会越来越高今天的ARM加GPU方案很可能就是未来整个接入网的主流底座。 
长河君 · 2026/10/16 7:06:14 · 阅读 1.2k AI-RAN架构深度解析：ARM+GPU如何重塑5G-A与6G接入网
1. 这次调研的起点AI-RAN和O社的ATR项目最近一直在追AI-RAN方向的资料我把它当作接下来几年移动通信最有变量的一块来研究。整理到后面O社的ATR项目成了绕不开的样本公开材料反复出现几个标签基于ARM架构的GPU平台、同时覆盖集中式和分布式AI-RAN、面向5G-A和6G演进。这几点放在一起就是一次完整的架构换代不是某个基站部件的小修小补。AI-RAN全称是AI-Radio Access Network字面意思是“人工智能无线接入网”。但这个词在行业里其实有三层理解容易混。第一层是AI for RAN用AI做信道估计、波束管理、网络节能相当于给无线算法加了一个“智能调度大脑”第二层是AI on RAN把基站机器变成边缘AI算力节点让原本闲置的资源对外输出推理能力第三层是AI and RAN强调AI和无线通信真正共享底层计算资源。ATR项目做的最关键事情就在第三层让5G基带处理和AI推理跑在同一块GPU上用一个硬件平台同时承担通信和算力两种角色。换句话说传统基站的基带处理是交给专用芯片的ASIC、FPGA、DSP好用是好用但只能做无线这一件事。AI服务器又是另外一台设备GPU常年开着利用率却经常不到百分之二十。AI-RAN想改变的是这种浪费。它把无线接入的功能“软”下来跑在通用GPU上闲时算力再给AI任务用。基站从通信设备变成了“能通信的计算节点”这是整个产业逻辑变化的核心。ATR项目为什么值得单独拎出来看主要因为两点。第一这是运营商自己下场做RAN软件栈而不是买设备商的整机O社动的其实不是射频还是天线而是把基带处理整个搬到GPU上重新做一遍第二它同时定义了集中式和分布式两种部署方式不是实验室里演示一把就完而是给了实际组网的路线图。这次调研我主要就是围绕这两点展开的。1.1 一个通俗的比喻把AI-RAN说清楚基站流量是典型的潮汐曲线白天写字楼区域流量拉满凌晨基本空闲。传统方案里BBU设备不管有没有流量整块电路板都在通电待命就像一家餐厅固定开着一个大厨房但一天只有两个饭点有人来吃饭。AI-RAN的思路是把厨房变成可以外接订单的中央厨房。人少的时候厨师们做外卖、做其他餐食把设备和场地利用起来。到了饭点信号处理任务优先级最高所有算力立刻切给业务。同一个厨房不同时间做不同的事。CPU、GPU这类通用计算资源天然适合这种“弹性分工”而专用芯片做不到ASIC的逻辑在出厂时就焊死了。这个比喻还能往下走一层。集中式AI-RAN相当于把几个餐厅的厨房合并到一个中央厨房统一采购、统一排班效率更高但距离远了菜送过去路上一慢会凉分布式AI-RAN相当于每家店保留一个中厨单店响应快但每家店的设备使用率不如中央厨房。这两种模式没有绝对的优劣要看现场条件。1.2 AI-RAN要解决的不只是成本问题很多人以为运营商做AI-RAN就是为了省电、省设备其实这只是最表层。另一个更深的原因是现网设备的软件化比例太低。传统基站里协议栈大部分跑在封闭环境里想新增一个AI优化功能需要依赖设备商升级版本周期非常长。O社这种体量的运营商既有用户规模优势又有AI研发能力自然想打破这个闭环。把RAN跑在GPU上以后很多以前不敢想的场景就通了。基站本身就是一个带AI能力的推理节点可以本地做视频结构化分析、工业设备异常监测、自动驾驶的低时延协同。以前这些东西需要单独在边缘机房部署AI服务器再把结果通过网络送到用户一来一回时延至少几十毫秒。现在基站的GPU直接把AI服务开在离用户最近的地方时延压到个位数毫秒这是5G-A和6G场景里非常重要的一张牌。ATR项目选的硬件路线也很有意思它没有走传统设备商最熟悉的x86 CPU加FPGA加速卡路线而是直接用ARM CPU和GPU融合的平台。这个选择背后是好几笔账我在下一节详细算。2. 硬件底座为什么是ARM架构GPU平台2.1 三种硬件方案的对比我在调研中把当前RAN加速方案分成了三类放在一起做对比这样才能看清ARM加GPU这套组合的位置。第一类是传统ASIC/FPGA方案。典型场景是现网中大量早期5G基站基带L1层走专用芯片性能和功耗都很好但问题也很明显开发周期长迭代一次物理层算法要按年来算AI能力基本为零除非额外挂一台AI服务器否则这块加速卡无法承接任何AI业务运维上也是黑盒出了问题只能交给设备商定位。第二类是x86 CPU加FPGA加速卡的方案。这也是不少厂商在5G中后期采用的路线。FPGA做L1高性能流程x86跑协议栈控制面比ASIC灵活但AI生态仍然弱。FPGA上部署深度学习模型需要专门做量化、编译和布线人力成本极高没法像NVIDIA那样用CUDA生态快速落地。更重要的问题是x86本身功耗高基站站点通常只给几千瓦的电力预算一台x86服务器放上去电源、散热、机房空间都要重新设计。第三类就是ARM加GPU。ARM CPU负责协议栈控制和通用计算GPU承担L1物理层同时也作为AI推理引擎。GPU的好处是同一块硬件天然能跑AI生态极其完整从训练框架到推理引擎全都现成。ARM CPU的好处是功耗低单核能效远好于x86而且ARM在电信设备里其实是老熟人很多基站的控制面早就在用ARM核兼容性不是问题。三类方案的关键差异我用一张简表列出来后面讲参数方便一点。维度ASIC/FPGAx86 FPGAARM GPU基带处理性能高中高中高AI负载承接差差好开发迭代速度慢中快功耗低高中资源池化能力弱中强生态基础封闭封闭开放2.2 ARM和GPU之间那根“高速管道”是关键很多没做过RAN的人第一次看ARM加GPU方案会有一个疑问ARM CPU和GPU是两个东西数据在这两者之间来回搬运会不会成为瓶颈这里就涉及平台本身的设计。ATR方案里选的是某GPU厂商的服务器级加速平台它把ARM CPU和GPU做成了紧密耦合的一颗大芯片CPU与GPU之间不是走传统的PCIe总线而是通过高带宽的一致性互联通道直接相连。PCIe的典型双向带宽在数十GB每秒这个平台的一致性互联在规格上高出一个量级。更重要的是它支持缓存一致性CPU和GPU访问内存时不需要频繁做数据拷贝和驱动同步这对毫秒级信号处理尤其关键。基带处理的本质是实时数据流天线端收到信号经过前传接口进入GPU做FFT变换、信道估计、解调再交回ARM CPU做协议处理。整个过程要在几毫秒内完成任何一个环节出现DMA拷贝延迟和数据等待都可能拖坏空口指标。ARM和GPU融合成一颗芯片后数据路径短延迟可控这是它和“x86服务器插一块GPU卡”最大的区别。很多公开技术资料里还提到了配套的DPU网卡。这块卡在AI-RAN里的作用很多人忽略了其实非常关键。基站前传接口承载的是样本数据需要高精度的时间同步传统方案里靠BBU里的独立时钟模块解决但在GPU平台里这个功能被卸载到DPU上由DPU完成eCPRI协议解析、时间戳打标、同步和流量整形。DPU还顺带承担了网络虚拟化的负载把容器间通信、OVS转发这些开销从CPU上解放出来。2.3 功耗与实时性这笔账RAN工作负载和普通AI推理有一个本质区别无线信号处理是有硬性实时要求的符号级任务必须在微秒级时间窗口内完成过了这个窗口物理层的帧结构就错了用户直接掉线。GPU本身就是为吞吐量设计的一个任务排队等几百微秒很正常所以直接在GPU上跑L1基带会出问题必须有软件栈做实时调度。O社的ATR方案里软件层面的玩法是把L1处理切成两类任务。一类是高优先级实时任务例如每个时隙内的核心符号处理用GPU的专用硬件队列来做严格锁定执行窗口另一类是低优先级非实时任务怎么做都行后台慢慢跑比如测量上报、日志分析。AI推理任务则被放在最低优先级只能占用RAN任务不用的计算资源。功耗账更要细算。服务器级GPU芯片功耗不低一块卡就要几百瓦到上千瓦放在中频基站站址常常超过机房的单机柜供电上限。所以ATR项目在分布式部署场景里直接推出了低功耗版本的设计GPU的时钟频率被锁定到较低档位同时采用外置散热整机整机功耗控制在1千瓦以内。这个数字放到传统基站里依然偏高但已经逼近机柜能接受的范围了。集中式部署则可以把功耗压力转移到边缘机房用液冷解决这也是集中式架构在实践中更好落地的原因之一。2.4 为什么这套平台适合做“运营商级”AI-RAN我个人的判断是ARM加GPU这个组合技术上有取舍但商业上很聪明。GPU的AI生态是现成的不用重新推动产业ARM的授权生态又是开放的运营商可以自己选处理器、选网卡、选服务器不用被单一设备商绑定。O社这样做等于把原本封闭的RAN产业从“卖整机”变成了“组装机”。代价是系统集成难度极高。传统设备商交付的基站是经过整体测试的整机运营商插上电就能用现在ARM服务器、GPU卡、DPU、前传光模块、实时操作系统、容器平台都要自己拼运维团队的要求一下子被拉高了。这也是ATR方案目前更多停留在大型项目合作和PoC验证阶段的原因真正大面积替换现网基站还有一段距离。3. 两种架构形态集中式与分布式怎么用3.1 集中式AI-RANGPU资源池化的优势集中式架构可以理解成把多个基站的基带处理集中到边缘机房机房里的GPU服务器组成一个资源池通过前传网络连接分布在远处的射频单元。这个概念本质上脱胎于C-RAN也就是云化无线接入网但ATR方案里的核心变化是资源池不仅能做基带还能同时跑AI。集中式的第一个好处是资源利用率高。十个基站放在一起负载高峰时间各不相同如果每个基站各自配备一块GPU必然出现有的满负荷有的闲置。集中后十个小区的算力可以共享同一批卡按业务量动态调度总卡数能省下三成以上。第二个好处是便于升级GPU卡可以集中替换不用爬铁塔、进站点一台一台换。第三个好处是AI服务更容易规模化部署机房里的GPU资源池直接统一调度一个模型可以在池子里随意分配任何一个基站覆盖区域的用户都能就近获得AI推理能力不用在每个站点重复部署。需要特别注意前传网络。集中式把基带处理拉到远处后射频单元和基带单元之间的前传时延必须严格受控尤其是L1处理对时延极敏感一般要求单跳传输时延在微秒级所以集中式机房通常距离远端站点几十公里以内并且需要高质量的光模块和精确时间同步协议。前传带宽同样需要预留信道光模块速率不够或者抖动过大空口指标立刻劣化。3.2 分布式AI-RAN把算力直接推到站点分布式架构则是另一幅图景每个基站站点部署一套一体化的ARM加GPU设备整台设备直接挂在接入机房甚至塔上基带处理和AI推理都在本地完成。这种形态解决集中式最头疼的两个问题前传时延超高标准和高带宽依赖。分布式方案在低时延场景里有天然优势。以工业场景为例机器人的运动控制周期一般在几毫秒如果控制决策要发回中心机房一来一回再考虑网络排队很难稳定达标。站点内嵌GPU之后推理计算本地完成时延基本就一次DMA的距离稳定在极低水平。这个优势适合真正硬实时的工业互联网场景是集中式替代不了的。代价也很明显分布式站点的环境比中心机房恶劣得多冬天没有暖气夏天没有空调白天暴晒灰尘和潮气无孔不入。GPU这类高功耗设备放在这种环境里对退热设计、防尘过滤、供电保障都是大考验。另一个问题是算力浪费站点流量有高峰有低谷低谷时GPU完全空闲但不像集中式还可以把资源给别的小区用只能白白闲着。所以分布式架构更适合那些本地AI业务占用本身就比较稳定的场景比如智慧园区、港口、矿山AI负载能和通信负载错峰互补。3.3 同一套软件栈如何覆盖两种模式ATR项目规划里最有价值的部分不是单独支持集中式或分布式而是用一个软件架构同时覆盖了两种模式。这意味着运营商不需要在两种方案之间做非此即彼的选择而可以根据地域、业务类型、机房条件灵活组合比如城区写字楼区域用集中式郊区工厂用分布式。要做到这点关键在于把RAN功能拆分成可编排的原子能力。L1物理层处理、L2协议处理、L3控制面这些功能模块全部做成可独立部署的软件容器。部署集中式时这些容器都跑在中心机房的GPU服务器上部署分布式时本地站点跑L1和一部分L2L3等高时延容忍的功能仍可送回中心机房。资源调度的策略也完全复用。无论集中还是分布底层都有一位GPU资源调度器负责给不同任务分配计算资源RAN任务拥有最高优先级AI任务使用空闲窗口。这套调度逻辑和部署方式无关集中式调度的是一大池子分布式调度的是一小池子策略相同颗粒度不同。这就是软硬件解耦设计带来的最大收益一套软件、两种形态、多处复用。4. 从纸面到落地部署步骤与算力测算4.1 算力测算一个节点需要几块GPU调研要从纸面落到实操第一步就是算算到底需要多少GPU资源。这个数字不能拍脑袋要按小区配置、带宽、天线数量、业务模型逐步推。以一个典型中频宏站小区为例100兆赫兹带宽、4T4R天线配置、TDD制式下行小区峰值吞吐量约在1.5Gbps左右L1物理层处理需要完成FFT变换、信道估计、均衡、编解码等操作每毫秒处理一个时隙的数据。按该GPU厂商公开演示的性能单个加速卡大概可以支撑3至4个这样配置小区的L1处理再叠加一部分L2处理实际能力会降到2至3个还要为突发流量保留余量。如果集中式机房里规划接入10个小区就需要4块以上加速卡。这里有个常见的误算直接把10除以3向上取整成4张卡但实际还要考虑L2开销、AI业务预留和故障冗余更稳妥的是按“每小区占用0.35卡”计算再预留20%算力峰值缓冲和一块卡的N加1备份最终结果是6块卡左右。算力规划宁多勿少因为无线RAN任务一旦超载不是变慢的问题是直接掉线。AI业务的资源预留可以单独计数。如果机房里还要运行30路视频分析每路按一个轻量模型推理需要大约一定比例的GPU实例算就得增加对应数量的卡。RAN和AI需求放在同一个资源池里调度器在保证RAN不超阈值的前提下把剩余算力尽量分配给AIAI资源总量应该在峰值算力基础上再打个折扣。4.2 一套可复制的PoC部署流程我建议第一次做AI-RAN项目验证的团队按下面的顺序走这样可以尽可能规避翻车。先定拓扑和场景。明确是要验证集中式还是分布式或者混合式。建议第一次做集中式机房条件可控问题排查也方便。然后做资源估算参考上一小节的方法把基站数、小区带宽、天线端口、预计AI业务类型和路数全部列出来算出GPU卡数。这一步一定要多算一点富余量软件层的损耗会在压力测试里暴露出来。再准备硬件环境。ARM加GPU的服务器网卡交换机前传光模块时钟同步设备逐一上架。时钟同步这一步经常被忽视AI-RAN机房里基站前传和普通数据中心不太一样必须要走精确时间同步协议否则空口帧对齐不了。软件层则是部署容器平台、实时操作系统的配置、基带加速栈和AI推理框架。然后是单站验证先不在多站并发场景下跑只接一个射频拉远单元验证一块GPU跑L1处理看空口能不能稳定建立连接吞吐量能不能达到理论值的八成以上。最后压力测试逐步增加小区数同时混入AI推理任务观察GPU利用率、时延和空口性能的变化曲线找到资源峰值边界。这一步做完才算从“能用”到了“够用”。4.3 资源切分和SLA保障策略AI-RAN系统里最重要的一条原则是RAN任务必须有绝对优先权。这不是靠程序员自觉而是靠底层调度机制硬保证的。具体实现上GPU实例切片的使用方式值得借鉴。一块物理GPU可按算力比例切分成多个实例每个实例拥有独立计算单元和显存互相之间隔离。可以给RAN任务分配一个独占实例这个实例不参与AI推理专职保证基带处理的实时性。AI任务跑在另一个实例上哪怕它把实例占满也不会对RAN造成直接冲击最多是等资源时间变长。在实例内部还可以加时间片隔离。实时无线任务长期占着队列的一部分固定窗口AI任务只能在剩余窗口里运行。这有点像高速公路上给应急车辆留出专用通道日常行驶非常自由但应急车辆一来其他车必须立刻让行。5. 实测中遇到的问题和几套排查思路5.1 实时任务在GPU上“跑飞”的处理第一次跑L1处理时最常见的问题是GPU任务时延抖动。传统基站的基带处理跑在专用芯片上时间行为几乎是确定的而GPU的任务调度天然带着不确定性。实测时最容易看到的现象是某个时隙的符号处理偶尔超时超时不超过几十微秒但对空口来说已经构成一次小中断。我要特别提醒不要一上来就优化代码先开GPU实时调度日志把超时分布抓出来看。大多数情况下问题不在算法而在任务排队。GPU上有多个计算队列如果RAN任务和AI任务默认使用同一个计算流AI的密集型计算会把RAN任务挤到队尾。解决思路很直接把RAN任务分配到独立的高优先级计算流并配合固定时间片抢占机制同时把AI任务压成低优先级的后台流。这属于平台级配置不需要改一行算法代码。如果配置完成后仍然抖动下一步检查显存分配。GPU实例之间如果共享显存带宽大量的显存拷贝会拖慢RAN处理。给RAN实例预留足够多的显存驻留空间尽量避免运行时频繁申请能显著改善时延稳定性。5.2 前传链路和资源冲突问题速查前传链路是集中式架构最容易出问题的地方。我整理了一份实测中最常踩坑的问题清单给正在做同类项目的团队参考。问题现象定位思路解决办法前传光模块误码率升高空口吞吐下降检查光模块速率和链路预算看是否在长距离场景用错模块等级换成更高等级光模块缩短前传距离空口帧偏移不稳定检查同步源是否所有射频单元都同步到同一时钟统一同步协议配置增加时钟源冗余GPU利用率不满但空口指标差检查CPU和GPU之间数据搬运路径是否走了低速接口确认使用高带宽一致性互联通道关闭不必要的数据拷贝AI推理启动后RAN时延升高查看GPU任务队列是否使用了同一计算流将RAN任务固化到独立计算流并设为最高优先级站点功耗超限导致掉电查看整机功耗曲线是否GPU长期满载设置功耗上限AI任务降频必要时锁GPU工作频率最容易被忽略的一个问题是AI模型预热带来的瞬时CPU和显存冲击。很多AI框架在推理服务冷启动时要加载模型会有一段很明显的资源峰值如果刚好赶上RAN的忙时就可能引发资源争抢。我建议在系统里做AI服务的资源配额限制并把模型加载放在RAN任务低峰期执行AI容器启动后先空载运行一段时间再接入实际业务流量。5.3 一小段真实调试经历供你参考我印象最深的一次调试是分布式站点GPU温度过高导致频率降到非常低整个系统的空口吞吐直接掉了三成。一开始还怀疑是前传问题排查了半天才发现是散热系统没有适配好。GPU在降频保护状态下不会报错只会在日志里提示功耗和温度限制但现网运维如果不关注这部分日志根本发现不了。那个教训让我养成了一个习惯在AI-RAN环境里做任何性能排查第一件事不是看空口指标而是看GPU的实时状态包括温度、功耗、算力利用率、显存占用、计算流队列深度。这五个指标先看完再判断是不是无线侧的问题。传统无线工程师做RAN排查时只看空口AI工程师做系统性能时只看GPU利用率这个项目最考人的恰恰是两边对齐。我个人的体会是AI-RAN这个方向的工程难点不在“GPU跑得动跑不动基带”而在“当一个系统里同时存在实时通信和弹性AI两类任务时怎么让它们互相不拖累”。ARM加GPU的硬件平台提供了一个足够开放的底座但真正决定项目能不能落地的还是软件调度、资源隔离、运营维护这些细节。从现网角度看ATR项目目前最有参考价值的也不是那块GPU卡而是它能不能把这套调度逻辑做成可复用的行业标准。这个方向后续值得持续跟踪尤其是从5G-A走向6G以后基站架构的软件化程度会越来越高今天的ARM加GPU方案很可能就是未来整个接入网的主流底座。