让 AI 把 CPU 程序改成 GPU 代码：难的不只是翻译，是「端到端更快」

很多搞科学仿真、金融计算、图算法和运筹优化的人，遇到的真问题不是「这段代码跑不出来」，而是「它算得对，就是慢」。慢到问题规模一大，一天一夜等一个结果。这时候想着把代码交给 GPU，本来是很自然的念头——可一动手才发现，这不是换个语言重写那么简单。

港科大团队这次投到 NeurIPS 2026 的论文，核心就围绕这件事。他们做了一个叫 AccelEval 的基准：从一份能跑对的 CPU 程序出发，看大模型能不能生成一个结果正确、而且端到端更快的 GPU 实现。「端到端」这三个字是有意的。论文、代码都已公开，链接放在文末。

「核心计算快 10 倍，整个程序反而更慢」

为什么要强调端到端？因为他们很清楚，很多评测容易骗人。论文里给的假设例子很直观：CPU 跑完一个任务要 10 毫秒；换成 GPU，核心计算只要 1 毫秒，看着提速 10 倍。但准备和输入搬运花了 6 毫秒，收尾和输出搬运又花 6 毫秒——用户实际等了 13 毫秒，比原来还慢。

AccelEval 的办法是，每个任务都通过统一入口接收主机端输入、返回主机端输出，内存分配、数据搬运、GPU 计算和清理全部计入计时，还设了审计机制，防止把该算的工作藏到计时区间之外。这倒逼一个很实在的标准：用户要的不是某一段代码快，而是从输入到答案，真的早一点拿到结果。

为什么有了 KernelBench，还要 AccelEval

现在社区里不是没有这类基准，KernelBench、TritonBench 都在做 GPU kernel 生成这事。它们的方向有价值：让模型根据 PyTorch 算子自动写出正确高效的 GPU 实现。但这类任务有个先天局限——深度学习里的矩阵乘、归一化、卷积、attention，这些算子本身定义规整、并行度高，也已经沉淀了成熟的优化范式，模型很可能只是从开源框架和代码仓库里复用了已有的实现模式。

可真实世界的程序往往不是这样。用户手里通常不是那个已经划好边界的深度学习算子，而是一份能正确运行、只是规模一大就越来越慢的 CPU 程序。里面有多层循环、条件分支、复杂数据结构、跨阶段的计算依赖。这时候做 GPU 加速，就不只是把局部计算改写成 CUDA，而是要读懂整个程序的计算结构：哪些能并行、哪些依赖必须保留、数据放哪、哪块值得融合、CPU 和 GPU 怎么分工。

42 项任务，三个规模

AccelEval 一共 42 项任务，覆盖高性能计算、科学仿真、图算法、时空算法、金融计算和运筹优化 6 个领域。既有路径计算、粒子仿真、期权定价，也有多周期库存补货、网络收益管理、Gittins 指数计算、一阶线性规划求解这类运筹任务。每个任务给自然语言说明、CPU 参考实现、固定接口，以及小中大三种规模的输入。版本要先能编译运行，再和 CPU 输出比对，数值敏感任务用预先规定的误差容限。只有算对了，性能数字才有意义。

同时测三种规模，其实是在问另一个问题：这种方案是小任务就被启动和搬运开销拖慢，还是规模一上来才显出并行优势。

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

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

这个数字得看清楚它的口径：加速比只统计通过的任务，CPU 对照是统一的单线程实现，并不是对充分调优的多线程 CPU 的普遍优势。而模型之间的能力轮廓差异很大——有的能写对更多任务，但不一定跑得更快；有的通过测试了，却没把并行资源用起来。只看「答对多少题」，根本刻画不了 GPU 加速能力。

论文里还给了人工实现做参照：在 11 个具备人工 CUDA 基线的任务里，即使逐任务挑 8 个模型里最快的正确方案，相对人工参考实现的速度比，几何平均也才约 0.75。自动加速的进展和还没解决的难题，在同一套基准里同时摆着。

43 类优化策略，想让试错变成能迁移的经验

如果评测到排名就结束，只能知道自己比谁快，却不知道下一步怎么改。LLM 有个特点：短时间能做出远多于人类的尝试，但实验往往彼此孤立，缺少跨任务的联系和总结。大量试错很难自动变成可积累、可迁移的优化能力。

所以 AccelEval 建立了一个 43 类的 CUDA 优化策略目录，覆盖内存访问与复用、计算重构、并行组织、负载平衡、主机端协调。结合静态代码检测和大模型代码分析，对 231 个通过验证的「模型与任务」组合做策略分解，把性能结果和代码采用的做法对应起来。比如内核融合能把连续计算阶段合并，减少中间数据读写和多次启动；共享内存分块让一组线程复用已搬到片上的数据；调整数据布局或算法选择，可能直接改变分工方式。

他们观察到，内核融合、分块、线程工作量调整这类结构性优化，和更高的同任务性能关联更强，而单个 kernel 内部的细节优化收益往往较低。策略迁移实验也支持这个方向：任务特定策略指导带来的整体提升是 1.78 倍，明显高于长度匹配的通用建议的 1.18 倍。

说到底，这份基准想让 AI 不只是「把代码翻译成 CUDA」，而是能读懂计算依赖、找到并行结构，再沉淀下「为什么快、什么能复用」的经验。这更像是往「AI 参与真实工程优化」的方向迈了一步——不过端到端相对人工还有一段距离，怎么走，论文里的 0.75 倍已经说明不是一两天能解决的事。

相关链接

• 论文：https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6835659
• 代码：https://github.com/Echoscd/AccelEval