At Qoro Quantum, we spend a lot of time thinking about a problem that sits slightly below the usual “algorithms vs hardware” discussion in quantum computing: execution. Before a quantum program ever runs on hardware, it is simulated, validated, benchmarked, and iterated on. As quantum workflows grow more complex, this simulation layer has quietly become one of the biggest bottlenecks.
Today’s ecosystem offers a rich set of quantum simulators: statevector engines, tensor network methods, MPS-based simulators, stabilizer backends, GPU-accelerated libraries, and distributed approaches. Each has different performance characteristics, APIs, configuration knobs, and failure modes. Choosing the right one for a given circuit is often a manual, expert-driven process. At scale—especially in HPC and cloud environments—that approach simply does not work.
Maestro is our answer to this problem.
What Maestro is
Maestro is an intelligent execution engine for quantum circuit simulation. It provides a unified C++ interface that integrates multiple simulation paradigms under a single abstraction, automatically selecting and optimizing the best backend for a given circuit and hardware environment.
At a high level, Maestro takes in a quantum circuit (currently via Qiskit or OpenQASM), analyzes its structure, and routes it to the simulator that is expected to execute it fastest while meeting fidelity constraints. Under the hood, it supports:
- Statevector simulation (CPU and GPU)
- Matrix Product State simulation (CPU and GPU)
- Tensor-network-based approaches (CPU and GPU)
- Stabilizer simulation for Clifford circuits (CPU)
- p-block simulation for distributed and memory-constrained workloads (CPU)
Rather than forcing users to pick a simulator up front, Maestro treats simulation as an execution problem: given this circuit, on this machine, with these constraints, what is the best way to run it?
Why this matters
Simulation is not just a development tool—it is the backbone of quantum algorithm design, verification, benchmarking, and hybrid quantum–classical workflows. In practice, users submit highly heterogeneous workloads: some circuits are shallow and structured, others are wide and entangled, many are batched together, and some are intended to model distributed quantum computing architectures.
A fixed simulation strategy is inefficient in these settings. Maestro’s design addresses this in three key ways:
- Unified abstraction: users write circuits in one framework and do not need to rewrite or retune them for each simulator, Maestro handles the native translation.
- Automated backend selection: Maestro predicts runtime based on circuit features such as qubit count, gate structure, entanglement growth, and measurement patterns.
- Execution-aware optimization: multiprocessing, multithreading, optimized sampling, and GPU execution are applied where they actually help, not blindly.
In our benchmarks, this approach consistently improves throughput—especially for large batched workloads typical of HPC environments—often outperforming single-simulator pipelines by large margins
Maestro in HPC and distributed settings
One of the core motivations behind Maestro is deployment in real production HPC environments, not just as a standalone research tool. From the beginning, Maestro was designed to operate inside existing quantum–HPC software stacks and scheduler-driven workflows, rather than requiring bespoke execution paths.
To that end, Maestro has already been integrated and validated across multiple HPC platforms. It is available within CESGA’s CUNQA environment and has been deployed at the Leibniz Supercomputing Centre (LRZ) via the Munich Quantum Software Stack and its QDMI interface. In both cases, Maestro appears as a simulation backend: users submit circuits through the platform’s existing interfaces, and Maestro handles backend selection, parallel execution, and optimization transparently.
These integrations demonstrate that Maestro works reliably in production settings and can coexist with established HPC tooling, device abstractions, and access models. However, they also highlight a practical limitation: access to Maestro was, until recently, tied to these larger platform stacks. If you were not running inside CUNQA, MQSS/QDMI, or a similar environment, there was no simple, generic way to expose Maestro as a simulator within a standard SLURM-based cluster.
This gap is what motivated our next step: providing a lightweight, scheduler-native integration path. By introducing a SLURM SPANK plugin, Maestro can now be made available directly inside SLURM jobs, without requiring a full quantum software stack or custom platform integration. This brings Maestro’s execution model—automatic backend selection, optimized parallelism, and hardware-aware behavior—into any HPC environment that already relies on SLURM, dramatically lowering the barrier to adoption.
In this way, Maestro moves from being “available inside specific stacks” to being a generally accessible simulation engine for HPC users, administrators, and platform builders alike.
What’s new: SLURM SPANK and Python bindings
Since publishing the Maestro paper, we’ve focused on making it easier to deploy and use in real workflows.
First, we’ve developed a SLURM SPANK plugin for Maestro: maestro-spank-plugin. This allows Maestro to integrate directly with SLURM-managed HPC clusters, enabling execution-aware simulation inside scheduled jobs without requiring users or operators to modify their existing scheduler configurations. In practice, this means Maestro can make intelligent backend and resource decisions while respecting the constraints of the job scheduler—a critical requirement for shared, multi-tenant environments.
Second, we’ve built a Python interface using nanobind and packaged it for Python installation: qoro-maestro. While Maestro is implemented in C++ for performance and portability, many users want to access it from Python-based workflows. The Python bindings expose Maestro’s core functionality while preserving the underlying execution model, making it straightforward to integrate Maestro into research code, benchmarking pipelines, and hybrid workflows without sacrificing performance.
Together, these additions make Maestro usable across the full spectrum: from low-level C++ integration in HPC environments to high-level Python-driven experimentation.
Cloud Access to Maestro
While Maestro was initially designed for HPC and on-premise environments, many users do not want to manage clusters, schedulers, or simulator deployments at all. To address this, Maestro is also available through Qoro’s Divi software as a fully managed cloud service.
Through Divi, users can access the full Maestro deployment running in a distributed cloud environment with no local configuration. Circuits submitted via the Divi API or Python interface are automatically routed to Maestro, where backend selection, parallel execution, and resource optimization are handled transparently. From the user’s perspective, simulation behaves as a simple execution call, while under the hood Maestro may be coordinating CPU, GPU, and distributed resources across multiple nodes.
This model is particularly useful for teams that want production-grade simulation capabilities without operating their own HPC infrastructure. It also enables hybrid workflows where simulation, classical post-processing, and quantum hardware execution are combined seamlessly within the same pipeline.
By exposing Maestro through Divi, we bridge the gap between advanced HPC-style execution and cloud-native usability. Users get the same intelligent execution behavior described in the paper, but delivered as an accessible service that scales automatically with workload complexity
Open source, with a clear path forward
The core Maestro framework is open source and available on GitHub. Our goal is to make high-performance, multi-backend quantum simulation accessible without forcing users to become simulator experts. At the same time, Maestro is designed as a foundation: predictive execution, runtime modeling, and resource-aware scheduling are all pieces that extend naturally into broader quantum–classical infrastructure.
As quantum computing moves toward tighter integration with HPC and cloud systems, execution layers like Maestro will matter more, not less. Simulation is no longer just about correctness—it’s about efficiency, scalability, and orchestration. Maestro is our contribution toward that next layer of the quantum software stack.
If you’re interested in trying Maestro, integrating it into your environment, or contributing, we’d love to hear from you.
Read our technical paper here: https://arxiv.org/abs/2512.04216
See examples of Maestro in action:
