Quantum-HPC Software Stacks and the openQSE Reference Architecture: A Survey

Diese Arbeit analysiert aktuelle Quanten-HPC-Software-Stacks, um deren Isolation und fehlende Schnittstellen aufzuzeigen, und schlägt darauf aufbauend die offene Referenzarchitektur openQSE vor, die eine interoperable und zukunftsfähige Softwareumgebung für sowohl NISQ- als auch zukünftige fehlertolerante Quantensysteme ermöglicht.

Das Wesentliche

Stell dir vor, du möchtest ein riesiges, komplexes Puzzle lösen. Dafür hast du zwei Arten von Helfern:

1. Die klassischen Supercomputer: Das sind wie riesige, extrem schnelle Bibliothekare. Sie können unendlich viele Bücher (Daten) sortieren, rechnen und organisieren. Sie sind perfekt für den Großteil der Arbeit.
2. Die Quantencomputer: Das sind wie magische Zauberer. Sie können bestimmte, sehr spezielle Rätsel (wie das Mischen von Medikamenten oder das Finden des besten Weges durch einen Labyrinth) lösen, für die die Bibliothekare ewig brauchen würden. Aber diese Zauberer sind noch etwas unruhig, brauchen eine ruhige Umgebung und können nur sehr wenige Aufgaben gleichzeitig erledigen.

Das Problem bisher:
In den letzten Jahren haben Wissenschaftler und Firmen angefangen, diese Zauberer in die Bibliotheken zu holen. Aber das hat zu einem großen Chaos geführt. Jeder Zauberer (jeder Quantencomputer-Hersteller wie IBM, Amazon, IonQ etc.) hatte seine eigene, völlig andere Sprache und seine eigenen Regeln.

• Der Bibliothekar musste für jeden Zauberer eine neue Übersetzung lernen.
• Wenn man von einem Zauberer zu einem anderen wechseln wollte, musste man das ganze Puzzle neu aufbauen.
• Es gab keine einheitliche Art, den Zauberern zu sagen: „Hey, mach das jetzt!" oder „Hier ist das Ergebnis, bitte weitermachen."

Das ist wie wenn du in einem Restaurant sitzt, wo jeder Koch eine andere Speisekarte hat, du aber für jeden Koch ein anderes Formular ausfüllen musst, um dein Essen zu bestellen. Das ist ineffizient und nervig.

Was diese Papier macht:
Die Autoren dieses Papers (eine große Gruppe von Experten aus Forschung und Industrie) haben sich neun dieser verschiedenen „Küchen" (Software-Stacks) angesehen. Sie haben analysiert, wie sie funktionieren, wo sie sich ähneln und wo sie sich unterscheiden.

Ihr Ergebnis ist ein neuer, gemeinsamer Bauplan, den sie openQSE nennen.

Die Analogie zum neuen Bauplan (openQSE):
Stell dir vor, die Autoren entwerfen jetzt eine universelle Bestellkassette und eine gemeinsame Sprache für das ganze Restaurant.

1. Die universelle Bestellkassette (Schnittstellen): Egal, welcher Zauberer (Hersteller) gerade arbeitet, du gibst deine Bestellung immer auf demselben Formular ein. Das Formular ist so gestaltet, dass es automatisch weiß, wie es die Nachricht an den jeweiligen Zauberer übersetzen muss. Du musst nicht mehr wissen, ob der Zauberer mit Ionen oder mit Licht arbeitet.
2. Die gemeinsame Sprache (Schichten): Der Bauplan teilt die Arbeit in klare Schichten auf:
   • Die obere Schicht: Hier sitzt der Wissenschaftler (der Kunde). Er denkt nur an sein Problem, nicht an die Technik.
   • Die mittlere Schicht: Das ist der Übersetzer und Manager. Er nimmt die Bestellung, schaut, welcher Zauberer gerade frei ist, und passt die Bestellung an die Fähigkeiten des Zauberers an.
   • Die untere Schicht: Das ist der Zauberer selbst mit seinen magischen Werkzeugen.
3. Zukunftssicherheit: Der Bauplan ist so gebaut, dass er heute schon mit den etwas unruhigen Zauberern (den aktuellen „NISQ"-Geräten) funktioniert, aber auch bereit ist, wenn in Zukunft die „perfekten" Zauberer (fehlertolerante Quantencomputer) kommen. Man muss das Formular oben nicht ändern, nur weil sich die Magie unten verbessert hat.

Warum ist das wichtig?

• Für Wissenschaftler: Sie können ihre Programme schreiben und müssen sich nicht um die Technik kümmern. Sie können einfach den „besten" Zauberer für ihr Problem wählen, ohne alles neu zu programmieren.
• Für die Rechenzentren: Sie können verschiedene Quantencomputer nebeneinander betreiben und effizient verwalten, ohne für jeden eine eigene Software zu bauen.
• Für die Zukunft: Es schafft ein Ökosystem, in dem alle zusammenarbeiten können, statt in isolierten Inseln zu verharren.

Zusammenfassung:
Dieses Papier ist wie ein Treffen aller Küchenchefs, um endlich eine einheitliche Bestellkarte und eine gemeinsame Sprache zu erfinden. Damit können wir die magischen Quantencomputer endlich wirklich effizient in unsere großen wissenschaftlichen Projekte integrieren, ohne dass jeder Einzelne das Rad neu erfinden muss. Es ist der erste Schritt von einem chaotischen Wildwuchs hin zu einem geordneten, funktionierenden System.

Technische Zusammenfassung

1. Problemstellung

Quantencomputer werden zunehmend in High-Performance-Computing (HPC) und Cloud-Umgebungen integriert, um hybride Workflows (z. B. Hamiltonian-Simulation, Optimierung, Quanten-Machine-Learning) zu unterstützen. Derzeit ist diese Integration jedoch durch eine starke Fragmentierung gekennzeichnet:

• Isolierte Lösungen: Es existieren viele proprietäre, vollständige Software-Stacks, die oft keine gemeinsamen Schnittstellen für Runtime, Ressourcenmanagement, Orchestrierung und Ausführung bieten.
• Hohe Wartungskosten: HPC-Zentren und Entwickler müssen für verschiedene Anbieter (Cloud vs. On-Premises) unterschiedliche Integrationslogiken für Job-Submission, Ressourcenbeschreibung und Sicherheit implementieren.
• Fehlende Portabilität: Anwendungen und Betriebsabläufe sind schwer zwischen verschiedenen Plattformen zu portieren.
• Unterschiedliche Skalierungsmodelle: HPC-Ressourcen (Kerne, GPUs) lassen sich modular und teilweise skalieren, während Quantenprozessoren (QPUs) durch Qubits skaliert werden, die knapp, stark gekoppelt und nicht unterbrechbar (kein Checkpointing) sind. Diese Asymmetrie erfordert neue Architekturen.

Das Ziel ist es, diese Fragmentierung zu überwinden, um eine effiziente, intelligente Integration von Quantenressourcen in HPC-Workflows zu ermöglichen, die sowohl für NISQ- (Noisy Intermediate-Scale Quantum) als auch zukünftige FTQC- (Fault-Tolerant Quantum Computing) Systeme geeignet ist.

2. Methodik

Die Autoren führen eine umfassende Analyse des aktuellen „State-of-the-Practice" durch:

• Untersuchungsgegenstand: Neun repräsentative, in Produktion eingesetzte QHPC-Software-Stacks wurden analysiert. Dazu gehören Lösungen von AWS, IBM, IonQ, JHPC-Quantum, MQSS, Pasqal, Quantinuum, Quantum Brilliance und Xanadu.
• Klassifikationsrahmen: Die Stacks wurden entlang vier Achsen verglichen:
  1. Bereitstellungsumgebung: Cloud, On-Premises und federierte Operationen.
  2. Quanten-Hardware-Modalität: Verschiedene Technologien (z. B. supraleitende Qubits, Ionenfallen, neutrale Atome, photonische Systeme).
  3. Anwendungsinteraktionsmuster: Workflow-zentriert (lose Kopplung) vs. Accelerator-zentriert (enge Kopplung, ähnlich GPU-Offloading).
  4. Quanten-Computing-Ära: Unterstützung für NISQ und/oder zukünftige FTQC-Systeme.
• Analyse der Schnittstellen: Es wurden etablierte Schnittstellen wie QDMI (Quantum Device Management Interface) und QRMI (Quantum Resource Management Interface) untersucht, um Konvergenzpunkte zu identifizieren.
• Vergleichsmatrix: Die Ergebnisse wurden in einer Interface-Konvergenzmatrix (Tabelle 1) zusammengefasst, die zeigt, wo sich die Felder angleichen und wo noch Unterschiede bestehen.

3. Schlüsselbeiträge

Das Paper leistet drei wesentliche Beiträge:

1. Analyse von Quantum-HPC-Stacks: Eine detaillierte Gegenüberstellung der neun führenden Frameworks, die gemeinsame architektonische Muster und kritische Unterschiede identifiziert.
2. Rahmenwerk für Anforderungen: Ein strukturiertes Design-Schema, das Deployment-Umgebungen, Hardware-Modalitäten, Anwendungsmuster und die verschiedenen Ären des Quantencomputings abdeckt.
3. Einführung der openQSE-Referenzarchitektur: Ein community-getriebener, herstellerneutraler Vorschlag für eine geschichtete Referenzarchitektur (open Quantum-HPC Software Ecosystem), die als Blaupause für eine einheitliche Ökosystem-Entwicklung dient.

4. Ergebnisse und die openQSE-Architektur

Die Analyse zeigt, dass sich die Stacks in grundlegenden Schichten (Anwendung, Runtime, Compiler, Hardware-Steuerung) ähneln, aber in der Implementierung der Schnittstellen stark variieren. Als Antwort darauf wird openQSE vorgeschlagen.

Die openQSE-Architektur besteht aus fünf logischen Teilen und definiert stabile Schnittstellen, um Interoperabilität bei gleichzeitiger Flexibilität der Implementierung zu gewährleisten:

• HPC-Control-Plane: Dient als logische Steuerungsebene für Job-Submission und Ressourcen-Abstraktion. Sie entkoppelt die Jobspezifikation von spezifischen Ressourcenmanagern (z. B. Slurm).
• Quantum Access Nodes: Der operative Einstiegspunkt für Workflows, der hybride Skripte hosten und direkten Zugriff auf Quantenressourcen ermöglichen kann.
• HPC/Classical Compute Nodes: Führen klassische Berechnungen aus und nutzen dieselben Runtime-Schnittstellen wie die Access Nodes.
• Quantum Resources: Umfasst die QPUs, die direkte QPU-Unterstützung, das Quantum Program Scheduling und die Multi-Tenancy-Steuerung.
• Gemeinsame Infrastruktur: Netzwerk und Datenspeicherung für Datenbewegung und Persistenz.

Wichtige Komponenten der Architektur:

• Quantum Runtime Interface (QRI): Eine anwendungsfreundliche Schnittstelle (ähnlich wie HIP für GPUs), die Anwendungslogik von anbieterspezifischen Details trennt. Sie unterstützt ressourcenbewusste Einreichung und Lebenszyklusmanagement.
• QHPC-Interconnect API: Eine bidirektionale Schnittstelle zwischen Rechenelementen, die nicht nur Einreichung und Ergebnisabruf, sondern auch Upstream-Signalisierung (Events, Callbacks, Anpassungsanfragen) ermöglicht.
• Compiler/Tool-Pipeline: Ein modellierter Ansatz für Transformationen und Compiler-Passes, der Reproduzierbarkeit und Wiederverwendbarkeit über verschiedene Frameworks hinweg sicherstellt.
• Steuerungselektronik (Control Electronics): Wird als architektonische Ebene betrachtet, die die Grenze zwischen physikalischer Zeitdomäne (PTD) und deterministischer Zeitdomäne (DTD) bildet. Dies ist entscheidend für FTQC, wo Echtzeit-Feedback und Fehlerkorrektur (QEC) innerhalb strenger Zeitfenster erfolgen müssen.

Die Architektur ist so gestaltet, dass sie sowohl aktuelle NISQ-Workloads als auch zukünftige FTQC-Systeme unterstützt, ohne dass sich die Schnittstellen für die oberen Anwendungsschichten ändern müssen.

5. Bedeutung und Ausblick

• Einheitlichkeit: openQSE bietet einen Weg, um die derzeitige Fragmentierung zu überwinden und eine gemeinsame Community-Architektur zu etablieren, ohne existierende SDKs oder proprietäre Stacks zu ersetzen.
• Zukunftssicherheit: Durch die Trennung von Hardware-spezifischen Details und höheren Abstraktionsebenen ermöglicht die Architektur einen nahtlosen Übergang von NISQ zu FTQC.
• Interoperabilität: Die definierten Schnittstellen (QRI, QHPC-Interconnect) ermöglichen es, Komponenten verschiedener Anbieter zu kombinieren und hybride Workflows effizienter zu gestalten.

Einschränkungen und zukünftige Arbeiten:
Die Analyse basiert auf dem Stand von April 2026 und öffentlich dokumentierten Informationen. openQSE ist derzeit ein konzeptionelles Referenzmodell; die konkreten Schnittstellenverträge müssen noch spezifiziert werden. Zukünftige Arbeiten umfassen quantitative Leistungsanalysen (Latenz, Durchsatz) und die Entwicklung einer Referenzimplementierung, um Interoperabilitätsprobleme frühzeitig zu identifizieren und iterativ zu verbessern.

Zusammenfassend stellt dieses Paper einen Meilenstein dar, um die Entwicklung von Quanten-HPC-Systemen von isolierten, proprietären Lösungen hin zu einem interoperablen, standardisierten Ökosystem zu führen.