ROCm™ Hyperloom 在 AMD Instinct™ GPU 上进行的大规模无人值守评估中实现了中位数 1.73 倍的推理加速，提升幅度从 1.35 倍到 7.31 倍不等。它会对每个工作负载进行性能分析，搜索框架和内核优化方案，端到端验证变更，并将已验证的结果持续积累，无需针对每个模型进行人工调优。

对于大规模部署 AI 模型的团队而言，服务效率直接决定了硬件容量、延迟和运营成本。然而，跨服务配置、框架代码和 GPU 内核来优化一个工作负载，传统上需要少数专家花费数周甚至数月的时间，而且每出现一个新模型、新框架版本和新加速器代际，这项工作都必须重新进行。我们构建 Hyperloom 就是为了让这个全栈优化循环实现自主化、可重复且安全。

在本文中，你将跟随 Hyperloom 处理一个工作负载的完整路径，从它起始的服务配置一直到最底层的 GPU 内核，并了解它如何在 AMD GPU 上无人值守地走完这条路径。

核心要点 #

• Hyperloom 是面向 AMD Instinct™ GPU 的端到端推理优化系统，在无需人工介入的情况下实现了经验证的 1.35 倍到 7.31 倍吞吐量提升。

• 该多智能体框架围绕目标完整性、累积优化和有界自主性而构建。

• Hyperloom 支持文本生成、图像生成以及视频等自定义流水线，覆盖三种服务框架：vLLM、SGLang 和 xDiT。

• Hyperloom 已优化超过 14,000 个模型，消除了每次部署中的专家瓶颈。

• Hyperloom 基于 MIT 许可证开源，文档见 ROCm Docs。

为什么朴素的优化循环会失败 #

无论模型或框架如何，推理优化都遵循相同的基本循环：分析工作负载，找出次优之处，修复它，再次测量。任何调优过服务栈的人都手动做过这件事，所以把它交给 LLM（大语言模型） 似乎是显而易见的下一步。然而，在真实工作负载上，一次优化过程并不快。模型会运行数百轮，启动和终止数十个推理服务器进程，编辑服务框架的源码树，更改服务配置，重写 GPU 内核。在如此长的运行中，朴素的循环会在三个方面崩溃，而每种失败都归结为同一个根本原因：模型是唯一在跟踪运行所依赖的东西。这三种失败可以概括为：

• 模型会漂移。在数百轮中保持连贯并非没有代价。当上下文窗口被运行自身的记录填满时，最初的目标已经悄然变成了别的东西。模型甚至可能开始编造基准测试数据，因为其环境中没有任何东西可以约束它。到那时，它优化的已不再是当初被要求优化的目标。

• 模型每次都从零开始。同一个模型、同一块 GPU、同一个框架，可能上周就已经优化过了，而 LLM 对此毫无记忆。它重新发现相同的环境变量，重新阅读相同的源代码，重新运行相同的基准测试，撞上相同的死胡同，每次都付出全部代价。一个无法积累知识的优化器，只是一种运行固定脚本的昂贵方式。

• 模型可能不安全地行动。优化服务栈意味着赋予 LLM 编辑框架源码树的权限，而在长时间运行中它可能滥用这一权限。本应针对某个文件的补丁落到了别处。一次糟糕的编辑没有被干净地回滚，损害会延续到之后的每一次测量中。这些都不是恶意行为：只是没有任何东西阻止模型偏离轨道。

这些问题都无法通过更好的提示词来解决。这就是 Hyperloom 被构建为多智能体框架的原因——它让运行与实际目标保持一致，使其能够获取先前运行已经学到的知识，并将其限制在可以安全执行的操作范围内。这一设计确保 AI 工作负载能够真正实现自主优化。

Hyperloom 的工作原理 #

在高层面上，Hyperloom 运行一个闭环优化循环：输入 → 优化 → 验证 → 学习。它从模型、服务栈、硬件目标、工作负载定义和优化预算开始。然后，它分析工作负载，并在框架设置、源代码更改和 GPU 内核中搜索改进。每个候选方案都在受控基准协议下进行端到端重新测量。未通过验证的更改会被回滚，而成功的更改则成为新的基线。最后，Hyperloom 将验证过的配置、实现产物、测量到的增益和有用的失败记录到其 Recipe KB 中，以便未来的会话可以从积累的经验开始，而不是从头开始。图 1 展示了 Hyperloom 内部的整个优化循环。

一个会话经历五个阶段：Prelude、Framework optimization、Kernel optimization、Sweep 和 Close。在 Sweep 之后，协调器要么关闭运行，要么开始另一个周期。新周期仅在以下情况下开始：

• 剩余足够的优化预算；

• 运行尚未收敛；且

• Roofline 分析显示仍有剩余性能提升空间。

周期数量的硬上限高于以上三个条件，因此即使条件看起来仍然有利，运行也不能无限循环。新周期从框架层恢复，而不是从头开始，因为基线和热启动已经建立。当任何条件失败时，Close 接管。运行留下两个输出：

• Recipe 知识库（KB）：验证过的配置、补丁、内核、测量到的增益以及值得记住的失败。

• 会话记录：最终报告、事件历史和完整的审计追踪。

Prelude：建立基线和目标 #

Prelude 按特定顺序设置起点和目标。首先，它在原始配置上测量基线，不使用 KB 建议的任何内容。这是后续所有比较的锚点。然后，它重放 KB 中最接近的匹配配方，为运行提供先发优势。最后，它分析基线并构建 roofline 分析，将测量到的性能与 GPU 的内存带宽和计算限制进行比较。该分析显示剩余多少性能提升空间、哪些内核消耗最多执行时间，以及工作负载主要受内存移动还是计算限制。每个方向都根据饱和阈值进行跟踪，该阈值后来决定哪些值得优化。

框架优化：先让它运行，再让它更快 #

框架优化涵盖模型在其所选框架内如何被服务。它有两个任务。

第一个是启用，让模型至少能运行。Hyperloom 将启动失败分类为特定的能力缺口，然后遵循六步恢复阶梯，从侵入性最小到最大：

• 只读诊断

• 服务标志更改

• 树内源代码补丁

• 替代 wheel 或源代码检出

• 合并拉取请求的源代码本地化

• 重新构建编译组件，例如 AITER（AMD 的优化 AI 算子库）或框架特定的内核包，如 sgl-kernel 和 vLLM

第二个任务是让工作负载更快。Hyperloom 搜索框架暴露的控制项和未发布的改进，包括：

• 服务标志和环境变量

• 权重和键值（KV）缓存精度

• 注意力实现

• 批处理和调度限制

• 开放的拉取请求，按预期吞吐量排序，以 diff 形式应用并测量

内核优化：提升 GPU 执行效率 #

内核优化直接作用于 GPU 内核，并将该阶段委托给一个 AMD 后端。共享工作流程如下：

• 打包工作负载、硬件目标和目前的最佳配置。

• 将选定的后端作为子进程启动。

• 收集其接受的内核及其声称的加速比。

• 在 Hyperloom 的基准测试协议下，对每一项被接受的更改进行端到端重新测量。只有当吞吐量提升且精度相对于会话基线保持时，该更改才会被保留。

Hyperloom 可以将此工作委托给两个 AMD 后端之一：GEAK，它在该阶段自主选择并优化内核目标；或 KernelForge，它对从性能分析跟踪中选择的目标应用专门的优化通道。它们的范围不同：

• GEAK 运行完整的内核优化阶段，并独立选择要探索的内核和优化策略。

• KernelForge 运行一系列专门的通道，即有界的优化通道，用于调优、融合、重写或通信集合操作。Hyperloom 根据 GPU 时间和重写可行性从性能分析跟踪中选择候选内核。

每个阶段只运行一个后端，绝不两者同时运行。

扫描：跨操作点验证 #

此阶段之前的所有内容都是在单一操作点上调优的：一个并发级别、一个输入长度、一个输出长度。在那里最快的配置不一定在不同的请求速率或不同的序列长度下也最快。因此，扫描会在并发级别和输入/输出长度的网格上重新测量累积的堆栈，并记录每个点的最佳配置。当验证后的增益自上次扫描以来没有变化时，扫描会跳过自身，而不是花费 GPU 时间来确认没有任何变化。

收尾：保留结果和学习成果 #

无论运行如何结束——通过收敛、时间限制或手动干预——收尾都必须正常工作。它确定运行停止的原因，如果运行结束得太突然而无法记录原因，则从阶段历史中推断原因。然后它运行优化后的 roofline 以记录调优后的堆栈距离硬件上限还有多远，将运行所学到的内容最终确定到 Recipe KB 中，从状态文件和事件流构建最终报告，标记任何未经完整验证而保留的更改，为下游工具编写机器可读的摘要，刷新可观测性日志，并打包产物。

多智能体协作以确保目标完整性 #

四个智能体角色共同运行一个会话，如表 1 所示。编排智能体在整个会话期间作为一个持续对话保持存活，因此其计划和假设始终可见，而无需从头重建。另外三个仅在需要时启动，随后即被丢弃：Critic 在每次保留或回退决策时参与，Robustness 角色在运行看起来卡住或停滞时被调用，而 Specialist 仅在需要编写内容时出现。

| 角色 | 运行时机 | 携带内容 | 如何使运行保持目标 |
| --- | --- | --- | --- |
| Orchestration | 每个 tick | 整个会话，作为一个对话 | 唯一的持续规划者，因此任务目标绝不会从冷启动提示中重新推导 |
| Critic | 在每次保留或回退决策时 | 无，每次全新 | 裁定某项变更是否真正服务于任务目标，运行所学到的记录由该裁定写入，而非由规划者写入 |
| Robustness | 当运行看起来停滞、崩溃或循环时 | 无，每次全新 | 断路器：它捕捉规划者陷入循环的情况，并强制恢复，而不是再绕一圈 |
| Specialist | 仅在需要编写判断时 | 除其单一任务外无其他内容 | 设计上即为临时性。由于没有累积的上下文，它没有什么可漂移的，并且它返回的是经过审查的 diff，而不是决策 |

表 1：四个智能体角色。

保持长时间运行的编排智能体方向明确需要三种机制：

• 基于状态的上下文。在每一轮，协调器从状态文件而非对话记录中重建任务目标和进度摘要。摘要包括基线、当前最佳、已验证增益和剩余时间。

• 阶段特定指令。指令按阶段和后端打标签，然后在每次阶段变更时重新组装。智能体只看到与当前步骤相关的工具和操作。

• 上下文刷新。协调器定期清空对话，并从状态文件加简明摘要重新启动，防止累积的对话记录噪声成为事实来源。

这些都无法阻止模型相信某件事奏效了而实际上并没有，因此模型报告的任何数字都不会被视为事实依据。基准测试由协调器运行，而不是由智能体请求。模型预测的增益会被记录用于校准，但绝不会自行决定任何事情，而内核后端声称的任何加速在 Hyperloom 端到端重新测量之前都视为未验证。

用于累积优化的自演化经验 #

Recipe KB 是 Hyperloom 的记忆：每个会话在开始前从中读取，在完成后写回。每一行涵盖一个工作负载、获胜配置、达到的吞吐量、运行所学到的内容以及未奏效的内容，归入七个字段：模型、硬件、框架、模型类型、架构、框架版本和精度。七个字段全部匹配即为直接命中，以完全置信度重放。大多数匹配并非精确匹配，因此查找会按照定义的降级顺序一次放宽一个字段（图 2）。

这正是让会话能够相互构建而非重复相同工作的原因。默认情况下，Hyperloom 应用匹配置信度超过配置阈值的最接近配方。这种热重放——将先前验证过的配置复用为新会话的起点——允许会话 N 从相似的早期会话结束之处开始，而不是从供应商默认值开始，因此它可以将时间花在尚未覆盖的领域上。KB 中的其他所有内容——被回退的补丁、使情况变糟的设置以及往往有帮助的旋钮——都作为提示上下文反馈，而不是编码为硬性规则。过去的失败被视为证据，而非取消资格的理由。系统严格把关的是什么可以首先进入 KB，因为一条糟糕的条目会比创建它的运行存续得更久。

用于安全实现的有界自主 #

系统中风险最高的权限是编辑源代码的能力。每个提议的变更都遵循相同的有界流程：

• 为 specialist 智能体创建一个隔离的 Git worktree 和分支。

• 将提议的变更作为统一 diff 返回，而不是触碰实时源代码树。

• 验证 diff 能干净地应用，并拒绝绝对路径或使用 .. 尝试逃逸目录。

• 将实时检出中任何未提交的变更暂存。

• 应用补丁，自动检测 strip 级别，并在需要时回退到三方合并。

• 在协调器的协议下对结果进行基准测试。

• 当变更提升性能时，仅提交所触碰的文件；否则，精确重置到 HEAD，即最后接受的状态。

已合并上游拉取请求的向后移植遵循相同路径：Hyperloom 获取 diff，并在执行前通过相同的验证关卡。

这些都不算新奇。这就是在真实硬件上运行不受信任代码时应遵循的常规纪律。智能体提出的每个操作都要经过一个策略关卡，而那些不可变通的规则关乎权限：哪个角色可以请求什么、谁可以写入核心会话状态、一个专家可以申请多少块 GPU，以及关键的一点——没有 Critic 的签字，任何补丁都不得合并。最后这项检查会发生两次，一次在关卡处，一次在执行器内部，因为一个已排队并稍后恢复的任务不会自动再次通过关卡。此外，拒绝不是无声的。它会以结构化事件的形式返回，指明被违反的具体规则，并附上一行提示，这样下一次尝试就是修复，而不是重复。

从一个会话到整个集群 #

跟踪单个会话 #

以一个会话的端到端流程为例：Llama-3.1-8B-Instruct 在单块 MI355X 上运行，使用 vLLM、bf16、输入和输出各 1024 个 token，并发数为 64。它最终达到每 GPU 每秒 26,682 个 token，相比 7,677 的基线提升了 3.48 倍，这是作为整个技术栈的一个数字来衡量的，而不是各项单独收益的加总（表 2）。

| 阶段 | 应用的变更 | 吞吐量 | 本阶段（百分点） | 累计 |
| --- | --- | --- | --- | --- |
| 基线 | 不适用 | 7,677 | 不适用 | 不适用 |
| 热重放 | 继承的六个 AITER 环境标志和 768 序列批处理上限 | 7,765 | +1.15 | +1.15% |
| 框架优化 | AITER 统一注意力、FP8 KV 缓存和权重、n-gram 推测解码 | 24,713 | +220.76 | +221.91% |
| 内核优化 | 一个重写的缓存内核 | 25,238 | +6.85 | +228.75% |
| ↻ 第二轮循环开始。第一轮扫描确认了收益，且预算仍有剩余 |  |  |  |  |
| 框架优化（第二轮循环） | RoPE（旋转位置嵌入）和 KV 缓存融合、图捕获上限 | 26,682 | +18.81 | +247.57% |
| 端到端验证 | 上述所有内容，一起衡量 | 26,682 |  | +247.57% |

表 2：一个会话，逐阶段展示。

表 2 突出了三个重要结论：

• 在此案例中，框架变更带来了大部分收益。新的注意力后端、FP8 KV 缓存和权重以及推测解码占据了这里的大部分改进，而重写的内核贡献了较小的额外收益。

• 第二轮优化循环又发现了一项收益。第一次扫描确认了累计改进，但剩余预算和 roofline 余量证明再进行一轮循环是合理的。该轮循环增加了 RoPE/KV 缓存融合和图捕获上限，将吞吐量提升至每 GPU 每秒 26,682 个 token。

• 热重放使后续改进成为可能。它的直接测量贡献不大，但其六个继承标志中有五个保留在最终配置中。框架方面的大幅收益也依赖于热重放已经启用的注意力后端。

这次运行结束时，其 24 小时中约有 5 小时未使用，因为它已经收敛：它耗尽的是值得测试的有前景想法，而不是时间。

内核优化的贡献程度取决于工作负载。内核优化在 Qwen3-14B-FP8 上贡献了 29.8 个百分点，在 DeepSeek-V4-Pro 上贡献了 27.7 个百分点，在 gpt-oss-120b 上贡献了 20.4 个百分点。在 DeepSeek-V4-Pro 上，这超过了总验证收益的一半。在孤立内核上，GEAK 和 Forge 都超过了 Claude Code 基线（表 3）。

| 指标 | GEAK | Forge | Claude Code |
| --- | --- | --- | --- |
| 平均加速比 | 2.45× | 2.97× | 1.95× |
| 中位加速比 | 2.22× | 3.09× | 1.73× |
| 峰值加速比 | 23.88× | 24.06× | 14.38× |

表 3：隔离内核加速比。

扩展至集群 #

单次会话表明这个循环可以闭环。它能否在无人监督、无需针对每个模型单独照看的情况下，跨多种不同工作负载保持稳定，才是更严峻的考验。表 4 涵盖三个服务框架、三种精度、稠密与 MoE 模型、文本与图像生成，参数规模从不足十亿到 8620 亿，共十六个工作负载。服务栈一列列出框架、精度和张量并行（TP）度。

| 模型 | 类型 | 规模 | 服务栈 | 增益 |
| --- | --- | --- | --- | --- |
| DeepSeek-V4-Flash-0731 | 文本 | 304B | SGLang · bf16 · TP 4 | +631.5% |
| GLM-5.2-MXFP4 | 文本 | 743B | vLLM · MXFP4 · TP 8 | +390.3% |
| Llama-3.1-8B-Instruct | 文本 | 8B | vLLM · bf16 · TP 1 | +247.6% |
| gpt-oss-120b | 文本 | 120B | vLLM · MXFP4 · TP 2 | +172.1% |
| Qwen3-0.6B | 文本 | 752M | vLLM · bf16 · TP 1 | +102.7% |
| Qwen3-8B | 文本 | 8B | vLLM · bf16 · TP 1 | +97.0% |
| Qwen3-14B-FP8 | 文本 | 15B | vLLM · FP8 · TP 1 | +88.3% |
| FLUX.1-schnell | 多模态 | 12B | xDiT · bf16 · TP 1 | +83.0% |
| gemma-4-26B-A4B-it | 多模态 | 27B | vLLM · FP8 · TP 2 | +62.3% |
| Mixtral-8x7B-Instruct-v0.1 | 文本 | 47B | SGLang · FP8 · TP 8 | +62.1% |
| Qwen-Image | 多模态 | 29B | xDiT · bf16 · TP 1 | +55.6% |
| DeepSeek-V4-Pro | 文本 | 862B | vLLM · MXFP4 · TP 8 | +53.2% |
| Z-Image-Turbo | 多模态 | 10B | xDiT · bf16 · TP 1 | +47.2% |
| Qwen3.5-397B-A17B-MXFP4 | 多模态 | 222B | vLLM · MXFP4 · TP 4 | +46.9% |
| Nucleus-Image | 多模态 | 17B | xDiT · bf16 · TP 1 | +41.5% |
| ERNIE-Image-Turbo | 多模态 | 8B | xDiT · bf16 · TP 1 | +35.2% |

表 4：大规模无人值守评估的结果。

增益范围从 7.31× 到 1.35×，中位数为 1.73×。与这些数字的大小同样重要的是，它们都不是由人产生的。每次运行都自行分析其工作负载、自行搜索配置空间、应用并重新测量其发现，并报告哪些结果站得住脚，从头到尾没有人类参与。过去需要稀缺专家花费数周的调优，现在可以自行完成，这使得将测试框架指向一个新模型变成了调度决策，而非人员配置决策。

总结 #

在本博客中，你探索了 Hyperloom 如何在 AMD Instinct GPU 上端到端优化推理，从服务栈一直调优到单个 GPU 内核，全程无需人工参与。你了解了多智能体测试框架如何让长时间运行始终围绕目标推进，让每次会话都从先前会话已验证的结果出发，并限制智能体允许更改的范围。你还逐步跟踪了一次会话，并看到了同一测试框架在大规模无人值守评估中产生的成果，加速比范围从 1.35× 到 7.31×，中位数为 1.73×。

Hyperloom 以 MIT 许可证开源，文档位于 ROCm Docs。下面的后续步骤概述了项目的发展方向，相关工作落地后我们会撰文介绍。如果你遇到问题或希望合作，欢迎与我们联系。

后续步骤 #

• 更轻量的测试框架。部分结构是为了补偿模型弱点，而更好的模型将不再需要这些补偿。其余部分则用于核查推理无法确定的事情，例如推理是否真的加速了。目标是在不削弱能力的前提下变得更轻量。

• 经过训练的循环。每次会话都会重新发现一种搜索策略，而累积的配方历史其实已经描述了这种策略。该历史可作为训练数据，用于训练一个能够从当前测试框架必须引导它开始的地方起步的模型。

• 向上游回流的发现。Hyperloom 已经会读取开放的拉取请求并回移已合并的请求。这条路径的自然终点是反向运行，即在一个工作负载上验证的修复成为整个生态系统继承的补丁。

其他资源 #

代码 #

• Hyperloom: AMD-AGI/Hyperloom

• GEAK: AMD-AGI/GEAK

• KernelForge: AMD-AGI/KernelForge

文档 #

• ROCm Docs 上的 Hyperloom 文档：https://rocm.docs.amd.com/projects/hyperloom/en/latest/index.html

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：AMD ROCm Blog

原创地址：https://rocm.blogs.amd.com/software-tools-optimization/hyperloom-optimization/README.html