Agentic CUDA Optimizer 实战：用 7 轮受控实验做 CUDA 性能优化

CUDA 性能优化：先看结论

应该把 Agentic CUDA Optimizer 当作有边界的实验执行器，而不是能自主给出证明的机器。 固定初始 v0.0 commit，在文档指定的 Windows 环境中构建 C++ 测试运行器，自备参考内核和输入用例，用 --max-iterations 7 限制搜索次数，最后审查 history.json、summary.json 和 best.cu，再独立复跑。

这个优化器可以把一套很实用的流程自动串起来：编写候选内核、编译、运行、在输出不一致时淘汰、在输出通过后计时，再把证据送入下一轮。它无法替你判断参考实现是否正确，也无法证明测试用例覆盖了生产环境，更不能保证一个孤立内核变快后，整笔 GPU 账单一定会下降。

该仓库于 2026 年 9 月 24 日 19:41:43 UTC 以 commit 1e9464da54dfc651337a97c3643bfeefec712bc1 首次出现。固定这个 commit 很重要，因为本文讲的是 v0.0，而不是仓库之后可能发生的变化。

这个优化器究竟做了什么

可以把它想成一个带质检关卡的模型工坊。模型能够重新设计工作台上的小零件，也就是 CUDA 内核，并调整它的启动方式；测试运行器负责掌控测量设备。只有全部输入用例都得到可接受输出，候选内核才会进入最终陈列柜。

在底层，独立的 C++ 运行器使用 NVRTC 编译 CUDA 源码，通过 CUDA Driver API 启动内核并保存输出。Python 随后把这些输出与参考结果比较，再筛选候选方案。标为 correctness 的用例必须通过，但不计入得分；标为 performance 的用例既参与正确性验证，也会进入用于排名的几何平均延迟计算。

默认情况下，每个计时用例先预热 10 次，再通过 CUDA event 正式测量 100 次。这些数字只描述内核计时，并不是任务总成本。编译、模型调用、失败尝试、输入生成、profiler 重放和人工复核都不包含在这段延迟里。

这也正是应该使用测试运行器，而不是只用一个 prompt 让通用编程 agent 交付所谓“聪明内核”的原因。它的价值在于提供一套有记录、有预算上限、关卡明确的循环，但这并不能证明 LangGraph 一定比能力出色的编程 agent 找到更好的答案。仓库作者在发布讨论中也强调过同一点：真正有用的是给各个步骤加上边界。

按固定版本搭建 Windows 环境

先沿用文档明确支持的 Windows 路径。 该仓库在 RTX 3060 Laptop GPU 上开发，文档指定 Visual Studio 2026 及其 C++ 工具。编译之前，请确认已有 Python 3.12 或更高版本、CMake 3.24 或更高版本、C++17 编译器、NVIDIA 驱动，以及兼容的 CUDA Toolkit。

python --version
cmake --version
where.exe cl
nvidia-smi
nvcc --version

git clone https://github.com/bertaye/agentic-cuda-optimizer.git
cd agentic-cuda-optimizer
git checkout --detach 1e9464da54dfc651337a97c3643bfeefec712bc1

python -m venv .venv
.venv\Scripts\python -m pip install -r optimizer_agent/requirements.txt
cmake -S cuda_test_harness -B cuda_test_harness/build -DCMAKE_BUILD_TYPE=Release
cmake --build cuda_test_harness/build --parallel

Set-Content .env 'OPENAI_API_KEY=your-key-here'

任何一项前置检查失败，都应该先停下来。工具链和 agent 同时变动内核时，很难判断失败究竟来自哪里。

v0.0 有两个细节尤其值得注意：

• README 建议传入 --config optimizer_agent/example.json，但固定 commit 中没有这个文件。请改用明确的 flags，或自行创建并审查配置。
• 公开仓库中没有 license 文件，GitHub 也显示未检测到 license。代码公开可见不等于获得商业授权；用于公司、再分发或付费产品之前，应先取得许可或接受法律审查。

该版本没有记录其他平台的搭建路径。本文也检查过 Linux 环境，但由于缺少所需的 CUDA 和构建工具，那次检查只能算前置条件审计，不能算成功完成了 Linux 测试。

最后，还要隔离运行机器。如果让优化器创建输入，生成的 Python 会直接在本地执行，没有 sandbox；生成的 CUDA 同样会直接在 GPU 上运行。请选择一次性主机或 VM，只授予有限凭据，不放生产数据和无关 secret，也不要让它访问重要的共享文件。

设计一个能诚实失败的实验

从一个能用一页纸写清契约的内核开始。 行主序 float32 矩阵乘法很适合作为试点：输入、输出和维度都很明确，奇数尺寸还能暴露那些规整方阵用例容易漏掉的边界处理问题。

在优化器的结果目录之外准备 3 项资产：

1. reference.cu：来自可信来源、经过审查的简单实现。不要让同一个模型同时生成 oracle 和候选内核。
2. initial.cu：原本真正准备上线的 baseline。这样就不会把“相对较弱生成代码的巨大提升”误判成业务收益。
3. input_cases.json：包含固定、可复现的二进制输入，并针对你的数值契约设定有实际意义的比较容差。

一个有边界的试点可以放入一个奇数形状的正确性用例，例如 M=31、N=37、K=29；再放入两个规模适中的性能用例，例如 256×256×256，以及 M=384、N=256、K=320。这些只是实验设计建议，不是仓库的 benchmark。另留一个搜索期间不可见的第 4 个 holdout 形状和一组新数值，让最终候选面对真正没见过的测试。

输入应使用有实际变化的数值，不要全是 0 或 1。逐一检查 buffer 大小、参数顺序、标量类型和容差。manifest 至少要有一个 performance 用例。所有用例都必须通过，但只有 performance 用例参与排名。

运行前，给参考实现、输入和测试运行器计算 hash，或者直接保留副本。优化器可以自由修改候选源代码以及各用例的启动配置，但不能修改成功的判定标准。

严格执行 7 轮改进

下面的命令使用明确的输入和文档指定的 Windows 解释器路径。它固定了入口签名，提供独立参考实现和真实 baseline，并把改进预算限制在 7 轮。

.venv\Scripts\python optimizer_agent\optimizer_agent.py `
  --description "Row-major float32 matrix multiplication C=MxN from A=MxK and B=KxN." `
  --signature 'extern "C" __global__ void matmul_f32(const float* a, const float* b, float* c, int m, int n, int k)' `
  --reference .\experiment\reference.cu `
  --initial-kernel .\experiment\initial.cu `
  --input-cases .\experiment\input_cases.json `
  --max-iterations 7

默认模型是 gpt-5-mini，reasoning effort 为 medium，API 用量由你的账户付费。7 轮改进不等于只调用 7 次模型，也不等于只启动 7 次内核。一次 proposal 可能包含工具调用和纠错重试，而仅一个计时用例，默认就有 10 次预热和 100 次正式测量。

第一次建立干净 baseline 时，先不要启用 --use-nsight 和 --nvidia-research。Nsight profiling 会增加重放工作，还需要 Nsight Compute 以及读取 GPU 性能计数器的权限；NVIDIA research 则会增加模型和检索工作。基础循环稳定之后，再一次只增加一个变量。

按下 Enter 之前，先建立实验日志并记录：

• 固定的 commit 和 dirty-tree 状态
• GPU 型号、驱动及 CUDA Toolkit 版本
• 参考实现和用例的 hash
• 开始与结束时间戳
• GPU 总 wall-clock time
• 模型名称、调用次数、token，或保存的 response 文件中可取得的其他用量 metadata
• 有效候选、被拒候选及拒绝原因
• baseline 与胜出版本在各用例上的延迟

比较计时时，应让 GPU 保持空闲。后台 GPU 任务可能把微小的表面提升变成纯粹的测量噪声。

读懂证据，再独立复跑胜出内核

把结果目录当作审计包，不要当成奖杯陈列柜。 每次 session 都保存在 results/run-NNN/ 下。先看这些文件：

• history.json 记录每次被评估的尝试，包括用例级执行细节、验证结果、启动配置和实测延迟。
• summary.json 给出最佳 iteration、各用例延迟、可取得的 baseline speedup，以及终止原因。
• best.cu 是通过全部输入用例后速度最快的候选内核。
• best-case-N.json 是使用胜出源码在现有用例上复跑的 request。
• model-*.json 和工具 response 文件保留 agent 的交互过程。应在其用量 metadata 中核算 API 成本，因为 summary.json 不会汇总模型支出。
• heatmap.png 和 heatmap.svg 展示计时历史。它们可以帮助定位问题，但不是正确性证据。

被拒候选与有效候选同样值得认真统计。6 个 proposal 被拒、只剩 1 个窄幅胜出方案，与所有候选始终保持有效，传达的是完全不同的信息。检查编译失败、输出不匹配，以及胜出源码是否真的与其 parent 有差异。

接下来，在同一块保持空闲的 GPU 上，通过测试运行器逐一复跑保存的 best-case-N.json。然后使用独立 oracle，让 best.cu 接受隐藏形状和新数值的测试。现有用例只能证明候选通过了这些用例，不能证明它在所有合法形状上都普遍正确、没有 race，也不能证明其行为始终安全。

只要任一 holdout 失败、重复计时与 baseline 的差距落入噪声，或者收益在真实应用中消失，就应淘汰这个胜出版本。生成的参考实现不能作为唯一 oracle；相对生成初始内核的胜利，也不代表胜过 cuBLAS 或其他生产 baseline。该仓库没有发布与 cuBLAS 的对比结果。

CUDA 性能优化是否划算，要算整笔账

判断依据应该是完整任务的经济性，而不是孤立的内核得分。 公开仓库没有订阅价格，但同样没有授予商业许可。实验仍然会消耗工程师时间、模型 API 用量和 GPU 时间。

一份实用的 worksheet 可以列 3 行：

• pilot cost = engineer setup and review + model charges + GPU wall-clock cost
• saved GPU hours per month = end-to-end milliseconds saved per invocation × monthly invocations ÷ 3,600,000
• payback months = pilot cost ÷ monthly gross GPU saving

这里要使用集成后的端到端毫秒节省量，而不是 summary.json 中由 CUDA event 得出的延迟。如果每次请求会多次运行该内核，就按实测调用次数计算。如果加速会改变吞吐量、显存压力或 batching，请重新测量完整 workload，不要凭假设外推内核结果。

人工方案本身也不便宜。Upwork 的 CUDA consultant 页面目前给出的规划区间是：性能 profiling 为 $500 至 $1,200，内核调优为 $2,500 至 $4,500。这些是平台区间，不是报价，也不能证明 agent 可以取代专家；但它们确实说明，如果一套可重复的一轮实验能把昂贵的专家工作收敛到证据完整的候选方案上，就可能创造价值。

是否继续的规则可以很直接：只有候选方案通过独立用例、反复胜过 baseline、确实改善真实 workload，并且回本周期落在团队运行前设定的范围内，才进入受控集成测试。

最适合采用这套方法的 7 类团队

下面按“最有可能把经过验证的内核收益转化为收入或算力节省”排序。

如果目标 workload 是完整应用、成熟的 vendor primitive，或持续变化的一组形状，应该先从别处入手。这个优化器明确处于实验阶段，目标是单个内核。

如需了解相邻系统，可以阅读现有的 GPU 优化 AI agent 对比，其中涵盖 AKO、KernelAgent、AutoKernel、Apex 和 CUDA Agent。Bertaye 的仓库是一个更新、相互独立的项目。

围绕它最值得做的 2 款产品

1. 有边界的 CUDA 优化审计

这是最值得优先考虑的机会。 面向只有一个高成本 CUDA 内核的团队，出售范围固定的证据包：捕获运行环境、接收可信用例、执行 7 轮尝试、独立复跑、核算模型与 GPU 成本，并给出继续或停止的报告。

需求不大，却非常具体。DataForSEO 显示，cuda optimization 在美国每月约有 30 次搜索，cuda kernel optimization 约有 20 次，两者的付费搜索竞争都较低。与此同时，Upwork 上 profiling 的规划价格为 $500 至 $1,200，调优为 $2,500 至 $4,500。这组信号更适合做小众专家服务，而不是大众自助应用。

最小可售版本需要安全 intake form、一次性 GPU runner、锁定的用例 manifest、运行成本 collector，以及 HTML 证据报告。人工 reviewer 不能缺席。真正的难点是信任：一个错误的胜出内核，就足以抹去多次成功审计积累的价值；仓库没有 license，也意味着在此代码之上提供商业服务前必须取得许可。

2. GPU 内核回归门禁

可以构建一项受控 CI 服务：在预留硬件上复跑已批准的内核，检查保存的输出，并在延迟或正确性发生漂移时阻止发布。GPU platform 团队和 CUDA 咨询公司会愿意为跨 driver、toolkit 和源码变更的稳定记录付费。

DataForSEO 显示，gpu performance optimization 在美国每月约有 10 次搜索。单靠 SEO，这个量级不足以支撑一门生意，但足以验证买家使用的表达方式。获客渠道应放在咨询公司、GPU vendor 和企业内部 platform 团队。

MVP 需要 hardware queue、环境 fingerprint、签名 reference case、重复计时、threshold，以及与上一个已接受版本之间的简洁 diff。难点在于 variance：如果 runner 无法控制机器并重复测量，共享主机、thermal state 和 driver 变化都可能造成误报。

这些限制会直接改变你的决定

坦率地说，v0.0 是一套有用的实验脚手架，但也带来很重的信任负担。

• 它优化的是单个 CUDA 内核，不是完整应用。
• 通过现有用例并不能确立普遍正确性。
• 生成的参考实现不是独立 oracle。
• 性能收益取决于 workload 和硬件。
• 它没有提供与 cuBLAS 或其他 vendor library 的对比。
• 默认计时不包含编译和 profiler 重放，因此不是运行总成本。
• 生成的输入脚本会在本地执行，没有 sandbox。
• 文档支持的构建路径是 Windows；其他平台需要单独保存经过验证的搭建记录。
• 固定 commit 中缺少文档提到的示例配置。
• 仓库没有确立商业许可权。

如果需要明确阶段、持久证据和可重复预算，独立运行器就值得使用。如果已有专家全程监管终端、测试足够强，而且任务确实只做一次，通用编程 agent 也可能已经够用。只有当边界与审计轨迹真正降低了风险或重复成本时，这个运行器才有存在价值。

常见问题

下周一最实际的一步很简单：安排 1 名 GPU 工程师、1 个低风险 float32 内核、1 台一次性 NVIDIA 机器，再留出 1 天准备独立参考实现、测试用例和成本表。只有这些关卡全部写清楚后，才开始 7 轮试点。

如果你希望把可测量的 GPU 实验及其复核路径接入生产系统，可以从 AI 生产系统 开始。