What happened
The project, named open-flapping-airplanes, is a GitHub release by Jerry (Bobliuuu) and Arnold Xu of Magni. It reproduces the Flapping Airplanes megakernel: one GPU kernel that trains a model, serves it, and runs Doom at the same time. The authors say they rebuilt the implementation from the company’s demo video. That distinction is important: this is an open reproduction of a demonstrated system, rather than a release of the original Flapping Airplanes code.
The repository describes a fused execution design in which work normally separated into training and inference paths is brought into a single kernel-oriented implementation. Its stated purpose is to make the design available as an open reference. The supplied material also describes the project as a reproduction of a “train-and-serve megakernel,” rather than a general-purpose serving framework or a hosted AI product. No paid tier, API access plan, general-availability service, or support commitment is stated in the supplied evidence. Builders access it as source code through GitHub.
The supplied material reports serving results on an Nvidia B200. With live weights and 24 streaming multiprocessors (SMs) assigned, the reproduction measured 1,660–1,741 tokens per second. The cited comparison figures are 1,076 tokens per second for the original and 1,537 tokens per second for vLLM at batch size one. The authors qualify the run as CPU-bound and say that 16 CPU cores were reserved. That matters because the observed serving number is not an isolated measurement of GPU kernel behavior: host-side resources and the stated allocation are part of the test conditions.
For training, the reproduction ran 4,000 steps on 116 SMs in 48.1 seconds. The supplied comparisons are 46.1 seconds for the original system, 62.4 seconds for Megatron+TE in eager mode, 52.5 seconds for PyTorch with flash-attn, and 43.1 seconds for Megatron+TE with CUDA graphs. The result is therefore not a blanket claim that the reproduced megakernel is the fastest option. It is faster than the cited eager Megatron+TE and PyTorch-plus-flash-attn runs, while slower than the CUDA-graphs Megatron+TE result and slower than the original’s reported training time.
These are author-reported measurements, and the release exposes a useful contrast rather than only a headline result. For a builder, the concrete artifact is an implementation that can be inspected and potentially reproduced alongside explicit comparison conditions: B200 hardware, SM allocations, 4,000 training steps, batch-size-one serving, live weights, and the CPU-bound caveat. The source does not establish behavior beyond those conditions, but it does make the claimed train-plus-serve architecture more accessible for technical examination.
What the archive adds
Our earlier note, OpenBMB open-sources ForgeKernel, a self-evolving agent for GPU kernel optimization, covered a different GPU-kernel project: an optimization agent rather than a reproduction of a fused train-and-serve kernel. This is a new event in the broader thread of open artifacts for GPU-kernel work, not a continuation of ForgeKernel.
Trend signal
This is a weak fit for agent economics moves to completed work. The repository reports elapsed time and token throughput, but it does not measure cost per verified completed task, nor does it show a production deployment outcome. Its firmer signal is methodological: an open reproduction can turn a striking systems demonstration into something engineers can inspect, benchmark, and challenge under stated conditions.
Why it matters
Teams building AI systems often encounter performance claims as isolated demo numbers, with little ability to determine whether a claimed advantage comes from kernel design, hardware partitioning, CPU resources, a particular workload, or the choice of baseline. This release supplies source code and a bounded set of comparisons around an unusual alternative: placing training and serving in the same GPU-kernel design while another workload runs alongside them.
The useful implication is not that a megakernel should replace an existing stack. The evidence instead shows why benchmark discipline matters. The reproduction exceeds some cited baselines, loses to Megatron+TE with CUDA graphs, and reports serving in a CPU-bound configuration with 16 reserved cores. Teams considering fused execution should keep the conditions attached to each result, compare against their strongest practical baseline, and test the model, batch size, CPU allocation, hardware, and traffic mix they actually operate.
Limits and uncertainty
The figures are the project authors’ measurements, not an independent replication. The source does not establish how the implementation performs on GPUs other than a B200, with other models, at other batch sizes, or under different training and serving mixes. It also does not specify total cost, power use, reliability, operational complexity, or the engineering cost of adopting this architecture.
The serving comparison is explicitly CPU-bound and uses 16 reserved CPU cores, so it cannot isolate the GPU-side contribution of the kernel. Training comparisons also differ by implementation choices, including whether Megatron+TE uses CUDA graphs. The evidence supports treating the repository as an inspectable, reproducible reference and its numbers as workload-specific evidence, not as a general benchmark verdict or a promise of production advantage.
Skill to build now
Choose one performance claim in your own AI stack and write down the complete test contract before optimizing it: model and version, hardware, CPU allocation, batch size, concurrency, workload mix, warm-up behavior, metric, and baseline configuration. Then run the comparison against the best alternative your team could actually deploy, not only an eager default. The release’s most reusable lesson is that a result becomes more actionable when its resource partitioning and losing baselines are visible alongside its winning ones.
Reader takeaway
open-flapping-airplanes makes an unusual fused train-and-serve megakernel available for inspection, with measurements that are more useful because they show both wins and losses. It is a reference for engineers investigating GPU execution design, not proof that a single fused kernel is universally faster than established training or serving stacks.
Open question
Can independent users reproduce these results under the same B200, CPU-allocation, and workload conditions, and does the architecture retain an advantage when the serving path is no longer CPU-bound?