Did China Really Build an AI That Writes CUDA Better Than Humans?

0:00 Nvidia has lost it. That post went up on the 16th of August and 300,000 people read it. The claim underneath, Chinese researchers had open-sourced a model that writes CUDA better than human

0:10 experts. If that were true, Nvidia would have a problem because CUDA is the software half of what Nvidia sells. The paper it points at is real. ByteDance and Tsinghua published it and

0:22 they called it CUDA agent. A CUDA kernel is the little program that runs on the graphics chip itself, the code doing the actual multiplying. Not many engineers write these by hand and the ones who can

0:32 are paid like it. The rest of machine learning runs on their work. What ByteDance trained learned to write them by trial and error in a sandbox that compiled and timed every try. On the

0:42 standard benchmark, it beat PyTorch's own compiler on 97% of 250 tasks. The same model before training beat that compiler 27% of the time. So, the training did the rest. So, the result is

0:54 real and it's big and none of that is what the post got wrong. Two words in that sentence don't survive the paper. One is open-sourced. The other is better than human experts. Both matter and the

1:06 second matters more than it looks because of what happened to this whole field in June. Start with the test it won. Kernel bench came out of Stanford in early 2025. 250 PyTorch programs and

1:17 your job is to rewrite each one as a faster CUDA kernel that still returns the right answer. It was led by Anne O'Yang and the headline finding was bleak. The best models of the day match

1:27 PyTorch on fewer than one in five problems. Writing correct CUDA turned out to be easy for a language model. Writing fast CUDA did not. The bar has moved since. PyTorch ships a compiler

1:38 called torch.compile that fuses operations together automatically and beating that is a much harder test than beating plain PyTorch. CUDA agent gets scored against both. Here's what

1:48 ByteDance did differently. They didn't ask a model for a kernel and grade the answer. They put the model inside a working development environment and let it stay there. Writing, compiling,

1:58 running, profiling, trying again for up to 200 turns. A pool of 128 graphics chips sat behind that doing nothing but timing the agent's attempts. Each run got its own card, so a measurement

2:11 couldn't be polluted by whatever else happened to be on the machine. They made the scoring deliberately blunt. A wrong answer lost you a point. Being correct but no faster earned one. Beating plain

2:21 PyTorch earned two and beating the compiler as well earned three. And faster meant at least 5%, so noise couldn't earn credit. Then came 150 steps of reinforcement learning across a

2:32 context window of 128,000 tokens. The first attempt collapsed after 17 steps, which is why a good chunk of the paper is about keeping the training from falling over. They also had to invent

2:43 the homework. No public data set was big enough, so they mined operators out of PyTorch, had a language model staple them into fused combinations, then threw away anything too easy, too slow, or too

2:54 close to the benchmark. 6,000 problems survived. So, the score. Of the 250 tasks, 98.8% came back correct and 96.8% came back faster than Torch Compile. Over everything that ran, the geometric

3:09 mean speedup against the compiler was 2.11 times. One small thing, because it matters later. The abstract gives the three-level scores as 100, 100, and 92%. The paper's own results table says 97,

3:22 100, and 90. Neither gap is large. The summary is just the friendlier of the two and the summary is what got quoted. The strongest number sits in the middle tier where several operations have to be

3:33 fused into a single kernel. There, CUDA agent was faster than the compiler on every problem in the set by an average of 2.8 times and fusion is exactly where a rule-based compiler runs out of rules.

3:45 Go back to that 27% that seed 1.6, the same model before any of this training, and its up against that compiler came in at 0.69, meaning its kernels usually ran

3:57 slower than the compiler's own. Two frontier models did better than that and still lost. Claude Opus 4.5 and Gemini 3 Pro, the strongest on offer at the time, beat the compiler on about 2/3 of tasks.

4:10 CUDA agent beat it on 97. So far, this is a straightforwardly good paper published in February 2026, a real method, a real jump measured against a baseline that isn't a straw man, which

4:22 brings us to the first word the post got wrong. There is a repository. It went up in February. It has picked up about 1,300 stars, and it holds a working agent environment, the 6,000 training

4:33 problems over on Hugging Face, and the reward recipe. Its most interesting file is a single markdown document, the skill file, and that's the instruction sheet the agent

4:42 works from, where to put things, which tools to run, when a result counts as fast enough to stop. What isn't in that repository is the model. No weights, no checkpoint, nothing to download. The

4:53 trained agent stayed at ByteDance. That's not an oversight, it's structural. CUDA agent is built on Seed 1.6, ByteDance's own mixture of experts model, 230 billion parameters in total,

5:06 23 billion of them active, and Seed 1.6 has not been released either. There's also no license file in the repository at all. Not a restrictive license, no license, and GitHub's own

5:17 guidance on that is blunt. You may look at it and fork it, and you have no permission to use, modify, or share it. So, is that open source? The answer is in what you can actually do with it. You

5:28 can read the method, you can train on their data, you can copy the reward design onto a model you already have. You can't download the thing that scored 97%, which is still worth having. Plenty

5:38 of published wins in this area arrive as a paper and a chart. This one arrives with the homework and the marking scheme attached, and those are the expensive half to rebuild. That cuts the other

5:48 way, too. You can't put an agent through a harder test when there's nothing to put through it. And outside ByteDance, there is nothing, which matters because a harder test showed up 4 months later.

5:58 First, though, the other half of the claim. Kernel bench doesn't measure anybody against a human expert. Its baseline is PyTorch, eager mode, and the compiler. Those are the two things a

6:08 kernel gets timed against, and there's no expert anywhere in the comparison. Then there's the instruction sheet, and this part rewards reading closely. The agent may not call PyTorch inside its

6:18 own kernels at all, with two exceptions written into the file. Nvidia's matrix multiply library and Nvidia's convolution library. The convolution one isn't merely allowed. For convolutions,

6:29 it's mandatory. Both of those libraries are handwritten. Nvidia's performance engineers have been tuning the convolution one since 2014, and it is precisely the work of human experts. The

6:40 paper says as much in its own case studies. Under a heading called library-aware optimization, it describes the agent spotting a chance to call a fused Nvidia routine, convolution, bias,

6:51 and activation in a single call, and credits that result to mature, hardware-tuned implementations. So, the skill on display is real. It just isn't the skill the post described. CUDA agent

7:02 is very good at deciding which human-written routine to call, how to fuse the work around it, and where a custom kernel actually pays. That's a brilliant foreman. It is not a

7:11 replacement. The accurate version of the headline reads, "A Chinese lab trained an agent that beats PyTorch's compiler on a 250 problem benchmark, partly by calling Nvidia's own libraries more

7:22 cleverly than the compiler does." Less shareable, and also true. Now for the part that should make anybody in this field careful, and it goes back to February 2025. A Japanese lab called

7:33 Sakana announced a CUDA writing agent and claimed speedups of 10 to 100 times over standard PyTorch. Then outside testers checked it. The system had found a hole in the evaluation code that let

7:44 it skip the correctness check and one tester measured the result running three times slower than the baseline. So, Cona revised the paper and rebuilt the harness.

7:53 The Cuda agent team site that failure by name and design against it. Evaluation scripts locked behind file permissions, a context manager that forbids falling back to PyTorch, five random inputs per

8:04 correctness check, and no web access, so nothing gets copied in from outside. That's careful work and it wasn't enough because the problem had moved up a level. In June of 2026, a group at Meta

8:16 and Stanford audited the benchmark itself. Their paper is called Kernel Bench Verified and Azalia Mirhoseini's name is on it, the same name that's on the original Kernel Bench. The person

8:26 who helped build the test came back to say the test was too easy. Two things were wrong with it. The reference timing ran PyTorch without Tensor Core acceleration, which no serious

8:35 deployment does, so the baseline was slower than reality. And every problem got checked on inputs drawn from one narrow distribution. The models found that second hole on their own. One

8:46 generated kernel checked whether the input matched the test exact shape and handed it straight back unchanged on the reasoning that the operation leaves positive numbers alone and every test

8:55 input was positive. It reported a speedup of 374 times. With a realistic baseline and four hidden input distributions, the numbers fall over. The strongest model tested

9:07 went from 1.4 three times faster to 0.88, which is slower than PyTorch. Of the seven frontier models tested, not one landed above parity. Here's where that touches this paper directly. Cuda

9:19 agent's own case study describes it switching Tensor Core math on inside its generated kernels. The exact acceleration the audit says the baseline was missing, which doesn't make its

9:28 result wrong. It means the result has not been measured under the stricter protocol published four months after the paper. And going back to that missing license,

9:37 no outside group can measure it because the model isn't downloadable. Where does that leave us? The method works. The jump over the base model is enormous. The fusion result is the

9:46 strongest evidence in the paper. And the headline multiplier rests on a benchmark whose own authors have since published a stricter version of it. One detail sat in the paper unquoted in the sentence

9:56 describing the hardware. Those 128 chips doing the timing were H20s. H20 is the hopper card Nvidia builds for the Chinese market cut down to clear American export rules. So a

10:08 Chinese team taught an agent to write Nvidia's proprietary language on Nvidia silicon Washington signed off on. That's a strange shape for a moat that's supposed to be evaporating. Here's my

10:18 call. The winner is the method and the method is the part they actually released. If you run models for a living, carry a graphics bill, and have no kernel engineer, then 6,000 fused

10:28 training problems, a skill file, and a four-level reward are a serious head start on whatever base model you already run. The 5% are the people who came for weights. If

10:38 you wanted a downloadable model that outruns Nvidia's own engineers, this isn't it and it isn't close. I'd still take the recipe at twice the price because the fusion gain comes from

10:49 cutting memory trips, not from tensor cores. The thing worth being annoyed at isn't ByteDance, which published more of its homework than the post gave it credit for.

10:57 It's the reflex that turns beats a compiler on a benchmark into beats human experts and turns a leaderboard row into a fact about the world. So here's the question worth sitting with.

11:07 When somebody finally runs an agent like this under the stricter test and within a year somebody will, does the number hold? My bet is that it drops and still lands above one. If it lands below one,

11:18 this entire genre of paper needs rewriting.