从 AI-RAN 到 AI Agent：基于 NVIDIA Nemotron 构建 5G/6G 智能网络故障诊断系统

从 AI-RAN 到 AI Agent：基于 NVIDIA Nemotron 构建 5G/6G 智能网络故障诊断系统

让 AI 不只是回答通信协议问题，而是真正读懂 gNB 日志、O-RAN 前传异常和 5G 核心网运行状态。

一、当 5G 网络遇上大语言模型

在传统的 5G 网络开发和运维过程中，网络故障诊断始终是一项高度依赖工程经验的工作。

例如，在一套由 NVIDIA Aerial、OpenAirInterface（OAI）、O-RAN O-RU 和 5G Core 组成的端到端实验平台中，一次手机无法注册、上下行吞吐异常或者 O-RAN 前传通信失败，可能涉及多个不同的技术层面。

从无线物理层的信道质量、MAC 调度、RRC 信令，到核心网的 AMF、SMF、UPF，再到 O-RAN 前传的 eCPRI、PTP 时间同步和交换机配置，都有可能成为问题来源。

传统的排障过程通常需要工程师分别查看不同组件的日志，再结合 3GPP、O-RAN 标准和设备厂商文档进行分析。

这种方式不仅需要大量专业知识，而且面对跨协议层、跨设备的复杂问题时，排查过程往往较为繁琐。

随着 NVIDIA Nemotron 等开放大语言模型的发展，一种新的技术思路正在出现：

将通信专业大模型与实际网络数据相结合，构建能够理解网络运行状态、分析故障原因并辅助工程决策的 AI Agent。

这可能成为 AI-Native Network 的一个重要发展方向。

二、为什么通信行业需要专用大模型？

通用大语言模型已经能够回答许多通信技术问题，但在具体工程场景中，仍然存在局限性。

例如，通信工程师提出以下问题：

• 5G NR 中 PRACH 和 PUSCH 的资源配置有什么区别？
• O-RAN Split 7.2x 的 C-Plane 和 U-Plane 如何协同？
• PTP Offset 正常，为什么仍然出现 Late Slot？
• UE 已成功注册 5GC，为什么无法建立 PDU Session？
• OAI gNB 与 O-RU 前传连接正常，但上行吞吐持续异常，应该从哪里排查？

这些问题不仅需要理解通信术语，还需要具备跨协议层分析、关联日志和理解工程实现的能力。

针对这一需求，AdaptKey 基于 NVIDIA Nemotron 3 Nano 30B-A3B 开放基础模型，推出了面向通信行业的 AdaptKey-Nemotron-30b。

该模型通过 LoRA 微调方式，使用超过 130 万条通信领域训练样本，涉及：

• 3GPP 标准
• IETF 网络协议
• O-RAN 架构
• 网络日志与异常检测
• 网络功能配置
• srsRAN 相关知识

根据 AdaptKey 发布的 TeleFlow 评测，模型综合得分由基础模型的 538 提升至 596，提升约 10.8%。

其中，网络日志分析、YAML 配置生成和网络参数表格推理是提升较为明显的项目。

这些结果表明，面向特定行业的数据微调具有一定价值。不过，该评测由模型发布方提供，仍需要通过独立测试确认其在真实通信网络中的表现。

模型地址：

https://huggingface.co/AdaptKey/AdaptKey-Nemotron-30b

三、通信大模型不应该只是一个聊天机器人

如果只是将 Nemotron 部署到 DGX Spark，通过 Open WebUI 提问通信标准知识，那么它仍然是一个独立的 AI 聊天助手。

真正有工程价值的方向，是让 AI 能够获取真实网络状态。

例如，当用户提出：

"为什么当前 5G 网络的上行吞吐只有 100Mbps？"

理想的智能诊断系统不应直接猜测原因，而是能够按照故障分析流程，逐步获取证据。

首先检查 UE 的无线测量指标，例如 RSRP、SINR 和 BLER。

随后分析 gNB MAC 层的上行调度情况，包括 UL Grant、MCS、PRB 分配和 HARQ 重传。

接着查看 NVIDIA Aerial cuPHY 是否存在物理层处理异常，并检查 O-RAN 前传链路是否出现丢包、时间同步问题或资源配置不一致。

如果以上数据没有明显异常，再继续检查 5G Core、用户面吞吐路径和 iperf3 测试环境。

在这一过程中，大语言模型负责组织诊断逻辑、分析证据和提出下一步检查建议，而实际网络信息由外部工具采集。

这正是 AI Agent 与普通聊天机器人的重要区别。

四、系统架构：DGX Spark + Nemotron + Aerial + OAI

可以考虑采用以下架构，将本地部署的大语言模型与真实 5G 网络测试平台集成。

           Web UI / 工程师
                  |
                  v
         Telecom AI Agent
          故障分析与调度
                  |
        +---------+---------+
        |                   |
        v                   v
  AdaptKey-Nemotron       RAG 知识库
     DGX Spark          3GPP / O-RAN
        |               Aerial / OAI
        |
        v
   诊断工具与 API
        |
   +----+-----+-----+------+
   |          |     |      |
   v          v     v      v
 Aerial      OAI   5GC   O-RAN
 cuPHY      gNB    Core   O-RU
   |          |     |      |
   +----------+-----+------+
              |
              v
       日志 / KPI / 状态
              |
              v
       根因分析与建议

整个系统可以划分为四个主要部分。

第一层：网络数据采集

负责获取 gNB、5GC、O-RU、交换机以及 GPU 加速物理层的运行信息。

第二层：通信知识库

存储 3GPP、O-RAN、NVIDIA Aerial、OAI 等技术文档，并为模型提供检索增强能力。

第三层：通信大模型

使用 AdaptKey-Nemotron-30b 进行语义理解、故障推理和诊断结果生成。

第四层：AI Agent

根据用户的问题调用不同的数据采集工具，组织诊断流程，并输出带有证据的分析结果。

在初期阶段，建议所有操作均采用只读模式，避免 AI 自动修改无线参数或设备配置。

五、如何将 NVIDIA Aerial 数据接入 AI Agent？

NVIDIA Aerial 提供 GPU 加速的无线接入网技术能力，能够将部分无线物理层处理任务运行在 NVIDIA GPU 上。

在实际测试中，Aerial 相关数据可以成为 AI 网络诊断的重要输入。

5.1 cuPHY 运行日志

对于 NVIDIA Aerial，可以重点收集以下信息：

• 物理层处理异常；
• Slot 处理超时；
• FAPI 消息异常；
• GPU 计算时延；
• 前传数据处理状态；
• SRS 和相关信道测量数据（在对应版本与配置支持时）。

例如，运行日志中出现：

AERIAL_ERROR_CODE_MSG_LATE_SLOT_ERR

传统方式需要工程师结合具体运行时间、Slot 调度和系统负载逐项排查。

如果将相关日志、配置和时间戳统一传入 AI Agent，模型可以辅助整理故障线索。

它可以提示工程师检查：

1. FAPI 消息到达时间与调度截止时间的关系；
2. CPU 调度及线程运行情况；
3. GPU 处理时延与系统负载；
4. PTP 时间同步状态；
5. O-RAN 前传数据包的实际到达时间。

需要注意，单独一条 Late Slot 日志不能证明具体根因。只有结合完整时序数据，才能判断究竟是消息迟到、线程调度异常、处理超时还是其他原因。

5.2 SRS 信道数据分析

SRS（Sounding Reference Signal）是 5G NR 上行信道测量的重要参考信号。

在具备相应采集功能的平台中，可以获取与 SRS 有关的信道估计、SNR 或 Timing Offset 等测量信息。

这些数据可以用于辅助分析：

• 上行信道质量；
• UE 的无线传播环境；
• 多天线信道差异；
• 上行链路质量变化；
• 潜在的定位与感知研究问题。

需要区分的是，通信大语言模型不适合直接替代传统数字信号处理算法，对大规模 IQ 样本进行逐点实时处理。

更加合理的方式是先由 DSP、GPU 或专用算法提取统计特征，再交由语言模型进行关联分析和解释。

六、通过 RAG 构建通信标准知识库

通信行业具有大量复杂且持续更新的标准文档。

例如：

• 3GPP TS 38.211：物理信道与调制；
• 3GPP TS 38.212：复用与信道编码；
• 3GPP TS 38.213：物理层控制过程；
• 3GPP TS 38.214：物理层数据过程；
• 3GPP TS 38.331：RRC 协议；
• O-RAN WG4 前传接口规范。

尽管经过通信领域微调的大模型具备一定的专业知识，但不代表它已经准确掌握最新版本的全部协议条款。

因此，可以引入 RAG（Retrieval-Augmented Generation，检索增强生成）技术。

其基本工作流程如下：

工程师提出问题
       |
       v
检索相关技术文档
       |
       v
提取相关协议章节
       |
       v
结合实时网络日志
       |
       v
Nemotron 分析
       |
       v
输出诊断结论及证据

例如，工程师询问：

"在 O-RAN Split 7.2x 架构中，为什么 O-RU 与 O-DU 时间同步正常，却仍然出现 U-Plane 数据异常？"

RAG 系统可以先检索 O-RAN 前传相关规范，再结合实际 PTP、eCPRI、VLAN 和 U-Plane 日志，由通信大模型组织诊断建议。

与直接向大模型提问相比，这种方式能够提供更明确的技术依据。

对于工程应用，建议输出具体文档版本、章节编号和日志时间戳，避免模型引用不相关或过时的规范。

七、AI Agent：从日志分析走向自动化故障排查

NVIDIA 已经公开了一套利用 NeMo-Skills 构建通信网络故障推理模型的技术教程。

该方案采用网络运营中心（NOC）常见的故障处理流程，让 AI 通过工具获取网络告警、资源状态和运行信息，再进行根因分析。

其中涉及的技术包括：

• 监督微调（SFT）；
• 合成故障数据生成；
• 工具调用（Tool Calling）；
• ReAct 推理工作流；
• 故障分类与诊断结果评估。

在 NVIDIA 公布的示例测试中，经过微调的 Qwen3-32B 模型在 21 条合成测试故障上的正确率为 90.5%，基础模型为 81.0%。

该数据来自 NVIDIA 的特定实验流程，并不代表 AdaptKey-Nemotron-30b 的实际表现，也不能直接推广到真实运营商网络。

这一技术路线展示了 AI Agent 如何从被动问答逐步转向主动获取网络证据。

需要注意，该教程中的完整模型训练流程使用多 GPU 环境，而不是针对单台 DGX Spark 的训练方案。

对于单台 DGX Spark，更适合优先开展模型推理、RAG 系统建设及小规模故障分析验证。

教程地址：

https://nvidia-nemo.github.io/Skills/tutorials/2026/02/27/teaching-a-model-to-reason-over-telecom-network-incidents/

八、一个具体案例：5G 上行吞吐异常分析

假设一套 NVIDIA Aerial + OAI + O-RU 测试平台出现以下现象：

• Android UE 成功注册 5G SA 网络；
• 下行吞吐表现正常；
• 上行吞吐明显低于预期；
• PTP Offset 保持在较小范围；
• 网络存在偶发的 Slot Timing 异常。

对于传统工程师而言，需要分别检查多个组件的日志和配置。

如果使用 AI Agent，可以将故障排查拆分为多个步骤。

第一步：收集无线链路指标

读取 UE 的 RSRP、SINR、CQI（如可用）、UL BLER 和 MCS 等信息，判断是否存在明显的无线质量问题。

第二步：分析 MAC 层调度

检查上行 PRB 分配、调度周期、HARQ 重传和 BSR 等相关信息，确认是否受到上行调度限制。

第三步：检查 cuPHY 与 FAPI 状态

检查 Slot Processing、消息处理时序和 GPU 运行状态，分析是否存在实时处理瓶颈。

第四步：检查 O-RAN 前传

确认 eCPRI 数据包、VLAN、MTU、eAxC、时间同步和前传链路统计信息是否正常。

第五步：检查 5GC 用户面路径

检查 UPF 转发、GTP-U 通道、iperf3 服务端接收能力以及网络接口统计。

最后，AI Agent 可以根据各环节的实际证据，输出一份分层故障诊断报告。

例如：

Incident: UL Throughput Degradation

Symptoms:
- UE registered successfully
- DL throughput normal
- UL throughput below expectation
- Occasional slot timing errors

Evidence:
- Radio measurements: pending
- UL scheduling statistics: pending
- cuPHY timing logs: available
- Fronthaul packet counters: pending

Possible causes:
1. UL scheduling limitation
2. PHY processing deadline misses
3. Fronthaul packet loss or timing variation
4. UPF or iperf3 receive-side bottleneck

Recommended next actions:
- Collect UL MCS / BLER / PRB allocation
- Correlate slot errors with throughput drops
- Check eCPRI counters and packet timestamps
- Verify end-to-end user-plane throughput

这是一个示例报告格式，而不是已经获得实际测量结果的诊断结论。

真正的 AI 网络诊断系统，应明确区分已确认的事实、尚未验证的假设以及下一步建议。

九、从故障分析助手走向 AI-Native Network

从长期技术路线来看，通信行业大模型和 AI-RAN 并不是相互替代的技术。

它们主要解决不同层次的问题。

AI-RAN 更侧重利用 AI 和 GPU 计算能力优化无线接入网络，例如物理层计算、信道处理和无线资源优化。

而通信行业大语言模型更侧重理解网络知识、设备状态与运营流程。

二者可以形成互补：

技术方向	主要作用
AI-RAN	无线网络的计算与算法优化
Telecom LLM	通信知识理解及网络分析
RAG	提供协议和设备文档依据
AI Agent	组织跨系统故障诊断流程
Digital Twin	在仿真环境中验证网络行为与配置方案

未来可以进一步将通信大模型、网络数字孪生和自动化管理工具结合。

例如，AI Agent 首先分析实际网络问题，再根据候选解决方案，在数字孪生或实验环境中进行仿真测试。

验证通过后，再由工程师审核并实施相应配置。

这种架构有助于降低直接依赖 AI 自动操作真实网络所带来的风险。

当然，从辅助分析到网络自动化控制，还需要解决模型可靠性、实时性、操作权限、安全隔离以及可验证性等工程问题。

十、总结：让通信大模型真正连接通信网络

AdaptKey-Nemotron-30b 的出现，说明开放基础模型正在朝更加专业化的通信行业方向发展。

但对 5G/6G 开发者来说，真正值得关注的不仅是模型参数规模或者专业知识评测得分。

更重要的是，如何将通信大模型与真实的无线网络系统结合。

基于 NVIDIA DGX Spark、NVIDIA Aerial、OAI、O-RAN 和 RAG 技术，可以探索构建一套本地运行的通信网络智能诊断平台。

这一平台可以从初期的协议问答、日志分析逐步发展到跨组件故障排查、网络状态关联分析及自动化诊断工作流。

通信大模型的价值，不仅在于"知道什么是 5G"，更在于它能否结合真实网络数据，帮助工程师解释"为什么这个 5G 网络没有正常工作"。

对于高校实验室、通信设备开发者和 5G/6G 研究团队，这将是一个值得持续研究的工程方向。

---

参考资料

1. AdaptKey-Nemotron-30b --- Hugging Face
2. NVIDIA Nemotron Foundation Models
3. NVIDIA NeMo-Skills：Teaching a Model to Reason Over Telecom Network Incidents
4. NVIDIA Aerial
5. OpenAirInterface

本文为技术架构分析及工程实现设想。AI Agent 与 NVIDIA Aerial、OAI、O-RAN 的集成方案不代表相关产品已经提供上述全部原生能力。实际功能需结合软件版本、数据接口与部署环境进行验证。