The Ananse Reports: Introduction

Why the series exists

Part of my ongoing doctoral research at George Washington focuses on the deployment of AI and Machine Learning systems in resource-constrained environments. That work, together with ongoing discussions with my advisor, led me beyond the theoretical questions and toward investigating how these systems behave on real hardware. I wanted to understand what actually makes it hard to run these models on edge hardware, so I started by measuring what current edge hardware can actually do. The first lesson was simple: spec sheets do not tell the whole story.

A chip's advertised operations-per-second is a peak figure from ideal conditions. However, this is not necessarily a reliable guide to performance on a real workload. There is no single best device, either. A dedicated AI accelerator can beat a GPU on one model and lose to it on the next. Furthermore, the field is crowded. A recent survey counts more than a hundred companies making inference chips and dozens of competing software frameworks. These findings point to this practical problem. There is no standard and complete way to benchmark these systems. I believe that problem matters beyond my dissertation. Engineers choosing hardware face the same fragmented evidence and could benefit from measurements they can inspect and compare.

What the reports measure

Because of this, I have decided to turn the work into a series of experiments and publish them as The Ananse Reports. Each report runs real models on constrained hardware, measures the cost with a repeatable method, and uses the result to inform deployment choices. The series starts at the floor of the hardware range: tiny models on microcontrollers. From there it moves to small language and vision models on single-board computers, dedicated edge accelerators, and an Apple-silicon machine, with a cloud GPU as the reference point. Whenever the hardware is on my bench, energy comes from physical power meters rather than software estimates. Every result states exactly what was measured and where the measurement boundary was. Later reports will test whether a learned controller can manage that compute budget at runtime. The final target is robotics, where on-device intelligence has to run on hardware that moves, draws from a limited power budget, and has real consequences when it fails.

Method as deliverable

Every report includes the method: the hardware, the software and firmware versions. Additionally, it includes how I took the measurement, what counted as success, and the conditions the experiment ran under. That context is often missing from benchmark write-ups, but it is necessary if the result is going to be useful. In this series, the method is part of the work. Lastly, I'll publish these reports when they are finished and the numbers are verified. There is no fixed publishing calendar.

If you build systems that have to work on real hardware, not only in a simulator or on a leaderboard, follow along at agoo-ai.com/blog/ananse-reports. The first experiment starts with the floor: what tiny models actually cost on microcontrollers.