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

Dit artikel presenteert HPC-vQPU, een service-exportarchitectuur die veilige, apparaatgetrouwe virtuele QPU-simulatie op batch-geplande HPC-systemen mogelijk maakt door een cloudgerichte besturingslaag te ontkoppelen van een op HPC-residerende uitvoeringslaag met behulp van uitgaande coördinatie en onveranderlijke, kalibratiebewuste apparaatsnapschoten.

De kern

Het Grote Probleem: Twee Verschillende Werelden

Stel je voor dat je een zeer krachtige, high-tech keuken hebt (een Supercomputer) die enorme maaltijden voor duizenden mensen tegelijk kan bereiden. Deze keuken heeft echter strikte regels:

1. Geen Toegang voor Buitenstaanders: Je kunt niet zomaar binnenlopen en een maaltijd bestellen. Je moet een formulier invullen, in de rij staan, en het keukenpersoneel begint pas te koken wanneer er een vrij fornuis is.
2. Geen Direct Contact: Zodra je eten in de keuken wordt bereid, zijn de chefs geïsoleerd. Ze kunnen je niet bellen om vragen te stellen of te vertellen hoe het gaat. Ze kunnen alleen een briefje sturen wanneer ze klaar zijn.

Nu stel je je voor dat je een Kwantumwetenschapper bent. Je wilt een zeer specifieke, delicate experiment (een "Kwantumkring") uitvoeren die een specifieke set ingrediënten en een specifieke kookstijl vereist (kalibratie en topologie). Je verwacht een dienst waarbij je kunt zeggen: "Bereid dit gerecht op het 'IBM Fez'-fornuis," en het resultaat direct terugkrijgt.

Het Conflict: De wetenschapper wil een interactieve ervaring van "bestellen-en-wachten". De Supercomputer biedt alleen een ervaring van "formulier-invullen-en-in-de-rij-staan". Als je probeert de keuken te dwingen direct met je te praten, schend je de beveiligingsregels van de keuken.

De Oplossing: HPC-VQPU

De auteurs hebben een systeem gebouwd dat HPC-VQPU heet om deze kloof te overbruggen. Denk hierbij aan een Slimme Kellner die precies weet hoe hij zowel met de wetenschapper als met de keuken moet praten zonder regels te breken.

Hier is hoe het werkt, stap voor stap:

1. Het Tweeledige Team

Het systeem is opgesplitst in twee verschillende rollen, net zoals een restaurant een Voorhuis en een Achterhuis heeft.

• Het Control Plane (Voorhuis): Dit is het deel waarmee de wetenschapper praat. Het lijkt op een normale, vriendelijke app. Het neemt je bestelling aan, controleert of je ingrediënten geldig zijn, en geeft je een bon. Het bevindt zich buiten de beveiligde keuken.
• Het Execution Plane (Achterhuis): Dit is het deel binnen de beveiligde keuken. Het is een nederige "Runner" (een agent) die op de entreebalie van de keuken zit. Het kan niet bellen naar het Voorhuis; het kan alleen vragen aan het Voorhuis om werk.

2. De "Alleen Uitgaand"-Regel (De Eenrichtingsdeur)

De keuken heeft een strikt beveiligingsbeleid: Niemand binnenin mag naar buiten bellen om een gesprek te starten. De buitenwereld kan ook niet naar binnen bellen.

• Hoe HPC-VQPU dit oplost: De Runner binnenin de keuken blijft tegen de deur kloppen (pollen) en vragen: "Heb je bestellingen voor mij?"
• Het Voorhuis belt de Runner nooit. Het wacht gewoon tot de Runner vraagt. Dit houdt de keuken veilig omdat er geen "achterdeurtjes" worden geopend.

3. Het "Snapshot"-Contract (Het Bevroren Recept)

Dit is het belangrijkste deel van het paper.

• Het Probleem: Kwantumcomputers zijn als levende wezens; hun "smaak" (kalibratie) verandert elke dag. Als je vandaag een gerecht bestelt, maar de keuken begint pas morgen met koken, kunnen de ingrediënten zijn veranderd en smaakt het gerecht niet goed.
• De Oude Manier: Als je gewoon een verzoek stuurde, zou de keuken het recept misschien op het moment dat het begint te koken opzoeken. Maar tegen die tijd kan het recept zijn veranderd, of kan de keuken te druk zijn om het op te zoeken.
• De HPC-VQPU Manier: Wanneer de Runner om een bestelling vraagt, geeft het Voorhuis niet alleen "Ga dit koken". Het overhandigt een Bevroren Receptkaart (een "Snapshot").
  • Deze kaart bevat de exacte staat van de ingrediënten, de fornuisinstellingen en de kookinstructies op het exacte moment dat de Runner de bestelling aannam.
  • De Runner neemt deze kaart, gaat de geïsoleerde keuken binnen, en kookt alleen met die kaart. Het hoeft het recept niet opnieuw op te zoeken.
  • Waarom dit belangrijk is: Zelfs als het hoofdreceptenboek van de keuken een uur later verandert, wordt jouw gerecht bereid met het "Bevroren Recept" dat je kreeg. Het resultaat is gegarandeerd consistent met de specifieke "Virtuele Kwantumcomputer" die je hebt aangevraagd.

4. De "Claim" (Eigenaarschap Aannemen)

Stel je een drukke keuken voor met twee runners.

• Het Risico: Als beide runners op hetzelfde moment om dezelfde bestelling vragen, proberen ze allebei het gerecht te koken, wat ingrediënten verspillen en twee verschillende resultaten oplevert.
• De Oplossing: Het Voorhuis heeft een speciaal slot. Wanneer een Runner om werk vraagt, zegt het Voorhuis: "Oké, JIJ hebt deze bestelling nu." Het markeert de bestelling direct als "Overgenomen" en geeft de Bevroren Receptkaart aan die specifieke Runner.
• Als een andere Runner een seconde later om dezelfde bestelling vraagt, zegt het Voorhuis: "Sorry, dat is al overgenomen." Dit zorgt ervoor dat de taak precies één keer wordt uitgevoerd.

5. De "Hartslag" (Afbellen)

Omdat de keukenrunners niet naar buiten kunnen bellen, hoe weet het Voorhuis dan dat ze nog in leven zijn?

• De Runner stuurt elke paar seconden een klein "Ik ben er nog" signaal (een hartslag).
• Als de Runner crasht of verdwijnt, merkt het Voorhuis dat de hartslagen stoppen. Het raakt niet in paniek; het wacht gewoon tot een menselijke manager zegt: "Oké, laten we die bestelling aan een andere Runner geven." Dit voorkomt dat het systeem vastloopt of data verliest.

Wat Hebben Ze Bewezen?

De auteurs hebben dit systeem getest op een echte supercomputer (Setonix) en bewezen:

1. Het is Snel Genoeg: De "kellner" vertraagt het koken niet. De extra tijd die wordt toegevoegd is minimaal en wordt niet erger naarmate het koken moeilijker wordt.
2. Het is Accuraat: De "Bevroren Recept" werkt. Toen ze gebruik maakten van real-world data die verandert, kookte het systeem het gerecht met het huidige recept op het moment van bestellen, niet met een oud exemplaar.
3. Het is Veilig: Zelfs als de Runner crasht, weet het systeem precies wat er is gebeurd en kan het herstellen zonder de bestelling te verliezen of het gerecht twee keer te koken.
4. Het is Veilig (Beveiliging): Het werkt perfect zonder ooit de beveiligingsregels van de supercomputer te schenden (niemand binnenin belt naar buiten om een gesprek te starten).

Samenvatting

HPC-VQPU is een slimme manier om wetenschappers een superkrachtige, beveiligde supercomputer te laten gebruiken alsof het een vriendelijke, interactieve kwantumcomputer is. Dit doet het door een "Runner" te gebruiken die om werk vraagt, "Bevroren Receptkaarten" uitdeelt zodat het koken consistent is, en ervoor zorgt dat niemand de strikte beveiligingsregels van de keuken schendt. Het zet een stijf, bureaucratisch systeem om in een soepele, betrouwbare dienst.

Technische samenvatting

Technische Samenvatting: HPC-VQPU

Probleemstelling

Het artikel behandelt de fundamentele mismatch tussen de eisen van apparaatbewuste kwantum-simulatie en de operationele beperkingen van beveiligde, in batches geplande High-Performance Computing (HPC)-systemen. Hoewel modern kwantumonderzoek steeds meer afhankelijk is van simulatoren die specifieke apparaattopologieën, native gate-sets en uit kalibratie afgeleide ruisparameters modelleren, is HPC-infrastructuur ontworpen voor uitvoering via een scheduler in plaats van voor interactieve, apparaatgerichte diensten.

Drie primaire uitdagingen voorkomen de directe export van kwantum-simulatie als dienst vanuit HPC-omgevingen:

1. Connectiviteitsinversie: Beveiligde HPC-clusters verbieden doorgaans inkomende verbindingen naar rekenknooppunten. Kwantumontwikkelaars verwachten circuits in te dienen bij een benoemde backend en resultaten interactief op te halen, maar HPC-beveiligingsmodellen staan alleen uitgaande communicatie vanaf inlogknooppunten toe. Een standaard "push"-model waarbij een dienst taken naar werknodes doorstuurt, is structureel niet beschikbaar.
2. Semantische Behoud: Een "virtuele QPU" is niet louter een circuit-uitvoerder; het is een software-gedefinieerd eindpunt dat topologie, kalibratie en ruisbeperkingen blootlegt. In een batchesysteem kan een taak uren in een wachtrij liggen terwijl de kalibratietoestand van het apparaat verandert. Als de uitvoersemantiek niet gebonden is aan een specifiek tijdstip, kan het resultaat niet langer overeenkomen met het gevraagde virtuele apparaat, waardoor de simulatie wetenschappelijk ongeldig wordt voor compilerontwikkeling of routingstudies.
3. Operationele Complexiteit: Batches-gemedieerde uitvoering introduceert een faaloppervlak dat verder gaat dan eenvoudige applicatiefouten, waaronder schedulervertragingen, knooppuntfouten, verdwijnen van agenten en misvormde artefacten. Een levensvatbare dienst moet interactieve levenscyclussemantiek (indienen, monitoren, ophalen) verenigen met de gedeeltelijke waarneembaarheid en asynchrone aard van HPC-taakplanning.

Methodologie en Architectuur

De auteurs stellen HPC-VQPU voor, een service-exportarchitectuur die serviceautoriteit scheidt van scheduler-gedreven uitvoering. Het systeem is georganiseerd in twee distincte vlakken die uitsluitend communiceren via uitgaande, door agenten geïnitieerde berichten, waarbij de HPC-beveiligingsgrens behouden blijft.

1. Twee-Vlak Decompositie

• Besturingsvlak (Cloud-gericht): Gehost extern aan het HPC-cluster, beheert dit vlak de API, taaklevenscyclus, apparaatidentiteit en projectie van gebeurtenissen. Het is autoritair voor taakstatus, maar bevat geen scheduler-gerichte functionaliteit of inkomende connectiviteit naar het cluster.
• Uitvoervlak (HPC-resident): Geïmplementeerd door een niet-bevoegde vqpu_agent die draait op een HPC-inlogknooppunt. Deze agent initieert alle coördinatie. Hij polst het besturingsvlak op werk, claimt taken, dient taken in bij de scheduler (bijv. Slurm) en rapporteert resultaten. Hij bezit geen duurzame service-waarheid en is bij herstart reconstrueerbaar.

2. Het Snapshot-contract

De kernabstractie is de apparaatsnapshot ($\Delta$), een graf-structureerde representatie van een virtueel apparaat dat topologie, native gates en kalibratieparameters (coherentietijden, foutpercentages) bevat.

• Binding bij Claim-tijd: Om de spanning tussen wachtrijvertraging en kalibratieversheid op te lossen, wordt de snapshot atomair gebonden op het moment van claimen, niet bij indiening. Wanneer een agent een taak claimt, draagt het besturingsvlak de eigendom over en levert de onveranderlijke snapshot ($\delta_i$) als onderdeel van het uitvoercontract.
• Hermetische Uitvoering: De runner op het rekenknooppunt ontvangt een lokaal payload met het circuit en de gebonden snapshot. Het voert de simulatie uit (bijv. met Qiskit-Aer/cuQuantum) volledig offline, waarbij ruismodellen worden afgeleid uit de snapshot zonder contact met het besturingsvlak. Dit zorgt ervoor dat uitvoersemantiek invariant blijft ten opzichte van apparaatstatuswijzigingen die plaatsvinden na het claimen.

3. Taaklevenscyclus en Protocol

Het systeem maakt gebruik van een vijfstaten-taakautomaton ($\{QUEUED, RUNNING, COMPLETED, FAILED, CANCELLED\}$) beheerd door het besturingsvlak.

• Asymmetrisch Protocol: De agent initieert CLAIM, HEARTBEAT en REPORT-operaties. Het besturingsvlak duwt nooit status naar binnen.
• Atomair Eigendom: De CLAIM-operatie is het linearisatiepunt voor eigendom. Het schakelt een taak atomair over van QUEUED naar RUNNING en wijst een unieke eigenaar toe, waardoor dubbele uitvoering door concurrerende agenten wordt voorkomen.
• Herstel: Als een agent faalt, blijft de taak in RUNNING met een verouderde eigenaar. Herstel vereist een expliciete administratieve actie (bijv. REQUEUE), zodat ambiguïteit niet stilzwijgend wordt opgelost en de uitvoeringslijn behouden blijft.

Belangrijkste Bijdragen

Het artikel presenteert vier hoofd bijdragen:

1. Service-Export Architectuur: Een decompositie in besturings-/uitvoervlakken die connectiviteitsinversie oplost via uitsluitend uitgaande coördinatie, waardoor beveiligde HPC-systemen apparaatbewuste simulatie kunnen exporteren zonder hun beveiligingspositie te verzwakken.
2. Apparaatsnapshot Abstractie: Een portable, graf-structureerd uitvoercontract dat topologie en kalibratiesemantiek atomair bindt op het moment van claimen, zodat geplande taken trouw blijven aan de gevraagde virtuele apparaatstatus.
3. Scheduler-bewuste Levenscyclus: Een vijfstaten-taakautomaton met een asymmetrisch claim/rapport/hartslagprotocol dat interactieve servicsemantiek verenigt met batches-gemedieerde uitvoering en gedeeltelijke waarneembaarheid.
4. Referentie-implementatie en Validatie: Een productie-implementatie op het Pawsey Supercomputing Research Centre met Setonix-GPU's, Qiskit-Aer en IBM Fez-kalibratiegegevens, die de haalbaarheid van de architectuur aantoont.

Experimentele Resultaten

De auteurs valideren de architectuur via regressietests en end-to-end productie-experimenten, met de volgende resultaten:

• Beperkte Overhead: Service-exportoverhead is additief en begrensd. Interface-zichtbare latentie (toelating en polling) blijft constant (~0,4s toelating, ~22-27s wachtrij-naar-claim) ongeacht de circuitgrootte (28–32 qubits). De exponentiële schaling van simulatie blijft beperkt tot het rekensubstraat.
• Kalibratietrouw: Experimenten met echte IBM Fez-kalibratiegegevens versus ideale (null) snapshots tonen aan dat de snapshotinhoud de uitgangsverdelingen direct beïnvloedt. Het systeem propagatieert correct uit kalibratie afgeleide ruisparameters naar de simulator.
• Binding bij Claim-tijd: Wanneer de kalibratie van een apparaat administratief wordt gewijzigd na indiening maar voor claim, voert het systeem de taak correct uit met de post-wijzigings (ideale) status. Dit bevestigt dat de snapshot gebonden is op het moment van claimen, wat verouderde uitvoering voorkomt.
• Concurrentie en Integriteit: In een multi-agenttest met 50 taken en twee concurrerende agenten werden alle taken precies één keer voltooid met een bijna gelijke verdeling (24:26). Er traden geen dubbele claims of ambigu eigendom op.
• Herstel: Na een agentcrash werden drie RUNNING-taken succesvol hersteld via expliciete herindiening, voltooid zonder dubbele uitvoering of stilzwijgende herinterpretatie van status.

Betekenis en Claims

Het artikel stelt dat HPC-VQPU aantoont dat beveiligde, in batches geplande supercomputers semantisch rijke, interactieve diensten kunnen exporteren zonder op te houden als HPC-systemen te functioneren. De betekenis ligt in het vermogen om apparaattrouw (topologie, native gates, kalibratie) over de schedulergrens te behouden.

De auteurs positioneren dit werk niet als een prestatieoptimalisatie voor simulatiekernen, maar als een systeemoplossing voor de servicegrens. Door de apparaatsnapshot te behandelen als een eerstelijns, tijd-geïndexeerd contract, maakt de architectuur kwantumsoftware-workflows (compiler-evaluatie, routing, ruisstudies) in staat om te interageren met HPC-bronnen alsof het interactieve virtuele QPUs zijn. De ontwerp-invarianten (uitsluitend uitgaande connectiviteit, atomair claimen, hermetische uitvoering) worden gepresenteerd als noodzakelijke voorwaarden om resultaten wetenschappelijk interpreteerbaar te maken als uitvoering op een specifiek virtueel apparaat, zelfs in het licht van wachtrijvertragingen en infrastructuurfouten.

Het artikel concludeert bescheiden, met erkenning dat de evaluatie is gericht op een enkele productielocatie en simulatiepad, en dat de architectuur autoritaire levenscyclussemantiek biedt in plaats van een bewijs van "exact-één-keer"-uitvoering in de volledige zin van gedistribueerde systemen. Het stelt echter dat de voorgestelde scheiding van autoriteit en realisatie een levensvatbaar pad biedt voor het integreren van HPC-schaal simulatie in het interactieve kwantumsoftware-ecosysteem.