DataKernelBench: LLMs能否优化GPU数据库查询？

# DataKernelBench：LLM能在GPU上优化数据库查询吗？
来源：https://arxiv.org/html/2608.25061  
rmTeXGyreTermesX

Gokul Karthik KumarYotam Perlitz附属机构：IBM Research, Zurich, SwitzerlandCorey Lammie附属机构：IBM Research, Zurich, Switzerland Andrea Giovannini附属机构：IBM Research, Zurich, SwitzerlandKatja Hose附属机构：gok@zurich\.ibm\.com, y\.perlitz@ibm\.com, corey\.lammie@ibm\.com,附属机构：agv@zurich\.ibm\.com, katja\.hose@tuwien\.ac\.at附属机构：TU Wien, Vienna, Austria

###### 摘要

GPU正日益加速数据库系统，但针对特定查询的峰值性能通常仍依赖手写内核。现有的LLM内核基准测试主要关注机器学习算子，未能测试不规则、异构、数据搬运密集的数据库风格算子。我们推出DataKernelBench111https://kerneldf.github.io/datakernelbench，它将SQL翻译成经过验证的PyTorch TorchPlan程序，并评估那些通过执行引导修复来优化核心张量受限片段或完整查询（在CUDA或Triton中实现）的LLM。在H100 GPU上，使用TPC-H SF10数据集对十款闭源和开源模型进行测试，最强的完整查询CUDA配置在完全通过率下实现了2.11倍于torch.compile的加速。我们发现，高性能实现通常使用内核融合和执行策略变更；更强的模型从完整查询特化中获益最多；且工作负载上下文比硬件上下文更重要。为处理超出GPU内存的数据，我们使用Dask-cuDF扩展了TorchPlan，支持在四块H100 GPU上对TPC-H SF100进行按需分区加载，实现了2.54倍的加速。

参考图注 图1：DataKernelBench测试LLM在GPU内核生成以优化数据库查询方面的表现，其中多个模型在NVIDIA H100上的TPC-H SF10数据集上实现了100%通过率，并较TorchPlan基线获得显著加速。详见表1（https://arxiv.org/html/2608.25061#S3.T1）和第4.2节（https://arxiv.org/html/2608.25061#S4.SS2）。
## 1引言

大规模的人工智能基础设施投资（国际数据公司（IDC），2025 (https://arxiv.org/html/2608.25061#bib.bib34)）已使GPU在企业环境中日益普及（Gartner, Inc., 2025 (https://arxiv.org/html/2608.25061#bib.bib35)）。与此同时，许多分析型工作负载的执行模式可以从GPU硬件中受益：对列式数据进行大规模扫描、谓词求值、连接和聚合，能展现出显著的数据并行性，并对内存带宽提出高需求。这种组合使得GPU加速成为分析数据处理一个越来越有吸引力的方向（Yogatama et al., 2026 (https://arxiv.org/html/2608.25061#bib.bib44)），尤其是对于执行频率高、其成本足以证明值得进行查询特定优化的查询。

一种实用的方法是**张量查询处理**（TQP）（He et al., 2022 (https://arxiv.org/html/2608.25061#bib.bib18)；Asada et al., 2022 (https://arxiv.org/html/2608.25061#bib.bib19)），它将连接、过滤和聚合等关系算子映射到张量计算，使得数据库工作负载可以在成熟的机器学习（ML）框架（如PyTorch）上运行。近期研究表明，这种方法支持在现代多GPU系统上进行TB级数据分析（Wu et al., 2025 (https://arxiv.org/html/2608.25061#bib.bib20)）。这些趋势引出了一个自然的问题：如果分析查询可以表达为张量程序，那么最新的代码LLM能否合成出优于通用编译的专用GPU内核？

这个问题之所以重要，是因为通用ML编译器在分析工作负载上通常无法达到峰值性能。尽管torch.compile对于规则的、计算密集的神经网络算子是有效的，但分析查询通常涉及不规则的内存访问、复杂的谓词、异构算子组合以及特定于查询的融合机会。因此，峰值性能通常仍需手写的定制GPU内核，然而即使对于执行频繁的报告查询，编写和维护这些内核的成本也很高（Marcus, 2023 (https://arxiv.org/html/2608.25061#bib.bib33)；Wehrstein et al., 2026 (https://arxiv.org/html/2608.25061#bib.bib17)）。

LLM的最新进展（OpenAI, 2023 (https://arxiv.org/html/2608.25061#bib.bib26)；Bai et al., 2022 (https://arxiv.org/html/2608.25061#bib.bib28)；Qwen Team, 2026a (https://arxiv.org/html/2608.25061#bib.bib6)；Team, 2024 (https://arxiv.org/html/2608.25061#bib.bib50)；Jain et al., 2024 (https://arxiv.org/html/2608.25061#bib.bib43)；Liu et al., 2024 (https://arxiv.org/html/2608.25061#bib.bib42)）为减轻这种工程负担提供了一条有希望的途径。先前的研究表明，LLM可以为硬件加速生成专用的CUDA和Triton内核（Woo et al., 2025 (https://arxiv.org/html/2608.25061#bib.bib21)；Dai et al., 2026 (https://arxiv.org/html/2608.25061#bib.bib22)；Liao et al., 2025 (https://arxiv.org/html/2608.25061#bib.bib23)；Lange et al., 2025 (https://arxiv.org/html/2608.25061#bib.bib24)；Baronio et al., 2026 (https://arxiv.org/html/2608.25061#bib.bib25)），而近期的基准测试如KernelBench（Ouyang et al., 2025 (https://arxiv.org/html/2608.25061#bib.bib1)）、TritonBench（Li et al., 2025 (https://arxiv.org/html/2608.25061#bib.bib2)）和MultiKernelBench（Ouyang et al., 2025 (https://arxiv.org/html/2608.25061#bib.bib1)）在ML算子上评估了这种能力。然而，这些基准测试关注的是具有可预测结构的规则张量计算。分析查询则可能涉及大量数据搬运、组合多个关系算子，并需要在数据依赖的控制流下保持严格正确性。因此，在以ML为中心的内核合成基准测试上表现良好，并不能证明LLM能处理数据库风格的工作负载。

为解决这一差距，我们推出了**DataKernelBench**，用于评估LLM生成的GPU内核在分析查询处理中的表现。对于每个查询，我们首先将SQL翻译成一个经过验证的PyTorch张量程序，我们称之为**TorchPlan**。TorchPlan作为一个可进行基准测试的中间表示：它保留了SQL语义，同时为内核合成了一个稳定的优化目标。它将`run_query`中的表处理与`_query_core`中的张量密集型热路径分离，支持在两个级别上进行受控特化：**核心**级别，仅热路径可被替换；以及**完整**级别，可以在保持外部API不变的同时重写完整的内部查询实现。每个基线TorchPlan在内核生成前，通过将其输出与DuckDB（Raasveldt and Mühleisen, 2019 (https://arxiv.org/html/2608.25061#bib.bib16)）比较进行验证。然后，我们要求LLM在多轮执行引导修复循环中注入优化的Triton或CUDA内核。

我们的主要基线是编译后的TorchPlan执行，因为TorchPlan提供了一个经过验证的张量参考，而torch.compile是该执行模型内最强的通用基线。因此，该基准测试衡量的是定制LLM生成内核相对于强大的编译张量基线的增量收益。我们还与外部系统（如Sirius（Yogatama et al., 2026 (https://arxiv.org/html/2608.25061#bib.bib44)）和DuckDB）进行了比较，但这些比较回答的是一个不同的系统问题：独立执行引擎运行该工作负载有多快？Sirius最好被视为一个通用的GPU专用数据库系统，它为现有的CPU数据库引擎提供即时GPU加速，而我们的方法则针对特定、频繁执行的查询生成定制内核。

DataKernelBench针对的是定期执行的查询，如定时报告和仪表盘刷新，其中相同的查询模板在刷新的数据上运行，使用不同的用户提供的参数，或两者兼有。在特化之前，部署可以比较预测的生成成本与未来运行中预期的执行时间或计算成本的降低。只有在经过验证并且预期节省足以证明特化合理时，才会采用生成的内核；否则，执行将回退到编译的TorchPlan或通用GPU查询引擎。表1（https://arxiv.org/html/2608.25061#S3.T1）报告了这样一个运行时阈值，即**Nsave1hN\_{\mathrm{save1h}}**。作为一个可能的集成路径，生成的CUDA内核可以包装成Velox等可扩展引擎中的GPU算子，其DriverAdapter支持算子替换、融合和添加（Velox, 2022 (https://arxiv.org/html/2608.25061#bib.bib15)）。

通过DataKernelBench，我们评估了十款闭源和开源LLM在CUDA和Triton后端以及两个优化级别上的表现（第4节（https://arxiv.org/html/2608.25061#S4））。收益高度依赖查询，且最佳的LLM优化内核是对通用GPU数据库系统的补充而非统一替代。执行计划分析将最大的收益归因于内核融合和避免中间物化的执行策略变更。我们还提供了超出单个GPU内存限制的初步证据，通过在四个H100 GPU上按需使用Dask-cuDF分区执行TPC-H SF100（第4.5节（https://arxiv.org/html/2608.25061#S4.SS5)）。

这项工作做出了三项贡献。首先，据我们所知，我们引入了第一个用于评估LLM为数据库查询（而非ML算子）生成GPU内核的系统性基准测试。其次，我们提供了一个经过验证的SQL到TorchPlan的流程，以及模块化的Python TorchPlan程序，这些程序提供了一个对LLM友好的优化目标，并作为内核合成的可插拔参考实现。第三，我们对十款LLM的评估，刻画了模型强度、优化范围、提示上下文、编程接口和查询结构如何影响正确性和性能，并使用执行计划级别的比较来解释最大收益的来源。

## 2相关工作

### 2.1数据库、GPU与分析处理

GPU加速的分析处理通过模块化库和完整数据库系统进行推进。诸如libcudf和RAPIDS cuDF（RAPIDS, 2023 (https://arxiv.org/html/2608.25061#bib.bib14)）之类的库加速了数据框风格的工作负载（Pandas, 2020 (https://arxiv.org/html/2608.25061#bib.bib12)），而像Velox（Velox, 2022 (https://arxiv.org/html/2608.25061#bib.bib15)）这样的可组合引擎则探索了如何将专用算子库集成到灵活的流水线中。其他工作则开发了GPU专用的数据库系统，如Sirius（Yogatama et al., 2026 (https://arxiv.org/html/2608.25061#bib.bib44)）、Kinetica（Kinetica, 2026 (https://arxiv.org/html/2608.25061#bib.bib40)）和SQream（SQream Technologies, 2026 (https://arxiv.org/html/2608.25061#bib.bib41)）。在更低的层面，Kernel Weaver（Wu et al., 2012 (https://arxiv.org/html/2608.25061#bib.bib46)）表明，自动融合的GPU内核可以显著减少关系工作负载中的冗余数据搬运。这些结果强化了为分析型GPU处理进行特化的价值，但它们操作的层面是完整的执行系统、编译器框架或固定的关系原语。相反，我们的重点是评估LLM能否在现有的基于张量的查询流水线内，为分析查询合成*定制内核*。

我们的工作在精神上最接近**张量查询处理**（TQP）（He et al., 2022 (https://arxiv.org/html/2608.25061#bib.bib18)；Asada et al., 2022 (https://arxiv.org/html/2608.25061#bib.bib19)），该方法将关系算子映射到ML运行时上的张量计算。后续工作缩小了SQL算子和张量操作之间的不匹配（Zhang et al., 2025 (https://arxiv.org/html/2608.25061#bib.bib48)），并支持直接在压缩数据上执行（Huang et al., 2025 (https://arxiv.org/html/2608.25061#bib.bib49)）。最近的研究也表明，基于张量的查询处理可以扩展到TB级多GPU分析（Wu et al., 2025 (https://arxiv.org/html/2608.25061#bib.bib20)）和分布式、存储常驻的OLAP（Luo et al., 2025 (https://arxiv.org/html/2608.25061#bib.bib45)）。然而，编译后的张量执行并未消除特化的需求：分析查询通常涉及不规则的访问模式、异构的算子以及特定于查询的融合机会，这些在通用编译中会暴露出泛化天花板。DataKernelBench旨在评估LLM生成的内核能否弥合这一差距。

### 2.2人工智能与GPU用于内核合成

代码LLM的最新进展推动了用于硬件加速的自动化内核生成的进步（OpenAI, 2023 (https://arxiv.org/html/2608.25061#bib.bib26)；Bai et al., 2022 (https://arxiv.org/html/2608.25061#bib.bib28)；Qwen Team, 2026a (https://arxiv.org/html/2608.25061#bib.bib6)；Zeng et al., 2025 (https://arxiv.org/html/2608.25061#bib.bib4)）。诸如TritonRL（Woo et al., 2025 (https://arxiv.org/html/2608.25061#bib.bib21)）、CUDA Agent（Dai et al., 2026 (https://arxiv.org/html/2608.25061#bib.bib22)）和KernelEvolve（Liao et al., 2025 (https://arxiv.org/html/2608.25061#bib.bib23)）等系统迭代地合成和优化CUDA或Triton内核，表明基于LLM的内核生成是实现硬件特化的一条可行途径。现在有几个基准测试系统地评估了这种能力。KernelBench（Ouyang et al., 2025 (https://arxiv.org/html/2608.25061#bib.bib1)）、TritonBench（Li et al., 2025 (https://arxiv.org/html/2608.25061#bib.bib2)）和MultiKernelBench（Wen et al., 2025 (https://arxiv.org/html/2608.25061#bib.bib3)）测量了LLM生成内核在不同硬件目标和编程抽象下的通过率和性能。

这些基准测试是我们工作的重要方法论基础，但它们的核心是机器学习算子，其中的计算通常是稠密的、规则的，并由同质张量原语主导。分析查询处理则结合了具有不规则数据访问和严格输出语义的异构关系算子。DataKernelBench在借鉴这些先前基准测试评估风格的同时，将目标领域从ML内核转向了数据库风格的分析工作负载。

### 2.3人工智能与数据系统

人工智能很早就应用于数据系统，最初是用学习组件（如学习型查询优化器（Marcus et al., 2019 (https://arxiv.org/html/2608.25061#bib.bib37)）和学习型索引（Kraska et al., 2018 (https://arxiv.org/html/2608.25061#bib.bib36)））替代手工设计的启发式方法。随着LLM的兴起，数据系统中的AI已从面向用户的接口（如文本转SQL（Li et al., 2024 (https://arxiv.org/html/2608.25061#bib.bib38)；Gao et al., 2024 (https://arxiv.org/html/2608.25061#bib.bib39)））扩展到自动化系统合成。与我们工作最接近的一系列工作是Bespoke OLAP（Wehrstein et al., 2026 (https://arxiv.org/html/2608.25061#bib.bib17)），它合成了特定于工作负载的数据库引擎，以超越DuckDB（Raasveldt and Mühleisen, 2019 (https://arxiv.org/html/2608.25061#bib.bib16)）等通用系统。我们的工作在范围和接口上有所不同：我们不是生成一个独立的数据库引擎，而是研究LLM能否合成*可插拔的GPU内核*，以加速经过验证的TorchPlan流水线内的特定瓶颈。

参考图注 图2：从SQL到TorchPlan再到LLM合成的TPC-H Q6融合GPU内核。\(A\)带有参数化字面量的SQL。\(B\)TorchPlan，其中`run_query`处理cuDF表处理，`_query_core`定义了基线中由torch.compile优化的张量热路径。\(C\)核心级别的LLM生成融合Triton实现。类似的CUDA示例见图5（htt