NeurIPS'26 | 港科大：从CPU到GPU，AI能否真正加速全流程？

在科学仿真、金融计算、图算法和运筹优化等领域，一个常见的难题并不是「没有程序」，而是程序已经能算对，却跑得太慢。

把它交给GPU，也远不只是换一种编程语言。为评测大模型能否承担这项工作，研究团队提出AccelEval：从可信的CPU程序出发，检验AI能否生成结果正确、端到端更快的GPU实现。

该基准覆盖6个领域、42项计算任务和3种输入规模，还系统整理了43类 CUDA 优化策略，将评测进一步延伸到「为什么快，以及这些经验能否复用」。相关论文已被NeurIPS 2026接收。

论文链接：https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6835659

代码链接：https://github.com/Echoscd/AccelEval

CPU像博士生

GPU像几千个小学生

图1：用「几个博士生」和「几千个小学生」的类比解释CPU与GPU的工作方式。

想象两支解题队伍：一边是几个博士生，另一边是几千个小学生。前者适合处理复杂、需要灵活判断的任务；后者的优势，是让大量成员同时完成规则明确、能够拆分的计算。

在高性能计算中，GPU的优势来自大规模并行，就像数量众多的「小学生」，而CPU则擅长处理分支密集的任务，就像高度训练的「博士生」。

假设有一百万道彼此独立的算术题，把题目分给几千个人同时做，当然很有吸引力。但现实程序往往没这么简单。有些题必须等前面的答案出来才能开始；有些人会同时修改同一个结果；还有些任务，发题、传资料、收答案花的时间，比真正解题还长。

面对一个大的计算任务，哪些计算能同时做，怎样分配CPU和GPU的任务，谁需要等待谁，数据放在哪里，多个结果如何安全地合并，是个非常复杂、繁琐的问题。

以最短路径计算为例。要寻找从一个起点到其他地点的最短距离，一种做法是反复检查每条道路，看它能否带来更短的路线。若固定上一轮得到的距离，各条道路就能同时计算自己的候选结果；

但通向同一地点的候选结果必须取最小值，下一轮也必须在本轮完成后继续。图数据还应尽量留在 GPU 上，避免每轮来回搬运。

这时，AI要做的已经不只是「把代码翻译成CUDA」，而是读懂计算依赖，找到并行结构，再写出一套可执行的分工方案。

计算快了10倍

整个程序却可能变慢

图2：核心计算更快，并不意味着端到端程序更快；数据搬运和收尾开销也会影响整体耗时。

即使AI写出了一个很快的GPU内核，也不代表用户能更早拿到结果。

一个简单的假设例子就能说明问题：CPU完成任务需要10毫秒；换到GPU后，核心计算只需1毫秒，但准备与输入搬运花了6毫秒，收尾与输出搬运又花了6毫秒。

只看核心计算，似乎提速了10倍；但用户实际等了13毫秒，比原来还慢。⁠[2]

这也是 AccelEval 把「端到端」放在中心位置的原因。每个任务都通过统一的计算入口接收主机端输入、返回主机端输出，调用过程中必要的内存分配、数据传输、GPU计算和清理工作，都要纳入计时。评测还设置了审计机制，检查是否把本应计入的工作藏到了计时区间之外。

用户需要的不是某一小段代码更快，而是同一个任务，从输入到答案，真正少等一会儿。

已经有KernelBench

为什么还需要AccelEval？

当前，社区中已经有不少与GPU kernel生成和优化相关的基准，例如 KernelBench、TritonBench等。

它们推动了一个重要方向：让大模型根据PyTorch算子或深度学习计算，自动生成正确且高效的 GPU 实现。

但这类任务也有其天然特点。

深度学习中的大量常见算子，例如矩阵乘、归一化、卷积和attention，已经拥有相对成熟的并行化范式和长期积累的优化经验。

随着这些算子及其高性能实现广泛出现在开源框架、技术博客和代码仓库中，模型在这类任务上的表现，也可能同时受益于已有实现模式的广泛暴露。

因此，仅依赖这些熟悉的计算模式，很难完全回答另一个更一般的问题：当模型遇到一个并没有现成GPU模板可套用的程序时，它是否真的能够读懂计算结构，并自行设计合理的并行化方案？

AccelEval面向更真实的需求和更广泛的计算场景。深度学习算子通常定义清晰、结构规整、并行度高，也天然适合GPU，因此相关的并行化模式和优化经验已经相对成熟。

但在大量实际应用中，用户手里并不是一个已经划分好边界的深度学习算子，而往往只有一份能够正确运行、却随着问题规模增大而越来越慢的CPU程序。这样的程序可能包含多层循环、条件分支、复杂数据结构，以及跨阶段的计算依赖。

在这种情况下，GPU加速就不再只是把一个局部计算改写成CUDA，而是需要先理解整个程序的计算结构：哪些部分可以并行，哪些依赖必须保留，数据应该放在哪里，哪些计算值得融合，以及CPU和GPU之间如何分工。

AccelEval希望评测的，正是模型面对这类更开放、更异构的程序时，能否从一份可信的CPU实现出发，自主找到合适的并行化和加速方案。

42项任务评测

图3：AccelEval整体评测流程：从CPU参考程序出发，比较GPU结果正确性，并统计端到端速度提升。

AccelEval 包含42项任务，覆盖高性能计算、科学仿真、图算法、时空算法、金融计算和运筹优化6个领域。任务依据公开代码、已有计算套件和经典算法或研究问题整理，提取有实际算法意义的CPU计算，再统一输入输出接口。⁠

其中既有路径计算、粒子仿真和期权定价，也有多周期库存补货、网络收益管理、Gittins指数计算和一阶线性规划求解等运筹任务。

这样的范围，把问题从「AI能否写出某类熟悉的GPU算子」，拓展为「面对不同领域的计算结构，AI能否选对加速方式」。

每个任务都提供自然语言说明、CPU参考实现、固定接口，以及小、中、大3种规模的测试输入。模型提交的GPU版本首先要成功编译和运行，再在相同输入下与CPU输出比较；数值敏感任务采用预先规定的误差容限。只有先算对，性能数字才有意义。⁠

同时测试3种规模，则让评测能够看到另一件事：一种方案是在问题变大之后才体现出并行优势，还是在小任务上就被启动与搬运开销拖慢。⁠

「算得对」和「跑得快」是两种能力

论文在NVIDIA H200上评测了8个大模型，并进行了RTX 4090上的跨硬件测试。在每个任务只生成一次代码的设置下，Gemini 3.1 Pro在中规模、通过正确性验证的任务上，相对固定单线程CPU参考实现取得了71.2倍几何平均加速比；大规模时为161.5倍。⁠

这些结果说明，自动CPU-to-GPU加速已经具有实际潜力，但不能脱离测量条件理解：加速比只统计通过的任务，CPU 对照也是统一的单线程实现，并不是对经过充分调优的多线程CPU的普遍优势。⁠

更值得关注的是，模型之间存在不同的能力轮廓。有的模型能写对更多任务，但不一定能让这些任务跑得更快；有的实现已经通过测试，却仍然没有充分利用并行计算资源。仅看「答对多少题」，不足以刻画GPU加速能力。⁠

研究因此同时考察正确性覆盖、端到端加速，以及一个方案距离该任务中「受测模型的最佳正确实现」有多远。这里的最佳实现只是本次评测里观察到的最好结果，不是硬件或算法的理论最优。⁠

人工参考实现也提供了一个有用的参照：在11个具备人工CUDA基线的任务中，即使逐任务挑选8个模型中最快的正确方案，其相对人工参考实现的速度比，跨任务几何平均也约为0.75。自动加速的进展与尚待解决的难题，在同一套基准里同时可见。⁠

43类GPU「加速工程经验」

图4：AccelEval将通过验证的GPU代码分解为43类优化策略，并进一步开展两阶段策略迁移实验。

如果评测到排名就结束，我们能够知道了谁更快，却未必知道下一步该怎么改。

CUDA加速本身清晰的反馈信号很适合通过增大采样数做Agent进化迭代加速。假设我们在一份代码上有了1000次的尝试经验和1000份结果，单单通过评测的数字结果「100ms」「400ms」，我们很难得知模型是否真正找到了合适的加速策略和技巧。

因此，我们更应该关心：为什么这份代码跑了100ms，而另一份代码却跑了400ms？是什么样的代码结构导致了这种差距？

人类工程师通过长期实践，逐渐形成判断不同程序该如何加速的CUDA「工程经验」。

相比之下，LLM 可以在短时间内完成远多于人类的尝试，但这些实验往往彼此孤立，缺少跨任务的联系与总结。

因此大量试错很难真正转化为可积累、可迁移的优化能力。

AccelEval希望进一步建立一种可量化、可在不同任务之间迁移的框架，把一次次优化尝试沉淀成类似人类工程师的“工程经验”。

为此，研究团队首先在已有 GPU 优化知识的基础上，建立了43类 CUDA 优化策略目录，覆盖内存访问与复用、计算重构、并行组织、负载平衡和主机端协调。

研究结合静态代码检测与大模型代码分析，对231个通过验证的「模型与任务」组合进行策略分解，把性能结果与代码采用的做法对应起来。

这些策略并不只是几个编译选项。

例如，内核融合可以把连续的计算阶段合并，减少中间数据读写和多次启动；共享内存分块让一组线程复用已经搬到片上的数据；调整数据布局、循环顺序或算法选择，则可能直接改变一项工作在 GPU 上的分工方式。⁠

研究观察到，内核融合、分块、线程工作量调整等结构性优化，与更高的同任务性能表现有较强关联，而单个kernel内部细节的优化，往往收益较低。

这份策略目录的价值，在于把一次次生成和实验中隐含的优化经验显式地沉淀下来：不只记录哪个实现更快，也记录它为什么更快、采用了怎样的计算组织方式。

结语

图5：任务特定策略指导带来的整体提升（1.78×）明显高于长度匹配的通用建议（1.18×）。

过去几年，大语言模型已经不断刷新人们对“机器会思考到什么程度”的想象：它们会做数学题、写代码、证明定理，也在越来越复杂的推理任务上逼近人类专家。

但真正更令人期待的，也许不是AI还能答对多少题，而是这些能力何时能够走出屏幕，进入真实世界的生产流程。

如果未来的模型不仅会生成代码，还能像工程师一样理解系统、发现瓶颈、总结经验并持续优化，那么AI带来的改变，就不再只是「帮人完成任务」，而是开始直接参与计算、工程乃至工业系统本身的演进。

AccelEval希望探索的，正是这样的下一步：让AI不只读懂世界如何运转，也开始成为推动世界运转的一部分。

参考资料：

https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6835659

文章来自于微信公众号 “新智元”，作者 “新智元”