NVIDIA’s workflow turns Python GPU kernels into Rust through staged tests, shared intermediate-representation checks, and benchmark gates.
A GPU kernel is a small program that performs work on a graphics processor. NVIDIA says its new AI-agent workflow can translate kernels written in CUDA Tile Python or Triton-TileIR into cuTile Rust.
The important part is not simply that an AI agent writes Rust. The workflow is designed so the agent cannot approve its own work based only on a convincing explanation. Instead, separate tools and agents check the result at several fixed points.
NVIDIA has shipped the workflow in its TileGym repository. In its reported test, the system converted all 24 public TileGym operators, covering roughly 40 GPU kernels, and reached 99.5% of cuTile Python performance on average.
The shared layer makes checking possible
CUDA Tile Python, Triton-TileIR and cuTile Rust are different ways to describe GPU work. NVIDIA says all three feed into the same intermediate representation, or IR.
An IR is a standard internal form that a compiler uses before producing machine code. Here, the shared CUDA Tile IR records important details such as memory operations, tile shapes and reductions. Tile shapes describe the chunks of data that a kernel processes at once.
That shared form gives the workflow a reference to compare. It does not need to decide only whether the Rust kernel produces the right final numbers. It can also compare the Rust kernel’s internal structure with the original.
NVIDIA’s process dumps the reference kernel’s Tile IR and the translated kernel’s Tile IR, then compares them. A mismatch might reveal a reduction on the wrong axis, a missing mask or a changed memory operation—even when a small test happens to pass.
This is the answer to the reader’s central question: the workflow does not rely solely on the AI agent’s judgment because the agent’s output is checked against compiler-level artifacts, automated tests and measured performance.
Each agent has a narrow job
The top-level agent acts as an orchestrator, according to NVIDIA. It routes work between specialized subagents rather than writing the engineering itself.
First, an analyzer studies the original kernel. CUDA Tile Python can specialize a kernel automatically when it is called, while Rust requires many of those choices to appear in the kernel signature. The analyzer records variants, data types, tile shapes, tolerances and launch details in a machine-readable file.
It also selects a reference implementation when both CUDA Tile Python and Triton-TileIR versions exist. NVIDIA says it benchmarks those versions and chooses the faster one for each structural variant.
A kernel-writing agent then produces only the Rust kernel. It is kept away from host code and the foreign-function interface, or FFI—the bridge that lets software written in different languages call one another.
That separation makes failures easier to locate. The kernel is first tested inside Rust, without Python or the FFI layer. It also goes through an IR self-check against the analyzer’s reference output.
A host and FFI agent comes next. It creates the wrapper that connects the Rust kernel to TileGym’s Python testing system. Only after the full stack passes TileGym’s correctness tests across its supported shapes and data types does the workflow allow benchmarking.
Verdicts control what happens next
The workflow uses fixed artifacts and validator scripts rather than informal conversation between agents. Each stage must return a structured result with a verdict.
A successful verdict advances the conversion. A failure routes the work back to a defined owner, such as the kernel writer or the host-code builder. If the environment is broken, the process stops instead of asking an agent to guess at the problem.
NVIDIA also sets limits on retries. Its description includes caps for analysis, kernel writing, host building, diagnosis and performance checks. That matters because an unconstrained agent loop can repeatedly rewrite code without resolving the underlying fault.
When a correctness test fails or performance looks unusual, diagnostic agents inspect the IR. One looks for translation mistakes. Another investigates slow cases on both the GPU side and the host side, including launch settings and wrapper logic.
Neither is supposed to rewrite the code directly. They produce a diagnosis for the responsible stage.
Performance is a separate gate
NVIDIA says its performance validator uses CUPTI device-time measurements. These measure time spent on the GPU rather than the complete user experience, which can also include launch and scheduling overhead.
Each configuration is paired with its reference on the same GPU. The workflow requires the geometric mean—the average calculated across ratios on a logarithmic scale—to come within 5% of the reference before accepting the result.
In NVIDIA’s reported benchmark, the comparison used 347 paired configurations across the 24 operators on an NVIDIA DGX B200, with one exclusive GPU for each backend. The overall geometric mean for cuTile Rust versus cuTile Python was 0.995.
That result describes kernel device time in NVIDIA’s test setup. It does not by itself predict application-level latency, nor does it show how the workflow performs on kernels outside TileGym or on other hardware.
What this changes for developers
The practical idea is less “ask an AI to translate my kernel” and more “make translation produce evidence at every step.”
A developer can inspect the generated Rust, the IR comparison, correctness logs and benchmark records. NVIDIA says the skill is already available in TileGym, along with validator scripts, coding rules and worked examples.
The workflow still depends on NVIDIA’s CUDA Tile toolchain and its stated environment, including CUDA 13.1 or newer, Rust 1.89 or newer, the tileiras compiler and a Blackwell GPU for the performance check. Independent users will need to determine how well those checks transfer to their own kernels and hardware.
For now, the useful lesson is straightforward: AI-generated systems code becomes more credible when the model is not the final judge. In this design, the compiler representation, tests and performance gates make the agent show its work.