{"slug": "introducing-int21-and-ptx-kernel-factory", "title": "Introducing INT21 and PTX Kernel Factory", "summary": "INT21 launched as the first company to achieve self-improving AI agent swarms for AI infrastructure, introducing PTX Kernel Factory that generates and optimizes low-level GPU software for NVIDIA hardware. The product is entering beta with four open-source implementations, aiming to automate the expert-intensive process of writing PTX kernels to improve AI workload performance and cost efficiency.", "body_md": "Today, we are launching INT21: the first company to achieve self-improving AI agent swarms, applied to AI infrastructure.\n\n## The Layer Most People Don’t See\n\nMost conversations about AI progress focus on models. But every model depends on a less visible layer: the software that tells GPUs how to perform each operation.\n\nThat software has an outsized effect on speed and cost. It is also difficult to build. Reaching the best performance on a new GPU often requires specialists who understand both the algorithm and the hardware in extraordinary depth.\n\nINT21 exists to make that work more scalable. We call this new category\n**Self-Improving Compute Infrastructure**.\n\n## Our First Product: PTX Kernel Factory\n\nPTX Kernel Factory is an AI system that generates and improves software for NVIDIA GPUs. A team defines the operation, the requirements, and the measure of success. The factory writes an implementation, tests it, measures it on the target hardware, learns from the result, and repeats.\n\nThe first four implementations produced by PTX Kernel Factory are open source\ntoday. The product is also entering beta, with early access available at\n[int21.ai](/join-beta).\n\nFor AI workloads running on NVIDIA GPUs, each model operation eventually becomes instructions executed by the hardware. A GPU kernel is the small, specialized program responsible for one such operation, such as normalization, attention, or moving data through memory. Thousands of these kernels run beneath every training job and AI application.\n\nPTX is NVIDIA’s low-level, assembly-like GPU language. It sits between higher-level GPU software and the final machine instructions executed by the hardware, making it one of the closest programmable layers in the NVIDIA stack.\n\nWorking at this level gives precise control over how data moves through memory, how threads cooperate, when work is synchronized, and which specialized GPU instructions are used. Those choices can determine whether an expensive GPU spends its time working or waiting.\n\nVery few engineers can write and optimize PTX well. The work requires a rare combination of algorithm knowledge, GPU architecture expertise, numerical rigor, and performance intuition. Higher-level tools, libraries, and compilers make GPU development accessible to far more people, but when a new AI operation has no mature implementation, or when existing abstractions cannot reach the required performance, this scarce low-level expertise becomes a bottleneck.\n\nIt is also exceptionally difficult. A kernel can look correct while failing on one rare input. It can be fast for one shape and slow for another. It can use too many registers, move too much data, or perform well on Hopper and regress on Blackwell. Even expert engineers must test many ideas, and most of those ideas do not work. Each hardware generation changes part of the problem.\n\nThat combination makes PTX an ideal first proving ground for INT21: it is technically demanding, economically important, and objectively measurable. A generated kernel is correct or it is not. It is faster or it is not.\n\nPTX Kernel Factory turns the expert loop of writing, testing, profiling, and revising low-level GPU code into a process that can run continuously and learn from its results.\n\n## How PTX Kernel Factory Works\n\nThe interface is intentionally simple:\n\n**Describe the operation.** Define what the kernel needs to do and the inputs it must support.**Set the requirements.** Provide correctness tests, target hardware, and any integration constraints.**Define success.** Choose the performance metric the system should optimize.\n\nFrom there, the factory runs a long-horizon engineering process. It generates candidate implementations, compiles them, rejects incorrect results, benchmarks valid candidates, and uses the evidence to guide the next round.\n\nThe released implementations combine CUDA C++ with inline PTX, giving the system control over hardware details that higher-level tools may intentionally hide. Rather than relying on a single agent to produce a one-shot answer, PTX Kernel Factory coordinates multiple AI agents across this loop.\n\nHuman engineers still define the goal, constraints, and acceptance criteria. PTX Kernel Factory automates the expensive search between a clear specification and a strong implementation.\n\n## What We Mean by Self-Improving\n\nA coding agent can produce an answer. A reliable engineering system also needs to determine whether the answer works, understand why an attempt failed, and carry useful knowledge into the next attempt.\n\nThat is what we mean by self-improving.\n\nMost efforts in this space focus on self-improving the AI itself. We are taking a fundamentally different path, where the agent swarms self-improve the infrastructure they run on, preserving human control while still compounding performance with every production cycle.\n\nThe challenge is less about producing one plausible kernel, and more about building a system that can reject thousands of wrong, fragile, or misleading attempts, preserve the few lessons that matter, and keep improving without drifting away from correctness.\n\nPTX Kernel Factory does not treat every generation as a fresh prompt. It preserves useful discoveries from successful and failed experiments, allowing later work to build on earlier evidence. The goal is to improve the process that produces the code.\n\nThis is how the factory’s performance compounds over time. Each generation begins with more evidence about what works, what fails, and which directions are worth exploring.\n\nOur broader thesis is:\n\nUse compute to improve compute.\n\nIntelligence is not only what a model knows. It is the ability to search, test, remember, correct, and improve. We believe systems that make those abilities cumulative will become an important part of future compute infrastructure and the broader self-improving evolution in AI.\n\n## Our First Proof: Two Very Different AI Workloads\n\nFor the first public release, we chose two workloads that test different abilities.\n\n**RMSNorm** is a common operation used throughout modern language models. It is\nmature, widely understood, and already has strong human-written\nimplementations. It tests whether the factory can compete on established work.\n\n**Kimi Delta Attention (KDA)** is a newer attention mechanism. It is more\nspecialized and has fewer established implementation patterns. It tests whether\nthe factory can adapt quickly to a newer research workload.\n\nWe compared the generated implementations with well-optimized human-built baselines: QuACK for RMSNorm and the CUTLASS-based FlashKDA implementation for KDA. The comparisons were run on the same hardware with correctness checks before timing.\n\n## Benchmark Highlights\n\n| Workload | Hardware | Result against the expert baseline |\n|---|---|---|\n| KDA | NVIDIA GH200, Hopper | 1.24x to 1.59x as fast across six fixed- and variable-length scenarios |\n| KDA | NVIDIA B200, Blackwell | 1.42x as fast through the standard public interface, and 1.52x as fast in an optimized integration |\n| RMSNorm | NVIDIA GH200, Hopper | 8.17% faster on geometric mean across 11 forward cases using a common 16-bit AI format; 15% to 34% faster in selected backward comparisons |\n| RMSNorm | NVIDIA B200, Blackwell | Faster in all 126 comparable cases across the full default benchmark matrix |\n\nThese are operator-level benchmark results, not claims about full-model speedups. The effect on an application depends on its model, workload, shapes, software stack, and how much total time it spends in the optimized operation.\n\nWe also report the less flattering results. In the Hopper RMSNorm matrix, two other number formats included small regressions; the slowest cases were 0.42% and 0.84% behind QuACK. We would rather publish the boundary of the result than hide it behind a single favorable number.\n\n## Correctness Comes Before Speed\n\nA fast kernel is useless if it changes the result or fails on real inputs.\n\nEvery performance comparison therefore begins with correctness:\n\n- The B200 KDA implementation passed all 580 upstream tests.\n- The Hopper KDA implementation passed 584 upstream tests and 235 package tests on the validated GH200 system.\n- The RMSNorm implementations passed their complete package suites on the validated hardware: 48 tests plus 65 subtests on GH200 and 66 tests on B200.\n\nThe suites cover different data types, input sizes, fixed and variable-length sequences, optional state, forward and backward paths where supported, and difficult edge cases.\n\nBenchmarks can still be environment-specific, so each repository includes the source, test commands, measurement method, software versions, and raw or generated reports needed to inspect and reproduce the results.\n\n## Why Start Here\n\nGPU kernels are a useful first test for our approach because the feedback is unforgiving.\n\nThe output is correct or it is not. The implementation is faster or it is not. A change can be compiled, tested, and measured. Progress is grounded in evidence rather than judged by how convincing generated text sounds.\n\nKernel optimization also sits at an important bottleneck. AI models are evolving quickly, hardware is changing every generation, and the supply of low-level optimization expertise cannot grow at the same rate.\n\nTurning more of this work into a repeatable system could help teams:\n\n- Bring new model operations to production faster.\n- Make better use of new GPU generations.\n- Explore optimization ideas that would be too expensive to test manually.\n- Reserve expert time for architecture, requirements, and system-level decisions.\n\nThis is not about removing engineers. It is about giving a small number of experts more leverage.\n\n## Open-Sourcing the First Four Factory Artifacts\n\nToday, we are releasing:\n\n[Int21-AI/KDA-B200](https://github.com/Int21-AI/KDA-B200): Kimi Delta Attention for Blackwell, validated on NVIDIA B200.[Int21-AI/KDA-H100](https://github.com/Int21-AI/KDA-H100): Kimi Delta Attention for Hopper, validated on NVIDIA GH200.[Int21-AI/RMSNorm-B200](https://github.com/Int21-AI/RMSNorm-B200): RMSNorm for Blackwell, validated on NVIDIA B200.[Int21-AI/RMSNorm-H100](https://github.com/Int21-AI/RMSNorm-H100): RMSNorm for Hopper, validated on NVIDIA GH200.\n\nWe are publishing the code because performance claims should be inspectable. Developers should be able to read the implementation, run the tests, reproduce the benchmarks, and challenge the results.\n\nThese releases are not the end product. They are the first public evidence that the factory can produce useful low-level software across established and emerging workloads, and across two generations of NVIDIA hardware.\n\n## About Us\n\nINT21 was founded by Bing Xu in April 2026 as an AI-native company, built on a simple idea: the company’s own engineering capacity should scale with compute.\n\nBing was a co-author of the original Generative Adversarial Nets paper, the original creator of XGBoost’s Python package, and a co-creator of MXNet and AITemplate.\n\nIn February 2025, he co-authored NVIDIA’s early work on agentic GPU kernel generation, using a reasoning model and inference-time scaling to generate and optimize attention kernels. Before INT21, Bing was a Distinguished Engineer at NVIDIA. He joined NVIDIA after it acquired HippoML, the GPU inference startup he co-founded and led as CEO.\n\n## A New Era of Compute\n\nPTX Kernel Factory is now in beta for teams building AI models, inference systems, training platforms, and other GPU-intensive products.\n\nThe starting point can be an operation that is too slow, a new architecture without a mature kernel, or an important workload that has not justified weeks of specialist time. The team supplies the problem and the definition of success. The factory takes on the search.\n\nPTX Kernel Factory is also the first step in a larger direction for INT21, and for the industry more broadly.\n\nMost compute infrastructure today is static: people write it, optimize it, and revisit it when requirements or hardware change. AI systems can generate impressive outputs, but reliably deploying them in production, at scale, remains largely unsolved.\n\nWe believe more of that infrastructure will become adaptive. It will test its own work, preserve what it learns, and improve the way it solves the next problem.\n\nWe are starting with one of the hardest, most measurable layers of the stack. Human knowledge does not scale, but agent swarms can keep getting better with every run. Self-improving compute infrastructure is a fundamental shift in how AI is built.\n\n**Describe the kernel. Define success. Let the factory improve the implementation.**", "url": "https://wpnews.pro/news/introducing-int21-and-ptx-kernel-factory", "canonical_source": "https://int21.ai/insights/introducing-int21-and-ptx-kernel-factory/", "published_at": "2026-06-16 00:00:00+00:00", "updated_at": "2026-07-07 17:33:27.771374+00:00", "lang": "en", "topics": ["ai-infrastructure", "ai-agents", "ai-tools", "ai-research", "ai-products"], "entities": ["INT21", "PTX Kernel Factory", "NVIDIA", "Hopper", "Blackwell", "CUDA C++"], "alternates": {"html": "https://wpnews.pro/news/introducing-int21-and-ptx-kernel-factory", "markdown": "https://wpnews.pro/news/introducing-int21-and-ptx-kernel-factory.md", "text": "https://wpnews.pro/news/introducing-int21-and-ptx-kernel-factory.txt", "jsonld": "https://wpnews.pro/news/introducing-int21-and-ptx-kernel-factory.jsonld"}}