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

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
| Metric | Origin Quantum WK_C180 | IBM Quantum ibm_fez | IBM Quantum ibm_torino |
|---|---|---|---|
| Qubits | 180 | 156 | 133 |
| Topology | Not fully public | Heavy-hex (fixed coupling) | Heavy-hex (fixed coupling) |
| SDK | pyqpanda3 | Qiskit Runtime (SamplerV2) | Qiskit Runtime (SamplerV2) |
| Access model | QCloudService API (private) | IBM Quantum Platform (public) | IBM Quantum Platform (public) |
| Shots per NFT | 8,000 | 4,096 | 4,096 |
| Avg time/NFT | ~45 seconds | ~19 seconds | ~22 seconds |
| Error mitigation | Basic | TREM (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:
| Metric | Origin WK_C180 | IBM ibm_fez | IBM ibm_torino |
|---|---|---|---|
| Shots/NFT | 8,000 | 4,096 | 4,096 |
| Avg Shannon entropy/shot | 3.92 bits | 3.97 bits | 3.95 bits |
| Max entropy score (0–100) | 94 | 98 | 97 |
| "Maximum" entropy NFTs | 0 | 2 | 1 |
| Decoherence rate (est.) | Higher | Lower | Moderate |
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
Post a Comment