把 GPU 内核调优变成夜间并行搜索

先对模型做 profiling，找出 kernel 或 fusion 的热点，再把后续的 kernel 改动当作搜索中的候选方案。在空闲 GPU 上并行运行试验，也可以让它们跑上一整夜。只要还有算力，就继续优化，直到工作负载达到理想的性能。

AMD AI 软件与解决方案企业副总裁 Anush Elangovan 在 2026 年 9 月的 Chain of Thought 节目中介绍了这套方法。ROCm 10 是一套 Agent 可以自行安装、随后用来部署模型服务的软件栈。Hyperloom 通过 profiling 找出 kernel 或 fusion 热点；GEAK 则搜索 kernel 改动，同时保持数值精度。他表示，在算力充足的情况下，Hyperloom 曾在一轮优化中处理约 14,000 个模型，带来了显著的性能提升。

如何确保更快的 kernel 在数值上依然可靠？

在第一次试验前明确写下容差，淘汰任何超出容差的配置。只有结果仍然符合参考值的配置，才有资格按速度排名。

Elangovan 把这项工作拆给了两个工具。首先是 profiling 和分析：接收模型，找出 kernel 热点或 fusion 热点。然后，一个他称为 GEAK 的工具包接手那些较慢的 kernel，搜索提高利用率的方案，同时保持相同的数值精度。

固定一小组真实输入，以及当前运行的 kernel 对这些输入产生的输出。每次测试候选方案后，都用最大绝对差与这组参考输出比较；如果数值跨度很大，则使用相对差。把差异和耗时一起保存。

搜索本身并不新鲜。在他创办、后来被 AMD 收购的公司里，autotuner 会定义一个搜索空间，再用粒子滤波器或遗传算法遍历它。他认为新的地方在于，使用 AI 和 LLM 做出更有依据的选择，并在搜索空间中寻找路径。更聪明的候选方案生成器不能取代校验。模型可以建议一次 fusion，但是否保留这个方案，仍然由容差决定。

GPU 通宵调优循环应该执行哪些步骤？

先做一次 profiling，再生成候选方案，淘汰精度不达标的方案，对剩下的方案计时；只要 GPU 仍然空闲，就重复这个过程。

Hyperloom 可以在你睡觉时持续进行性能优化；当你不使用系统时，同样的工作也可以并行运行。较小的模块可以从 profiling 开始，独立运行。调优器会把任务组织成定义清晰的问题和目标。只给 Claude 或 Codex 一个笼统的提速要求，可能还不够。这些目标对应的 spec 很简短：输入、参考输出、容差、你关心的指标，以及停止规则。

下面只是一个说明思路的示例，并不是生产环境的库，也不是任何人的实际实现。

import math

def tune_until_budget(candidates, reference, tolerance, gpu_hours):
    if not math.isfinite(tolerance) or tolerance < 0:
        raise ValueError("tolerance must be finite and non-negative")
    if not math.isfinite(gpu_hours) or gpu_hours < 0:
        raise ValueError("gpu_hours must be finite and non-negative")
    best_config = None
    best_time = None
    spent = 0.0
    for config in candidates:
        remaining = gpu_hours - spent
        if remaining <= 0:
            break
        # Helpers cancel and return None when the launch would pass the cap.
        launched = run_kernel(config, remaining)
        if launched is None:
            break
        outputs, elapsed, cost = launched
        if not math.isfinite(cost) or cost < 0 or cost > remaining:
            break
        spent += cost
        diff = max_abs_diff(outputs, reference)
        if not math.isfinite(diff) or diff > tolerance:
            continue
        remaining = gpu_hours - spent
        if remaining <= 0:
            break
        timed = benchmark(config, remaining)
        if timed is None:
            break
        timing, bench_cost = timed
        if (
            not math.isfinite(bench_cost)
            or bench_cost < 0
            or bench_cost > remaining
            or not math.isfinite(timing)
        ):
            break
        spent += bench_cost
        if best_time is None or timing < best_time:
            best_config = config
            best_time = timing
    return best_config, best_time

run_kernel 和 benchmark 是占位函数，分别代表实际启动 kernel、对稳态批次计时的操作。精度是硬性筛选条件，耗时是排序依据，gpu_hours 是预算。独立配置之间不需要互相等待，因此可以把它们排到空闲设备上执行。

具体说到 Hyperloom，我记得我们有一次在一轮优化中处理了大约 14,000 个模型，对吧？我们把所有模型都拿来，只要算力足够，就可以针对同一类模型，尝试不同版本的搜索空间探索方案。

Anush Elangovan，AMD AI 软件与解决方案企业副总裁，出自 Chain of Thought 第 72 期

用 AI 调优 GPU 性能… - Chain of Thought | AI Agents、基础设施与工程 - Apple Podcasts

播客单集 · Chain of Thought | AI Agents、基础设施与工程 · 9 月 9 日 · 53 分钟

而且，它还能在你睡觉时进行性能优化。你可以运行我们一个叫 Hyperloom 的工具，它能让你在运行过程中持续优化。你就这样一直做下去，直到性能真的达到理想水平。这项工作也可以并行进行，尤其是在你不使用系统时，我们可以继续优化。

Anush Elangovan，AMD AI 软件与解决方案企业副总裁，出自 Chain of Thought 第 72 期

如何为不同硬件上的 kernel 试验分配预算？

限制 GPU 小时数和候选方案数量，而且只有在你实际交付的设备上取得的提升，才算有效。

设置 GPU 小时数上限、候选方案数量上限，以及一条耐心规则：连续固定数量的合格试验都没有带来提升，就停止。并行运行会更快耗尽预算，但不会增加预算。

过去一年，他的团队针对持续跟进的框架，在多个硬件代际上把 CI 的规模扩大了一个数量级。PyTorch、vLLM 和 SGLang 的 CI 接入已达到 100%，因此，如果上游 pull request 只在 NVIDIA 上测试，却会导致 AMD 硬件性能回退，就可以被拦截。如果每个候选方案都只在一台机器上计时，调优循环也会存在同样的漏洞。把你支持的每一代硬件都选一台设备放进通宵运行队列，即使这意味着每台设备能测试的候选方案更少。

Agent 可以在搜索开始前把软件栈搭起来。使用 Claude Code 或 Codex 的开发者，可以直接让它安装 ROCm，因为相关 skills 已经集成好了。当你要求它用 vLLM 部署模型服务时，Agent 会阅读文档、加载 skills、解决依赖问题，再启动服务。先建立这条基线，之后再运行以精度校验为门槛的调优循环。

Agent trace 改变的是容量规划，而不是 kernel 试验预算。一次人类用户会话，可能只是某个人登录后要求写一首诗。Agent trace 则包含持续的查询、文件读取和搜索。如果这种模式成了基础负载，就要按工程师或客户过去用量的 100 倍来规划容量。

所以，整个负载特征现在正在发生变化：好吧，如果这就是基本的运行水平，我们就需要按工程师或客户过去用量的 100 倍来规划。

Anush Elangovan，AMD AI 软件与解决方案企业副总裁，出自 Chain of Thought 第 72 期

精度检查应该放在循环的哪个位置？在按速度排名之前。Elangovan 介绍说，GEAK 会接手较慢的 kernel，在保持相同数值精度的前提下进行搜索。在上面的示例中，超出容差的配置会被跳过，只有通过这项检查后，benchmark 才能更新最优方案。

你不在时，搜索能继续吗？可以。Hyperloom 可以在你睡觉时、在你不使用系统时，并行地持续测试性能优化方案。给它设置 GPU 小时数上限，避免一台空闲机器一直运行而没有停止条件。

只在一家厂商的硬件上跑 CI，足以验证 kernel 改动吗？只在 NVIDIA 上测试的代码，仍然可能导致 AMD 性能回退。他的团队通过把 CI 规模扩大一个数量级，在多代硬件上测试 PyTorch、vLLM 和 SGLang，来拦截这类 pull request。对候选方案计时时，要覆盖你实际交付的每一代硬件。

在修改任何 kernel 之前，固定参考输出和数值容差。

先做 profiling，把试验次数用在 kernel 或 fusion 热点上。

淘汰所有超出容差的候选方案，再按速度给剩下的方案排名。

在空闲 GPU 上并行运行独立配置，并在 GPU 小时数预算耗尽时停止。

在你实际交付的每一代硬件上重新测试，并使用持续运行的 Agent trace 做 benchmark。

完整对话及文字稿可在 Chain of Thought 查看。

你也可以在 YouTube 上观看。

我每周都会在 Chain of Thought newsletter 中，介绍 AI 开发者正在学到的经验。

本文借助 AI，根据节目文字稿起草，再由我编辑。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。