The broken bridge
The EdgeAI Foundation put forward a video explaining Why Neuromorphic Development is Broken (And How to Fix It), featuring Gianvito Urgese. Urgese et al., in the IEEE Internet of Things Journal, argue that neuromorphic computing is still limited by hardware heterogeneity, immature toolchains, and poor reproducibility. Their remedy is NMLOps, a neuromorphic specialization of MLOps, instantiated by the inNuCE research infrastructure.
Plainly stated, I don’t agree. Neuromorphic development isn’t broken. Nevertheless, the talk opens with a broken bridge slide. Research labs on one span, industrial AIoT on the other, the deck in pieces labeled fragmented hardware, immature toolchains, the skills gap, and poor reproducibility.
The picture is vivid but it fundamentally misreads the landscape. Put your seatbelt on and I will demonstrate why. The question here is not whether a bridge must be designed from first principles. The question is whether crossings that carry real traffic are already standing.
Fragmentation is the normal condition
The paper’s description of neuromorphic hardware, distinct computational models, distinct SDKs, immature compilers, non-portable artifacts, and incomparable benchmarks describes the conventional AI-processor market just as accurately.
CUDA is proprietary to one vendor and depends on a compatibility matrix spanning architecture generation, driver, toolkit, cuDNN, cuBLAS, NCCL, and the framework build. TensorRT engines are tied to the GPU and the TensorRT version that produced them. Practitioners do not call that a broken ecosystem. They call it engineering.
AMD’s ROCm exists because CUDA is not portable by default, and HIPIFY is the evidence. Tenstorrent has already reorganized its compiler once, from TT-Buda to TT-Forge, and a developer still faces a distinct programming model. Groq is statically scheduled, and most developers reach it through a hosted API rather than by programming the chip. TPU, Trainium, Gaudi, Cerebras, SambaNova, Graphcore, Hexagon, and Ascend each ship their own compiler, runtime, quantization rules, and operator coverage.
Nobody proposed a GPU-MLOps as a precondition for CUDA, or a Dataflow-MLOps as a precondition for Cerebras. Fragmentation was absorbed by four ordinary layers: intermediate representations and compilers, framework back ends, serving runtimes, and workload managers with a shared data plane. ONNX, MLIR, OpenXLA, Triton, and TVM did not eliminate vendor stacks. They made them interchangeable at defined boundaries. vLLM joined NVIDIA, AMD, TPU, Neuron, Gaudi, and CPU by back ends and plugins, not by a new lifecycle. Machine learning operations itself grew up as a hardware-agnostic discipline above those layers.
Reproducibility is not solved elsewhere either. PyTorch documents that completely reproducible results are not guaranteed across releases, commits, or platforms. Work from Thinking Machines Lab in 2025 showed inference outputs from widely used serving engines varying with batch composition even at temperature zero, because common kernels are not batch-invariant. Bit-identical results are the exception in conventional AI inference, not the rule.
The skills gap is also not new. Engineers trained on sequential CPU code had to learn warps, thread blocks, and coalesced access once CUDA arrived. Every new processor class has one. The gap shrinks through libraries, abstractions, and practice, not through a lifecycle methodology. By the paper’s submission in October 2025, AI-assisted coding was already in widespread professional use. The cost of taking up an unfamiliar SDK had fallen sharply. The paper does not mention it.
The crossings are already standing
For neuromorphic computing specifically, the crossings are already documented with work already published and done.
Three IEEE NAECON 2026 papers cover the orchestration and decision framework [1]. A public record of 82 demos on BrainChip Akida AKD1000 and AKD1500 silicon runs inside a heterogeneous compute ontology built on IBM Spectrum Symphony, IBM Spectrum LSF, and IBM Storage Scale. BrainChip released the Symphony Community Akida Bundle as open source in August 2026.
My demo record bears on each barrier the EdgeAI video names, many of them already documented in the IEEE papers.
Toolchain immaturity: Akida as a first-class vLLM back end, hot-swapping of one hundred resident models, a one-billion-parameter state-space model across more than twenty chips, twenty thousand concurrent fly-brain connectomes on ten chips, and a reproduction of the foundational on-chip learning result.
Heterogeneity is the purpose of the ontology, not a reason to stop. Akida has been coordinated with Jetson Orin Nano, a Qualcomm QCS6490, FPGA fabrics, ReRAM, and quantum processors. In one demo, the neuromorphic processor is the sentinel deciding when a Qualcomm Hexagon NPU should wake.
Reproducibility: IBM Spectrum Symphony HostFactory brought up a fleet of 131 nodes in 37 cities across 20 countries on six continents, put the same question to every Akida instance, and tore the fleet down. Fourteen minutes and fifty seconds, about $1.40, bit-identical classification on every node.
Deployment: batch-managed and multi-tenant under LSF, with each chip reporting availability, mapped models, and tenant history; online inference behind a standard API; a single vLLM endpoint live across fifty-six nodes at three sites; learning after deployment.
Scale: a 46-node fleet under Symphony over GPFS held 8,832 concurrent inference contexts at 99.4 percent of ideal scaling.
A single-board prototype cannot reveal the problems that decide enterprise adoption: placement, multi-tenancy, shared data across sites, fleet bring-up, and cross-site serving. The paper cites “Neuromorphic computing at scale” in support of the promise, yet nothing in its own evaluation operates at scale.
Registering a node is not an ontology
Read closely, inNuCE is an instance of the general pattern, not an alternative to it. Development on Kubernetes, execution on Slurm, with GPUs, FPGAs, MCUs, and neuromorphic boards exposed through independent queues and partitions. Dataset versioning on MinIO, model versioning in Git, hyperparameter search through NNI, Kubeflow components in the talk demo, portability through the existing vendor toolchains and NIR.
The paper concedes the methodology is not neuromorphic-specific in practice. The infrastructure also supports CPU, GPU, TPU, MCU, and FPGA use cases through the same NMLOps procedures. A procedure that applies unchanged to conventional hardware is machine learning operations. The neuromorphic specialization is the vendor toolchains and encoding libraries plugged into it.
The weak point is the integration. New hardware, the paper says, could be onboarded by registering the Slurm node and its containerized SDKs. That is bolting a board onto a generic cluster. In the counted-resource model a neuromorphic processor is one unit of an opaque device type. Neither the orchestrator nor the workload manager knows the models resident on the chip, whether it is learning on-chip, its event history, its tenant history, or the kind of work it is suited to. Boards sit behind independent queues that enforce fairness and exclusive access. That is fair sharing of an opaque device, not placement by understanding.
By way of contrast, a heterogeneous compute ontology represents each class of processor for what it is. External load information can expose each Akida chip as a resource reporting availability, mapped models, and tenant history, so the workload manager places work according to the state of the processor and not merely its existence. In Symphony, Akida participates as a first-class service resource alongside quantum, GPU, and CPU. A generic node answers whether a device is free. An ontology answers which processor should do the work. Enterprise adoption depends on the second question.
Containerization is presented by the video and the paper only as a benefit: consistency, isolation, reproducibility. The costs go unacknowledged. Device drivers live in the host kernel while user-space SDK components live in the container, which adds a version-coupling problem rather than removing one. Exposing a PCIe device requires mounts, plugins, or elevated privileges. cgroup quotas can throttle latency-sensitive processes. Networking and storage layers add indirection, which matters for a processor whose value is partly sub-millisecond response. No such cost is measured. The reported 0.29 ms Akida figure is given without stating whether the measurement was inside a container or how much overhead the container layer contributed. The threats-to-validity section does not mention containerization at all.
The evidence does not support the claims
The infrastructure proposed by the paper is said to lower adoption barriers, reduce development costs, shorten time-to-market, make cross-target comparisons routine, and act as an effective catalyst. No data are presented on any of those. No development-time or porting-effort comparison, no user study, no queue throughput, no device utilization, no cost figures, no report of an experiment rerun and reproduced. The three user scenarios, an industry engineer, a student, and an embedded engineer, are illustrative personas, not participants.
The seven use cases are single-device prototypes. Human activity recognition runs on a Raspberry Pi. Positioning runs on an embedded NVIDIA GPU. Compliance with Loihi or SpiNNaker, as the talk put it, is not deployment. The Loihi Braille deployment and the Loihi 2 hippocampal-cortical network are marked in the paper’s own table as steps performed outside the infrastructure, on Intel servers and Intel vLab. Storage for two use cases sits on GitHub. No use case involves multiple neuromorphic processors working together, concurrent tenants, or sustained serving. Energy is missing for human activity recognition, Speck latency is missing, the Loihi 2 result is missing, and the FPGA case reports no numbers.
The gesture-recognition case is the only direct comparison across neuromorphic and conventional hardware on the same task. On the reported figures the desktop GPU is roughly 70 times faster than the Akida deployment, GPU energy per sample is within about 16 percent of Akida energy per inference, and the CPU is about five times faster at about five times the energy. The paper summarizes this as comparable to the CPU reference while substantially reducing average power. That is true of average power. It is not the conclusion most naturally supported by the energy-per-inference figures. The comparison also cannot be interpreted with confidence. Batch size is unstated, whether energy includes static or idle power is unstated, the instrument beyond “on-board APIs” is unstated, and whether “per inference” and “per sample” are the same unit of work is unstated. The Braille case is similar: Loihi at 40.1 to 80.9 percent accuracy against 87.78 percent on an MPU and up to 98.2 percent on a GPU, with the MPU energy computed from nominal power rather than measured, in a laboratory the paper describes as equipped with power meters.
These points are not an argument against a neuromorphic advantage because in reality there are a lot of apples being compared to oranges here. The truth is that they are an argument that single-sample, single-device prototype comparisons are a poor basis for claims about the field. Such comparisons treat the neuromorphic processor as a drop-in substitute for a GPU on a GPU-shaped task. Deployed value depends on duty cycle, always-on operation, sparsity in real input streams, and the occasions on which the processor suppresses work entirely or escalates it. The evaluation design cannot reach that question.
Operations are described in detail and not demonstrated: canary, shadow, and blue-green rollouts with automated rollback, telemetry, data-drift detection, adaptive retraining, board health, firmware and SDK lifecycle management, fleet management, remote attestation, and incident-response runbooks. The paper states that the operation and monitoring procedures are implemented. In the evaluation table, the operation row for every use case lists only metric names. No rollout, rollback, drift event, retraining trigger, fleet operation, or incident is reported. Asked in the talk about continuous monitoring and learning, the lead author said that is not a task inNuCE was designed for, that the platform supports the prototype, not the operation, and that a satisfied user should download the work and buy the board. The paper places the adoption gap between prototype and industrial deployment. By its lead author’s account, the infrastructure stops on the prototype side of the gap.
Reproducibility mechanisms are described and sound: version-pinned containers, an immutable artifact registry, logged seeds, golden-set tests, provenance. No experiment is reported as rerun, on the same device or a different one, with agreement measured. Mechanisms designed to enable reproducibility are not evidence of reproducibility. The bit-identical result across 131 nodes is the kind of evidence the claims require and do not include.
Hardware availability is also presented inconsistently. The paper lists a current pool and lists SpiNNaker 2 among hardware that could be onboarded. The talk lists SpiNNaker 2 under remote physical execution while the narration says the boards are still being procured. Loihi and Loihi 2, used in two of the seven use cases, are not in the pool and were reached through Intel services but remain commercially unavailable.
According to the video and the paper, federation is envisaged. Access models are in the future tense. The platform is described as alpha inside the authors’ institution. Each is a reasonable stage for a research platform. None is the stage at which a platform can be presented as the remedy for a field-wide problem.
What would substantiate the claims
The claims are not unfalsifiable. Seven kinds of evidence would strengthen them. A controlled comparison of development effort, with and without the infrastructure, AI-assisted coding held constant, against a baseline of production workload management, a shared parallel file system, vendor SDKs, and NIR. Cross-platform results under a stated protocol, with batch size, static power, instruments, and units of work made explicit. A measured cost of containerization against bare metal. A measured reproducibility result, the fraction of registry entries that reproduce months later. At least one deployment exercising the rollout, monitoring, drift, and retraining capabilities that are described. Evidence past a single device: multi-device execution, concurrent users, queue behavior under load and engagement with production orchestration work, stating what NMLOps adds beyond the general-purpose machinery it is built on and beyond a heterogeneous compute ontology already integrating the processor more deeply.
Absent that, the defensible claim is narrower. The inNuCE team has built a carefully engineered prototyping environment for its own laboratory and collaborators, assembled from sound general-purpose components. That is a worthwhile contribution. It is not a demonstration that neuromorphic development is broken, and it is not the remedy the field needs.
The manuscript was received in October 2025 and published in February 2026, before the demo record and the NAECON papers. It cannot be faulted for failing to cite them. However, the EdgeAI talk was delivered after both were public and a talk claiming early priority for a neuromorphic lifecycle should at least locate itself relative to work already placing the hardware into managed, multi-tenant, and multi-site operations.
Old black water
The industry did not respond to CUDA, ROCm, Tenstorrent, Groq, or the cloud AI chips by declaring each ecosystem broken and prescribing a bespoke lifecycle. It built compilers, intermediate representations, serving runtimes, workload managers, and shared data planes, and got on with deploying. Deployment today proceeds with AI-assisted coding, which has made adopting a new framework cheaper than at any point in the history of computing.
A broken bridge is the wrong picture. Bridges are already standing: workload managers that know the nature of each processor, shared data planes holding models and state across sites, serving runtimes, intermediate representations, and vendor SDKs. Freight train-level traffic is already moving across them.
The barrier to neuromorphic adoption is not the absence of a neuromorphic-specific methodology. The barrier is the continued treatment of neuromorphic hardware as a laboratory curiosity needing its own world or as a helper device for other compute. Neuromorphic silicon should be treated as a distinct class of processor standing on its own, as my demos demonstrate, with a first-class place in the heterogeneous compute ontology of the enterprise. A complete paradigm change is in order that both research institutions and commercial houses need to adopt.
Old black water keeps on rolling. The fabric runs dark, quiet, and sub-watt beneath the rest of the enterprise, waking only at the points of pressure from the world, as a peer of the GPU, the CPU, the mainframe, and the quantum processor. The field does not need to be rescued from fragmentation. The field needs to cross the bridges already standing because trains are already doing that very thing every day of the week.
[1] The three IEEE papers are published here:
Johnson, K. D.; Harbour, S. D. “Utility-Optimized Neuromorphic Orchestration for Real-Time ISR and Multi-Sensor Fusion.” 2026 IEEE National Aerospace and Electronics Conference (NAECON). doi:10.1109/NAECON70028.2026.11675010
Johnson, K. D.; Harbour, S. D. “Neuromorphic Orchestration for Efficient LLM Infrastructure via Utility-Optimized Decision-Making.” 2026 IEEE National Aerospace and Electronics Conference (NAECON). doi:10.1109/NAECON70028.2026.11675008
Harbour, S. D. Johnson, K. D. et al. “From Compute Scaling to Decision Optimization: Neuromorphic Architectures for Sustainable AI Infrastructure.” 2026 IEEE National Aerospace and Electronics Conference (NAECON). doi:10.1109/NAECON70028.2026.11674860