RASP-QAOA

Choosing a backend name is not choosing an execution. A complete choice also fixes the representation, the adapter, the precision mode, and the memory policy. RASP-QAOA treats that whole tuple as the decision object, filters out actions that cannot implement the request before ranking anything, and only then orders what is left.

Reference implementation and reproducibility package for RASP-QAOA: Resource-Aware Per-Instance Selection for Exact QAOA Simulation.

Author — Chih-Chung Hsu <chihchung@nycu.edu.tw> Institute of Smart Industry and Green Energy, National Yang Ming Chiao Tung University, Hsinchu, Taiwan

The finding, stated plainly

On a content-disjoint 60-request H200 evaluation, at least one admissible action completes and validates for 31 requests. RASP-QAOA covers all 31, against 19 for development-selected CUAOA and 23 for static priority.

And the part worth arguing about:

The gains come from representation features, not from classifier complexity. A depth-1 stump matches gradient boosting.

If you take one thing from this repository, take that. The expensive part of per-instance selection was not the model.

The ten actions

The decision object. Each row is a complete executable key, not a backend name — note that three different peer full-state GPU entries differ only in precision and memory policy, and that difference decides admissibility.

action key	representation	adapter	what makes it admissible
full_hbm	full-state, cost precomputed	map_qaoa_torch	complex128; retained cost vector; calibrated HBM envelope
full_recompute	full-state, cost recomputed	map_qaoa_torch	complex128; regenerated cost vector; calibrated HBM envelope
local_lightcone	exact local light cone	numpy_local	complex128; supported local objective; bounded cone
fixed_weight_subspace	fixed-Hamming-weight subspace	numpy_subspace	complex128; preserving mixer; subspace fits budget
fixed_weight_full_embedded	fixed-weight full embedding	numpy_full_embedding	complex128; preserving mixer; full basis fits budget
cuaoa_gpu	peer full-state GPU	pycuaoa	complex128; 768 MiB + 36 B/amplitude
qokit_gpu	peer full-state GPU	qokit_nbcuda	complex128 state, float32 diagonal; 768 MiB + 40 B/amplitude
cudaq_observe	peer full-state GPU	cudaq_cusvsim	default fp32, relaxed 1e-3 validation only; 768 MiB + 20 B/amplitude
qiskit_aer_gpu	peer full-state GPU	qiskit_aer_gpu_statevector	complex128; 768 MiB + 24 B/amplitude
qtensor_gpu	peer tensor network	qtensor	unweighted MaxCut only; relaxed 1e-3; empirical contraction boundary

Machine-readable in config/action_keys.json.

The four admission checks

Everything is decided from pre-execution information only:

1. Semantic — does the action implement the requested objective, mixer, and constraint semantics? A preserving mixer opens the fixed-weight routes; the same graph with a standard X mixer closes them.
2. Precision — checked against the configured action, not the backend family. cudaq_observe at fp32 is a different action from a complex128 one.
3. Deployment — is the specific package and device path actually present?
4. Resource — calibrated peak-memory estimate against min(B, 0.9 * H_VRAM), using a process base plus action-specific bytes per amplitude.

Only what survives all four gets ranked. Actions in the learned support are ordered by the ranker; compatible actions outside that support are ordered by analytical work proxies. The two are never compared on a shared scale — the supported branch has strict priority.

The work proxies

For actions outside learned support, ordering uses closed-form estimates:

representation	work proxy
fixed-weight	p * C(n, k)
local light cone	m * 2^min(24, 2 + d*p)
tensor contraction	(1/4) * p * 2^min(n, 28)
full-state	terms scaling with p * 2^n, plus resident or recomputed cost

These give an ordering, not a completion guarantee. They are the part of this work most directly reusable elsewhere.

Reproduce

No GPU and no simulator required — the package replays the measured campaign.

python code/reconstruct_results.py

Ends with "status": "PASS" and writes to reproduced/. Verified against expected_outputs.json:

quantity	expected
oracle-solvable requests	31
RASP-QAOA successes	31
top-1 / top-2	27 / 31
geometric-mean regret	1.051
PAR10 ratio vs development-selected CUAOA	0.0396
outcomes A / R / V / Y	148 / 192 / 124 / 107

The strict outcome is Y = A ∧ R ∧ V: admissible, completes under the execution cap, and returns a finite strict-precision value within absolute error 1e-7.

Recalibrating for your hardware

The memory coefficients in this repository were measured on an H200. They are calibration constants, not universal truths — on a different card the admission gate will be wrong until you re-measure.

What is hardware-specific:

• the process base (768 MiB here), which is the resident footprint before any amplitude storage
• the bytes per amplitude per action (20–40 B here), which depends on the adapter's auxiliary and workspace arrays, not just the state dtype
• the contraction boundary for qtensor_gpu, which is empirical

To port: run each action at increasing n until it fails, record peak memory against 2^n, and fit the intercept and slope. The intercept is your process base, the slope your bytes per amplitude. config/action_keys.json is where those numbers live.

Scope

Evidence supports resource-aware representation selection at n <= 35, p <= 5. Two of the ten actions validate only at a relaxed 1e-3 tolerance (cudaq_observe, qtensor_gpu) and are labelled as such throughout; qtensor_gpu additionally handles unweighted MaxCut only.

All 40 development labels are cuaoa_gpu, so the fresh evaluation contains no multi-class learned boundary. The learned and analytical paths are therefore reported separately (19 and 12 of the 31), and a dedicated 30-request crossover tests whether structural features improve ordering where learned-supported actions actually overlap — there they move top-1 from 12/30 to 25/30.

Citation

@misc{hsu2026raspqaoa,
  title  = {RASP-QAOA: Resource-Aware Per-Instance Selection for Exact QAOA Simulation},
  author = {Hsu, Chih-Chung},
  year   = {2026},
  eprint = {2608.05646},
  archivePrefix = {arXiv},
  primaryClass  = {cs.ET}
}

Preprint: arXiv:2608.05646.

See also LC-Implicit-QAOA (arXiv:2608.05610), the bounded-light-cone evaluator; local_lightcone is the corresponding action here.

License

MIT, © 2026 Chih-Chung Hsu. See LICENSE.