视频 · 前往原文观看过去几个月里,我们一直在开发一个能够自主构建、维护和部署复杂软件的多智能体系统。作为这项工作的一部分,我们已在多个领域对该系统进行了测试,包括让它从零开始构建一个浏览器,以及在 First Proof 基准测试上解决一个研究级别的数学问题。
最近,我们开始与 NVIDIA 合作应对一项新挑战:将多智能体框架应用于 CUDA 内核优化。这些是难度极高的技术问题,具有重要的现实影响:CUDA 内核是支撑 NVIDIA GPU 上 AI 模型训练与推理的核心软件。更快的内核意味着更高的 GPU 利用率、更低的能耗、更低的延迟以及更低的每 token 成本——从而使服务提供商能够同时为更多用户提供更大、更强的模型。
我们的多智能体框架在 235 个问题上自主运行了三周。该系统通过从零开始构建并优化 Blackwell GPU 内核,一直深入到汇编层级,实现了 38% 的几何平均加速。
这种级别的性能提升通常只有经验极其丰富的内核工程师经过数月甚至数年的工作才能实现。而多智能体系统在数周内就完成了这一目标,解决了现有方法难以处理的大量长尾内核问题。
内核优化作为智能体系统能力的试金石
评估长时间运行的多智能体系统的最佳方法之一,是交给它们开放式优化问题——连我们自己都不知道正确答案的那种。内核优化问题正好符合这一标准:它们提供了可量化的目标,系统可以针对这些目标进行迭代优化,而不是仅仅针对一个已知的简单差异进行修改。
如今,工程师们通过将模型拆解为单个数学运算并逐一调优来优化内核。这种方法虽然让问题变得可控,但却牺牲了性能,因为零散的优化无法捕捉到对整个系统进行同步优化所能带来的潜在收益。迄今为止,GPU 性能一直受限于我们无法在手动简化之外探索完整的解空间。
通过这项实验,我们希望检验我们的多智能体系统能否在这些约束之外运行,探索更广阔的解决方案空间,从而生成更快的内核。
SOL-ExecBench:用于问题生成与基准评测
NVIDIA 使用 SOL-ExecBench 从超过 124 个生产级开源模型(如 Deepseek、Qwen、Gemma、Kimi 和 Stable Diffusion)中生成了 235 个优化问题。与合成数据或玩具内核不同,每个问题都是针对多种模型架构(包括大语言模型、扩散模型、视觉模型、音频模型、视频模型以及多模态混合模型)在训练或推理负载上的真实约束。
我们还使用 SOL-ExecBench 在 27 块 NVIDIA Blackwell B200 GPU 上对多智能体内核解决方案进行了基准测试。SOL-ExecBench 是一个有效的评估工具,能够将内核性能与现有软件基线以及理论硬件性能极限进行比较。如果智能体采用缓存等作弊手段,并交付了超出 B200 支持范围的性能,该流水线将判定结果无效。
实验执行方式
该多智能体系统通过部署一个规划智能体,根据性能指标在自主工作节点之间分配和重新平衡任务,一次性解决了全部 235 个 GPU 内核优化问题。
整个协调协议存放在一个单一的 markdown 文件中,该文件规定了输出格式、规则和测试。多智能体系统在运行过程中自主学会了调用基准测试流水线,形成了一个系统持续测试、调试和优化内核的循环,全程无需任何开发者干预。
为了更好地评估多智能体系统的能力,我们要求它在两次独立的运行中分别使用两种语言编写解决方案,这两种语言位于 GPU 抽象层次的两端:
- CUDA C 内联 PTX:让智能体能够直接访问寄存器和 ISA 级指令,测试系统能否在最低层级理解硬件。
- CuTe DSL:提供高级可组合抽象,且在公开训练数据中极少出现,测试系统能否仅凭提供的文档学习全新的 API。
整体加速比达 38%,其中 19% 的优化实现了超过 2 倍的性能提升。
我们从两个维度报告多智能体系统的性能:
- 与单智能体优化后的 PyTorch 代码(作为基线)相比的几何平均加速比。
- 光速(SOL)得分,该得分以对数曲线形式衡量解决方案相对于理论硬件极限的优劣程度。0.5 分代表优化后的 PyTorch 基线,1.0 分代表性能极限。
我们的多智能体系统在 235 个问题中的 149 个(63%)上成功超越了基线,几何平均比值为 1.38 倍(几何平均加速 38%)。
在 235 个问题中的 45 个(19%)上,多智能体系统实现了相比基线超过 2 倍的优化效果。您可以在本公开代码仓库中查看该系统开发的最终解决方案。
针对不同问题采用不同的优化策略
为展示该系统在不同类型问题上的适应性,我们重点介绍三个问题,系统针对这些问题自发采用了截然不同的优化策略。
BF16 分组查询注意力与分页预填充
带分页预填充的分组查询注意力是现代大语言模型推理栈中常见的提示阶段操作。一个经过良好优化的实现可以在相同 GPU 显存上支持更长的上下文、更高的并发度以及更好的吞吐量。
该智能体使用 CUDA C++ 优化了从 SGLang 推理引擎中提取的、针对 Llama 3.1 8B 的注意力问题。在智能体对内核进行迭代的过程中,它成功运用了特定的硬件指令进行内存加载和数学运算,通过持久化内核增加了改进的调度策略,并针对输入尺寸进行了超优化。
我们将多智能体系统的自定义内核与 FlashInfer 库中人工优化的基线进行了比较。我们发现该系统生成的解决方案接近硬件极限,SOL 得分为 0.9722,相比基线实现了 84% 的几何平均加速。
我们还将 SGLang 中的现有内核替换为该内核,观察到 Llama 3.1 8B 的首 token 生成时间(TTFT)加速了 3%。考虑到该注意力问题根据服务配置不同,约占预填充过程的 2-5%,我们认为这是一个不可忽视的端到端加速。
NVFP4 MoE 线性层与门控
这个问题代表了在 Qwen3 等混合专家模型中常见的一种双内核模式,其特殊之处在于输入张量和中间乘法输出结果都被量化为了 NVFP4(4 位浮点数)。
该智能体正确地将量化区域识别为主要瓶颈,并据此融合了缩放计算和取整操作。它没有在量化过程中先缩放再取整,而是使用预先计算的阈值桶,直接将 FP32 值映射为 FP4 编码,之所以能做到这一点,是因为 NVFP4 只有 16 种可能的取值。接着,它将这些优化应用到了更大的测试用例上。
该智能体最终超越了优化后的 PyTorch 基线,实现了 39% 的几何平均加速比和 0.58 的 SOL 分数。
BF16 矩阵乘法
矩阵乘法是一个公认的优化难题,因为它需要深入理解各种硬件单元及其调度机制。性能完备的矩阵乘法内核(GEMM)需要在内核中使用内联 PTX(类似于汇编语言)、流水线技术和分阶段处理。因此,编写高性能的 GEMM 历来只由经验丰富的内核专家负责。
Cursor 多智能体系统从头生成了一款专门的 CUDA C++ GEMM 内核,其性能非常接近(达到 86%)来自 NVIDIA cuBLAS 库的精心调优的人工基线。该系统通过自主学习使用 Blackwell 特有的指令、针对硬件优化内存读写,然后针对特定形状进行超优化,最终达到了这一结果。
而在对 LLM 推理解码尤为重要的中小规模矩阵(small-M)测试用例上,该多智能体系统内核的性能比库高出 9%。这一结果表明,即使在最难的内核问题上,多智能体系统也很快将超越领域专家。
一个用于构建软件的多智能体系统
尽管多智能体框架相比基线实现了 38% 的几何平均加速,但 SOL 得分的中位数仍然只有 0.56,这意味着还有很大的优化空间。我们相信,多智能体解决方案可以通过更多算力得到大幅改进,因为我们当时只有 27 块 GPU 来运行数百个问题和智能体。这限制了我们充分利用多智能体系统的能力。如果拥有更多 GPU,该系统就能探索更深层、更新颖的解决方案。
软件领域最具挑战性的任务是开放式的,没有明确的解决方案。单智能体系统在此类任务中表现不佳,因为模型最擅长处理训练阶段已见过的、范围狭窄的任务。我们将内核优化实验视为进一步的佐证,证明多智能体架构将很快成为构建软件的默认方法,因为它们能够应对远超训练数据分布的全新问题。
我们正在研究的这些技术将很快应用于 Cursor 的核心产品。如果您对多智能体协调中的难题感兴趣,Cursor 团队期待您的来信,联系方式为 hiring@cursor.com。
2026 年 1 月 14 日
扩展长时间运行的自主编码能力
Wilson Lin
2025 年 8 月 29 日
使用自定义 MXFP8 内核实现 1.5 倍 MoE 训练加速
Stuart Sul
推出 Composer 2.5
视频 · 前往原文观看Over the past few months, we've been developing a multi-agent system that can build, maintain, and deploy complex software autonomously. As part of that work, we've been testing the system in a variety of domains, including having it build a browser from scratch and solve a research-level math problem on the First Proof benchmark.
Recently, we began collaborating with NVIDIA on a new challenge: applying the multi-agent harness to optimize CUDA kernels. These are difficult technical problems with important real-world consequences: CUDA kernels are the core software that supports AI model training and inference on NVIDIA GPUs. Faster kernels mean better GPU utilization, reduced energy consumption, lower latency, and reduced cost per token—allowing providers to serve bigger, more capable models to more users at once.
Our multi-agent harness operated autonomously for three weeks across 235 problems. The system achieved a 38% geomean speedup by building and optimizing Blackwell GPU kernels from scratch, all the way down to the assembly level.
These levels of performance improvement are typically only found through months or years of work from highly experienced kernel engineers. The multi-agent system accomplished it in weeks, addressing a long-tail of kernel problems that had been impractical with existing approaches.
Kernel optimization as a test of agent system capabilities
One of the best ways to evaluate long-running, multi-agent systems is to give them open-ended optimization problems where even we don't know the right answer. Kernel optimization problems meet this criteria: they provide measurable objectives that the system can iteratively optimize against, instead of targeting a simple known diff.
Today, engineers optimize kernels by breaking models into individual math operations and tuning each one separately. This makes the problem manageable but leaves performance on the table because piecemeal optimization misses potential gains from optimizing across the entire system simultaneously. To date, GPU performance has been limited by our inability to explore the full solution space beyond these manual simplifications.
With this experiment, we wanted to see if our multi-agent system could operate outside these constraints, exploring a broader solution space to produce faster kernels.
SOL-ExecBench for problem generation and benchmarking
NVIDIA used SOL-ExecBench to generate 235 optimization problems from over 124 production open-source models such as Deepseek, Qwen, Gemma, Kimi, and Stable Diffusion. As opposed to synthetic data or toy kernels, each problem is a real-world constraint on training or inference workloads for a variety of model architectures: LLMs, diffusion, vision, audio, video, and multi-modal hybrids.
We also used SOL-ExecBench to benchmark multi-agent kernel solutions on 27 NVIDIA Blackwell 200 GPUs. SOL-ExecBench is an effective evaluator that compares kernel performance against existing software baselines and theoretical hardware performance limits. If agents use cheating tactics like caching and deliver performance beyond what a B200 can support, the pipeline invalidates the result.
How we ran the experiment
The multi-agent system solved all 235 GPU kernel optimization problems in a single run by deploying a planner agent that distributed and rebalanced work across autonomous workers based on performance metrics.
The entire coordination protocol lived in a single markdown file that specified the output format, rules, and tests. The multi-agent system independently learned to call the benchmarking pipeline during its runs, creating a loop where the system continuously tested, debugged, and optimized kernels without any developer intervention.
In order to better gauge the multi-agent system's capabilities, we asked it to write its solutions in two languages in two separated runs, at opposite ends of the GPU abstraction spectrum:
- CUDA C with inline PTX, which gives agents direct access to registers and ISA-level instruction, testing whether the system can reason about hardware at the lowest level.
- CuTe DSL, which provides high-level composable abstractions with minimal presence in public training data, testing whether the system can learn novel APIs purely from provided documentation.
38% speedup, with 19% of optimizations exceeding 2x improvements
We report performance of the multi-agent system in two ways:
- Geomean speedup vs. PyTorch code that was optimized by a single agent as a baseline.
- Speed-of-Light (SOL) scores that represent how good a solution is compared to theoretical hardware limits on a logarithmic curve. A score of 0.5 represents the optimized PyTorch baseline and 1.0 is the performance limit.
Our multi-agent system successfully outperformed baselines on 149 out of 235 problems (63%), with a geometric mean ratio of 1.38x (38% geomean speedup).
On 45 out of 235 problems (19%), the multi-agent system delivered optimizations greater than 2x compared to baselines. You can see the final solutions our system developed in this public repo.
Different optimization strategies for different problems
To show the adaptability of the system across different types of problems, we highlight three problems where it organically arrived at distinct optimization strategies.
BF16 Grouped Query Attention with Paged Prefill
Grouped-query attention with paged prefill is a common prompt-stage operation in modern LLM inference stacks. A well-optimized implementation can support longer contexts, higher concurrency, and better throughput on the same GPU VRAM.
The agent used CUDA C++ to optimize this attention problem extracted from SGLang inference for Llama 3.1 8B. As the agent iterated on the kernel, it successfully employed specific hardware instructions for memory loading and math, added improved scheduling via persistent kernels, and hyper-optimized for input size.
We compared the multi-agent system's custom kernel with a human optimized baseline in the FlashInfer library. We found that the system produced a solution approaching hardware limits with a SOL score of 0.9722, representing a 84% geomean speedup over the baseline.
We also replaced the existing kernel in SGLang and observed a 3% speedup for time to first token (TTFT) on Llama 3.1 8B. Given that this attention problem occupies 2-5% of the prefill process depending on serving configuration, we see this as a non-trivial end-to-end speedup.
NVFP4 MoE Linear with Gating
This problem represents a common two-kernel pattern found in Mixture-of-Experts models like Qwen3, with the caveat that the input tensor and intermediate multiplication output are quantized to NVFP4 (4-bit floating point).
The agent correctly identified the quantization area as the primary bottleneck and accordingly fused scale calculation and rounding. Instead of scaling and then rounding during quantization, it used pre-computed threshold buckets to directly map FP32 values to FP4 codes, which is possible because there are only 16 possible NVFP4 values. Next, it applied these optimizations to larger test cases.
The agent ultimately surpassed the optimized PyTorch baseline, delivering a 39% geomean speedup and 0.58 SOL score.
BF16 Matrix Multiplication
Matrix multiplication is a notoriously difficult problem to optimize because it requires deep understanding of the various hardware units and their scheduling. Fully performant matrix multiplication kernels (GEMMs) require inline PTX (akin to assembly language), pipelining, and staging within a kernel. As a result, writing fast GEMMs has been historically siloed to highly experienced kernel experts.
The Cursor multi-agent system generated a specialized CUDA C++ GEMM kernel from scratch, coming remarkably close (86%) to a meticulously tuned human baseline from the NVIDIA cuBLAS library. The system reached this result by independently learning to use Blackwell-specific instructions, optimizing memory reads and writes for the hardware, and then hyperoptimizing for the exact shapes.
And on small-M test cases, which are especially important for LLM inference decode, the multi-agent system kernel outperformed the library by up to 9%. This result points to multi-agent systems soon outperforming domain experts even on the hardest kernel problems.
A multi-agent system for building software
While the multi-agent harness delivered a 38% geomean speedup over baselines, the median SOL score was still only 0.56, leaving significant room for further optimization. We believe that multi-agent solutions can be vastly improved with more compute, as we had hundreds of problems and agents running on only 27 GPUs. This limited our ability to take full advantage of the multi-agent system. With more GPUs, the system could explore even deeper and more novel solutions.
The most ambitious tasks in software are open-ended, without a clear solution. Single agent systems struggle here because models are best at narrowly scoped tasks they have already seen during training. We see the kernel optimization experiment as further validation that multi-agent architectures will quickly become the default approach to building software because they can tackle novel problems that fall far outside training data distribution.
The techniques we're researching here will soon inform Cursor's core product. If you're interested in working on hard problems in multi-agent coordination, the Cursor team would love to hear from you at hiring@cursor.com.
Jan 14, 2026
Scaling long-running autonomous coding
Wilson Lin
Aug 29, 2025
1.5x faster MoE training with custom MXFP8 kernels
Stuart Sul
Introducing Composer 2.5