Origin Quantum vs IBM Quantum: 100 Production Jobs Through Two Quantum Stacks

Quantum Genesis #5 — generated on Origin Quantum WK_C180

Quantum Genesis needed 100 quantum seeds, one per NFT. We started on Origin Quantum's WK_C180 and produced the first 18 pieces there. Then we switched to IBM Quantum (ibm_fez and ibm_torino) for the remaining 82. I want to be upfront about why: this wasn't a strategy we designed, it was a necessity forced on us, and the comparison below is honest field notes rather than a curated spec sheet.

Before relying on vendors' claims, we'd spent the previous weeks building a working pipeline — the QRNG approach is laid out in the generator post, and my earlier Origin vs IBM comparison captured the first impressions. This post is the production version of that, at 100 jobs.

The hardware, side by side

MetricOrigin Quantum WK_C180IBM Quantum ibm_fezIBM Quantum ibm_torino
Qubits180156133
TopologyNot fully publicHeavy-hex (fixed coupling)Heavy-hex (fixed coupling)
SDKpyqpanda3Qiskit Runtime (SamplerV2)Qiskit Runtime (SamplerV2)
Access modelQCloudService API (private)IBM Quantum Platform (public)IBM Quantum Platform (public)
Shots per NFT8,0004,0964,096
Avg time/NFT~45 seconds~19 seconds~22 seconds
Error mitigationBasicTREM (built-in)TREM (built-in)

The SDK gap: pyqpanda3 vs Qiskit Runtime

This is where the two stacks differ the most, and where most of our pain lived.

Origin Quantum — pyqpanda3. Learning curve is steep and the documentation is sparse (mostly Chinese, tiny community). Measurement requires an explicit mapping — measure([qubits], [classical_bits]) — and it's easy to get the lists out of sync. We hit breaking changes between versions; pinning the version reduced the flux but didn't eliminate edge cases. Error messages were minimal; "Failed to submit job" with no further detail was a common afternoon. Circuit definition is verbose — qubit allocation, classical register allocation, and program initialization are all manual.

IBM Quantum — Qiskit Runtime (SamplerV2). The learning curve is moderate with excellent docs, a large community, and plenty of tutorials. SamplerV2 handles measurement automatically — you define the circuit and run. It was rock solid; versioning is semver. Error messages are rich, job logs exist, and the platform visualizes circuits. generate_preset_pass_manager handles heavy-hex topology mapping during transpilation. TREM error mitigation, dynamical decoupling, and zero-noise extrapolation are all built in.

The gap is real. pyqpanda3 felt like a research prototype; Qiskit Runtime felt production-grade. That's not a knock on Origin's hardware — it's a statement about the SDK experience, and they don't have to be the same thing.

Queues and access

Origin Quantum is private. We negotiated access directly through their QCloudService — there's no public queue because there's no public availability. If you don't have a contract, you don't get in.

IBM Quantum is a public platform. The free tier (open plan) has queue times; pay-per-use and reserved capacity are available. For our 82 NFTs, the average queue wait was 2–5 minutes, and the total wall time for the whole batch was roughly 2 hours.

For reproducibility and scheduling, IBM wins. A pipeline you can start and forget is a pipeline you can actually ship.

Shot fidelity and noise

We used the Shannon entropy per shot as a proxy for shot fidelity — a measurement that's closer to a fair coin carries more usable entropy:

MetricOrigin WK_C180IBM ibm_fezIBM ibm_torino
Shots/NFT8,0004,0964,096
Avg Shannon entropy/shot3.92 bits3.97 bits3.95 bits
Max entropy score (0–100)949897
"Maximum" entropy NFTs021
Decoherence rate (est.)HigherLowerModerate

IBM's TREM error mitigation shows in the numbers. ibm_fez produced the highest entropy scores (98). Origin's higher shot count (8,000 vs 4,096) partially compensated for the extra noise, but it didn't fully close the gap.

Cost

  • Origin Quantum: private commercial contract, not publicly priced — realistically in the thousands for dedicated access.
  • IBM Quantum: free tier (open plan) for research, pay-per-second for reserved, enterprise contracts available. Our 82 NFTs ran at ~$0 on the free tier, within fair-use limits.

Which would I choose again?

For anything we ship next: IBM Quantum, without much hesitation. Qiskit Runtime is production-grade, SamplerV2 with TREM is dependable, and the public platform means the numbers above are reproducible by anyone.

But Origin Quantum WK_C180 has a place that isn't measured in entropy scores. The 18 Origin pieces (#1–18) are historically significant — among the first NFTs ever generated on a Chinese quantum processor. That provenance is real, and it's part of why the collection tells a story about the state of quantum hardware rather than just one vendor's kit. You can read about why the collection ended up split across two vendors in the launch post.

So my honest answer, both parts: for the next project, 100% IBM Quantum. For this one, I'm glad both stacks are in the record — the honest comparison is the content. If you're choosing hardware for a production job, benchmark the SDK and the queue before you benchmark the qubit count; the qubit count is rarely the thing that breaks your week.

Comments

Popular posts from this blog

Getting Your Collection Visible on OpenSea, Step by Step

Polygon versus Ethereum for an NFT contract, from the gas bills up

Quantum Error Correction, or Why Your Qubits Forget What They Were Doing