ECAPs (Edge Computing Agentic Processors) brings AI compute to homes, schools, labs and communities across Africa. It works alongside central AI infrastructure, and carries its value to the last mile.
Central compute is the base of Africa's AI future, but AI-ready compute is still scarce. Inclusive AI needs more of it, in more places.
AI-ready compute is scarce, so many institutions, schools, labs and communities cannot access AI, especially where power is unstable and connections are weak.
Africa has 18% of the world's people but little AI-ready compute. Central infrastructure is the foundation, and it takes time to build. Meanwhile institutions, schools, labs and communities are left waiting, or pay again and again to rent compute from far away. ECAPs adds AI compute close to people, alongside central infrastructure.
of the world's people live in Africa
A large part of the world's AI future is here.
of the world's data-centre capacity is in Africa
The compute that runs AI sits mostly elsewhere.
of Africa's data centres are AI-ready
Few facilities can run AI work today.
Africa's share of the world's compute is far smaller than its share of the world's people.
World Bank, Africa Economic Update, October 2026.
ECAPs proposes a complementary layer to Africa's central compute investment: accessible edge compute that extends AI's reach into homes, institutions, communities and technical systems that central infrastructure will take time to serve. We do not treat decentralisation as the goal. It is the mechanism by which central investment turns into everyday, widespread use. Every node is a new endpoint, a new source of demand and a broader market for the compute and chip providers building Africa's core infrastructure.
ECAPs is a two-tier edge compute system, shown here as three sizes of one design. The sizes differ in compute, memory and power. They share one architecture and one software stack. All sizes below are proposed designs.
Nodes are networked to serve more users. They are not designed to split one model across machines.
Agentic means a node runs local AI agents that sense, decide and act without waiting for the cloud. An agent reads a sensor, a small local model decides what to do, and the node acts, for example switching a pump on or logging an alert. ECAPs supports this with four things: an always-on, low-power design; input and output for sensors and machines; a small local memory of recent events; and a managed runtime that picks a model that fits the node.
Nodes are designed with DC input and low idle draw so they can run from a dedicated solar system or another renewable source. A power-aware mode (eco, normal, boost) lets the software adjust to the energy available.
| Pattern | How it works |
|---|---|
| Local first | The small local model answers by default. |
| Escalate when needed | If a task is too heavy, the node passes it to a larger cloud model when connected. |
| Local data, cloud reasoning | Raw data stays on the node. Only what is needed goes up. |
| Update when online | The node pulls new models and software when there is a connection. |
This follows the edge and cloud collaboration patterns described in the research literature (see the sources).
On small devices, how fast an AI model writes text is set by memory bandwidth, the number of bytes per second the chip can read from memory, not by TOPS, the peak maths figure. To write each new word (token), the chip reads the model's whole set of weights from memory once. The maths per token is small, so the chip mostly waits for data.
Rule of thumb: tokens per second is at most memory bandwidth divided by model size in bytes.
memory bandwidthmodel sizeceiling on text speed
Worked example: an 8-billion-parameter model on a board with about 100 GB/s of memory bandwidth.
| Precision | Bytes per weight | Model size | Speed ceiling |
|---|---|---|---|
| 16-bit | 2 | about 16 GB | about 6 tokens per second |
| 8-bit | 1 | about 8 GB | about 12 tokens per second |
| 4-bit | 0.5 | about 4 GB | about 25 tokens per second |
The example is a back-of-envelope ceiling from the rule above. Real speeds are lower.
The llama.cpp project keeps a public benchmark thread that runs one model (Llama 2 7B, 4-bit), with the same software and the same test (generating 128 tokens), on many Apple M-series chips and lists each chip's memory bandwidth beside its speed. These are other people's measurements on other hardware, not ECAPs results. They show the pattern the design relies on.
At 400 GB/s
+33% compute cores, about +12% speed
At 800 GB/s
+33% compute cores, about +12% speed
Same model (Llama 2 7B, 4-bit), same software (llama.cpp), measured by others across Apple M-series chips. Not ECAPs results. Source: llama.cpp discussion #4167, Performance of llama.cpp on Apple Silicon M-series.
More bandwidth gives faster text. A third more compute cores at the same bandwidth gives about 12% more speed. Speed does not grow in step with bandwidth, because other limits start to matter at the top, so the formula above is a ceiling.
These are the proposed targets for each node size. They come from the rules below. They are design targets for the architecture we are proposing.
| Spec | Node Mini | Node | Node Hub |
|---|---|---|---|
| Models (4-bit) | 1 to 3 billion parameters | about 7 billion | 13 to 30 billion |
| Memory | 2 to 4 GB | about 8 GB | about 32 GB |
| Memory bandwidth class | about 25 to 50 GB/s | about 100 GB/s | 200 GB/s or more |
| Power | 3 to 5 W | 10 to 25 W | 40 to 60 W |
| Speed ceiling | about 17 tokens/s for a 3B model | about 28 tokens/s for a 7B model | about 13 tokens/s for a 30B model |
Assumptions: a node drawing 20 W all day, one day of battery autonomy, 80% of the battery usable, 5 peak sun hours a day and 70% system efficiency.
Sunshine varies by place and season. Old national records put the Abuja area at roughly 4.85 kWh per square metre per day, so 5 is a reasonable planning figure there. Size every real site from its own data.
ECAPs began in robotics and engineering. In this setting the same unit works as a plug-and-play compute module, giving robots and embedded systems on-device intelligence and agentic decision-making without building custom compute hardware into every system. This lowers the barrier for student projects, research labs and small engineering teams across Africa, who can build AI-capable robotics and automation on a shared, standard compute layer instead of custom silicon for each project.
Tech justice asks who builds technology, who owns it and who controls it. ECAPs puts compute closer to local hands, so everyone has a chance to use and build with AI.
Infrastructure that communities can build on, own and operate.
The ECAPs Node Runtime is the open reference software for every node size. It is a prototype in the research and development stage. It runs on an ordinary computer so that anyone can try and check it. Results shown on this page come from a stand-in reference machine, not from ECAPs hardware.
| Part | What it does |
|---|---|
| Backend interface | Runs models through llama.cpp, an open-source inference engine (MIT licence). |
| Model manager | Given a memory budget, picks the largest model that fits and explains why. |
| Agent runtime | Sense, plan, act. A model chooses a validated action, the runtime executes it, and a small local memory keeps recent events. |
| Power-aware modes | Eco, normal and boost modes adjust to the energy available. |
| Device interface | A simulated sensor feed, an ESP32 serial adapter and an MQTT adapter. |
| Offline queue | Events and actions are queued on the node and synced when a cloud endpoint is reachable. Cloud sync is off by default. |
| Node discovery and routing | Nodes on a local network find each other and a busy node can hand a request to a less busy one. |
| Management API | Read-only status, models and metrics for a manager. |
Four benchmarks are defined and run with one command: B1 overhead compared with raw llama.cpp; B2 model choice at 2, 4 and 7 GB memory budgets; B3 an offline agent loop of about 20 tasks with and without a network; B4 eco, normal and boost power modes. Raw results and figures will be published on this page when the runs are complete. Each figure states the machine it was measured on.
Results will be published here when the runs are complete. Raw data (not yet available)
| Model | Licence |
|---|---|
| Qwen2.5-1.5B-Instruct | Apache 2.0 (checked on the model card, 17 Oct 2026) |
| Phi-3.5-mini-instruct (3.8B) | MIT (checked on the model card, 17 Oct 2026) |
| Qwen2.5-7B-Instruct | Apache 2.0 (checked on the model card, 17 Oct 2026) |
| llama.cpp | MIT (project page) |
Done: the abstract was accepted at BUILD26.
In progress: node sizes, specifications and the layers of the shared stack.
Built; real benchmark results to follow.
Next: simulate and prototype the architecture.
Next.
Open: we are looking for chip and infrastructure partners.
ECAPs depends on collaboration with chip and compute infrastructure providers, not as competitors to central infrastructure but as partners extending its value into last-mile access, new markets and new demand.
Let's talk.
benedictisaac258@gmail.com or +234 904 837 7499.
| Source | Used for |
|---|---|
| World Bank, Africa Economic Update, October 2026 | 18%, 0.6% and 5% figures |
| Collaborative Inference and Learning between Edge SLMs and Cloud LLMs: A Survey (arXiv 2507.16731, 2025) | Edge and cloud collaboration patterns |
| Edge Computing: Vision and Challenges (IEEE Internet of Things Journal, 2016) | Definition and reasons for edge computing |
| On-Device Language Models: A Comprehensive Review (arXiv 2409.00088) | Model compression and on-device inference |
| Prefill vs Decode: LLM Inference Phases Explained (Redis); Why LLM Decoding Is Memory-Bound (DEV Community) | Why text generation is memory-bound |
| Community Networks and Sustainability: a Survey (arXiv 1707.06898) | Lessons for shared infrastructure |
| Research ICT Africa, Beyond fairness: why justice should guide Africa's AI future (2 July 2026) | Tech Justice framing |
| The Conversation, How a rural community built South Africa's first ISP owned and run by a cooperative (Zenzeleni) | Community-run network example |
| llama.cpp (github.com/ggml-org/llama.cpp) | Inference engine, MIT licence |
| llama.cpp discussion #4167, Performance of llama.cpp on Apple Silicon M-series (Llama 2 7B, 4-bit) | Measured bandwidth and speed in section 6 and on the poster |
No. It is a complementary layer. Nodes run models locally and call larger cloud models when they need to.
No for local work. The node runs the model, the agent loop and local users offline. A connection is used for heavy tasks, updates and remote monitoring.
A Raspberry Pi is a good general board. An ECAPs Node is meant to be a complete, managed edge-AI package: reference hardware, preloaded local models, firmware and software to host and manage it, and a solar-ready power design.
We are researching and choosing a compute architecture, and plan to partner with an existing provider to produce it.
ECAPs manages it. It does not own it. Users pay per use.
Anyone: homes, institutions and builders. We expect institutions to use it first.
Yes, that is the plan. Local-language models can run on the same node, including optional support for N-ATLAS.
Research and development. The design is proposed and the reference software is a prototype.
ECAPs is researched and developed by Benedict Isaac, Researcher, ECAPs. The work began in robotics and engineering systems and grew into the question of how to extend AI infrastructure to the last mile.
