VAST Data 押注 AMD Blocks，挑战 Nvidia 对 AI 基础设施的掌控力

VAST Data 已将与 AMD 的合作扩展至六个基础设施层面，使 amd blocks 成为对以 Nvidia 为核心的 AI 系统的直接挑战。

这项协议将 VAST 的 AI Operating System 与第六代 AMD EPYC 处理器、Instinct GPUs、Helios 机架、Pensando 网络、ROCm 软件和共享推理存储连接起来。VAST 还将在下一代 CBox 和 EBox 硬件中采用 EPYC 芯片。

这一合作范围的意义，远不止又一次兼容性公告。VAST 已与 Nvidia 及部署 Nvidia 加速器的云服务商保持紧密合作，如今正构建一条从存储数据直达生成 token 的 AMD 路径。

这一转变反映出 AI 支出的更广泛变化。训练依然重要，但企业日益需要支撑持续推理、推理型智能体和基于检索应用的基础设施。这些工作负载会反复在存储、内存、CPU 和 GPU 之间移动模型、提示词和可复用上下文。

AMD 提供计算组件，VAST 则希望协调围绕这些组件的数据。如果这套设计能在生产负载下发挥作用，采购方将获得比 Nvidia 一体化基础设施模式更完整的替代选择。

核心问题不在于 AMD 能否推出高速加速器，而在于 AMD 及其合作伙伴能否让整个 AI 系统像一个产品般协同运行。

AMD Blocks 合作超越 GPU 支持

VAST 将 AMD 视为基础设施根基，而非在销售周期末尾新增的加速器选项。

此次扩展合作在 AMD 于 7 月 22 日至 23 日在旧金山举办的 Advancing AI 2026 活动前后披露。双方描述了一个适用于训练、推理、强化学习和智能体 AI 的通用平台。

首项承诺涉及 VAST 自身的一体机产品。此前代号为 Venice 的第六代 EPYC 处理器，将为第六代 VAST CBox 系统和第三代 EBox 系统提供动力。

CBox 系统在 VAST 架构中运行数据服务和元数据操作。EBox 系统则提供底层存储容量和数据路径。将 EPYC 处理器纳入两条产品线，使 AMD 在 VAST 平台内部占据一席之地，即使客户使用其他加速器也是如此。

新一代 EPYC 支持 PCI Express 6.0。这一互连技术的理论带宽是 PCI Express 5.0 的两倍，可改善处理器、存储、网络设备和连接加速器之间的数据传输。

VAST 表示，额外带宽应有助于其文件、对象、数据库、数据仓库和事件流服务。不过，应用性能仍将取决于软件行为、队列深度、网络设计和工作负载并发度。

合作还涵盖与 DriveNets 共同开发的 AI Infrastructure Reference Architecture。该设计结合 VAST AI OS、AMD Helios 机架级系统和 DriveNets AI Fabric 网络。

参考架构是一种有文档记录的部署模式，包含组件选择、规模配置建议和经验证的连接方式。它能减少设计工作，但并不能证明每种客户工作负载都能达到相同的性能目标。

计划中的指导范围覆盖模型训练、推理、强化学习和键值缓存工作负载。键值缓存通常简称为 KV cache，用于存储语言模型在生成后续 token 时可复用的注意力数据。

TensorMesh 和 EmbeddedLLM 正参与额外的推理工作。它们的参与使该项目不止于处理器认证，也延伸至面向生产级智能体应用的软件部署。

原始报道还列出了七家使用 AMD 相关服务的 AI 云服务商：5C、Core42、Crusoe、EmbeddedLLM、Phanos.AI、TensorWave 和 Vultr。

这份客户名单显示已有部署活动，但并未披露各服务商运营的容量规模，也无法证明客户采用了完整的 VAST、AMD 和 DriveNets 设计。

尽管如此，这一系列承诺显然不只是认证标签。AMD 已进入 VAST 的产品路线图、参考架构、推理软件和客户部署叙事。

因此，这项合作形成了一项可衡量的检验。采购方可通过已发布的系统、文档化设计、公开基准测试和生产案例来评估它，而非只依赖关于开放性的笼统说法。

推理将存储上下文转化为计算问题

这项合作此时到来，是因为推理让数据移动成为每次回答关键路径的一部分。

传统模型训练将巨大的计算量集中在计划任务中。生产推理的表现则不同：它要服务大量并发请求、维持用户上下文、检索外部信息，并且往往生成较长的推理序列。

这种模式可能让昂贵的加速器处于等待状态。GPU 或许拥有足够的算力，却仍可能在系统加载模型权重、检索文档或重建先前生成的上下文时停滞。

VAST 认为，推理从根本上说是一个数据问题。这一说法在方向上可信，但在许多部署中，计算、网络和软件调度仍同样重要。

长提示词和多轮对话会扩大与每个活跃请求相关联的 KV cache。将所有缓存条目保留在 GPU 内存中可实现低延迟，但加速器内存有限且昂贵。

删除缓存可以节省空间，却会迫使模型重新计算先前的注意力状态。将选定条目移至主机内存或共享存储，则提供了另一种选择，前提是系统能足够快地将其取回。

VAST 和 AMD 正在测试第三条路径。其集成方案结合 Instinct GPUs、AMD Infinity Context、ROCm 软件和 VAST 存储，以卸载可复用的 KV cache 条目。

该数据路径采用 AMD 的 Pensando Pollara 400 网络接口卡。它通过 TCP 或远程直接内存访问，使用 NFS 在 GPU 内存和 VAST 的 NVMe 存储之间传输信息。

远程直接内存访问，即 RDMA，可让一个系统在 CPU 参与有限的情况下访问另一系统的内存。在合适的网络中，它能降低重复传输时的延迟和处理器开销。

VAST 还计划提供自动化缓存生命周期控制。管理员可应用策略，使包含个人、机密或受监管信息的存储上下文到期并删除。

这一功能应对了缓存卸载一个较少被注意到的后果：一旦短暂的模型状态进入共享存储，它便成为受治理的数据，而非临时 GPU 内存。

企业必须了解是哪个用户或应用创建了缓存、缓存可保留多久，以及其他租户是否能够访问。他们还需要能够跨副本和恢复系统生效的删除控制。

共享上下文可能在多种场景下提升利用率。客户支持智能体可以在数千次对话中复用冗长的产品手册。编码助手则可以在相关任务之间保留代码库上下文。

研究系统可以在多个智能体审查同一证据时保留已处理文档。推理服务可以将不活跃对话移出加速器内存，并在用户返回时恢复它们。

这些场景解释了为何存储厂商正更深入地介入推理软件。它们的角色不再止于将模型检查点送达 GPU 集群。

VAST 的架构名为 Disaggregated Shared Everything，在呈现统一数据空间的同时分离计算和存储资源。该公司表示，该模型支持多种协议、隔离租户和全局命名空间。

这种设计适合需要通过共享基础设施服务众多客户的 AI 云服务商。但它也在存储、网络、运行时和加速器层面增加了更多依赖关系。

VAST 报告了使用 Instinct MI355X GPU 的早期测试。该公司称，相比本地主机内存，远程缓存卸载将首 token 时间提升九倍，token 吞吐量提升 9.7 倍。

首 token 时间衡量模型开始响应前的延迟。token 吞吐量衡量系统在一段时间内生成的输出量，尤其是在并发需求下。

这些数据来自一项特定比较：将缓存卸载至本地主机内存，与通过 NFS 和 RDMA 卸载至远程 VAST 分区相比。它们并非针对 Nvidia 硬件或完整生产环境的结果。

这一区别很重要。这些数字支持的是测试条件下的一种存储机制，并不能证明每个 VAST 和 AMD 部署都将获得九倍提升。

即便如此，该实验揭示了合作背后的机制。双方并非声称存储能让 GPU 本身变得更快，而是试图减少重复工作并让加速器持续保持忙碌。

AMD 需要合作伙伴来对抗 Nvidia 的一体化技术栈

主要竞争是在由合作伙伴共同构建的开放 AMD 系统，与 Nvidia 高度协同的基础设施技术栈之间展开。

Nvidia 的优势不止在于加速器性能。CUDA、网络、系统、库、部署工具和成熟的运维知识，都在降低采购方的使用门槛。

这种既有基础影响着采购决策。选择 Nvidia 的企业通常能够找到经验丰富的工程师、经过验证的框架、托管云容量和现成的部署模板。

AMD 一直通过建设更多周边平台来应对同样的问题。其战略结合 EPYC CPUs、Instinct GPUs、Pensando 网络、Helios 机架和 ROCm 软件。

VAST 填补了这一组合中一个显著缺口。它提供能够为加速器供给数据、保存模型资产、管理推理上下文并支撑模型周边应用的数据服务。

竞争逻辑很明确：如果合作伙伴能将各层整合为连贯系统，AMD 就不必拥有每一层。

这种方式可以保留采购方的选择空间。AI 云服务商如今可能将 VAST 数据服务与 AMD 加速器组合，同时为依赖 CUDA 的工作负载保留部分 Nvidia 容量。

VAST 也能从避免依赖单一 GPU 供应商中受益。由于可用性、工作负载适配性和软件要求不同，其客户越来越希望能够使用多种加速器类型。

该公司并未放弃 Nvidia。相反，其与 AMD 更深入的合作，旨在将 VAST 定位为异构 AI 集群的通用数据基础设施。

这使 amd blocks 战略成为模块化竞争的一种形式。每个模块都有明确角色，但完整系统依赖于厂商之间的标准和工程协作。

AMD 一直在其他领域重复这一模式。其与 Nutanix 的合作结合了 EPYC、Instinct、ROCm、云编排和企业生命周期管理。

AMD 在该协议中承诺进行股权投资并提供工程资金。其商业结构与 VAST 公告不同，但两者都瞄准了寻求替代垂直整合 AI 平台的企业。

AMD 还与 Red Hat、Oracle、Microsoft、主要模型开发商以及推理软件项目展开合作。其软件生态系统涵盖可缩小应用层兼容性差距的框架和模型提供商。

VAST 则从不同层面提供支持。它聚焦于从存储信息到活跃模型上下文的路径，而低效的数据移动可能会抵消更快处理器带来的收益。

AMD 的 Helios 设计进一步提高了门槛。Helios 将 CPU、GPU、网络和软件整合为机架级系统，而非要求客户自行组装加速器服务器。

独立分析师 Steve McDowell 将 2026 年的 Helios 配置描述为：一个液冷机架内配备 72 块 MI455X GPU 和 18 颗 Venice CPU。他的 Helios 分析将 AMD 面临的挑战概括为：把硬件进展转化为可部署的算力规模，以匹敌 Nvidia 的体量。

VAST 和 DriveNets 的参考架构以数据与横向扩展网络围绕该机架构建。两者共同让 AMD 更接近一套可采购的系统，而不只是芯片目录。

不过，模块化也会引入协调成本。客户需要协调一致的固件、驱动程序、网络设置、存储策略、运行时版本、可观测性和支持升级机制。

Nvidia 能够在一个企业架构内解决其中更多问题。基于 AMD 的设计则需要在多家公司之间分配责任。

这正是核心权衡所在。由合作伙伴构建的技术栈提供了灵活性和议价能力，但其运维体验必须接近高度集成平台的一致性。

VAST 可以通过文档化的参考设计和经过验证的配置来减轻这一负担，但无法消除独立供应商之间联合支持的需求。

市场压力将首先落在以 Nvidia 为中心的 AI 云服务商，以及正在规划下一轮扩容周期的企业身上。在继续扩大单一供应商的部署规模前，它们现在多了一种架构需要评估。

这同样给 AMD 带来压力。公开合作关系提高了外界对可用系统、可重复基准测试以及愿意在 Nvidia 环境之外运行高价值工作负载的客户的期待。

9.7 倍结果需要接受生产环境的现实检验

VAST 的缓存基准测试令人鼓舞，但其狭窄的对照基线不足以证明这套组合架构的商业价值。

报告中所称的 9.7 倍吞吐量提升，是在一项基于 AMD 的测试中比较两种缓存放置方法得出的。它既没有比较完整的 AMD 与 Nvidia 系统，也没有披露行业标准基准测试。

许多细节都会改变结果。缓存大小、提示词长度、请求并发度、模型架构、可用主机内存、存储距离、网络拥塞和缓存命中率都会影响性能。

基线的选择尤其重要。本地主机内存听起来比远程存储更快，但在高并发下，容量压力和访问模式可能会颠覆这一预期。

远程 VAST 分区可以在多台服务器之间汇聚容量，并保留更多可复用的上下文。如果本地内存基线经常驱逐有用条目，远程存储或许可以避免大量重复计算。

这是合理的系统收益，但买方仍需明确了解它究竟会在何种条件下出现。

VAST 承认，相对加速幅度取决于底层硬件。计算能力或存储延迟不同的系统，可能会得出不同的比例。

生产工作负载还会混合不同的请求类型。有些对话很短，几乎无法从持久缓存中获益；另一些包含大量上下文，但返回频率过低，不足以证明保留其状态是合理的。

缓存复用带来了另一层不确定性。只有当后续请求能够以低于重新计算的成本复用已存储信息时，卸载才会产生价值。

因此，管理员需要制定准入和驱逐策略。系统必须决定哪些条目值得存储，哪些应留在加速器内存中，以及哪些应被删除。

安全控制同样需要严格审查。存储的 KV 缓存可能编码了提示词、检索文档和先前模型输出中的敏感信息。

自动删除策略有所帮助，但买方仍需要看到关于租户隔离、加密、访问日志、复制、备份行为和可验证擦除的证据。

推理质量也会受到影响。过期或错误关联的缓存可能导致无效输出、跨用户污染，或难以调试的故障。

合作公告描述了生命周期管理，但没有公布完整的威胁模型，也没有说明如何在所有受支持的推理运行时中实施策略执行。

运维责任仍未明确。延迟问题可能源于 ROCm、模型服务器、Pollara 网络、DriveNets 网络架构、NFS 设置、VAST 软件，或应用本身。

参考架构可以定义受支持的版本和诊断流程。客户案例将揭示这些流程是否能在真实事故中奏效。

同样的谨慎也适用于 AMD 更广泛的性能表述。内部测试可以为评估提供方向，但买方应使用自己的模型、提示词、并发度和服务等级目标复现结果。

企业应比较整体系统行为，而不仅是加速器规格。关键指标包括每机架完成的请求数、首个 token 延迟、输出 token 延迟、能耗、缓存命中率、故障恢复能力和工程投入时间。

扩大的合作提到了效率和性能提升，但没有披露客户定价、部署周期或经审计的生产环境节省数据。

对于一项早期架构公告而言，这种缺失很正常。但这也意味着商业结论仍未确定。

只有当多家客户报告可预测的部署与运营结果时，amd blocks 方法才会具备可信度。在供应商活动上进行大型演示固然有用，但可重复性才能建立信任。

VAST 和 AMD 面对的也是一个不断变化的目标。Nvidia 持续改进网络、推理软件、存储集成和机架级系统。

其他存储公司也在争夺同样的 GPU 供给机会。Weka、DDN、Dell、HPE、Pure Storage 以及云原生数据平台都希望在 AI 基础设施中扮演更重要的角色。

因此，客户不止有两种选择。他们可以使用集成式 Nvidia 技术栈、组装基于 AMD 的系统，或运行采用独立数据基础设施的混合型集群。

最终胜出的路线将因工作负载而异。依赖 CUDA 专用软件的公司，可能会接受较少的硬件选择，以降低迁移工作量。

以高并发服务开放模型的 AI 云服务商，可能更看重加速器多样性和共享缓存容量。大型企业则可能会将支持责任和合规控制置于峰值基准比例之上。

这些差异使该公告无法简化为一张 AMD 对比 Nvidia 的记分卡。它是一种架构选择，必须通过针对具体工作负载的证据来证明自身价值。

三个信号将揭示这一策略是否奏效

下一阶段取决于参考系统的交付、可复现结果的发布，以及证明命名合作关系之外的实际采用。

第一个信号是 VAST 下一代 CBox 和 EBox 是否采用第六代 EPYC 处理器并实现供货。已出货的系统将把路线图承诺转化为客户可以认证的设备。

买方应关注受支持的配置、正式上市日期、升级路径和部署指南。广泛可用将强化 AMD 正在成为 VAST 标准平台的说法。

延迟或配置受限则会削弱这一结论，表明该合作在营销层面比产品运营层面更成熟。

第二个信号是扩大的 KV 缓存测试。具有参考价值的披露应包括模型、上下文长度、并发水平、缓存命中率、网络拓扑和延迟分布。

最有力的证据将来自客户自行运行的测试或可复现的基准测试说明。覆盖多个模型和推理引擎的结果，将显示该机制是否能够超越单一受控工作负载而得到迁移。

持续重复的改进将加强将共享存储视为活跃推理基础设施的理由。较小或不一致的收益则会缩小该技术可服务的使用场景。

第三个信号是联合参考架构在生产环境中的采用。已被点名的客户已经显示出对 AMD 算力的兴趣，但完整设计的部署更为重要。

应关注客户是否在一个受支持环境中连接 Helios 机架、DriveNets 网络、VAST AI OS 和基于 ROCm 的推理。他们的运营报告应涵盖利用率、可靠性和上线时间。

客户规模扩大将验证 AMD 由合作伙伴主导、用以回应 Nvidia 集成优势的方案。孤立的试点则表明，单靠技术选择无法克服软件熟悉度和支持复杂性。

AMD 自身的路线图增添了紧迫感。该公司此前将 Helios 的可用时间目标定在 2026 年，并在其数据中心战略中报告 ROCm 的采用率正在增长。

VAST 为这一战略提供了更强的数据层。它也构成了一项严苛考验，因为存储和上下文管理直接处于用户可感知的延迟路径上。

开发者应当关注，因为基础设施选择决定了哪些模型、运行时和优化工具仍具可行性。更好的 AMD 支持能够降低对围绕单一加速器平台设计的软件的依赖。

AI 云运营商应当关注，因为未被利用的 GPU 时间会直接减少可用服务容量。只有当存储和网络成本低于其替代的重复计算成本时，共享上下文才会有所帮助。

企业买方应当关注，因为推理数据存在治理要求。将缓存上下文移入受管理存储可以改善控制，但也会扩大安全边界。

知识工作者将间接感受到结果。如果系统能高效保留有用上下文，助手就能处理更长的项目，而无需反复重建相同的背景信息。

这一结果还取决于应用如何组织源材料。维护良好的 AI 知识库可以在任何基础设施优化开始前改善检索效果。

因此，amd blocks 策略并不是宣称 AMD 已取代 Nvidia。它是一项计划，旨在让 AMD 计算更易作为完整推理系统的一部分进行部署。

VAST 已为该计划投入硬件、软件、网络、缓存管理和参考设计。剩余工作是在多样化、持续的客户需求下进行公开验证。

未来数月，应忽略关于开放性或 AI 工厂的笼统说法。应关注已经出货的 VAST 设备、可复现的缓存结果，以及运行完整架构的客户。

这三个信号将揭示该合作关系能否为 AI 基础设施创造一条可信的第二路径，还是仅仅又一组彼此兼容的组件。