这次调研我一直在琢磨一个问题AI-RAN 从概念走向机房之后为什么最先被拿出来公开讨论的不是性能不是时延而是功耗。软银和红帽联合开发的这个解决方案恰恰把这个行业里最不好意思摆在台面上的短板——AI-RAN 数据中心到底有多费电——摆到了桌面上。先说结论AI-RAN 的功耗难题不是单一设备的问题而是架构级的问题。通用服务器替代专用基带硬件之后静态功耗上去了AI 推理单元加进来之后峰值功耗又上去了运营商还要求网络不能断所以服务器不能随便关机。这种情况下不重新做一整套功耗管理系统AI-RAN 根本谈不上经济性。这篇文章我会围绕软银和红帽这次合作的背景、技术路线和行业信号尽可能把它拆开讲透。如果你正在考虑虚拟化 RAN、边缘 AI 或者运营商级容器平台的方向这篇内容应该能给到你一些实际参考。1. AI-RAN的功耗账为什么省电反而成了头号难题1.1 通用服务器取代专用设备功耗为什么不降反升传统 RAN 里的基带单元BBU大多是专用硬件芯片是针对无线协议专门设计的一个机框插几块板卡功耗基本恒定设计上把所有功能都定制好了做得又紧凑又省电。到了 vRAN 阶段基带功能变成了跑在通用 CPU 上的软件也就是分布单元DU和集中单元CU这种架构的灵活性的确好但代价是功耗变高了。高在哪里我可以给你算一笔行业里常用的粗账。一座典型 5G 宏站的 DU如果跑在通用 x86 服务器上按 2 路 32 核处理器来配置整机功耗轻松到 1 千瓦以上传统专用基带设备的同类功耗往往在几百瓦这个量级。再加上前传、交换、时钟同步、管理节点一个边缘机柜叠起来功耗差距就相当明显了。行业公开测试里经常提到vRAN 比专用 RAN 的功耗要高 30% 到 50%这个数字在不同负载和不同配置下会有变化但方向性共识是明确的——通用性的代价就是功耗。还有一个容易被忽略的问题专用设备功耗稳定制冷系统也好设计通用服务器随着负载波动热点分布会移动散热设计更难做。你在机房规划空调和机柜功率密度的时候不能只按平均功耗算还要按最不利工况的峰值功耗算这会让整个数据中心的配电和制冷规模进一步放大。1.2 AI进来的同时也给功耗管理带来了变量AI-RAN 和 vRAN 的区别在于它把 AI 推理直接放进了无线接入网。所谓 AI-RAN大体上有三类理解用 AI 来优化 RAN 的运行AI for RAN让 AI 应用和 RAN 共享基础设施AI and RAN以及把 RAN 算力开放给上层 AI 应用AI on RAN。无论哪一类网络上都要增加 GPU、NPU 或者专门 AI 加速卡。GPU 的静态功耗就摆在那里。一块中等功率的 GPU 空载功耗几十瓦跑推理任务时功耗可以到几百瓦。如果在一个边缘节点里既跑 DU 又跑 AI 推理那整机功耗就是 CPU 功耗加 GPU 功耗再加上底座功耗。这时候你会发现一个矛盾AI 处理能力强了功耗上去了但 AI 的预测能力如果用来做资源调度又能反过来帮网络省电。比如预测到下一秒某个小区流量很低就提前让载波进入休眠或者压低载波发射功率。关键看你能不能把这套闭环做出来。我个人的判断是AI-RAN 的直接功耗一定是增加的想单纯靠把 AI 加进 RAN 来省电短期内很难实现。真正的价值在于AI 带来的动态调控能力能不能在系统层面覆盖掉它自身增加的功耗最后跑出净收益。软银和红帽合作开发的这个优化方案本质上就是在做这层系统级的收益管理。2. 软银与红帽这场合作的职责边界和技术底座2.1 软银会把AI-RAN的合作重心放在哪里软银在 AI-RAN 这件事上的布局可以说非常积极。它是 AI-RAN 联盟的核心推动方之一这个联盟 2024 年成立成员里能看到 NVIDIA、Arm、爱立信、诺基亚、微软这些名字。软银旗下有日本市场的移动网络也在大规模建设数据中心推出的 Super Cloud 计划就是面向 AI 时代的基础设施布局。换句话说软银既是 AI-RAN 的提出者和实践者也是潜在的全球方案输出者。在这次和红帽的合作中软银的角色更偏网络侧。它掌握着 RAN 的实时状态、无线协议栈的部署经验、以及运营商网络运维的各种场景。比如无线接入网里常用的 RICRAN Intelligent Controller平台xApp/rApp 的调度逻辑要在哪些时机把功耗优化指令下发到基站这种网络级 know-how 恰恰是通用软件公司很难替代的。软银公开强调过要把 AI-RAN 从演示性项目做成实际可部署的网络方案。这句话分量不轻。运营商行业的规律是任何新架构没有跑过真实商用网络都只能算试点。软银用自己的现网当试验场意味着这个方案不是实验室产品而是要进生产环境的。2.2 红帽提供的是哪几层能力红帽在电信行业的积累比很多人以为的更深厚。电信运营商的核心网、边缘云、OpenShift 容器平台红帽在这些领域都有大量案例。OpenShift 是红帽在 Kubernetes 基础上做的企业级发行版但在 AI-RAN 这个场景里它提供的远不止容器编排。第一层是操作系统底座。RHEL 的电信版和边缘版可以做 CPU 核隔离、巨页配置、实时内核调优这些对 RAN 工作负载的确定性延迟非常重要。RAN 里的 DU 对时延抖动特别敏感内核里一个调度的抖动都可能导致无线帧超时所以节点级调优是基本功。第二层是容器调度和资源管理。OpenShift 里 CPU Manager、NUMA 感知调度、Topology Manager 这些机制能保证 RAN 容器始终跑到确定性高的 CPU 和内存位置。功耗优化方案如果想让某些 CPU 空闲下来进入低功耗状态前提就是调度器能把负载聚拢到部分核上这个能力只有编排平台层面才能给到。第三层是功耗可观测性。红帽开源社区里有个项目叫 Kepler全称是 Kubernetes-based Efficient Power Level Exporter它可以从节点和容器的粒度估算功耗。有了它网络运维人员能看到每个 RAN 容器吃掉多少瓦而不是到了整机层面只能糊里糊涂地看一个总电表。这种细粒度数据正是后面做功耗优化的输入。这三层能力叠加起来红帽在合作里的定位就很清楚了它负责给软银的 AI 功耗优化算法提供一个可控、可观测、可编排的底座。2.3 分工之外开放生态才是这场合作真正值钱的地方这次合作的另一个看点是它没有绑死在任何一个封闭硬件上。软银和红帽跑的是软件加通用硬件的路线这意味着同样的方案理论上可以部署在多家设备商的服务器上不必被某一家专用平台绑架。这种开放路线在通信行业里就是一把双刃剑。好处是避免了供应商锁定坏处是集成和验证的成本全部落在自己头上。软银愿意走这条路说明它对这个方向的长期价值判断很清晰——AI-RAN 如果注定是未来那越早把开放架构的坑踩平后期收益越大。红帽作为中立平台厂商在商业定位上也和这种诉求天然一致。3. 功耗优化方案里真正在省电的技术环节新闻稿和发布会通常只会说AI 驱动动态优化功耗但实际技术环节到底是怎么省下来的互联网上讨论得不多。我把这个方案的实现链路拆成四层从编排到节点、到预测、再到落地约束逐层说清楚。3.1 编排层的功耗感知调度省电的第一件事是别让服务器空转。数据中心里经常出现的情况是一个节点上的容器只用了 20% 的 CPU却没有办法关掉其他空闲节点因为集群里有业务分布和高可用要求。功耗感知调度的思路是把这些负载尽量集中到少数节点上把更多节点留成可休眠状态。具体到 OpenShift 里可以做这样几件事给 RAN 工作负载打上功耗敏感度标签调度器按负载集中的逻辑分配容器。借助 Vertical Pod Autoscaler 和集群自动缩放器在低峰期缩小容器规格、回收节点。用 Node Tuning Operator 设置低功耗的内核配置对空闲节点执行深度睡眠策略。这个环节唯一要小心的是RAN 是高可用敏感业务不能因为省电把一个小区的 DU 和 CU 调度到同一台物理机上否则一台机器宕机就是一片基站脱网。功耗优化再怎么激进容灾规则永远排在更优先的位置。3.2 节点级的调频、调压与功耗封顶到了单机层面核心手段就是动态调频调压也就是控制 CPU 的 P-state 和 C-state。负载不高的时候把 CPU 频率降下来电压也同步降功耗按电压平方的关系往下掉收益非常显著。服务器硬件的功耗管理接口比如 ACPI 里的这些机制原本就有只是服务器厂商默认配置通常偏保守性能优先功耗其次。运营商级场景里更常用的是做功耗封顶power capping也就是给节点设定一个功耗上限。这个上限不能设得太低否则在突发流量时会出现丢包或时延劣化。我看到过一些落地项目的经验封顶策略一般要预留 15% 到 20% 的性能冗余封顶触发之后的降频策略也要按照优先级来先压非实时业务再压实时业务。还有一点容易被忽视从整机功耗里区分 CPU、内存、GPU 各自的比例才能确定该优化谁。GPU 的空闲功耗依然可观如果在低峰期能让 AI 推理容器缩容释放 GPU或者启发 GPU 进入低功耗模式节省效果会非常明显。这就是为什么需要像 Kepler 这类工具先在容器粒度把功耗数据摸清楚。3.3 AI预测驱动的动态休眠与错峰复用这个环节是整个方案里名字最响亮的AI部分。无线网络的流量有很强的时间规律夜间凌晨的流量可能只有白天的几分之一。传统设备商也有小区休眠功能但通常基于固定阈值比如凌晨两点强制关掉某些载波。这种策略太机械容易误伤突发用户的体验。AI 预测能做的是更精细的决策。用历史网络数据训练一个流量预测模型比如按 15 分钟粒度预测每个小区接下来一段时间的负载然后动态决定哪些小区进入符号级微休眠哪些载波可以深度休眠哪些 AI 推理任务可以顺延到低峰期批量执行错峰避开流量高峰期GPU 上的推理任务和通信任务如何错峰复用避免算力闲置。这里我建议搞这个方向的人不要一开始就上多复杂的深度学习模型。先拿几个月的 KPI、流量、资源使用数据跑一个传统的时序模型比如 LightGBM 或 Prophet往往就能达到不错的效果。复杂的强化学习模型训练起来麻烦上线后还不好解释在通信这种对可解释性要求极高的行业里先易后难是比较稳妥的路径。3.4 实时网络约束下的落地取舍必须泼一点冷水功耗优化的每一个手段都在和 RAN 的实时性要求抢资源。DU 的处理时延是毫秒级的降低 CPU 频率、让内核进入低功耗模式、动态调度容器都会直接影响无线帧的及时处理。所以在实际部署中无感知是最高目标但做的时候要分层灰度推进。我的建议是把功耗管理分成两个时间尺度。慢尺度是分钟级和小时级的决策比如载波休眠、容器缩容、GPU 错峰快尺度是毫秒级和秒级的决策比如 CPU 调频这类操作必须交给专门的实时控制器并且要和 DU 的负载刀锋曲线做严格对齐。如果两个尺度混在同一条逻辑里处理很容易在突发流量来临时来不及恢复造成用户体验劣化。还有一个很实际的注意项任何功耗优化动作都要形成完整的审计日志。因为通信网络要满足 SLA 要求一旦某个小区的故障被怀疑和休眠策略有关你需要能追溯出当时做了什么优化决策。没有日志的 AI 优化在运营商的运维流程里是过不了关的。4. 运营商视角这次合作透露出的行业信号4.1 功耗正在从运维成本变成架构选型指标过去运营商采购网络设备主要看性能、容量、价格、可维护性功耗是一个重要考虑但谈不上首要。AI 时代不一样了一个数据中心里塞满 GPU 服务器之后电费和散热成本会迅速成长为 CAPEX 和 OPEX 里最扎眼的一行。我举个直观的对比传统通信机柜的功率密度一个机柜几千瓦到十几千瓦普通风冷就能压住。AI 训练集群的机柜功率密度可以到几十千瓦甚至上百千瓦风冷根本压不住得上液冷。AI-RAN 如果往重算力的方向走机房的暖通设计、供电容量、碳排指标全都得重新规划。这也解释了为什么网络热词里会出现英伟达 B300 数据中心 暖通设计这种词条——GPU 功率密度提升之后暖通已经变成数据中心方案里绕不开的环节。功耗优化不再只是软件层面的省电它直接决定了机房建不建得起、建在什么地方、PUE 能不能过审。软银和红帽这次合作之所以受关注正是因为它把这个问题从IT 运维话题提升到了网络架构战略话题。4.2 产业验证价值虚拟化RAN的风向标前几年业内对 vRAN 的质疑除了性能最多的就是功耗和成本。很多运营商做过测算之后发现 vRAN 在架构灵活性上的收益不足以抵消功耗和硬件成本的增加于是按下了暂停键。软银作为大运营商如果能把 AI-RAN 的功耗优化方案跑通等于给整个行业吃了一颗定心丸虚拟化路线的经济性问题是有解的只是需要系统级的设计方案而不是单点工具。当然目前对外发布的信息还没有给出实测省电数据尤其缺少不同网络负载下的对比。所以我的态度是把这次合作看作一次信心的验证而不是结论的宣布。结论还要看后续的商用报告。4.3 接下来值得继续观察的三件事第一看测试数据。如果后续公开的测试结果显示在典型 5G 负载下AI-RAN 加功耗优化方案的整体功耗已经接近甚至低于传统专用 RAN那这个行业真的会迎来转折点。第二看联盟协同。AI-RAN 联盟里的芯片厂、设备商、软件厂商会不会围绕功耗管理制定统一的度量标准。功耗优化的效果要是各家用各家的口径行业对比无从谈起。第三看方案的可复制性。软银有日本现网红帽有运营商基座但这个方案能不能落到其他国家的网络上会不会受不同频段、不同业务模型的影响这需要更多实网验证。对国内做边缘云和行业网络的人来说这里面的调度、预测、容灾思路都是可以直接借鉴的。我最近也在自己的项目里尝试把 Kepler 加进测试集群做容器级功耗监控前期的数据效果比我想象中要好。给想做类似事情的朋友一个建议先别急着买专用功耗硬件先把你集群里已有的数据拿干净再把容器的功耗算清楚很多时候省电的空间就藏在你想不到的空闲容器和过度配置里。
