When a company open-sources a cloud model, the industry reads it as a developer-relations move. Weights go up on a model hub, download counters climb, and the conversation centres on access: who can build with this, and what will they build?
I have spent the last several years co-designing on-device language models with the silicon they run on, across three generations of a flagship device line. And I can tell you that when the model being released is an on-device model, one whose architecture was negotiated, decision by decision, against the constraints of a specific edge accelerator, open-sourcing it is not a developer-relations move at all. It is an act of ecosystem architecture. You are not just publishing weights. You are exporting your hardware team’s design decisions into every competing silicon roadmap in the industry.
That distinction, between access and architecture, is the most underexamined dynamic in on-device AI today. It determines which organisation’s design language the mobile industry standardizes on, and it is being decided right now, largely out of public view.
A cloud model travels light. An on-device model carries its hardware with it.
Here is the difference that everything else follows from. A cloud model’s architecture is shaped by economics that are, at inference time, abstracted away from almost everyone. Whether it runs on one vendor’s GPUs or another’s, the serving stack absorbs the difference. The weights travel light.
An on-device model cannot travel light. Every consequential choice in its architecture was made against a hard budget: the compute, bandwidth, and power envelope of a specific neural processing unit. How attention is structured, which operators appear in the graph, how far the weights can be quantized before quality collapses — each of these decisions has a hardware constraint on the other side of it. Co-design means exactly this. The model is bent toward the silicon, and the silicon toward the model, until a production gate is met. In our case that gate was concrete: 100+ tokens per second on device, the threshold below which an entire generation of AI features would not ship.
Now open-source that model. The weights that go out the door carry the accelerator’s fingerprints in every layer. The quantisation format assumes certain hardware support. The operator choices reflect one accelerator’s strengths. The compute-bound balance of the architecture encodes one team’s judgment about where mobile silicon is heading.
And here is the mechanism that makes this ecosystem architecture rather than mere publication: competing platforms do not get to relitigate those decisions. Developers want to run the model that exists, that is proven, that has momentum. So rival silicon vendors implement support for its operator set. Rival device makers tune their inference stacks to its shape. The path of least resistance for the entire industry becomes compatibility with an architecture that was originally optimized for someone else’s chip. One organisation’s co-design constraints quietly become everyone’s reference standard.
What three generations of diffusion actually look like
This is not a theoretical argument. I watched it happen in stages.
The first generation was a first-party story: the first multimodal LLM, understanding text and images together, running natively on a mobile phone. It shipped on one device line, on one accelerator, and it stayed there. Impressive, and contained.
The second generation was released as open weights. It crossed 2M+ downloads and, for the first time, the architecture escaped its native hardware. Developers ran it on devices its designers had never targeted, and its structure began showing up in derivative work across the ecosystem.
The third generation made the pattern unmistakable. The open release passed 6M+ downloads, and the model now runs in production not only on the first-party device line it was designed for but on its largest competitor’s flagship phones. We also open-sourced a companion piece of inference infrastructure, a drafter model for multi-token speculative decoding that breaks the autoregressive bottleneck on edge devices, and it was adopted across two rival mobile silicon ecosystems. The architecture designed against one accelerator’s constraints is now the substrate for on-device intelligence on hardware built by companies that compete fiercely with its originator.
Notice the trajectory: first-party proof, then open release, then cross-platform adoption, each generation diffusing further than the last. That is how on-device AI infrastructure actually moves through the mobile industry. Not through licensing deals or standards bodies, but through open weights that competing platforms find cheaper to support than to replace.
The conditions under which your architecture becomes the standard
Open-sourcing alone buys nothing. Roughly half the models on the largest public model hub have fewer than 200 total downloads, while the top 200 models account for nearly half of all downloads. The ecosystem does not standardize on what is available. It standardizes on a handful of reference points. Three conditions decide whether yours is one of them.
Shipped proof beats benchmark proof. A model that cleared a real production gate, sustained tokens-per-second on a phone in a pocket with thermals and memory pressure included, arrives with evidence no leaderboard can supply. Competing platforms adopt architectures that have already survived contact with consumer hardware, because that adoption is de-risked by someone else’s launch.
Timing against the hardware wave. The substrate is being laid at extraordinary speed: generative-AI-capable smartphones grew more than 360% in 2024 to 234 million units, and are forecast to reach 912 million units and 70% of all smartphone shipments by 2028, a category defined precisely by the presence of a capable NPU. Every one of those NPUs needs a model to run. An open architecture released into that vacuum, at the moment silicon vendors are deciding what to optimize for, gets designed into roadmaps. The same release two years earlier finds no hardware; two years later, it finds the decisions already made.
Release the stack, not the checkpoint. The small-model tier is where the volume lives — the median model downloaded from public hubs has stayed around 400 million parameters even as headline models balloon — and adoption compounds when the release includes the machinery around the model: the drafter that accelerates it, the encoder that gives it vision, the quantisation recipe that fits it into a phone’s memory. A checkpoint is a curiosity. A stack is a dependency.
Deploying is a product decision. Enabling is an infrastructure decision.
The strategic gap this exposes is one most organisations have not named. Deploying a model on first-party hardware is a product decision: it differentiates a device, and its value is captured at the point of sale. Enabling that model to function across third-party ecosystems at scale is an infrastructure decision, and its value is captured somewhere else entirely: in the gravitational pull of being the architecture everyone else’s tooling and silicon are shaped around.
These two decisions are usually made by different people, on different timelines, with different success metrics. The organisations that treat the open release as an afterthought to the product launch get access: downloads, goodwill, derivative projects. The organisations that treat it as the second half of the co-design process — proof on first-party silicon, then deliberate export of the architecture at the moment the ecosystem is most receptive — get something more durable. They get to set the terms on which an industry builds.
The exclusivity instinct says a hardware company should keep its co-designed model close, because the model is the differentiation. The evidence of the last three device generations says the opposite: the differentiation is fleeting, and the standard is permanent.
In on-device AI, open-sourcing the model was never about giving away the product. It is how you publish the standard.
