SageMaker HyperPod 多区域训练在缓存预热后实现与本地一致的吞吐量

Amazon Web Services 表示，尽管从另一个 AWS Region 读取数据集，SageMaker HyperPod 多区域训练在短暂缓存预热后实现了与本地相当的吞吐量。这一结果挑战了一项常见的基础设施原则：将昂贵的训练算力部署在数据旁边，否则就要接受更慢的输入性能。

该架构将 Amazon SageMaker HyperPod 与 Cloud Native Qumulo（CNQ）结合使用。HyperPod 运行训练集群，而部署在算力附近的 Qumulo spoke 会读取位于其他位置的 Qumulo hub 中的数据。Qumulo 的直读缓存层 NeuralCache 会逐步将被频繁请求的数据移至更靠近训练工作节点的位置。

当主数据集附近缺少合适的加速器容量时，这种分离方式为基础设施团队提供了另一种应对方案。不过，已发布的验证结果来自 AWS 和 Qumulo，而非独立基准测试。其实际价值取决于工作负载的复用情况、网络成本、安全要求，以及缓存预热前的表现。

SageMaker HyperPod 多区域训练将 GPU 与数据分离

关键变化不在于远程文件访问本身，而在于其宣称：经缓存的远程访问可以在不持续损失吞吐量的情况下支撑训练。

AWS 于 2026 年 9 月 25 日发布了这一多区域训练架构。该设计将 SageMaker HyperPod 集群和一个 CNQ spoke 部署在同一 Region，而包含训练数据集的 CNQ hub 则保留在另一个 Region。

Qumulo Cloud Data Fabric 连接 hub 和 spoke。位于算力侧的 spoke 会向训练进程提供所需文件，同时 NeuralCache 获取远程数据块，并将可复用数据保留在更靠近集群的位置。应用程序可以继续采用面向文件的访问模式，无需围绕独立的手动传输流程重写。

该参考架构还使用 Amazon EKS 作为编排器。EKS 提供托管式 Kubernetes 控制平面，而 HyperPod 则提供面向大规模机器学习工作负载的基础设施。AWS 将 SageMaker HyperPod描述为一项用于预置和运营模型开发集群的服务。

同区域测试将 HyperPod 集群和 Qumulo hub 部署在同一 Region。远程测试则将 spoke 放置在 HyperPod 旁边，同时将 hub 和源数据保留在其他位置。因此，权威数据集所在位置成为关键变量。

AWS 表示，本地测试维持了超过 1.0 GBps 的吞吐量。在远程运行期间，随着缓存填充、读取延迟下降，吞吐量最初逐步提升。预热完成后，据称远程配置达到了与同区域配置相同的吞吐量。

这一过程比单一峰值数字更重要。未缓存的读取仍必须跨越区域边界，因此距离并未消失。系统所做的是在 NeuralCache 填充 spoke 后，尽量从重复读取中消除这段距离的影响。

这是一项关于机制的主张，而非宣称每个远程数据集都会像本地存储一样运行。反复访问相同分片的训练作业，为缓存提供了可保留的有价值内容。以唯一、一次性读取为主的工作负载，则能从中获得的收益要小得多。

该架构也不会在算力开始工作前迁移整个数据资产。对于过大、过于活跃，或在运营上过于重要而无法为每个训练位置复制的数据集，这一区别尤为重要。spoke 可按需填充，而不必提前完成整份复制。

传统的数据预置仍然是一种有效替代方案。团队可以将训练语料复制到目标 Region，完成验证后运行作业，并在之后移除副本。这种方法提供了可预测的本地性，但也增加了准备时间、同步工作和另一套数据集生命周期管理。

SageMaker HyperPod 多区域训练提出了另一种权衡。团队以接受预热期和更分布式的存储路径为代价，换取更快的部署灵活性。其吸引力在于，无需完整迁移即可获得接近本地的稳态吞吐量。尚未解决的问题是，真实工作负载能否稳定达到这一状态。

稀缺的加速器容量让位置灵活性更具价值

该架构冲击了这样一种假设：数据所在位置必须决定每个训练集群的运行地点。

大规模训练计划依赖的不只是加速器规格。团队还需要足够数量的兼容实例、网络容量、编排支持、存储性能以及可接受的部署窗口。当数据集无法随之迁移时，位于错误 Region 的合适实例系列可能在运营层面毫无用处。

当预留资源、内部截止日期或区域供应限制排程时，这个问题会变得更加昂贵。团队可能在一个 Region 获得算力，而经批准的数据环境仍位于另一个 Region。通常的选择是等待、预置副本，或重新设计数据路径。

Qumulo 跨区域训练引入了第四种选择。训练集群可以在可用容量附近启动，并通过区域 spoke 获取数据。源数据仍与 hub 关联，而缓存则在算力侧吸收重复读取。

这一选择并不会让 AWS 上的容量在不同 Region 之间完全可互换。HyperPod 的可用性、受支持配置、网络、配额和组织控制仍因 Region 而异。该架构仅放松了一项依赖：主数据集和训练集群必须位于同一地点的要求。

其价值不仅限于紧急部署。组织常常集中管理数据集，因为将其复制到多个环境会增加治理复杂度。即使另一个 Region 有可用容量，不同研究团队也可能竞争同一区域的基础设施。

按需填充的缓存可以减少为每个潜在集群旁永久保留完整副本的需要。这使得该设计适用于拥有大型共享语料库、周期性训练任务和不断变化的算力位置的团队。当每项作业都已稳定地在数据旁运行时，它的吸引力则较低。

这种压力首先落在“先复制、后计算”的工作流上。这些工作流将区域预置视为前提条件，可能造成训练开始前的闲置时间。它们还需要制定版本控制、同步、验证、保留和删除规则。

当源数据仍在持续变化时，复制的数据集可能会过时。运营团队随后需要快照或其他一致性控制，以确保每个工作节点看到预期版本。远程文件数据架构并不会消除一致性要求，但可以减少需要分别管理的完整副本数量。

该设计也对与单一算力位置紧密绑定的存储架构形成压力。如果客户能够将训练容量接入分布式数据层，存储本地性就会成为策略和缓存决策，而不再必须是原始数据集的固定属性。

Amazon EKS 的相关性在于，它在训练环境周围保留了熟悉的 Kubernetes 运营模式。EKS 架构将托管控制平面与客户工作节点基础设施分开。HyperPod 则围绕该编排层构建机器学习集群运营能力。

因此，实际买家并非寻求一个简单训练按钮的用户，而是已经在管理区域限制、Kubernetes 资源、数据访问策略和昂贵加速器的基础设施组织。即使模型代码保持不变，对这类团队而言，部署灵活性也可能至关重要。

不过，仍存在一条战略边界。一旦字节跨入另一个 Region，数据驻留就不再等同于数据存储位置。源数据集可以保持锚定于 hub，但缓存内容会存在于算力旁。安全和合规团队必须直接评估这一差异。

这条边界意味着，该架构不能成为应对数据驻留限制的通用方案。无论权威副本保留在哪里，某些政策都禁止跨区域传输、处理或缓存。团队必须先梳理实际数据路径，才能将该设计描述为保留数据驻留要求。

NeuralCache 将重复读取转化为接近本地的吞吐量

NeuralCache 之所以关键，是因为它会随时间改变远程路径，将重复的跨 Region 读取转化为更近的缓存命中。

冷路径始于训练工作节点请求 spoke 尚未持有的数据。系统从远程 hub 获取该数据，将其传递给请求工作负载，并将符合条件的内容保留在集群附近。首次请求仍会受到跨 Region 延迟和带宽的影响。

后续请求可使用 spoke 中的缓存数据。缓存命中避免再次进行完整的远程获取，并缩短存储与算力之间的有效路径。随着更多活跃工作集到达，聚合吞吐量可能上升，读取延迟也可能下降。

这解释了为什么已发布图表显示的是爬升过程，而非立即达到一致表现。AWS 表示，在冷启动期间，spoke 的输入输出操作和吞吐量均有所提升。随着 NeuralCache 积累工作数据，读取延迟随之下降。

预热完成后，据称 spoke 维持了与同区域运行中 hub 相同的吞吐量。这正是 SageMaker HyperPod 多区域训练主张背后的核心结果。它表明，稳态训练可能受限于本地路径，而非持续的跨区域获取。

这一机制依赖时间局部性，即最近访问的数据很可能再次被访问。训练工作负载通常会跨多个 epoch 重访样本、重新打乱数据，或复用常见工件。这些模式可在首次遍历后让直读缓存受益。

不过，并非每条流水线都会以相同方式重复数据。流式摄取、激进的数据增强、频繁变化的数据集和单次预处理，都可能降低缓存命中率。持续请求未见数据的作业，仍会持续承担远程访问成本。

缓存容量带来了另一项限制。如果活跃数据集远大于可用缓存容量，有价值的数据块可能在复用前被逐出。性能随后将取决于替换策略、访问顺序、分片布局以及重复读取之间的间隔。

并行工作节点既可能放大收益，也可能加剧压力。对热门分片的共享访问可以产生高复用率，使许多请求受益于已填充的缓存。相反，针对未缓存分片的大规模突发请求，可能在启动期间将需求集中到远程链路上。

元数据操作同样值得关注。训练性能并不只取决于大块顺序读取。文件发现、目录遍历、小文件访问、权限检查以及打开大量分片，可能呈现出与持续吞吐量图表不同的延迟模式。

数据格式也会影响结果。较大的连续分片与数百万个小型对象或文件相比，通常会形成不同的输入特征。团队应复现自身的分片、采样、压缩和工作节点并发情况，而不应仅根据聚合带宽进行推断。

同样的谨慎也适用于预处理。当 CPU 预处理成为瓶颈时，可能会掩盖存储延迟。高度优化的 GPU 流水线由于更快地消耗已准备好的批次，反而可能更清楚地暴露输入停顿。

热缓存也有其生命周期。运营人员需要了解缓存数据是否能在作业重启、spoke 变更、节点替换和长时间空闲后继续保留。持久性决定了预热成本是只需支付一次、每个集群一次，还是在日常运行中反复支付。

该架构将准备工作从显性的复制阶段转移为运行时缓存行为。这可以缩短启动作业的路径，但并未消除准备工作。它只是让准备变为增量式、按需驱动，并依赖于实际观察到的读取行为。

这一差异应当指导性能测量。团队需要在完整运行过程中关注冷启动时长、达到稳定吞吐量的时间、缓存命中率以及加速器利用率。仅凭一张稳态带宽图，无法判断初始代价究竟微不足道还是影响显著。

对于长时间训练任务，短暂的预热可能会被总运行时间稀释。对于短期实验、评估任务或频繁重启的流水线，同样的预热则可能主导有效工作时间。因此，评估 NeuralCache 训练性能时，应结合任务时长，而不能只看其最佳持续区间。

远程吞吐量并不消除网络成本或风险

预热后达到与本地相当的吞吐量，并不意味着跨 Region 路径在运营层面等同于同地部署。

AWS 和 Qumulo 的测试验证了特定访问模式下的一种特定配置，并不能证明存在普适性的性能保障。AWS 和 Qumulo 参与了该架构设计与报告，披露的结果尚未得到独立复现。

第一个不确定性在于工作负载的代表性。公布的超过 1.0 GBps 吞吐量提供了有用参考，但模型流水线差异很大。工作节点数量、文件大小、采样顺序、数据增强、epoch 数量和缓存容量都会改变结果。

第二个不确定性是冷启动影响。AWS 将 NeuralCache 预热描述为短暂过程，但团队仍需根据实际作业测量其时长。五分钟对于多日预训练任务与短期迭代实验的意义截然不同。

第三个问题是网络经济性。跨 Region 传输通常属于按量计费的云活动，反复缓存未命中会增加传输字节数。AWS 将其数据传输条款与计算和存储费用分开发布，因此团队必须对完整路径进行建模。

较高的缓存命中率可以在预热后减少重复的远程读取，但无法让初始传输免费，缓存失效也可能导致内容再次迁移。成本分析应包括预热、变动、重试、评估任务和并行集群。

安全控制也会变得更加分布式。spoke 需要获得通往 hub 的授权连接，训练环境则必须落实身份验证、加密、路由、日志记录和最小权限访问。运营人员必须同时检查存储网络与 Kubernetes 环境。

AWS Regions 被设计为具有隔离基础设施的独立地理区域。AWS 在其 Regions 指南中解释了这些边界。在它们之间连接工作负载，会形成一项架构师必须纳入故障分析的明确依赖。

即使本地集群保持健康，Regions 之间的中断仍可能影响未缓存读取。缓存内容或许能让部分作业继续执行，但后续对缺失数据的请求仍可能导致停顿。团队需要测试训练框架会重试、暂停、失败，还是造成进度损坏。

检查点位置也带来了另一项选择。将检查点保存在计算资源附近，可以加快该 Region 内的恢复，但检查点可能仍需复制到其他位置。将它们远程保存能够维持集中化，但会在关键路径上增加另一项跨 Region 依赖。

数据新鲜度可能与缓存复用相冲突。如果源数据发生变化，系统必须确保工作节点不会读取非预期的版本混合。不可变训练快照能简化这一问题；持续变化的语料库则需要更清晰的失效与版本控制。

驱逐行为也可能让运营人员意外。多个作业共享一个 spoke 时，可能会争夺缓存空间，导致不同运行之间的命中率变化。在无竞争缓存条件下进行的基准测试，未必能预测繁忙的多租户环境。

因此，可观测性至关重要。团队应同时监控 hub 与 spoke 吞吐量、读取延迟、缓存未命中、网络传输、工作节点等待时间和 GPU 利用率。即使存储仪表盘显示正常，加速器也可能因应用层排序而供给不足。

运营层面的比较必须涵盖替代方案。完整复制会消耗存储和管理工作，但复制完成后可提供可预测的区域独立性。直接访问对象存储可简化持久化，但需要采用不同的文件或数据加载策略。

部署在计算资源旁的托管文件系统提供了另一条本地路径，尽管它们仍需要进行数据填充。自定义缓存代理可以提供更多控制权，却会将更多工程责任转移给客户。Qumulo 的主张是，其 fabric 封装了这种分布式文件访问与缓存行为。

正确的结论比“数据位置不再重要”要更有限。该测试表明，可缓存的训练读取能够跨 Regions 达到接近本地的稳态吞吐量。这一优势能否在生产环境中延续，取决于缓存未命中、故障、治理和总成本。

Qumulo 跨 Region 训练改变了部署决策

该架构使计算资源部署成为工作负载决策，而不再是数据集所在 Region 的自动结果。

团队传统上会先确定权威数据的位置，再询问附近有哪些可用加速器。Qumulo 跨 Region 训练可以颠倒这一顺序。运营人员可以先确定合适的计算资源，然后再判断活跃数据集能否通过 spoke 提供服务。

当所需实例类型位于其他 Region、另一个 Region 提供可接受的部署窗口，或多个团队需要独立集群时，这种改变很有价值。它还支持临时容量需求，无需为每个位置创建永久的完整副本。

决策仍应从策略开始。如果缓存数据不能跨越区域边界，设计就应止步于此。如果允许传输，团队随后可以评估数据集结构、复用情况、作业时长和预期的缓存工作集。

合理的验证应使用真实训练加载器，而非通用存储基准测试。测试应保留工作节点数量、分片、批次大小、采样、预处理和数据增强。对于以小型或随机操作为主的工作负载，合成顺序读取可能夸大结果。

第一个基线应是实际同地部署的运行。它能够在没有远程依赖的情况下，建立训练吞吐量、GPU 利用率、步耗时和存储行为的基准。第二次运行则应从空的或冷的 spoke 缓存开始。

运营人员应记录远程运行接近基线的速度，以及其是否能够保持稳定。他们还应在缓存驱逐、重启和源数据变化后重复测试。一次成功的热缓存运行不足以证明运营上的可预测性。

故障测试同样重要。团队应中断跨区域连接、更换工作节点、重启训练，并在降级条件下请求未缓存数据。在昂贵作业依赖该架构之前，必须先定义预期响应。

成本评估至少应比较三种完整工作流：完整区域预置、远程缓存访问，以及等待数据集所在位置附近的容量。比较应包括人员时间、重复存储、传输费用、闲置加速器和错过的调度窗口。

模型应区分冷运行与热运行。具有多个 epoch 的工作负载可以将初始传输成本分摊到重复访问中。单 epoch 任务或快速变化的语料库则可能形成截然不同的成本和性能特征。

数据治理同样需要具体的表述。团队应记录缓存字节位于何处、保留多久、谁可以访问，以及删除如何传播。仅仅表示主数据集仍位于其他位置，并不能回答这些问题。

该架构还可能影响组织所有权。存储团队可能管理 hub 和 fabric，而机器学习平台团队管理 HyperPod 和 EKS。对于缓存容量、事故处理、版本控制和性能目标，需要设立共享服务边界。

开发人员应尽可能少地感知这些复杂性。理想情况下，现有训练代码只需挂载预期文件路径即可正常运行。平台团队仍需公开缓存状态和已知故障模式，以便开发人员正确理解较慢的启动过程。

这正是 SageMaker HyperPod 多区域训练超越单纯存储功能的地方。它结合了集群部署、Kubernetes 编排、网络设计和分布式数据访问。只有当这些层作为一条受支持路径协同运行时，收益才会出现。

其主要竞争对手并非某个单一云产品，而是成熟的“先复制、后计算”路径。该路径在预置完成后更容易理解，而缓存路径则优先提供灵活性和更快获取远程容量的能力。

没有任何一种路径适用于所有数据集。稳定且被反复读取的语料库更适合缓存；小型数据集可能更易于复制；高度受监管的数据可能要求同地部署；频繁变化的输入则可能降低复用程度，从而使其他架构更具优势。

三个信号将表明该结果能否普适

下一项测试是：生产工作负载能否复现热缓存结果，同时不掩盖不可接受的启动、成本或可靠性代价。

第一个信号是独立的工作负载数据。客户或技术合作伙伴需要公布使用不同数据集规模、文件布局、工作节点数量和训练框架的结果。最有价值的报告将包含完整时间线，而不只是预热后的吞吐量。

这些时间线应展示冷阶段、过渡阶段和稳定阶段，并将存储吞吐量与训练步耗时和加速器利用率配对。只有模型训练循环也匹配本地基线时，带宽匹配才有意义。

如果多个适合缓存的工作负载在可预测预热后都接近同地性能，独立结果将增强这一主张。较大的差异则会缩小该架构的适用范围，表明已公布的结果高度依赖访问模式或调优方式。

第二个信号是围绕 NeuralCache 的运营细节。团队需要更清晰的缓存容量、驱逐、持久性、预热、失效、监控和故障恢复指导。这些控制措施决定热缓存行为是否可重复，而非偶然发生。

预热对于短期作业尤其重要。如果运营人员能够识别所需分片，并在加速器开始消耗计费时间前填充它们，该架构将更容易纳入调度。如果预热只能在训练期间进行，其成本就仍与昂贵集群绑定。

缓存可观测性还必须将存储事件与模型性能关联起来。一个有用的运行视图应将命中率和远程获取与工作节点停顿和 GPU 利用率建立关联。缺少这种联系时，团队只能看到症状，却无法定位瓶颈。

第三个信号是更广泛的区域和生产环境采用情况。AWS 和 Qumulo 需要证明，这一模式能够适用于受支持的 HyperPod 配置以及真实的网络环境。客户案例研究应说明为何选择远程集群，以及它替代了哪种方案。

如果团队利用该设计获得原本无法使用的计算资源，且没有反复出现性能问题，那么采用情况将强化文章的核心判断。采用有限则可能表明，合规要求、数据传输成本或运维复杂性超过了部署位置带来的收益。

团队还应关注其他训练平台周边是否出现类似方案。分布式缓存、复制式对象层和数据编织架构都在探索不同版本的计算与数据解耦。竞争对手的响应将印证，区域部署已成为更广泛的基础设施议题。

现有结果已经确立了一个可信的技术方向。据报道，当其工作数据变热后，远程辐射节点的表现可与本地中心节点相当。这一点意义重大，因为它表明，缓存可以成为连接集中式数据与区域受限加速器的实用桥梁。

但这并不能决定采购方案。已发布的基准测试仍需在不同的数据加载器、冷启动条件、故障场景和成本模型下复现。生产环境证据必须证明，稳定状态持续的时间足以证明分布式路径的合理性。

对基础设施团队而言，眼下的行动很直接：针对一项有代表性的训练任务，分别在冷缓存和热缓存条件下进行基准测试。测量每秒训练步数、GPU 利用率、数据传输和恢复行为。这些证据是否足以支持你将下一个集群迁向可用容量，同时让源数据集保持在原处？