Upscale 于 2026 年 10 月 8 日发布 Token Fabric,将 AI 计算组内部的网络与数据中心范围的网络纳入共同架构。对于考虑采用多个供应商加速器的团队,这一方案旨在简化网络集成与运维。目前适合开展验证:Upscale 的公告将正式普遍供货时间定在 2027 年初,并表示早期访问和联合验证项目正在进行。
The Next Web 于 10 月 8 日报道了这次发布。事件与报道发生在同一天,但这里的“发布”不代表完整系统已经普遍供货。公司公布的是产品组合和部署方向,客户仍需为自己的硬件与工作负载组合取得证据。
两类网络承担不同的通信任务
Scale-up 连接紧密协同的计算组内的加速器,scale-out 则在更大的集群中连接这些计算组。区分两者很重要:能够正常传输常规流量的网络,未必适合 AI 工作负载中频繁、紧密同步的数据交换。
Upscale 的scale-up 产品说明将 SkyFabriX 芯片定位于同步工作负载。其scale-out 系统使用 Nvidia Spectrum-X 交换芯片和基于 SONiC 的网络操作系统。根据发布公告,Token Fabric 还加入 SkyOS 作为共同软件基础,以及负责编排和可观测性的 SkyCMD。
开放的加速器互连涉及的也不仅是一根熟悉的线缆。UALink 联盟介绍了加速器之间的直接加载、存储和原子操作。这类通信让处理器通过互连访问数据,或执行不可分割的更新。因此,部署规格需要明确支持的协议及其实际实现版本。
统一运维不意味着芯片可以直接互换
Upscale 表示,其架构支持不同厂商的加速器和网卡。这是供应商对网络能力的主张,不能证明为一种加速器编译的应用无需修改便可运行在另一种加速器上,也不能证明混合集群能达到同构集群的性能。
实际吸引力在于减少彼此独立的运维边界。团队可以研究:一个管理层是否能让两个网络范围之间的故障更容易定位。相应的约束是集成责任仍然存在,驱动程序、通信库、工作负载调度和故障恢复仍须协同工作。这些是试点的验收问题,并非本文取得的 Token Fabric 实测结果。
明确联合验证需要证明什么
有效评估应先确定加速器和网卡的具体型号、协议版本、软件栈与拓扑,再运行目标工作负载。除了应用吞吐量、通信延迟和链路故障后的恢复表现,还应记录诊断所需的工具。将结果与现有集群比较,比接受针对整个架构的性能承诺更有参考价值。
另一类基础设施约束可参见 TechKili 对CoreWeave 印度容量计划的报道,其中分析了规划中的园区何时可能投入使用。Token Fabric 提出互补的问题:集群内部的计算设备将如何通信。园区公告或网络路线图都不能独自证明部署已经就绪。
下一项有意义的证据应是得到支持且有完整文档的配置,以及可以重复的工作负载结果。在此之前,早期访问可帮助工程团队验证需求,却不足以将宣传中的所有多厂商组合都视为可投入生产。
来源
本文依据公开文档撰写。TechKili 未独立测试 Token Fabric;上述试点标准属于编辑分析。