TuniQ: Autotuning Compilation Passes for Quantum Workloads at Scale for Effectiveness and Efficiency

TuniQ ist ein auf Reinforcement Learning basierendes System, das basierend auf spezifischen Hardware- und Rauschbedingungen dynamisch optimale Kompilierungspässe für Quantenschaltkreise auswählt und damit die Ausgabe-Genauigkeit sowie die Kompilierungseffizienz im Vergleich zu fortschrittlichen statischen Kompilatoren wie dem Qiskit-Transpiler von IBM erheblich verbessert.

Das Wesentliche

Stellen Sie sich vor, Sie versuchen, eine empfindliche, komplexe Nachricht über eine sehr laute, holprige Straße zu senden. Die Nachricht ist ein Quantenprogramm (eine Reihe von Anweisungen für einen Quantencomputer), und die Straße ist die Quantenhardware.

Das Problem ist, dass die Straße voller Schlaglöcher (Fehler) ist und die Nachricht mit der Zeit, die sie unterwegs ist, an Qualität verliert. Wenn Sie einen langen, verschlungenen Weg wählen, könnte Ihre Nachricht verzerrt ankommen. Wenn Sie einen schnellen Weg wählen, aber zu viele Schlaglöcher treffen, kommt sie ebenfalls verzerrt an.

Derzeit verwenden die „Fahrer" (die Compiler), die diese Nachrichten senden, ein festes Regelwerk. Sie weisen jeder einzelnen Nachricht an, exakt denselben Weg zu nehmen, unabhängig davon, ob die Nachricht einfach oder komplex ist oder ob die Straße derzeit trocken oder schlammig ist. Manchmal funktioniert dies, aber oft ist es ineffizient und führt zu einer langsamen Zustellung oder einer beschädigten Nachricht.

TuniQ ist ein neuer, intelligenter Fahrer, der die Regeln ändert. Anstatt einer festen Karte zu folgen, verwendet es Reinforcement Learning (eine Art von KI, die durch Versuch und Irrtum lernt), um in Echtzeit die beste Route für jede einzelne Nachricht zu entscheiden.

So funktioniert TuniQ, aufgeteilt in einfache Konzepte:

1. Das „feste Regelwerk" vs. der „intelligente Fahrer"

Stellen Sie sich das aktuelle System (IBM Qiskit) wie ein Navi vor, das jedes Auto zwingt, dieselbe Autobahn zu nehmen, selbst wenn für ein bestimmtes Auto eine Abkürzung existiert. Es wendet denselben Satz von „Optimierungspassagen" (Verkehrsregeln) auf jede Quantenschaltung an.

• Der Fehler: Eine Abkürzung, die Zeit für ein kleines Auto spart, könnte für einen großen LKW einen Stau verursachen. Ebenso kann eine Compiler-Einstellung, die einem Quantenprogramm hilft, ein anderes tatsächlich schädigen.
• Die TuniQ-Lösung: TuniQ ist wie ein Fahrer, der die spezifische Fracht (die Schaltung) betrachtet, das aktuelle Wetter und die Straßenverhältnisse (die Rauschpegel der Hardware) prüft und dann entscheidet: „Muss ich die malerische Route nehmen, um ein Schlagloch zu vermeiden? Oder sollte ich Gas geben, weil die Straße frei ist?" Es wählt aus, welche „Verkehrsregeln" für diese spezifische Fahrt angewendet und welche übersprungen werden sollen.

2. Der „Dual-Encoder" (Die zwei Augenpaare des Fahrers)

Um diese Entscheidungen zu treffen, muss TuniQ die Welt in verschiedenen Phasen der Fahrt unterschiedlich sehen. Die Arbeit beschreibt ein Dual-Encoder-System:

• Vor der Straße (Logische Sicht): Am Anfang betrachtet der Fahrer den Plan der Fahrt. Er sieht die logischen Verbindungen zwischen den Passagieren (Qubits), ohne sich noch um die spezifischen Schlaglöcher zu kümmern. Er fragt: „Wie müssen diese Personen zusammensitzen?"
• Auf der Straße (Physikalische Sicht): Sobald das Auto auf der Straße ist, schaltet der Fahrer auf ein anderes Augenpaar um. Jetzt betrachtet er das tatsächliche Auto und die tatsächlichen Straßenverhältnisse. Er sieht, welche spezifischen Reifen (physikalische Qubits) sich abnutzen und welche Teile der Straße holprig sind.
• Warum das wichtig ist: Dies ermöglicht TuniQ, sich anzupassen. Wenn die Straße schlammiger wird (das Rauschen zunimmt), kann es sofort auf eine sicherere, langsamere Route wechseln, ohne neu trainiert werden zu müssen.

3. Die „geformten Belohnungen" (Lernen aus der Reise)

Auf die alte Weise erhielt der Fahrer erst am Ende Feedback: „Haben Sie die Nachricht zugestellt?" Wenn die Nachricht beschädigt war, wusste der Fahrer nicht, welche Kurve das Problem verursacht hatte.

• Der Ansatz von TuniQ: TuniQ erhält unterwegs kleine „Punkte" (Belohnungen).
  • „Gut gemacht, dass du dieses Schlagloch vermieden hast!" (Zwischenbelohnung).
  • „Toll gemacht, dass du das Auto stabil gehalten hast!" (Eine weitere Zwischenbelohnung).
  • „Du hast die Nachricht perfekt zugestellt!" (Endbelohnung).
    Dies hilft dem Fahrer zu lernen, dass eine bestimmte Kurve zu Beginn der Fahrt entscheidend für den Erfolg der gesamten Reise war, auch wenn das Ergebnis erst am Ende sichtbar wurde.

4. Die „dynamische Maske" (Der Sicherheitswächter)

Man kann einem Fahrer nicht einfach erlauben, jede Straße zu wählen; einige Straßen sind Sackgassen oder illegal.

• TuniQ verwendet Dynamic Action Masking (dynamische Aktionsmaskierung). Stellen Sie sich dies als Leitplanke vor, die den Fahrer sofort daran hindert, eine Kurve zu nehmen, die das Auto beschädigen oder gegen Verkehrsregeln verstoßen würde. Es stellt sicher, dass das Endergebnis unabhängig davon, was die KI entscheidet, immer ein gültiger, befahrbarer Pfad ist.

Die Ergebnisse: Schneller und klarer

Die Arbeit testete TuniQ auf echten Quantencomputern von IBM. Hier ist, was passierte:

• Bessere Qualität: Die Nachrichten kamen viel klarer an. Im Durchschnitt verbesserte sich die „Fidelität" (wie stark die Nachricht dem ursprünglichen Plan entsprach) um 20 %.
• Schnellere Zustellung: Die Zeit, die für die Routenplanung (Kompilierungszeit) benötigt wurde, sank um 34 %. Das ist enorm, da viele Quantenalgorithmen ihre Route Tausende von Malen hintereinander planen müssen.
• Kein Neulernen erforderlich: Wenn Sie den Fahrer in eine andere Stadt versetzen (einen anderen Quantencomputer), funktioniert TuniQ sofort, ohne dass er die neue Stadt von Grund auf neu lernen muss.
• Skalierbarkeit: Je größer und komplexer die Nachrichten werden (Utility-Scale-Schaltungen), desto besser wird TuniQ im Vergleich zu den alten festen Regelwerken.

Zusammenfassung

TuniQ ist wie der Upgrade von einem starren, „one-size-fits-all"-Navi zu einem intelligenten, adaptiven Co-Piloten. Es betrachtet die spezifische Fracht, prüft die Echtzeit-Straßenverhältnisse und lernt aus jeder Fahrt, um die perfekte Mischung aus Geschwindigkeit und Sicherheit zu wählen. Dies macht Quantencomputing zuverlässiger und schneller, besonders wenn wir versuchen, in Zukunft größere Probleme zu lösen.

Technische Zusammenfassung

Technische Zusammenfassung: TuniQ

Problemstellung

Quantenprozessoren werden zunehmend als Co-Prozessoren in High-Performance-Computing (HPC)-Ökosysteme integriert, wobei Quantenschaltungen als Kernel fungieren, die von klassischen Knoten aus dispatched werden. Aktuelle Quantencompiler, wie der Qiskit-Transpiler von IBM, verlassen sich jedoch auf eine festgelegte Sequenz von Kompilierungspässen, die einheitlich auf alle Schaltungen angewendet wird. Dieser „Einheitslösungs"-Ansatz berücksichtigt drei kritische Variablen nicht:

1. Schaltungsstruktur: Unterschiedliche Algorithmen (z. B. QPE, VQE, Grover) weisen unterschiedliche Topologien und Gatterzusammensetzungen auf, die von verschiedenen Optimierungsstrategien profitieren.
2. Hardware-Backends: Quantengeräte variieren in ihren Kopplungstopologien, nativen Gattersätzen und Fehlerprofilen.
3. Rauschbedingungen: Kalibrierungsdaten (Gatterfehler, Kohärenzzeiten $T_1/T_2$) driftieren auf einem einzelnen Gerät über die Zeit.

Eine feste Passsequenz wendet oft unnötige Optimierungen an, die die Schaltungstiefe oder die Gatteranzahl erhöhen, wodurch mehr Rauschen akkumuliert und die Ausgangsfidelity (gemessen durch die Total Variation Distance, TVD) verringert wird. Umgekehrt können vorteilhafte Pässe für spezifische Schaltungsstrukturen übersprungen werden. Darüber hinaus ist eine erschöpfende Suche über die Millionen möglichen Passkombinationen rechnerisch nicht handhabbar, und eine gierige Optimierung pro Stufe führt häufig zu global suboptimalen Ergebnissen, da frühe Entscheidungen spätere Stufen einschränken.

Methodik: TuniQ

TuniQ ist ein auf Reinforcement Learning (RL) basierendes System, das entwickelt wurde, um Kompilierungspässe adaptiv in jeder Stufe der Transpilierungspipeline auszuwählen. Es formuliert die Passauswahl als Markov-Entscheidungsprozess (MDP), bei dem ein Agent lernt, die Schaltungsfidelity zu maximieren und gleichzeitig die Kompilierungszeit zu minimieren.

Kernkomponenten

1. Dual-Encoder-Architektur:

   • Pre-Layout-Encoder: Kodiert die logische Schaltungsstruktur (räumlich-zeitliche Gatterinteraktionen) vor dem Hardware-Mapping.
   • Post-Layout-Encoder: Kodiert die an die physikalische Hardware gebundene Schaltung und integriert Echtzeit-Rauschmerkmale (Fehlerraten, Kohärenzzeiten) aus der Backend-Kalibrierung.
   • Diese Trennung ermöglicht es dem Agenten, stufenspezifische Strategien zu erlernen: Layout-/Routing-Entscheidungen basierend auf der logischen Struktur und Optimierungsentscheidungen basierend auf physikalischen Rauschprofilen.

2. Zustandsraum:

   • Enthält einen One-Hot-Stufenindikator (Init, Layout, Routing, Translate, Optimize, Cleanup).
   • Schaltungsmerkmale, dargestellt als Tensoren (logische Qubits vor dem Layout, physikalische Qubits nach dem Layout).
   • Globale Merkmale, einschließlich Gatteranzahl, Tiefe und Verhältnissen der Topologie-Kompatibilität.

3. Aktionsraum & Dynamisches Maskieren:

   • Der Agent wählt in jeder Stufe spezifische Transpiler-Pässe oder eine „Überspringen"-Aktion aus.
   • Dynamisches Action Masking erzwingt gültige Kompilierungssequenzen. Es verhindert ungültige Übergänge (z. B. das Überspringen des Routings vor dem Layout) und stellt sicher, dass Hardwarebeschränkungen eingehalten werden, wodurch garantiert wird, dass jede abgeschlossene Episode eine ausführbare Schaltung erzeugt.

4. Belohnungsstruktur:

   • Geformte Belohnungen: Um das Kreditverteilungsproblem über mehrere Stufen hinweg zu adressieren, verwendet TuniQ intermediate Belohnungen basierend auf einer Transpilierungsqualität (TQ)-Metrik. Diese Metrik schätzt die Erfolgswahrscheinlichkeit (ESP) unter Verwendung von Gatterfehlerraten und Schaltungstiefe ab und passt sich an, während die Schaltung von der logischen zur physikalischen Darstellung übergeht.
   • Endbelohnung: Nach Abschluss erhält der Agent eine Belohnung basierend auf dem Logarithmus-Verhältnis der erreichten ESP gegenüber einer Qiskit-Level-3-Baseline (Fidelity Optimized), kombiniert mit Hilfsgrößen für die Reduktion der Gatteranzahl und der Tiefe.

5. Training & Inferenz:

   • Training: Verwendet Maskable PPO (Proximal Policy Optimization) auf zufälligen Schaltungen und gestörten Backend-Rauschprofilen, um Robustheit zu gewährleisten.
   • Inferenz: Die Policy wird eingefroren. Das System führt einen einzigen Vorwärtsdurchlauf durch, um Pässe auszuwählen, und fügt einen vernachlässigbaren Overhead hinzu (<1 % der gesamten Kompilierungszeit). Während der Inferenz wird keine Referenzkompilierung oder Belohnungsberechnung durchgeführt.

Hauptbeiträge

1. Erster Rausch-konditionierter Cross-Stage-Selector: TuniQ ist das erste System, das die Transpilierung als einheitliches Cross-Stage-Pass-Auswahlproblem formuliert, das an Echtzeit-Rauschprofile konditioniert ist und gleichzeitig Fidelity und Kompilierungszeit optimiert.
2. Neuartige RL-Erweiterungen: Die Arbeit führt einen Dual-Encoder für stufenbewusste Repräsentation, geformte Belohnungen für die Cross-Stage-Kreditverteilung und dynamisches Action Masking zur Garantie gültiger Kompilierung ein.
3. Skalierbarkeit und Generalisierung: Das System wird auf kleinen Schaltungsinstanzen (5–10 Qubits) trainiert, skaliert jedoch effektiv auf nutzungsskalige Schaltungen (bis zu 65 Qubits) ohne Nachtraining. Es generalisiert in einer Zero-Shot-Manner über verschiedene IBM-Quantum-Backends (Torino, Fez, Kingston, Pittsburgh).
4. Open Source: Das Framework und die Implementierung sind Open-Source, um die Adoption durch die Community zu erleichtern.

Experimentelle Ergebnisse

Evaluiert an diversen Workloads (MQTBench, QASMBench) über mehrere IBM-Quantum-Cloud-Prozessoren:

• Fidelity-Verbesserung: TuniQ verbessert die Ausgangsfidelity (reduziert TVD) im Durchschnitt um 20 % im Vergleich zum state-of-the-art Qiskit-Transpiler (Fidelity Optimized). Für spezifische Benchmarks wie QPE wurde TVD von 0,76 auf 0,50 reduziert, was den algorithmischen Erfolg signifikant verbessert.
• Kompilierungszeit: TuniQ reduziert die Kompilierungszeit im Durchschnitt um 34 %. Dies ist kritisch für variationale Algorithmen (z. B. VQE, QAOA), die Schaltungen tausende Male neu kompilieren.
• Skalierung: Mit zunehmender Schaltungsgröße (bis zu 65 Qubits) wächst der Vorteil von TuniQ; es erzeugt Schaltungen mit 40 % weniger Gattern und 50 % geringerer Tiefe als die Baseline.
• Robustheit: Das System behält seine Wirksamkeit über verschiedene Rauschniveaus (simuliert durch Skalierung der Fehlerraten) und verschiedene Hardware-Generationen (Heron R1–R3) bei und demonstriert Resilienz gegenüber Kalibrierungsdrift.

Bedeutung und Behauptungen

Die Arbeit behauptet, dass TuniQ eine fundamentale Einschränkung aktueller Quantenkompilierung adressiert: die Abhängigkeit von statischen, festen Passsequenzen. Durch den Wechsel zu einem adaptiven, gelernten Ansatz zeigt TuniQ, dass die optimale Passauswahl stark kontextabhängig von der Schaltung, der Hardware und der Rauschumgebung ist.

Die Autoren betonen, dass TuniQ nicht nur eine einzelne Metrik verbessert, sondern einen besseren Qualitäts-Zeit-Tradeoff bietet. Im Gegensatz zu suchbasierten Methoden (z. B. evolutionäre Algorithmen), die einen hohen Overhead pro Schaltung verursachen, amortisiert TuniQ die Suchkosten während des Trainings, was es für HPC-Workflows geeignet macht, bei denen der Durchsatz entscheidend ist. Die Arbeit legt nahe, dass, wie sich die Quantenhardware in Richtung Fehlertoleranz entwickelt, adaptive Kompilierung ein entscheidender Leistungshebel bleiben wird, und TuniQ bietet ein skalierbares Framework zur Realisierung dieses Potenzials.