Team #
We are a small team with our own mathematics and a Tensor Engine built from the ground up.
We are driven by theories, architectures and measurements. Two of our papers are on our
Publication page.
Founder’s Note #
For about ten years I led a team that built an engine for wash sale, one of the heaviest number-crunching jobs in Wall Street tax. When I met the Transformer, it was a shock. A few billion calculations in a few seconds. To me it was not coding but pure mathematics infused in a machine. I was but a frog in a well.
I designed a few forms of pipeline parallelism in PyTorch. All were too fragile and did not perform. Nothing in the mathematics blocked it. One thing I believe is that mathematics does not lie. The fragility had to be in the execution, but I could not see what failed or where. So around Halloween of 2025, we started our own Tensor Engine.
It was a fun and brutal ride.
Today we are proud to bring pipeline parallelism to practical reality. A small start. We would like to believe we changed the future a little.
November 13, 2026
When did you last see NVIDIA with enough RAM lose to Macs on speed? No, we are not talking about power efficiency or about a large model that never fit on a single card.
GR00T is a popular robot model made by NVIDIA. NVIDIA published its performance on an H100
[here](https://github.com/NVIDIA/Isaac-GR00T). Then
[Fenon AI](https://www.fenon.ai/blogs/gr00t-n1-7-h100-inference) topped it
also on an H100. The question is: can NVIDIA’s own model on a highly optimized setup lose on speed to Macs? Read on
for the result, the method and how to run it yourself. Here is the result.
How we did it #
A robot policy looks through the robot’s cameras and answers with the next chunk of actions. One answer is one chunk: the model predicts 40 action steps, and the client uses 16.
A room of robots does not need one fast answer. It needs many answers at once. So many robots share one model. Requests that are waiting are answered together, up to 16 in one model call. Each Mac holds its own copy of the model and serves its own 48 clients.
Inside one answer, three things happen. A vision part reads the two camera frames. A language part reads the instruction and the robot’s state. Then the action part, a diffusion transformer, turns that into motion in 4 denoising steps.
The model’s values are NVIDIA’s, unchanged, in 16-bit. We changed how the engine runs them. In our report’s words, the build used “M5 FP16 projections, Neural Accelerator vision attention, packed DiT projections and scratch reuse.” Together they took one request from 62.66 ms on our starting build to 44.34
ms: 1.41× faster. The engine is the same one as in our first article. Here is the run on four MacBook Pros.
Now the honest part #
The H100 figures are published by others, for one request at a time. We did not run them, and nobody has published an H100 rate for many requests at once. Ours is 192 clients at once, on four machines against one card.
For one request at a time, the H100 is faster. Its HBM memory has more bandwidth, and that is superior for a single robot’s inference. If you have one robot, the H100 wins. When you have many robots, four MacBook Pros serve them 2.45× faster than the fastest H100 figure in print, and 4.24× faster than NVIDIA’s own published figure.
And the price. Four of these MacBook Pros list at $19,996. One H100 card costs at least $25,000, and you cannot run an H100 by itself.
Our own target was 100 chunks a second per Mac. We did not reach it.
No robot moved. Recorded camera frames went in, and actions came out. This is how fast the policy answers, not how well a robot does its task.
Under the 192-client load, half of the answers came back within 1,275 ms. All 1,536 requests in the measured run returned valid actions, with 0 errors. The details are in our
Run it yourself #
The one-Mac version is a free download. Get NukeTorch and the GR00T bundle, and follow the GR00T part of the README. Start the server with the policy beside a text model, and run the built-in benchmark. It sets your run beside ours.
On one MacBook Pro M5 Max with 48 GB, we measured 37.2 chunks a second with 16 clients, and 44.8 ms for one request at a time. If you have a more capable Mac, we would love to hear what result you get.
For the multi-machine version, please request an evaluation license: [email protected]
What it means #
A robot lab without a specialized data center. Four laptops on a desk, on wall power, with no rack, no external fans and no liquid cooling, running inference for 192 robots. No waiting for a power permit.
Robotics has our full attention. Please share with us what you need most: more robots per machine, a faster single answer, or another policy model.
Speed is our passion. Our questions were:
- How much can software fill the gap left by missing high-bandwidth HBM memory?
- Is the NVIDIA chip simply better, HBM or not?
GR00T was one study of whether similarly priced consumer MacBooks can win on speed against highly optimized NVIDIA hardware.
November 12, 2026
Most analysts estimate that about four of every five AI chips sold are NVIDIA’s. NVIDIA’s hold is even stronger in training large models. It can look like a sacred realm, where almost no one else is allowed to set foot. We thought: do we have a chance?
At WWDC 2026, Apple shared a training video. Apple used data parallelism to LoRA fine-tune Qwen3.5-9B on four M3 Ultra machines. So we did it too. Same job. Same recipe. Same WikiSQL training steps. We wanted to see how our NukeTorch stacks up.
Here is the result.
| Apple, WWDC26 | NukeTorch | |
|---|---|---|
| One machine | ~180 tokens/s One M3 Ultra Mac Studio | 1,440.8 tokens/s One MacBook Pro M5 Max, 48 GB |
| Four machines | ~600 tokens/s Four M3 Ultra Mac Studios | 5,358.5 tokens/s Four MacBook Pro M5 Max, 48 GB each |
| Method on four machines | Data parallel | Pipeline parallel |
| 1,000 steps on four machines | About 40½ minutes at that speed | Under 5 minutes |
- One machine trains 4 examples per step and four machines train 16, as in Apple’s two commands. The machines differ, and Apple’s figures are the ones spoken in its session. We did not run Apple’s setup. The details
are in our [one-Mac report](https://nuketorch.ai/reports/qwen-9b-one-mac.pdf) and our
[four-Mac report](https://nuketorch.ai/reports/qwen-9b-fine-tuning.pdf), and you can watch the
four-Mac run in our [video demo](https://www.youtube.com/watch?v=XG8tV_RL8OA).
How we did it #
There are two parts: speed and pipeline. The speed comes from the engine, and two of its ideas are published.
Unfolding
A tensor’s values are fixed. How they are stored and read is a choice. Unfolding is changing that choice.
Memory is one line. Several values share one machine word, and a kernel takes a handful of values at a time. If its handful is spread over many words, it fetches many words to use a few values. If a word holds c values and the kernel makes m draws, the words it must fetch, Φ, obey:
m ≤ Φ ≤ c·m
Unfolding moves the store to the low end, Φ = m. A real case: a public four-bit model packs eight neighbouring codes into each 32-bit word, but each lane of our decode kernel takes every 32nd code. Unfolded, the eight codes a lane needs share one word, and word fetches fall from 256 to 32 per block.
You can also leave the file alone and redraw the kernel. On one matrix, a test kernel that reads the file as it is ran 4.9× faster than our engine’s loop: 516 GB per second, 94% of the 546 GB per second that Apple states for the chip.
It was a journey of discovery. First we credited a gain to the order of the values. After many iterations we learned that most of the gain came from the form of the kernel’s loop.
The detail is in our paper, Unfolding: Theory and Principles. If there is enough interest, I can write another article about it, so you do not have to read all 27 pages yourself.
Shaping neural simulation
We call any neural network running on any device a neural simulation. A matrix product in it has three axes: rows M, output width N, and reduction length K, the number of products summed into each output value.
We expected the size of a program to set its speed. It did not. The rate was set by one axis, the length of the sum K. Past a knee, doubling K halves the rate. So we cut one long sum into P shorter ones and add the partial sums.
On that layer pair, shaping raised the rate 3.12 to 3.46×, while cutting by output channels left it at 0.99 to 1.00×. With the same change, Whisper large-v3-turbo transcription took 21.5% and 21.9% less time on an M4 Max and an M5 Max. It does not always help: at one row per call, the split gains at most 3.4%.
The full detail is in Understanding the Shapes of Neural Simulation, 28 pages. Again, I can write another article if needed.
One honest note. Both papers measure inference, and we have not yet published a breakdown of the training speed.
Pipeline parallelism
We named ours the Choo-Choo Relay Train. Like a train, it connects machines in a line, with a single Thunderbolt
cable between them. You can see our setup in the video on our X. The usual way to use four machines is data parallel: every machine holds the whole model. Apple’s WWDC26 run was data parallel. In a pipeline, each machine holds only its assigned layers, and together they work as one distributed machine. It does not make a single prompt faster. Our speed comes from the mathematics.
- It keeps the speed. Four Macs ran at 93% of four single Macs.
- It uses a fraction of the memory. Spread a model over N machines, and each needs 1/N of the RAM for the weights that data parallelism needs.
- It uses less energy. 7.3% less per trained token than our own data parallelism on the same four Macs. Boring? That was Apple to Apple, pun intended. Next we will compare the same model on NVIDIA and AMD.
Run it yourself #
The one-Mac trainer is in the free download. Get NukeTorch and the training bundle and follow the README: one command, about five minutes, and it prints your tokens per second. It is free to download and use under our license.
On a MacBook Pro M5 Max with 48 GB the download trained at up to 1,242.0 tokens/s, the best of our five runs; their median was 1,195.4. That is not the 1,440.8 in the table, which is from our report and video demo. The version that pipelines several machines is by invitation: [email protected]
What it means #
Pipeline parallelism has long been our north star. A model no longer has to fit in one machine.
We designed the Choo-Choo Relay Train for the AI data center. Our goal is a line of machines, each holding just a single layer of a large model. No single pool of memory that must hold the whole model. No special interconnects, which are costly and labor-intensive. Each machine needs only enough RAM for its one layer, and a cable or two to its neighbours.
Acknowledgement #
For a small team like ours, it would not have been possible without the contributions of others: the amazing CUDA community, open-source models like Qwen, the sea of knowledge deposited in arXiv, the oMLX community, where many of our models were sourced, the personal AI machines of Apple, and the explosion of frontier AI models, whom we acknowledge not as tools but as partners. We hope to contribute back to the fundamental acceleration of Intelligence.