HPC-vQPU: A Service-Export Architecture for Virtual QPUs on Batch-Scheduled HPC Systems

Dieser Beitrag stellt HPC-vQPU vor, eine Architektur zum Export von Diensten, die eine sichere, gerätetreue virtuelle QPU-Simulation auf batch-geplanten HPC-Systemen ermöglicht, indem eine Cloud-orientierte Kontrollebene von einer HPC-residenten Ausführungsebene durch abgehende Koordination und unveränderliche, kalibrierungsbewusste Gerätesnapshots entkoppelt wird.

Das Wesentliche

Das große Problem: Zwei verschiedene Welten

Stellen Sie sich vor, Sie haben eine sehr leistungsstarke, hochtechnologische Küche (einen Supercomputer), die riesige Mahlzeiten für Tausende von Menschen gleichzeitig zubereiten kann. Diese Küche unterliegt jedoch strengen Regeln:

1. Kein Spontanbesuch: Sie können nicht einfach hereinkommen und eine Mahlzeit bestellen. Sie müssen ein Formular ausfüllen, in einer Schlange warten, und das Küchenpersonal beginnt erst mit dem Kochen, wenn ein Herd frei ist.
2. Kein direkter Kontakt: Sobald Ihr Essen in der Küche zubereitet wird, sind die Köche isoliert. Sie können Sie nicht anrufen, um Fragen zu stellen oder Ihnen den Fortschritt mitzuteilen. Sie können nur eine Nachricht herausgeben, wenn sie fertig sind.

Stellen Sie sich nun vor, Sie sind ein Quantenwissenschaftler. Sie möchten ein sehr spezifisches, empfindliches Experiment (einen „Quantenschaltkreis") durchführen, das eine bestimmte Auswahl an Zutaten und eine spezielle Zubereitungsart (Kalibrierung und Topologie) erfordert. Sie erwarten einen Service, bei dem Sie sagen können: „Bereiten Sie dieses Gericht auf dem 'IBM Fez'-Herd zu", und das Ergebnis sofort zurückerhalten.

Der Konflikt: Der Wissenschaftler möchte ein interaktives „Bestellen-und-Warten"-Erlebnis. Der Supercomputer bietet nur ein „Formular-ausfüllen-und-in-der-Schlange-warten"-Erlebnis. Wenn Sie versuchen, die Küche zu zwingen, direkt mit Ihnen zu sprechen, verletzen Sie die Sicherheitsregeln der Küche.

Die Lösung: HPC-VQPU

Die Autoren haben ein System namens HPC-VQPU entwickelt, um diese Lücke zu schließen. Stellen Sie es sich als einen intelligenten Kellner vor, der genau weiß, wie er sowohl mit dem Wissenschaftler als auch mit der Küche sprechen kann, ohne gegen irgendwelche Regeln zu verstoßen.

So funktioniert es, Schritt für Schritt:

1. Das Zwei-Teile-Team

Das System ist in zwei unterschiedliche Rollen aufgeteilt, genau wie ein Restaurant in einen Gastbereich (Front of House) und einen Küchenbereich (Back of House) unterteilt ist.

• Die Kontrollebene (Gastbereich): Dies ist der Teil, mit dem der Wissenschaftler spricht. Er sieht aus wie eine normale, freundliche App. Er nimmt Ihre Bestellung entgegen, prüft, ob Ihre Zutaten gültig sind, und gibt Ihnen eine Quittung. Er befindet sich außerhalb der sicheren Küche.
• Die Ausführungsebene (Küchenbereich): Dies ist der Teil innerhalb der sicheren Küche. Es ist ein bescheidener „Läufer" (ein Agent), der am Eingangstresen der Küche sitzt. Er kann nicht zum Gastbereich anrufen; er kann dem Gastbereich nur Arbeit abfragen.

2. Die „Nur ausgehend"-Regel (Die Einwegtür)

Die Küche hat eine strenge Sicherheitsrichtlinie: Niemand im Inneren kann nach außen rufen, um ein Gespräch zu beginnen. Auch die Außenwelt kann nicht hineinrufen.

• Wie HPC-VQPU dies löst: Der Läufer im Inneren der Küche klopft ständig an die Tür (Polling) und fragt: „Haben Sie Bestellungen für mich?"
• Der Gastbereich ruft den Läufer niemals an. Er wartet einfach darauf, dass der Läufer fragt. Dies hält die Küche sicher, da keine „Hintertüren" geöffnet werden.

3. Der „Snapshot"-Vertrag (Das eingefrorene Rezept)

Dies ist der wichtigste Teil des Papiers.

• Das Problem: Quantencomputer sind wie lebende Organismen; ihr „Geschmack" (die Kalibrierung) ändert sich jeden Tag. Wenn Sie heute ein Gericht bestellen, die Küche aber erst morgen mit dem Kochen beginnt, könnten sich die Zutaten verändert haben, und das Gericht schmeckt nicht richtig.
• Der alte Weg: Wenn Sie einfach eine Anfrage senden würden, würde die Küche das Rezept beim Start des Kochens nachschlagen. Aber bis dahin könnte sich das Rezept geändert haben, oder die Küche könnte zu beschäftigt sein, um es nachzuschlagen.
• Der HPC-VQPU-Weg: Wenn der Läufer nach einer Bestellung fragt, gibt der Gastbereich nicht einfach den Befehl „Geh und koche das". Er überreicht eine eingefrorene Rezeptkarte (ein „Snapshot").
  • Diese Karte enthält den exakten Zustand der Zutaten, die Herdeinstellungen und die Kochanweisungen zum exakten Zeitpunkt, zu dem der Läufer die Bestellung entgegengenommen hat.
  • Der Läufer nimmt diese Karte, geht in die isolierte Küche und kocht nur mit dieser Karte. Er muss das Rezept nicht erneut nachschlagen.
  • Warum das wichtig ist: Selbst wenn das Hauptrezeptbuch der Küche eine Stunde später geändert wird, wird Ihr Gericht mit dem „eingefrorenen Rezept" zubereitet, das Sie erhalten haben. Das Ergebnis ist garantiert konsistent mit dem spezifischen „virtuellen Quantencomputer", den Sie angefordert haben.

4. Die „Behauptung" (Übernahme der Verantwortung)

Stellen Sie sich eine belebte Küche mit zwei Läufern vor.

• Das Risiko: Wenn beide Läufer gleichzeitig nach derselben Bestellung fragen, könnten sie beide versuchen, sie zu kochen, was Zutaten verschwendet und zu zwei unterschiedlichen Ergebnissen führt.
• Die Lösung: Der Gastbereich hat eine spezielle Sperre. Wenn ein Läufer nach Arbeit fragt, sagt der Gastbereich: „Okay, DU hast diese Bestellung jetzt." Er markiert die Bestellung sofort als „Übernommen" und gibt die eingefrorene Rezeptkarte an diesen spezifischen Läufer weiter.
• Wenn ein anderer Läufer eine Sekunde später nach derselben Bestellung fragt, sagt der Gastbereich: „Entschuldigung, das ist bereits übernommen." Dies stellt sicher, dass die Aufgabe genau einmal erledigt wird.

5. Der „Herzschlag" (Kontrollieren)

Da die Küchenläufer nicht nach außen rufen können, wie weiß der Gastbereich, dass sie noch am Leben sind?

• Der Läufer sendet alle paar Sekunden ein kleines „Ich bin noch da"-Signal (einen Herzschlag).
• Wenn der Läufer abstürzt oder verschwindet, bemerkt der Gastbereich, dass die Herzschläge aufhören. Er gerät nicht in Panik; er wartet einfach darauf, dass ein menschlicher Manager sagt: „Okay, geben wir diese Bestellung einem anderen Läufer." Dies verhindert, dass das System stecken bleibt oder Daten verliert.

Was haben sie bewiesen?

Die Autoren haben dieses System auf einem echten Supercomputer (Setonix) getestet und bewiesen:

1. Es ist schnell genug: Der „Kellner" verlangsamt das Kochen nicht. Die hinzugefügte Zeit ist winzig und wird nicht schlechter, je schwieriger das Kochen wird.
2. Es ist genau: Die „eingefrorene Rezeptkarte" funktioniert. Wenn sie reale, sich ändernde Daten verwendeten, kochte das System das Gericht mit dem aktuellen Rezept zum Zeitpunkt der Bestellung, nicht mit einem alten.
3. Es ist sicher: Selbst wenn der Läufer abstürzt, weiß das System genau, was passiert ist, und kann sich erholen, ohne die Bestellung zu verlieren oder sie doppelt zu kochen.
4. Es ist sicher: Es funktioniert perfekt, ohne jemals die Sicherheitsregeln des Supercomputers zu verletzen (niemand im Inneren ruft an, um ein Gespräch zu beginnen).

Zusammenfassung

HPC-VQPU ist eine clevere Methode, um Wissenschaftlern zu ermöglichen, einen superleistungsstarken, sicheren Supercomputer so zu nutzen, als wäre er ein freundlicher, interaktiver Quantencomputer. Dies wird erreicht, indem ein „Läufer" verwendet wird, der nach Arbeit fragt, „eingefrorene Rezeptkarten" austeilt, damit das Kochen konsistent bleibt, und sicherstellt, dass niemand gegen die strengen Sicherheitsregeln der Küche verstößt. Es verwandelt ein starres, bürokratisches System in einen reibungslosen, zuverlässigen Service.

Technische Zusammenfassung

Technische Zusammenfassung: HPC-VQPU

Problemstellung

Die Arbeit adressiert die fundamentale Diskrepanz zwischen den Anforderungen gerätebewusster Quantensimulation und den operationellen Einschränkungen sicherer, batch-geplanter High-Performance-Computing (HPC)-Systeme. Während moderne Quantenforschung zunehmend auf Simulatoren angewiesen ist, die spezifische Gerätetopologien, native Gate-Sets und kalibrierungsabgeleitete Rauschparameter modellieren, ist die HPC-Infrastruktur für scheduler-vermittelte Ausführung und nicht für interaktive, geräteorientierte Dienste konzipiert.

Drei Hauptprobleme verhindern die direkte Exportierung der Quantensimulation als Dienst aus HPC-Umgebungen:

1. Umkehrung der Konnektivität: Sichere HPC-Cluster verbieten typischerweise eingehende Verbindungen zu Rechenknoten. Quantenentwickler erwarten, dass sie Schaltkreise an einen benannten Backend einreichen und Ergebnisse interaktiv abrufen, doch HPC-Sicherheitsmodelle erlauben nur ausgehende Kommunikation von Login-Knoten aus. Ein standardmäßiges „Push"-Modell, bei dem ein Dienst Aufträge an Worker verteilt, ist strukturell nicht verfügbar.
2. Semantische Erhaltung: Eine „virtuelle QPU" ist nicht bloß ein Schaltkreis-Executor; sie ist ein softwaredefiniertes Endpunkt, der Topologie, Kalibrierung und Rauscheinschränkungen exponiert. In einem Batch-System kann eine Aufgabe stundenlang in einer Warteschlange verweilen, während sich der Kalibrierungszustand des Geräts ändert. Wenn die Ausführungsssemantik nicht an einen spezifischen Zeitpunkt gebunden ist, entspricht das Ergebnis möglicherweise nicht mehr dem angeforderten virtuellen Gerät, wodurch die Simulation für Compiler-Entwicklung oder Routing-Studien wissenschaftlich ungültig wird.
3. Operationale Komplexität: Scheduler-vermittelte Ausführung führt zu einer Fehlerfläche, die über einfache Anwendungsfehler hinausgeht, einschließlich Scheduler-Verzögerungen, Knotenausfällen, Agenten-Verschwinden und fehlerhaften Artefakten. Ein funktionsfähiger Dienst muss interaktive Lebenszyklus-Semantik (Einreichen, Überwachen, Abrufen) mit der partiellen Beobachtbarkeit und dem asynchronen Charakter der HPC-Jobplanung in Einklang bringen.

Methodik und Architektur

Die Autoren schlagen HPC-VQPU vor, eine Service-Export-Architektur, die die Dienstautorität von der scheduler-gesteuerten Ausführung trennt. Das System ist in zwei getrennte Ebenen organisiert, die ausschließlich über ausgehende, agenteninitiierte Nachrichten kommunizieren und dabei die HPC-Sicherheitsgrenze wahren.

1. Zwei-Ebenen-Zerlegung

• Steuerungsebene (Cloud-orientiert): Extern zum HPC-Cluster gehostet, verwaltet diese Ebene die API, den Aufgaben-Lebenszyklus, die Geräteidentität und die Ereignisprojektion. Sie ist autoritativ für den Aufgabenstatus, enthält jedoch keine scheduler-orientierte Funktionalität oder eingehende Konnektivität zum Cluster.
• Ausführungsebene (HPC-resident): Implementiert durch einen nicht privilegierten vqpu_agent, der auf einem HPC-Login-Knoten läuft. Dieser Agent initiiert alle Koordinationsvorgänge. Er fragt die Steuerungsebene nach Arbeit ab, beansprucht Aufgaben, reicht Jobs beim Scheduler ein (z. B. Slurm) und meldet Ergebnisse. Er besitzt keine dauerhafte Dienstwahrheit und ist nach einem Neustart rekonstruierbar.

2. Der Snapshot-Vertrag

Die zentrale Abstraktion ist der Geräte-Snapshot ($\Delta$), eine graph-strukturierte Darstellung eines virtuellen Geräts, das Topologie, native Gates und Kalibrierungsparameter (Kohärenzzeiten, Fehlerraten) enthält.

• Bindung zum Zeitpunkt der Beanspruchung: Um die Spannung zwischen Warteschlangenverzögerung und Kalibrierungsfrische aufzulösen, wird der Snapshot atomar zum Zeitpunkt der Beanspruchung gebunden, nicht beim Einreichen. Wenn ein Agent eine Aufgabe beansprucht, überträgt die Steuerungsebene das Eigentum und stellt den unveränderlichen Snapshot ($\delta_i$) als Teil des Ausführungsvertrags bereit.
• Hermetische Ausführung: Der Rechenknoten-Runner erhält eine lokale Nutzlast, die den Schaltkreis und den gebundenen Snapshot enthält. Er führt die Simulation (z. B. mit Qiskit-Aer/cuQuantum) vollständig offline aus, leitet Rauschmodelle aus dem Snapshot ab, ohne die Steuerungsebene zu kontaktieren. Dies stellt sicher, dass die Ausführungsssemantik gegenüber Gerätezustandsänderungen, die nach der Beanspruchung auftreten, invariant bleibt.

3. Aufgaben-Lebenszyklus und Protokoll

Das System verwendet einen fünfzuständigen Aufgabenautomaten ($\{QUEUED, RUNNING, COMPLETED, FAILED, CANCELLED\}$), der von der Steuerungsebene verwaltet wird.

• Asymmetrisches Protokoll: Der Agent initiiert CLAIM, HEARTBEAT und REPORT-Operationen. Die Steuerungsebene drückt niemals Zustände nach innen.
• Atomare Eigentumsübernahme: Die CLAIM-Operation ist der Linearisierungspunkt für das Eigentum. Sie führt einen Aufgabenstatus atomar von QUEUED zu RUNNING über und weist einen eindeutigen Eigentümer zu, wodurch eine doppelte Ausführung durch konkurrierende Agenten verhindert wird.
• Wiederherstellung: Wenn ein Agent ausfällt, bleibt die Aufgabe mit einem veralteten Eigentümer in RUNNING. Die Wiederherstellung erfordert eine explizite administrative Aktion (z. B. REQUEUE), wodurch sichergestellt wird, dass Mehrdeutigkeiten nicht stillschweigend gelöst werden und die Ausführungs-Herkunft bewahrt bleibt.

Hauptbeiträge

Die Arbeit präsentiert vier Hauptbeiträge:

1. Service-Export-Architektur: Eine Zerlegung in Steuerungs- und Ausführungsebene, die die Umkehrung der Konnektivität durch ausschließliche Koordination über ausgehende Verbindungen auflöst und es sicheren HPC-Systemen ermöglicht, gerätebewusste Simulation zu exportieren, ohne die Sicherheitsposition zu schwächen.
2. Geräte-Snapshot-Abstraktion: Ein portabler, graph-strukturierter Ausführungsvertrag, der Topologie und Kalibrierungssemantik atomar zum Zeitpunkt der Beanspruchung bindet und sicherstellt, dass eingeplante Aufträge dem angeforderten virtuellen Gerätezustand treu bleiben.
3. Scheduler-bewusster Lebenszyklus: Ein fünfzuständiger Aufgabenautomat mit einem asymmetrischen Claim/Report/Heartbeat-Protokoll, das interaktive Dienstsemantik mit scheduler-vermittelter Ausführung und partieller Beobachtbarkeit in Einklang bringt.
4. Referenzimplementierung und Validierung: Eine Produktionsbereitstellung am Pawsey Supercomputing Research Centre unter Verwendung von Setonix-GPUs, Qiskit-Aer und IBM-Fez-Kalibrierungsdaten, die die Machbarkeit der Architektur demonstriert.

Experimentelle Ergebnisse

Die Autoren validieren die Architektur durch Regressionstests und End-to-End-Produktionsexperimente, wobei folgende Ergebnisse erzielt wurden:

• Begrenzter Overhead: Der Service-Export-Overhead ist additiv und begrenzt. Die für die Schnittstelle sichtbare Latenz (Zulassung und Abfrage) bleibt unabhängig von der Schaltkreisgröße (28–32 Qubits) konstant (~0,4 s Zulassung, ~22–27 s Warteschlange-zu-Beanspruchung). Die exponentielle Skalierung der Simulation bleibt auf den Rechenuntergrund beschränkt.
• Kalibrierungstreue: Experimente mit realen IBM-Fez-Kalibrierungsdaten im Vergleich zu idealen (null) Snapshots zeigen, dass der Snapshot-Inhalt die Ausgangsverteilungen direkt verändert. Das System leitet kalibrierungsabgeleitete Rauschparameter korrekt an den Simulator weiter.
• Bindung zum Zeitpunkt der Beanspruchung: Wenn die Kalibrierung eines Geräts administrativ nach dem Einreichen, aber vor der Beanspruchung geändert wird, führt das System die Aufgabe korrekt unter Verwendung des post-mutierten (idealen) Zustands aus. Dies bestätigt, dass der Snapshot zum Zeitpunkt der Beanspruchung gebunden wird und eine veraltete Ausführung verhindert.
• Parallelität und Integrität: In einem Multi-Agenten-Test mit 50 Aufgaben und zwei parallelen Agenten wurden alle Aufgaben genau einmal abgeschlossen, mit einer nahezu gleichmäßigen Aufteilung (24:26). Es traten keine doppelten Beanspruchungen oder mehrdeutigen Eigentumsverhältnisse auf.
• Wiederherstellung: Nach einem Agenten-Crash wurden drei RUNNING-Aufgaben durch explizites Re-Queuing erfolgreich wiederhergestellt und abgeschlossen, ohne doppelte Ausführung oder stille Neuinterpretation des Zustands.

Bedeutung und Behauptungen

Die Arbeit behauptet, dass HPC-VQPU demonstriert, wie sichere, batch-geplante Supercomputer semantisch reiche, interaktive Dienste exportieren können, ohne aufzuhören, wie HPC-Systeme zu operieren. Die Bedeutung liegt in der Fähigkeit, die Gerätetreue (Topologie, native Gates, Kalibrierung) über die Scheduler-Grenze hinweg zu bewahren.

Die Autoren positionieren diese Arbeit nicht als Performance-Optimierung für Simulationskerne, sondern als Systemlösung für die Dienstgrenze. Indem der Geräte-Snapshot als primärer, zeitindexierter Vertrag behandelt wird, ermöglicht die Architektur, dass Quanten-Software-Workflows (Compiler-Bewertung, Routing, Rauschstudien) mit HPC-Ressourcen interagieren, als wären sie interaktive virtuelle QPUs. Die Design-Invarianten (ausschließlich ausgehende Konnektivität, atomare Beanspruchung, hermetische Ausführung) werden als notwendige Bedingungen präsentiert, um Ergebnisse auch angesichts von Warteschlangenverzögerungen und Infrastrukturausfällen wissenschaftlich als Ausführung auf einem spezifischen virtuellen Gerät interpretierbar zu machen.

Die Arbeit schließt bescheiden und räumt ein, dass die Evaluation auf einem einzelnen Produktionsstandort und einem Simulationspfad basiert und dass die Architektur autoritative Lebenszyklus-Semantik bietet, anstatt einen Beweis für „exakt-einmalige" Ausführung im vollen Sinne verteilter Systeme zu erbringen. Dennoch wird behauptet, dass die vorgeschlagene Trennung von Autorität und Realisierung einen gangbaren Weg für die Integration von HPC-skalierten Simulationen in das interaktive Quanten-Software-Ökosystem bietet.