企业官网建设流程全解析

这次调研我一直在琢磨一个问题：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 的实时状态、无线协议栈的部署经验、以及运营商网络运维的各种场景。比如无线接入网里常用的 RIC（RAN 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 加进测试集群做容器级功耗监控，前期的数据效果比我想象中要好。给想做类似事情的朋友一个建议：先别急着买专用功耗硬件，先把你集群里已有的数据拿干净，再把容器的功耗算清楚，很多时候省电的空间，就藏在你想不到的空闲容器和过度配置里。