Network-Aware Quantum Compiler (aka QNDK)

Meaningful quantum work will require tens of thousands of qubits, yet the current state-of-the-art chips have on the order of 100 qubits. Continuing to vertically scale quantum chips will take time and requires more research. So in the mean-time, let’s use the evolution of classical computing as an example and connect the smaller QPUs (quantum processing units) together into a distributed computing network.

Imagine you want to make a stir fry for your dinner party, but you only have small cutting boards and frying pans. You need to divide up the preparation and cooking across multiple surfaces, but you must account for the fact that certain ingredients need to be prepared together while others can be merged later. How do you effectively distribute your workload across your limited resources?

Cisco's Network-Aware Quantum Compiler (codename: QNDK) is a Python based Software Development Kit to help you simulate running quantum algorithms in a distributed context. It provides you with the tools to easily define and customize various datacenter networks, and run analysis on how your circuit performs when split across the defined QPUs.

This is not a replacement for a single QPU compiler, but is rather a networked multi-QPU compiler to facilitate exploring how the shared network resources impact the execution of your quantum algorithm.

At the moment, this SDK only supports running local simulations and does not facilitate executing these circuits in a real physical quantum datacenter.

What research does it facilitate?

QNDK is targeted for Quantum researchers who are studying how quantum programs (eg. Qiskit circuits) execute over multi‑QPU, networked quantum datacenter topologies.

• Exploration of partitioning algorithms (e.g., Kernighan–Lin, METIS, Cisco's Optimized Window Based Partitioning) to minimize entanglement (EPR) cost throughout circuit execution.
• Evaluation of topology and network design choices.
• Simulation of resource-aware execution timelines (local vs. non-local gate execution, BSM resource usage, communication contention).
• Analysis of scheduling and partitioning trade‑offs via structured metrics (latency distributions, EPR costs, switch utilization).
• Extension experiments: custom partitioners, new network characteristic models, remapping (rack placement ILP), or alternative schedulers.