NVIDIA Nemotron 3 Ultra 在代理式RTL编码的准确性和效率上领先开源模型

现代芯片设计受限于工程时间，RTL 开发与验证需要专业硬件知识、精确推理以及与 EDA 工具的反复交互。LLM 加速了代码生成，但 AI 代理通过利用验证反馈进行迭代纠错，进一步扩展了其影响。对于 RTL 而言，正确性依赖于精确的时间行为，许多错误仅在基于工具的验证中才会暴露。

ACE-RTL 代理采用生成-测试-反思的迭代工作流：生成器产生或更新 RTL 代码，反射器分析仿真反馈并识别根本原因，协调器跨迭代维护不断演化的调试上下文。这种设计使代理能够从先前的失败中学习，而非重复类似错误。

在包含九类 RTL 任务的 CVDP 基准测试中，ACE-RTL 代理搭配 Nemotron 3 Ultra 实现了 97.1% 的平均通过率，高于 Kimi K2.6 的 95.2% 和 GLM 5.2 的 92.1%。Nemotron 3 Ultra 在多个类别中达到 100% 通过率。

更重要的是，Nemotron 3 Ultra 在实现最高精度的同时，Token 消耗显著更低：每次迭代平均 6,629 个 Token，比 GLM 5.2 的 9,156 个少 28%，比 Kimi K2.6 的 22,579 个少 71%。这种高精度与低 Token 成本的组合，使得在相同计算预算下可以尝试更多 RTL 任务，工程师也能更快获得结果。

Nemotron 3 Ultra 是一个 550B 总参数、55B 活跃参数的混合 Mamba-Attention MoE 模型，专为长时间运行的代理设计。它基于 20 万亿文本 Token 预训练，支持 1M Token 上下文长度。混合 Mamba-Attention 架构通过减少注意力成本和 KV 缓存占用提高了吞吐效率，MoE 设计则提升了每活跃参数的精度，相比其他开放模型可实现高达 5 倍的吞吐量和 30% 的成本降低。

对于 RTL 工作流，效率至关重要，因为代理上下文会迅速增长。单次调试迭代可能包含规格说明、模块代码、生成的 RTL、仿真输出、断言失败以及先前的修复尝试。高效的上下文推理直接影响这些代理在实际工程中的实用性。

Nemotron 3 Ultra 的 RTL 能力得益于 ACE-RTL 论文中提出的合成数据生成流水线。该流水线旨在创建高质量的 RTL 训练数据，反映硬件工程师和 RTL 代理的实际工作方式：不仅从规格生成代码，还包括修改现有实现和调试失败设计。