Amazon Trainium 训练借助原生 PyTorch 挑战 Nvidia

Amazon 于 10 月 20 日推出了对 Trainium 的原生 PyTorch 支持，通过研究人员已在使用的工作流挑战 Nvidia 在训练软件方面的优势。Amazon Trainium 训练现已提供名为 TorchNeuron 的公开测试版后端，这一软件组件可将 PyTorch 模型代码连接到 Amazon 的加速器。PyTorch 是开发者用于定义、训练和运行模型的框架。

这一变化之所以重要，是因为训练硬件竞争的不只是计算能力。研究人员需要修改模型、检查故障并重复实验，而无需围绕陌生设备重建软件。Nvidia 的 CUDA 平台——其用于加速计算的编程环境——仍是这一体验的参照标准。

10 月 23 日，SemiAnalysis 的一项评估提供了令人鼓舞的实操证据，同时也指出了编译延迟和兼容性尚未完善的问题。当前的竞争焦点在于，Amazon 能否让 Trainium 适用于日常研究。这并不能证明 Amazon 已在各类训练工作负载上超越 Nvidia。

Amazon Trainium 训练获得原生 PyTorch 路径

Amazon 正在改变研究人员与其芯片之间的软件契约。

AWS 的 TorchNeuron 公开测试版支持 Trainium2 和 Trainium3 实例。该公司表示，开发者可以选择 neuron 设备，同时保留标准 PyTorch 接口。它还通过 Neuron Kernel Interface 支持自定义算子；后者是 Amazon 用于编写设备特定计算例程的接口。

这一发布解决了一个实际障碍：研究人员理解的模型与他们必须适配的硬件栈之间的距离。如果采用某个有前景的加速器意味着必须维护一套独立版本的实验，它的吸引力就会下降。

原生集成改变了这种适配发生的位置。理想情况下，硬件后端会吸收更多设备特定工作，让研究人员更接近自己原有的模型定义。这为 Amazon 进入缺乏专职加速器专家的团队提供了更清晰的路径。

不过，这种表述仍需谨慎。原生支持描述的是一种集成方式；它并不保证在每一项操作、库或工作负载上都有完全一致的行为。公开测试版也意味着，开发者应预期受支持的范围会持续演进。

对研究团队而言，关键区别在于启动一项实验与维持一项研究计划。启动要求模型能够加载并执行；维持则要求架构变更、调试、评估和软件更新始终可控。

如果这些后续活动不再需要付出异常多的努力，Amazon Trainium 训练就会更具竞争力。一次成功演示可以建立切入点；反复进行的常规实验，则决定这一切入点能否成为可靠的工作环境。

设想一个示例团队正在修改语言模型的注意力机制，即决定哪些信息会影响每次预测的组件。团队需要将修改后的方案与基线进行比较。其硬件选择不应变成另一个独立的研究项目。

这一例子解释了为何该发布的影响超出了基础设施专家的范畴。研究人员选择工具，部分取决于这些工具允许他们尝试何种实验。因此，硬件兼容性会影响团队能够在现有时间内研究的问题。

对企业买家而言，其含义同样具体。采购比较应包括维持工作负载健康运行所需的工程工作。当软件工作量使实验变得不切实际时，设备可用性本身意义不大。

因此，眼下的变化是向更多团队发出评估 Trainium 的邀请。AWS 为这一评估提供了熟悉的接口。团队是否会留下来，取决于该接口之下的实际表现，尤其是在其代码偏离预先准备的演示时。

Nvidia 在研究人员投入时间之处面临压力

竞争切口在于迁移研究所需的投入，而非某项孤立的硬件评分。

Nvidia 是这一故事中的主要对手，因为 Amazon 正在针对围绕 GPU 训练形成的软件习惯。GPU 是专为并行计算设计的处理器。研究人员评估的是其周围完整的工作环境，包括调试、库和团队积累的知识。

这些投入构成了继续使用现有平台的强大理由。组织了解哪些故障属于常规问题、哪些变化需要谨慎处理，以及内部专长位于何处。更换硬件可能会打破这种理解。

Amazon 的方法直接针对转换负担。如果研究人员能够保留熟悉的接口，他们在测试前就拒绝替代方案的理由会更少。即使买家尚未决定哪个平台表现更好，这也是一种竞争优势。

因此，Nvidia 面临的压力是明确的。AWS 正试图让硬件评估对研究流程的干扰更小。Nvidia 必须持续赢得那些拥有更易接触替代方案的团队的偏好。

这种压力不应被误解为即时迁移预测。实验室可以在保留现有 GPU 基础设施的同时研究 Trainium。评估扩大了可选项，但并不能说明最终会有多少工作迁移过去。

TorchTitan 是 PyTorch 用于组装大规模训练工作流的框架，可作为一个有用的参照点。其项目描述了模块化模型定义和可配置的分布式执行，即将计算分布到多个设备上。这使其与正在调整现有训练基础的研究团队相关。

战略价值在于保留这种基础。团队不希望每次硬件实验都为其科学工作创建一个永久分支。实现方式越接近，结果就越容易比较。

这也是为什么推理成功并不能自动证明其适合训练。推理是使用训练好的模型生成输出。研究训练则是在开发者探索架构、数据和优化选择时改变模型参数。

服务型工作负载可以从对稳定路径的精心优化中受益。研究型工作负载还需要容忍变化。加速器必须支持供应商未曾专门准备的实验。

对买家而言，这提示了另一种理解竞争的方式。相关问题是，团队利用现有人员和基础设施能完成多少有价值的研究。硬件吞吐量有助于这一结果，此外还有搭建工作量和诊断时间。

如果 Amazon 能减少这些额外负担，它就拥有可信的机会。Nvidia 则在其工作环境能让团队更高效的领域保持优势。竞争结果将随工作负载、软件依赖关系及操作人员的专业能力而变化。

这种差异性使得广泛宣称胜负为时过早。但它也让这一发布具有重要意义：AWS 正在争夺研究人员的工作日，而硬件偏好正是在那里变得持久。

原生 PyTorch 改变实验循环

Amazon 挑战背后的机制，是从修改模型代码到评估其行为之间的路径更短。

AWS 的 原生 PyTorch 后端使用 PyTorch 的标准扩展机制，将 Trainium 注册为一种设备。其文档描述了即时执行——操作会在开发者调用时运行——以及编译执行——软件会在运行前优化已捕获的计算。

这两种模式服务于实验中的不同阶段。交互式执行有助于开发者在想法尚未确定时检查行为。当计算趋于稳定且值得为重复执行进行额外优化时，编译就会更具吸引力。

实际收益来自于在这些阶段之间切换时，无需放弃研究代码。研究人员可以考察一项改动、确认其是否有效，然后再检视性能。支持这一顺序的后端符合实验工作的实际推进过程。

AWS 的文档还说明，为何熟悉的执行方式并不能消除编译成本。此前未见过的操作形状可能需要在首次使用时编译。缓存结果可以帮助后续执行，但首次等待仍属于研究人员的体验的一部分。

这一细节将集成故事与剩余摩擦联系起来。模型在接口层面可能感觉熟悉，但底层却可能产生陌生的停顿。开发者需要在估算可节省多少迭代时间前理解这两个层面。

从这一视角理解 TorchNeuron，它意味着责任的转移。更多适配工作进入后端，而研究人员保留更多熟悉代码。当覆盖范围或性能不足时，设备特定工程仍然是必要的。

同一份文档还区分了不同执行模式下的回退行为。在即时模式下，不受支持的算子可以在 CPU——计算机的通用处理器——上运行，并发出警告。在编译模式下，后端无法翻译的操作则可能导致编译失败。

这一区别在评估一次成功运行时很重要。仅仅完成并不能证明预期的计算始终留在加速器上。一个可运行的实验与一个获得高效加速的实验，是两项不同的发现。

对于一个示例研究团队，评估应遵循其实际执行的工作。标准模型可建立基线。有意义的架构修改则能揭示兼容性是否延伸到预先准备路径之外。

随后，团队可以比较科学结果及获得这些结果所需的工作量。如果修改后的实验行为正确，却需要大量修复，接口改进就只兑现了部分承诺。

Amazon 的软件战略让这种评估更容易尝试。其长期价值取决于后端能否持续处理研究人员所作的那些不规整改动。这正是原生集成与更广泛训练业务之间的联系。

更易接触的起点扩大了潜在用户群。可靠的实验循环则给这些用户留下来的理由。

质量控制必须覆盖正确性与等待时间

训练软件要赢得信任，既要保持结果可靠，也要让实验能够切实重复。

SemiAnalysis 的 Trainium 训练测试报告称，在 16 颗 Trainium2 芯片上，Qwen3-32B 在即时模式下的吞吐量为每秒 11,099 个 token，在编译模式下为每秒 14,156 个。Token 是语言模型处理的文本单位。这些是特定工作负载的测量结果，并非对 Nvidia 的总体比较。

该刊物还报告，其 gpt-oss 训练配方的编译等待时间为 27 分 17 秒。其对 Trainium3 FlexAttention 的评估在 96 个案例中通过了 89 个；其余案例超过了编译时间限制。FlexAttention 是用于定义注意力机制变体的 PyTorch 接口。

这些发现支持一种审慎的解读。该技术栈能够执行实质性的训练实验，但等待时间仍会影响研究可用性。更快的重复执行并不会消除为实现它而花费的时间。

这种区别对于短期实验尤其重要。测试某个想法的研究人员，可能更关心获得初步结果所需的时间。较长时间的运行则可以将准备成本分摊到更多有用的计算工作中。

这意味着性能报告应区分准备、执行和成功完成。将它们合并为一个有利的数字，可能掩盖决定研究人员是否持续使用该平台的体验环节。

正确性带来了另一项要求。模型即使运行很快，若学习结果不同，也需要先展开调查，速度才有价值。数值一致性意味着要检查：在所选精度和测试条件下，计算是否产生足够一致的结果。

AWS 在其 TorchNeuron testing methodology 中描述了大量自动化测试。该公司表示，其模型扫描覆盖了 100,000 个采用精简配置的 Hugging Face 模型，并记录执行、编译和回退行为。这些都是供应商自行报告的覆盖范围声明。

同一份说明称，8 月共记录了约 154,000 个上游测试结果，其中约 69,000 个被跳过。部分跳过遵循 PyTorch 的适用资格规则，另一些则反映了 Neuron 的覆盖决策。列出的初始排除项包括稀疏操作和动态形状。

持续集成，即对软件变更进行自动化测试，在这里十分重要，因为后端改进可能在其他环节造成回归。有效的测试系统会在研究人员于昂贵实验中发现问题之前识别这些回归。

仅凭测试量无法证明可靠性。读者需要了解运行了什么、跳过了什么，以及测试配置与其工作负载的相似程度。广泛的目录扫描无法取代对每个所列模型进行完整训练验证。

最有力的证据应结合透明的覆盖范围报告与可复现的外部结果。AWS 的披露为这种审视提供了材料。SemiAnalysis 的经验则提供了外部视角，其中包括正面发布措辞可能掩盖的问题。

Amazon Trainium 训练应从两个维度进行评估：实验能否正确完成，以及团队能否避免过度延迟地重复这些实验。一个维度上的进展绝不应掩盖另一个维度的弱点。

分析器为 Amazon 提供了另一种竞争方式

即使初始结果令人失望，对缓慢执行有更好的可见性也能让加速器更易于改进。

Neuron Explorer 是 Amazon 的性能分析工具，这类软件会记录执行过程，供工程师调查性能问题。AWS 的 hardware profiling tools 区分系统级活动与设备级活动。它们提供时间线、源代码链接、依赖关系信息和内存视图。

这些功能解决的问题不同于兼容性。一旦模型能够运行，开发者还需要确定它为何在等待。缓慢的步骤可能源于计算、数据移动、通信，或是在加速器之外执行的工作。

总时长只能识别症状。有效的追踪可帮助定位原因。这种差异决定了工程师能否进行有针对性的改动，还是必须通过反复猜测来排查。

例如，一个示例训练任务可能在计算开始前耗时等待数据移动。仅改进算术运算并不会消除这一依赖。清晰的时间线可以将工程师引向真正限制进展的工作。

这也是性能分析器质量应纳入竞争分析的原因。硬件规格描述可用能力。诊断工具帮助开发者将这种能力转化为适用于其特定模型的有效执行。

它与原生集成的联系也很实际。熟悉的模型代码缩短了抵达首次运行的距离。清晰的性能分析则缩短了从首次运行到理解其行为的距离。

这些改进结合起来，处理的是训练周边的工程工作。它们并不保证性能优势，却能让团队更容易发现这种优势是否存在。

“GPU impossible”这一表述需要克制。SemiAnalysis 用它来形容自己对 Trainium 细粒度性能分析体验的热情。这句话不应演变为宣称 Nvidia 硬件缺乏观察计算例程内部活动的方法。

Nvidia 记录了 in-kernel event tracing，这是一种在内核内部记录事件的机制；内核是由加速器执行的例程。它的存在将可成立的比较范围收窄至特定任务中的集成度、可见性和开发者投入。

这仍然是有意义的比较。两个平台可以呈现相关信息，但收集和解读这些信息所需的工作量不同。相关判断在于工程师必须进行怎样的调查。

因此，对买家而言，评估性能分析器应从一个真实且尚未解决的性能问题出发。精美的截图无法证明工具能多有效地帮助团队回答这个问题。能够产生可执行诊断结论的追踪，提供的证据更有力。

分析还应保留诊断与修复之间的界限。知道工作负载为何停滞，并不保证软件或硬件能够消除停滞。更好的可见性能够改善决策，其中也包括拒绝不适合平台的决策。

Amazon 的机会在于让这些决策更快、更有依据。这将增强其训练方案的价值，而无需每种工作负载都给出有利结果。

什么能证明一种持久的训练替代方案

接下来的证据应追踪迭代时间、持续维护的兼容性，以及超出受支持演示范围的采用情况。

未来几个月的第一个信号，是初始编译等待时间出现可复现的缩短。发布公告应与相同模型和有意义的架构变更相对应。否则，更快的结果可能只是反映了不同的实验。

重要的结果是通往可信结果的路径更短。如果准备环节有所改善，而正确性和重复执行仍保持可比，Amazon 的研究价值主张就会增强。如果普通变更后等待仍然存在，原生接口便仍留下了沉重负担未解决。

这一评估应包括首次运行和重复运行。研究人员需要区分缓存编译结果带来的收益，以及能够帮助陌生工作负载的改进。两者都很重要，但回答的是有关日常可用性的不同问题。

第二个信号是能够经受软件更新考验的兼容性。发布时对某一接口的支持只是建立起点。随着研究发生变化，团队需要模型、其依赖项和设备后端继续协同工作。

关注对新增支持操作、剩余排除项和回归问题的透明报告。不断缩短的例外清单将强化这样一种观点：Amazon 正在承担更多适配工作。用户代码中反复出现的修复需求则会削弱这一观点。

在这里，将 TorchNeuron 解释为一种开发策略，比将其视为发布口号更有用。它的价值取决于用户能在多大程度上避免长期的硬件特定维护。接口只是这一承诺的开端。

第三个信号是来自运行多样化训练工作负载团队的详细报告。有价值的说明应解释迁移了什么、哪些地方需要调整，以及哪些部分仍保留在现有基础设施上。它们还应区分常规供应商支持与例外的工程协助。

此类报告将帮助读者判断，这种体验是否超出了预先准备好的方案。独立复现将进一步增强证据。少量演示案例则会让实际采用广度仍不确定。

对不同读者而言，其影响各不相同。开发者获得了另一个可针对实际实验进行评估的环境。企业买家则有理由就迁移工作量和维护提出更精确的问题。

AI 产品用户应预期一种间接影响。更好的基础设施选择可能影响产品团队如何分配工程时间，以及如何推进模型改进。该公告本身并未确立这些用户所接触应用中的任何特定改进。

对于关注这一转型的团队，应将基准设置、软件版本和失败原因与有利结果一并保留。一套可搜索的知识库可以在下一次后端发布改变比较结果时，确保这些证据仍然可用。

从团队熟悉的研究工作负载开始，然后评估从代码变更到验证结果的完整路径。记录准备时间、执行行为、调试投入和维护需求。让比较始终围绕你计划重复进行的工作。Amazon Trainium 训练如今为这项评估提供了更熟悉的路径，而公开测试版也让更广泛的受众看到了仍存的差距。请将兼容性披露与性能结果一并阅读，并随着软件发展重新审视这一决策。有用的问题是：团队能否利用现有资源完成更多可信的实验。请选择能够为你的工作负载证明这一结果的平台。