embedding

Blog/October 2026·7 min

vega-U: one engine, any reader

The universal adapter: a 14.3M decision engine in a shared space that any frozen LLM can plug into through a small linear port. Readers it never trained with score highest, up to 0.811 held-out with a cold-attached 27B.


Every decision model we have shipped so far married its decision layer to one backbone. laya is a 421M encoder with its head. vega is an adapter trained on a specific frozen Qwen3.5. If you wanted the same calibrated decisions on a different LLM, you started over.

vega-U removes that marriage. The decision engine, 14.3M parameters, about 57MB on disk, lives in a shared 1024-dimensional feature space that no single model owns. Each reader, meaning each frozen LLM, gets a port: one small linear map per tapped layer that carries its hidden states into that space. The engine never sees a backbone, only the space.

Qwen3.5 0.8BportGemma 3 1BportQwen3.5 4Battached coldportyour LLMportshared space1024 done engine14.3M, frozen fitanswerp = 0.93
Readers stay frozen, each with its own port. One engine reads the shared space.

The method: five decisions that make the space real

A shared space is cheap to claim and easy to fake. If you train an engine on features from one model and bolt on a projection from another, the projection learns a disguise: it maps the second model wherever the loss is low, not where meaning lives. vega-U is built from five deliberate choices that close that loophole.

1. Anchor the space to one reader. The shared space is not an abstract latent that training is free to invent; it is literally the reference reader's own standardized feature space, and that reader's port is frozen as the identity. This pins the coordinate system. Every other port has a fixed, meaningful target to map into, and nothing can drift during training, because the anchor cannot move.

2. Standardize before you project. Each reader's features are normalized with that reader's own statistics before the port sees them. Different models speak at wildly different scales and offsets; removing those first means the port only has to learn rotation and meaning, not bookkeeping, and it is what makes the next choice viable.

3. Keep the port linear, on purpose. A port is one plain linear map per tapped depth. No activation, no hidden layers. This is a feature, not frugality: a linear map cannot smuggle in new reasoning, so all intelligence provably stays in the reader and all decision-making stays in the engine. And a linear map can be fit in closed form, which is what makes attaching a new model cheap enough to be routine.

4. Train jointly, with an invariance loss. The engine trains on several readers at once, and every training item carries a stable id, so the same item seen through different tokenizers can be matched across readers. The loss then pulls those matched views to the same point in the shared space. The engine never learns which reader fed it, because by construction there is nothing reader-shaped left to learn from. This is the step that turns "one space per reader, awkwardly glued" into one space, full stop.

5. Save the map for whoever comes next. After training, the shared-space coordinates of a reference slice of items are stored alongside the engine. That file is the Rosetta stone: any future model reads the same items, and a closed-form regression from its features to those stored coordinates yields its port. The engine does not need to be present, let alone retrained, for a new reader to join.

Attaching a model the engine never met

Attaching a new reader costs three steps, none of which touch the engine or the reader's weights:

  1. Extract features once: hidden states at two depths, pooled per span and per option, standardized per backbone.
  2. Fit the port in closed form, a ridge regression against shared-space targets stored from training, then refine it for 300 steps against the frozen engine.
  3. Refit calibration for that reader. Calibration never transfers between readers, so this step is not optional.

The October 2026 run validated the whole path by attaching Qwen3.5 4B cold, after training the engine jointly on Qwen3.5 0.8B and Gemma 3 1B only. On the same held-out split, the cold-attached 4B scored 0.791 accuracy with a calibration error of 0.017, above the trained 0.8B at 0.765 and the trained Gemma 1B at 0.738. The engine was byte-identical in all three cases; the run asserts its checksum before packaging.

That inversion is the result worth pausing on. The best score came from the reader the engine had never trained with, because the reader was simply better at reading, and the engine's job, turning features into a typed answer with an honest probability, carried over unchanged.

Then a 27B, same engine, same story

The follow-up run attached Qwen3.8-27B the same way, cold, on a single RTX 6000 Pro. Held-out accuracy 0.811, calibration error 0.021, and the best selective risk of any reader (AURC 0.053; at 50% coverage it is 97.6% accurate). The ladder now reads 0.765, 0.791, 0.811 for the 0.8B, the 4B and the 27B, with the engine checksum identical across all of them.

vega-U benchmark table: four readers, one byte-identical engine, accuracy rising with reader size
One engine, four readers. The 27B's held-out split is capped at 400 records per source.

The per-benchmark breakdown says where the extra capacity goes. The 27B gains land exactly where reading matters: 0.941 on the 70k-token long-context set and 0.972 on its hard short counterpart (0.831 and 0.875 for the 0.8B), 0.922 on ARC, 0.919 on MNLI, 0.792 on CommonsenseQA. Saturated perception tasks (phishing, spam, intents, all around 0.99) stay flat, which is what an unchanged engine behind better eyes should look like. The one flat question type is the ordinal score, around 0.61 for every reader: that ceiling belongs to the engine or the labels, not the reader, and it is on the list.

The full vega-U benchmark board: every evaluated source across four readers, grouped by task family, best per row highlighted
The full board: every evaluated source, all four readers, best per row in orange.

What this buys you

Status

Qwen3.8-27B is attached and measured; Gemma 3 27B is being attached now, evaluated on the same held-out splits plus fresh task data the training never saw. The release follows the same rule as everything before it: engine, ports, attach tooling and the benchmark harness, all open, loadable with vegaml 0.11 where vega-U is the default model. Progress lives on the vega-U page, and the earlier families are on GitHub.


More posts·embedding.in