QuPort: Topology-, Port-, and Congestion-Aware Compilation for Modular Multi-QPU Quantum Systems

Dieser Beitrag stellt QuPort vor, einen Kompilierungsrahmen für modulare Multi-QPU-Systeme, der ein dreistufiges Modell und den TPCCAP-Algorithmus einsetzt, um Qubit-Mapping, Port-Zuweisung und Interconnect-Überlastung gemeinsam zu optimieren und dadurch den Cross-QPU-Datenverkehr sowie Kommunikationsengpässe zu minimieren.

Das Wesentliche

Stellen Sie sich vor, Sie versuchen, eine riesige, komplexe Party zu organisieren, bei der die Gäste „Quantenbits" (Qubits) sind und die Räume, in denen sie sich aufhalten, kleine, separate Quantencomputer namens QPUs sind.

In früheren Zeiten befanden sich alle Gäste in einem einzigen riesigen Ballsaal. Die Aufgabe des „Partyplaners" (des Compilers) bestand lediglich darin, sicherzustellen, dass Gäste, die miteinander sprechen mussten, nebeneinander standen. Wenn dies nicht der Fall war, musste der Planer die Leute umordnen (ein Prozess namens „Routing"), bis sie sich unterhalten konnten.

Doch nun bauen wir modulare Quantencomputer. Anstelle eines einzigen riesigen Ballsaals haben wir ein Gebäude mit vielen kleinen, separaten Räumen (QPUs). Einige Räume sind durch Flure verbunden, doch diese Flure sind eng und teuer in der Nutzung.

Dieser Artikel stellt einen neuen Partyplaner namens QuPort vor. So funktioniert er, unter Verwendung einfacher Analogien:

1. Die drei Karten

Um die Party zu planen, betrachtet QuPort gleichzeitig drei verschiedene Karten:

• Die Gästeliste (Logischer Graph): Wer muss mit wem sprechen und wie häufig? (Einige Gäste sind beste Freunde und müssen ständig sprechen; andere sagen nur einmal „Hallo".)
• Der Raumplan (Physische Karte): Innerhalb jedes kleinen Raums, welche Stühle stehen nebeneinander?
• Der Gebäudeplan (Interconnect-Graph): Wie sind die Räume verbunden? Gibt es direkte Flure, oder muss man durch drei andere Räume gehen, um zum nächsten zu gelangen?

2. Das große Problem: Der „Tür"-Engpass

Wenn Sie zwei beste Freunde in verschiedene Räume setzen, müssen sie über den Flur schreien. Doch es gibt zwei große Probleme:

1. Zu viel Geschrei: Wenn zu viele Paare von Freunden in verschiedenen Räumen sind, werden die Flure verstopft.
2. Zu wenige Türen: Jeder Raum hat nur wenige „Kommunikationstüren" (Ports). Wenn Sie 100 Gäste in einen Raum setzen, aber nur 5 von ihnen nach draußen schreien müssen, können nur 5 gleichzeitig hinaus. Die anderen bleiben stecken.

3. Die Lösung: Die TPCCAP-Strategie

QuPort verwendet eine spezielle Strategie namens TPCCAP, um zu entscheiden, wer in welchen Raum geht. Es versucht, drei Dinge auszubalancieren:

• Entfernung: Es versucht, beste Freunde im selben Raum zu halten. Wenn sie in verschiedenen Räumen sein müssen, platziert es sie in Räumen, die nahe Nachbarn sind (kurze Flure).
• Türdruck: Es stellt sicher, dass kein Raum gezwungen wird, mehr „Türen" zu nutzen, als er tatsächlich hat. Es setzt nicht 10 schreiende Gäste in einen Raum mit nur 5 Türen.
• Flurverkehr: Es verteilt das Geschrei so, dass kein einzelner Flur mit zu viel Verkehr verstopft wird.

4. Wie QuPort die Party plant (Die Algorithmen)

QuPort rät nicht einfach; es verwendet einige clevere Tricks, um die beste Anordnung zu finden:

• Heavy-Edge-Clustering: Es betrachtet zuerst die stärksten Freundschaften und schließt diese Paare in denselben Raum ein, bevor es sich um den Rest kümmert.
• Balanced Greedy: Es füllt die Räume einen Gast nach dem anderen, wobei es immer den Raum wählt, der für diesen Gast am sinnvollsten ist, ohne den Raum zu überfüllen.
• Simulated Annealing: Dies ist wie eine Phase des „Zweifelns". Nach dem ursprünglichen Plan versucht es zufällige kleine Änderungen (wie das Tauschen zweier Gäste), um zu sehen, ob die Party reibungsloser läuft. Wenn eine Änderung die Dinge verbessert, behält sie sie bei. Wenn sie die Dinge verschlechtert, behält sie sie möglicherweise trotzdem für einen Moment bei, um nicht in einem „gut genug", aber nicht „perfekten" Plan stecken zu bleiben.

5. Die Liste der „Remote Events"

Sobald die Gäste den Räumen zugewiesen sind, erstellt QuPort eine spezielle Anweisungsliste.

• Lokale Anweisungen: „Gast A und Gast B sind im Raum 1. Sie können normal sprechen."
• Remote Events: „Gast A ist im Raum 1 und Gast B ist im Raum 2. Sie müssen sprechen."

QuPort erkennt nicht, wie sie über den Flur sprechen (ob sie Laser, Kabel oder Magie verwenden). Es markiert lediglich den Ort, an dem dieses Gespräch stattfinden muss, und sagt den Hardware-Ingenieuren: „Sie müssen hier ein Protokoll entwickeln, um dieses spezifische Schreien zu bewältigen."

6. Der Zeitplan

Schließlich schätzt QuPort, wie lange die Party dauern wird. Es zählt, wie viele „Schreie" gleichzeitig stattfinden können, ohne die Flure zu verstopfen oder die Türen zu erschöpfen. Es gibt eine grobe Schätzung der Gesamtzeit (Makespan) basierend auf diesen abstrakten Regeln.

Was QuPort NICHT ist

Der Artikel ist sehr klar darüber, was dieses Werkzeug nicht ist:

• Es ist keine physische Maschine.
• Es kennt die spezifische Physik Ihres Quantencomputers nicht (wie lange eine Batterie hält oder wie viel Fehler ein Laser verursacht).
• Es führt das eigentliche „Schreien" über die Räume nicht aus.

Zusammenfassend: QuPort ist eine intelligente Verkehrsleitstelle für einen modularen Quantencomputer. Es ermittelt den besten Weg, die Arbeit auf verschiedene kleine Computer aufzuteilen, damit sie nicht warten müssen, bis sie aufeinander warten, und stellt gleichzeitig sicher, dass sie nicht versuchen, mehr Türen oder Flure zu nutzen, als tatsächlich existieren. Es bereitet die Anweisungen vor, damit die eigentlichen Hardware-Ingenieure später den besten Weg finden können, die „Schrei"-Technologie zu bauen.

Technische Zusammenfassung

Technische Zusammenfassung: QuPort - Topologie-, Port- und Stau-bewusste Kompilierung für modulare Multi-QPU-Quantensysteme

1. Problemstellung

Modulare Quantenarchitekturen, die mehrere Quantenprozessoren (QPUs) über Verbindungen koppeln, stellen eine einzigartige Kompilierungsherausforderung dar, die sich von monolithischen Geräten unterscheidet. Bei der Kompilierung einzelner Geräte ist die lokale Kopplungskarte die primäre Einschränkung; nicht-lokale Wechselwirkungen werden durch Einfügen von SWAP-Operationen gelöst. In modularen Systemen sind Wechselwirkungen zwischen Qubits auf verschiedenen QPUs jedoch nicht lediglich „längere" lokale Gatter, sondern hängen von knappen Kommunikationsressourcen ab: der Topologie der Verbindungen, den Kommunikationsports und der Link-Kapazität.

Bestehende Compiler behandeln die Kommunikation zwischen QPUs oft als nachrangiges Anliegen oder verstecken sie innerhalb des Standard-Routings. Dieser Ansatz ist für modulare Systeme unzureichend, da eine Zuordnung, die auf einem einzelnen Kopplungsgraphen akzeptabel ist, in einem modularen Setting scheitern kann, wenn sie:

1. Übermäßigen verkehr zwischen QPUs erzeugt.
2. Verkehr auf eine kleine Anzahl von Verbindungslinks konzentriert (was zu Staus führt).
3. Zu viele Rand-Qubits (Qubits, die mit anderen QPUs interagieren) einer QPU mit unzureichenden Kommunikationsports zuweist.

Der Artikel adressiert die Notwendigkeit eines Compiler-Frameworks, das lokale Gerätekonnectivität und kommunikation zwischen QPUs gleichzeitig explizit berücksichtigt, bevor ein spezifisches physikalisches Protokoll für Remote-Gatter (z. B. photonische Links, Verschränkungsgenerierung) ausgewählt wird.

2. Methodik

QuPort ist ein auf Qiskit aufbauendes, Python-basiertes Kompilierungs-Framework. Es führt ein Systemmodell auf drei Ebenen und einen spezifischen Partitionierungsalgorithmus zur Optimierung der Ressourcennutzung ein.

2.1 Systemmodell

Das Framework abstrahiert das Kompilierungsproblem in drei verschiedene Graphen:

1. Logischer Interaktionsgraph ($G_L$): Ein gewichteter ungerichteter Graph, bei dem Knoten logische Qubits darstellen und Kantengewichte die Häufigkeit oder zeitliche Bedeutung von Zwei-Qubit-Wechselwirkungen wiedergeben.
2. Physikalische Kopplungskarte: Ein gerichteter Graph, der die Konnektivität innerhalb jeder einzelnen QPU darstellt (z. B. Gitter, Ring, Clique).
3. QPU-Verbindungsgraph ($G_Q$): Ein ungerichteter Graph, der die Topologie darstellt, die die QPUs verbindet (z. B. Mesh, Ring, Clos, Fat-Tree). Dieser Graph wird zur Berechnung von Hop-Distanzen und Link-Lasten verwendet.

Das System geht von $N$ QPUs aus, wobei jede $C$ Rechen-Qubits und $P$ Kommunikations-Qubits besitzt. Eine logische-zu-QPU-Partition ($\pi$) muss die Kapazitätsbeschränkung ($C+P$) pro QPU einhalten.

2.2 Das TPCCAP-Ziel

Der Kern von QuPort ist die TPCCAP-Zielfunktion (Topologie-, Port- und Stau-bewusste Partitionierung) $J(\pi)$, die eine gewichtete Summe aus drei Kostentermen minimiert:

1. Gewichtete Schnittentfernung: $\sum w_{ij} \cdot d(\pi(i), \pi(j))$. Dies bestraft Wechselwirkungen zwischen Qubits, die QPUs zugewiesen sind, die im Verbindungsgraphen weit voneinander entfernt sind, wobei $d$ die kürzeste Pfaddistanz ist.
2. Überlauf der Kommunikationsports: $\sum \max(0, b_q - P)^2$. Dies bestraft QPUs, bei denen die Anzahl der Rand-Qubits ($b_q$) die verfügbaren Kommunikationsports ($P$) überschreitet.
3. Gestauter Link-Last: $\sum L_e^2$. Dies bestraft die quadrierte Last auf Verbindungs-Kanten ($e$) und wirkt einer Verkehrskonzentration auf bestimmte Links entgegen.

2.3 Algorithmen

QuPort implementiert eine Pipeline von Heuristiken zur Lösung des Partitionierungs- und Layoutproblems:

• Schwere-Kanten-Clustering: Verschmilzt hochgewichtete logische Paare zu Clustern, solange die Clustergröße die QPU-Kapazität nicht überschreitet.
• Ausgewogene Greedy-Partitionierung: Weist logische Qubits einzeln basierend auf dem gewichteten Grad zu, gleicht die Last über die QPUs aus und belohnt die Platzierung in der Nähe bereits zugewiesener Nachbarn.
• TPCCAP-Lokale Suche: Verfeinert die initiale Partition durch Verschieben von Qubits, um das $J(\pi)$-Ziel zu reduzieren, während Kapazitätsbeschränkungen eingehalten werden.
• TPCCAP-SA (Simulated Annealing): Fügt eine stochastische Verfeinerungsphase hinzu, um lokale Minima zu verlassen, indem gelegentlich Züge akzeptiert werden, die die Zielfunktion erhöhen.
• Port-bewusstes Layout: Nach der Partitionierung werden spezifische logische Qubits ausgewählt, um Kommunikationsports basierend auf ihrem „externen Score" (Gesamtgewicht der Wechselwirkungen mit anderen QPUs) zu belegen.
• Verteilter Programm-Entwurf: Im verteilten Modus extrahiert das Framework Zwei-Qubit-Operationen zwischen QPUs als explizite Remote-Ereignisse und fügt Synchronisationsbarrieren ein, während lokale Operationen nur innerhalb ihrer jeweiligen QPU-Kopplungskarten geroutet werden.

2.4 Planung und Kostenabschätzung

QuPort enthält einen topologiebewussten Schätzer, der die Ausführungszeit (Makespan) unter Verwendung abstrakter Kostenparameter approximiert:

• Lokale Kosten: Ausführungszeiten für Gatter bei Ein-Qubit-, Zwei-Qubit- und SWAP-Operationen.
• Remote-Kosten: Ein Modell, das die Kosten der Verschränkungsgenerierung ($\tau_E$), die Kosten für klassische Hin- und Rückwege ($\tau_C$) und Remote-Overhead ($\tau_R$) kombiniert.
• Planung: Remote-Operationen werden basierend auf verfügbaren Kommunikationsports und Link-Kapazitäten in „Runden" gepackt, unter Einhaltung der Verbindungs-Topologie.

3. Hauptbeiträge

1. Explizite Abstraktion auf drei Ebenen: Der Artikel schlägt eine Compiler-Ebene-Abstraktion vor, die den logischen Interaktionsgraphen, die physikalische Kopplungskarte und den QPU-Verbindungsgraphen trennt. Diese Trennung ermöglicht die Optimierung modulspezifischer Kosten (Entfernung, Ports, Stau), die für Standard-Monolith-Compiler unsichtbar sind.
2. Die TPCCAP-Zielfunktion: Eine neuartige Zielfunktion, die QPU-Entfernung, Knappheit der Kommunikationsports und Link-Stau gemeinsam optimiert, anstatt diese als separate oder nachrangige Anliegen zu behandeln.
3. Verteilter Kompilierungspfad: Ein Mechanismus, der eine Zwischenrepräsentation erzeugt, bei der lokale Schaltkreise und Remote-Ereignisse explizit getrennt sind. Dies ermöglicht dem Compiler, modulspezifische Pläne zu generieren, ohne sich für eine spezifische Hardware-Implementierung von Remote-Gattern festzulegen.
4. Open-Source-Framework: Die Implementierung dieser Algorithmen in Python/Qiskit bietet eine reproduzierbare Umgebung zur Untersuchung modularer Kompilierungsstrategien.

4. Ergebnisse und Validierung

Der Artikel konzentriert sich auf die algorithmische Struktur und Korrektheit des Frameworks, anstatt kalibrierte Hardware-Laufzeitergebnisse zu berichten.

• Korrektheit: Die Autoren liefern formale Beweise (Propositionen 1 und 2), die zeigen, dass ihre Partitionierungsalgorithmen (Schwere-Kanten, Greedy, TPCCAP, TPCCAP-SA) die Kapazitätsbeschränkungen pro QPU strikt einhalten und dass ihre Multi-Pfad-Routing-Routinen den Verkehrsgewicht erhalten.
• Validierung: Das Framework erzwingt Validierungsprüfungen bei Partitionseingaben, Layout-Erstellung und Verkehrsmatrizen, um endliche, nicht-negative und symmetrische Werte sicherzustellen.
• Umfang der Ergebnisse: Der Artikel behauptet nicht, spezifische Hardware-Protokolle zu übertreffen oder kalibrierte Fehlerraten bereitzustellen. Stattdessen zeigt er, dass das Framework erfolgreich gültige Partitionen und verteilte Programme generiert, die die definierten abstrakten Beschränkungen einhalten.

5. Bedeutung und Behauptungen

Der Artikel positioniert QuPort als Compiler-Ebene-Abstraktion und nicht als Hardware-Implementierung. Seine Bedeutung liegt in:

• Entkopplung der Kompilierung von Hardware-Protokollen: Durch die Trennung der logischen Partitionierung und der Extraktion von Remote-Ereignissen von der physikalischen Realisierung von Remote-Gattern ermöglicht QuPort Forschern, die algorithmische Struktur modularer Kompilierung zu untersuchen, bevor eine spezifische Verbindungstechnologie (z. B. photonisch vs. Mikrowelle) finalisiert ist.
• Ressourcenbewusste Zuordnung: Es hebt hervor, dass modulare Kompilierung einen Wechsel von der Minimierung von SWAPs zur Minimierung von „Schnittentfernung", „Port-Überlauf" und „Link-Stau" erfordert.
• Bescheidenheit in den Behauptungen: Die Autoren stellen explizit fest, dass das Framework keine kalibrierte Hardware-Laufzeit beansprucht und auch kein physikalisches Remote-Gatter-Protokoll implementiert. Die „Remote-Ereignisse" sind Zwischenrepräsentationen, die anzeigen, wo ein Backend ein Protokoll bereitstellen muss. Der Planungsschätzer wird als „schichtbasierter Greedy-Modell" beschrieben, nicht als verifizierter Netzwerksteuerungs-Planer.

Zusammenfassend bietet QuPort einen strukturierten, heuristisch getriebenen Ansatz für das komplexe Ressourcenallokationsproblem, das im modularen Quantencomputing inhärent ist, und stellt ein Werkzeug dar, um die Kompromisse zwischen Topologie, Port-Verfügbarkeit und Stau auf plattformunabhängige Weise zu erkunden.