README.md

---
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.*

[![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)

</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>