A quantum machine can report excellent gate fidelity and still fail the only test that matters: can it complete a useful circuit, at a useful rate, after compilation, decoding, routing, and error correction take their share? QUOPS and CUDA-Q Logical put that uncomfortable question at the center of fault-tolerant quantum engineering.
This is a tougher standard than raw qubit count. It is also the standard HPC teams need. A quantum processing unit beside a classical cluster isn’t an exhibit; it is a constrained accelerator with a scheduler, a control path, a cooling budget, and an application-level service objective.
NVIDIA’s September 14, 2026 Toronto release made the pairing concrete: CUDA-Q Logical became an open-source coordination layer for fault-tolerant applications, while Sandia’s Quantum Universal Operations Performance System, QUOPS, entered CUDA-Q as a first-class benchmarking primitive. This is not a finished production stack. At this stage, it is more useful: a disciplined loop for compiling, scheduling, and measuring early fault-tolerant workloads.
CUDA-Q Logical makes fault tolerance a compilation contract
The central design decision in the CUDA-Q Logical preprint, arXiv:2609.13388, is simple in concept and demanding in practice. Keep the application program immutable as it picks up implementation commitments. Instead of flattening a kernel into a one-shot device program, the compiler carries an accumulating build from P0 through P4. Earlier artifacts remain available after later stages run.
That preservation matters. Fault tolerance is a coupled optimization problem: logical placement affects routing; routing affects the code schedule; the schedule affects idle error, decoder load, controller bandwidth, and wall-clock execution time. A compiler that drops its placement decision when it binds a code is hard to inspect. I’d rather retain a larger build artifact than accept a smaller opaque executable.
P0 through P4, with responsibility separated
At P0, CUDA-Q kernels become typed logical programs. Physical qubits, pulse envelopes, and vendor-specific topology do not belong here. An algorithm team can express logical allocation, unitary operations, measurement, and classical feedback without quietly baking in an assumption about a trapped-ion chain or a neutral-atom array.
P1 attaches logical-machine placement. Logical qubits map onto an architecture-independent grid or connectivity graph, while the placement stays code-independent. That separation lets an engineer compare layouts before deciding whether the target will use a surface-code patch or a [[7,1,3]] realization. It sounds procedural. It prevents expensive confusion.
P2 binds the quantum error-correcting code. A logical CNOT is no longer merely a logical CNOT; it becomes an encoded operation with syndrome extraction, encoded gate sequences, ancilla use, and correction semantics. P3 binds the device and produces physical schedules, including physical-qubit demand, gate counts, latency constraints, and timing. P4 is intended to create the concrete hardware-controller plan. The public release as of September 2026 reaches P0–P3, so controller synthesis remains unfinished engineering work, not a feature to quietly assume.
MLIR is a sensible foundation for this problem. Its dialect and conversion machinery can represent progressively constrained operations while keeping type and legality checks local to a lowering boundary. The real benefit is architectural: each stage can enforce a contract. P1 should reject a placement that violates its logical graph. P2 should expose the code assumptions it introduces. P3 should explain each physical resource estimate back to its encoded origin.
// Conceptual build lineage; names illustrate the contracts, not a public API.
p0 = lift_cudaq_kernel(kernel);
p1 = place_logical_machine(p0, connectivity_graph);
p2 = bind_qec_code(p1, code_choice); // surface code or [[7,1,3]]
p3 = schedule_for_device(p2, target_model); // timing, qubits, operations
report = estimate_resources(p3);The important engineering rule is to version the build lineage, not just the source kernel. A reproducible result needs the logical program, P1 placement policy, P2 code parameters, P3 target model, compiler revision, decoder assumptions, and benchmark configuration. Without that record, two resource reports with the same source file can describe entirely different machines.
QUOPS measures the work that survives the stack
Sandia’s QUOPS paper, arXiv:2609.12146, avoids the usual proxy metrics. It determines the largest computationally relevant randomized circuits a machine can execute successfully, along with the rate at which it executes them. Its two reported quantities are Q, the largest benchmark circuit size above a success threshold in a utility-motivated region, and Ω, the effective operations per second at that point.
QUOPS defines circuit size as 2 × width × depth. Deliberately so. Width alone rewards idle capacity, while depth alone hides whether a system can coordinate a substantial register. Q forces both dimensions into the score, and Ω asks whether the machine can process that credible workload quickly enough to matter.
A useful benchmark boundary is not “how many qubits exist?” It is “which circuits complete reliably, and how fast?”
The benchmark sweeps randomized but structured workload shapes and identifies a capability frontier: circuit configurations that still succeed, plus adjacent configurations that do not. The same procedure can be applied across architectures, codes, modalities, and fault-tolerance levels. It can compare a trapped-ion device, a superconducting processor, and a neutral-atom array without pretending their native operations are identical.
QUOPS is not magic. A randomized workload can underrepresent a particular application’s routing pressure, non-Clifford density, mid-circuit measurement pattern, or classical feedback latency. The wrong default is to treat Q as a universal application speedup score. Use it as a system-capability boundary, then put an application-specific workload beside it. If the application sits outside the boundary, the rest of the proposal is decoration.
The early experiments provide needed scale discipline. Sandia applied QUOPS to processors from Quantinuum, Google, and IBM using physical qubits, and found that capability must grow by about five orders of magnitude before recognized challenge problems become realistically addressable. That isn’t a reason to dismiss current systems. It is a reason to stop turning isolated fidelity improvements into premature application claims.
One logical workload can be refined and retargeted across fault-tolerant architectures.
The same work evaluated a simple fault-tolerant logical-qubit processor on Quantinuum’s Helios-1 with up to eight [[7,1,3]]-encoded logical qubits. This is what a bridge metric should provide: physical systems can be tracked now, logical demonstrations can be plotted on the same conceptual axes, and projected generations can be tested against a common capability definition rather than a vendor-specific slogan.
QUOPS and CUDA-Q Logical form an experimental loop
The combined workflow is best understood as a closed engineering loop. An application team writes a hybrid CUDA-Q kernel. CUDA-Q Logical lifts it to P0, explores placement at P1, binds candidate QEC schemes at P2, and generates target schedules at P3. QUOPS then probes the actual target’s capability region. Results feed back into code choice, placement, algorithm design, or the decision not to deploy yet.
Picture the system diagram as four planes. At the top, an application plane contains a quantum Monte Carlo kernel or a materials-simulation subroutine. Beneath it, the compiler plane holds P0 through P3 artifacts and resource models. The execution plane contains QPU scheduling, decoding, measurement streams, and classical control. Alongside all three sits the QUOPS plane, which runs standardized workloads and records Q and Ω under a declared configuration.
That sidecar position matters. Benchmarking shouldn’t be a one-time certification exercise after integration. Run it during compiler upgrades, decoder replacements, control-firmware changes, and device calibration changes. A P3 schedule that reduces nominal entangling gates can still worsen Ω if it creates a serialized measurement path or overloads the decoder.
Fermilab’s reported use of CUDA-Q Logical is a useful operational signal. NVIDIA says it reduced fault-tolerant architecture development from five months to three weeks, roughly a sevenfold acceleration in iteration cycles. The number should not be generalized blindly; it reflects a particular workflow and baseline. Still, the mechanism is credible: reusable intermediate artifacts remove repeated manual translation between algorithm, code, architecture, and schedule studies.
A benchmark protocol that can survive review
A serious QUOPS campaign needs more than one score. Capture the target hardware identity, calibration interval, compiler build, P2 code realization, decoder version, P3 scheduling policy, success threshold, sampled width-depth grid, queue behavior, and whether Ω includes reset, readout, decoding, and host-to-controller transfer. Four runs across separate calibration windows are more valuable than a single glossy maximum.
Then compare two frontiers. The first is the native QUOPS frontier of the device. The second is the frontier after compiling representative application kernels through the same P0–P3 chain. The gap between them is actionable compiler debt: routing inefficiency, poor placement, costly decomposition, unnecessary synchronization, or an error-correction binding mismatched to the machine.
Retargeting CUDA-Q Logical across hardware is not free
CUDA-Q Logical can preserve one logical description across targets. It cannot erase hardware character. Quantinuum’s trapped-ion approach, supported by a finalized $100 million CHIPS R&D award announced September 8, 2026, depends on ion-trap fabrication, control electronics, and optical stability. Its work with GlobalFoundries on next-generation ion traps and control electronics, and Monarch Quantum on lasers and optical components, addresses variables that can move the QUOPS frontier directly.
Neutral atoms present a different compilation target. QuEra uses rubidium atoms in laser-based optical tweezers, Rydberg interactions, flexible layouts, qubit shuttling, and analog and digital modes. Tens of thousands of atoms can fit in less than a square millimeter, while acousto-optic deflectors steer a small number of lasers across many sites. The physical density is attractive. The scheduler still has to account for movement, interaction zones, calibration state, and the timing cost of reconfiguration.
QuEra has stated that Libra, a megaquop-class system with 256 logical qubits at a 10-6 logical error rate, is scheduled for Amazon Braket in 2028. It targets a gigaquop-class successor with 1,000+ logical qubits in 2028/29. Those are exactly the claims a QUOPS-oriented workflow can make concrete. “Megaquop” should correspond to an observed capability region under a stated protocol, not become a label detached from scheduling and decoder costs.
Pasqal’s September 10, 2026 three-year Memorandum of Understanding with LG CNS points toward hybrid AI and quantum computing platforms for data centers. QuEra’s collaboration with HPE similarly points to on-premises HPC integration. In both cases, the difficult boundary is classical-quantum orchestration: batching policy, queue isolation, data movement, retry semantics, calibration-aware admission control, and the latency budget for feedback. A QPU doesn’t become an HPC accelerator merely because it occupies the adjacent rack.
For early deployments, treat the QPU as a scarce asynchronous service. Submit workloads that amortize compilation and control setup. Keep classical preprocessing local to the cluster. Record every execution context. Avoid tight host-driven loops unless the controller can close them within the required coherence and error-correction timing window. It’s fine for a prototype, not for a fleet. This is less glamorous than a quantum circuit diagram, but it is where useful Ω is won or lost.
The decision gate is capability, not spectacle
CUDA-Q Logical and QUOPS give technical leaders a clean decision gate. Compile the same logical workload against competing placements and QEC bindings. Generate P3 resource and timing estimates for each candidate target. Measure Q and Ω using the CUDA-Q QUOPS reference implementation. Then ask whether the application’s required circuit shape and throughput sit inside the demonstrated region with operational margin.
Benchmarkable quantum co-processors move closer to practical HPC deployment.
If they do not, preserve the artifacts, identify the dominant constraint, and wait or redesign. Don’t bury that result beneath raw qubit numbers. If they do, the next question is concrete: can the controller path, decoder, and HPC scheduler sustain that capability outside a benchmark run?