干过无线网络优化和云化基带资源调度的朋友应该都有过这种体验核心网侧风平浪静到了无线侧可能就是一场灾难。去年我在一个大型体育场馆做容量保障晚高峰还没开始监控大屏上一个热门小区的PRB利用率已经顶到98%可用户上报速率却连1Mbps都不到投诉电话一个接一个。反观隔壁小区PRB利用率只有20%出头一张云卡资源就闲在那里。问题出在哪儿出在我们给小区配的云卡资源是静态的压根没跟着无线信道的实际容量走。这个项目做下来核心就一句话把信道容量计算作为云卡分配的依据让基带资源池里每一张卡都流向真正需要它的地方。这里面的链路长得很——从SINR测量、CQI上报到MCS/TBS映射再到以容量为输入的分配算法最后落成云卡动态调整的执行动作每一步都有值得拆的细节。这篇就按我们实际落地时的技术主线把原理、实现和场景预判一次说清楚。1. 云卡分配为什么必须算着来容量感知的必要性1.1 先把云卡这个概念对齐它不是一块铁板卡云卡不是一个标准协议术语但在近几年的C-RAN和云化基带演进里大家已经习惯用云化基带板卡/云卡来指代运行在通用服务器或专用加速器上的虚拟基带处理单元。把它简单理解成基带资源池里的一种资源抽象就够了抽象的核心字段包括计算算力CPU核数/虚拟核数、内存带宽、加速器DSP资源、前传接口带宽以及最重要的时延预算。比如一张云卡可以被定义成2个vCPU 4GB内存 一定量的LDPC编码加速资源 10Gbps前传带宽这些资源打包成一个可调度的实例分配给一个或多个小区使用。这种形态的好处是弹性小区忙时可以给它加卡闲时可以回收。但这也带来了一个根本问题——按什么标准来加、来减、来分配如果标准选错了整个调度系统就只是个花架子。1.2 静态配额和按用户数分卡为什么会在真实无线环境里失效最早的云化资源池沿用了传统BBU时代的静态配额思路每小区固定分配一块板卡的资源忙时加板卡闲时不管。这种思路在话务模型稳定、用户分布均匀的时期问题不大但进入5G时代后用户环境变得太快了。我举一个实测里反复出现的典型场景。两个小区共用一个云资源池一个覆盖室内密集办公区一个覆盖室外主干道。按用户数来分室内小区在线用户数更多分到的云卡资源自然更多。可实际测试结果反而是用户较少的室外小区吞吐更高、时延更低。原因在于室内场景的信道离散度极大有些用户在窗边SINR能到20dB以上有些用户坐在建筑核心区SINR是负数。高SINR用户少低SINR用户多云卡资源虽然多但大量算力被花在了低效的重复传、降级调度上。室外小区虽然用户少信道普遍干净每单位算力能转化的吞吐反而更高。这就是典型的资源量到位了容量没到位。PRB利用率高不代表真实吞吐高云卡分配得多不代表用户就快。任何不看信道条件的分配策略本质上都是在盲人摸象。1.3 用容量计算把资源分配替换成容量分配既然静态配额失效那正确的抽象应该是什么我当时的判断是把分配对象从资源量换成容量。逻辑很简单——在无线侧决定业务体验的不是某些分配了多少算力而是在当前信道条件下用这些算力能挤出多少吞吐、压低多少时延。信道容量计算恰好充当了这座桥梁它把物理层的信道信息SINR、干扰、BLER转换成一个调度系统可以直接消费的元数据类似每张云卡在当前无线条件下能转化成多少Mbps。有了这个元数据分配问题就变得非常清晰——不是均匀分配不是按用户数分配而是按容量缺口和边际收益分配。这也是为什么后面的算法设计、工程实现全部都要围绕容量估计是否准确来展开的原因。容量算得不准算法再漂亮也是空中楼阁。2. 信道容量计算从香农公式到可执行的上报链路2.1 香农极限和真实系统的gap到底差在哪做容量计算第一反应肯定是香农公式C B × log2(1 SINR)B是带宽SINR是信号与干扰加噪声比。这条式子给出了信道容量的理论上限但它和真实网络能力之间有一道不可忽视的gap。真实系统的调制编码方式是离散的阶梯不是连续可调的。以NR为例PDSCH的MCS索引是有限个档位每一档对应固定的调制阶数和码率从QPSK一路到256QAM。系统实际能跑的速率必须落在一个具体的MCS档位上不可能是香农公式算出来的那个连续值。所以我的建议是云卡分配系统里不要直接用香农公式的瞬时输出作为容量值要用MCS阶梯校准后的可达速率作为容量估计。这条原则在后面整个算法设计中都是基调。理论极限可以用于容量上限推算和预规划但实时调度必须以可实现速率为准。2.2 SINR → CQI → MCS → TBS → 吞吐量的完整换算链路具体落地时容量计算的输入并不是直接拿频谱仪去测SINR而是走一条现成的链路UE测量参考信号上报CSI包含CQI、PMI、RI网络侧根据CQI选择MCS再结合分配的PRB数查出TBS传输块大小最终得出速率。我把这条链路拆成几步每一环都容易出问题UE侧测量UE基于CRS或CSI-RS做信道估计这个测出来的SINR是用户实际感受的信道质量比理论仿真值靠谱得多。CQI上报UE把SINR映射成CQI索引0~15档。不同档位对应不同的调制方式和码率。MCS选择基站/集中调度器根据CQI决定本次传输用的MCS索引。TBS查表根据MCS和实际调度的PRB数量从协议表里查出TBS大小。吞吐折算TBS除以传输时间间隔如1ms就是该链路的瞬时峰值速率。这里给一组粗略对应关系经验值不同厂家实现有差异但量级可信SINR区间(dB)粗略CQI调制方式大致效率趋势0~52~5QPSK偏低适合覆盖边缘5~106~916QAM中低档10~1510~1364QAM中高档15~2013~15256QAM高档接近峰值这张表对应的算力消耗差异非常大。同样一个PRB256QAM模式下调制解调的计算量比QPSK明显高出一截更别提高阶MIMO的检测复杂度。所以云卡分配系统里容量计算不只是决定该不该加卡还要为加多大的算力卡提供依据——这一点很容易被忽略。2.3 BLER校准容量计算不能只盯着瞬时SINR信道是时变的。UE上报CQI到集中控制器做出分配决策再到业务真正执行中间隔着几十毫秒。如果完全按瞬时SINR计算容量结果经常会过于乐观或过于悲观。我见过不少容量预估方案就栽在这上面——按瞬时SINR算出好几百Mbps的容量实际一跑只有一半。工程上通常用两种手段校准一是加平滑窗口对CQI/SINR做时间维度上的平均或分位数统计而不是用瞬时值二是引入外环调整以实测BLER块误差率反向修正MCS选择。eMBB业务的目标BLER一般设在10%左右URLLC则要求1%以下。BLER过高说明MCS选乐观了需要降档BLER异常低说明有余量可以升档。我把经过校准后的有效容量写成这样一个简单模型C_eff (1 - BLER) × R(MCS, PRB)其中R是从MCS和PRB数查表得到的标称速率。云卡分配算法拿到的应当是C_eff而不是R。一个很常见的误判是两个小区标称速率相同但一个BLER长期在2%另一个长期在15%前者有效容量明显更高。如果分配系统不看BLER就会把资源浪费在大量重传的小区上。3. 分配算法选型与落地从贪心优先到强化学习3.1 把分配问题写成数学模型目标函数和硬约束容量计算拿到手后下一步就是把云卡分配变成一个可计算的优化问题。我们的做法是先建一个最小化、可解释的数学模型再谈算法。假设资源池里有N张云卡服务M个小区。设分配变量x_i表示第i个小区获得的云卡数量每个小区在这些云卡功率下能达到的有效容量是C_eff_i(x_i)。优化的目标不是简单最大化总吞吐那样会导致信道好的小区把所有资源吃光、边缘用户彻底没救用户体验会很难看。我们选的是比例公平效用函数maximize Σ_i Σ_j log(R_j / T_j)R_j是用户j当前的可达速率T_j是用户j的历史平均吞吐。这个目标天然折中信道好、T_j低的用户有更高优先级信道差但长期饥饿的用户也不会被完全饿死。整个函数可以等价地理解成让每个用户吃亏的程度尽量均衡。硬约束则包括算力上限所有小区的分配总和不能超过资源池总算力。时延预算每个小区分配的云卡资源必须保证调度时延和服务质量在目标范围内。前传带宽上限云卡的前传接口带宽不能超限。隔离约束某些切片或高安全等级业务不允许与其他小区共享同一张物理卡。这些约束看着琐碎但任何一个在算法里被忽略落生产环境时都会变成事故。3.2 贪心优先级算法工程上最稳妥的第一版资源池规模不大、小区数量在几十个量级时我的建议是先做贪心优先级不急着上强化学习。贪心方法的思路很直观每次迭代找增量收益最大且需求最迫切的小区给它加一张云卡直到资源耗尽。伪代码大概长这样def allocate_cloud_cards(cells, pool): allocated {} while pool.available 0: candidates [] for cell in cells: # 边际收益给该小区多分配一张云卡能增加的容量 marginal cell.effective_capacity(allocated[cell] 1) \ - cell.effective_capacity(allocated[cell]) # 需求度当前容量与目标容量的差距 demand max(0, cell.target_capacity - cell.effective_capacity(allocated[cell])) candidates.append((cell, demand * marginal)) best_cell max(candidates, keylambda x: x[1])[0] pool.allocate_to(best_cell) allocated[best_cell] 1 return allocated这个算法的好处有三个计算开销几乎可以忽略几十个小区的场景一轮迭代毫秒级完成可解释性强出问题能直接搬出当时每个小区边际收益是多少来复盘调试方便不需要训练阶段和仿真环境。它的缺点也明显每次只做一步前瞻无法考虑这次给A加卡会不会导致后面B完全没卡可加的长远权衡。不过对第一版系统来说这个缺点完全可以通过需求度边际收益排序来对冲因为它已经包含了当前状态下的优先级信息。注意贪心算法里最容易翻车的是边际收益的计算方式。如果直接把每张云卡的算力当成均质资源来处理边际收益算出来全是常数排序就变成了纯按需求度排退化成按人头分卡又绕回老路上了。务必把容量函数做成随分配卡数递增但边际递减的形态。3.3 强化学习路线状态空间变大后的选择小区数量上百、用户动态性强、业务类型混合时贪心算法的一步前瞻就不够看了。我们后续测试过把决策换成强化学习整个建模思路和贪心完全不同。状态每个小区的有效容量估计、在线用户数、平均排队时延、当前占用云卡数。动作每次决策是给某个小区增加一张云卡、减少一张云卡还是保持不动。奖励比例公平效用函数的变化量再减去时延违约惩罚项。训练使用DQN或A2C这类深度强化学习框架都可以。状态空间不大时DQN够用小区数量上百时A2C的稳定性更好。训练数据先用仿真环境生成——把典型场景的信道模型、用户分布、业务模型都参数化做domain randomization域随机化让智能体见过足够多样的环境避免训练和真实环境分布不一致导致泛化失败。接入真实环境时我的建议是先用一段时间的真实采集数据做回放测试确认智能体给出的分配策略在上帝视角下优于贪心基线后再灰度上线。直接上生产环境的风险在于强化学习策略的决策边界不透明万一它在某个罕见业务场景下抽风排查起来非常痛苦。3.4 两条路线的取舍不是非黑即白很多项目会纠结到底用贪心还是强化学习其实这两条路线不是替代关系而是演进关系。我给一张对比表对比项贪心/优先级强化学习计算开销极低毫秒级推理开销可控训练开销大可解释性高可直接审计每步决策偏低需要额外做决策归因冷启动免训练部署即用需要仿真训练和回放验证动态环境适应靠更新需求度间接适应可端到端学习动态规律运维难度低较高需要监控模型漂移推荐阶段第一版、小规模规模化后的演进方向我们实际落地时的路线是第一版跑贪心跑通全链路、积累三个月的容量数据和分配日志之后再把这些数据作为训练集去做强化学习版本用历史数据离线对比确认收益后再切流量。这比自己上来就硬上RL稳妥得多。4. 工程实现的三座山时延预算、无感迁移与回退策略4.1 一条分配指令的端到端时延预算算法想得再漂亮工程执行跟不上就是白搭。云卡分配不是一次性配置下发而是持续控制环路。你需要对从信道测量到云卡资源生效的端到端时延有精确预算。我拆一个典型流程测量与上报UE测量周期通常5~40msCQI周期上报可能10~80ms。汇聚计算集中控制器采集各小区的容量估计约10~20ms。决策执行贪心算法1~10ms强化学习推理20~100ms。配置下发经网管或控制面协议下发到云卡管理面约20~50ms。资源生效虚拟卡实例化或权重调整约10~50ms。单次控制环的端到端时延粗算在50~200ms之间。这个量级意味着云卡的调整周期不适合做到毫秒级工程上我推荐按秒级周期比如1~5秒做一次决策和动作既避免了乒乓效应也给系统留足了稳定时间。4.2 先建后拆的迁移流程比你想的重要得多云卡分配真正执行的时候最忌讳的操作是对一个正在承载业务的小区直接减小资源配额甚至撤销云卡实例。这等于让用户业务在高负载状态下强制搬迁必然掉线、卡顿、闪断。正确流程必须遵循先建后拆原则在资源池其他位置创建满足目标配置的新云卡实例完成配置加载和参数同步。将业务或小区负荷切换到新实例上切换过程和切换后保持一段观察时间。确认新实例运行稳定、指标达标后再释放旧云卡资源。旧资源释放前保留足够长的冷却期避免切换引发的问题立刻摧毁新实例。这套流程确实会多消耗一段时间的双份资源但它是保证业务不中断的底线。我在项目里见过有人为了省资源跳过先建后拆结果切换瞬间业务闪断投诉升级到集团层面省下来的那点算力钱完全不够赔。4.3 配置漂移、对账机制与回退兜底云卡系统的配置链路长经过网管、控制器、虚拟化平台多个层级配置漂移是大概率事件。经常出现的情况是控制器认为某小区已经分配了3张卡但虚拟化平台显示实际只有2张实例在运行。这种状态不一致如果不处理后续算法决策全部建立在一个错误的世界观上。我们采用的办法是定期reconcile对账控制面每隔一段时间如30秒把期望配置和实际生效配置拉齐比对发现差异先告警再自动纠正纠正不成功就进入人工介入流程。回退机制也必须前置设计。我给系统设了硬性安全阈值任何一次云卡调整动作执行后如果目标小区吞吐下降超过25%或BLER抬升超过设定值系统自动回滚到调整前的配置快照。回滚前必须提前保存快照快照内容包括各小区的云卡配额、MCS偏置、流量权重等关键参数。没有快照的回退策略等于没有回退策略。这块内容看着没有算法那么高级但真实运维中云卡分配系统能不能稳定跑三个月不事故拼的就是这些工程细节。5. 应用场景与演进方向从潮汐调度到算网协同5.1 容量热点潮汐大型场馆、交通枢纽、写字楼午高峰容量驱动的云卡分配最直接的应用场景就是应对容量潮汐。大型体育场馆在有比赛和没比赛时业务量可能差几十倍交通枢纽在工作日和节假日、早晚高峰之间也有明显波峰波谷写字楼午休一小时和下班两小时是小区容量需求的高地。这类场景的共同特征是需求可预测。结合票务数据、排班信息、历史流量统计可以在波峰来临前15~30分钟完成云卡的预扩容结束前再按容量收缩。分配系统要做的是三层配合预测层提前给预分配层信号预分配层在波峰来临前建好资源在线决策层在真实运行中做微调。只靠实时反应效果会大打折扣因为时延预算在那里摆着。5.2 多业务差异化保障eMBB、URLLC、mMTC混合5G时代一张网里同时跑大带宽、低时延、海量连接三类业务容量计算的角度完全不同。eMBB看的是平均吞吐容量越大越好URLLC看的是边缘速率和时延边界追求的是最差情况也不出格mMTC看的是连接密度对单用户速率毫无要求。云卡分配策略可以相应分层给URLLC切片预留一定比例的专用云卡保证极端负载下低时延业务不被大流量业务挤垮mMTC业务对算力消耗极低可以在剩余容量里捎带eMBB则完全走容量驱动的动态分配。这里的容量计算要细化到业务粒度不能只看小区总容量得看每个切片在当前信道条件下能分到多少有效容量。5.3 节能视角容量收缩与资源关断的结合还有一个容易被忽视的方向是节能。无线网络到了凌晨业务量极低大多数小区的容量需求只有高峰期的十分之一。容量驱动的云卡分配系统可以自然地把多个低负载小区合并到少数几张云卡上释放出的物理服务器进入深度休眠状态整机的功耗直接降下来。这项实践在运营商侧的价值非常大。我们做过测算在低业务时段合理收缩云卡资源并关闭空闲物理机功耗节省可以到两位数百分比。但有两个前提收缩策略必须预留一定的突发余量避免突然有用户大量接入时资源池被瞬间打满同时要配合快速唤醒机制能在1分钟内恢复足够的算力来应对突发的容量需求。5.4 下一步演进AI预测、数字孪生与算网协同最后聊几个方向上被验证有潜力、但我们还没完全走通的部分。第一个是AI时间序列预测把历史容量数据、客流数据、天气数据都喂给预测模型云卡分配从事后响应变成事前预判体验和效率都会再上一级台阶。第二个是数字孪生在仿真孪生环境里先跑一遍策略、验证效果和风险再把可用方案下发到真实网络相当于给分配动作上了双保险。第三个是算网协同无线侧的容量计算不再只服务于云卡分配而是和边缘计算节点的负载联动一张云卡的归属同时考虑无线信道的可达容量和边缘业务的算力需求这对未来的低时延业务融合场景很有价值。我在实际部署这套系统时最深的一个体会是算法本身不是瓶颈瓶颈在于容量估计的可信度和执行动作的安全性这两个看着不性感的环节。容量估计算得不准再多花哨的算法都是空中楼阁执行流程不安全一次事故就能让整个项目退回解放前。所以我的建议很直接——不管最终目标多宏大第一版务必要从可信的容量测量和安全的资源迁移做起跑通闭环、积累数据再谈智能和优化。先把地基夯实上面的楼才能盖得稳。