新模型架构每周都在涌现，但软件编译栈往往滞后。传统上，启用新硬件加速器需要专家数月的工作。

在我们最新的技术博客中，IBM Spyre团队展示了AI编程智能体如何通过编写运行时适配器来弥合这一差距。通过修补不支持的操作并解决内存对齐约束，HF-适配器通过torch-spyre将标准HuggingFace Transformers直接连接到PyTorch。

关键成果包括：13个由AI编写的适配器成功支持了前10,000个HuggingFace嵌入模型中的7,960个，以及6,804个模型在IBM Spyre加速器上通过了完整的端到端设备测试。

阅读完整技术深度解析：https://bit.ly/4wFGMlB

@IBMResearch

利用AI实现首日模型支持 – PyTorch

来源：https://pytorch.org/blog/harnessing-ai-for-day-one-model-enablement/

精选项目

• PyTorch logo (https://pytorch.org/projects/pytorch/)

摘要

AI模型领域永不停歇，而运行这些模型的软件栈总是慢一步：即使在成熟的编译栈上，新模型家族常带有无法良好降级的新颖模块；在新硬件上——当年轻的软件栈首次面对整个生态系统时——差距更为显著。传统上，为每个新模型家族扩展栈支持是缓慢的专家工作，会延迟部署。本文展示AI智能体如何通过在模型工作流与编译栈之间架起桥梁，实现首日支持新模型或整个生态系统。我们展示了这一领域更困难的一端：通过少量AI编写的适配器，我们让标准HuggingFace Transformers模型在IBM的Spyre AI加速器上运行，实现了对数千个模型的完整支持。

问题：追赶不断演变的模型格局

模型领域永不停歇。新架构和检查点不断涌现——每个都是特定的操作、形状和数值范围的组合——而必须运行它们的软件总是慢一步。即使在最成熟、部署最广泛的栈上，全新的模型家族也会带来某些现有软件尚无法妥善处理的新颖模块、融合注意力变体或数值范围。

***模型格局时间线：HuggingFace Transformers库中随时间添加的新模型家族。*每个步骤标记了一个重要模型家族的加入，展示了新架构稳定且加速涌现的步伐。

在任何设备上运行模型都需要软件栈——一个编译器、一组算子降级方案和一个运行时——将其映射到硬件的核心、内存层次结构和数值格式。该软件栈是一个庞大且持续演进的软件，新架构可能触及其中尚未成熟的部分。在那部分完善之前，模型无法运行，或运行效果不佳——而弥合这样的差距传统上需要数周或数月的专家工作。

新硬件是差距最大的地方。新加速器不仅仅是一块芯片：它伴随着一个年轻的软件栈，需要不断适应不同模型的需求。这里并非一个新模型面对一个成熟的栈，而是一整个模型生态系统面对一个仍在构建的栈——而且该栈必须同时跟上在其上运行的新架构。支持工作不能等待栈完善；它应当并行推进，让真实模型在运行的同时，其底层平台得以成熟。

***AI加速器发布时间线。*每个点标记了新芯片的发布日期。新硬件的发布几乎与新模型一样稳定——每个芯片架构都需要一个持续演进的软件栈。

新硬件是极端情况，但这是一个普遍性挑战：无论栈是成熟还是全新，都要让软件与模型格局保持同步。下文我们将描述一种弥合这一差距的策略，并通过一个具体实例进行演示——让标准HuggingFace Transformers模型在IBM Spyre加速器上运行。

策略：适配器作为模型与栈之间的桥梁

我们描述的策略是一层轻量的运行时补丁——适配器——它允许标准模型在今天就能在给定平台上运行，而无需等待底层栈中的每个差距被弥合。我们假设平台已提供一个PyTorch编译器，能将标准torch代码中的核心张量运算（包括矩阵乘法、逐元素操作和归约操作）降级到目标硬件上，因此大部分模型逻辑可以原样运行。当模型中的某些操作在栈中尚无干净的降级路径时，适配器会在运行时介入，将其替换为等效的、有路径的操作。补丁改变了模型为设备表达的方式，但不改变其计算内容：底层数学得以保留。适配器不是手工优化的内核——它向栈提供一种可以良好降级的形式，但性能仍是编译器的责任。

适配器并非阻塞于栈的当前状态，而是提供了穿越当前栈的实用桥梁。一个有用的类比是大型建筑项目。在正在施工的建筑周围——无论其仍在建造还是已建成正在翻新——几乎总有脚手架：临时的通道坡道和支撑梁，让未完工部分的作业得以继续。没有哪个脚手架是永久的；一旦其后的结构能自立，脚手架就会被拆除。

适配器扮演着相同的角色。单个适配器通常是过渡性的：它的任务是承载模型跨越栈当前状态的特定差距，设计为一旦该差距被弥合（随着平台成熟、新优化集成、更多架构被支持、永久路径在下方打开）即可移除。不过并非所有适配器都会被拆除：有些弥合了栈最终会闭合的临时差距，而另一些则适应了目标硬件真实存在的、持久的差异；当加速器硬件具有独特架构时，这些桥梁可能永久存在。

然而，适配器层本身是持久的，不像单个适配器。因为模型领域永不停歇，总是存在栈尚未追上的新差距——所以即使旧脚手架被拆除，新脚手架又在别处搭建。这一层连接着并行演进的两样东西。一方面是模型生态系统——在我们这里是HuggingFace Transformers，数千个具有稳定API和庞大社区的模型。另一方面是平台的硬件降级栈——在我们这里是Spyre，一个将模型映射到加速器设备的编译器和运行时栈，其本身也处于持续开发中。适配器居于其间，让模型得以在硬件上运行，同时两端继续演进。

使这一策略在数千模型规模下变得可行的是AI。历史上，启用每个新模型家族是缓慢的专家工作，需要为每个硬件平台和芯片架构付出大量努力。编程智能体改变了经济性，将原本的定制工作转变为能够跟上生态系统节奏的事情。下文将展示其运作方式——但首先我们介绍实现此策略的具体平台。

平台：Spyre 与 torch-spyre

我们示例中的硬件是Spyre，IBM的AI加速器，基于AIU（人工智能单元）构建。它由通过高带宽环连接的小型核心组成，每个核心拥有自己的本地暂存内存和执行矩阵乘法的处理单元阵列。它有几个特点。首先，它是数据流驱动的：计算由数据到达计算引擎触发，这减少了顺序控制流的瓶颈，使硬件专注于模型所构成的结构化、重复的数学运算。这与传统GPU相反，GPU将内核作为显式指令流在预定的线程组上执行。其次，Spyre使用专为推理设计的低精度数值格式，使其能在低功耗下提供高吞吐量。

Spyre的内存和计算处理称为“条块”的固定大小块——128字节，或fp16下的64个值——并要求张量维度在条块边界上对齐（参见Tiled Tensors RFC (https://github.com/torch-spyre/RFCs/blob/main/0047-TiledTensors/0047-TiledTensorsRFC.md)）。这与PyTorch和模型代码所依据的契约不同，后者中张量是任意形状的扁平数组，框架隐藏了其到内存的映射方式。模型架构基于统计和建模原因选择其头维度、序列长度和词汇表大小，对“条块”一无所知——因此在我们的情景中，适配器的部分工作是通过弥合HF Transformers模型实现与PyTorch中的Spyre编译器扩展，来调和这两种视角。

将模型映射到此硬件上的软件栈是torch-spyre (https://github.com/torch-spyre/torch-spyre)，一个PyTorch后端，能在Spyre上编译和运行标准的torch代码：模型被编译成硬件可以执行的计划。而适配器——上一节提到的临时脚手架——是我们称为HF-适配器 (https://github.com/torch-spyre/hf-adapters) 的项目：允许标准HuggingFace模型今天就能在Spyre上运行的运行时补丁。

AI如何助力构建适配器

适配器存在于两个代码库之间的缝隙中。一边是Transformers表达的模型——模块、注意力块、特定架构如何连接其RoPE和归一化。另一边是torch-spyre，将这种计算降级到设备的编译器和运行时。编写适配器需要同时理解两者，并找到它们尚未匹配的精确位置：模型以编译器无法干净降级的形式表达的操作。实践中，这意味着遵循模型的内部逻辑，同时追踪其每个部分如何流经编译栈。这部分工作已被AI改变。

编程智能体现在可以在各个层面遵循整个Transformer模型的内部逻辑，从单个模块到注意力块再到完整的前向传播。它们可以将相同的计算通过torch-spyre的降级逻辑向下追踪，查看其如何设计在硬件上运行。同时持有这两种视角，使得这项工作的核心循环成为可能：识别栈中的差距，然后起草一个高级补丁将模型带过这个差距。模型侧和设备侧通常在不同地方、使用不同语言、处于不同抽象层级进行文档化。快速阅读并交叉引用两者，曾是让此类工作完全不可行的瓶颈。

[图示：how-ai-helps-cycleagent]

有几件事使这项工作在实践中可行。我们维护一个知识库，描述硬件和软件栈及其演进，使智能体能够基于Spyre的实际行为而非通用假设进行推理。我们直接提供其访问HuggingFace Transformers库和torch-spyre后端的源码和GitHub，以便它能通过实际代码、议题和拉取请求追踪逻辑。此外，前沿模型已经具备对机器学习和Transformer架构的深度工作知识——它们在打开我们的代码库之前就知道注意力、RoPE和RMSNorm是什么，这意味着阅读从理解而非一无所知开始。

重要的是，我们添加的每个适配器也是哪些适应性调整有效及其原因的记录。新模型很少是全新的问题：它通常是我们已支持架构的变体，而最接近的现有适配器既是模仿的模板，也是可直接重用的补丁来源。因此，我们启用的每个模型都降低了下一个类似模型的成本，添加新适配器会随时间变得更容易。下图展示了实际的累积效应：少数几个不同的适配器，在几个月内添加，覆盖了目标集中的绝大多数模型。

***Spyre嵌入模型适配器覆盖率：2026年4月中旬至6月下旬目标模型集的覆盖情况。*左轴计数嵌入模型，右轴计数不同适配器。在最终快照中，13个不同的适配器覆盖了前10,000个最热门HF嵌入模型中的7,960个，其中6,804个在Spyre上通过了端到端测试。覆盖线以几个大步上升，而非逐个模型：因为大多数新模型是已支持架构的变体，每个新适配器一次拾取一整个相似模型家族。工作量随架构数量扩展，覆盖度则随模型数量扩展。两条覆盖线之间的差距——有适配器的模型与在Spyre上通过的模型——说明了调试挑战：适配器是必要但不充分的，弥合这一差距正是下方人机协作诊断工作投入之处。

同时，人类专业知识和监督仍然至关重要。两种失败模式反复出现。

第一种是定位确实困难。当一个在CPU或GPU上正确的模型在设备上产生错误输出时，缩小误降级的精确来源很少是读一遍代码就能解决的。这意味着需要在隔离和协同状态下重现模型的不同部分——抽取单个块单独测试，然后放回以查看故障是否在周围计算中持续——因为故障通常不在于任何单一操作，而在于它们之间的交互，其中微小的忠实偏差恰好以某种方式对齐，被下游组件放大。当原始和适配后的代码在相同CPU或GPU上运行时，我们通常期望逐位相同的输出，以确认适配器保留了计算。然而，这种逐位确定性的期望并不延伸到目标硬件，其中预期的数值漂移可能难以与真正的降级错误区分开来。定位更加困难还在于编译器并非孤立地降级每个操作：它将相邻操作融合在一起，哪些操作被融合取决于它们出现的上下文。同一个操作单独测试时可能以一种方式降级，一旦与周围融合又会以另一种方式降级——因此，一个单独测试时表现忠实的操作，在原位运行时仍可能行为异常，恰恰是因为将其抽出改变了融合方式。这是需要耐心和方法的工作，任何单一的自动化探测都无法替代。

第二种是智能体常从定向实验中得出错误结论。模型深处某个地方的大幅数值差异是一个线索，而非定论。对于人和智能体都一样，容易在某个中间张量中发现惊人的差异，并得出其是端到端失败原因的结论。但下游层通常会衰减内部错误，使其永远无法到达输出，因此一个组件可能看起来严重损坏，但对最终结果完全无害。区分真实诊断与似是而非诊断的纪律是——将差异向前追踪到实际输出，对任何与最终输出不一致的探测结果保持怀疑——