22 June 2026
Continuing on from my previous blog, The neuromorphic wedge: Akida in the cloud - a concept , this article looks at the custom hardware that would be needed to make such an appliance practical.
The previous article imagined a dedicated neuromorphic rack appliance: a server-class system capable of running Linux, IBM Spectrum Symphony, IBM GPFS/Spectrum Scale and dedicated application software for managing pure neuromorphic or mixed AI workloads.
Most of that appliance is not exotic. The chassis, power supplies, cooling, host CPU, system RAM, NVMe storage, networking, baseboard management controller and operating system are all familiar enterprise-server components. These are commercial off-the-shelf parts.
The missing piece is the Akida layer
More specifically, the appliance would need a custom Akida Fabric Board: a dense accelerator board designed to hold, power, cool, address, manage and orchestrate many Akida devices as a single neuromorphic compute resource.
This article is a speculative product concept. BrainChip has not announced such a board, and IBM has not announced such an appliance. The purpose is to explore what kind of custom hardware would be needed if Kevin D. Johnson’s public Akida/Symphony/GPFS work were ever to be packaged into a repeatable enterprise neuromorphic appliance.
Overview of the neuromorphic appliance
The proposed appliance is not a replacement for a conventional server. It is a conventional server wrapped around a neuromorphic accelerator fabric.
At the hardware level, the appliance would include:
- a standard rack-mounted server chassis
- host processors
- system memory
- NVMe model cache
- high-speed networking
- Linux operating system
- IBM Spectrum Symphony or LSF-style orchestration
- IBM GPFS/Spectrum Scale-style shared model and state storage
- dedicated Akida runtime and management software
- one or more custom Akida Fabric Boards
The job of the server is to provide the ordinary enterprise infrastructure: boot, storage, networking, orchestration, monitoring, security and integration.
The job of the Akida Fabric Board is to provide the neuromorphic compute layer.
The appliance does not require every component to be invented from scratch. It requires one critical custom component that turns Akida from a collection of individual chips into a managed accelerator fabric.
Why the custom board is the minimum requirement
Kevin D. Johnson’s public work has already pointed toward Akida as a multi-model, multi-modal, multi-domain resource managed through enterprise infrastructure. His demonstrations show Akida being treated less like a single fixed-function edge chip and more like a schedulable neuromorphic compute component.
But for that idea to become an enterprise appliance, the hardware needs to become dense, repeatable and supportable.
A lab can work with individual Akida boards, cables, nodes and configurations. A customer-facing appliance needs something cleaner.
It needs a board that can present many Akida devices to the host system in a controlled way. It needs power management, cooling, telemetry, firmware control, model-staging support and software visibility. It needs to let orchestration software know what Akida resources are available, what models are loaded, what chips are healthy and what workloads can be scheduled.
That is the role of the Akida Fabric Board.
What the Akida Fabric Board would contain
A practical Akida Fabric Board would not simply be 64 chips placed on a PCB. It would be a complete accelerator subsystem.
At minimum, it would likely include:
- multiple Akida devices or Akida modules
- PCIe switch fabric connecting the Akida devices to the host server
- board management controller
- power regulation and sequencing
- thermal sensors and cooling zones
- firmware and module identification
- model staging memory or cache support
- telemetry for utilisation, temperature, power and faults
- runtime hooks for Akida management software
- cluster-level grouping so chips can be allocated individually or in groups
The host server would see the board as a pool of available Akida resources. The orchestration layer could then allocate workloads to a single Akida device, a group of devices, or eventually a larger logical fabric.
The Akida array
The core of the board would be the Akida array.
An early design might use 64 individual Akida devices or modules. These could be organised as eight clusters of eight, four clusters of sixteen, or another layout that best suits power, cooling and signal routing.
Each Akida module could be individually addressable. One might run a vision model. Another might run RF sensing. Another might run anomaly detection. Another might run temporal patterning. Another might sit idle, ready for fast model loading.
This would support module-by-module operation.
That alone would be useful. It would allow the appliance to behave as a pool of neuromorphic accelerators.
But the more ambitious possibility is fabric-level operation.
From individual modules to one Akida fabric
The board should ideally support two operating modes.
The first is simple resource pooling.
Each Akida module runs its own model or workload. This is the easiest and most immediately practical approach.
The second is logical fabric operation.
In this mode, the appliance attempts to treat multiple Akida modules as parts of one larger neuromorphic system.
That does not mean the board literally becomes one giant chip. It means the runtime, compiler and orchestration layer could partition larger workloads across many Akida devices, route events between them, coordinate state and present the result as a larger logical neuromorphic fabric.
This would require more than hardware. It would require software capable of:
- model partitioning
- inter-chip event routing
- workload placement
- timing and synchronisation
- shared model/state management
- cluster-level scheduling
- fault handling
- fabric-wide telemetry
Without that software, 64 Akida devices are merely 64 separate accelerators. With it, they become a coordinated neuromorphic fabric.
The future scaling path: from 64 Akidas to 1,024 Akida-class engines
A first-generation Akida Fabric Board could be imagined around 64 individually addressable Akida devices or Akida modules. That is the straightforward version of the concept: one dense accelerator board exposing many Akida resources to the host server.
But the more interesting scaling path would require a new Akida package or module specifically designed for dense fabric deployment.
BrainChip has already developed newer Akida IP, including Akida 2 / Akida 2500-class IP designed for more advanced process nodes such as 12 nm. If that IP were used to create a purpose-built multi-Akida module, the density of the fabric could increase dramatically.
For example, instead of each board position containing one Akida device, each position could contain a multi-Akida package: perhaps 16 Akida 2500-class neuromorphic engines in a single module or package.
In that scenario:
64 board positions x 16 Akida-class engines per position = 1,024 Akida-class neuromorphic engines
That would be a very different class of appliance.
The first-generation board might aggregate individual Akida devices. A future board could aggregate multi-Akida modules. The same server architecture, cooling concept, management layer and orchestration model could remain broadly similar, but the neuromorphic density would increase by an order of magnitude.
This is speculative. BrainChip has not announced a 16-Akida 2500 module, and it has not announced a 1,024-Akida appliance. But this is the logical reason the Akida Fabric Board concept matters. It creates a hardware architecture that could scale as BrainChip’s IP becomes denser, more power-efficient and more suitable for enterprise-class accelerator packaging.
At that point, the appliance is no longer merely a rack-mounted collection of individual edge AI chips. It becomes a true neuromorphic fabric: a dense, managed array of Akida-class engines that could be scheduled module-by-module, cluster-by-cluster, or potentially exposed as one larger logical Akida fabric.
The important point is that the 1,024-engine version would probably not be built by wiring up 1,024 separate devices one by one. It would likely require a new generation of Akida module or package designed from the start for fabric-scale deployment.
Why this matters
The Akida Fabric Board is the physical bridge between edge AI and neuromorphic infrastructure.
Without it, Akida remains primarily a chip or module deployed in individual systems.
With it, Akida becomes a server-class resource: schedulable, pooled, monitored, cooled, powered and managed like other enterprise accelerators.
That is the minimum hardware step required to support the broader Kevin D. Johnson-style vision: Akida as part of a heterogeneous compute ontology, coordinated by enterprise orchestration software and used across multiple domains, models and sensor types.
The board does not create the full vision by itself. The appliance still needs runtime software, orchestration, shared state and application logic.
But the board makes the vision physically deployable.
It turns many Akida devices into one managed neuromorphic compute substrate.
That is the first step toward an Akida neuromorphic appliance.
An enterprise-class server, not a neuromorphic science project
As described above, the neuromorphic rack server and Akida Fabric Board may sound like a dedicated appliance that only provides neuromorphic AI compute.
That would be a valid role. A rack-mounted Akida appliance could operate as a specialist neuromorphic accelerator, receiving workloads from applications that need low-power, event-driven inference, anomaly detection, sensor fusion or domain-specific recognition.
But the more important point is that this should be imagined as an enterprise-class server, not a laboratory assembly of accelerator boards.
That means it should be deployable in multiple roles.
Standalone server:
In its simplest form, the appliance could operate as a standalone neuromorphic AI server. It could host its own operating system, Akida runtime, local model cache, management layer and potentially IBM Spectrum Symphony or LSF-style orchestration. In this configuration, the appliance would receive jobs directly, schedule those jobs across its own Akida Fabric Board, run the relevant models and return results to applications.
As a component in a larger system:
In a larger enterprise environment, the same appliance could function as one schedulable resource among many. Symphony might be hosted elsewhere in the rack, cluster or data centre. From there, workloads could be routed across CPUs, GPUs, conventional AI accelerators, storage systems, mainframes, quantum simulators, FPGAs and Akida neuromorphic resources. In that role, the Akida appliance would not be an isolated box. It would be the neuromorphic execution layer inside a broader heterogeneous compute fabric.
A workload might begin on a CPU, move to a GPU for large-model processing, use Akida for sparse event-driven sensing or anomaly detection, access shared model and state data through GPFS/Spectrum Scale, then return results to an application layer. The Akida appliance would not replace the rest of the compute stack. It would add a low-power neuromorphic execution layer to it.
Full scale deployment:
The third role is scale-out deployment. Multiple Akida neuromorphic servers could be installed in the same rack, across several racks, or across multiple data-centre locations. Symphony or a similar orchestration layer could then treat the appliances as a larger neuromorphic pool: one server for a small domain, many servers for a larger domain, or a distributed Akida fabric spanning edge, private cloud and enterprise infrastructure.
That is why the enterprise-server framing matters.
The custom Akida Fabric Board makes neuromorphic compute dense and manageable inside a single machine. The appliance form factor makes it deployable, monitorable, serviceable and supportable. Symphony makes it schedulable. GPFS or another shared storage layer makes model, state and event data available across the system.
So the appliance can be understood in three roles.
- First, as a standalone neuromorphic AI server.
- Second, as a neuromorphic node inside a wider heterogeneous compute environment.
- Third, as part of a larger multi-server neuromorphic array.
This makes the concept more commercially realistic. Enterprise customers do not want isolated science projects. They want resources that can be monitored, scheduled, secured, scaled and integrated into existing infrastructure.
The Akida appliance would therefore not need to win by replacing everything else.
It could win by becoming the enterprise-class, low-power neuromorphic layer inside a much larger compute ecosystem.
From hardware fabric to neuromorphic operating system
The Akida Neuromorphic Rack Server and Akida Fabric Board concept described in this article is the hardware extension of the direction already visible in Kevin D. Johnson’s public Akida/Symphony/GPFS work. As envisaged here, such an appliance could make many valuable neuromorphic applications far more enterprise-ready: dense, rack-mounted, schedulable, monitorable, serviceable and deployable alongside existing data-centre infrastructure.
But hardware is only the first step.
A rack-scale Akida fabric could run today’s available software stack and support multi-model, multi-modal, multi-domain neuromorphic workloads. The bigger question is what happens if such an appliance also had its own neuromorphic compute operating system: a higher-order software layer designed not merely to schedule models, but to support domain-specific learning, self-organization, lifelong adaptation and sleep-like optimization.
That is the idea explored in the next article.
