企业官网建设流程全解析

26.1.2已经正式发布，Tag 日期是2026-08-12，commit 为efe0d8c。26.1.0是 2026-04-13，26.1.1是 2026-05-27。26.1.2仍属于26-1 系列维护版本，NVIDIA 官方文档的 Release Version 仍写作26-1，但这次代码变化实际上相当大。(GitHub)

先看结论

GitHub 自己显示26.1.2这个 commit 一次改变了63 个文件、7560 行新增、855 行删除；因此它和只有一行版本字符串修正的26.1.1完全不是一个量级。(GitHub)

1. 最大变化：SRS 正式进入 Data Lake / E3

这是26.1.2最值得关注的变化。

26.1 原来的 Data Lake 类型主要是：

fh pusch hest

26.1.2 扩展为：

fh pusch hest srs_iq srs srs_hest

配置文件也新增：

datalake_data_types:[fh,pusch,hest,srs_iq,srs,srs_hest]num_rows_srs_iq:40num_rows_srs:70num_rows_srs_hest:90

而且如果没有显式指定类型，新的默认类型已经包含这些 SRS 数据。

这三个新增类型分别大致对应：

也就是说数据链开始真正变成：

UE SRS ↓ O-RU ↓ O-RAN 7.2x FH ↓ cuPHY SRS Receiver ↓ ┌──────────────┬──────────────┬──────────────┐ │ Raw SRS IQ │ SRS Metrics │ SRS Hest │ └──────────────┴──────────────┴──────────────┘ ↓ Data Lake ↓ E3 Agent ↓ dApp ↓ AI / ML / Analytics

这是 26.1.2 的核心价值。

2. 新增 Raw SRS IQ：GPU → Host → Data Lake

cuPHY API 新增：

__half2*pDataRxSrs;

代码明确说明这是：

host-pinned buffer for raw SRS IQ GPU -> host copy gated on DataLake

SRS RX 会把buf_st_2中的原始 SRS IQ 从 GPU 拷贝至 Host pinned memory，然后交给 Data Lake。

所以相比 26.1：

26.1 SRS IQ ↓ GPU cuPHY ↓ SRS processing ↓ Hest / SRS report

26.1.2 增加：

26.1.2 ┌→ SRS Processing │ Raw SRS IQ → GPU ────┤ │ └→ Host Pinned Memory ↓ Data Lake ↓ dApp

这对做 Neural Receiver、AI Channel Estimation、RF fingerprint、Channel Prediction 等应用都很重要。

3. SRS telemetry 增加得非常多

26.1.2 的 E3 Agent 已明确暴露：

srs_iq_samples srs_hest srs_rb_snr

其中srs_hest是：

每个 UE 的 SRS Channel Estimate

SRS RB SNR是：

每个 UE、每 RB/PRG 的 SNR

另外新增大量 scalar telemetry，例如：

srs_wideband_snr srs_signal_energy srs_noise_energy srs_toa srs_hd_ant_flag srs_sc_corr srs_cs_corr_ratio_db srs_ant_ports ...

这其中几个特别值得关注：

srs_wideband_snr ↓ 宽带信道质量 srs_rb_snr ↓ 频域信道质量 srs_toa ↓ Time of Arrival srs_sc_corr ↓ Spatial Correlation srs_hest ↓ Channel Matrix H

所以 26.1.2 已经能够为 AI-RAN 提供相当丰富的：

Time Frequency Spatial Channel IQ

多维输入。

这实际上就是你之前提到的Aerial Sample Apps 1.1 新增 30+ SRS telemetry fields背后的 ACAR/L1 数据基础之一。

4. PUSCH Channel Estimate：从单 UE Group 升级到所有 UE Groups

这个改动很重要，但很容易被忽略。

26.1 的代码明确写着：

Currently only handling first UE group

也就是：

UE Group 0 Hest → Data Lake UE Group 1 × UE Group 2 × ...

26.1.2 改成：

all UE groups concatenated

并且：

pChannelEstSizes[g]

为每一个 UE Group 保存 Channel Estimate 大小。

变成：

UE Group 0 ─┐ UE Group 1 ─┤ UE Group 2 ─┤ UE Group 3 ─┤ ↓ H Matrix Buffer ↓ Data Lake

这对：

Multi-UE MU-MIMO Massive MIMO AI Beamforming Channel Prediction

明显更有价值。

所以我认为这是 26.1.2 第二个非常重要的底层升级。

5. 新增 E3 Agent Standalone

这个是26.1.2的另一个大功能。

新目录：

cuPHY-CP/ └── e3agent-standalone/

它允许：

没有真实 RAN、没有 cuPHY、没有 FAPI、没有 O-RU、甚至没有 GPU pipeline，也可以运行真正的 NVIDIA E3 Agent 来开发 dApp。

NVIDIA 在代码说明里写得非常明确：Standalone 环境运行生产版本e3_agent.cpp，dApp 看到的 subscription、indication schema 和 shared-memory layout 与实际 cuBB L1 相同。

架构可以理解为：

真实环境： O-RU ↓ cuPHY ↓ Data Lake ↓ E3 Agent ↓ dApp

现在可以：

开发环境： Synthetic Data 或 Recorded Trace 或 Sionna / AODT ↓ Data Lake Shim ↓ 真正的 E3 Agent ↓ dApp

而且 NVIDIA 明确写了 replay trace 可以来自：

Math Models Sionna AODT 其他数据源

这个东西我认为意义很大。

因为它把：

Wireless Digital Twin + dApp + E3

真正连起来了。

以后完全可以：

Sionna RT ↓ 仿真信道 / Channel Matrix ↓ E3 Standalone ↓ dApp ↓ AI Algorithm

先训练、开发、验证，然后把同一个 dApp 放进真实 Aerial 网络。

6. Standalone 支持 Synthetic + Replay 两种模式

26.1.2 新增两种：

synth

和：

replay

synth可以自己产生：

PUSCH SRS FH Channel Estimates IQ

用于功能调试。

replay则可以：

真实 Aerial ↓ ClickHouse / Data Lake ↓ clickhouse_to_trace.py ↓ session.trace ↓ E3 Agent Standalone ↓ dApp replay

并且保持原来的 TAI Timing 节奏进行回放。

所以可以做：

第一次： 真实 OTA 实验 → Record 以后： 无 RU 无 UE 无 PTP 无真实基站 ↓ Replay ↓ 重复调试 dApp

对于算法开发非常实用。

7. PyAerial 新增两个 Notebook

26.1.2 新增：

pyaerial/notebooks/ ├── datalake_hest_per_ue.ipynb └── datalake_srs_per_ue.ipynb

(GitHub)

其中 SRS notebook 已经直接做：

Wideband SNR TOA Signal Energy Noise Energy Spatial Correlation SRS IQ SRS Channel Estimate

分析。

所以整个链已经比较清晰：

WNC O-RU ↓ Aerial cuPHY ↓ Data Lake ↓ ClickHouse ↓ PyAerial / Notebook ↓ SRS Analysis ↓ AI Model

8. 对 WNC O-RU：26.1.2 有一个你需要特别注意的修改

这个与你使用 WNC 很相关。

cuphycontroller_P5G_WNC_DGX.yaml

和：

cuphycontroller_P5G_WNC_GH.yaml

都修改了 O-RAN FH Timing。

其中：

T1a_min_cp_dl_ns:

从：

7600 ns

改为：

77000 ns

即：

7.6 μs → 77 μs

并在多个 cell 配置中重复修改。

同时保留：

T1a_max_cp_dl = 464000 ns Tcp_adv_dl = 125000 ns T1a_max_up = 339000 ns Ta4_min = 84000 ns Ta4_max = 280000 ns

并加入注释明确：

T1a_max_up = T1a_max_cp_dl - Tcp_adv_dl

这不是无关紧要的修改。

对于真实 WNC O-RU，C-Plane/U-Plane timing window 会直接影响：

C-Plane arrival U-Plane arrival late packet early packet FH packet drop RU scheduling

所以如果你从 26.1 升到 26.1.2，不要继续盲目使用旧的 WNC YAML。至少应该把新旧：

cuphycontroller_P5G_WNC_DGX.yaml

做一次 diff。

9. WNC + GH200：开启 Batched Memcpy

GH200 WNC 配置还发生：

use_batched_memcpy:0

变成：

use_batched_memcpy:1

也就是 GPU/Host 数据搬运路径开始默认采用 batch memcpy。

这和这次 Data Lake / SRS 大量增加 GPU→CPU 数据传输是有关系的架构方向，但 commit 本身没有明确写这是修改原因，因此不能简单说“就是为了 SRS”。

10. DGX Spark + ConnectX-7 安装流程变化非常明显

26.1.2 不再简单假设 NIC 已经配置完成，而是专门增加：

DGX Spark ↓ ConnectX-7 ↓ Firmware Verification ↓ mlxconfig ↓ Aerial NIC settings

安装脚本明确要求 CX-7 FW：

28.47.1088

并在安装 DOCA /mlnx-fw-updater后要求：

reboot → make install → FW verify

CX-7 要检查/配置：

FLEX_PARSER_PROFILE_ENABLE=4 PROG_PARSE_GRAPH=1 REAL_TIME_CLOCK_ENABLE=1 ACCURATE_TX_SCHEDULER=1 CQE_COMPRESSION=1

这一点与你之前碰到的：

ConnectX-7 Flex Parser / offload unsupported

问题尤其相关。

也就是说26.1.2 并没有取消 Flex Parser 要求，反而把 CX-7 firmware 和这些 mlxconfig 参数正式纳入安装检查流程。

因此如果某块 CX-7：

FLEX_PARSER_PROFILE_ENABLE

确实报“不支持”，那么在 26.1.2 下更应该进一步检查：

CX-7具体SKU FW 28.47.1088 DOCA OFED mlxconfig capability

而不是绕过错误。

11. GH200 + BF3 的安装也被重构

GH200 现在不是只处理一个 BF3。

26.1.2 明确配置：

BFB_RSHIM_NUMS="0 1"

对应两个 BF3 device：

/dev/mst/mt41692_pciconf0 /dev/mst/mt41692_pciconf1

并检查 BF3 FW：

32.47.1088

而且流程明确要求：

BFB install ↓ Full POWER CYCLE ↓ make install ↓ mlxconfig settings ↓ Full POWER CYCLE ↓ make install

NVIDIA 特别强调：

soft reboot 不够。

这对于 GH200 安装稳定性来说是一个相当大的改进。

12. Spark 的 PTP CPU affinity 也改了

26.1：

PTP_CPU_AFFINITY=4

默认把 PTP pin 到 CPU 4。

26.1.2：

PTP_CPU_AFFINITY=""

默认不绑定 CPU，如果需要再手动指定。

这个变化值得注意。

特别是在 Spark 上如果有：

isolcpus nohz_full RT thread cuPHY worker ptp4l phc2sys

CPU affinity 配置不合理，很容易引入 latency spike。

13. 安装方式发生了明显改变

以前文档倾向：

makepreparerebootRU_MAC=xxxmakeall

26.1.2 明确改成分阶段、可恢复安装。

Spark：

makepreparerebootmakeinstallrebootmakeinstallRU_MAC=xxxmakebuildRU_MAC=xxxmakestart_all

GH200 则还需要 cold power cycle。

这个变化说明 NVIDIA 已经意识到：

Kernel DOCA GPU Driver NIC FW mlxconfig PTP Services

之间存在重启依赖，不能简单一个make all从头跑到底。

14. 还有一个容易忽略的重要变化：Data Lake 不再只有一个工作线程

26.1：

datalake_thread

26.1.2：

datalake_pusch_thread datalake_srs_thread

因此处理架构变成更接近：

┌→ PUSCH Data Lake Worker cuPHY ───────┤ └→ SRS Data Lake Worker

而不是 PUSCH/SRS 全部塞进一个线程。

对于实时 L1 来说这是合理的，因为增加：

SRS IQ SRS Hest RB SNR 30+ metrics

以后 Data Lake 的吞吐量明显增加。

15. 5GModel 的 aerial_mcore 包也换了

26.1.2 删除：

aerial_mcore-0.20261.687897.687897

换成：

aerial_mcore-0.20261.567096.567096

(GitHub)

从编号看属于 package revision 的替换/回退，但 commit 没有给出具体原因，因此不应该进一步推断是哪个 bug。

16. 所以 26.1 → 26.1.2 的真正技术意义

如果只看版本号：

26.1.0 ↓ 26.1.1 ↓ 26.1.2

很容易觉得只是 patch。

但实际情况更像：

26.1.0 │ ├── DGX Spark ├── CX-7 ├── SRS MU-MIMO ├── cuMAC ├── GPU shared memory └── E3 / Data Lake 基础 │ │ ▼ 26.1.2 │ ├── Raw SRS IQ → Data Lake ├── SRS Hest → Data Lake ├── SRS RB-SNR → Data Lake ├── 30+ SRS/E3 Telemetry 基础 ├── PUSCH 全 UE Group Hest ├── E3 Agent Standalone ├── Synthetic E3 data ├── Recorded Trace Replay ├── Sionna/AODT → E3/dApp 路径 ├── PyAerial SRS notebooks ├── WNC FH Timing 修改 ├── Spark CX-7 FW 管理增强 ├── GH200 双 BF3 FW 管理 └── 安装/重启流程重构

因此我的判断是：

26.1.2 虽然没有改成26-2，但对于 AI-RAN / dApp / SRS / Data Lake 研发来说，价值远高于普通 patch。

特别是现在研究：

SRS → Channel Estimate → Data Lake → E3 → dApp → AI

的话，26.1.2 明显比 26.1.0 更值得使用。

而对于真实 OTA 系统，尤其是DGX Spark + CX-7 + WNC O-RU，我也倾向于采用26.1.2，但升级时最需要注意两个地方：不能直接沿用旧 WNC FH timing YAML；必须重新核对 CX-7 FW/mlxconfig。

查看 26.1.2 Tag
查看 26.1.0 → 26.1.2 完整 Diff

我可以继续监控 26.1.x/26.2 的 Tag，以及后续是否修正 CX-7、WNC 和 SRS Data Lake 相关问题。