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

Dit artikel analyseert bestaande quantum-HPC softwarestapels om gemeenschappelijke behoeften te identificeren en stelt de openQSE-referentiearchitectuur voor als een eerste stap naar een verenigd ecosysteem dat interoperabiliteit mogelijk maakt voor zowel huidige NISQ- als toekomstige FTQC-systemen.

De kern

🌌 De Grote Quantum-HPC Verbinding: Een Reis naar de Toekomst

Stel je voor dat Quantumcomputers een soort van superkrachtige, maar zeer eigenzinnige muzikanten zijn. Ze kunnen prachtige symfonieën spelen die normale computers niet eens kunnen dromen. Maar ze spelen alleen maar als ze precies weten wat er moet gebeuren, op het juiste moment, en met de juiste instrumenten.

Aan de andere kant hebben we HPC (High-Performance Computing), de enorme orkesten van klassieke computers die al decennia lang de zware werklasten van de wetenschap en industrie draaien.

Het probleem? Tot nu toe proberen deze twee groepen samen te werken alsof ze in verschillende talen spreken, met verschillende bladmuziek en zonder een dirigent. De ene quantumcomputer gebruikt een ander systeem dan de andere, en elke supercomputercentrale bouwt zijn eigen brug naar de quantumwereld. Dit zorgt voor een enorme rompslomp: het is duur, traag en moeilijk om te verplaatsen.

Dit artikel is als het ontwerpen van een universele taal en een gemeenschappelijk orkestplan (de openQSE).

1. Het Huidige Probleem: De "Babel" van Software

Op dit moment is de wereld van quantumcomputers een beetje als een stad waar elke wijk zijn eigen regels heeft.

• Als je een quantumcomputer van Amazon wilt gebruiken, moet je hun specifieke app en regels volgen.
• Wil je IBM of IonQ gebruiken? Dan moet je weer een andere taal leren en een andere sleutel in het slot steken.

Wetenschappers moeten hierdoor steeds opnieuw hun werk aanpassen. Het is alsof een kok elke keer dat hij van restaurant wisselt, zijn hele keuken moet herbouwen en nieuwe potten en pannen moet kopen, in plaats van gewoon met zijn eigen messen te kunnen koken.

2. De Oplossing: De "openQSE" Blauwdruk

De auteurs van dit artikel (een groep experts van grote laboratoria en bedrijven) hebben gekeken naar negen verschillende bestaande systemen. Ze hebben gekeken naar hoe deze systemen werken, wat ze gemeen hebben en waar ze verschillen.

Hun conclusie? Er zijn veel overeenkomsten, maar ze zijn verspreid. Dus hebben ze een referentie-architectuur bedacht, genaamd openQSE (Open Quantum-HPC Software Ecosystem).

De Metafoor: Het Universele Stopcontact
Stel je openQSE voor als een universeel stopcontact en stekker.

• Vroeger had je voor elk apparaat een ander stopcontact nodig.
• Met openQSE wordt er een standaard ontworpen. Of je nu een quantumcomputer van Amazon, IBM of een klein start-upbedrijf gebruikt: de "stekker" (de software-interface) past altijd in het "stopcontact" (de HPC-omgeving).
• Hierdoor kan een wetenschapper zijn programma schrijven, en het werkt gewoon, ongeacht welke quantumcomputer er achter de schermen draait.

3. Hoe Werkt Dit Nieuwe Systeem? (De Drie Lagen)

Het artikel beschrijft hoe dit nieuwe systeem eruit ziet, alsof je een gebouw bouwt met drie verdiepingen:

• De Bovenverdieping (De Applicatie): Hier werken de wetenschappers. Ze zien alleen hun eigen programma. Ze hoeven niet te weten of ze een "ijskoude atoom-computer" of een "elektrische chip-computer" gebruiken. Het is alsof ze een afstandsbediening gebruiken die altijd hetzelfde doet, ongeacht welk merk televisie er onder zit.
• De Middenverdieping (De Regisseur): Dit is de slimme laag die de vertaling doet. Hij kijkt naar de opdracht en zorgt dat deze wordt omgezet in de juiste taal voor de specifieke quantumcomputer. Hij zorgt ook voor de "verkeersregels": wie mag er nu spelen? Is de machine bezig met kalibreren (afstellen)?
• De Onderverdieping (De Hardware): Hier zitten de echte quantumchips. Ze doen hun werk, maar ze praten niet direct met de wetenschapper. Ze praten met de regisseur.

4. Twee Manieren om te Werken

Het artikel onderscheidt twee manieren waarop mensen met deze systemen werken:

1. Het "Reisplan" (Workflow-centric): Je stuurt een groot project in. De computer doet stap 1, wacht even, doet stap 2, en geeft het resultaat terug. Dit is zoals het sturen van een pakketje: je geeft het in, en later krijg je het terug.
2. Het "Directe Gesprek" (Accelerator-centric): De klassieke computer praat terwijl hij werkt direct met de quantumcomputer. Het is alsof een dirigent direct met de vioolspeler fluistert om de snelheid aan te passen. Dit is sneller, maar vereist dat ze heel dicht bij elkaar zitten (lage vertraging).

5. Waarom is dit belangrijk voor de Toekomst?

We staan nu in de "NISQ-tijdperk": quantumcomputers zijn nog wat "ruisig" (ze maken fouten). Maar in de toekomst komen de "FTQC-systemen": foutloze, superkrachtige quantumcomputers.

Het mooie van deze nieuwe blauwdruk (openQSE) is dat hij toekomstbestendig is.

• Metafoor: Het is alsof je een auto bouwt met een standaard stuur en pedalen. Of je nu een benzineauto (nu) of een elektrische auto (toekomst) onder de motorkap zet, jij als bestuurder hoeft je stuur niet te veranderen. De software blijft hetzelfde, alleen de "motor" eronder wordt krachtiger en slimmer.

Conclusie

Kortom: Dit artikel zegt dat we stoppen met het bouwen van honderden verschillende bruggen naar de quantumwereld. In plaats daarvan bouwen we één grote, flexibele brug (openQSE).

Dit zorgt ervoor dat:

• Wetenschappers makkelijker kunnen samenwerken.
• Bedrijven hun technologie makkelijker kunnen verkopen.
• We klaar zijn voor de toekomst, wanneer quantumcomputers echt de wereld gaan veranderen.

Het is de eerste stap naar een wereld waar quantumcomputers net zo gewoon zijn als je laptop, en waar iedereen ze op dezelfde manier kan gebruiken. 🚀

Technische samenvatting

Titel

Quantum-HPC Software Stacks en de openQSE Referentiearchitectuur: Een Survey

1. Probleemstelling

Quantumcomputers worden steeds vaker geïntegreerd in High-Performance Computing (HPC) en cloud-omgevingen. Echter, de huidige softwarestapels voor Quantum High-Performance Computing (QHPC) blijven geïsoleerd en zijn vaak proprietair. Er ontbreekt een gemeenschappelijke interface tussen de verschillende lagen: runtime, resource management, orchestration en execution.

De huidige integratie leidt tot:

• Fragmentatie: Veel provider-specifieke interfaces en aannames die verschillen tussen cloud en on-premises omgevingen.
• Hoge onderhoudskosten: Sites bouwen vaak vergelijkbare integratielogica opnieuw voor taakindiening, resourcebeschrijving en beveiliging.
• Gebrek aan portabiliteit: Dit vertraagt vergelijkende evaluaties en maakt het moeilijk voor applicaties en operationele teams om tussen verschillende systemen te migreren.
• Schalingsasymmetrie: HPC-capaciteit schaalt modulair (racks, nodes, cores), terwijl QPU-capaciteit schaalt via kwantumbits die schaars en sterk gekoppeld zijn. Quantum-informatie kan niet worden gekopieerd, wat betekent dat het niet preemptief kan worden gepland of checkpointed. Dit vereist fundamenteel andere scheduling- en resource-managementbenaderingen.

2. Methodologie

De auteurs hebben een survey uitgevoerd van de huidige state-of-the-practice in QHPC-softwarestapels.

• Onderzoeksscope: Negen representatieve productie-QHPC-stapels werden geanalyseerd, ontwikkeld door zowel industrie als onderzoek (AWS, IBM, IonQ, JHPC-Quantum, MQSS, Pasqal, Quantinuum, Quantum Brilliance, en Xanadu).
• Classificatie-aspecten: De stapels werden beoordeeld langs vier classificatie-asen:
  1. Deploymentsomgeving: Cloud, on-premises, en federatie (combinaties hiervan).
  2. Quantum-hardware modaliteit: Verschillende technologieën zoals supergeleidende qubits, gevangen ionen, neutrale atomen, fotonische systemen, etc.
  3. Applicatie-interactiepatronen:
     • Workflow-centric: Onafhankelijke klassieke en quantumstadia die door een workflow-engine worden gecoördineerd.
     • Accelerator-centric: Strakke koppeling waarbij quantumkernels worden aangeroepen tijdens de uitvoering van een HPC-programma (analoog aan GPU-offload).
  4. Doelquantumcomputing-era: Ondersteuning voor NISQ (Noisy Intermediate-Scale Quantum) en/of FTQC (Fault-Tolerant Quantum Computing).
• Analyse: De auteurs identificeerden gemeenschappelijke ontwerppatronen, interfaces en beperkingen, en mapten deze naar een gemeenschappelijk blauwdruk.

3. Belangrijkste Bijdragen

Het paper levert drie hoofdbijdragen:

1. Analyse van Quantum-HPC Stapels: Een uitgebreide review van negen frameworks die leidt tot een convergentiematrix (Tabel 1 in het paper). Dit toont waar de sector convergeert (bijv. OpenQASM 3, QDMI) en waar er nog divergentie is.
2. Requirements Framework: Een gestructureerd raamwerk dat deploy-omgevingen, hardware-modaliteiten, applicatiepatronen en de evolutie van NISQ naar FTQC omvat.
3. openQSE Referentiearchitectuur: De introductie van de open Quantum-HPC Software Ecosystem (openQSE). Dit is een vendor-neutrale, gelaagde referentiearchitectuur die:
   • Een holistisch beeld biedt van het geïntegreerde QHPC-systeem zonder eigendom van specifieke lagen toe te wijzen aan vendors.
   • Implementatieflexibiliteit behoudt terwijl het interfaces stabiliseert voor portabiliteit en interoperabiliteit.
   • Ontworpen is om zowel huidige NISQ-werklasten als toekomstige FTQC-systemen te ondersteunen zonder wijzigingen in de bovenste applicatielagen.

4. Resultaten en Kerninzichten

Uit de analyse van de negen stapels komen de volgende inzichten en patronen naar voren:

• Gelaagde Scheiding: De meest consistente patroon is een scheiding tussen applicaties, runtime-services, compilatie en hardware-gerichte besturing.
• Twee Cruciale Interfaces: Er is een duidelijke trend naar het ontkoppelen van interfaces via:
  • QDMI (Quantum Device Management Interface): Een C-niveau standaard voor interactie met quantumapparaten (device discovery, job lifecycle).
  • QRMI (Quantum Resource Management Interface): Een vendor-neutrale interface voor resource-acquisitie en scheduling binnen HPC-systemen (zoals Slurm).
• Timing-Domeinen: Voor FTQC is een strikte scheiding van timing-domeinen essentieel:
  • PTD (Physical Timing Domain): Waveform-niveau interactie.
  • DTD (Deterministic Timing Domain): Hardware-lokale besturing en snelle feedback (QEC).
  • RTD (Real-Time Domain): Gebonden-latentie klassieke verwerking.
  • ATD (Application Time Domain): Abstrahering voor de gebruiker.
• Observability: Telemetrie en observability zijn geen optionele features meer, maar architecturale vereisten voor debugging, scheduling en operaties.

De openQSE Architectuur:
De voorgestelde architectuur bestaat uit vijf logische onderdelen:

1. HPC Control Plane: Voor taakindiening en resource-abstractie (Job Submission Abstraction).
2. HPC/Classical Compute Nodes: Waar hybride applicaties draaien.
3. Quantum Access Nodes: Operationele toegangspunten met directe toegang tot QPU's.
4. Quantum Resources: De fysieke QPU's en hun ondersteunende klassieke laag.
5. Shared Infrastructure: Netwerk en data-persistentie.

Belangrijke componenten in openQSE zijn:

• Quantum Runtime Interface (QRI): Scheidt applicatielogica van vendor-specifieke details (vergelijkbaar met HIP voor GPU's).
• QHPC-Interconnect API: Een bidirectionele interface voor communicatie tussen compute-elementen (submit, callback, adaptatie).
• Tool/Compiler Pipeline: Een beheerd model voor transformaties en compilatiepasses.
• Control Electronics: Behandeld als een architecturale laag die grenst aan de fysieke wereld, essentieel voor QEC en feedback.

5. Significantie

Deze survey en de voorgestelde openQSE-architectuur zijn van groot belang voor de toekomst van quantumcomputing in HPC:

• Standaardisatie: Het biedt een gemeenschappelijk blauwdruk om de huidige fragmentatie te overwinnen, wat leidt tot interoperabiliteit tussen verschillende vendors en HPC-centra.
• Toekomstbestendigheid: De architectuur is ontworpen om de transitie van NISQ naar FTQC soepel te laten verlopen zonder dat applicaties herschreven hoeven te worden.
• Efficiëntie: Door het definiëren van duidelijke grenzen en interfaces, kunnen HPC-centra quantumresources efficiënter plannen, beheren en integreren in bestaande workflows.
• Community-gericht: Het initiatief is bedoeld om door de community (vendors, centra, gebruikers) te worden aangedreven, wat de adoptie van standaarden zoals QDMI en QRMI zal versnellen.

Kortom, het paper schetst de weg van een gefragmenteerde markt van gesloten oplossingen naar een open, modulair en interoperabel ecosysteem voor hybride quantum-klassieke computing.