FastKernels：生产环境中GPU内核生成的基准测试 FastKernels: Benchmarking GPU Kernel Generation in Production
首个生产级GPU内核生成基准，解决基准与生产环境不匹配问题
前置知识
GPU内核
GPU内核是运行在GPU设备上的并行计算函数，用CUDA或Triton等语言编写。在深度学习推理中，内核负责执行矩阵乘法、注意力机制、归一化等计算密集型操作。内核的性能直接影响模型推理速度，优化内核需要考虑内存访问模式、线程调度、共享内存使用等多个硬件层面的因素。
论文的核心就是评估和优化GPU内核生成，理解内核在推理框架中的作用和性能瓶颈是读懂本文的基础。
vLLM和SGLang
vLLM和SGLang是主流LLM推理框架，通过PagedAttention、连续批处理等优化技术提升吞吐量。内部使用大量优化的GPU内核（FlashAttention-3、cuBLAS等），代表生产环境LLM推理最佳实践。
论文将vLLM和SGLang作为生产级基线，理解它们的工作原理有助于理解为什么现有基准与生产环境不匹配。
算子融合
算子融合将多个连续操作合并为一个GPU内核执行，减少内存读写和启动开销。例如融合残差连接、RMSNorm和量化。融合显著提升性能，是生产框架优化推理的关键技术。
论文的L2级任务专门针对融合操作符，理解融合机制有助于理解为什么简单基准测试无法评估真实性能。
多GPU通信
多GPU通信是分布式推理中GPU间数据传输，包括all-reduce、reduce-scatter、all-to-all等。MoE模型需要all-to-all分发token。NCCL是常用通信库，性能受网络带宽、延迟和通信计算重叠影响。
论文首次在内核基准测试中包含多GPU通信内核，这是理解论文创新点和评估现有代理性能下降原因的关键。
研究动机
现有GPU内核生成基准测试与生产推理框架严重不匹配。具体来说，KernelBench、SOL-ExecBench等现有基准存在四个核心问题：第一，使用合成输入而非真实推理时产生的张量，导致评估结果无法反映实际负载特征；第二，在单GPU上评估孤立内核，忽略了多GPU通信模式（如tensor-parallel all-reduce、expert-parallel all-to-all）对端到端延迟的影响；第三，使用简化接口而非生产模块的真实接口，导致优化后的内核无法直接部署到vLLM、SGLang等框架；第四，各层级任务相互独立，无法组合成完整推理管道。这些问题导致Agent在沙箱中生成高分的内核，但集成到真实系统时会出现接口不兼容、编译堆栈冲突、正确性退化等问题。
本文的目标是本文的目标是构建一个与生产环境高度对齐的GPU内核生成基准测试，使基准测试中获得的性能提升能够直接转化为生产环境中的吞吐量改进。具体而言，FASTKERNELS要实现以下目标：作为最小化的生产级推理框架运行，与vLLM和SGLang在主流LLM服务上达到同等性能；提供从原语操作符到完整模型的组合式任务层次；每个任务的接口与对应生产库中的模块匹配；捕获并回放生产模型实际馈送给内核的张量；包含多GPU通信内核；提供端到端验证和跨架构的统一评估指标。
与已有工作不同的是，本文的独特切入角度是"基准测试即框架"的设计理念。与传统基准测试将任务与评估环境分离的做法不同，FASTKERNELS本身就是一个可用的推理框架，评估就在真实推理管道中进行。这使得优化后的内核不需要移植就能获得端到端性能数据。另一个独特角度是自上而下的任务构建：从46个真实模型架构开始，递归分解为组成它们的内核，每个内核都可追溯到特定模型的特定层。这确保了没有任何合成任务，所有任务都对应真实推理中执行的操作。此外，FASTKERNELS首次将多GPU通信内核纳入基准测试，填补了单GPU基准无法评估分布式推理性能的空白。
核心方法
FASTKERNELS采用"基准测试即框架"的设计理念，构建了一个自包含的推理框架，其任务接口与生产模块匹配，因此优化后的内核可以在原地评估并直接转移到vLLM、SGLang等系统。框架灵感来自nanoGPT，实现了连续批处理、分块prefill、多模态输入和OpenAI兼容的服务API。FASTKERNELS从46个真实模型架构自上而下推导所有任务，确保每个内核都可追溯到特定模型的特定层。任务分为四个组合层级：L1原语操作符（注意力变体、归一化、激活、位置编码等）、L2融合操作符（自然融合机会如残差连接+RMSNorm+量化、注意力+输出投影、MoE门控+分发+专家计算）、L3完整层和块（transformer解码器层、SSM扫描块、带路由的MoE层等）、L4端到端模型架构（完整模型推理路径）。L1-L3支持隔离内核优化和快速迭代，L4测试优化在完整模型管道中是否正确组合并保持质量。
FASTKERNELS的核心创新点有五个。第一，基准测试即框架设计：FASTKERNELS是自包含推理框架，任务接口匹配生产模块，优化内核可在原地评估并直接部署到vLLM、SGLang等系统。第二，组合式任务层次：任务从原语到融合操作符、层和完整模型递进，允许Agent在优化高级模块时重用低级优化（如优化MLP时重用已优化的线性算子），而不是从头重新发现相同的构建块。第三，生产级评估：使用生产基线（cuBLAS、FlashAttention-3、FlashInfer、vLLM CUDA ops、deep_gemm、FLA recurrents、custom-IPC all-reduce而非PyTorch eager）、捕获的张量、编译堆栈效应和多GPU通信模式。第四，端到端验证和指标：将生成内核注入完整模型执行，检查下游质量，报告MACROEVAL，结合校准正确性、覆盖率和跨模型族的端到端吞吐量-延迟加速比。第五，广泛架构覆盖：46个架构跨越8大类——密集和MoE LLM、线性和新架构、视觉/音频/视频、3D/机器人、推荐和世界模型——对比生产基线而非硬件理论边界。
方法步骤详情
FASTKERNELS的方法包含四个主要步骤。第一步是自上而下的模型驱动任务构建：对于每个模型架构，加载HuggingFace配置和架构定义，遍历前向传播，为每个计算内核产生独立任务实现，所有配置常量（隐藏大小、注意力头数、数据类型）从模型配置内联。每个任务都经过审核以验证：(i)参考实现的语义正确性，(ii)任务捕获模型中实际执行的操作符（而非简化代理），(iii)张量形状和数据类型匹配模型真实配置，(iv)任务接口匹配对应生产参考库中的模块。第二步是组织任务为四个组合层级：L1原语操作符（注意力、归一化、激活、位置编码、量化/反量化例程）、L2融合操作符（自然融合机会）、L3完整层和块（完整架构块）、L4端到端模型架构（完整模型推理路径）。第三步是接口兼容设计：对于每个模型架构族，识别对应最先进生产库（如LLM的vLLM、服务的SGLang），设计每个任务的接口（__init__构造函数签名和forward方法）以紧密匹配该库中对应模块。第四步是评估堆栈暴露：FASTKERNELS通过三个递增范围的基准测试层级向用户和Agent暴露相同的评估堆栈。Tier 1 Kernel运行内核级基准：候选操作符与基线模块并排实例化，复制权重，从形状、数据类型和初始化参数的输入注册表比较forward()输出和运行时。Tier 2 E2E运行端到端模型基准，测量完整模型吞吐量、延迟和用户指定工作负载下的服务行为。Tier 3 Eval运行标准化评估扫描，在固定模型、张量并行配置和吞吐量-延迟工作负载上比较基线和候选执行。
技术新颖性
FASTKERNELS的技术新颖性体现在五个方面。第一，首次在内核基准测试中包含多GPU通信内核，覆盖张量并行的all-reduce/reduce-scatter、专家并行的MoE路由all-to-all分发和组合（DeepSeek-V3、Mixtral），以及必须隐藏NCCL集合通信在计算背后的重叠内核。在单GPU基准中无法访问这些任务，一个在单GPU上实现$1.5 imes$加速的内核如果破坏通信调度仍可能降低端到端吞吐量。第二，首次将任务组织为从原语到完整模型的组合层次，镜像生产组装。现有基准的层级是独立的，而FASTKERNELS的层级使能动态规划风格的优化循环：Agent可以在优化高级模块（如MLP或transformer块）时重用已优化的低级内核（如线性算子），而不是从头重新发现相同的构建块。第三，首次测量加速比对比生产框架实际shipped的内核（cuBLAS、FlashAttention-3、FlashInfer、vLLM CUDA ops、deep_gemm、FLA recurrents、custom-IPC all-reduce）而非参考PyTorch eager或理论边界。一个在torch-eager基线上双倍的内核可能仍比推理引擎实际调用的慢。第四，首次匹配生产模块接口，使能复制-粘贴部署到vLLM、SGLang等SOTA框架。FlashInfer-Bench的FIApply在内核分发级别（FlashInfer内部抽象）替代，而FASTKERNELS的兼容性在模块级别——生产框架实际使用的组合单元。第五，首次捕获并回放生产模型实际馈送给内核的张量。MoE路由研究显示合成输入显著改变负载偏斜和热专家身份。
实验结果
论文评估了FASTKERNELS在46个代表性基准上对比每个架构族的最先进生产推理框架（如LLM的vLLM、服务的SGLang、SDXL的diffusers、线性注意力的FLA、视觉编码器的timm）的端到端性能和每个L1-L4任务的数值正确性。结果显示FASTKERNELS平均达到$1.24 imes$吞吐量（中位数$1.04 imes$），但分布是双峰的：在主流LLM服务对抗硬化框架如vLLM和SGLang时，FASTKERNELS处于同等水平（Llama-3.1 $1.04 imes$、GPT-OSS $1.02 imes$、Mixtral $0.97 imes$、DeepSeek-V3.2 $0.84 imes$）；超单位增益集中在唯一可用参考是研究库或非服务库的架构上（Pi0 $3.48 imes$、ColBERTv2 $3.08 imes$、CosyVoice3 $2.13 imes$、RetNet/GLA约$1.86 imes$ vs FLA），其中生产级调度和KV缓存路径转化为服务不足工作负载的大端到端增益。对齐在模态间保持一致强：自回归模型保持与其参考的token或rank高协议，而视觉、检测、检索、图形和推荐模型通常在任务特定相似性检查下精确或接近精确。在评估现有内核生成代理方面，论文在FASTKERNELS L1和L2上运行三个内核生成代理（Dr. Kernel、KernelAgent、OpenAI Codex），每个架构族一个代表模型（$48$ L1 + $40$ L2 = $88$目标族），报告相同任务图上MACROEVAL的内核级类似物：每个目标的覆盖率、正确性和对抗生产塑形FASTKERNELS参考在捕获输入上的几何平均加速比。在FASTKERNELS上，所有三个代理都低于$1 imes$聚合：Codex $0.943 imes$、KernelAgent $0.777 imes$、Dr. Kernel $0.527 imes$。这与这些代理在参考是PyTorch eager的操作符级基准上报告的超单位数字形成对比。按参考类型拆分Codex的48 L1结果使这具体化：22个torch-eager包装族$1.16 imes$几何平均 vs 26个供应商或手写内核$0.93 imes$，所以一旦对比锚定到可部署基线，大部分操作符级增益消失。大于$1 imes$的胜利集中在没有专用生产内核的操作符上（layer_norm $3.72 imes$、conv3d $3.41 imes$）；小于$1 imes$的损失集中在生产热路径上（moe_align $0.28 imes$、linear $0.56 imes$、flashinfer_decode/prefill $0.71 imes$、allreduce $0.84 imes$）。所有到达L2的代理在L2上都退化：KernelAgent从$26/40$正确（$0.79 imes$）降到$2/36$（$0.629 imes$）；Codex保持$100\%$正确性但从$1.03 imes$降到$0.84 imes$；Dr. Kernel产生$0$个正确L2内核（$0/3$）。L2失败主要由句法有效但违反周围生产合同的内核主导（如attention、fused_experts、qwen3_moe、gpt_oss_moe、parallel_linear）。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Production Inference Framework Performance | Throughput Speedup | 1.24× average (1.04× median) across 46 architectures | vLLM, SGLang, diffusers, FLA, timm, etc. | Parity on mainstream LLMs (0.97-1.04×), substantial gains on under-served architectures (Pi0 3.48×, ColBERTv2 3.08×, CosyVoice3 2.13×) |
| Kernel Generation Agent Evaluation (L1) | Geometric Mean Speedup | Codex 1.03×, KernelAgent 0.79×, Dr. Kernel 0.53× | Production-shaped FASTKERNELS reference | All agents below parity, in contrast to sup-unity numbers on operator-level benchmarks with PyTorch eager reference |
| Kernel Generation Agent Evaluation (L2) | Geometric Mean Speedup | Codex 0.84×, KernelAgent 0.63×, Dr. Kernel 0× (no correct kernels) | Production-shaped FASTKERNELS reference | Significant L1→L2 regression for all agents, indicating production-shaped composite modules are harder than primitives |
| HuggingFace Transformers Coverage | Architecture Coverage | 96.2% (409/425) | All PyTorch models in HF Transformers (commit da6c53e4) | Minimum set of 46 architectures covers overwhelming majority with only 5 requiring genuinely new kernel and 2 requiring external library |
局限与改进
论文承认了几个限制性因素。首先，由于计算和人工审查时间的限制，代理研究只涉及L1+L2；L3/L4 harness随框架一起提供但不用于主要数字。其次，$96.2\%$ HuggingFace覆盖率数字依赖于手动审核的映射，该映射有手动验证的正和无覆盖裁决和抽查的覆盖裁决，所以最好读作指示性上界。第三，性能在锁定时钟H100 SXM5上测量；B200、MI300X或消费GPU上的排名可能不同，应在目标硬件上重新运行。第四，MACROEVAL的等族权重、$\lambda=0.5$ blend和乘积分数-正确性-覆盖率乘积编码价值判断；我们分别报告组件指标以便特定工作负载的重新聚合直接明了。我观察到的额外限制包括：FASTKERNELS目前专注于推理工作负载，未涵盖训练场景；框架主要在NVIDIA GPU上评估，AMD和Intel GPU的支持可能有限；捕获的张量虽然来自真实执行，但可能无法覆盖所有可能的输入分布，特别是在长尾边缘情况下；评估主要关注吞吐量和延迟，未深入分析内存占用、能效等其他重要生产指标。
独立分析的弱点
FASTKERNELS的第一个弱点是架构覆盖虽然声称96.2% HuggingFace兼容性，但这基于手动审核的映射，可能存在遗漏或错误。特别是对于非常新的或小众的架构，可能需要添加新内核。改进方向是自动化架构到内核映射的审核过程，并建立社区贡献机制。第二个弱点是代理研究仅限于L1+L2，L3/L4的评估尚不充分。虽然L3/L4 harness已提供，但缺乏在完整模型层面评估Agent能力的实验数据。改进方向是扩展评估到L3/L4，特别是端到端模型级别的性能和正确性。第三个弱点是性能测量仅在H100 SXM5上进行，缺乏在其他硬件（B200、MI300X、消费GPU）上的验证。不同GPU架构的性能特征可能不同，基线内核的选择也可能需要调整。改进方向是在多种GPU硬件上运行完整评估套件。第四个弱点是评估指标主要关注吞吐量和延迟，对内存占用、功耗、部署难度等其他生产重要因素关注不足。改进方向是扩展MACROEVAL指标体系，包含内存效率、能效等维度。第五个弱点是虽然声称生产级接口兼容，但实际部署到vLLM/SGLang等复杂框架可能仍需要处理版本差异、内部API变化等细节问题。改进方向是提供更详细的部署指南和自动化兼容性测试工具。
未来方向
论文提出的未来工作方向包括扩展代理研究到L3/L4层级，在完整模型上评估Agent能力；在B200、MI300X和消费GPU上重新运行评估以验证排名的硬件鲁棒性；将FASTKERNELS任务集扩展到覆盖剩余的HuggingFace架构，特别是需要 genuinely new kernel的5个架构和需要外部库的2个架构；增强多GPU通信内核覆盖，包括更多分布式推理模式（如流水线并行、数据并行）；集成更多生产框架作为参考基线（如TensorRT-LLM、TGI）。基于论文成果可延伸的额外方向包括：将FASTKERNELS扩展到训练场景，涵盖反向传播内核；开发专门针对MoE架构的评估指标和测试集；集成到CI/CD流水线，使内核优化成为模型部署的标准步骤；开发专门针对特定硬件（如移动GPU、TPU）的FASTKERNELS变体；建立社区驱动的内核优化排行榜，鼓励Agent开发；探索将FASTKERNELS与自动调优工具（如AutoTVM、Triton MLIR）结合的混合优化方法；开发针对多模态模型的端到端评估指标；研究内核优化与模型压缩（量化、剪枝）的联合优化。
复现评估
论文声称将FASTKERNELS作为开源代码发布在https://github.com/Snowflake-AI-Research/fastkernels，这是复现性的良好基础。然而，复现论文中的具体实验仍面临几个挑战。硬件方面，论文在锁定时钟H100 SXM5上测量性能，这种高端GPU的获取成本很高，且锁频操作需要专业设置。软件方面，需要安装特定版本的vLLM、SGLang、FlashInfer等生产框架作为基线，版本兼容性可能带来问题。数据方面，虽然使用HuggingFace模型和公开数据集，但"捕获的张量"需要从特定模型执行中获取，这涉及精确的工作负载定义和执行环境配置。代理评估方面，论文使用Dr. Kernel、KernelAgent和OpenAI Codex，但这些系统的版本和配置参数未详细说明，复现相同结果可能需要精确复现环境。评估指标方面，MACROEVAL的实现细节（每个族的(g_i, f_i, τ_i)阈值表）虽声称在附录C中提供，但实际复现需要仔细实现校准正确性、覆盖率等计算。总体而言，论文的复现难度中等到高，主要是因为硬件要求和复杂的软件栈依赖，但开源代码和详细的方法描述提供了必要的复现基础。
论文图表
