5G-A里最热闹也最容易被误读的一句话，叫“把AI塞进空口”。我第一次在仿真交流会上听同行聊起这个话题时，心里先打了个问号：空口是通信系统里最讲规矩的地方，每条信令都有固定格式，每个反馈都有比特级约定。而AI是什么？是概率模型，是黑盒，是同一段输入可能给出不同输出的非确定性系统。把这两样东西硬放在一起，就像让一个凭直觉挥洒的画家按照工程图纸一笔一笔作画，还得保证每一笔都不出格。更关键的问题是：3GPP为了维持空口的纪律，到底给AI上了多少道枷锁？这些枷锁值得吗？

我想把这件事说清楚，围绕三个问题展开：AI究竟被塞进了空口的哪个位置；3GPP为了不让链路失控花了多大力气；这些约束带来的代价是什么。如果你正在做5G-A的算法验证、标准化跟踪，或者准备把AI模型从仿真搬进基带芯片，这篇文章应该能帮你省掉不少绕弯子的时间。

1. 真实落点：3GPP到底给5G空口加了哪几块AI

1.1 三大场景：CSI反馈增强、波束管理、定位

3GPP在5G-A的Rel-18阶段没有一上来就搞“全网智能”，而是选了三个非常具体的场景试水。第一个是CSI反馈增强，简单说就是让UE把信道信息用一种类似图像压缩的方式传回基站。传统做法是UE测完信道后，从码本里挑一个最接近的PMI、算一个CQI和RI，再打包上报。AI的做法变成了：UE侧跑一个编码器，把信道矩阵压成一小段稀疏特征；基站侧跑一个解码器，再把这个特征恢复成完整的信道估计。这个思路和微信传压缩图几乎一模一样，瓶颈结构天然适合自编码器。

第二个场景是波束管理。高频段波束很窄，传统方案靠周期性扫描来跟踪最优波束，开销不小。AI可以做两件事：一是波束预测，根据历史波束序列预测下一次切换的方向，跳过部分扫描；二是波束失败预测，提前判断链路快要断了，主动触发切换而不是等失败后再恢复。第三个场景是定位，利用信道特征或者参考信号做“指纹匹配”，通过多小区联合推断终端位置，比纯几何测量的抗NLOS能力更鲁棒。

这三个场景有一个共同点：它们的输入输出都封闭在物理层内部，不改变DCI、UCI这些消息的核心语义。也就是说，AI只是替换了原本由人设计算法完成的那段处理，而协议里“要上报一份信道状态、要维持一个波束连接、要算出一个位置”这件事本身没有变。这很关键，因为3GPP不会被允许去改变一个已经跑得足够稳的流程接头。

1.2 为什么偏偏是这三个场景

我看到不少评论说3GPP太保守，为什么不直接把MAC调度器、HARQ重传这些更影响性能的地方交给AI。原因是调度和重传的失误代价完全不同。CSI反馈算错了，顶多是MCS选高一点导致重传率上升，系统有兜底；波束预测错了，链路会断，但还可以靠波束扫描回退；定位偏差大一点，服务可以降级，不会把连接丢掉。但调度器一旦做出错误决策，会直接放大到整个小区用户的体验；HARQ如果被模型干扰，传输可靠性就会出问题。

这些高风险场景的AI化不是不想做，而是必须在“可证明的兜底机制”成熟之后才会被标准化。3GPP的做法很务实：先用低风险场景把AI/ML框架和管理机制跑通，让业界积累模型监控、切换、回退的经验，后面才谈得上动更敏感的链路。用一句行话讲，这是“在可控边界里先试水”。

1.3 先分清：空口内AI和空口外AI不是一回事

很多讨论把“AI在RAN中的应用”都混在一起，实际上差别很大。空口外的AI，比如网络节能、负载均衡、参数寻优、边缘侧智能运维，这些都是跑在RAN内部的功能，不改变UE和网络之间的协议交互过程。UE根本不知道网络侧用了AI做决策。空口内的AI则完全不同，它改变了物理层某些功能模块的输入输出形态，比如CSI上报内容从“码本索引”变成“隐式特征”，这就必须通过协议约定来保证两端能对上。3GPP真正在做的其实是后者：定义一套“AI辅助空口功能”的协议外壳，让不同厂商的设备和算法能在标准框架下互操作。区分这两者，是理解整个Rel-18 AI方向的第一步。

2. 为什么必须“戴镣铐”：空口的确定性契约与AI的概率本质

2.1 传统空口设计的第一原则：行为可复现

传统物理层设计的出发点不是追求极致性能，而是保证不同厂商的设备能够互通，并且在任何信道条件下都有确定的预期行为。UE上报了PMI=2，基站侧恢复出来的一定是码本里第2个预编码矩阵，全世界任何一台设备结果都一致。DCI里说用格式1_1调度，终端就知道PDSCH资源在哪里，不会因为芯片型号不同、软件版本不同而产生二义性。这种“确定性契约”是整个移动通信系统能大规模商用的基石。

AI的问题恰恰在这里：模型输出是不确定的。同一段信道输入，模型A可能给出0.8的置信度，模型B给出0.75，换个数据集训练出来的模型C可能就变成0.6。这还是在模型没有崩的前提下。一旦模型推理出错，网络侧根本无从判断“错误原因是什么、应该回退到哪个状态”，因为模型权重对协议栈而言完全是黑盒。

我用一个类比来解释：传统协议像是订一份合同，每一条都写得明明白白，出了纠纷看一眼条文就能裁断。AI辅助功能则像是在合同里加了一句“如果乙方觉得合适，可以做一个合理的决定，但乙方得自己保证决定是对的”。这种条款能签，但必须附带极其复杂的监督和退出机制，否则没人敢签字。

2.2 AI与协议栈冲突的三个层次

第一层是输出不确定性。模型对临界输入可能产生跳变，同一个信道样本在推理时出现边界抖动，导致反馈值在两个码本索引之间来回横跳。这在封闭仿真里看起来很微小，但到了真实链路上，基站的调度器和链路自适应都会被这种抖动干扰。

第二层是数据分布偏移。训练AI用的信道数据永远只覆盖真实世界的一小部分。终端穿过小区边缘、进入隧道、遇到强干扰站，信道特征和训练集相差悬殊，模型精度会从90%掉到50%，而且没人能提前预测掉到多少。传统算法面对未知信道虽然也会变差，但它差得可预测，协议可以按最坏情况留余量，AI不行。

第三层是运维黑盒。基站的信道估计模块如果坏了，可以通过特征分析定位到是FFT的问题还是插值的问题。AI模块坏了呢？模型还在跑，输出看似正常，但精度已经悄悄劣化。要发现这种劣化，你必须额外设计监控指标，而这些监控指标本身又需要信令开销、需要门限设计、需要触发条件。

2.3 委员会的真实取舍：宁要“可控的平庸”，不要“失控的惊艳”

翻看Rel-18相关的规范讨论，会发现一个很有意思的现象：几乎所有AI场景都有“与不采用AI时兼容”的要求。这意味着AI被定位成传统方案的增强模块，而不是替代方案。比如CSI反馈，AI模式可以跑，但UE必须保留传统PMI反馈能力；模型出问题，网络要能信令式地把UE切回传统模式。

这样做必然牺牲一部分性能上限。模型自适应能力再强，也要被包裹在一个“随时可以回退”的外壳里；网络侧的恢复流程必须按最坏情况设计；监控门限不能设得太激进。我见过不少做算法的人拿到这些约束后很沮丧，觉得“好不容易训出来的增益，被协议框架削掉三分之一”。但换个角度看，如果3GPP不设这些镣铐，任何一家设备商都不敢把AI功能开源到商用网络里，因为你不知道对端的模型是什么状态。镣铐不是阻碍AI，而是让AI变得可以被信任。

3. 镣铐的内部结构：AI/ML框架为模型管理增加了哪些“规矩”

3.1 全生命周期管理：从训练到推理，每一步都要可控

Rel-18引入的AI/ML框架把模型的一生管得明明白白：训练、配置、推理、监控、切换回退。每一阶段在协议层都有对应动作。训练阶段，标准不规定你用哪种神经网络结构、在什么数据集上训练，但要求模型有明确的适用场景和使用条件；配置阶段，网络要能下发模型ID、激活指定模型、约束模型使用条件；推理阶段，模型输出如何影响现有协议行为要有明确接口；监控阶段，网络要能观测模型的性能指标；切换阶段，一旦触发条件满足，要能从AI模式平滑切回传统模式或切到另一个模型。

这看起来只是一堆流程性的描述，但落地到代码和工作流里就是实实在在的工作量：协议层要新增UE能力字段、模型ID字段、测量上报容器、切换触发信令。L1/L2软件里要多维护一份“AI任务实例”状态机，处理激活、关闭、上报、失败恢复这些事件。任何一个状态转换没定义清楚，跨厂商联调的时候就是事故现场。

3.2 模型ID与切换信令：AI功能如何被调度

模型ID是整件事的枢纽。网络侧通过模型ID告诉UE：现在请使用模型v2.3做CSI反馈。UE收到后要确认本地是否缓存了这个模型，是否满足运行要求，再回复配置完成。这个过程类似应用商店里分发一个小更新包，但多了不少网络约束：模型版本要兼容基站实现，一个终端可能要维护多个模型，模型什么时候可以擦除、什么时候可以覆盖都需要协商。

切换信令的设计也很有讲究。触发切换的原因很可能是模型性能劣化，但网络判断劣化需要先收集监控数据，收集就需要时间。所以协议必须定义一个不算太长的评估窗口，既不能频繁误判，也不能发现劣化后反应太慢。我在找资料时看某设备商的公开材料里提过，切换时延指标直接决定了AI功能的可用性：如果回退需要几十毫秒甚至几百毫秒，高频波束场景下链路早就断了。

3.3 模型黑盒化带来的互通性难题

还有一个很多人忽略的代价：互通性验收。传统协议测试有一个好处，所有行为都是确定性的，测试用例可以精确判定“通过”或“不通过”。但AI模型是黑盒，标准化组织无法定义一个通用的模型质量指标，因为每个厂商训练的数据集不同、模型结构不同。于是只能退而求其次，定义“外部行为约束”：上报延迟不能超过多少、模型切换时延不能超过多少、监控指标应该包含什么类型。至于模型跑出来的CSI重建精度好不好，标准管不了，只能靠厂商自己的仿真和互操作性测试去验证。

这就导致一个新问题：AI功能的性能论证变成了一件各说各话的事。设备商A在自家仿真器里测得增益很高，设备商B在另一个信道模型下测到增益很低，两者都没有错，但行业很难像传统功能那样形成共识。这不是3GPP偷懒，而是概率系统的天然属性。理解这一点，会减少很多对着仿真曲线争输赢的无意义争论。

3.4 这些规矩实际增加了什么工作量和复杂度

我看到不少团队评估AI空口功能的商用落地时，最开始只关注模型训练和精度，后面才发现工程量主要在模型管理这条链路上。新增UE能力上报、模型存储管理、推理任务调度、监控指标计算、回退流程处理，这些代码量和测试量加在一起，一点也不比训练模型小。有人比喻说“模型训出来只用了三分之一的力气，剩下三分之二全在给模型盖笼子”，虽然夸张，但方向是对的。

4. 算一笔代价账：以CSI反馈增强为例

4.1 CSI压缩在端到端链路里的位置和流程

把CSI反馈增强单独拎出来算账，是因为它最有代表性。传统链路是UE测CSI-RS，得到信道估计矩阵，然后查码本，选PMI/RI/CQI，拼成一条UCI消息发出去。AI链路则在中间插了一对编码器解码器：UE侧神经网络把信道矩阵映射成几十个比特的隐式特征，UCI载荷改成传这个特征，基站侧拿到特征后用解码器恢复出信道估计。整个过程从协议外观看只是“UCI里填的内容变了”，但神经网络的推理节点跑在物理层处理链路上，实时性要求很高。

选择这个场景的原因很直接：CSI反馈本身就是空口里少数几个“可以容忍一定误差”的地方。信道估计偏离实际一点，链路自适应会通过CQI和HARQ补偿，不会像波束管理那样一错误就断链。这为AI模型提供了容错空间，也解释了为什么它是第一个大规模讨论AI化的物理层功能。

4.2 需要付出的比特开销、算力开销、信令开销

先说比特。传统CSI反馈里，PMI加CQI加RI，开销在几十比特量级。AI压缩编码器理论上可以把隐式特征压到十几比特甚至更低，但标准不会只为AI模式设计专属上报尺寸，还要求保留传统反馈模式。因此UE要么需要在两种格式之间切换，要么需要同时维护两套上报配置，这本身就占用额外的RRC配置资源。

再说算力。编码器虽然部署在UE侧，但基带芯片不是GPU服务器。一个几万到几十万参数量的CNN模型，一次前向推理大约需要百万到千万次乘加运算。按一个中等规模模型估算，单次推理延迟控制在几毫秒以内是可做的，但需要专门NPU或者给DSP预留一段处理窗口。这直接影响基带芯片的面积预算和功耗预算。我印象里某实验室的仿真评估里，CSI编码器的推理功耗占基带总功耗的比例不算高，但如果后续要支持在线训练，功耗和内存墙会立刻成为瓶颈。

最后是信令。模型管理、监控上报、切换触发这些机制都不是免费的。模型配置信令要占RRC信道，监控指标要定期上报，回退切换需要额外的DCI或MAC CE触发。这些开销虽然单次很小，但叠加起来，对有限的控制信道容量也是一种压力。

4.3 标准化后的性能增益预期：为什么不高

在关注各家公开的仿真数据时，我注意到一个规律：AI-CSI方案在仿真里相对传统码本反馈都有增益，尤其在低于抗噪、高相关性的信道下提升明显。但一旦加上标准化约束——比如传统反馈必须保留、监控门限不能太离谱、模型切换必须平滑——性能优势就明显打折。原因是标准框架要求AI模块与现有协议栈共存，不能为了增益而推翻已有的调度行为。

这其实是合理的。空口AI的目标不是把某项性能提升到极限，而是在不影响稳定性的前提下提升整体效率。拿CSI反馈来说，真正的收益不只是精度高了几个dB，而是终端可以用更低的反馈开销获得相同的调度性能，或者把省下来的比特让给其他控制信息。具体到某个商用配置下能省多少，得看信道环境、终端能力和网络配置，没有统一答案。

4.4 代价不只是协议，还有芯片和测试

协议上的修改只是水面上的部分，水下还有两块：芯片设计和测试体系。芯片要为AI推理预留专用硬件、为多重模型存储预留内存、为模型管理指令预留接口，这意味着基带SoC的设计周期变长。原本做数字基带的团队可能完全不熟悉神经网络推理，需要新增加速器IP、软件栈和工具链。

测试体系的压力更大。传统物理层测试是确定性用例，输一个测试向量，比对输出的比特流。AI功能是统计性行为，同一测试用例在不同权重、不同随机种子下可能结果不同。验证团队要设计大量信道场景、干扰场景、动态环境来评估模型鲁棒性，再叠加回退机制、切换时延、并发模型管理的测试。测试时间从按小时计变成按天计，几乎是可以肯定的。我听说过有厂商的验证团队评价说“没测好模型的边界行为，根本不敢提交商用申请”。

我把CSI反馈增强这笔账的主要花费整理成一张表，方便快速对照：

5. 实操中经常踩的坑：模型上线空口前的几个提醒

5.1 数据分布偏移导致模型老化，监控门限怎么设

模型部署后不是一劳永逸的，电信场景每天都在变，数据分布偏移几乎是必然的。我见过一个团队把CSI编码器仿真做到精度很好，一上外场，发现远点用户信道特征和训练集差异大，重建精度明显下滑，但系统没有监控机制，直到用户投诉速率上不去才发现问题。所以监控指标不是可选项，是必选项。

门限设置要参考滑动窗口。比如统计最近N次上报的重建误差或预测命中率，误差超过阈值持续M次才触发切换。N和M不能拍脑袋，要根据信道相干时间和系统响应时延来定：门限太紧会频繁切换，监控开销反倒吃掉增益；门限太松则劣化期间性能损失不可控。建议前期用系统级仿真把所有信道场景跑一遍，找出模型表现最差的5%场景，用它们的性能下界做兜底门限。

5.2 回退机制必须当作功能设计，不能当作备胎

很多项目把回退当成“出问题了再考虑”的事，这是大坑。AI功能上线的第一版，回退链路必须和AI推理链路同步设计、同步测试。原因是AI推理一旦失败，链路本身可能已经处于不健康状态，此时再按普通流程切回传统算法，时延和信令开销都会放大。比如波束预测失败后，如果回退还要重新做完整的波束扫描，恢复时间可能比AI推理前还长。

正确做法是在设计之初就把回退当成一个一等公民功能。评估切换时延要按最坏情况算，要专门测试“模型错误输出时回退指令是否能被正确响应”的场景。我印象比较深的一次测试是，AI波束预测连续三次给出错误波束索引，回退流程直到第四次才触发，而触发后先等了一个上报窗口才开始重扫，总恢复时间远超预算。这个问题的根源就是回退逻辑没有考虑失败累积的情况。

5.3 端侧算力与功耗：AI推理不是免费的午餐

在GPU服务器上训练模型和在终端基带里跑推理，完全是两码事。基带芯片的算力预算非常紧张，单次推理延迟、内存带宽、功耗都会约束模型设计。我的建议很直接：训模型第一版就把计算量预算写进需求文档，比如“单次CSI编码推理不超过XX万次乘加，算力功耗不超过XX毫瓦”。没有这个预算，模型会越训越大，最终根本塞不进芯片。

模型压缩三板斧很实用：量化、剪枝、蒸馏。CSI反馈这类低层物理量对精度要求比较高，训练时直接采用量化感知训练，先确认INT8精度损失是否在可接受范围再部署，比训完再后量化少踩很多坑。另外注意激活函数的实现成本，某些非线性激活在DSP上实现特别难受，能用简单近似的就不要用复杂算子。这些细节在仿真里不痛不痒，在芯片验证阶段都是硬成本。

5.4 兼容与演进：多版本模型共存要考虑什么

商用网络不会一步到位，可能存在多个终端型号、多种协议版本、多套模型并存的情况。网络侧要有清晰的策略去维护模型版本库，哪些UE用模型A、哪些用模型B、哪些只支持传统方案。新一代模型出来后，要考虑和老模型的平滑切换，避免模型更新引发链路闪断。这里的复杂度不亚于折腾一个简单的容器编排系统，建议从一开始就把模型版本管理当成一个正式组件来做，不要只靠运维脚本拖着。

另外，模型适用条件和服务小区配置强相关。天线数不同、子载波间隔不同、CSI-RS端口数不同，同一个模型不能直接复用。模型训练时需要明确声明适用场景，网络下发模型前也要校验配置匹配，否则模型加载后行为不可预期。这是我在实际项目里发现极易出问题的地方，因为仿真时往往只按某个固定配置训练，量产时才发现一个模型救不了所有配置组合。

说几句实在话

戴着重镣铐跳舞，姿态确实谈不上飘逸。3GPP为了把AI塞进空口，付出的代价是性能上限被压缩、协议复杂度上升、测试验证周期拉长、芯片设计压力变大。这些代价是显性的，也是必需的。通讯系统的第一原则从来不是“最快”“最聪明”，而是“可靠、可互通、可运维”。如果AI的加入没有这些镣铐，那它根本无法在真实的商用网络中活过第一个安全周。

对我来说，这个方向最有意思的地方在于：它第一次让物理层处理从“完全规则化”走向“规则化外壳加概率内核”。这会给未来十年的无线系统设计带来非常深远的影响。不要只盯着Rel-18那三个场景的增益曲线，更值得关注的是这套模型管理框架——训练、监控、回退、版本共存——这套框架一旦成熟，后面的场景可以像搭积木一样往里加。做空口算法的人，迟早要习惯在这种“不自由”里找空间。习惯了之后你会发现，镣铐知道的边界，往往比自由想象的边界更接近真实世界。