Deel 7 van de reeks Van quarks tot quantumvoordeel
Na zes delen kunnen we eindelijk de vraag stellen die vaak al in de eerste alinea wordt gesteld: heeft de quantumprocessor gewonnen van de klassieke computer? Het eerlijke antwoord is niet één woord. De hardwaretijd is veel korter dan de gepubliceerde TN- en Pauli-propagatietijden voor de gekozen observable-estimation-instantie. Maar korter wordt pas quantumvoordeel als taak, nauwkeurigheid en tijdsaccounting voldoende gelijk zijn.
De paper levert sterk bewijs voor een praktisch interessante hardware-route en een coherent niet-Abels hadronsignaal in het vroege tijdvenster. Zij levert nog geen algemene complexiteitsscheiding, geen volledige end-to-endbenchmark en geen bewijs dat ieder laat tijdpunt nauwkeurig overeenkomt met één bekende klassieke waarheid.
Vier vragen, niet één
Een voordeelclaim moet vier afzonderlijke vragen beantwoorden:
- Fysica: volgt de benaderde dynamica de volledige LSH-Hamiltoniaan?
- Circuit: berekent het ideale circuit de bedoelde observabele?
- Hardware: blijft het signaal na gates, decoherentie en meting herkenbaar?
- Prestatie: is de quantumroute voor dezelfde taak sneller of schaalbaarder?
flowchart LR
H["volledige LSH-theorie"] -->|"TN versus PP"| C["ideaal circuit"]
C -->|"PP versus QPU"| Q["hardwaredata"]
Q -->|"decoder en normalisatie"| O["fysische observabele"]
O -->|"gelijke fout en accounting"| A["voordeelclaim"]Een snelle hardwaremeting zonder de eerste drie stappen kan efficiënt het verkeerde antwoord produceren. Een perfecte kleine validatie zonder prestatievergelijking toont daarentegen geen voordeel. De kracht van dit project zit in de keten, maar iedere schakel heeft een eigen bereik.
Wat vergelijkt de paper fysisch?
De tensor-networkroute evolueert de volledige LSH-Hamiltoniaan met een fluxcutoff en \(D_{\max}=200\). Pauli-propagatie evolueert de gemeten operatoren door het ideale, benaderde Trottercircuit. De QPU voert dat circuit uit met hardwarefouten.
Daaruit volgen twee diagnostische verschillen:
TN - PP -> modelbenadering, cutoffverschil en Trotterisatie
PP - QPU -> hardware-, compilatie- en meetfoutenDe overeenkomst in de vroege ruimtetijdheatmaps en in de afgeleide breathing frequency ondersteunt de interpretatie van het hardwarepatroon als hadrondynamica. Dat is sterker dan alleen een geconserveerde globale lading.
De vergelijking wordt later in de evolutie moeilijker. De TN-bonddimensie raakt beperkend, PP moet meer Pauli-termen behandelen en de diepe QPU-circuits verzamelen meer hardwarefout. De methoden kunnen dan allemaal verslechteren, maar niet noodzakelijk in dezelfde richting.
Dezelfde observabele is een harde voorwaarde
De globale lading
\[Q=\sum_r[n_i(r)+n_o(r)]
\]
heeft een exact bedoelde waarde 60. Zij is uitstekend voor sectorcontrole. Bij stap 20 rapporteert de tracker \(Q_{\mathrm{QPU}}=59,99402699\), een afwijking van ongeveer 0,00597. De meegeleverde charge-based error bar is 0,00571065; die is dichtbij, maar niet identiek aan de ruwe absolute afwijking.
De hadronvraag zit echter in \(n_f(r,t)\), de differentieheatmap en de breathing frequency. Een correcte (Q) sluit grote lokale profielafwijkingen niet uit. Dat blijkt ook uit de trackerwaarden voor de globale \(n_f(20)\)-scalar:
| methode | n_f(20) |
|---|---|
| TN | 0,277835 |
| PP-CPU | 0,408178 |
| PP-GPU | 0,245628 |
| QPU | -0,077234 |
De methodestandaarddeviatie is daar ongeveer 0,2062 en de QPU ligt 0,32 tot 0,49 onder de drie klassieke waarden. Stap 20 is dus geen punt waarop alle methoden numeriek samenvallen. De paperclaim steunt breder op het vroege ruimtetijdpatroon, symmetriebehoud en de spectroscopische frequentie.
Dit bepaalt ook de grens voor onze reproductie. Onze lokale SCV-versus-meson-scalar is uit dezelfde QASM-counts afgeleid, maar gebruikt nog niet aantoonbaar dezelfde som en normalisatie als tracker-\(n_f(t)\). De twee kolommen mogen daarom niet als fout van elkaar worden afgetrokken. Eerst moet de paperdefinitie exact in de analyzer worden vastgelegd.
De paper-native timing
De tracker rapporteert voor de hoofdinstantie tijden per geëvalueerde Trotterdiepte. Voor stappen 5 en 20 zijn de gepubliceerde waarden:
| stap | QPU | TN | PP-CPU | PP-GPU | snelste klassieke / QPU |
|---|---|---|---|---|---|
| 5 | 20,0 s | 584,092 s | 477,447 s | 547,581 s | 23,9x |
| 20 | 20,0 s | 2.484,369 s | 2.930,440 s | 8.949,110 s | 124,2x |
Bij stap 5 is PP-CPU de snelste van de drie klassieke routes; bij stap 20 is TN de snelste. Binnen de accounting van de paper blijft de QPU op 20 seconden door het vaste shotbudget, terwijl de klassieke methoden duurder worden met de evolutiediepte en de benodigde representatiegrootte.
Deze tabel ondersteunt een duidelijke praktische timingwinst binnen het gerapporteerde benchmarkprotocol. Zij bewijst niet dat iedere klassieke algoritmefamilie op iedere machine minstens zo langzaam moet zijn. Het zijn gemeten of gerapporteerde implementaties met concrete cutoffs en resourcebudgetten.
Onze Fire Opal-timing
Onze lokale hardware-only tijd gebruikt estimated_duration * shots voor de twee main-circuits, SCV en meson. Bij 512 shots vonden we 0,987136 seconde voor stap 5 en 2,768896 seconden voor stap 20.
Om alleen de shotbudgetten gelijk te trekken kunnen we lineair naar 10.000 shots schalen:
| stap | lokaal gemeten, 512 shots | geschat bij 10.000 | paper-QPU | snelste paper-klassiek / lokale schatting |
|---|---|---|---|---|
| 5 | 0,987136 s | 19,28 s | 20,0 s | 24,8x |
| 20 | 2,768896 s | 54,08 s | 20,0 s | 45,9x |
Bij stap 5 komt de lineaire schatting vrijwel overeen met de paper-QPU-tijd. Bij stap 20 is onze geschatte ibm_fez-hardwaretijd ongeveer 2,7 keer zo groot als de paperwaarde van 20 seconden. De quantumroute blijft daar in hardwaretijd ruim sneller dan de gepubliceerde klassieke baselines: ongeveer 45,9 keer ten opzichte van TN, 54,2 keer ten opzichte van PP-CPU en 165,5 keer ten opzichte van PP-GPU.
De 54,08 seconden zijn niet gemeten. Zij veronderstellen lineaire shotschaling en dezelfde geoptimaliseerde circuitduur. Een echte 10.000-shotrun kan door servicegedrag, calibratie of batching anders uitvallen.
Drie klokken geven drie antwoorden
Voor onze lokale runs zijn minstens drie tijdsdefinities relevant:
| klok | bevat | sluit uit |
|---|---|---|
| hardware-only | geschatte QPU-uitvoering van de shots | queue, API, analyse |
| action wall | Fire Opal-action van submit tot resultaat | lokale voorbereiding en nabewerking |
| end-to-end | voorbereiding, service, hardware, ophalen en decoding | niets binnen de gekozen workflow |
De main action voor stap 5 had een wall time van 133 seconden. De gecombineerde main action voor stappen 10, 15 en 20 duurde 304 seconden. De hardware-only delen daarbinnen zijn veel korter. Dat is niet tegenstrijdig: een cloudservice kan wachten, compileren, plannen en meerdere circuits als groep verwerken.
De paper-QPU-tijd en onze lokale hardwaretijd zijn geschikt voor de vraag hoe de fysieke shotuitvoering schaalt. Zij beantwoorden niet hoe lang een onderzoeker vanaf een bronbestand op een eindresultaat wacht. Een end-to-endvoordeel is met de huidige tabellen dus niet vastgesteld.
Er is nog een tweede accountingvraag. De QPU gebruikt voor ieder tijdpunt een apart circuit. Een klassieke TDVP-run kan onderweg meerdere tijdpunten uit dezelfde evolutie opslaan. De paper rapporteert zijn eigen compute up to step protocol, maar een onafhankelijke hele-trajectbenchmark moet expliciet vastleggen of alle tijdpunten of alleen het laatste punt worden gevraagd.
Nauwkeurigheid en tijd horen bij elkaar
Een methode die sneller wordt door agressiever te trunceren, heeft alleen voordeel wanneer de fout nog binnen het afgesproken budget ligt. Voor deze vergelijking zijn drie foutsoorten zichtbaar:
- TN: fluxcutoff, eindige bonddimensie en verlies bij groeiende verstrengeling;
- PP: afkap of budgettering van een groeiende Pauli-expansie;
- QPU: gate-, decoherentie-, readout- en shotruis.
De paper gebruikt globale ladingsafwijking en methodespreiding als praktische diagnostiek omdat de exacte \(N=60\)-real-timeoplossing niet beschikbaar is. Methodespreiding is echter geen statistisch betrouwbaarheidsinterval rond een bekende waarheid. Alle methoden kunnen een gedeelde bias hebben, of juist door verschillende benaderingen uiteenlopen.
Een definitieve benchmark zou vooraf één foutmaat kiezen, bijvoorbeeld RMSE van de volledige \(\Delta n_f(r,t)\)-heatmap in een tijdvenster, plus een tolerantie voor (Q) en de breathing frequency. Daarna moeten alle routes tot diezelfde tolerantie worden geconvergeerd en pas dan worden getimed.
Vier mogelijke betekenissen van quantumvoordeel
We kunnen de conclusie nu precies formuleren:
| Claim | Huidige status |
|---|---|
| Asymptotisch complexiteitsvoordeel | niet aangetoond |
| Universeel klassiek onbereikbaar resultaat | niet aangetoond |
| End-to-end runtimevoordeel | nog niet gemeten |
| Hardwaretijdwinst tegenover de gerapporteerde TN/PP-baselines | duidelijk aanwezig |
| Coherent fysisch signaal op een grote niet-Abelse instantie | ondersteund in het vroege tijdvenster |
De sterkste verdedigbare formulering is daarom een praktische hardwaretijdwinst voor de gedefinieerde observable-estimation-taak, gedragen door een gelaagde maar benaderde fysische validatie. Dat is wetenschappelijk interessant zonder het groter te maken dan de data toelaten.
Wat is nog nodig voor onze eigen sterke claim?
De lokale reproductie heeft vier concrete vervolgstappen:
- Implementeer exact de paper-normalisatie van \(n_f(t)\) en test die op synthetische en ideale QASM-data.
- Voer stap 20 bij voorkeur werkelijk met 10.000 shots uit in plaats van alleen lineair te schalen.
- Rapporteer bootstrap- of binomiale onzekerheden voor SCV, meson en hun differentie, naast de (Q)-sectorcontrole.
- Meet hardware-only, action wall en volledige end-to-endtijd met dezelfde begin- en eindpunten voor quantum en klassiek.
Voor een hele-trajectclaim moet daar nog één keuze bij: telt de taak alleen \(t=20\), of alle twintig tussenpunten? Die workload moet voor alle methoden identiek zijn.
Eindconclusie van de reeks
De weg van quarkfysica naar een timingtabel bestaat uit veel meer dan een groot QASM-bestand. De niet-Abelse Gauss-wetten worden eerst in de LSH-basis opgelost. Een zwakke-koppelingsbenadering reduceert de lokale dynamica tot twee qubits per site. Trotterisatie maakt daar een ondiep lokaal circuit van. Differentiële SCV-versus-mesonmeting haalt een coherent signaal uit ruizige hardware. TN en PP controleren vervolgens verschillende overgangen in die keten.
Binnen dat zorgvuldig afgebakende protocol is de QPU-hardware veel sneller dan de gerapporteerde klassieke baselines en blijft fysisch herkenbare vroege hadrondynamica zichtbaar. De huidige data rechtvaardigen nog geen algemene uitspraak dat klassieke simulatie is verslagen. Ze laten wel zien dat een physics-native encoding een niet-Abelse real-timeberekening op een schaal brengt waar de beschikbare klassieke referenties snel duur en moeilijk te controleren worden.
Dat is geen slogan, maar een concreet onderzoeksresultaat met een duidelijke volgende test: dezelfde paper-genormaliseerde observabele, dezelfde foutgrens en dezelfde klok op alle platforms.