数据库查询搬到GPU后，最慢的热点仍常靠工程师手写CUDA或Triton。IBM Research、维也纳工业大学提出DataKernelBench，把SQL先转成可验证的PyTorch张量计划，再让大模型在保持结果一致的前提下改写GPU内核。
基准在H100上覆盖TPC-H SF10的22条查询和10个闭源、开放权重模型。最强的全查询CUDA配置通过全部正确性检查，相对torch.compile平均加速2.11倍；在四张H100处理SF100数据时，分区执行达到2.54倍加速。
先把SQL变成能逐项核对的TorchPlan
大模型不直接改原始数据库引擎。系统先把SQL翻译成TorchPlan：表读取、连接和结果格式放在外层，张量密集热点放进_query_core。每份计划先与DuckDB结果做差分验证，只有语义一致的程序才进入内核生成。
论文示意：SQL先转成可执行TorchPlan，再由大模型生成融合CUDA或Triton内核。
评测分两种权限。core模式只能替换热点函数，full模式可以重写查询内部流程但必须保留外部接口。后者允许模型融合算子、减少中间结果和改变执行策略，空间更大，也更容易引入语义错误。
基准还固定数据规模、参数接口与计时方式。每个候选在正式计时前预热，运行时间取多次测量的中位数，并设置超时，防止错误内核挂住GPU。这样的协议把“代码能跑”和“代码确实更快”分开，也让不同模型的修复轮数与生成成本可以比较。
每轮生成都要过正确性和速度双门槛
模型输出完整模块后，系统比较列名、形状、行数和单元格。整数、日期和字符串必须完全一致，浮点数按精度设置容差。通过正确性后还要比编译TorchPlan至少快1.05倍，否则保留基线。
论文排行榜：十个模型在CUDA、Triton及不同优化范围下的通过率与加速。
GPT-5.5的CUDA-full配置通过率100%，平均2.11倍；Claude Sonnet 4.6为1.54倍，Claude Opus 4.7为1.51倍。开放权重模型中，Qwen3.5-397B-A17B与GPT-OSS-120B都达到1.26倍，但通过率分别为100%和86.4%。
加速来自融合和执行策略，不是所有查询都受益
逐查询结果差异很大。高分实现常把多个过滤、聚合步骤融合，避免中间张量落地；部分简单查询已经接近硬件带宽上限，可优化空间有限。论文发现，提供工作负载的表规模与数据类型，比追加硬件说明更能帮助模型写出有效内核。
论文逐查询对比：最佳模型生成内核与编译TorchPlan等基线的运行时间。
生成本身也有成本。论文用“要重复多少次才能省下一小时执行时间”衡量摊销门槛；这类特化更适合反复运行的报表和仪表盘查询，不适合只执行一次的临时SQL。
例如最佳配置平均每次生成成本约0.18美元，但不同查询省下的毫秒数差异很大。是否值得生成，取决于未来重复次数、GPU价格与内核维护周期。模型更新、CUDA版本变化或表结构改变后，原先通过的内核也需要重新验证，不能永久沿用一次基准结论。
从单卡基准走向生产数据库
当SF100数据超过单卡显存，系统用Dask-cuDF按需装载分区，在四张H100上执行，报告2.54倍加速。这个实验验证了分区路径，但并未覆盖真实数据库中的并发、更新、权限和故障恢复。
论文多GPU实验：数据按需分区装载，并比较不同GPU数量下的执行表现。
下一步要把已验证内核接入可回退的查询引擎：新数据分布或软件版本变化后重新校验，失败时回到通用计划。DataKernelBench提供的是“生成—执行—修复—验证”协议，不是允许模型未经检查把任意代码放进生产库。
生产验证还要覆盖空表、极端参数、空值和不同数据分布。TPC-H提供标准负载，却不能代表企业所有SQL语义。更稳妥的部署方式是让模型只生成隔离模块，在沙箱中跑回归测试和性能测试，达到门槛后再进入灰度流量，并保留随时切回编译计划的开关。
参考资料
https://arxiv.org/abs/2608.25061
https://arxiv.org/html/2608.25061
