The problem we work on
At batch one, a language model reads every weight from memory to produce a single token, and uses each weight exactly once. Arithmetic intensity is about 0.5 FLOP per byte, so generation speed is:
tokens/second ≤ memory bandwidth ÷ model bytes
The accelerator's FLOP rating never enters that equation. A 7B model in bf16 is 14 GB — on 1 TB/s that is a hard ceiling near 71 tokens per second, whatever the spec sheet claims. The only lever on single-stream speed is how many bytes the model is.
So we move fewer bytes. ℰ-PURE compresses the weights, and they stay compressed in memory — packed indices go straight into the matmul, where the kernel decodes them in the operand path. The dense weight is never assembled. That is the difference between a smaller download and a smaller process.
See it for yourself: The Memory Wall — pick your hardware, pick a model size, watch the ceiling move.
The families
| class | say it | meaning | runs on | sizes |
|---|---|---|---|---|
| Dzo | jo | fire (Ewe) | laptop, CPU, edge | ≤ 4B |
| Nunya | NOO-nya | knowledge (Ewe) | a single GPU | 7B – 32B |
| Kese | KEH-seh | great (Twi) | server, multi-GPU, MoE | 70B+ |
Fire, knowledge, greatness — named in Ewe and Twi, from Ghana, where we build.
Every model is published compressed by default. The uncompressed reference
carries the -BF16 suffix, not the other way round: running on less hardware is
the product, not a variant of it.
What is free, and what is not
| Free and open (Apache-2.0) | the epure-runtime library, CLI and SDK · the .ebin format specification · every published model weight |
| Ours | the ℰ-PURE encoder — the compressor that produces them |
You can run, fine-tune, serve, benchmark and deploy anything we publish without asking us and without paying us. What we keep is the compressor itself.
pip install epure-runtime
epure run Exeaon/Exeaon-Dzo-1.7B --prompt "Explain the memory wall."
Fine-tuning without decompressing
Compressed models here are not frozen artifacts. The quantization indices stay fixed while the codebook and per-group scales train — roughly 1% of the weight values — so adaptation happens in the compressed state, never by rebuilding the dense weight in memory.
Gradients through the packed representation are exact, verified against a dense reference to within 2×10⁻⁶.
Attribution
Several Exeaon models are derived from openly licensed base models (Apache-2.0
or MIT). Each model card names its base model, links the original, and ships the
upstream LICENSE and NOTICE files unmodified, as those licences require.
Compression, calibration, packaging and the runtime are ours. The pretrained knowledge is not, and we say so on every card.
Connect
- Runtime and SDK — github.com/ExeaonLM
- Website — zenuxplimver.tech
- Contact — contact@zenuxplimver.tech