New statevector simulator backend plugin based on `cuQuantum`

[matulni]

This issue is part of unitaryHACK 2026. You have to be registered to participate. Please read carefully the unitaryHack rules before submitting a PR for this issue.

A note about AI Slop: while we are open to collaboration with LLMs for unitaryHACK, fully AI-generated PRs are not acceptable. It is at the maintainers' discretion whether or not LLM-generated PRs are the right fit for the issues, and those that appear fully AI-generated may be immediately rejected. Please read carefully the AI policy if you are using LLMs for your work.

Context

Quantum computations in the MBQC model are represented with patterns which are sequences of commands¹ (see graphix.pattern):

• $N(i)$: initializes qubit $i$
• $E(i, j)$: entangles qubits $i, j$ (applies a $CZ_{ij}$ gate).
• $M(i)$: measures qubit $i$.
• $X(i, j), Z(i, j)$: applies a $X$ or $Z$ Pauli correction on qubit $i$ depending on the (classical) outcome of measuring qubit $j$.

Simulating patterns is of fundamental importance, and Graphix is equipped with a built-in pattern simulator. The simulator processes commands, computes outcome probabilities and handles the feed-forward logic (i.e., the fact that $X$ and $Z$ commands are conditional on past measurement results). The simulator backend is responsible of applying the actual quantum operations (entanglement, Pauli operations, measurement, etc.) on a certain representation of the quantum state (a statevector or a density matrix).

Graphix' backends are similar to the usual quantum circuit simulators with one crucial difference: the size of the register varies throughout the execution of the program, since $N$ and $M$ commands (for adding and measuring qubits, respectively) can appear at any point in the pattern. For the statevector backend, this logic is implemented in :meth: graphix.sim.statevec.add_nodes and :meth: graphix.sim.statevec.remove_qubit.

The separation between the pattern processing and the quantum-state simulation allows users to "plug and play" custom backends with improved efficiency. The goal of this issue is to develop a GPU backend based on NVIDIA's cuQuantum SDK.

Task

Implement a statevector backend plugin built on top of cuQuantum Python (the Python wrapper for cuStateVec).

To facilitate the task, we have prepared a template for statevector backends. See the README for detailed instructions. You should fork and submit your PRs to that repository.

The template is a guideline for the methods required in a minimal working statevector backend. You may need to add new functions and attributes to the Statevec class.

Acceptance criteria

For the PR to be considered for review:

• It should pass the CI in the template².

• New functions should be documented appropriately following numpy style.

• Unitary Hack AI use guidelines should be respected.

• Benchmarks results (see benchmarks/ in the template) should be presented in the PR text.

• Author should be ready to engage in a feedback loop.

For the PR to be accepted:

• All provided feedback should have been implemented.

Footnotes

1. Danos, Kashefi and Panangaden, 2007 (arXiv:0704.1263). ↩

2. The Graphix team does not have a self-hosted runner with GPU, therefore the CI will not be able to test the validity of your functions. To avoid any crashes you may include a @pytest.mark.skip(reason="GPU not available") decorator (or programatically detect if there's an available GPU). The CI will still ensure that your submission is properly formatted and type-checked, and test the imports. Tests will be run offline by the project maintainers. ↩