012 · 不跑 GPU，也能知道哪个 kernel 更快吗？

核心问题：当 LLM 预测相对性能，并以置信度决定哪些候选值得实测时，减少 GPU 测量带来的搜索收益，能否抵消错误排序与错误自信的风险？

论文卡片

• 原题： GPU Forecasters: Language Models as Selective Surrogates for Kernel Runtime Optimization
• 作者： Zaid Khan、Justin Chih-Yao Chen、Jaemin Cho、Elias Stengel-Eskin、Mohit Bansal。
• 机构： UNC Chapel Hill、Allen Institute for AI、Johns Hopkins University、University of Texas at Austin。
• 版本： 2026-05-29，arXiv v1；分类为 cs.LG、cs.AI。
• 定位： 将 LLM 用作 GPU kernel 性能选择性代理模型，以有限硬件测量预算辅助搜索的实证系统论文。
• 阅读入口： alphaXiv · arXiv · PDF 全文

论文讲了什么

自动 kernel 优化通常循环执行“生成候选—编译—检查正确性—上 GPU 计时”。生成吞吐提高后，真实硬件评测反而成为瓶颈：论文举例，CUDA 候选的编译可能需要 60–120 秒，而一次批量化 LLM 预测可摊薄到约 30 秒；已有搜索甚至会消耗数万次 GPU 评测。

作者没有让 LLM 预测精确运行时间。输入包括参考 kernel、候选 kernel 和目标硬件规格，模型只预测候选相对参考实现的 speedup，并把结果放入 8 个对数区间：从不超过 0.25×，一直到超过 4×。输出不是单一标签，而是 8 个区间上的概率分布。搜索可用期望 speedup 对候选排序，也可把最高概率当作置信度：高置信度预测由代理模型处理，低置信度候选再交给真实 GPU。

这个设定把 LLM 的角色从“提出下一段 kernel”改成“预测硬件会如何回应已有候选”。作者称它为 GPU 的 selective surrogate：代理不需要在所有候选上都正确，但需要知道哪些预测可用、哪些应当弃权。

数据与评价方式

论文发布的完整数据包括 12,388 个有实测运行时间的 LLM 生成 kernel，覆盖 118 个问题、CUDA 与 Triton、A100/L40S/H100 三类 GPU 和四种生成方法，数据获取约消耗 4.11 亿 LLM token 与 618 GPU 小时。不过论文的核心预测实验范围更窄：它只在 A100 上评价 6 个 GPU Mode 任务的 480 个正确 Triton kernel。

这 480 个样本按任务和 8 个 speedup 区间近似均衡，每个任务每个区间最多 10 个。作者用三个指标评价代理模型：

• Speedup recovered： 只实测代理排序前 1%、5%、10%、25%、50% 的候选时，能找回全量实测最佳 speedup 的多少；表中再对这些预算取平均。
• Expected Calibration Error： 模型说 70% 确信的一组预测，实际命中正确区间的比例是否接近 70%。
• Forecast error： 预测区间代表值与真实 speedup 的绝对差距。

作者还对 GPT-OSS-20B 做强化学习。训练标签来自同六类任务的另一组搜索轨迹，与测试候选不重合；奖励分别使用区间命中、命中加 Brier 校准、命中加 CRPS 校准。训练只使用成功运行并得到 speedup 的候选，不包括编译失败、运行失败或正确性失败的样本。

主要结果

未经专门训练的模型已经能提供有用排序。Gemini-3 Flash 的 speedup recovered 为 93.12%，GPT-OSS-120B 为 86.85%，GPT-OSS-20B 为 82.88%，DeepSeek-V4 为 79.86%。这里的 93.12% 是对五档测量预算和六个任务的聚合指标，不表示只测一个候选就有 93% 概率找到最优 kernel。

排序强不代表置信度可靠。Gemini-3 Flash 的 recovered 最高，但 ECE 也是四个模型中最差的 0.624；GPT-OSS-20B 的 ECE 为 0.441。基础模型还倾向于高估慢 kernel、低估超过 4× 的最快 kernel，恰好可能错过搜索中最重要的突破候选。

强化学习结果说明，奖励定义会改变“会不会排序”和“知不知道自己可能错”之间的关系。只奖励正确区间虽然把 ECE 降低 0.031，却让 speedup recovered 下降 1.29 个百分点，并使置信度与误差的单调关系变差。加入 Brier 奖励后，ECE 下降 0.106、recovered 提升 2.06 个百分点；但按最可能区间计算的 forecast error 反而增加 0.130。也就是说，一个分布可以更适合排序与决策，同时单点预测看起来更不精确。

最终的端到端实验比较两种 PUCT 搜索。基线实测每个生成候选；代理版本每个父节点生成四倍候选，只实测 Brier 训练代理排在前四分之一的候选，因此两者每一步消耗相同 GPU 测量次数。6 个任务中，代理搜索在 3 个任务找到更快 kernel，在 TriMul 基本持平，在其余 2 个任务落后约 5% 和 7%。因此证据支持“固定硬件测量预算下，代理排序经常扩大有效探索”，而不是“代理可以稳定替代 GPU”。

证据边界

首先，论文的主要预测结果来自同一块 A100、同一组 6 类任务和经过区间均衡的正确 Triton 候选。训练与测试 kernel 不重合，但任务家族和硬件相同。完整数据虽然包含三类 GPU、两种语言和 118 个问题，论文没有给出跨 GPU、跨 backend 或全新任务上的主要泛化实验。

其次，均衡 speedup 区间有利于比较模型，却不同于真实搜索分布。现实轨迹中慢 kernel、无改进候选和失败代码的比例可能更高；而 RL 明确不在失败候选上训练。代理能否同时预测“不能编译／不正确”和“能运行但速度慢”，仍未由当前八区间任务回答。

再次，端到端搜索并没有依据置信度阈值动态决定是否弃权，而是固定生成四倍候选、测量排序前四分之一。论文证明了预算内排序的价值，也单独证明 Brier 奖励改善置信度；但“根据校准置信度自适应地把疑难候选交给 GPU”这一完整策略尚未在搜索实验中被直接验证。

最后，论文固定的是 GPU 测量次数，不是总墙钟时间、美元成本或能耗。代理版本额外使用四倍候选生成和每个候选的 LLM 预测；它可能节省稀缺 GPU 评测，却增加模型推理。端到端图也没有报告多次完整搜索的方差，因此 3 胜、1 平、2 负仍应视为有限任务上的初步系统证据。

重点读哪里

先读 §2.1，理解为什么作者预测相对 speedup 区间而非精确时间，以及“选择性”如何定义；再读 §3.1–§3.2，弄清 speedup recovered、ECE 和 480 个均衡样本；随后看 §3.4 的三种 RL 奖励，重点比较 Table 2 中相互冲突的指标；最后读 §3.5，判断端到端搜索究竟固定了什么预算。附录 B、C、F 给出数据构造、评测成本和正确性／计时细节。

思考启发

以下是导读者由论文引出的理解角度，不是作者额外验证过的结论。

这篇论文最重要的转向，是把硬件评测从“每个候选都必须获得的真值”变成“有限预算下应当分配的资源”。代理模型不需要模拟 GPU 的每个微架构细节，只需把真正有希望的候选排到前面。于是评价重点从绝对预测误差转向决策后果：在相同实测预算下，最后找到的 kernel 有多快。

但选择性系统的关键不只是平均准确率，而是错误如何分布。如果模型对普通候选犹豫、对罕见突破候选却错误自信，平均指标仍可能不错，搜索却会永久丢弃最有价值的分支。论文中“只奖励命中反而损害排序和置信度关系”的结果说明，预测目标、概率校准与搜索策略不是三个可独立优化的部件；一个指标变好，整体决策未必变好。

三个思考问题

1. 排序准确与可安全弃权是同一种能力吗？

一个模型能把大部分较快候选排在前面，但置信度严重失准时，它是否已经足以承担“选择性代理”的角色？

2. 代理模型最危险的错误是哪一种？

高估普通 kernel、低估突破 kernel，以及对失败代码过度乐观，这三类错误对搜索造成的损害是否相同？

3. “同样 GPU 预算”是否足以说明系统更高效？

代理搜索用四倍候选生成和额外预测换取更少实测时，比较双方相同的 GPU 测量次数，遗漏了哪些成本？