SOLAR：AI驱动的光速性能分析

# Solar: 基于AI的光速级性能分析

来源：https://arxiv.org/html/2606.26383
Qijing Huang, Sana Damani, Zhifan Ye, Athinagoras Skiadopoulos Siva Kumar Sastry Hari, Jason Clemons, Sahil Modi, Jingquan Wang Aditya Kane, Edward C Lin, Humphrey Shi, Christos Kozyrakis

NVIDIA

###### 摘要

一个深度学习模型在目标硬件上*理论上*可以跑多快？当前的实现距离这个极限还有多远？这些问题对于软件、硬件和算法优化都至关重要。光速分析通过计算给定架构上工作负载的理论最小执行时间来回答这些问题。然而，推导光速界限仍然是手动完成的，容易出错，并且与快速模型开发脱节。为弥补这一差距，我们引入了SOLAR，这是一个能够从PyTorch和JAX源代码自动推导验证过的光速界限的框架。SOLAR在其流程中同时利用*生成式*和*确定性*组件：一个LLM前端将任何源程序转换为可执行的仿射循环IR，并通过输出比较进行验证；一个确定性流程将IR提升为爱因斯坦求和图；一个分析后端计算非融合、融合和缓存感知的光速界限。SOLAR提供了全面的算子与语言覆盖，产生零观察到的光速违规的验证界限，并提供多保真度分析，以收紧界限并揭示优化洞察。我们在KernelBench、JAX/Flax模型和机器人工作负载上评估了SOLAR。这些实验展示了四个用例：多保真度级别的余量分析、识别优化机会、跨平台探索以及反向屋顶线的硬件配置。SOLAR是开源的，可在https://github.com/NVlabs/SOLAR获取。

## 1 引言

参考图注\(a\)在KernelBench上的光速余量。
参考图注\(b\)朴素 vs. 缓存感知光速。
工具Cov.SOLfvcore75%×ptflops84%×Solar100%✓\(c\)算子覆盖率。

图 1: Solar提供的内容。Solar从源代码推导验证过的光速界限，提供了现有工具缺乏的三种能力。\(a\)*光速余量分析*：对角线以下的点揭示优化机会；Solar在KernelBench上揭示了高达数量级的余量。\(b\)*更紧的界限*：缓存感知分析考虑了片上缓冲区约束，将光速界限比朴素屋顶线收紧最多10×10×。\(c\)*更高的覆盖率*：FLOP计数器Meta AI (2023 (https://arxiv.org/html/2606.26383#bib.bib44)); Sovrasov (2023 (https://arxiv.org/html/2606.26383#bib.bib45))覆盖KernelBench的75–84%，且无法推导光速；Solar覆盖100%，提供完整的光速分析。
现代深度学习加速器达到的峰值吞吐量以petaFLOPS计，但实际工作负载很少接近这些极限。一个模型或内核在目标硬件上*理论上*能跑多快？当前实现距离这个极限有多远？*光速*分析通过计算给定架构上工作负载的理论最小执行时间来回答这些问题。这些界限在整个优化栈中都很有用：内核和编译器工程师使用它们来识别瓶颈和剩余余量；算法设计者使用它们来评估精度-性能-成本权衡；架构师使用它们为目标工作负载配置计算和带宽；AI智能体可以使用它们来验证生成的优化在物理上是可实现的。没有分析上限，优化——以及日益增长的智能体代码生成——可能会在剩余余量很少的工作上浪费计算和令牌。Hari等人 (2026 (https://arxiv.org/html/2606.26383#bib.bib67))。

尽管其重要性，但没有现有工具能够自动从源代码推导光速界限。FLOP计数器Meta AI (2023 (https://arxiv.org/html/2606.26383#bib.bib44)); Sovrasov (2023 (https://arxiv.org/html/2606.26383#bib.bib45))受到狭窄语言和算子覆盖的限制（图̃1\(c\) (https://arxiv.org/html/2606.26383#S1.F1.sf3)），并且忽略了I/O流量；分析器NVIDIA (2023a (https://arxiv.org/html/2606.26383#bib.bib46))测量的是实际性能而不是理论性能；纯LLM估计存在误差。与此同时，AI架构的日益多样化，包括TransformersVaswani等人 (2017 (https://arxiv.org/html/2606.26383#bib.bib31))、MoEDeepSeek-AI (2024 (https://arxiv.org/html/2606.26383#bib.bib5))、SSMsDao和Gu (2024 (https://arxiv.org/html/2606.26383#bib.bib14))以及混合模型NVIDIA (2025 (https://arxiv.org/html/2606.26383#bib.bib16))，再加上机器人模型等新兴领域，使得自动化的光速分析变得越来越关键。

为了解决这一差距，我们引入了Solar，即运行时光速分析，这是一个源码到光速框架，有三个目标：1）广泛的算子和语言覆盖，2）自动化和验证过的光速推导，3）以及揭示优化洞察的更紧界限。Solar通过将*生成式*翻译与验证从*确定性*分析中分离来实现这些目标：一个LLM将源代码翻译为可执行的仿射循环IR，其正确性可以通过数值输出比较来验证；一个确定性编译器然后将验证过的IR提升为爱因斯坦求和图，一个分析后端计算非融合、融合和缓存感知的光速界限。

这个三阶段结构捕捉了两全其美：一个具有输出验证的智能体流程，用于从源语言轻松翻译为爱因斯坦求和表示，与确定性的提升和性能分析相结合，以保证可重复性和正确性。图̃1\(a\) (https://arxiv.org/html/2606.26383#S1.F1.sf1)说明了结果：每个点绘制了KernelBench工作负载的测量PyTorch运行时间相对于Solar的融合光速界限，与对角线的差距表示优化余量——在实际工作负载上高达数量级。图̃1\(b\) (https://arxiv.org/html/2606.26383#S1.F1.sf2)进一步显示，SOLAR中的缓存感知分析Huang等人 (2024 (https://arxiv.org/html/2606.26383#bib.bib19))通过考虑有限的片上缓冲区容量，将这些界限比朴素屋顶线收紧。本文做出三项贡献：

1. 1.一个源码到光速框架。Solar是第一个直接从PyTorch和JAX源代码推导验证过的光速界限的工具。它支持算子和图级分析，具有非融合、融合和缓存感知界限，在KernelBench上实现了100%的分析覆盖。
2. 2.一个分离生成式和确定性推理的三阶段流水线。Solar不是要求LLM直接估计光速，而是将LLM限制在一个可验证的任务上：将源代码翻译为可执行的仿射循环IR（*验证的智能体降级*）。然后一个确定性编译器将IR提升为爱因斯坦求和图（*确定性爱因斯坦求和提升*），从中一个分析后端推导多保真度光速界限。
3. 3.跨内核、算法和架构用例的证据。融合分析在KernelBench上揭示了比逐算子分析多高达7.8×7.8×的余量；缓存感知界限将光速收紧2.06×2.06×。爱因斯坦求和链重排序在DeepSeek MLA上识别到2.04×2.04×的FLOP减少。跨平台投影覆盖了四个硬件目标，无需物理访问，反向屋顶线显示500 Hz机器人VLA目标需要高达19.7×19.7×当前带宽。

## 2 相关工作

没有现有工具能够直接从源代码推导验证过的光速界限。表̃1 (https://arxiv.org/html/2606.26383#S2.T1)将Solar与当前格局进行了对比。

表 1: 性能分析格局。Solar是唯一结合了执行验证翻译、图级爱因斯坦求和提取、多保真度光速界限、缓存感知收紧和语言无关输入的方法。“图”=分析算子图（不仅仅是单个内核）；“光速”=推导理论界限（而非实际性能）；“验证”=执行验证翻译；“缓存”=通过缓冲区大小感知分块实现更紧的光速。类别工具图形光速验证缓存输入FLOP计数器fvcoreMeta AI (2023 (https://arxiv.org/html/2606.26383#bib.bib44))××N/A×PyTorchptflopsSovrasov (2023 (https://arxiv.org/html/2606.26383#bib.bib45))××N/A×PyTorchtorchinfoYep (2020 (https://arxiv.org/html/2606.26383#bib.bib66))××N/A×PyTorch分析器NCUNVIDIA (2023a (https://arxiv.org/html/2606.26383#bib.bib46))××N/A×任意NSysNVIDIA (2023b (https://arxiv.org/html/2606.26383#bib.bib47))✓×N/A×任意预测器PaleoQi等人 (2017 (https://arxiv.org/html/2606.26383#bib.bib24))✓×××CaffeHabitatYu等人 (2021 (https://arxiv.org/html/2606.26383#bib.bib37))✓×××PyTorch基于LLMPure LLM SOL×✓××任意ASAPDing等人 (2025 (https://arxiv.org/html/2606.26383#bib.bib40))✓×××JAX/XLAOpalZaeed等人 (2025 (https://arxiv.org/html/2606.26383#bib.bib41))××××CUDA/HIP性能建模框架TimeloopParashar等人 (2019 (https://arxiv.org/html/2606.26383#bib.bib22))×✓✓✓手动AccelForgeAndrulis和Gilbert (2024 (https://arxiv.org/html/2606.26383#bib.bib20))✓✓✓✓手动Solar✓✓✓✓任意表 2: KernelBench上的FLOP计数器覆盖。fvcore和ptflops对逐元素操作返回0，并在L4上崩溃。两者都不报告I/O流量或图结构。级别Nfv OKfv 0fv failpt OKpt 0pt failL11005740361372L21001000010000L35044604820L42010191901所有270202462222839375%覆盖率84%覆盖率
表 3: 零样本LLM光速在KernelBench上的准确性。直接提示总体达到83%，但在L3上由于空间维度跟踪失败而崩溃到38%。级别N正确Acc.主要错误模式L11009696%错误公式L2100100100%—L3501938%无空间跟踪L420945%错误公式所有27022483%

FLOPs和参数计数器。诸如fvcoreMeta AI (2023 (https://arxiv.org/html/2606.26383#bib.bib44))和ptflopsSovrasov (2023 (https://arxiv.org/html/2606.26383#bib.bib45))等工具仅限于PyTorch输入，并只覆盖KernelBench上75–84%的算子（表̃3 (https://arxiv.org/html/2606.26383#S2.T3)）。因为它们计算MACs和参数但不计算总内存流量，所以无法用于推导精确且紧的光速界限。

硬件分析器。诸如NCUNVIDIA (2023a (https://arxiv.org/html/2606.26383#bib.bib46))和NSysNVIDIA (2023b (https://arxiv.org/html/2606.26383#bib.bib47))等分析器测量*特定实现*的硬件利用率，即它们报告一个内核在多大程度上接近每个硬件单元的峰值吞吐量。这回答了：*这个实现在多大程度上利用了硬件？*Solar回答了一个不同的问题：*这个算法在这个硬件上的最小可能执行时间是多少？*区别很重要：并非所有算法都能同时饱和所有硬件单元。一个内存受限的softmax永远不会达到100%的计算利用率；NCU会报告物理上无法实现的余量。Solar的界限是与实现无关且更紧的，同时考虑了算法属性和硬件约束。

基于LLM的直接光速估计。零样本LLM估计（Claude Code with Opus 4.6）在KernelBench上达到83%的准确率，但在复合工作负载上崩溃，在L3子图上为38%，在L4完整模型上为45%，并且46个错误中有20个超过10×10×（表̃3 (https://arxiv.org/html/2606.26383#S2.T3)）。此外，需要系统搜索的分析（例如，在缓冲区容量约束下的缓存感知分块Huang等人 (2024 (https://arxiv.org/html/2606.26383#bib.bib19))）很难仅通过下一个标记预测可靠地执行。

性能建模框架。TimeloopParashar等人 (2019 (https://arxiv.org/html/2606.26383#bib.bib22))和AccelForgeAndrulis和Gilbert (2024 (https://arxiv.org/html/2606.26383#bib.bib20))提供缓存感知性能建模，但需要以它们的输入格式手动指定工作负载；手动翻译容易出错且未经验证。Solar通过自动将源代码翻译为这些框架可以直接使用的验证过的爱因斯坦求和表示来弥合这一差距。

LLM代码翻译。前沿LLM在HumanEval上达到96%的pass@1Chen等人 (2021 (https://arxiv.org/html/2606.26383#bib.bib2))，在SWE-bench Verified上达到80%Jimenez等人 (2024 (https://arxiv.org/html/2606.26383#bib.bib63))，并通过智能体优化在KernelBench上达到100%Ouyang等人 (2025 (https://arxiv.org/html/2606.26383#bib.bib21))，建立了强大的源码到源码翻译能力。Solar利用此能力进行经过验证的代码翻译，以实现自动化的光速推导。

## 3 方法

Solar通过一个三阶段流水线从源代码推导光速界限（LABEL:fig:overview）。首先，验证的智能体前端（第̃3.1节 (https://arxiv.org/html/2606.26383#S3.SS1)）将源程序翻译为可执行的*仿射循环中间表示*。确定性爱因斯坦求和生成（第̃3.2节 (https://arxiv.org/html/2606.26383#S3.SS2)）然后将验证过的IR编译为*爱因斯坦求和图*，即扩展爱因斯坦求和的有向无环图。最后，光速分析（第̃3.3节 (https://arxiv.org/html/2606.26383#S3.SS3)）阶段针对目标硬件规格计算多保真度屋顶线界限。

h

### 3.1 验证的智能体前端

本节描述了Solar流水线的第一阶段：一个语言无关的前端，它使用LLM智能体将张量程序翻译为称为*仿射循环IR*的可执行中间表示。关键思想是将LLM视为一个可编程、可重定向的解析器，其输出通过数值比较与原始程序进行验证。LLM代码生成不能被信任在第一次尝试时产生正确输出，因此数值验证通过提供具体的通过/失败信号来关闭此信任差距，该信号控制下游消费。

#### 3.1.1 仿射循环IR

使用LLM智能体作为爱因斯坦求和生成的前端对IR提出了四个要求：

1. 1.爱因斯坦求和提取。表示必须能够支持后端机械地提升为爱因斯坦求和。
2. 2.表达力。IR必须覆盖广泛的深度学习工作负载。
3. 3.LLM生成。IR必须易于LLM正确生成。
4. 4.验证。LLM生成的IR必须是可执行和可扩展的，以进行数值验证。

为了实现机械的爱因斯坦求和提取，同时保持表达力，仿射循环IR（图̃2 (https://arxiv.org/html/2606.26383#S3.F2)b）将程序分为两部分：受限的仿射循环内核，代表单个爱因斯坦求和算子，以及一个无限制的组合层，用于处理广泛的深度学习工作负载。

每个仿射循环内核都受到限制，以便可以从其结构机械地推导出爱因斯坦求和方程。一个@kernel函数包含一个或多个完全嵌套的循环嵌套，其变量命名的维度张量。循环界限是静态的张量形状常量，索引表达式是循环变量的仿射形式，没有数据相关的分支，循环体仅包含标量算术和一组固定的内建函数。

张量携带后端推导字节数所需的元数据。例如，`Tensor("B,M,K", dtype="fp16", role="weight", sparsity=0.5, fill=0)`声明了一个fp16权重张量，具有50%稀疏度和命名维度B、M和K。这些命名维度既是循环维度又是爱因斯坦求和下标，因此后端可以从循环嵌套推导出一个爱因斯坦求和方程。

为了覆盖广泛的深度学习工作负载，一个无限制的顶层组合层（`model()`）组合内核，调用库内建函数，并通过控制流表达循环。内建函数处理不适合仿射内核模型的模式：数据移动操作（reshape, slice, stack, concat）、数据相关索引（gather）以及稀疏操作（`apply_mask`，它传播张量的`sparsity`字段，以便下游字节和FLOP估计反映有效稀疏度）。

最后