--- title: "Backline Is a Control Plane, Not a Quantum Computer" slug: "xanadu-amd-backline-open-quantum-classical-infrastructure" author: "Miguel Amigot" date: "2026-09-17 15:00:00" category: "Premium" topics: "quantum computing, quantum error correction, open source infrastructure, AMD, heterogeneous computing, control plane, vendor lock-in" summary: "Xanadu and AMD released Backline on September 10, 2026 under Apache 2.0. Its sub-3-microsecond figure is a 2.305 μs FPGA-to-CPU round trip over RoCE v2 — the GPU path is 4.5 μs, and the quantum side is simulated." banner: "" thumbnail: "" linkedin: | Xanadu and AMD released Backline on September 10, 2026. It is being read as "quantum computing just became open infrastructure." That is not what shipped, and what did ship is more interesting. Backline is an Apache 2.0 extension to PennyLane — a compilation and execution framework that lets you write a quantum error-correction decoder in Python and run it on a CPU, GPU, or FPGA without changing frameworks. The numbers, from the companion paper: an AMD VPK120 FPGA controller measured a 2.305 μs median round trip to a Threadripper PRO CPU and 4.5 μs to an Instinct MI210 GPU, over RoCE v2, across ~10^6 rounds per path. Read that carefully. "Sub-3 microseconds" is the CPU path. The GPU path is 4.5. And both are classical-to-classical measurements between a controller and a coprocessor — the published demos run the quantum side on PennyLane's Lightning simulator, not a QPU. So no, a photonic quantum computer did not become open infrastructure last week. Xanadu's Aurora prototype is 12 qubits, and optical loss is still the barrier to fault tolerance. What actually became open is the control plane — the layer that decides which classical engine a workload lands on. → The accelerator is proprietary; the layer that routes work to it is Apache 2.0 → A team can build against that layer now, years before the accelerator is real → When the hardware changes, the orchestration code does not → That is layer ownership, and it is the same argument enterprises should apply to AI With ibl.ai you own all the code and the data — self-hosted inside your own perimeter, model-agnostic across any LLM, usage-based with no per-seat pricing, deployable anywhere from your own cloud to a fully air-gapped network. #iblai #AgenticAI #EnterpriseAI #QuantumComputing #OpenSource #Infrastructure --- ## The Short Answer **Xanadu and AMD released Backline on September 10, 2026 as an Apache 2.0 extension to PennyLane, not a quantum computer. Its published benchmark is 2.305 μs median round-trip from an AMD VPK120 FPGA controller to a Threadripper PRO CPU — and 4.5 μs to an MI210 GPU — over RoCE v2, with the quantum side simulated. The pattern matters: with ibl.ai you own all the code and the data at the same orchestration layer.** The interesting thing about Backline is not the quantum part. It is which layer of the stack arrived open-source first. ## What is Backline, and what did Xanadu and AMD actually release? A compilation and execution framework, released as open source inside an existing open-source project. Xanadu and AMD [announced Backline on September 10, 2026](https://www.globenewswire.com/news-release/2026/09/10/3359349/0/en/xanadu-and-amd-launch-backline-to-streamline-cpu-gpu-fpga-integration-for-quantum-technology.html) as a feature suite within PennyLane, Xanadu's existing quantum programming platform. It is not a separate product, a chip, or an interconnect you buy. It is a way to write a quantum error-correction encoder or decoder in Python and compile it — through MLIR — down to whichever classical engine should run it. The licence is real open source, not open-core or open-weight. [The Backline repository](https://github.com/PennyLaneAI/backline) states Apache License, Version 2.0, the same licence PennyLane itself carries. That repository holds benchmarks, demos and a cross-build system; the implementation lives in the PennyLane and Catalyst repositories. The architecture has three pieces: a **controller** (the classical hardware driving the quantum processor and its measurements), a **coprocessor** (the CPU, GPU or FPGA doing the heavy classical work, typically decoding), and the transport between them. That is the whole idea. The quantum processor is treated as one node in a heterogeneous, low-latency network, and the framework decides where each piece of classical work lands. ## What does Backline's "sub-3-microsecond" latency actually measure? A classical round trip between a controller and a coprocessor — not a measurement taken against a quantum processor. The companion paper, [*Python in the front, party in the Backline*](https://arxiv.org/abs/2609.09270) (arXiv:2609.09270, submitted September 8, 2026), is specific about the setup: an AMD VPK120 FPGA board as the controller, issuing each round from its hardware-handshake engine. Across roughly a million rounds per path, the authors measured median steady-state round-trip latencies over RoCE v2 of **2.305 μs to an AMD Ryzen Threadripper PRO CPU** and **4.5 μs to an AMD Instinct MI210 GPU**. Two corrections follow from that sentence. **"Sub-3 microseconds" describes the CPU path only.** The GPU path is 4.5 μs — [above the threshold](https://quantumcomputingreport.com/xanadu-and-amd-launch-open-source-backline-extension-for-pennylane/), not below it. The press-release framing collapses two different numbers into one. **Neither number is a quantum-to-classical latency.** Both are classical-to-classical, FPGA to coprocessor, over a network. That is the right thing to measure for this work — decoding is the part that has to finish before the qubits decohere — but it is not "CPUs, GPUs and FPGAs connected directly to quantum hardware." Why the target is single-digit microseconds at all: real-time error correction has to detect and correct faults inside the coherence window of the physical qubits. Miss that window and the correction is arithmetic about a state that no longer exists. ## Is there a real quantum processor in Backline's loop yet? Not in the published demonstrations, and the project does not claim otherwise. [PennyLane's Backline demo](https://pennylane.ai/demos/backline) runs the quantum side on the Lightning simulator while the coprocessor performs the decoding. The paper's code examples use a null device. The QPU in the diagram is a placeholder for hardware that does not exist yet at the scale the software is being built for. The paper's conclusion says so plainly: fault-tolerant quantum computing systems remain under active development across all hardware platforms, with significant R&D still required across software, hardware, error correction and architecture. Xanadu's own hardware tells the same story. [Aurora, announced January 22, 2025](https://thequantuminsider.com/2025/01/22/xanadu-announces-aurora-a-universal-photonic-quantum-computer/), is a **12-qubit** prototype built from 35 photonic chips and about 13 km of fibre across four server racks, running at room temperature. Its significance is architectural — it shows the modular, networked path scales — and optical loss is still the barrier to fault tolerance. So Backline is infrastructure being built ahead of the machine, deliberately. That is a normal and sensible way to build a platform. It is just not a machine becoming available. ## Does Backline make quantum computing open infrastructure rather than a lab experiment? No — and the accurate version of that claim is the more useful one. Quantum hardware did not become open, available or productized on September 10. The QPUs are still scarce, still under development, and in Xanadu's case still a 12-qubit prototype with a fault-tolerance problem to solve. What became open is the **control plane**: the compilation and execution layer that sits between classical accelerators and the quantum device and decides what runs where. [AMD's named parts](https://thequantuminsider.com/2026/09/10/xanadu-amd-backline-low-latency-quantum-classical-computing/) — EPYC and Threadripper CPUs, Instinct GPUs, Versal FPGAs, Pensando networking — are all proprietary silicon. The layer that orchestrates them is Apache 2.0. That inversion is the story. The accelerator stays closed; the thing that routes work to the accelerator ships open, first, before there is much to route. ## Why does an open control plane matter before the accelerator arrives? Because the orchestration layer is what a team actually writes code against, and it outlives the hardware underneath it. A quantum error-correction decoder written against Backline today runs on a Threadripper. The same Python runs on an MI210, or a Versal FPGA, or — when one exists — a QPU, without switching frameworks. The hardware decision moves out of the application and into configuration. This is the same structural argument as the [custom silicon race in AI inference](/blog/custom-silicon-enterprise-ai-inference): the chips change every eighteen months, and the organizations with a portable orchestration layer can adopt a new one as a procurement decision rather than a migration project. It is also why [open weights keep becoming enterprise default infrastructure](/blog/open-source-ai-infrastructure-enterprise-default-2026) at the layer above. Ownership concentrates where switching costs are highest, and switching costs are highest in the plumbing, not in the accelerator. The practical test for any new class of compute is not "can I get one." It is: when I can get one, how much of what I have already written survives. ## How does ibl.ai keep the orchestration layer yours? By shipping the control plane itself, under your control, rather than access to someone else's. With ibl.ai you own all the code and the data. The platform runs on your own infrastructure with full source code — a data and integration layer, a per-user memory layer, an agent orchestration layer and model-agnostic LLM routing — so you can swap providers without rebuilding. It is usage-based with no per-seat pricing, and you can deploy anywhere: your own cloud, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. Concretely, that means running Llama, Mistral or Qwen privately on your own GPUs, or connecting Claude, GPT or Gemini through your own accounts, and switching between them without rewriting the agents on top. The routing layer absorbs the change; your applications do not see it. To be clear about scope: ibl.ai orchestrates LLMs on classical hardware. It does not run on quantum processors, and nothing here suggests it does. The transferable point is the shape of the argument — an organization that owns its orchestration layer changes accelerators without changing vendors, whether the accelerator is a GPU today or something else later. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY. *Related reading: [the custom silicon race signals enterprise AI's next phase](/blog/custom-silicon-enterprise-ai-inference) — the same portability argument one layer up · [open weights are becoming enterprise default infrastructure](/blog/open-source-ai-infrastructure-enterprise-default-2026) · [NVIDIA's PAIR is a router, not an inference cluster](/blog/nvidia-pair-personal-ai-router-local-inference-cluster) — another launch whose category was misread.* *Sources: the launch and AMD hardware list from [the September 10, 2026 press release](https://www.globenewswire.com/news-release/2026/09/10/3359349/0/en/xanadu-and-amd-launch-backline-to-streamline-cpu-gpu-fpga-integration-for-quantum-technology.html) and [The Quantum Insider](https://thequantuminsider.com/2026/09/10/xanadu-amd-backline-low-latency-quantum-classical-computing/); the 2.305 μs and 4.5 μs RoCE v2 round trips and the R&D caveat from [arXiv:2609.09270](https://arxiv.org/abs/2609.09270); the Apache 2.0 licence and repository contents from [the Backline repository](https://github.com/PennyLaneAI/backline); the simulator-based demonstration from [the PennyLane Backline demo](https://pennylane.ai/demos/backline); the per-path breakdown from [Quantum Computing Report](https://quantumcomputingreport.com/xanadu-and-amd-launch-open-source-backline-extension-for-pennylane/); Aurora's specifications from [The Quantum Insider's January 22, 2025 report](https://thequantuminsider.com/2025/01/22/xanadu-announces-aurora-a-universal-photonic-quantum-computer/).* ## Why does owning the AI stack matter? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.