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加速能力。⁠ 研究因此同时考察正确性覆盖、端到端加速，以及一个方案距离该任务中「受测模型的最佳正确实现」有多远。这里的最佳实现只是本次评测里观察到的最好结果，不是硬件或算法的理论最优。⁠ 人工参考实现也提供了一个有用的参照：在