Preprint aus Jülich: Fehlerkorrektur-Bausteine auf 10 Quantenrechnern im Test – noch keine Fehlerkorrektur

98 Qubits. 91 davon für Daten. Bleiben sieben. Rechnen wir nach – die Rechnung selbst folgt weiter unten, hier nur die Ansage: Sie entscheidet darüber, was eine Studie aus Jülich über die Fehlerkorrektur auf aktuellen Quantencomputern wirklich aussagt und was nicht. Denn ein Benchmark, der keine Fehler beseitigt, wird gern wie ein Beleg dafür gelesen, dass genau das längst gelingt.

Am Montag, dem 5. Oktober, haben J. A. Montañez-Barrera und Kristel Michielsen vom Jülich Supercomputing Centre im Forschungszentrum Jülich den Preprint „Evaluating the performance of QEC primitives on quantum processors at large width and depth“ eingereicht (Preprint auf arXiv, arXiv:2610.05928, 17 Seiten). Es ist ein Messlatten-Paper: Es prüft die Bausteine der Quanten-Fehlerkorrektur, nicht den fertigen fehlerkorrigierenden Quantenrechner.

Die Studie ist ein Preprint auf arXiv und noch nicht von unabhängigen Gutachtenden geprüft; die Faktoren 13 und 8 stammen aus Quantinuums Auswertung, nicht aus dem Paper.

Diese Auswertung hat Quantinuum am Donnerstag, dem 8. Oktober, im eigenen Blog veröffentlicht und die Studie darin als Beleg für die eigene Stärke ausgelegt. Das ist legitim, aber interessengeleitet. Wir bei digital-magazin.de trennen deshalb in diesem Artikel konsequent: Was steht im Preprint? Was sagt der Hersteller? Und was ergibt unsere eigene Rechnung?

Was der Jülich-Benchmark misst – und was nicht

Zunächst die Bausteine. Jede Runde Quanten-Fehlerkorrektur braucht dieselben Zutaten: Hilfs-Qubits (Ancillas), die mit den Daten-Qubits verschränkt werden, dazu Mid-Circuit-Messungen (MCM), also Messungen mitten im Schaltkreis, ohne dass die Rechnung endet. Hinzu kommen Reset, Feed-forward, bei dem ein Messergebnis die folgenden Operationen steuert, und ein Scheduling, das all das in eine Reihenfolge bringt. Laut Preprint werden diese Bausteine meist entweder isoliert bewertet oder über ressourcenhungrige Experimente.

Das Jülicher Team geht einen Mittelweg. Es nutzt LR-QAOA, eine Variante des Quantum Approximate Optimization Algorithm mit linear ansteigenden Winkeln, nicht als Optimierer, sondern als Messinstrument. Ich halte diesen Perspektivwechsel für den eigentlichen Kniff der Arbeit; wie sich QAOA als Werkzeug außerhalb der reinen Optimierung lesen lässt, haben wir bereits an anderer Stelle beschrieben (QAOA als Messinstrument statt Optimierer).

Konkret funktioniert das so: Aus den Prüfstrukturen („Checks“) eines Codes bauen die Autoren einen Hamiltonian. Der Schaltkreis ahmt dann Konnektivität und Messmuster der Syndrom-Extraktion nach – so heißt das Auslesen der Paritätsprüfungen. Heraus kommt ein direktes algorithmisches Signal, die Approximation Ratio r. Sie liegt bei 0,5, wenn die Ausgabe reines Zufallsrauschen ist, und wird besser, je sauberer die Maschine arbeitet. Die Tiefe, also die Zahl der QAOA-Schichten, entspricht laut Preprint der Zahl wiederholter Syndrom-Runden.

Aus dem Abfall von r mit der Tiefe leiten die Autoren einen effektiven Fehler ab und rechnen ihn in eine äquivalente Zwei-Qubit-Depolarisationsrate um, λeff. Der Haken: Laut Autoren sollte λeff nicht als physikalische Fehlerrate einer einzelnen Hardware-Operation interpretiert werden. Es ist ein Sammelwert für alles, was das Signal zerstört.

Und die Fehlerkorrektur selbst? Dazu sind die Autoren eindeutig. Für die Strukturtests schreiben sie, sie nutzten LR-QAOA als vorläufigen, kostengünstigen Test:

„Wir verwenden LR-QAOA als vorläufigen, kostengünstigen Test dafür, wie ein Gerät die eigene Struktur eines QEC-Codes ausführt.“

Montañez-Barrera und Michielsen, arXiv 2610.05928, eigene Übersetzung

Ein r über Zufallsniveau heißt also: Die Struktur wurde mit erkennbarem Signal ausgeführt. Mehr nicht. Zwischen „Struktur läuft“ und „Fehler werden unterdrückt“ liegt ein ganzes Experimentierprogramm. Der Abstract nennt den Sinn der Übung selbst: ein praktischer Benchmark, bevor vollständige Logical-Memory-Experimente laufen.

Zehn Quantenprozessoren, bis zu 2.950 Messungen

Die Breite der Messreihe ist beachtlich. Das Team vergleicht zehn QPUs: von Quantinuum helios-1 und h2-1, von IBM ibm_fez, ibm_marrakesh, ibm_boston, ibm_kingston, ibm_pittsburgh und ibm_phoenix, von IQM iqm_garnet und iqm_emerald. Das sind sechs IBM-, zwei IQM- und zwei Quantinuum-Geräte. Nach Kenntnis der Autoren sind das die einzigen öffentlich verfügbaren QPUs, die ein gewisses Maß an MCM-Implementierung erlauben.

Zwei Zahlen sollten Sie nicht verwechseln. „Bis zu 2.950 MCM-Operationen“ gilt für alle Experimente und bezeichnet den größten Schaltkreis der gesamten Studie. Die Code-Strukturtests (Surface Code, Color Code, qLDPC) kommen auf bis zu 480 MCM-Operationen. Und sie liefen nur auf Helios-1, H2-1 und, für den Surface Code, auf ibm_phoenix, weil nur diese drei laut Preprint zum Zeitpunkt der Auswertung alle nötigen Elemente direkt bereitstellten.

Der Hauptbefund der Autoren ist ein Vergleich innerhalb jeder Plattform, nicht zwischen den Herstellern. Laut Preprint ist die durch MCM verursachte Degradation auf IBM-QPUs derzeit etwa eine Größenordnung größer als bei demselben Protokoll ohne MCM. Auf Quantinuum-QPUs ist die zusätzliche Degradation durch MCM vergleichbar mit jener durch Zwei-Qubit-Gatterfehler. Das ist nicht dasselbe wie „IBM ist zehnmal schlechter als Quantinuum“, und wer es so liest, vergleicht Äpfel mit Birnen: Jede Plattform wird an ihrem eigenen Referenzwert ohne MCM gemessen.

Interessant ist auch Figur 5. Dort wiederholt das Team das MCM-Experiment zu verschiedenen Zeitpunkten. Die ersten beiden Läufe auf Helios-1 waren seriell implementiert; sie nutzten die acht verfügbaren Zonen, in denen Zwei-Qubit-Gatter und MCM gleichzeitig laufen können, nicht aus. Für das in Figur 5 orange markierte Experiment änderten die Autoren die Implementierung und parallelisierten Zwei-Qubit-Gatter und MCM, wo immer möglich; die Leistungsverbesserung sei in den Kurven deutlich sichtbar, schreiben sie. Der Benchmark misst demnach die Hardware und zugleich die Implementierungsqualität. Die Autoren sehen darin zwei Fähigkeiten: Er reagiert auf Verbesserungen am System ebenso wie auf Verbesserungen bei Scheduling und Umsetzung.

Bei IBM fällt ein Detail auf. Bis ibm_boston haben neuere Generationen laut Preprint tendenziell niedrigere effektive Fehlerraten. Dann kommt die Square-Lattice-Topologie der Nighthawk-Architektur. Die geänderte Konnektivität und das veränderte Mapping können laut Autoren zum größeren λeff beim neuesten Gerät beitragen, was einen direkten Vergleich mit den Vorgängern weniger einfach macht (mehr zur Architektur: IBM Quantum Nighthawk). Man liest hier also einen Hinweis auf einen Mapping-Effekt, keinen Beleg für schlechtere Qubits.

Ist das alles nur Messtechnik? Ja, und das ist kein Makel.

98 Qubits, 91 für Daten – rechnen wir nach

Die 91 ist im Preprint des Jülicher Teams keine Prahlzahl, sondern eine Zumutung für die Maschine. Der triangulare Color Code mit Distanz d = 11 braucht 91 Daten-Qubits. Helios-1 hat laut Preprint 98 physische Qubits. Rechnen wir nach: 98 − 91 = 7. Für die Prüfmessungen bleiben also sieben Hilfs-Qubits, rund 7 Prozent der Maschine. Hilfs-Qubits (Ancillas) lesen die Paritätsprüfungen aus, ohne die Daten selbst zu messen.

Montañez-Barrera und Michielsen beschreiben die Folge in Abschnitt D, den wir hier wörtlich übersetzen:

„Bei d = 11 lassen die 91 Daten-Qubits nur 7 der 98 physischen Qubits der Maschine als Ancillas übrig, sodass die 45 Ancilla-Messungen pro Schicht auf neun Batches mit höchstens sieben Checks verteilt werden müssen, statt auf die drei disjunkten Messklassen, die die Code-Struktur erlaubt.“

Montañez-Barrera und Michielsen, arXiv 2610.05928, eigene Übersetzung

Unsere Rechnung dazu: neun statt drei Messabschnitte pro Schicht, also dreimal so viele (9 ÷ 3). Die Batch-Zahl selbst hängt an der Überlappung der Checks, die rechnen wir nicht nach. Das Preprint nennt die Zahl, wir übernehmen sie.

Und das Ergebnis? Laut Preprint liegt der Color Code von d = 3 bis d = 11 deutlich über dem Zufallsniveau von r = 0,5. Die Approximation Ratio r misst, wie nahe die gemessenen Bitstrings an der besten Lösung liegen. Sie beträgt r = 0,926 bei d = 3 und r = 0,733 bei d = 11, das sind 8,1σ über Zufall bei nur 10 Shots. Ein Shot ist ein einzelner Schaltkreisdurchlauf.

Wichtig ist, was das nicht heißt. Hier wird keine Fehlerkorrektur ausgeführt. Der Test bildet die Prüfstruktur nach, und ein r über Zufall besagt: Die Struktur lief mit Signal durch. Die Autoren nennen das einen „QEC-Readiness-Benchmark“ und im Abschnitt D einen „vorläufigen, günstigen Test“. Ihr Quantenrechner hat dabei keinen einzigen Fehler behoben.

Surface Code und BB48: Engpass Code oder Engpass Maschine?

Der Surface Code läuft laut Preprint ähnlich: r = 0,752 bei d = 5 und r = 0,737 bei d = 9, also bei 81 Daten-Qubits, 19,0σ über Zufall mit 20 Shots. Er braucht 80 Checks pro Schicht, lässt aber 17 Qubits als Ancillas frei. Sieben Batches genügen, das Signal bleibt stark.

Zum Vergleich: Der bivariate-bicycle-qLDPC-Code BB48 lässt laut Preprint „50 Qubits frei“. Trotzdem braucht eine Schicht sieben Batches mit höchstens acht Checks, weil sich die Checks so stark überlappen. Das Jülicher Team nennt das eine Serialisierung, die der Code vorgibt und nicht die Maschine. Beim Color Code bremst also die Qubit-Zahl, beim BB48 die Struktur. Lesende, die Hardware-Roadmaps prüfen, sollten diese Unterscheidung kennen. Wer nur „mehr Qubits“ verlangt, löst das zweite Problem nicht.

Die Grafik zeigt die größte getestete Code-Struktur je Code-Familie laut Preprint – ein Readiness-Test, keine Fehlerkorrektur. Wir bei digital-magazin.de halten diesen Satz bewusst direkt unter der Grafik fest, weil Balken gern als Leistungsbalken gelesen werden.

13-fach und 8-fach – Quantinuums Lesart

Drei Tage nach dem Preprint, am 8. Oktober, kam der Blog von Quantinuum. Schon der Titel nennt die Studie „independent“. Das ist Quantinuums Wort, nicht das der Autoren. Im Vorspann spricht Quantinuum von „approximately 10x“ und von einem „approximately order-of-magnitude advantage“. Im Text folgen die präziseren Zahlen: Laut Quantinuum ist der effektive Fehler „approximately 13 times lower at 30 data qubits and eight times lower at 50 data qubits than the comparable superconducting result“.

Der Haken: Im Preprint steht weder ein Faktor 13 noch ein Faktor 8. Die Zahlen gehören zum Kettentest, also zu eindimensionalen Ketten mit 30 bzw. 50 Qubits (im Paper: Kettenlänge Nq). Mit den Code-Strukturen von 81, 91 und 48 Daten-Qubits haben sie nichts zu tun. Welches supraleitende Gerät die Vergleichsbasis ist, sagt Quantinuum nicht. Der Vorspann-Wert „etwa 10x“ und die Werte 13 und 8 sind außerdem drei verschiedene Aussagen, die man nicht ineinander umrechnen sollte.

Quantinuums Faktoren sind also ein Plattformvergleich, der Hauptbefund der Autoren ist ein Vergleich innerhalb jeder Plattform.

Quantinuum argumentiert zudem, Quantinuum-Geräte könnten drei Code-Familien ausführen, Supraleiter nur eine. Das ist Quantinuums Aussage. Das Preprint bestätigt, dass die Strukturtests nur auf Helios-1, H2-1 und ibm_phoenix liefen. Zur Konnektivitätsgrenze bei IQM schreiben die Autoren aber zugleich, sie sei „per se“ keine prinzipielle Einschränkung für ein Logical-Memory-Experiment. Eingeschränkt werden demnach adaptive Protokolle, die messungsabhängige Operationen brauchen.

Meine Einschätzung: Quantinuums Lesart ist legitim, aber interessengeleitet. Die Daten gibt es, sie sind öffentlich, und auf diesem Benchmark schneidet die Ionenfalle gut ab. Nur ist ein Blog kein Review, und das Preprint ist es auch nicht. Ihr Quantenvertrieb wird das ungern hören, aber: Ein Faktor ohne benannte Gegenseite ist eine Behauptung, kein Messwert.

Warum der Faktor bei 50 Qubits kleiner ist

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptPhotorealistic photo of a trapped-ion quantum computer optical table with lasers, mirrors and lenses, faint green and blue laser beams visible in the dark, scientific laboratory, no people, no logos, no brand marks, no readable text, no letters, no numbers, no watermarks, 16:9

Hier hilft das Preprint, auch wenn es Quantinuums Faktoren nicht kennt. Für die Messungen auf Helios-1 steigt λeff von 0,22 ± 0,04 Prozent bei 30 auf 0,41 ± 0,05 Prozent bei 50 Qubits, laut Preprint ein Faktor von 1,9. Zur Erinnerung: λeff ist ein Sammelwert, keine physikalische Fehlerrate einer einzelnen Operation.

Ihre Erklärung: Längere Ketten erhöhen λeff, wie es zu erwarten ist, wenn die Schicht teilweise seriell läuft. Helios-1 hat acht Operationszonen und verarbeitet höchstens sechzehn Qubits gleichzeitig. Die Messungen einer Schicht können daher nicht alle auf einmal stattfinden, und die nicht gemessenen Daten-Qubits warten im Leerlauf.

Bei IBM sieht das Bild anders aus. Die MCM-Kosten sind laut Preprint schon bei kleiner Größe hoch und hängen nur schwach von der Problemgröße ab. Über Nq = 10 bis 60 ändern sie sich um 1,2-fach auf ibm_kingston, 1,5-fach auf ibm_fez und höchstens 2,3-fach auf ibm_boston.

Nun zu Quantinuums Zahlen, rechnerisch, unsere Rechnung: Quantinuum nennt 13-fach bei 30 und 8-fach bei 50 Qubits. Das ergibt 13 ÷ 8 ≈ 1,6, und 1 − 8/13 ≈ 38 Prozent: Der von Quantinuum genannte Faktor ist bei 50 Qubits rund 38 Prozent kleiner als bei 30. Im Preprint selbst liegt der absolute Anstieg bei 0,41 − 0,22 = 0,19 Prozentpunkten. Sieht man sich beide Verläufe an, passt das zusammen: Wenn die Gegenseite fast flach bleibt und Helios-1 mit der Kettenlänge wächst, muss ein Verhältnis kleiner werden. Das ist unsere Lesart, kein Satz aus dem Preprint, und welche Supraleiter-Kurve Quantinuum meint, bleibt offen.

Zum Vergleich: Bei Nq = 30 messen die Autoren auf H2-1 λeff = 0,49 ± 0,24 Prozent, auf Helios-1 0,22 ± 0,04 Prozent. Die Mittelwerte zeigen eine Verbesserung. Die Unsicherheit sei „for this measurement alone“ aber zu groß, um sie eindeutig zu belegen, schreiben die Autoren. Ihre Vorsicht ist hier angebracht.

Unter dem Strich liefert das Jülicher Team eine billige Messlatte, keinen Wettbewerbsentscheid. Wer sie nutzt, sollte Faktoren immer mit Basis lesen. Wo liegt die Basis, auf welcher Kettenlänge, auf welchem Gerät? Fehlt eine dieser Angaben, ist die Zahl nicht prüfbar.

ibm_phoenix: die Brücke zur logischen Ebene

Bisher ging es um Signale, die ein Benchmark liefert, etwa bei den Strukturtests mit den 91 Daten-Qubits. Ob dieses Signal etwas über echte Fehlerkorrektur aussagt, prüft das Preprint nur an einer Stelle. Und nur auf einem Gerät: ibm_phoenix.

Montañez-Barrera und Michielsen führen dort Surface-Code-Speicher mit Distanz d = 3 aus, verteilt auf 11 Patches. So heißen die Chipbereiche, auf denen je ein kleiner Code-Flicken sitzt. Bei einem solchen Logical-Memory-Experiment wird ein Zustand über mehrere Runden Syndrom-Extraktion gehalten und anschließend dekodiert. Im selben Zeitfenster läuft auf denselben Patches der LR-QAOA-Benchmark. Das Ganze wiederholt sich über 12 Sessions innerhalb einer Woche.

Verglichen wird per Rangkorrelation (Spearman, ρs). Sie fragt nicht, ob zwei Zahlenreihen gleich groß sind, sondern ob sie die Patches in ähnlicher Reihenfolge sortieren. Laut Preprint zeigen Chipregionen mit besserem LR-QAOA-Ergebnis in der Regel eine geringere logische Fehlerwahrscheinlichkeit. Die stärkste Korrelation erreicht |ρs| = 0,88 bei d = 3. Das ist die einzige Brücke zwischen Benchmark und Logical Memory, die das Papier baut.

„Diese Entsprechung bedeutet nicht, dass LR-QAOA alle Aspekte der QEC-Leistung erfasst.“

Montañez-Barrera und Michielsen, arXiv 2610.05928, eigene Übersetzung

Die Begründung liefern die beiden gleich mit. Das Memory-Experiment verschränkt X- und Z-Checks, bildet Detektoren über mehrere Runden und stützt sich auf einen Dekodierer. Der Benchmark wertet dagegen vertauschbare Checks in einem einzigen Bezugssystem aus. Außerdem sind die Ergebnisse auf d = 3 und ein Gerät beschränkt. Im Schlussabschnitt schränken die Autoren ebenfalls ein, der Satz bricht im Preprint allerdings mitten ab. Das ist ein kleiner Schönheitsfehler, aber an der Aussage ändert er nichts.

Ich halte 0,88 bei elf Patches für ein ermutigendes, aber dünnes Indiz. Wie viel trägt eine Rangfolge aus elf Elementen? Genug, um den Benchmark ernst zu nehmen. Zu wenig, um ihn als Ersatz für das Experiment zu behandeln, das er vorbereiten soll.

Konkret leistet ein Readiness-Test also eine Vorauswahl: Er zeigt, ob eine Struktur überhaupt noch Signal trägt, bevor teure Läufe starten. Ersetzen kann er die Validierung auf logischer Ebene nicht. Wer dazu das Prinzip an anderer Stelle nachlesen möchte: Dieser Beitrag behandelt, warum ein Speedup-Befund die Prüfung auf logischer Ebene nicht überflüssig macht. Für Benchmarks gilt dasselbe.

Was ein Preprint (noch) nicht ist

Das Papier ist die Version 1 eines arXiv-Preprints vom 5. Oktober. Es ist nicht begutachtet. Ein Journal, ein Review-Datum oder eine Revision ist im Preprint nicht angegeben, davon ist bislang nichts bekannt. Gutachtende haben die Methode noch nicht geprüft, auch wenn sie in sich schlüssig wirkt.

Ein Gegengewicht gibt es: Laut Abschnitt „Data availability“ sind alle Problem-Instanzen und der Code zur Reproduktion öffentlich. Das Repository enthält laut Preprint diese Instanzen und den Code. Mehr sage ich über seinen Inhalt nicht, denn nachgeprüft haben wir ihn nicht. Der Weg dorthin ist aber gelegt, und das ist bei Herstellerblogs selten.

Zur Transparenz gehört auch der Zugang. Die Danksagung nennt für Montañez-Barrera die Projekte JUNIQ, gefördert vom Bundesministerium für Forschung, Technologie und Raumfahrt (BMFTR) und vom Wissenschaftsministerium NRW, sowie EPIQ (MKW NRW). Die Quantinuum-Experimente liefen über die Oak Ridge Leadership Computing Facility. Die IQM-Geräte nutzte das Team über Amazon-Braket-Credits von AWS, die IBM-Geräte über IBM Quantum Credits. Den Satz, dass die geäußerten Ansichten die der Autoren seien und nicht die von IBM, liefert das Preprint selbst. Eine Befangenheit folgt aus keiner dieser Angaben. Lesende sollten sie dennoch kennen.

Quantinuum überschreibt seinen Blogbeitrag mit „Independent Study“; „independent“ ist dort Quantinuums Wort. Das Preprint selbst spricht von „independent institutions“ in einem anderen Sinn: Gemeint sind Institutionen ohne eigene große Rechenressourcen, die prüfen wollen, ob ein Hersteller seiner Roadmap folgt.

Was das für Roadmaps heißt

Das Preprint sieht seinen Wert dort, wo er billig ist. Die Konstruktion und der geringe Ressourcenbedarf lieferten laut Abstract einen „practical benchmark for comparing hardware generations and QEC implementations before full logical-memory experiments are performed“. Auf Deutsch: eine praktische Messlatte für den Vergleich von Hardware-Generationen und Fehlerkorrektur-Implementierungen, bevor vollständige Logical-Memory-Experimente laufen.

Für Forschende, Technik- und Förderverantwortliche ist das konkret nützlich. Das Papier regt an, Rekorde zu führen, also die größte Code-Distanz und die Zahl der Code-Instanzen, die ein Gerät ausführen kann. Eine so entstehende Historie könnte zeigen, ob aufeinanderfolgende Generationen zur Roadmap passen. Dasselbe Problem stellt sich bei Förderzielen für fehlerkorrigierte Rechner: Sie brauchen Messlatten, die jemand reproduzieren kann. Wie das in der Praxis aussieht, zeigt der Beitrag zum Wettbewerb um den fehlerkorrigierten Quantenrechner. Einen Zusammenhang zwischen dem Wettbewerb und diesem Preprint behaupten wir nicht. Dass JUNIQ laut Preprint auch aus Bundesmitteln gefördert wird, ist schlicht eine Randnotiz.

Der Haken: Eine Messlatte misst nur, was sie misst. Zum Vergleich: Ein Belastungstest für Brückenpfeiler sagt nichts über die fertige Brücke. Deshalb eine Checkliste für jeden Herstellerclaim, der sich auf eine Studie beruft:

• Auf welcher Basis wird verglichen, und welches Vergleichsgerät steht konkret dahinter, oder bleibt es ungenannt?
• Welches Experiment liegt der Zahl zugrunde, ein Kettentest, ein Strukturtest oder ein dekodiertes Logical-Memory-Experiment?
• Ist die Quelle ein Preprint oder ein begutachteter Artikel, und welche Version liegt vor?
• Misst das Ergebnis die Hardware oder auch die Qualität der Implementierung, etwa durch seriellen oder parallelen Ablauf?
• Sind Rohdaten und Code öffentlich, sodass Dritte die Zahl nachrechnen können?

Keine dieser Fragen ist eine Anlageempfehlung, und keine unterstellt Absicht. Sie sind Handwerkszeug.

Was bleibt?

Ein gutes Werkzeug aus Jülich, ein selbstbewusster Hersteller und eine Aufgabe für alle, die lesen: beides auseinanderzuhalten. Das Jülicher Team liefert eine billige, reproduzierbare Messlatte mit offenem Code und benennt ihre Grenzen selbst. Quantinuum liefert eine legitime, aber interessengeleitete Lesart derselben Studie. Das Preprint enthält diese Lesart nicht.

Wir bei digital-magazin.de halten es deshalb mit der einfachsten Regel: Zahl, Basis, Quelle, in dieser Reihenfolge. Die 91 Daten-Qubits sind ein Belastungstest für Bausteine, nicht der fertige fehlerkorrigierte Quantencomputer. Das ist keine Enttäuschung. Es ist ein Werkzeug, bevor die teuren Experimente beginnen.

Bleibt eine Frage, die über dieses Preprint hinausreicht. Legen Herstellende ihre Rohdaten so offen wie das Jülicher Team?