Where Akida Fits: Seven Patterns for Heterogeneous Compute

By Dr. Jonathan Tapson, Chief Development Officer

Akida was designed for AI at the edge. Increasingly, it is also being built into heterogeneous compute systems, alongside CPUs, GPUs, and FPGAs.

That raises a practical question: in a system with several kinds of processors, which job should Akida take?

At BrainChip, we have been working to identify and enable Akida’s role across these applications. The framework below names seven core patterns. For each one, we give the case for, the case against, and an example.

The Seven Patterns at a Glance

Pattern Akida’s role Main constraint
Big-little Routes work for a larger system Only as good as its small decision model
Sharding Runs one large model split across chips Inter-chip traffic erases the energy advantage
Ensembling Runs many complete small models that vote Adds throughput, not model size
Watchdog Wakes the big processor when an event fires A missed event never reaches the big processor
Pipeline split Takes the stages it handles well The handoff can lose information
Maximum Akida loading Runs the whole workload Limited to workloads Akida runs at the required accuracy
On-device adaptation Learns a final layer in the field Learning is limited to the last layer

Big-Little: Akida Manages a Larger System

The pattern: A small, always-on Akida controller makes the classification and routing decisions that govern the throughput of a larger system.

Why it works

  • The controller only makes small classification or routing decisions, which fit a compact quantized model.
  • Idle power is tiny, so the controller can always be on.
  • The decision layer is independent of the vendor scheduler.

Where it strains

  • Akida can only judge what its small model can represent, so it may miss the features that make a job expensive.
  • Its input has to be encoded into something it handles well, such as events or small feature vectors.
  • If the big system is rarely idle, the savings are small.

In practice: Akida watches queue depth, request type, and sensor activity in an inference cluster, then decides which requests go to a GPU pool and which are handled cheaply. Akida acts as the neuromorphic tier of the cluster.

Sharding: One Large Task Across Many Akidas

The pattern: One large model is split across several Akida chips.

Why it works

  • It could deliver the most compute if the model can be split.
  • Idle chips draw little power.

Where it strains

  • Most large models need floating-point math, attention, or flexible activation functions, none of which map to Akida (although Akida 2 has custom activation functions).
  • Intermediate activations would cross narrow links between chips, which erases the energy advantage.
  • The model would have to be retrained and quantized to fit each shard.

In practice: A very large convolutional neural network (CNN) for 4K or 8K video, split layer by layer across several chips.

Ensembling: Small Models That Vote

The pattern: Each chip runs a complete small model, and the chips vote on the answer.

Why it works

  • Each chip runs a complete model, so there is no inter-chip traffic.
  • Chips can learn independently on-chip and vote, which improves robustness.
  • Results are easy to verify, because each chip’s answer can be compared with a host computation.

Where it strains

  • It adds throughput, not model size, so it does not help a task that needs a bigger model.
  • Ensemble gains depend on diversity, and chips trained the same way can be wrong together.
  • Voting only pays off if the added chips are cheap compared with the accuracy gain.

In practice: A football-prediction demo, in which ten chips each learn situation types and vote on run versus pass.

Watchdog: Akida Wakes the Big Processor

The pattern: Akida monitors a stream continuously and wakes a larger processor only when something happens.

Why it works

  • This is Akida’s strongest fit, because it only spends energy when something fires.
  • Always-on sensing at low power is what the chip is designed for.
  • The big processor can sleep, which gives large system-level savings.

Where it strains

  • The system depends heavily on the Akida model’s performance, because a missed event never reaches the big processor.
  • The threshold has to be tuned, and it can drift as conditions change. This could become an advantage if Akida’s on-chip learning can be used to track that drift.
  • The time taken to wake the big processor adds to the response time.

In practice: An Akida chip watches a camera or sensor stream and wakes a Jetson system only when it sees a person or an anomaly.

Pipeline Split: Each Processor Takes Its Stage

The pattern: The workload is divided into stages, and each stage runs on the processor that suits it.

Why it works

  • Akida handles the stages it is good at, such as feature extraction or classification.
  • A Jetson system or GPU takes the stages that need floating point, attention, or generation.

Where it strains

  • Two toolchains and two sets of models have to be maintained.
  • The handoff format, such as spikes or quantized features, may lose information the next stage needs.
  • End-to-end accuracy can fall below what a single processor would give.

In practice: Akida runs an efficient sensor classifier and passes a compact summary to a larger model on a Jetson system for reasoning, as in a Jetson Nano plus AKD1000 build with a large language model as the reasoning layer.

Maximum Akida Loading: The Whole Workload on Akida

The pattern: Every workload that Akida can run is moved onto Akida entirely.

Why it works

  • It offers the largest possible power saving.
  • It removes the data-center-class processor from the hot path for those workloads.

Where it strains

  • It only applies to workloads Akida can run at the required accuracy.
  • The headline saving depends on the baseline, so a fair comparison needs a power-optimized GPU.

In practice: A drone runs a detection model entirely on Akida, where it previously needed a Jetson system.

On-Device Adaptation: Learning in the Field

The pattern: A frozen front end feeds a final layer that Akida keeps learning after deployment.

Why it works

  • Akida’s on-chip learning of a final layer fits this directly.
  • A frozen front end plus an adaptive last layer lets the system handle new conditions without retraining offline.
  • It can flag novelty without labels.

Where it strains

  • Learning is limited to what the last layer can represent.
  • A model that changes after deployment is hard to benchmark.
  • Agreement between nodes is not proof of correctness.

In practice: An electronic-warfare demo, in which a frozen FPGA front end feeds an Akida that learns a new emitter in the field.

Early Conclusions

On this analysis, the seven patterns do not fit equally well.

  • Best fit: watchdog, ensembling, and on-device adaptation.
  • Workable: big-little, although it is only as good as its small decision model.
  • Narrow: sharding one large model, which is going to have narrow applications.

The Bottom Line

Akida fits best where each chip does a complete, self-contained job: watching for events, voting as one of many small models, or adapting in the field. It fits least when one large model has to be divided across chips.

If you are designing a heterogeneous system and want to explore where Akida fits, get in touch.