| --- |
| title: EXEAON AI — Organization Profile Card |
| colorFrom: indigo |
| colorTo: blue |
| sdk: static |
| pinned: true |
| --- |
| |
| <div align="center"> |
|
|
| # EXEAON |
|
|
| ### *Frontier models on the hardware you already own.* |
|
|
| [](https://zenuxplimver.tech) |
| [](https://github.com/ExeaonLM) |
| [](https://opensource.org/licenses/Apache-2.0) |
|
|
| </div> |
|
|
| --- |
|
|
| ## 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 |
|
|
| <div align="center"> |
| <sub>EXEAON is a product of <b>Zenux Plimver Technologies LTD</b>, Ghana.</sub> |
| </div> |
|
|
