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

Ce papier présente HPC-vQPU, une architecture d'exportation de services qui permet une simulation virtuelle fidèle aux appareils et sécurisée de QPU sur des systèmes HPC planifiés par lots, en découplant un plan de contrôle orienté vers le cloud d'un plan d'exécution résident dans le HPC à l'aide d'une coordination sortante et de snapshots d'appareils immuables et conscients de l'étalonnage.

L'essentiel

Le Grand Problème : Deux Mondes Différents

Imaginez que vous possédez une cuisine très puissante et high-tech (un Superordinateur) capable de préparer d'énormes repas pour des milliers de personnes à la fois. Cependant, cette cuisine a des règles strictes :

1. Pas d'entrée directe : Vous ne pouvez pas simplement entrer et commander un repas. Vous devez remplir un formulaire, faire la queue, et le personnel de la cuisine ne commencera à cuisiner que lorsqu'une plaque de cuisson sera libre.
2. Pas de contact direct : Une fois votre nourriture en cours de cuisson dans la cuisine, les chefs sont isolés. Ils ne peuvent pas vous appeler au téléphone pour poser des questions ou vous dire comment ça va. Ils ne peuvent envoyer un message que lorsqu'ils ont terminé.

Maintenant, imaginez que vous êtes un Scientifique Quantique. Vous souhaitez mener une expérience très spécifique et délicate (un « Circuit Quantique ») qui nécessite un ensemble précis d'ingrédients et un style de cuisson particulier (calibration et topologie). Vous attendez un service où vous pouvez dire : « Préparez ce plat sur la plaque « IBM Fez » », et obtenir le résultat instantanément.

Le Conflit : Le scientifique souhaite une expérience interactive de type « commande et attente ». Le Superordinateur n'offre qu'une expérience de type « remplissez-un-formulaire-et-attendez-en-queue ». Si vous essayez de forcer la cuisine à vous parler directement, vous enfreignez les règles de sécurité de la cuisine.

La Solution : HPC-VQPU

Les auteurs ont créé un système appelé HPC-VQPU pour combler ce fossé. Imaginez-le comme un Serveur Intelligent qui sait exactement comment parler au scientifique et à la cuisine sans enfreindre aucune règle.

Voici comment cela fonctionne, étape par étape :

1. L'Équipe en Deux Parties

Le système est divisé en deux rôles distincts, tout comme un restaurant possède une Salle et une Cuisine.

• Le Plan de Contrôle (La Salle) : C'est la partie avec laquelle le scientifique communique. Elle ressemble à une application normale et conviviale. Elle prend votre commande, vérifie si vos ingrédients sont valides et vous remet un reçu. Elle réside à l'extérieur de la cuisine sécurisée.
• Le Plan d'Exécution (La Cuisine) : C'est la partie située à l'intérieur de la cuisine sécurisée. C'est un humble « Coureur » (un agent) qui se trouve au bureau d'entrée de la cuisine. Il ne peut pas appeler la Salle ; il ne peut que demander du travail à la Salle.

2. La Règle « Sortie Uniquement » (La Porte à Sens Unique)

La cuisine a une politique de sécurité stricte : Personne à l'intérieur ne peut appeler vers le monde extérieur pour initier une conversation. Le monde extérieur ne peut pas appeler non plus.

• Comment HPC-VQPU résout cela : Le Coureur à l'intérieur de la cuisine continue de frapper à la porte (interrogation) et demande : « Avez-vous des commandes pour moi ? »
• La Salle n'appelle jamais le Coureur. Elle attend simplement que le Coureur demande. Cela maintient la cuisine sécurisée car aucune « porte dérobée » n'est ouverte.

3. Le Contrat « Instantané » (La Recette Gelée)

C'est la partie la plus importante du document.

• Le Problème : Les ordinateurs quantiques sont comme des êtres vivants ; leur « saveur » (calibration) change tous les jours. Si vous commandez un plat aujourd'hui, mais que la cuisine ne commence à le cuisiner que demain, les ingrédients peuvent avoir changé et le plat ne sera pas bon.
• L'Ancienne Façon : Si vous envoyiez simplement une demande, la cuisine pourrait consulter la recette au moment où elle commence à cuisiner. Mais à ce moment-là, la recette peut avoir changé, ou la cuisine peut être trop occupée pour la consulter.
• La Façon HPC-VQPU : Lorsque le Coureur demande une commande, la Salle ne dit pas simplement « Allez cuisiner ceci ». Elle remet une Carte de Recette Gelée (un « Instantané »).
  • Cette carte contient l'état exact des ingrédients, les réglages de la plaque et les instructions de cuisson au moment précis où le Coureur a pris la commande.
  • Le Coureur prend cette carte, entre dans la cuisine isolée et cuisine uniquement en utilisant cette carte. Il n'a pas besoin de consulter la recette à nouveau.
  • Pourquoi cela compte : Même si le livre de recettes principal de la cuisine change une heure plus tard, votre plat est cuisiné en utilisant la « Recette Gelée » qui vous a été donnée. Le résultat est garanti être cohérent avec l'« Ordinateur Quantique Virtuel » spécifique que vous avez demandé.

4. La « Revendication » (Prendre Possession)

Imaginez une cuisine occupée avec deux coureurs.

• Le Risque : Si les deux coureurs demandent la même commande en même temps, ils pourraient tous deux essayer de la cuisiner, gaspillant des ingrédients et obtenant deux résultats différents.
• La Solution : La Salle possède un verrou spécial. Lorsqu'un Coureur demande du travail, la Salle dit : « D'accord, VOUS avez cette commande maintenant ». Elle marque instantanément la commande comme « Prise » et remet la Carte de Recette Gelée à ce Coureur spécifique.
• Si un autre Coureur demande la même commande une seconde plus tard, la Salle dit : « Désolé, c'est déjà pris ». Cela garantit que le travail est effectué exactement une fois.

5. Le « Battement de Cœur » (Vérification)

Puisque les coureurs de la cuisine ne peuvent pas appeler vers l'extérieur, comment la Salle sait-elle qu'ils sont toujours en vie ?

• Le Coureur envoie un petit signal « Je suis toujours là » (un battement de cœur) toutes les quelques secondes.
• Si le Coureur plante ou disparaît, la Salle remarque que les battements de cœur s'arrêtent. Elle ne panique pas ; elle attend simplement qu'un gestionnaire humain dise : « D'accord, donnons cette commande à un autre Coureur ». Cela empêche le système de se bloquer ou de perdre des données.

Qu'Ont-ils Démontré ?

Les auteurs ont testé ce système sur un véritable superordinateur (Setonix) et ont prouvé :

1. C'est assez rapide : Le « serveur » ne ralentit pas la cuisson. Le temps supplémentaire ajouté est minime et ne s'aggrave pas à mesure que la cuisson devient plus difficile.
2. C'est précis : La « Recette Gelée » fonctionne. Lorsqu'ils ont utilisé des données réelles qui changent, le système a cuisiné le plat en utilisant la recette actuelle au moment de la commande, et non une ancienne.
3. C'est sûr : Même si le Coureur plante, le système sait exactement ce qui s'est passé et peut récupérer sans perdre la commande ni la cuisiner deux fois.
4. C'est sécurisé : Cela fonctionne parfaitement sans jamais enfreindre les règles de sécurité du superordinateur (personne à l'intérieur n'appelle pour initier une conversation).

Résumé

HPC-VQPU est une manière ingénieuse de permettre aux scientifiques d'utiliser un superordinateur surpuissant et sécurisé comme s'il s'agissait d'un ordinateur quantique convivial et interactif. Il y parvient en utilisant un « Coureur » qui demande du travail, en distribuant des « Cartes de Recette Gelées » pour assurer une cuisson cohérente, et en veillant à ce que personne ne enfreigne les règles de sécurité strictes de la cuisine. Il transforme un système rigide et bureaucratique en un service fluide et fiable.

Résumé technique

Résumé Technique : HPC-VQPU

Énoncé du Problème

L'article traite du décalage fondamental entre les exigences de la simulation quantique consciente des dispositifs et les contraintes opérationnelles des systèmes de calcul haute performance (HPC) sécurisés et planifiés par lots. Alors que la recherche quantique moderne repose de plus en plus sur des simulateurs modélisant des topologies de dispositifs spécifiques, des ensembles de portes natives et des paramètres de bruit dérivés de l'étalonnage, l'infrastructure HPC est conçue pour une exécution médiatisée par un planificateur plutôt que pour des services interactifs orientés vers les dispositifs.

Trois défis principaux empêchent l'exportation directe de la simulation quantique en tant que service depuis les environnements HPC :

1. Inversion de la Connectivité : Les clusters HPC sécurisés interdisent généralement les connexions entrantes vers les nœuds de calcul. Les développeurs quantiques s'attendent à soumettre des circuits à un backend nommé et à récupérer les résultats de manière interactive, mais les modèles de sécurité HPC n'autorisent que les communications sortantes depuis les nœuds de connexion. Un modèle standard de « poussée » où un service distribue des tâches à des travailleurs est structurellement indisponible.
2. Préservation Sémantique : Un « QPU virtuel » n'est pas simplement un exécuteur de circuits ; c'est un point de terminaison défini par logiciel exposant la topologie, l'étalonnage et les contraintes de bruit. Dans un système par lots, une tâche peut rester dans une file d'attente pendant des heures tandis que l'état d'étalonnage du dispositif change. Si les sémantiques d'exécution ne sont pas liées à un instant précis, le résultat peut ne plus correspondre au dispositif virtuel demandé, rendant la simulation scientifiquement invalide pour le développement de compilateurs ou les études de routage.
3. Complexité Opérationnelle : L'exécution médiatisée par lots introduit une surface de défaillance au-delà des simples erreurs d'application, incluant les retards du planificateur, les défaillances de nœuds, la disparition d'agents et des artefacts malformés. Un service viable doit concilier les sémantiques de cycle de vie interactif (soumettre, surveiller, récupérer) avec l'observabilité partielle et la nature asynchrone de la planification des tâches HPC.

Méthodologie et Architecture

Les auteurs proposent HPC-VQPU, une architecture d'exportation de service qui sépare l'autorité du service de l'exécution gouvernée par le planificateur. Le système est organisé en deux plans distincts qui communiquent exclusivement par des messages sortants initiés par un agent, préservant ainsi la frontière de sécurité HPC.

1. Décomposition en Deux Plans

• Plan de Contrôle (Orienté Cloud) : Hébergé en dehors du cluster HPC, ce plan gère l'API, le cycle de vie des tâches, l'identité du dispositif et la projection des événements. Il est autoritaire pour l'état des tâches mais ne contient aucune fonctionnalité face au planificateur ni aucune connectivité entrante vers le cluster.
• Plan d'Exécution (Résident HPC) : Implémenté par un vqpu_agent non privilégié s'exécutant sur un nœud de connexion HPC. Cet agent initie toute la coordination. Il interroge le plan de contrôle pour obtenir du travail, revendique des tâches, soumet des tâches au planificateur (par exemple, Slurm) et rapporte les résultats. Il ne possède aucune vérité de service durable et est reconstructible après un redémarrage.

2. Le Contrat de Snapshot

L'abstraction centrale est le snapshot de dispositif ($\Delta$), une représentation structurée en graphe d'un dispositif virtuel contenant la topologie, les portes natives et les paramètres d'étalonnage (temps de cohérence, taux d'erreur).

• Liaison au Moment de la Revendication : Pour résoudre la tension entre le délai de file d'attente et la fraîcheur de l'étalonnage, le snapshot est lié de manière atomique au moment de la revendication, et non au moment de la soumission. Lorsqu'un agent revendique une tâche, le plan de contrôle transfère la propriété et fournit le snapshot immuable ($\delta_i$) dans le cadre du contrat d'exécution.
• Exécution Hermétique : L'exécuteur du nœud de calcul reçoit une charge utile locale contenant le circuit et le snapshot lié. Il exécute la simulation (par exemple, en utilisant Qiskit-Aer/cuQuantum) entièrement hors ligne, dérivant les modèles de bruit à partir du snapshot sans contacter le plan de contrôle. Cela garantit que les sémantiques d'exécution sont invariantes par rapport aux changements d'état du dispositif survenant après la revendication.

3. Cycle de Vie des Tâches et Protocole

Le système emploie un automate de tâches à cinq états ($\{EN\_FILE, EN\_COURS, TERMINE, ECHOU, ANNULE\}$) géré par le plan de contrôle.

• Protocole Asymétrique : L'agent initie les opérations REVENDIQUER, BATTEMENT_DE_COEUR et RAPPORT. Le plan de contrôle ne pousse jamais d'état vers l'intérieur.
• Propriété Atomique : L'opération REVENDIQUER est le point de linéarisation pour la propriété. Elle fait passer atomiquement une tâche de EN_FILE à EN_COURS et attribue un propriétaire unique, empêchant une exécution dupliquée par des agents concurrents.
• Récupération : Si un agent échoue, la tâche reste dans EN_COURS avec un propriétaire obsolète. La récupération nécessite une action administrative explicite (par exemple, REMETTRE_EN_FILE), garantissant que l'ambiguïté n'est pas résolue silencieusement et que la lignée d'exécution est préservée.

Contributions Clés

L'article présente quatre contributions principales :

1. Architecture d'Exportation de Service : Une décomposition plan de contrôle/plan d'exécution qui résout l'inversion de connectivité via une coordination uniquement sortante, permettant aux systèmes HPC sécurisés d'exporter une simulation consciente des dispositifs sans affaiblir leur posture de sécurité.
2. Abstraction de Snapshot de Dispositif : Un contrat d'exécution portable et structuré en graphe qui lie la topologie et les sémantiques d'étalonnage de manière atomique au moment de la revendication, garantissant que les tâches planifiées restent fidèles à l'état du dispositif virtuel demandé.
3. Cycle de Vie Conscient du Planificateur : Un automate de tâches à cinq états avec un protocole asymétrique de revendication/rapport/battement de cœur qui concilie les sémantiques de service interactif avec l'exécution médiatisée par lots et l'observabilité partielle.
4. Implémentation de Référence et Validation : Un déploiement de production au Pawsey Supercomputing Research Centre utilisant des GPU Setonix, Qiskit-Aer et des données d'étalonnage IBM Fez, démontrant la faisabilité de l'architecture.

Résultats Expérimentaux

Les auteurs valident l'architecture par le biais de tests de régression et d'expériences de production de bout en bout, produisant les résultats suivants :

• Surcharge Bornée : La surcharge d'exportation de service est additive et bornée. La latence visible par l'interface (admission et interrogation) reste constante (~0,4 s pour l'admission, ~22-27 s de la file d'attente à la revendication) indépendamment de la taille du circuit (28–32 qubits). La mise à l'échelle exponentielle de la simulation reste confinée au substrat de calcul.
• Fidélité de l'Étalonnage : Des expériences utilisant de vraies données d'étalonnage IBM Fez par rapport à des snapshots idéaux (nuls) démontrent que le contenu du snapshot modifie directement les distributions de sortie. Le système propage correctement les paramètres de bruit dérivés de l'étalonnage vers le simulateur.
• Liaison au Moment de la Revendication : Lorsque l'étalonnage d'un dispositif est muté administrativement après la soumission mais avant la revendication, le système exécute correctement la tâche en utilisant l'état post-mutation (idéal). Cela confirme que le snapshot est lié au moment de la revendication, empêchant une exécution obsolète.
• Concurrence et Intégrité : Dans un test multi-avec 50 tâches et deux agents concurrents, toutes les tâches ont été complétées exactement une fois avec une répartition presque égale (24:26). Aucune revendication dupliquée ni propriété ambiguë n'est survenue.
• Récupération : Après un crash d'agent, trois tâches EN_COURS ont été récupérées avec succès via une remise en file explicite, se terminant sans exécution dupliquée ni réinterprétation silencieuse de l'état.

Signification et Revendications

L'article affirme que HPC-VQPU démontre que les superordinateurs sécurisés et planifiés par lots peuvent exporter des services interactifs riches sémantiquement sans cesser de fonctionner comme des systèmes HPC. La signification réside dans la capacité à préserver la fidélité du dispositif (topologie, portes natives, étalonnage) à travers la frontière du planificateur.

Les auteurs positionnent ce travail non pas comme une optimisation de performance pour les noyaux de simulation, mais comme une solution système pour la frontière de service. En traitant le snapshot de dispositif comme un contrat de première classe indexé dans le temps, l'architecture permet aux flux de travail logiciels quantiques (évaluation de compilateurs, routage, études de bruit) d'interagir avec les ressources HPC comme s'il s'agissait de QPU virtuels interactifs. Les invariants de conception (connectivité uniquement sortante, revendication atomique, exécution hermétique) sont présentés comme des conditions nécessaires pour rendre les résultats scientifiquement interprétables comme une exécution sur un dispositif virtuel spécifique, même face aux retards de file d'attente et aux défaillances d'infrastructure.

L'article conclut modestement, reconnaissant que l'évaluation est centrée sur un seul site de production et un chemin de simulation, et que l'architecture fournit des sémantiques de cycle de vie autoritaires plutôt qu'une preuve d'exécution « exactement une fois » au sens plein des systèmes distribués. Cependant, il affirme que la séparation proposée entre autorité et réalisation offre une voie viable pour intégrer la simulation à l'échelle HPC dans l'écosystème logiciel quantique interactif.