QP-Core / Architecture

Transpiler Pipeline

How a QP-Core request turns an OpenQASM 2.0/3.0 circuit into an Amazon Braket IR payload, documented against the backend's actual source, not an idealized description.

QP-Core's FastAPI service (quantumflow-api) exposes a single POST /api/v1/transpile endpoint. The request and response shapes are:

1class TranspileRequest(BaseModel):
2 qasm: str
3 target_device: BraketDevice = BraketDevice.LOCAL_SIMULATOR
4 optimization_level: int = Field(1, ge=0, le=3) # accepted, not yet wired up

The pipeline behind that endpoint has three real stages today, parse, convert, emit. There is currently no fourth "optimize" stage in the code path, which the next section explains.

1. Parsing

Parsing is Qiskit's own, not a QP Core authored AST parser. qasm3.loads() is tried first (OpenQASM 3); if that raises, the code falls back to QuantumCircuit.from_qasm_str() (OpenQASM 2). Both return a Qiskit QuantumCircuit, Qiskit's own in memory circuit representation. QP-Core doesn't define or walk its own AST.

1def _parse_circuit(source: str) -> QuantumCircuit:
2 try:
3 return qasm3.loads(source)
4 except Exception:
5 try:
6 return QuantumCircuit.from_qasm_str(source)
7 except Exception as exc:
8 raise TranspilationError(f"Could not parse circuit source: {exc}") from exc

2. Optimization, accepted, not yet wired up

TranspileRequest.optimization_level is a real field in the request schema (default 1, range 0-3, mirroring Qiskit's own convention), but the current transpile_to_braket() implementation never reads it. The circuit goes from parsed QuantumCircuit straight to Braket conversion, no qiskit.transpile() call, no PassManager, in the code path today.

For reference, once wired up this stage would run Qiskit's own preset pass managers, which include commutation based gate cancellation (cancelling or merging adjacent gates that commute past each other, not just adjacent identical ones) and, for hardware targets with limited connectivity, layout selection and SWAP based routing to satisfy the device's coupling map. Those are real, well documented Qiskit internals, see Qiskit's transpiler passes reference. QP-Core would be selecting and configuring them, not implementing them from scratch.

The live playground on this site shows a small, labeled preview of the same class of optimization: its client side analyzer (src/lib/qasmAnalyzer.ts) cancels adjacent self inverse single qubit gate pairs on the circuit you paste in and reports the resulting gate count reduction. It's a simplified, illustrative version of one thing a real commutation pass does, not the production QP-Core pipeline, and not a general commutation analysis (it only catches immediately adjacent identical gates, not gates separated by something they commute past).

3. Braket IR emission

Conversion is handled by qiskit_braket_provider's to_braket() adapter, which maps the Qiskit circuit onto Amazon Braket's circuit model. The response serializes that via to_ir(), braket_ir carries the IR's JSON payload, and qasm carries a readable OpenQASM form when the IR type exposes one.

1def transpile_to_braket(request: TranspileRequest) -> TranspileResponse:
2 circuit = _parse_circuit(request.qasm)
3 
4 braket_circuit = to_braket(circuit)
5 
6 return TranspileResponse(
7 braket_ir=braket_circuit.to_ir().json(),
8 qasm=braket_circuit.to_ir().source if hasattr(braket_circuit.to_ir(), "source") else str(braket_circuit),
9 target_device=request.target_device,
10 qubit_count=circuit.num_qubits,
11 gate_count=sum(circuit.count_ops().values()),
12 )

Benchmarks

Not yet measured. The test suite today (tests/test_transpiler.py) covers correctness, a health check and a Bell state transpile that asserts the reported qubit count, not performance. There is no Rust or native extension anywhere in this service; it is pure Python (FastAPI + Qiskit + qiskit-braket-provider). A performance benchmark section will be added here once real measurements exist, rather than before.

Source: github.com/sadeqisaidmohaddes-star/quantumflow-api