摘要

  • AS398037 登记在 NVIDIA Corporation 名下，可观察到 14 条 IPv4 公告、一个 IPv6 起点，以及从路由路径反推出的七家上游运营商。
  • NVIDIA 自己的 DGX Cloud 与 NVIDIA Cloud Partner 文档，把算力、存储与网络的交付责任写在合作方一侧；公司保留集群组件管理、监控与维护协调。
  • 一个以产品命名的自治系统，证明的是对地址的控制，不是对承载工作负载的设施的所有权。

登记记录：一个产品名和几个具体日期

系统编号写得很直白：ASName 为 NVIDIA-NGC-NSV，持有者为 NVIDIA Corporation，组织编号 NC-1089，状态为在 ARIN 下有效并已分配。该 AS 注册于 2019 年 10 月 14 日，最后一次更新停在 2021 年 3 月 2 日；关联的组织记录注册于 2019 年 9 月 26 日，更新于 2024 年 11 月 25 日，以上字段取自 bgp.tools 公开的复现内容。NSV 后缀指向公司云软件的型号命名，这解释了名字的来历，却没有解释谁运营这张网。

被公告的地址段同样有据可查。IPv4 一侧可观察到 8.44.54.0/24，24.51.5.0/24，聚合段 24.51.6.0/23 及其覆盖的两个 /24（24.51.6.0/24 与 24.51.7.0/24），以及 198.100.160.0/24 到 198.100.165.0/24 和 198.100.171.0/24 到 198.100.173.0/24。IPv6 一侧只有一个起点：2604:1520:1000::/48。公告条数记为 14 条，但一个覆盖两个 /24 的 /23 足以说明，公告条数不是唯一地址块的数量。

这些地址不会自己走进公网。观察到的路径画出七家上游：Arelion（AS1299）、Lumen（AS3356）、Telecom Italia Sparkle（AS6762）、GTT（AS3257）、Cogent（AS174）、PCCW（AS3491）与 Telstra（AS4637）。IPv6 方向只看得见 Arelion。观察站自己的方法说明写得很清楚：BGP 并不编码商业关系，上游标签是从观察到的路径推断出来的，见 bgp.tools 对上游的定义。这是一份工程概率，不是合同清单。

开放对等，和两条 100 Gbps 端口

互联登记补齐了另一块拼图。这张网登记名为 NVIDIA NGC NSV，别名 Nvidia NGC，类型标注为企业网络，范围为全球，声明的对等策略是开放型，不设流量比例、合同或多地接入门槛，见 PeeringDB 的 AS398037 记录。登记显示 IPv4 前缀 30 个、IPv6 前缀 1 个，均按最大预期值填报；互联设施分布在美国、荷兰、英国、新加坡与日本，交换中心连接写了两条：AMS-IX 与 LINX LON1，各 100 Gbps。该记录更新时间是 2026 年 4 月 22 日。

这些字段的含义需要读准。目录里的前缀数字是运营方声明的最大预期值，不是某一时刻观察到的路由数量，所以“声明 30 个”与“观察到 14 条”并不构成矛盾，PeeringDB 运营方指南 把这层区别写成了填报规则。这份目录由用户自行维护：声明开放，并不证明某一条双边会话真实存在；本次取回的对等记录页面在公共交换中心一栏里也没有列出具名条目。

第二个采集点把画面拉宽，而不是推翻它。Hurricane Electric 于 2026 年 8 月 18 日展示的快照记为 13 条 IPv4 起点、1 条 IPv6 起点与十家观察到的对等方，其中 AS286 与 AS1000 并未出现在 bgp.tools 的表格里，见 Hurricane Electric 的 AS398037 页面。差别来自可见度与抓取日期，不属于两种互相矛盾的结论：任何单一采集点都不可能穷尽。

另一层：谁在运营机器

到这里只是一半。另一半是 NVIDIA 自己写的，而且不是写在路由登记里，而是写在产品文档里。

2023 年 3 月 21 日的发布稿提供了按月租用的专用 DGX Cloud 集群，由云服务商承载，最先落地的是 OCI；Azure 承载与向 Google Cloud 扩展，当时被描述为未来计划，见 DGX Cloud 发布公告。同一份公告把价值主张放在“从浏览器即时接入”上，也就是放在界面与软件上，而不是放在机房产权上。

当前的 DGX Cloud 产品页 把这项服务描述为 NVIDIA 的内部环境，用于开发模型、验证架构并通过云服务商与 NVIDIA Cloud Partner 运行生产负载，同时仍保留着面向 AWS、Google Cloud、Microsoft Azure 与 OCI 的市场渠道或私有报价栏目。页面没有说明这些商务段落是否仍然生效，这份含糊属于文档本身，不属于解读。

Run:ai on DGX Cloud 的文档更新于 2026 年 2 月 27 日，说得更具体：订阅使用的是 NVIDIA CSP 合作方提供的 GPU 容量；NVIDIA 管理集群组件，监控由 CSP 承载的算力、存储与网络，管理 Kubernetes，并与 CSP 协调维护与升级，见 Run:ai on DGX Cloud 文档。NVIDIA 真正运营的部分就在这里，而且是软件平面的运营：必须有人盯着集群，那个人正是同时收取订阅费的品牌方。

《NVIDIA Requirements for AI Clouds》2.4 版，日期为 2026 年 9 月 1 日，用接近合同的措辞划出边界：NVIDIA Cloud Partner 是负责交付并运营相应算力、网络、存储与托管服务的云服务商；文件同时把 NCP 环境中的 DGX Cloud 集群，与 NVIDIA CorpIT 以及 NVIDIA 自有本地对象存储区分开来，并对后者提出私有互联要求，见 AI 云要求文档。

Slurm 集群管理指南又补上区分“供应商”与“最终运营者”的那一笔：在该配置下，由 NVIDIA 提供并配置集群，而集群的管理与运营责任落在客户一侧，NVIDIA 管理的是 CSP 账户、基础设施资源，以及客户之间算力、网络与存储的隔离，该指南收录在 DGX Cloud 文档 中。

设备不等于网络

还有第三块常被混进来的拼图。Spectrum-X 描述的是以太网交换机与 SuperNIC，具备自适应路由与基于遥测的拥塞控制，用于 GPU 之间的通信；Spectrum-XGS 把该平台延伸到分布式数据中心之间，见 Spectrum-X 产品页。这是设备与软件能力，不是关于谁拥有客户网络的一句话，也不会把交换机厂商变成线缆产权人。

为什么这个区分会改变采购判断

评估 AI 基础设施的读者，需要逐层检验控制权。在地址层，NVIDIA 持有一个全球自治系统，有已登记的地址段、七家推断上游与开放的对等姿态，其中包括两条位于欧洲最繁忙交换中心的 100 Gbps 端口。在设施层，它自己的文档把算力、存储与物理网络交给 CSP 与 NVIDIA Cloud Partner，只保留软件管理、监控与协调。地址持有者与机房运营者不是同一方。

实际后果是一个合同问题：你买的到底是哪一个角色，你又替谁承担了哪一个角色。更换软件平面的供应商，和更换机房运营者，是两件不同的事，成本不同，凌晨三点出故障时的责任人也不同。反向的误读同样存在：因为 NVIDIA 不运营所有机房，就断定它什么都不运营，也是错的。它管理集群，监控由第三方承载的资源，运维着一个有国际存在的自治系统；它没有把那个 AS 变成自有骨干网的证据。

公司在 BTW 名录中的 NVIDIA Corporation 条目 汇总了身份与登记信息，便于把地址持有者与其余业务对照起来看。

证据边界

ARIN 返回的登记文档使用本次复核无法渲染的响应类型，因此文中的 AS 与组织字段来自第三方复现，而非直接读取登记库。DGX Cloud 页面上面向 AWS、Google Cloud、Microsoft Azure 与 OCI 的商务栏目是否仍然生效，文档本身没有给出答案。开放对等声明不构成任何具体双边会话的证明。上游身份是从观察路径推断的，不是合同。各合作方承载份额与当前采购资格未获核实。