26.1.2已经正式发布Tag 日期是2026-08-12commit 为efe0d8c。26.1.0是 2026-04-1326.1.1是 2026-05-27。26.1.2仍属于26-1 系列维护版本NVIDIA 官方文档的 Release Version 仍写作26-1但这次代码变化实际上相当大。(GitHub)先看结论项目26.1 / 26.1.026.1.2发布时间2026-04-132026-08-12定位26-1 首发版26-1 大型维护/增强版相对 26.1.0—2 commits、63 files changed代码规模基线7,560 / -855SRS Data Lake基础 SRS大幅增强SRS 原始 IQ无完整 Data Lake 路径支持SRS Channel EstimateL1/Scheduler 使用可进入 Data Lake/E3SRS RB SNR不完整支持E3 telemetryFH/PUSCH/Hest 为主新增大量 SRS telemetryE3 Agent随真实 cuBB/L1新增 standalone 模式PUSCH Hest只处理第一 UE Group支持所有 UE GroupWNC 配置原始 timing修改 FH timing 参数DGX Spark CX-7已支持FW 检查/配置流程显著增强GH200 BF3已支持双 BF3 FW/BFB 管理增强安装流程比较简单分阶段、可恢复、明确 reboot/power cyclePyAerial原功能新增 SRS/Hest Data Lake notebookGitHub 自己显示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 hest26.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 数据。这三个新增类型分别大致对应数据含义srs_iq原始 SRS IQsrsSRS 测量结果/标量/RB SNRsrs_hestSRS Channel Estimates也就是说数据链开始真正变成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 IQGPU → Host → Data LakecuPHY API 新增__half2*pDataRxSrs;代码明确说明这是host-pinned buffer for raw SRS IQ GPU - host copy gated on DataLakeSRS RX 会把buf_st_2中的原始 SRS IQ 从 GPU 拷贝至 Host pinned memory然后交给 Data Lake。所以相比 26.126.1 SRS IQ ↓ GPU cuPHY ↓ SRS processing ↓ Hest / SRS report26.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 EstimateSRS 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.cppdApp 看到的 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和replaysynth可以自己产生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 新增两个 Notebook26.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 Model8. 对 WNC O-RU26.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-RUC-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 MemcpyGH200 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 FW28.47.1088并在安装 DOCA /mlnx-fw-updater后要求reboot → make install → FW verifyCX-7 要检查/配置FLEX_PARSER_PROFILE_ENABLE4 PROG_PARSE_GRAPH1 REAL_TIME_CLOCK_ENABLE1 ACCURATE_TX_SCHEDULER1 CQE_COMPRESSION1这一点与你之前碰到的ConnectX-7 Flex Parser / offload unsupported问题尤其相关。也就是说26.1.2 并没有取消 Flex Parser 要求反而把 CX-7 firmware 和这些 mlxconfig 参数正式纳入安装检查流程。因此如果某块 CX-7FLEX_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_NUMS0 1对应两个 BF3 device/dev/mst/mt41692_pciconf0 /dev/mst/mt41692_pciconf1并检查 BF3 FW32.47.1088而且流程明确要求BFB install ↓ Full POWER CYCLE ↓ make install ↓ mlxconfig settings ↓ Full POWER CYCLE ↓ make installNVIDIA 特别强调soft reboot 不够。这对于 GH200 安装稳定性来说是一个相当大的改进。12. Spark 的 PTP CPU affinity 也改了26.1PTP_CPU_AFFINITY4默认把 PTP pin 到 CPU 4。26.1.2PTP_CPU_AFFINITY默认不绑定 CPU如果需要再手动指定。这个变化值得注意。特别是在 Spark 上如果有isolcpus nohz_full RT thread cuPHY worker ptp4l phc2sysCPU affinity 配置不合理很容易引入 latency spike。13. 安装方式发生了明显改变以前文档倾向makepreparerebootRU_MACxxxmakeall26.1.2 明确改成分阶段、可恢复安装。SparkmakepreparerebootmakeinstallrebootmakeinstallRU_MACxxxmakebuildRU_MACxxxmakestart_allGH200 则还需要 cold power cycle。这个变化说明 NVIDIA 已经意识到Kernel DOCA GPU Driver NIC FW mlxconfig PTP Services之间存在重启依赖不能简单一个make all从头跑到底。14. 还有一个容易忽略的重要变化Data Lake 不再只有一个工作线程26.1datalake_thread26.1.2datalake_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 相关问题。
