Edukaizen

Menu
  • Nieuws
  • Hubbard 1D
    • Part 1: 1D Hubbard model
    • Part 2: Snake layout and fSWAP
    • Part 3: Qiskit and Fire Opal
    • Part 4: 120-qubit run
    • Part 5: Time-to-answer
    • Part 6: Tensor networks
    • Part 7: Majorana propagation
    • Part 8: Heatmaps
    • Part 9: 2D Hubbard outlook
    • Part 10: Quantum computer as a lab
    • Part 11: Official Monoprop benchmark
  • Hubbard 2D
    • Part 1: 1D to 2D
    • Part 2: Cuprates
    • Part 3: 3×3
    • Part 4: Time
    • Part 5: 4×4
    • Part 6: 6×6 Fez
  • Hadron
    • Part 1: Hadron on a quantum processor
    • Part 2: Quarks and confinement
    • Part 3: SU(2) and LSH
    • Part 4: Hamiltonian and circuit
    • Part 5: Fire Opal
    • Part 6: Classical simulations
    • Part 7: Quantum advantage
  • Black Hole OLE
    • Part 1: What we ran
    • Part 2: How OLE works
    • Part 3: Fire Opal and Kingston
    • Part 4: The tensor-network challenge
    • Part 5: Hawking and scrambling
    • Part 6: What the result proves
    • Part 7: Local toy model
    • Part 8: QGSS26 compatibility
  • Random Graph
    • Start here
    • Part 1: Theory
    • Part 2: Circuit
    • Part 3: Qiskit
    • Part 4: Complexity
    • Part 5: Verification
    • Part 6: Workflow
    • Part 7: Conclusion
  • QOS QML
    • Tutorial: UMI counts to a four-qubit circuit
    • Part 1: The QML task
    • Part 2: QOS theory
    • Part 3: Gene expression to 40 qubits
    • Part 4: JAX to hardware
    • Part 5: Readout and classifier
    • Part 6: 40-qubit result
    • Part 7: Route to quantum advantage
    • Part 8: 60-qubit result
  • Floquet-Ising
    • Part 1: Floquet physics
    • Part 2: Ising cycle
    • Part 3: Two-qubit toy model
    • Part 4: Oscillation and entanglement
    • Part 5: Noise and error mitigation
    • Part 6: Toward 51 qubits
  • GOLD REL
    • Part 1: Why gold is a relativistic quantum problem
    • Part 2: Why the 2025 gold VQE study stalled
    • Part 3: From QE and spin-orbit coupling to Qiskit
    • Part 4: Twelve gold spinor modes on four qubits
    • Part 5: The 24-qubit route: an active window for transport
    • Part 6: 24 qubits on IBM and with Fire Opal
    • Part 7: The road to quantum advantage for gold
  • Advantage List
Menu

Het 60-qubitresultaat: hardware 17, lineair 16, RBF 14

Nederlands | English | Projectpagina | Vorig deel | Volgend deel | QOS paper | Officiële code | Hardwarecode

Op 21 juli 2026 is de eerder voorgestelde 60-qubitpilot daadwerkelijk uitgevoerd via Fire Opal op ibm_fez. Ditmaal betekende meer breedte niet simpelweg een grotere hash. We vervingen de oude invoer door zestig labelvrije coexpressiemodules en hielden het circuit bewust ondiep.

De vaste held-out test gaf het beste hardwarepuntresultaat in deze reeks:

Route Balanced accuracy Correct
60-qubit hardware 0,53125 17/32
klassieke lineaire baseline 0,50000 16/32
klassieke RBF-baseline 0,43750 14/32

Dit is een positief resultaat op twee assen: de bevroren hardwareclassifier eindigde op deze test vóór beide vooraf vastgelegde klassieke referenties, en de quantumfeatureberekening gaf lokaal een duidelijke tijdseparatie tegenover MPS. Door de kleine testset en de ontbrekende MPS-convergentie is het geen algemene of asymptotische quantum-advantageclaim.

Relatie tot de QOS-paper

De 60q-pilot is geen letterlijke QOS-implementatie. De zestig modulewaarden worden klassiek berekend en als rotatiehoeken in een ondiepe RY/RZ/RZZ-featuremap geladen. De route bevat niet de willekeurige sample-opgebouwde query-oracle uit de paper, geen QSVT/lineaire solver en niet de exacte classical-shadowreadout.

Een letterlijke QOS-bouwsteen staat elders in dit project: het afzonderlijke 4q flat-QOS-toymodel voor \(D=16\) en \(M=64\) implementeert de officiële q_state_sketch_flat sampling-kern. Fire Opal-action 2334156 behaalde voor 64 willekeurige kernels gemiddeld 0,990104 Hellinger-fideliteit. Dat 4q-resultaat valideert de sketch-kern, maar niet de volledige classifier. Het 60q-resultaat valideert de brede real-data hardware-adaptatie, maar niet de formele oracleketen. Samen vormen ze een duidelijke, nog onvolledige brug naar de paper.

Waarom de eerste 60-qubitroute niet werkte

Onze eerdere 60-qubitroute haalde 15/32 op hardware, tegenover 17/32 ideaal en 19/32 klassiek. De extra qubits droegen toen vooral meer gehashte invoerkanalen. Dat voegde breedte toe, maar niet noodzakelijk stabielere biologische structuur.

De nieuwe pilot veranderde daarom de representatie, niet alleen het aantal qubits:

  • zestig coexpressiemodules, geleerd uit een vaste en labelvrije pool van 512 cellen;
  • 1.200 variabele genen met detectiefrequentie tussen 1% en 95%;
  • deterministische KMeans met random_state=6110 en n_init=20;
  • per module vier samenvattingen: gemiddeld log1p, detectiefractie, RMS en het gemiddelde van het bovenste kwartiel;
  • mediaan/IQR-schaling uitsluitend geleerd op de trainingscellen;
  • tanh(z/3) en L2-normalisatie per blok.

De modulepool, training en test zijn onderling gescheiden. De testlabels speelden geen rol bij modulevorming, schaling, modelkeuze of hyperparameterkeuze.

Het 60-qubitcircuit

De zestig qubits liggen in een logische 6×10-topologie. De featuremap gebruikt vier invoerblokken, een multiplier van sqrt(60), een logische diepte van 20 en 134 tweequbitinteracties. X-, Y- en Z-metingen leveren samen 627 geordende observabelen per cel.

Voor 32 trainings- en 32 testcellen zijn drie meetcircuits per cel gemaakt:

  • 192 circuits;
  • 128 shots per circuit;
  • 24.576 shots totaal;
  • backend ibm_fez;
  • Fire Opal action 2335848.

Het Fire Opal-dashboard rapporteerde 26 quantumseconden voor deze taak. Dat is opvallend kort voor 192 circuits op zestig qubits. Het gearchiveerde get_result-antwoord bevatte dit veld niet; daarom vermelden we expliciet dat 26 seconden de dashboardmeting is.

Training-only selectie en blinde test

Binnen de trainingsset koos de quantumroute via cross-validation een RBF-SVC met C=10 en gamma=0,1. De gemiddelde training-only CV-score was 0,59375; de slechtste fold bleef op 0,50000. Pas daarna is één keer op de 32 afgeschermde testcellen geëvalueerd.

Op die test scoorde hardware 17/32, de lineaire baseline 16/32 en de RBF-baseline 14/32. Dat verschil van één cel ten opzichte van de sterkste baseline is klein, maar de richting is voor het eerst positief op echte hardware.

Waarom ook de doorlooptijd interessant is

De eigenlijke quantumtaak duurde volgens het Fire Opal-dashboard slechts 26 seconden. Van indiening tot volledig opgehaald resultaat verstreken ongeveer 8 minuten en 33 seconden; daarin zitten ook orchestratie, compilatie, wachttijd en retrieval. De lokale MPS-controle van exact dezelfde 60-qubitrepresentatie liep 42 minuten en 57 seconden en was toen nog niet geconvergeerd: bond dimension 64 was voltooid, maar bij 128 was slechts één van acht benodigde delen klaar.

Voor dezelfde gespecificeerde 627-featuretarget is 2.577 seconden gedeeld door 26 seconden gelijk aan 99,1. Omdat MPS toen nog niet klaar was, is meer dan 99,1× een gemeten lokale ondergrens voor de kernel-tijdseparatie. Als we de volledige Fire Opal-route van 513 seconden gebruiken, blijft de ondergrens meer dan 5,0×.

Dit is dus een lokale time-to-feature-generation advantage binnen de gedeclareerde resources. Het is nadrukkelijk geen end-to-end tijdvoordeel tegenover gewone klassieke ML: de lineaire en RBF-modellen kunnen rechtstreeks op klassiek voorbereide data worden getraind zonder het 60-qubitcircuit te simuleren. Ook convergeerde MPS niet, zodat geen gematchte numerieke featurefout beschikbaar is.

Statistische grens van dit resultaat

Met 32 testcellen is één fout gelijk aan 3,125 procentpunt. De tweezijdige exacte McNemar-p-waarde tegenover de sterkste lineaire baseline is 1,0. Het 95%-bootstrapinterval voor hardware minus lineair loopt van -0,1875 tot +0,25. Een klassiek voordeel, gelijkspel en hardwarevoordeel blijven dus allemaal verenigbaar met deze kleine steekproef.

We melden het tijdresultaat daarom als een taakgebonden lokale quantum advantage voor featuregeneratie, met een gemeten ondergrens van 99,1× op kerneltijd en 5,0× inclusief retrieval. De voorspellende 17/32-score blijft door de kleine test een empirische aanwijzing, niet bewezen algemene quantum advantage.

De volgende beslispoort

De volgende wetenschappelijke stap is niet automatisch meer quantumtijd gebruiken. Eerst moeten we het ontwerp bevriezen en de volledige klassieke frontier voor een grotere 256/256-split vastleggen. Een grote hardwarefase zou 1.536 circuits van 128 shots vergen en krijgt alleen afzonderlijke toestemming wanneer de extra informatiewaarde opweegt tegen het Fire Opal-budget.

Bronnen en reproduceerbaarheid

  • 60-qubit modulepipeline
  • Fire Opal-pilotrunner
  • 60-qubit runbook
  • Vermelding in de Pro Student Quantum Advantage List
  • QOS-paper
  • Volledige repository
Nederlands | English | Projectpagina | Vorig deel | Volgend deel | QOS paper | Officiële code | Hardwarecode

Recent Posts

  • Quantum computing-nieuws — 10 augustus 2026
  • Quantum computing-nieuws — 9 augustus 2026
  • Quantum computing-nieuws — 8 augustus 2026
  • Quantum computing-nieuws — 7 augustus 2026
  • Quantum computing-nieuws — 6 augustus 2026

Recent Comments

No comments to show.

Archives

  • August 2026
  • July 2026
  • May 2026
  • March 2026
  • February 2026
  • September 2024

Categories

  • 10
  • Quantum Computing
  • Uncategorized
©2026 Edukaizen | Theme by SuperbThemes