One Model. Hundreds of Specializations.

Ask a frontier model to click a button in a CRM and it will usually get close. Close is the problem.

We put nine frontier models on 139 held-out screens from a live customer-service CRM and asked each one where to click. To count as correct, the box a model predicted had to genuinely overlap the target, which is the standard object detection has used for a decade. The strongest model in the field, OpenAI's newest at the time, got 44.6% of them right.

Our 4B model got 92.09%.

Twice the accuracy of the best frontier model money can buy, on a task that amounts to clicking the right thing in a business application. It was trained on fewer than a thousand datapoints.

The score is not the part we are proudest of, though. The customer running that model does not train a four-billion-parameter model, does not store one, and does not serve one. They train a small, specific set of weights inside a base model that already exists, and what they end up owning is an 80 MB file. We call it a slice.

Working out which weights belong in that file, and building something a production server can actually run, took three problems worth of work:

• Which layers carry the specialization. Most of a vision-language model does not need to change for a new customer. We ran the layer-wise analysis to find the part that does, because guessing gets it wrong.
• How to cut those weights out without changing anything else. Extraction has to be exact. A serving node that swaps customers all day cannot be quietly corrupting itself while it does.
• How to make the result a real build artifact. Versioned, checkable, portable between machines, and loadable by a production server with nobody watching it.

Solve all three and a customer's model goes from 8.88 GB to 80 MB, and a hundred of them run on one GPU at once. That is the business.

Problem one: which layers actually matter

A 4B vision-language model has hundreds of weight tensors. Fine-tuning all of them gives you a second 8.88 GB model per customer, which is exactly the thing we are trying to avoid. So the first question is simple: which tensors actually need to change?

There is no principled answer in the literature, and the intuitive answers are wrong. Retraining the vision encoder, the conventional prescription for a new visual domain, is close to redundant: the encoder already sees what it needs to. Retraining the language side moves nine tenths of the weights and makes the model worse. The parameters that matter sit in a narrow band where the visual representation crosses into the language model, and you cannot find that band by reasoning about it. We found it by defining a taxonomy of candidate placements and training every one of them, on multiple tasks, across two model families, then measuring which held up.

The answer is a set of layers we call the junction set, between 1.5% and 2% of the model's parameters. We do not repeat that search per customer. Every new specialization trains the same known set of layers, which is why onboarding a customer is a training run rather than a research project.

Where the cut sits matters as much as how big it is. Cut at the junction and the expensive majority of the model remains identical across every customer. Cut a few layers deeper and that shared computation disappears. That placement is not just a training result; it is the architectural decision our inference engine is built around. Find the right 2%, and suddenly hundreds of specialized models can share the other 98%.

Problem two: cutting it out without breaking the model

Knowing which tensors to take is half of it. Getting them out, and back in, without perturbing the model is the other half, and it is a correctness problem rather than a performance one.

A slice is not a compressed approximation of a fine-tune, and it is not a patch applied on top of the base at inference time. It is the actual trained tensors, extracted directly from the PyTorch model state. Applying one writes those tensors directly into the corresponding parameter buffers with identical shape and dtype: no merge, no reconstruction, no arithmetic. The 8.88 GB base never moves. The ~80 MB specialization does. Restore the original tensors and the model returns bit-for-bit identical to the untouched base. We verify this at the tensor level and across a full base → slice → base decoding cycle.

That invariant is what makes our inference engine possible. The base model stays permanently resident on the GPU; switching customers means swapping ~80 MB of specialization state instead of loading another 4B model. One customer's slice leaves nothing behind for the next, and rolling back a customer means changing an artifact, not redeploying a model.

We test the opposite direction too: a swap must actually change behaviour. Slices trained on deliberately different objectives produce different answers to identical inputs, while restoring the base reproduces its original behaviour. Apply changes behaviour. Restore recovers the base exactly. Either direction takes 16 ms.

Problem three: building an inference engine for slices

This is where most of the engineering went.

Existing inference engines are built to serve one set of model weights extremely efficiently. We needed an engine that could serve hundreds of specialized models as if they were one. So we built our own inference engine on top of vLLM, keeping its high-performance CUDA execution, continuous batching and KV-cache machinery, but changing the fundamental unit of model state from a checkpoint to a slice.

The 8.88 GB base is loaded once and stays resident. Each customer's ~80 MB slice is a versioned, self-describing artifact containing the tensor payload and a manifest pinning its base revision, placement, shapes, dtypes and content hash. Our runtime validates and stages these slices, while a slice-aware scheduler decides which specialization needs to be active for each request. We swap specialization state, not models.

That changes the economics completely. A normal serving stack sees a hundred fine-tunes and thinks a hundred models. Our engine sees one model and a hundred 80 MB pieces of state. The expensive weights, execution engine and GPU memory are shared; only the tiny part that makes the model customer-specific moves.

That is the payoff of building the engine ourselves on top of vLLM: specialization becomes a runtime primitive rather than a deployment primitive. The base stays hot. The slices move. And adding another customer starts looking less like deploying another model and more like scheduling another request.

The task

The benchmark is UI grounding on a real product: the ticket-disposition workflow of a customer-service CRM, captured live while agents worked. One sample is one decision point. The input is a screenshot of the page as it looked immediately before the agent acted, plus an instruction like "open 'Assign To' and pick an agent option" or "type into 'Search sub folder' to filter L2/L3 suggestions". The model answers with JSON: an action, click or fill, and a bounding box on a 0–1000 scale.

These are not big obvious buttons. Twelve distinct intents span 269 distinct selectors, and the held-out set alone contains 42 distinct target boxes across 18 tickets: suggestion chips inside a three-level disposition folder tree, an autocomplete field that only exists after a parent selection, a callback checkbox, the tab that reveals a conversation's email body. Several targets are roughly 29 by 56 units in a 1000-unit space. Landing a cursor somewhere in the right neighbourhood of one is easy to do by accident, which is why we do not score it that way. A prediction counts only if the box it names substantially covers the element it is supposed to hit.

We split by ticket rather than by sample, smallest ticket first, so that no screenshot from a training flow leaks into evaluation as a near-duplicate.

What the field actually scored

The rest of the picture, and it is consistent:

Mean overlap is the number we find most telling. Ours is 0.882, so when our model names a box it is essentially the right box. The best competitor manages 0.529 and most of the field sits between 0.25 and 0.37. A figure around 0.3 describes a model that knows roughly which region of the screen you mean and has no idea where the element ends. For a demo that is fine. For an agent that has to click twenty-three times in a row with nobody watching, it is not.

Action precision points the same way. Ours is 100%: on every response that parsed, the model correctly told "click this" apart from "type into this". The field ran 79% to 85%. One in five actions being the wrong kind is not a rounding error in a workflow that has to run to completion.

Fewer than a thousand screens

The training set is under a thousand labeled screens. That is the whole thing. No synthetic augmentation, no contractor pipeline, no reinforcement learning stage. It is the byproduct of instrumenting a workflow that agents were already performing, captured as a side effect of the product running.

Two things stand out. A few hundred examples already beat every hosted model in Figure 1, which means the bar for onboarding a customer is a dataset they can produce in a week of ordinary operation rather than a labeling project. And accuracy was still climbing when we stopped adding data, so we are limited by how many screens we have and not by the size of the model. The fix for the next customer is more of their screens, not a bigger model.

What this buys on one GPU

A 4B base sits in 8.88 GB resident. Each customer's slice adds about 80 MB. The base loads once and is never duplicated, so the fleet's memory footprint is set by the model, not by how many customers you have. This is the entire commercial argument, and it only works because the cut is in the right place.

Co-residency would be worth having on its own. What makes it fast is the shared remainder: because every slice is cut above the language model, the expensive part of the computation is identical for all of them and runs once for the whole batch. Different customers, different screens, different slices, one pass, different answers. Verified end to end, with nothing swapped between requests.

That is also where the latency goes. Served one at a time, each specialist costs about 1,430 ms. Batched over the shared base, total time barely moves as the batch grows, so per-request latency falls to 156 ms at a batch of ten. Nine customers get served in the time the tenth would have taken alone.

Cost and speed

A real disposition task runs about 23 steps. Priced at published rates from token counts captured off live API responses, that is what each model costs and how long it takes.

Speed follows the same shape, for a different reason. Hosted models burn wall-clock on reasoning tokens: GPT-5.6-sol averages 620 output tokens for a bounding box, GLM 1,517, Kimi 2,028. Ours emits a short JSON object and stops.

Nine seconds against a minute and a half is the difference between an agent a human can supervise and a batch job. The two open-weight reasoning models are also wildly variable, with single calls of 58 to 82 seconds sitting next to others under ten.

Because the base is shared, the fixed cost divides across the fleet. This is the one thing per-token pricing structurally cannot do.

A hundred customers as independent fine-tuned models would need 888 GB of weights, so twenty cards before anyone gets an answer, or roughly $161 per customer per month against our $8. And that is only the memory bill, with none of the batching economics.