"Quantum advantage" is een gevaarlijke term. Hij klinkt absoluut: de quantumcomputer wint en de klassieke computer verliest. Voor near-term many-body simulatie is dat meestal te grof.
De betere vraag is praktischer
Hoeveel tijd kost het om voor deze specifieke taak een bruikbare observable te krijgen?
Dat noem ik hier time-to-answer.
De taak
De concrete taak is niet "bereken de volledige quantumtoestand exact". Dat zou voor 120 qubits absurd zijn. De taak is smaller:
- neem een 1D Fermi-Hubbard keten met 60 sites;
- evolueer tot
t = 6met 30 Trotter steps; - meet lokale observables zoals charge, spin en double occupancy;
- vergelijk met klassieke referenties waar mogelijk.
De quantumcomputer hoeft dus niet alles te geven. Hij hoeft een fysisch bruikbare observable te geven.
De simpele speedup
Als je de lokale chi256 MPS wall time vergelijkt met de Fire Opal main+readout execution proxy, krijg je:
\[\mathrm{speedup}=\frac{T_{\mathrm{classical}}}{T_{\mathrm{quantum}}}\qquad \frac{9033\,\mathrm{s}}{33.148928\,\mathrm{s}}\approx 272.5\]Dat is een indrukwekkend getal. Maar het is niet het hele verhaal.
Waarom niet?
Omdat execution time niet hetzelfde is als benchmark time. Een eerlijke vergelijking kan verschillende dingen tellen:
- alleen quantum circuit execution time;
- cloud wall time inclusief service overhead;
- queue time;
- klassieke preprocessing;
- layout en calibration search;
- error mitigation;
- post-processing;
- klassieke convergence studies.
Welke tijd je kiest, verandert de claim.
Als je alleen execution time vergelijkt, ziet de quantumroute er sterk uit. Als je volledige workflowtijd vergelijkt, wordt het moeilijker. Maar dat geldt ook voor de klassieke kant. Een klassieke methode heeft vaak eigen tuning: bond dimension, cutoff, truncation threshold, time step, symmetry sector en convergence checks.
De verborgen parameter
De Majorana-propagation vergelijking laat dit scherp zien. Cutoff 2 was heel snel, zelfs sneller dan de quantum execution proxy, maar niet nauwkeurig voor mean double occupancy. Cutoff 4 was veel nauwkeuriger, maar kostte ongeveer 19 minuten.
Het probleem is niet alleen de runtime van cutoff 4. Het probleem is dat je vooraf niet vanzelf weet dat cutoff 4 genoeg is. Om dat te weten, moet je vergelijken met een duurdere referentie of een convergence ladder draaien.
Dat is precies de time-to-answer vraag
Telt alleen de runtime van de beste klassieke parameter nadat je hem kent? Of telt ook de zoektocht die nodig is om te weten dat die parameter betrouwbaar is?
Een eerlijke formulering
Ik zou de claim zo formuleren
De quantumprocessor bewijst niet dat geen enkele klassieke methode deze taak aankan. Maar voor deze instantie en deze observable kan de quantumroute een betere praktische time-to-answer hebben dan een klassieke benadering waarvan de nauwkeurigheid afhangt van een vooraf onbekende truncatieparameter.
Dat is minder spectaculair dan "quantum advantage". Maar het is beter.
Waarom dit belangrijk is
Near-term quantumhardware gaat waarschijnlijk niet winnen door perfecte, universele simulatie. De interessante gevallen zitten in concrete taken:
- een specifieke Hamiltoniaan;
- een specifieke observabele;
- een specifieke nauwkeurigheid;
- een specifieke workflow;
- een duidelijke klassieke tegenstander.
In zo'n benchmark is het niet genoeg om te zeggen dat er een klassieke methode bestaat die achteraf goed werkt. Je moet ook vragen hoeveel werk nodig was om te weten dat zij goed werkt.
De klassieke frontier beweegt
Er is inmiddels ook een klassieke tegenreactie op de Q-CTRL claim. Betere symmetry-aware GPU tensor-network simulaties kunnen de oorspronkelijke speedup sterk verkleinen. Dat is precies hoe wetenschap hoort te werken. Een quantum claim zet een benchmark neer, en klassieke methoden verbeteren.
Daarom moet de claim niet zijn
klassiek is onmogelijk.
De claim moet zijn
voor deze taak is de quantumroute een serieuze time-to-answer kandidaat, en de klassieke route moet inclusief tuning en validatie worden geteld.
Dat is het echte benchmarkprobleem.
Bronnen en projectlinks
- Q-CTRL Fermi-Hubbard paper: https://arxiv.org/abs/2605.04025
- Projectrepo: https://github.com/BramDo/fermi-hubbard-60q-tdvp
- Classical response paper: https://arxiv.org/abs/2606.04771
- Majorana benchmark in deze repo:
docs/120q30_majorana_benchmark_summary.md