--- title: EXEAON AI — Organization Profile Card colorFrom: indigo colorTo: blue sdk: static pinned: true ---
# EXEAON ### *Frontier models on the hardware you already own.* [![Website](https://img.shields.io/badge/Website-zenuxplimver.tech-blue.svg?style=for-the-badge)](https://zenuxplimver.tech) [![GitHub](https://img.shields.io/badge/GitHub-ExeaonLM-181717.svg?style=for-the-badge)](https://github.com/ExeaonLM) [![License](https://img.shields.io/badge/Runtime-Apache_2.0-green.svg?style=for-the-badge)](https://opensource.org/licenses/Apache-2.0)
--- ## 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](https://huggingface.co/spaces/Exeaon/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. ```bash 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](https://github.com/ExeaonLM) - **Website** — [zenuxplimver.tech](https://zenuxplimver.tech) - **Contact** — contact@zenuxplimver.tech
EXEAON is a product of Zenux Plimver Technologies LTD, Ghana.