好的，我们继续深入规范的第6章，转向N-af_Training服务的API实现细节，这是“天穹智脑”作为中心AI工厂的核心接口。
深度解析 3GPP TS 29.530：6.3 Naf_Training Service API (中心化训练服务的实现蓝图)
本文技术原理深度参考了 3GPP TS 29.530 V1.0.0 (2025-09) Release 19 规范，我们将聚焦于第6.3章“Naf_Training Service API”。本章是
Naf_Training服务的Stage 3协议实现指南，它将第5.4章中描述的“AI模型工厂”生产流程，转化为开发者可以逐行编码实现的具体API接口、资源和数据模型。
“天穹智脑”AI平台的开发已进入深水区。Team Alpha和Team Bravo在VFL（垂直联邦学习）服务的开发上取得了显著进展。现在，项目的焦点转移到了负责核心算法平台的Team Gamma身上。他们的任务是构建“天穹智脑”的心脏——一个强大的、按需生产AI模型的中心化训练平台。
首席架构师Dr. Evelyn Reed在Team Gamma的项目启动会上，指着“决战‘音乐节’网络浪潮”的场景规划图说：“VFL让我们学会了如何与他人共舞，而Naf_Training则要求我们成为舞台的领舞者。客户（NF消费者）将向我们提交最复杂、最苛刻的模型生产订单，我们的平台必须像一座精密的自动化工厂，接收订单、调度资源、执行生产、并最终交付高质量的AI模型。第6.3章就是这座工厂的建设蓝图，每一个API、每一个数据字段，都是保证我们工厂能够高效、标准化运作的齿轮和轴承。”
1. 6.3.1 & 6.3.2 - API的身份与通信协议
规范的结构保持了高度的一致性，首先定义了API的“门牌号”和“通信规则”。
1.1 6.3.1 Introduction - API的统一资源标识符 (URI)
规范原文引用 (Clause 6.3.1 Introduction) The Naf_Training shall use the Naf_Training API. The API URI of the Naf_Training API shall be:
{apiRoot}/<apiName>/<apiVersion>… with the following components:
- The
shall be “naf-train”. - The
shall be “v1”.
深度解读:
- API身份 (
apiName): 规范明确，Naf_Training服务的apiName是naf-train。这个简洁的名称将作为该服务在5G网络中的唯一标识，出现在所有相关API的URI中。 - 完整URI前缀: 因此，所有对此服务的API调用，其URL都将以
{apiRoot}/naf-train/v1为前缀。例如，一个创建训练订阅的完整请求URI将是https://brain.operator.com/naf-train/v1/subscriptions。
1.2 6.3.2 Usage of HTTP - 标准化的通信栈
本节再次确认了SBA的通用通信技术栈，与前两个服务完全一致：
- 协议: 强制使用HTTP/2，并根据AF的可信度决定是否必须使用TLS。
- 数据格式:
application/json用于成功交互，application/problem+json用于错误报告。
Team Gamma的负责人，资深算法工程师Dr. Chen，对团队说：“基础架构部分是标准化的，我们可以直接复用平台已有的组件。我们的核心挑战在于理解并实现Naf_Training独有的、更为复杂的资源和数据模型。让我们直接进入第6.3.3节。”
2. 6.3.3 Resources - “AI模型工厂”的API骨架
本节是6.3章的核心，定义了“AI模型工厂”对外暴露的“订单处理”接口。
2.1 6.3.3.1 Overview - 资源与方法总览
Figure 6.3.3.1-1: Resource URI structure of the Naf_Training API和Table 6.3.3.1-1: Resources and methods overview为我们描绘了API的结构。
资源URI结构:
{apiRoot}/naf-train/<apiVersion>
|
+-- /subscriptions
|
+-- /{subscriptionId}
资源与方法概览表 (Table 6.3.3.1-1):
| Resource purpose/name | Resource URI (relative path after API URI) | HTTP method | Description (service operation) |
|---|---|---|---|
| Training Subscriptions | /subscriptions | POST | Create a new Training Subscription. |
| Individual Training Subscription | /subscriptions/{subscriptionId} | GET | Retrieve an existing “Individual Training Subscription” resource. |
PUT | Request the update of an existing “Individual Training Subscription” resource. | ||
PATCH | Request the modification of an existing “Individual Training Subscription” resource. | ||
DELETE | Request the deletion of an existing “Individual Training Subscription” resource. |
深度解读:
- 熟悉的结构: API的资源结构与
Naf_VFLTraining服务完全相同，都是围绕/subscriptions集合资源和/{subscriptionId}单个成员资源展开。 - 完整的CRUD+P: 与VFL训练服务一样，
Naf_Training的单个订阅资源上支持完整的GET,PUT,PATCH,DELETE操作，允许消费者对“生产订单”进行全面的生命周期管理（查询、全量修改、部分修改、取消）。
2.2 6.3.3.2 Resource: Training Subscriptions - 创建“生产订单”
本节详细定义了如何通过POST /subscriptions来提交一份新的模型训练订单。
HTTP POST /subscriptions 请求与响应详解:
1. 请求 (Request)
- Request Body: 请求体必须包含一个
TrainEventsSubsc类型的数据结构。
Table 6.3.3.2.3.1-2: Data structures supported by the POST Request Body on this resource
| Data type | P | Cardinality | Description |
|---|---|---|---|
TrainEventsSubsc | M | 1 | Represents the parameters to request the creation of a Training Subscription. |
2. 响应 (Response)
- 成功 (
201 Created):- Response Body: 响应体中返回一个
TrainEventsSubsc结构，即刚刚被接受的“订单”的完整视图。 - Headers: 必须包含
Location头，指向新创建订单的URI。
- Response Body: 响应体中返回一个
Table 6.3.3.2.3.1-3: Data structures supported by the POST Response Body on this resource
| Data type | P | Cardinality | Response codes | Description |
|---|---|---|---|---|
TrainEventsSubsc | M | 1 | 201 Created | Successful case. The Training Subscription is successfully created and a representation of the created “Individual Training Subscription” resource shall be returned. |
场景实现 (Team Gamma的代码逻辑):
后端工程师小王开始设计POST /subscriptions的处理逻辑，重点关注“订单评审”和“资源调度”：
- 定义Controller方法，监听
POST /naf-train/v1/subscriptions。 - 将请求体反序列化为
TrainEventsSubsc对象（这个对象比VFL的订阅对象复杂得多）。 - 核心业务逻辑 - 订单评审:
a. 深度验证
TrainEventsSubsc对象。例如，检查trainFilter指定的数据源是否可访问，targetPeriod是否合理，modelMonInfo中要求的模型精度是否可能达到。 b. 估算资源: 根据订单规格，估算所需的计算资源（GPU/CPU hours）、存储空间和训练时长。 c. 资源检查: 查询内部资源池，确认是否有足够资源来执行此订单。 - 如果评审通过：
a. 生成唯一的
subscriptionId（订单号）。 b. 在数据库中创建订单记录，状态为“已接受”。 c. 向后台的训练调度器提交一个新任务。 - 构建
201 Created响应，设置Location头，并返回订单确认信息。 - 如果评审失败（如数据源不可用、资源不足），则返回相应的
4xx/5xx错误，并在ProblemDetails中详细说明原因。
2.3 6.3.3.3 Resource: Individual Training Subscription - “生产订单”的生命周期管理
本节定义了如何通过GET, PUT, PATCH, DELETE来管理一个正在生产中或已完成的订单。这部分的操作语义与Naf_VFLTraining服务完全一致，我们在此重点突出其在中心化训练场景下的特殊意义。
GET /{subscriptionId}: 查询订单状态。OAM系统可以通过此接口，随时查询“音乐节”模型订单的当前状态（如“数据准备中”、“训练中”、“已完成”）、已用时长、当前模型精度等。PUT /{subscriptionId}: 订单重置。相当于取消旧订单，换一个新的。PATCH /{subscriptionId}: 订单变更。如前述场景，音乐节增加午夜场，OAM通过PATCH请求修改订单中的时间参数，AI工厂需要动态调整生产计划。DELETE /{subscriptionId}: 取消订单。音乐节因故取消，OAM通过DELETE请求，通知“天穹智脑”停止生产，释放所有已分配的资源。
3. 6.3.5 & 6.3.6 - 生产报告与数据模型的精密齿轮
这两节是“AI模型工厂”能够自动化、标准化运作的根本保证，定义了工厂如何向客户汇报，以及所有交互信息的确切格式。
3.1 6.3.5 Notifications - 异步的“生产进度/交付”报告
规范原文引用 (Clause 6.3.5.2 Training Notification) The Training Notification is used by the AF to notify a previously subscribed NF service consumer on Training report(s).
POST {notifUri} 详解:
- 动作: “天穹智脑”在训练的关键节点（如完成一轮epoch、或训练完成时），主动向OAM指定的
notifUri发送POST请求。 - 请求体: 包含一个
TrainEventsNotif数据结构。
3.2 6.3.6 Data Model - 数据的精确定义
这是6.3章的灵魂，定义了中心化训练服务中所有复杂的数据结构。
Type: TrainEventsSubsc (训练订阅/订单)
Table 6.3.6.2.2-1: Definition of type TrainEventsSubsc是该服务的核心数据结构，即“模型生产订单”的模板。
| Attribute name | Data type | P | Cardinality | Description |
|---|---|---|---|---|
trainEventSubs | map(EventSubsc) | M | 1..N | 核心订单项。一个从事件ID到EventSubsc对象的映射。 |
notifUri | Uri | M | 1 | 回调地址。 |
notifCorreId | string | M | 1 | 订单号。 |
reportingReqs | ReportingInformation | O | 0..1 | 报告要求。 |
eventNotifs | array(EventNotif) | C | 1..N | 训练事件报告。仅当订阅时要求立即返回结果时出现。 |
suppFeat | SupportedFeatures | C | 0..1 | 特性协商。 |
深度解读:
map(EventSubsc): 与VFL训练的array不同，这里使用了map结构。key是事件ID（如"LOAD"），value是EventSubsc对象。这使得一个订单可以同时为多个不同的事件请求模型训练，且每个事件的规格（EventSubsc）都可以独立定义。
Type: EventSubsc (单个事件的训练规格)
Table 6.3.6.2.4-1: Definition of type EventSubsc是订单中最具体、最关键的部分。
| Attribute name | Data type | Description |
|---|---|---|
event | NwdafEvent | 要训练的事件，如LOAD。 |
trainFilter | EventFilter | 训练数据过滤器。 |
tgtUe | TargetUeInformation | 目标用户/区域。 |
targetPeriod | TimeWindow | 预测的目标时间窗口。 |
inferInputData | InputDataInfo | 对推理输入数据的要求。 |
modelMonInfo | MlModelMonitorInfo | 模型监控信息，如要求的最低精度accuThreshold。 |
accuLevel | Accuracy | 期望的精度级别。 |
Type: TrainEventsNotif (训练通知/交付单)
Table 6.3.6.2.6-1: Definition of type TrainEventsNotif定义了“生产报告”的格式。
| Attribute name | Data type | P | Cardinality | Description |
|---|---|---|---|---|
notifCorreId | string | M | 1 | 关联的订单号。 |
eventNotifs | array(EventNotif) | M | 1..N | 事件通知数组。 |
Type: EventNotif (单个事件的通知内容)
Table 6.3.6.2.7-1: Definition of type EventNotif是交付单的核心。
| Attribute name | Data type | Description |
|---|---|---|
event | NwdafEvent | 通知的事件。 |
trainingInd | boolean | true=训练中, false=训练完成。 |
validityPeriod | TimeWindow | 训练出的模型适用的时间窗口。 |
spatialValidity | NetworkAreaInfo | 训练出的模型适用的地理区域。 |
accMLModel | Uinteger | 模型精度，0-100。 |
termCause | VflTermCause | 如果训练失败，附上失败原因。 |
modelReference | Uri | 成品交付！ 指向训练好的模型的引用/URI。 |
深度解读:
modelReference: 这是整个Naf_Training服务的最终价值体现。当trainingInd为false时，“天穹智脑”必须在此字段中提供一个URI，指向新生成的模型。消费者（如OAM）获取到这个URI后，就可以在Naf_Inference服务中，用它来发起推理请求。从生产到消费的闭环，在这里通过一个URI完美地连接了起来。
4. 总结：构建标准化的“AI模型即服务”工厂
通过对第6.3章的精读，Team Gamma已经拥有了构建“天穹智脑”中心训练平台所需的所有技术细节。这不仅仅是一套API，更是一套完整的、标准化的“AI模型即服务”（Model-as-a-Service）的工业流程。
- 标准化的订单 (
TrainEventsSubsc): 消费者可以通过一份结构化的“订单”，精确地描述他们需要的AI模型规格。 - 自动化的生产流程 (API Operations):
POST,PATCH,DELETE等操作，对应了订单处理、修改、取消的自动化流程。 - 透明的生产监控 (
NotifywithtrainingInd=true): 工厂可以主动向客户报告生产进度，增强了服务的透明度和可信度。 - 可靠的成品交付 (
NotifywithmodelReference): 通过标准的Notify消息，将训练好的模型及其元数据（精度、适用范围等）安全、可靠地交付给客户。
Dr. Chen对团队说：“我们的任务就是将这张蓝图变为现实。我们要构建的，是一个能够响应全网需求的、7x24小时不间断生产智慧的自动化工厂。每一个API的实现，都是在为这座工厂添砖加瓦。让我们开始工作，让‘天穹智半’的心脏，强有力地跳动起来！”
5. FAQ 环节
Q1：Naf_Training和Naf_VFLTraining的数据模型（如订阅请求）有何本质区别？
A1：本质区别在于控制权和信息详尽程度。
Naf_VFLTraining(VflTrainingSubs): 它的数据结构相对简单，更像一份“参与协议”。它主要定义了AF需要遵循的规则（如加密算法、特征对齐方式），而不需要定义模型的具体规格，因为模型是由协调者统一规划的。Naf_Training(TrainEventsSubsc): 它的数据结构非常复杂和详尽，是一份完整的“产品规格说明书”。消费者需要在这里详细定义它想要的最终模型是什么样的（数据源、预测目标、精度要求等），因为AF是这次训练的唯一负责人。
Q2：EventSubsc中的modelMonInfo（模型监控信息）有什么作用？
A2：modelMonInfo是消费者向AI工厂提出的“质量验收标准”。例如，OAM可以在订单中设置accuThreshold（精度阈值）为95。这意味着，OAM要求“天穹智脑”交付的模型的精度不得低于95%。
- 在训练过程中，“天穹智脑”会持续监控模型的性能。如果发现无论如何都无法达到95%的精度，它可以提前终止训练，并通过
Notify告知OAM训练失败，原因是UNABLE_TO_MEET_ACCURACY。 - 只有当模型精度达到或超过95%时，“天穹智脑”才会宣布训练成功，并通过
Notify交付模型。 这个字段将一个开放式的训练任务，变成了一个有明确质量目标的工程项目。
Q3：EventNotif中的validityPeriod和spatialValidity有什么用？
A3：这两个字段是训练出的模型的“使用说明书”，至关重要。
validityPeriod(时间有效性): 告诉消费者，这个模型是在什么样的时间背景下训练出来的，也暗示了它最适合在什么样的时间段使用。例如，一个基于工作日数据训练的模型，在节假日使用的效果可能就会打折扣。spatialValidity(空间有效性): 告诉消费者，这个模型是在哪个地理区域的数据上训练的，最适合用于哪个区域。例如，为“奥体中心”区域训练的模型，直接用到“金融中心”区域，效果可能就不佳。 这两个字段保证了模型的可解释性和正确使用，避免了模型被滥用或误用。
Q4：如果训练过程非常耗时，消费者如何知道AF没有“死机”？
A4：这就是reportingReqs（报告要求）字段的作用。消费者可以在“订单”TrainEventsSubsc中，通过reportingReqs设置一个repPeriod（报告周期），例如“每小时一次”。这样，“天穹智脑”即使还在紧张地计算中，也会每隔一小时就向消费者发送一次Notify（此时trainingInd=true），报告当前的训练轮次、模型精度等“心跳”信息。这让漫长的训练过程对消费者来说是透明的、可监控的。
Q5：EventNotif中交付的modelReference是一个URI，这意味着我可以直接通过HTTP GET下载这个模型文件吗？
A5：不一定。规范将modelReference定义为URI，提供了很大的灵活性，它可能是一个可以直接下载模型文件（如.h5或.pkl格式）的URL，但也可能只是一个不透明的、逻辑上的标识符（URN, Uniform Resource Name）。在后一种情况下，这个URI/URN只是模型的唯一ID，消费者并不能直接用它下载模型，而只能在后续调用Naf_Inference服务时，将其作为modelId参数传入。Naf_Inference服务内部会根据这个ID去加载模型。这种方式更为安全和常见，因为它将模型资产牢牢地控制在AF内部，只暴露服务接口，而不暴露模型文件本身。