How Long Does It Take to Port a New AI Model? Minutes Now, and Falling

In September 2023 we issued a press release bragging that Llama 2 took us only 13 engineer weeks. It was a good number; other vendors were quoting six months. It is also, in retrospect, the most dated thing we have ever published.

The reason isn't that we got faster. It's that the thing that made porting slow, a human writing kernels, stopped being the bottleneck, and that changes what matters in an AI processor.

Some context for anyone new to Quadric: we don't sell chips. We license a processor core, the Quadric GPNPU, that semiconductor companies build into their own system on chip designs, and we ship the SDK their engineers use to run AI models on it. Getting a new model onto that core is what we mean by porting.

Here is what porting looks like now. On October 27, Liquid AI released LFM3, the newest generation of its small language models. Just after 4 pm that afternoon, an agent started porting the 1.7 billion parameter version. By 5:09 the full 24 layer model was producing correct tokens on our cycle accurate simulator. By 5:57 it was running on an FPGA prototype of our processor core, matching the simulator bit for bit. At 6:09 it recorded this:

That's the FPGA prototype at 75 MHz, shown in real time. On our cycle accurate simulator, decode runs at 94% of its roofline, the limit set by how fast the core can load weights. Nobody optimized it to get there. The agent spent 39 minutes profiling, which mostly confirmed how little was left on the table, until I told it to stop and put the model on the FPGA.

Nor is this something only we can do: any licensee with Claude or GPT gets the same playbook our own agents use, because our skills are served over MCP.

The porting tax

Every new AI model comes with a porting tax. A network is a graph of operations, and an accelerator only runs the operations someone has implemented for it. When a model shows up with an operation the toolchain has never seen, someone has to read the paper, write the missing kernels, check that the numbers match, and only then start making it fast.

The industry has dealt with this tax in two ways.

The first is to pay it with people, at enormous scale, for a very long time. That's NVIDIA's moat. The silicon is excellent, but competitors can approach it. What they can't approach is the decade of kernels that thousands of engineers wrote for it.

The second is to refuse the tax. Most NPUs are built around a fixed set of accelerated operations: if a model sticks to the list, it flies, and if it doesn't, the new operation waits for the next silicon or falls back to a CPU. That works until the models change, which in AI is roughly every week. This is where six month porting targets come from.

Our GPNPU took a third path. Every processing element in the core is fully programmable, so any operation can run on it; someone just has to write the kernel. We paid the tax too, just more efficiently than most. In 2023, "more efficiently" meant 13 engineer weeks for Llama 2, and we put out a press release about it.

The floor fell out

Internally we've started calling this number time to port, or TTP: elapsed time from the start of a port to a model running correctly on our cycle accurate simulator. It's the number we watch most closely, because it's the porting tax expressed as a clock. Here is what it has looked like for us, on a plain linear scale.

The bars go up before they go down. Pi-0.5, a robot vision language action model we brought up this spring, took about seven weeks, nearly twice as long as Llama 2. For most of the last three years, models got harder faster than we got better. Then, over one summer, the floor fell out.

The definitions differ slightly from row to row, so read this as orders of magnitude rather than a benchmark. From Pi-0.5 in the spring to iFormer-T in September is roughly 1,600 times faster, in four months. In the four weeks Llama 2 took in 2023, an agent today could port 876 networks like iFormer-T.

The newest row is LFM3, and its timeline is worth seeing whole.

Quantization was quick because Liquid publishes its own 4-bit weights, trained to be quantized, and our toolchain imports them exactly. Running on the device added essentially no error on top of Liquid's own quantization.

The models didn't get easier, either. Qwen3.5 is a 4 billion parameter vision language model. V-JEPA is a world model running attention over 2,048 video patches. Alpamayo 1.5, NVIDIA's 10 billion parameter driving model, arrived as a complete four stage example in its very first commit and was running across four cores within days.

What actually changed

Agents got smarter, but that alone doesn't explain it. A smart agent dropped in front of an unfamiliar processor burns an afternoon learning what our engineers learned over years. What changed is that we wrote those years down.

Those years deserve more credit than a post about agents usually gives them. Before an agent could port anything in 46 minutes, our engineers spent years building the things it drives: the Chimera Compute Library and its kernels, a compiler for the GPNPU built on LLVM, a graph compiler that lowers whole networks onto the core, and a cycle accurate simulator to check every result against. An agent writing five new kernels in an afternoon is mostly an agent standing on kernels, compiler passes and test cases that people wrote first. The agents didn't replace that work; they made it compound. Thank you to the team that built it.

Over the past year we turned how we actually port a model into a set of engineering skills for agents: how to read a profile, how the core's memory hierarchy behaves, how to write kernels against the Chimera Compute Library, and above all how to prove a result is correct. The most important thing the skills encode is an order of operations. First, write a twin of the model in PyTorch in exactly the form the processor will compute it, and prove it matches the original. Then pick the precision by measuring what each choice costs in accuracy. Then write the kernels, each with a CPU reference the simulator is checked against, so when something disagrees you know exactly where.

That order lets agents work in parallel without getting lost. On the V-JEPA port, one agent built the twin, another chose the precision and a third wrote the kernels, all at once; the first full transformer block was running on the simulator 33 minutes after the first prompt.

Most of what's in those skills came from customer support. Our engineers have spent thousands of hours alongside customers' engineers, bringing up their models on our core, chasing down their accuracy bugs and tuning their kernels. For years that knowledge lived in a few people's heads. Now it lives in skills that any agent can load.

It also compounds, which is why the chart looks like a cliff rather than a slope. Every port teaches the skills something: a bug pattern, a faster kernel recipe, a better check. The next agent starts from there. Better models, better skills and a faster toolchain multiply rather than add. I don't think TTP has found its floor; every input to it is still improving, and none of them slowly. The more models we port, the more our agents can do, and the more they can port next. Anyone can use the same frontier models we do. What they don't have is the thing we've gotten very good at: turning the art and science of writing and optimizing kernels into skills an agent can follow.

Fast, and provably right

Fast and right are different things, and an agent will cheerfully hand you a fast port that is subtly wrong. So the skills spend more effort on proof than on anything else.

Every agent port in that table cleared a bar that a machine checks, not a person. Each kernel has a CPU reference, each port has a gate it must pass on inputs the agent never saw, and each checker is itself tested by planting an error and confirming it gets caught. Nothing counts as ported until the gate says so.

For vision networks the bar is bit for bit: the processor has to reproduce the quantized reference model exactly. On iFormer-T that meant 20 real images, 16 of them held out, with zero mismatches across a million kernel outputs, and a port that reproduces from scratch with one command in under 15 minutes. We ran the same experiment on five networks, with Claude and GPT driving the same toolchain, and all five came out exact, in anywhere from 7 minutes to 3 hours, with 51 custom kernels written along the way.

Language models and world models have legitimate freedom in their arithmetic, so there the bar is a tight tolerance against the original float model over many inputs, and then the hardware has to agree with the simulator. LFM3 matched it bit for bit on the FPGA the same afternoon it was released.

Your agent, our playbook

None of this is an internal capability. Our skills are served over MCP. That's all the server does: it hands the playbook to whatever agent you already use. A licensee who connects Claude or GPT gets the same skills our agents use, drives the same SDK, and gets the same results we do.

That changes what model support means. A vendor's model zoo used to be a list of the networks its engineers had gotten around to. If your model wasn't on the list, you waited, or you filed a ticket and hoped. Now the list is whatever your agent decides to port this afternoon, and you don't need to wait for us at all.

Why programmability matters now

The porting tax was always a labor cost, and both of the industry's answers to it were answers about labor. NVIDIA could afford to pay it, and the payments became a moat. Fixed function NPU vendors couldn't, so they designed silicon that didn't need it, and accepted falling behind whenever the models moved.

Agents make that labor nearly free, and moats made of labor don't survive labor getting cheap. So what replaces them? Labor was the old moat. The new one is how much you can scale expertise.

On a fixed function NPU, an agent can't help with a missing operation: if the silicon doesn't have it, no software puts it there, and the best the agent can do is write a polite ticket. If it's unlucky, a feature request for the next generation of silicon, and then a years-long wait for it to tape out. On a programmable processor, a missing operation is just a kernel nobody has written yet, and writing kernels is something we've gotten very good at teaching agents to do.

Programmability always had a price, and the price was people. For years it was the hardest part of our architecture to explain, because the benefit was abstract and the cost was obvious. Agents took the cost away. What's left is a processor core that can run anything, which now means a processor core an agent can port anything to.

What comes next

Porting is only the first step. Making a model fast is the next one, and our MCP server serves a kernel optimization skill for that too. For the hardest kernels there's our Kernel Arena: the V-JEPA world model we ported in an afternoon became more than twice as fast in a day and a half once the arena got hold of it.

In 2023 we were proud of four weeks. Today TTP is measured in minutes, and the only direction we can imagine it going is down. I suspect this post will look just as dated a year from now, and I mean that as the most optimistic thing in it.