An exported checkpoint is a promise that the model still answers the same way outside the Python stack it was trained in. The open decision ecosystem has settled on three export targets — GGUF, ONNX, and device runtimes like CoreML and MLX — and each one trades something different for portability.
GGUF and llama.cpp
Jev-Style v3 is the best-documented case. Its Q4_K_M file is 0.53 GB, and the card reports it decision-identical to PyTorch FP32 on 240 of 240 parity rows plus 6 of 6 long prompts. The catch is that decisions do not come from llama.cpp's own server: the project builds a one-time jev-score binary against a pinned llama.cpp commit, and plain chat completion will not produce typed answers.
Drex follows the same route at 8B with a Q8_0 GGUF and its own llama.cpp and Ollama forks, plus a platform quirk worth knowing: on Apple Silicon the Metal tensor path has to stay disabled for long inputs.
ONNX and WebGPU
Julia 1's ONNX export puts a 551 MB decision model in the browser. The package is an ONNX graph, a Rust WebAssembly tokenizer, and a JavaScript API; after a 5.84-second load and warmup, 100 decisions ran in a median 7.55 seconds on the WebGPU path — about 75 ms each — with all 100 predictions matching the original Julia 1 and a maximum logit difference of 0.00225.
That is an output-parity test, not a rerun of the accuracy suite, and the card says so. Near-tied logits can still flip under floating-point rounding, so verify exports against the artifact you actually ship.
Apple and device runtimes
The catalog's Apple-side projects take the same idea further down: Laya-MLX and Laya-CoreML put the 421M encoder on Apple silicon, and PocketJev reads A/B/C logits on an iPhone for 2 to 26 choices. OpenDecider Nano ships an ONNX build that runs in a browser tab at 47 ms per question, and its card also links a native MLX-adjacent path for Macs. On the smallest end, Archai Zagreus is a 465 MB Q8_0 GGUF aimed at sub-10 ms CPU inference.
| Target | Artifact | Parity evidence | Watch for |
|---|---|---|---|
| GGUF | 0.53 GB Q4_K_M | 240/240 rows vs FP32 | custom scorer binary, pinned commit |
| ONNX / WebGPU | 551 MB graph + WASM tokenizer | 100/100 predictions, ≤0.00225 logit diff | WebGPU availability, near-ties |
| MLX / CoreML | platform-specific weights | project-local checks | separate runtime, model reloads |
What survives an export
Three things travel reliably: the interface, the answer space, and the option-order invariance of architectures that read options in parallel, like bev-decider, whose card measured 960 shuffles with no probability moving more than 1e-5.
Three things need re-verification. Full softmax probabilities survive rounding only within near-ties; bf16 serving in vLLM changed JEV-9B's decisions in the third decimal depending on batching; and runtime configuration, like strict encoding or context limits, can reject an input the original stack would have truncated.
What changes in operations
An export usually removes a server. The browser build has no endpoint, no key, and no per-call billing; the GGUF runs wherever llama.cpp runs. What it adds is statefulness — keep the model loaded between requests, budget memory for the full weight file, and treat the pinned runtime commit as part of the artifact. For which model to export in the first place, see choosing an open decision model.
