摘要

  • Volta 于 8 月宣布，今年早些时候收购了 Genesis Cloud 的技术，涉及公共 AI 云和裸金属集群管理软件。公告没有说明所有公司主体、客户合同或网络资产都随之转移。
  • AS209045 在 10 月 19 日的一次核查中没有宣告路由。页面保留的旧前缀和对等网络，不能用来证明当前 GPU 服务的配置、价格或交付状态。

查询 Genesis Cloud 的网络记录，会遇到一个容易看错的数字：两个 IPv6 前缀。它很具体，具体到可以写出完整地址块，似乎比一段云服务宣传更可靠。但同一页面还有另一句话：这个 ASN 自 2026 年 4 月 16 日以来未在全球路由表中可见，部分信息停留在那时。

漏读这句话，就会把一张旧照片当成现场直播。

另一个变化发生在网络记录之外。Volta 在 8 月 4 日的公告中表示，已于今年早些时候收购 Genesis Cloud 的技术，软件覆盖公共 AI 云以及裸金属集群管理。它说明了一部分技术的去向，却没有交代每份客户合同、每台 GPU 或每个网络资源的归属。

两份材料摆在一起，最值得追问的不是“这家云的 GPU 便不便宜”，而是更靠前的一步：眼前的服务究竟由谁提供，报价对应什么资源，出了问题由谁履约？4 月的路由变化与技术收购之间，没有已核实的因果链，不能替它们补上一条。

先把这张网络快照读对

Hurricane Electric 的 AS209045 页面将其标为 Genesis Cloud Limited，来源国家字段为马耳他。历史记录显示，它曾起源两个 IPv6 前缀，没有起源 IPv4 前缀：2a09:7000::/31 与 2a09:7007::/36，两者的标签均为“Genesis Cloud LIR Admin”。页面列出的两个 IPv6 对等网络是 AS13237 euNetworks GmbH 和 AS16276 OVH SAS。

这些名称和地址可以帮助辨认过去的网络关联，不能直接搬进一张“当前供应能力表”。页面另一个字段显示，正在宣告的前缀数为零；它自己也提醒读者，保留了最后可见时的信息。历史上出现过两个前缀，与今天仍宣告两个前缀，是两回事。

新的核查有明确时间点。RIPEstat 的直接接口在 2026 年 10 月 19 日 08:00 UTC 的结果中，将 AS209045 标为未宣告路由，持有人字段为空。同日的 RIPE RDAP 查询返回 HTTP 404，没有提供可据以确认当前登记主体的正面记录。前者支持这个时刻的路由观察，不等于补齐了 4 月以来每一天的历史；后者也不是公司注销证明。

即使路由记录完整而且实时，它仍然不是机房资产清单。两个前缀不能折算成两处机房，不能量出流量，更数不出 GPU。“LIR Admin”是标签，不是地址实际用途的调查结论；出现对等网络名称，也不代表已经看到了转接合同、带宽承诺或客户数据的真实路径。国家字段同样不能单独证明公司注册地和服务器所在地。

因此，能站稳的判断很窄：这里有一个可辨认的历史网络足迹，以及一次带时间戳的未宣告观察。它不足以说明全部服务中断、客户已迁走，或网络资产已交给 Volta。

技术有了去向，合同还需要自己的答案

Volta 的公告补上了旧调查缺失的一块。公共 AI 云软件与裸金属集群管理软件可以被收购、用于新的服务，而不要求某个 ASN 同步转移。软件、网络资源和客户合同本来就是不同的东西。

这也是“技术收购”四个字不能省略的原因。把它写成“收购了 Genesis Cloud 的全部业务”，会额外带入公告未证实的公司主体、硬件和客户义务；把它解释为 4 月路由不再可见的原因，则又多走了一步。

旧稿在 10 月 17—18 日的查询中，没有从 Genesis 网站取得可读的产品条款，也没有取得可用的 RDAP 结果；当时 RIPEstat 落地页的提取同样没有提供有用摘要。这些是当次检索的局限，不是“从未公开过资料”。如今，直接接口给出了路由观察，Volta 则提供了可归属的官方技术收购说明，旧结论必须随证据更新。

10 月 19 日再次访问 Genesis 网站，本次调查仍未取得可读的产品目录。因此，这里不能给出已核实的当前套餐、价格或服务条款。但网页未能读取，也不等于知道它为何无法读取，更不等于掌握了存量客户的服务状态。真正需要补的是文件，而不是对空白的想象。

GPU 小时很明确，完成一项任务却没有那么简单

即便拿到了准确的每 GPU 小时报价，也还没有完成成本比较。小时衡量的是占用资源的时间；买方真正需要的，往往是一次训练完成、一个推理批次处理完，或系统在负载下保持可接受的响应速度。

问题并非所有报价都只包含一块芯片。一个计费单位可能已经打包 CPU、内存等主机资源。需要弄清的是，这个包里究竟有什么，它在目标任务上能做多少有效工作。

数据要先到达加速器。主机内存、存储速度、应用准备输入的方式，都可能影响 GPU 能否持续工作。使用多块 GPU 时，还会多出设备之间交换数据的时间。一块设备上的好成绩，不能自动变成多块设备按比例缩短工期的承诺。

NVIDIA 对 NCCL 的技术说明给出了具体区别：节点内部可以经过 PCIe 或 NVLink，节点之间可以使用套接字、InfiniBand 或 RoCE；通信还会受 CPU、网卡以及设备连接路径影响。这说明为什么配置和放置方式值得问清，并不是 Genesis 采用某种设备的证据，也不是它的性能测试。

更快的互联并非所有任务都值得购买。有的工作通信很少，有的则需要频繁交换大量信息。前者未必能把昂贵互联的优势用出来，后者却可能为等待付出持续计费的时间。脱离任务宣布“PCIe 一定是瓶颈”或“某种互联能快十倍”，都省掉了最重要的测量。

比较应落到同一项工作上：在明确的配置中跑完它，记录耗时、完成量和实际计费资源。这样得到的不是一个漂亮的设备名称，而是一项可复查的结果。

数据怎么走，也会改变账单

硬件测试之外，还有合同问题：哪些传输已包含在价格里？检查点和结果放在哪里？容量预留后没有使用，是否仍计费？这些问题不能靠另一家云的惯例代答。

Amazon EC2 的按需定价页就是一个具体例子。它分别列出实例使用和数据传输规则；传输有额度和例外，符合条件的操作系统按秒计费、最低 60 秒，其他操作系统的规则不同；未使用的按需容量预留也可能产生费用。这能说明为什么需要读条款，不能据此声称 Genesis 采用同样的收费方式。

写一次检查点并不必然产生出站费，每个传入或传出的字节也不必然收费。路径、服务和合同决定它属于哪一项。预留折扣同样需要与利用率一起看：单价下降，如果空置时间增加，完成一项任务的成本未必下降。

就 Genesis 而言，本次调查没有取得已核实的现行目录、独立工作负载测试和当前合同包含项。缺这些材料时，把每小时单价排列出来，只能算比较开始，不能算结论。下一份真正有用的报价，应该写清签约主体、GPU 与主机配置、放置及连接承诺，以及存储、传输和中断条款，再用可重复的任务检验交付。

历史路由告诉人们去哪里继续查，技术公告告诉人们已有哪一部分发生变化。买方最终要拿到的答案却在别处：这项任务由谁承接，多久完成，账单如何形成，未按约交付时找谁负责。两个旧 IPv6 前缀回答不了这些问题。