好的,我们继续前进,深入探讨AF作为中心训练平台的Naf_Training服务。
深度解析 3GPP TS 29.530:5.4 Naf_Training Service (中心化模型训练服务)
本文技术原理深度参考了 3GPP TS 29.530 V1.0.0 (2025-09) Release 19 规范,我们将聚焦于第5.4章,对
Naf_Training服务进行全面而深入的拆解。本章定义了当AF作为AI模型训练的中心服务器时,如何响应和管理由NF服务消费者发起的训练任务。
在前两章的探索中,“天穹智脑”AI平台已经成功掌握了作为VFL(垂直联邦学习)客户端的协作技巧,学会了在Naf_VFLTraining和Naf_VFLInference服务中扮演好“参与者”和“协作者”的角色。现在,是时候让“天穹智脑”从幕后走向台前,展现其作为强大中心AI平台的真正实力了。
首席架构师Dr. Evelyn Reed召集了负责核心算法平台的Team Gamma,下达了新的指令:“如果说VFL服务教会了我们如何‘合纵连横’,那么Naf_Training服务将是我们建立‘中央帝国’的基石。在这个服务中,‘天穹智脑’不再是被动的参与者,而是训练任务的主导者、算力的提供者和智慧的生产者。我们的任务,就是构建一个稳定、高效、可按需服务的AI模型工厂。客户下单,我们生产!”
1. 5.4.1 Service Description - 服务的核心使命
本节开宗明义,定义了Naf_Training服务的核心宗旨。
规范原文引用 (Clause 5.4.1 Service Description) The Naf_Training service exposed by the AF enables an NF service consumer to:
- request the creation/update of a Training subscription; and
- receive Training related event(s) reporting.
这段描述与Naf_VFLTraining服务的描述惊人地相似,但内涵却发生了根本性的变化。
- 管理训练订阅 (Subscription Management): AF依然是处理订阅的创建和更新。但在这里,订阅不再是“参与协作的合同”,而是一张发往“天穹智脑”这个AI工厂的**“生产订单”**。NF消费者(如OAM或NWDAF)通过这张订单,详细说明它需要一个什么样的AI模型。
- 报告训练事件 (Event Reporting): AF依然需要报告事件。但在这里,报告不再是“小组工作汇报”,而是AI工厂向客户反馈的**“生产进度报告”或“成品交付通知”**。
“天穹智脑”场景设定:决战“音乐节”网络浪潮
为了生动地展示中心化训练的威力,我们设定一个全新的、极具挑战性的场景:
- 事件: 全市最大的“未来之声”音乐节即将在周末于奥体中心举办,预计将吸引超过10万名观众。
- 挑战: 这将在短时间内对奥体中心及周边区域的移动网络造成巨大的、动态的冲击。传统的静态扩容方案不仅成本高昂,而且无法应对人群在不同舞台、餐饮区、出入口之间的高度动态流动。
- 任务: 运营商的OAM(运维管理系统)希望“天穹智脑”能够基于历史数据,训练一个**“大规模人群动态网络负载预测模型”。OAM将作为NF服务消费者**,向“天穹智脑”这个中心训练平台下达任务。
2. 5.4.2 Service Operations - “AI模型工厂”的生产流程
本节详细定义了“天穹智脑”作为AI工厂的标准化生产流程,即Naf_Training服务的具体操作。
2.1 5.4.2.1 Introduction - 操作总览
Table 5.4.2.1-1: Naf_Training Service Operations清晰地列出了本服务的所有操作接口。
| Service Operation Name | Description | Initiated by |
|---|---|---|
| Naf_Training_Subscribe | This service operation enables the NF service consumer to request the creation/update of a Training Subscription. | e.g., NWDAF, NEF |
| Naf_Training_Unsubscribe | This service operation enables the NF service consumer to request the deletion of a Training Subscription. | e.g., NWDAF, NEF |
| Naf_Training_Notify | This service operation enables the NF service consumer to receive Training related event(s) reporting. | AF |
表格解读:
- 经典三段式: 服务的接口依然是经典的
Subscribe,Unsubscribe,Notify三件套,这体现了3GPP SBA设计的高度一致性,降低了开发者学习和实现的复杂度。 - 明确的角色:
Subscribe和Unsubscribe由消费者(客户)发起,用于下订单和取消订单。Notify由AF(工厂)发起,用于报告进度和交付产品。这种清晰的角色划分,使得双方的交互逻辑一目了然。
接下来,我们将跟随Team Gamma的开发过程,一步步实现这套生产流程。
2.2 5.4.2.2 Naf_Training_Subscribe - 接收并处理“生产订单”
这是客户(OAM)与工厂(“天穹智脑”)的第一次接触,也是整个生产流程的起点。
2.2.2.2.2 Training Subscription Creation (创建订单)
流程图: Figure 5.4.2.2.2-1: Procedure for Training Subscription Creation,该图展示了与VFL训练创建订阅完全一致的交互模式:
- NF service consumer → AF:
1. POST ../subscriptions (TrainEventsSubsc) - AF → NF service consumer:
2a. 201 Created/2b. 4xx/5xx
流程深度解析:
规范原文引用 (Clause 5.4.2.2.2, Step 1)
- In order to subscribe to Training, the NF service consumer shall send an HTTP POST request to the AF targeting the URI of the “Training Subscriptions” collection resource, with the request body including the TrainEventsSubsc data structure.
- 动作: OAM系统向“天穹智脑”的
.../naf-train/v1/subscriptions端点发送一个HTTPPOST请求。 - 载荷 (
TrainEventsSubsc): 这是**“模型生产订单”**的核心。这份订单比VFL的邀请函要复杂得多,因为它需要详细描述最终产品的规格。其中可能包含:trainEventSubs: 一个或多个具体的训练事件订阅。例如,事件可以是“预测NwdafEvent-LOAD(网络负载)”。useCaseCxt: 描述了使用场景,如“music-festival-prediction”。trainFilter: 训练数据过滤器,定义了需要哪些数据,如“奥体中心区域内所有小区过去三年大型活动日的无线KPI数据”。tgtUe: 目标UE信息,比如“所有曾在该区域驻留超过1小时的用户群体”。targetPeriod: 预测的目标时间窗口,如“未来24小时”。notifUri: 必选,OAM提供的回调地址,用于接收生产进度和交付通知。notifCorreId: 必选,订单号,用于关联后续所有通知。
规范原文引用 (Clause 5.4.2.2.2, Step 2a) 2a. Upon success, the AF shall respond with an HTTP “201 Created” status code with the response body containing a representation of the created “Individual Training Subscription” resource…and an HTTP “Location” header field containing the URI of the created resource.
- 成功响应: “天穹智脑”的“订单处理中心”(API网关)接收到订单后,进行评审(参数是否合法、数据是否可用、算力是否足够)。评审通过后:
- 返回
201 Created,表示**“订单已接受,准备投入生产”**。 - 在
Location头中返回该订单的唯一URI,如/naf-train/v1/subscriptions/order-music-fest-01。 - 在响应体中返回完整的订单回执。
- 返回
场景再现:
- OAM的运维专家配置好了“音乐节”网络保障模型的训练参数。
- OAM系统自动生成了一个包含上述所有细节的
TrainEventsSubscJSON对象。 - OAM向“天穹智脑”的
/subscriptions端点发送了POST请求。 - “天穹智脑”接收订单,启动资源调度模块,为该任务分配了100个GPU的算力集群,并向数据湖发起了数据提取请求。
- 一切就绪后,它向OAM返回了
201 Created和订单URI,表示生产流程正式启动。
2.2.2.2.3 Training Subscription Update (修改订单)
流程图: Figure 5.4.2.2.3-1: Procedure for Training Subscription Update,展示了标准的PUT/PATCH更新流程。
流程深度解析:
- 场景: 音乐节主办方临时宣布,将增加一个午夜场,持续到凌晨2点。OAM需要紧急修改模型订单,将训练数据的覆盖时间延长。
- 动作: OAM向
.../subscriptions/order-music-fest-01发送一个PATCH请求,请求体中只包含更新后的trainFilter(时间范围扩展)和targetPeriod字段。 - 响应: “天穹智脑”收到请求后,动态调整了数据提取和训练计划,并返回
200 OK或204 No Content,表示“订单已成功修改”。
2.3 5.4.2.3 Naf_Training_Unsubscribe - 取消“生产订单”
流程图: Figure 5.4.2.3.2-1: Procedure for Training Subscription Deletion,展示了标准的DELETE删除流程。
流程深度解析:
- 场景: 音乐节模型V1.0训练完成并成功交付,或者因故(如活动取消)不再需要该模型。
- 动作: OAM向
.../subscriptions/order-music-fest-01发送DELETE请求,意为“取消此订单”。 - 响应: “天穹智脑”停止该订单相关的所有生产活动,释放资源,归档结果,并返回
204 No Content,表示“订单已成功取消”。
2.4 5.4.2.4 Naf_Training_Notify - 报告进度与交付成品
这是“AI工厂”与客户之间最重要的沟通渠道。
流程图: Figure 5.4.2.4.2-1: Procedure for Training Notification,展示了AF主动向消费者notifUri发送POST通知的标准流程。
流程深度解析:
规范原文引用 (Clause 5.4.2.4.2, Step 1)
- In order to notify a previously subscribed service consumer on Training report(s), the AF shall send an HTTP POST request to the NF service consumer with the request URI set to “{notifUri}”…, and the request body including the TrainEventsNotif data structure.
- 动作: “天穹智脑”在训练过程中,或在训练完成时,主动向OAM在订单中提供的
notifUri发送POST请求。 - 载荷 (
TrainEventsNotif): 这是**“生产报告/交付单”**。notifCorreId: 必选,订单号。eventNotifs: 一个或多个事件通知。这才是报告的核心内容,其中可能包含:event: 报告的事件类型,如“网络负载”。trainingInd: 一个布尔值,true表示**“正在生产中(训练正在进行)”,false表示“生产完成(训练已结束)”**。accMLModel: 训练出的模型的精度值,如95(表示95%的准确率)。modelId/modelUri: 成品交付! 当训练完成后,AF会在这里附上训练好的模型的唯一标识符或访问地址。OAM可以通过这个ID,在后续的Naf_Inference服务中调用这个模型。
场景再现:
- 进度报告: 训练进行到一半,“天穹智脑”向OAM的
notifUri发送了一次Notify。请求体中trainingInd为true,并附上了当前的模型精度等中间指标,让OAM可以实时监控生产质量。OAM收到后返回204 No Content。 - 成品交付: 经过72小时的紧张训练,模型终于诞生。“天穹智脑”再次向OAM发送
Notify。这次,trainingInd为false,accMLModel为98,并且最重要的,附上了modelId: "model-music-fest-v1.0"。 - OAM收到这份“交付通知”,知道模型已生产完毕,质量达标,并记下了模型ID。现在,它随时可以利用这个模型,去调用
Naf_Inference服务,获取对音乐节期间网络负载的精准预测了。
3. 总结:AI能力即服务 (AIaaS) 的标准实现
通过对5.4章的深入分析,我们看到Naf_Training服务为5G网络定义了一套标准的、端到端的“AI能力即服务”(AI as a Service)的生产流程。
- 订单驱动 (Subscription-driven): NF消费者可以像在电商平台下单一样,通过
Subscribe操作,定制化地请求AI模型训练服务。 - 流程透明 (Notification-based): AF通过
Notify机制,将复杂的、耗时的模型训练过程,以异步、事件驱动的方式,对消费者保持透明。 - 成果交付 (Model ID): 服务的最终产出是一个可用的、有唯一标识的AI模型,这个模型可以直接被后续的
Naf_Inference服务所调用,形成了从生产到消费的完美闭环。
Team Gamma出色地完成了任务。他们构建的不仅是一套API,更是一个强大的、自动化的“AI模型工厂”。有了这个工厂,“天穹智脑”就能源源不断地为5G网络的各种智能化场景,生产出定制化的“智慧大脑”,真正实现了AI能力的按需供给。
4. FAQ 环节
Q1:Naf_Training和Naf_VFLTraining在API设计上如此相似,都是Sub/Unsub/Notify,这样设计的好处是什么?
A1:这种高度的一致性是3GPP SBA(服务化架构)设计的核心思想之一,带来了诸多好处:
- 降低学习成本: 开发者一旦掌握了一种服务的交互模式,就能很快上手其他服务,因为它们遵循同样的设计哲学。
- 提高开发效率: 可以复用大量的通用代码和逻辑。例如,处理订阅创建、更新、删除以及异步通知的框架代码,几乎可以在两个服务的实现中共享。
- 增强系统健壮性: 统一的交互模式使得网络中的行为更加可预测,便于进行统一的监控、管理和故障排查。 尽管业务逻辑(一个是中心化训练,一个是参与联邦训练)完全不同,但通过抽象出统一的“订阅/通知”模型,极大地简化了系统的复杂性。
Q2:TrainEventsSubsc这个“订单”数据结构里,具体可以定制哪些训练的细节?
A2:TrainEventsSubsc是一个非常灵活且强大的数据结构,允许消费者精细地控制训练过程。虽然详细字段在第6章定义,但其核心能力包括:
- 事件与目标: 定义要预测的事件(如
LOAD负载,QOS_CHANGE等)和目标(如预测未来值,或进行异常检测)。 - 数据源与过滤: 通过
trainFilter可以指定使用哪些网络区域、哪些时间段、哪些用户群体的数据。 - 模型监控: 通过
MlModelMonitorInfo可以设置对模型性能的要求,比如期望的最低精度accuThreshold。 - 报告要求: 通过
ReportingInformation可以定义AF应该如何报告进度,是周期性报告还是训练完成后一次性报告。 这种灵活性使得AF可以作为一个通用的训练平台,满足各种不同场景的定制化模型需求。
Q3:如果“天穹智脑”AF在训练过程中失败了(比如算力故障或数据源中断),它会如何通知OAM?
A3:这正是Naf_Training_Notify服务的另一个重要作用。当训练异常终止时,“天穹智脑”会向OAM的notifUri发送一次Notify通知。在这个通知的TrainEventsNotif数据结构中,可以包含一个termCause(Termination Cause)字段,用以说明失败的原因,例如INSUFFICIENT_RESOURCES(资源不足)或DATA_NOT_AVAILABLE(数据不可用)。这样,OAM就能及时了解到生产订单失败,并可以根据失败原因决定是重新发起订阅,还是进行人工干预。
Q4:训练出的模型(modelId)是存储在哪里?是存储在AF内部吗?
A4:是的。Naf_Training服务的核心思想是AF作为中心训练平台,它不仅负责“训练”这个动作,也负责“管理”训练出的模型资产。训练完成后,生成的模型文件、元数据、版本信息等,都会被存储在AF的“模型仓库”中。“天穹智脑”会拥有一个庞大的、可管理的模型库。它返回给消费者的modelId,就是这个模型在其仓库中的唯一索引。当消费者后续调用Naf_Inference服务时,只需提供这个modelId,“天穹智脑”就能准确地找到并加载对应的模型来执行推理。
Q5:Table 5.4.1-1中,AF的角色被描述为“acting as VFL server”,这是否意味着Naf_Training服务只能用于VFL场景?
A5:这是一个非常好的问题,也是规范中容易引起混淆的一点。尽管术语是“VFL server”,但Naf_Training服务本身定义的是一个中心化的训练流程,它并不强制要求联邦学习。这里的“VFL Server”更准确的理解应该是与Naf_VFLTraining中AF的“VFL Client”角色相对应,强调其在此服务中扮演的是中心协调者和任务主导者的角色,而不是一个分布式的参与者。在最常见的用法中,Naf_Training就是用于传统的、数据汇集到AF的集中式模型训练。当然,这个框架也具备扩展性,理论上可以协调一个由其他NF作为客户端参与的联邦学习任务,但这并不是其核心和唯一的应用场景。