Intégration de l’informatique quantique à des applications classiques

Certains problèmes de calcul sont impraticables ou inductibles à résoudre sur les ordinateurs classiques, même sur les supercalculateurs volumineux. Pour certains de ces problèmes, un algorithme quantique peut atteindre une solution en utilisant beaucoup moins de ressources que l’approche classique la plus connue. Un ordinateur quantique utilise des effets mécaniques quantiques, tels que la superposition et l’enchevêtrement, pour représenter et traiter des informations de manière à ce qu’un ordinateur classique ne puisse pas.

Les programmes quantiques s’exécutent sur fournisseurs d’informatique quantique auxquels vous accédez en soumettant des tâches. Les cibles quantiques exposent différents profils cibles. Certains profils autorisent uniquement les opérations quantiques, et la logique classique que vous pouvez exécuter sur eux est limitée. D’autres profils permettent à la fois aux opérations quantiques et classiques de s’exécuter ensemble sur le fournisseur.

Quel que soit le profil cible, les composants de calcul classiques gèrent l’intégration d’applications environnantes. Même lorsqu’une cible quantique accepte des opérations classiques, vous atteignez la cible en envoyant un travail et en attendant les résultats. Cet article décrit et compare deux modèles d’orchestration pour l’intégration d’un travail quantique à des applications classiques.

En pratique, l’exécution d’un programme quantique est un appel de service. Votre application classique ou votre code client envoie un travail à une cible, attend qu’elle s’exécute et récupère les résultats. Un ou plusieurs composants de calcul classiques orchestrent chaque travail quantique en effectuant les activités suivantes :

• Préparation des données d’entrée
• Envoi de travaux d’informatique quantique à un environnement quantique cible
• Surveillance de l’exécution du travail
• Résultats de la tâche post-traitement

Modèles d’intégration quantique

Vous intégrez le travail quantique à une application classique à l’aide de l’un des deux modèles d’orchestration :

• Intégration quantique directe. Une application cliente ou un harnais classique léger interagit directement avec l’espace de travail Azure Quantum. Le client possède la préparation des entrées, la soumission de travaux, la surveillance, la gestion des résultats et la logique classique qui entoure l’exécution quantique.

• Intégration quantique orchestrée par flux de travail. Un orchestrateur de workflow gère l’état global et les transitions. L’exécution quantique a lieu dans des étapes d’un flux de travail qui s’exécutent parallèlement à des étapes s’exécutant sur des ressources de calcul haute performance (HPC) ou sur processeur graphique (GPU).

Pour une limite d’intégration d’application donnée, ces modèles sont des alternatives. Soit le client s’intègre directement à l’espace de travail, soit un workflow plus large possède l’étape quantique. Cet article décrit l’implémentation de chaque modèle.

Le choix d’intégration est indépendant de l’endroit où le calcul classique s’exécute. Selon le profil cible et la charge de travail, la logique classique peut s’exécuter dans le programme quantique, dans le client harnais entre les exécutions quantiques, dans l’orchestrateur de flux de travail ou dans une étape de flux de travail classique sur le calcul HPC ou GPU.

Matrice décisionnelle

Utilisez la matrice de décision suivante pour guider votre choix de modèles d’intégration :

Si votre charge de travail présente ces caractéristiques	Utiliser cette approche
Une application ou un script léger gère l’ensemble du cycle de vie de la tâche quantique, et la préparation des données d’entrée ainsi que le traitement des résultats sont pris en charge par ce client.	Intégration quantique directe
Vous explorez les propriétés du matériel quantique avec du code quantique manuscrit, et une application ou un petit ensemble d’applications associées consomme les résultats.	Intégration quantique directe
La partie classique est lourde et fait appel au calcul quantique comme à une étape parmi d’autres, dans un pipeline à plusieurs étapes dont chacune s’exécute sur le back-end qui lui convient, par exemple un système HPC, un GPU ou une cible quantique.	Intégration quantique orchestrée par flux de travail
Les exécutions quantiques se répètent et le résultat d’une exécution génère le programme quantique suivant ou détermine ses paramètres.	Intégration quantique orchestrée par flux de travail

Détails du scénario

Les deux flux de travail implémentent le modèle de Request-Reply asynchrone et les étapes définies pour le cycle de vie des travaux Azure Quantum.

Les cibles quantiques, en particulier le matériel quantique, sont des ressources limitées. Azure Quantum alloue ces ressources via une file d’attente de travaux. Lorsque vous soumettez une tâche, elle est mise dans la file d’attente de la cible que vous sélectionnez et s’exécute une fois que cette cible a terminé les entrées précédentes. Pour afficher le temps d’attente attendu, répertoriez les cibles disponibles. Calculez votre temps de réponse total comme la somme du temps d’attente dans la file et du temps d’exécution de la tâche.

Les fonctionnalités d’une cible quantique varient également. Certaines cibles acceptent uniquement les opérations quantiques, tandis que d’autres exécutent une logique classique avec des opérations quantiques dans un seul travail. Ce modèle prend en charge les algorithmes qui s’adaptent pendant l’exécution. Avant de valider une cible, vérifiez qu’elle prend en charge les opérations dont votre algorithme a besoin. Pour plus d’informations sur la façon dont les instructions classiques et quantiques s’exécutent ensemble, consultez Présentation de l’informatique quantique hybride.

Intégration quantique directe

Les sections suivantes décrivent le modèle d’intégration directe pour intégrer le travail quantique à une application classique.

Architecture

Téléchargez un fichier PowerPoint de cette architecture.

Flux de données

Le flux de données suivant correspond au diagramme précédent :

1. Un utilisateur connecté déclenche l’exécution d’un travail quantique via une application cliente classique.

2. L’application cliente entre les données dans stockage Azure.

3. L’application cliente envoie le travail à un espace de travail Azure Quantum, en spécifiant la cible ou les cibles d’exécution.

   Le client identifie l’espace de travail à partir de sa configuration et s’authentifie auprès de l’espace de travail à l’aide d’une identité Microsoft Entra. Un client qui s’exécute sur une ressource hébergée Azure peut utiliser une identité managée. Une application cliente locale s’authentifie avec une autre identité Microsoft Entra, comme un principal de service ou une connexion utilisateur interactive.

4. Un fournisseur quantique exécute le travail sur un environnement cible.

5. L’application cliente surveille l’exécution du travail en interrogeant l’état du travail.

6. Dès que le travail quantique se termine, l’application cliente obtient le résultat de calcul à partir du stockage.

Composants

• Azure Quantum fournit un workspace, accessible à partir du portail Azure, pour les ressources associées à l’exécution de travaux quantiques sur différentes cibles. Les travaux s’exécutent sur des simulateurs quantiques ou du matériel quantique, selon le fournisseur que vous choisissez.
• Microsoft Entra ID coordonne l’authentification des utilisateurs et permet de protéger l’accès à l’espace de travail Azure Quantum.
• Le stockage assure le stockage des données d’entrée et des résultats provenant du fournisseur quantique.

Cas d’usage potentiels d’intégration directe

Le modèle d’intégration quantique directe correspond aux cas d’usage suivants :

• Une application cliente ou un harnais classique léger possède le cycle de vie complet du travail quantique sans flux de travail plus large.
• Le client peut exécuter des travaux classiques, tels que la préparation des entrées et le traitement des résultats.
• Vous explorez les propriétés du matériel quantique, vous écrivez donc généralement le code quantique à la main plutôt que de le générer dynamiquement.
• L’utilisation des composants quantiques est limitée à une seule application ou à un petit ensemble d’applications associées.
• Le travail quantique représente une solution spécialisée, telle qu’une simulation moléculaire, qu’une seule application classique spécialisée utilise.

Intégration quantique orchestrée par flux de travail

Les sections suivantes décrivent le modèle orchestré par le flux de travail pour intégrer le travail quantique à une application classique.

Architecture

La logique de flux de travail ne dépend d’aucun hôte ou fournisseur spécifique. L’organigramme suivant montre l’ordinateur d’état : une seule entrée, une boucle sur les étapes et les phases par étape. La branche quantique peut inclure une phase facultative de génération de programme et d’optimisation que les étapes classiques n’utilisent pas.

Le sélecteur principal dans l’organigramme précédent est une phase logique plutôt qu’un composant requis et peut être une recherche de configuration qui achemine chaque étape vers un type back-end fixe.

Vous pouvez héberger ce flux de travail sur Azure avec un ensemble de services classiques qui envoient et surveillent le travail quantique. Le diagramme suivant illustre un exemple de topologie :

Téléchargez un fichier PowerPoint de cette architecture.

Flux de données

Le flux de données suivant correspond à la topologie de déploiement :

1. Une application cliente envoie une demande via Gestion des API, qui authentifie l’appelant avec Microsoft Entra ID et applique la limitation avant que la demande atteigne le niveau de calcul.
2. Gestion des API transfère la requête à l’API d’entrée, une fonction déclenchée par HTTP qui la valide et démarre l’orchestrateur de flux de travail.
3. Pour une étape qui s’exécute classiquement, l’orchestrateur achemine l’exécution vers un serveur principal classique, tel qu’un cluster HPC ou un calcul GPU.
4. Le back-end classique écrit ses résultats et l’état mis à jour du pipeline dans l’espace de stockage.
5. Pour une étape qui s’exécute sur quantum, l’orchestrateur achemine l’exécution via le chemin quantum. Le chemin quantique prépare le programme de l'étape, en le générant et en l'optimisant à partir de l'entrée de l'étape ou à l'aide d'une implémentation fixe, et envoie le travail à l'espace de travail Azure Quantum. La soumission s’authentifie via une identité managée.
6. L’espace de travail exécute le travail sur la cible quantique sélectionnée.
7. La cible quantum écrit ses résultats dans Stockage.
8. L’orchestrateur lit le stockage d’état mis à jour et évalue la logique de transition du pipeline. Si une condition de convergence ou d’itération nécessite une autre exécution quantique, l’orchestrateur utilise le résultat pour déterminer les paramètres du programme quantique suivant ou pour fournir des entrées qui génèrent le programme suivant. Le pipeline effectue ensuite une boucle vers l’étape appropriée.
9. Le client interroge l’API Status via Gestion des API pour suivre la progression et récupérer les résultats finaux lorsque le pipeline atteint un état terminal.

Composants

• Durable Functions agit en tant qu'orchestrateur de flux de travail pour exécuter le pipeline en tant qu'ordinateur d'état, coordonner les étapes, puis sélectionner le serveur principal de type de calcul ou quantique pour l'exécution de chaque étape. Vous pouvez implémenter l’orchestrateur avec Durable Functions ou un autre moteur de flux de travail.
• Azure serveur principal de calcul HPC et GPU classique exécutent les étapes non quantiques.
• Azure Functions héberge les API HTTP qui démarrent et surveillent le flux de travail, ainsi que l’orchestrateur qui l’exécute.
• Gestion des API est le point d’entrée pour les demandes clientes. Il authentifie les appelants et applique une limitation du débit. Pour empêcher l’application de fonction d’être appelée directement, utilisez Azure Functions options de mise en réseau, telles que les restrictions d’accès entrantes ou un point de terminaison privé, afin qu’elle accepte uniquement le trafic à partir de Gestion des API.
• Azure Quantum fournit un espace de travail pour les ressources associées aux travaux quantiques en cours d’exécution. Les travaux s’exécutent sur des simulateurs quantiques ou du matériel quantique, selon la cible que vous choisissez.
• Microsoft Entra ID coordonne l’authentification et protège l’accès à l’espace de travail Azure Quantum.
• Le stockage stocke les données d’entrée, l’état du pipeline intermédiaire et les résultats.

Alternatives

Les architectures de cet article exécutent une partie d’une tâche de calcul sur une cible quantique. Pour certains défis de calcul, les services existants conçus pour effectuer un calcul hautes performances ou fournir des fonctionnalités IA peuvent être des alternatives.

Pour les charges de travail de R&D scientifique, Microsoft Discovery utilise l’IA pour orchestrer des tâches complexes à travers les modèles, les outils et les ressources de calcul. Microsoft Discovery peut coordonner divers outils dans des pipelines en plusieurs étapes et est extensible, ce qui vous permet de connecter vos propres outils et agents au lieu de développer et gérer vous-même l’orchestration. L’intégration avec les fonctionnalités quantiques, y compris l’exécution d’étapes quantiques, peut utiliser l’IA pour effectuer l’orchestration que ce modèle génère manuellement.

Détails du scénario orchestré par flux de travail

Dans ce modèle, un orchestrateur de workflow exécute la charge de travail en tant que pipeline d’étapes. L’orchestrateur se comporte comme une machine d’état dans laquelle les étapes se répètent et se bouclent jusqu’à ce qu’une condition d’arrêt ou de convergence soit remplie. Chaque étape suit la même forme : elle prépare son entrée, s’exécute et traite la sortie.

L’orchestrateur sélectionne le système back-end qui exécute chaque étape. Cette sélection fait partie de la logique d’orchestration, et non d’un service distinct, et peut être aussi simple que la lecture du back-end cible pour chaque étape de la configuration. Une étape s’exécute sur un back-end quantique ou sur un calcul classique, tel qu’un cluster HPC ou un calcul GPU. Une étape classique légère peut s’exécuter dans l’orchestrateur lui-même. Lorsque les étapes quantiques se répètent, le flux de travail traite le résultat d’une exécution quantique pour déterminer les paramètres du programme quantique suivant ou pour fournir des entrées qui génèrent le programme suivant.

Une étape qui s’exécute sur un back-end quantique peut ajouter une phase que les étapes classiques n’ont pas. Cette phase génère et optimise le programme quantique avant l’exécution. Cette phase est facultative. Le programme peut être généré dynamiquement à partir de l’entrée de l’étape, ou provenir d’une implémentation fixe qui saute cette phase. Une étape éligible au traitement quantique peut néanmoins être exécutée sur un backend classique si cela est mieux adapté aux données d’entrée.

La chimie quantique est un exemple représentatif. Un pipeline classique utilise des étapes classiques pour préparer un système moléculaire : optimisation de la géométrie, calcul de champ auto-cohérent et sélection d’espace actif. Le pipeline calcule ensuite une propriété cible, telle que l’énergie d’état terrestre d’une molécule. L’étape d’informatique énergétique conserve la même intention qu’elle s’exécute sur une approximation classique ou sur un algorithme quantique. Vous choisissez le back-end en fonction de la précision dont vous avez besoin et de l’ampleur du problème.

La bibliothèque QDK/Chimie prend en charge les pipelines comme ceux-ci. La bibliothèque fournit des composants modulaires pour les étapes de préparation classiques et pour générer un circuit de préparation d’état à partir de la fonction d’onde calculée classiquement, qu’un back-end quantique utilise ensuite pour estimer l’énergie avec un algorithme tel que l’estimation de phase quantique. Cette fonctionnalité de génération de circuits est un exemple concret de génération dynamique du programme quantique à partir de l’entrée d’une étape.

Cas d’usage potentiels

Le modèle d’intégration quantique orchestrée par flux de travail correspond aux cas d’usage suivants :

• Le côté classique est lourd et orienté vers une logique d’états et de problèmes, et il exploite la capacité de quantum comme une ou plusieurs étapes parmi tant d’autres.
• La charge de travail est un pipeline à plusieurs étapes, souvent itératif, comme une machine à états. Chaque étape s’exécute sur le back-end de calcul le mieux adapté : HPC, GPU ou cible quantique. L’informatique quantique est une option pour une ou plusieurs étapes.
• Une étape quantique représente un bloc de construction bien défini, tel qu’un calcul scientifique qui calcule une propriété moléculaire. Le code quantique précis peut même être généré et optimisé dynamiquement pour s’adapter aux entrées réelles.
• L’orchestrateur de flux de travail assure la gestion de plusieurs exécutions quantiques autonomes et du traitement classique entre elles. Le résultat d’une exécution détermine les paramètres du programme quantique suivant ou fournit des entrées qui génèrent le programme suivant. L’estimation de phase itérative correspond à cette structure, comme les algorithmes variationnels tels que l’Eigensolver (VQE) variational quantum et l’algorithme d’optimisation approximative quantique (QAOA).

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d'informations, veuillez consulter la liste de vérification de la conception pour la fiabilité.

Les tâches quantiques s’exécutent sur des cibles distantes et partagées, de sorte que leur exécution peut échouer en raison d’erreurs transitoires, telles que l’expiration du délai d’attente de la cible. Quel que soit le modèle d’intégration que vous choisissez, surveillez l’exécution du travail afin de pouvoir exposer l’état du travail à l’utilisateur. Lorsqu’un travail échoue en raison d’une erreur temporaire, appliquez le modèle Nouvelle tentative. Envoyez des travaux au moyen d’appels asynchrones et interrogez régulièrement le résultat afin de ne pas bloquer le client appelant.

La disponibilité de la fonctionnalité de calcul quantique dépend fortement de la disponibilité et des caractéristiques de capacité du fournisseur de calcul quantique. Selon la cible de calcul, l’application cliente classique peut rencontrer des retards longs ou une indisponibilité de la cible.

Pour les services Azure environnants, les considérations de disponibilité habituelles s’appliquent. Si nécessaire, envisagez d’utiliser les options de réplication dans stockage Azure redondance.

Fiabilité de l’intégration orchestrée par flux de travail

• Pour la haute disponibilité dans l’intégration orchestrée par le flux de travail, déployez gestion des API dans plusieurs zones de disponibilité ou plusieurs régions. La redondance de zone nécessite le niveau Premium ou Premium v2, et le déploiement multirégion nécessite le niveau Premium.

• Si vous implémentez l’orchestrateur avec Durable Functions, planifiez sa reprise après sinistre comme un tout, au lieu de considérer l’application de fonction et son état comme des services indépendants. Les fonctions durables conservent l’état d’orchestration dans un hub de tâches dans un serveur principal de stockage, qui est stockage Azure par défaut. Étant donné que l’état d’exécution et le calcul sont couplés via ce hub de tâches, l’approvisionnement de l’application de fonction dans une deuxième région et la réplication du stockage séparément ne définit pas de basculement sécurisé. Les orchestrations peuvent interrompre, perdre des transactions récentes ou lire un hub de tâches entre des régions, en fonction de la topologie.

  Pour un basculement sécurisé, utilisez une configuration active-passive qui bascule vers une région secondaire, placée derrière un service mondial d’équilibrage de charge tel que Azure Front Door ou Azure Traffic Manager. Vérifiez que les sondes d’intégrité du service peuvent accéder à l’application de fonction avec vos restrictions réseau, car les contrôles qui limitent l’application au trafic d’API Management peuvent également bloquer ces sondes. Choisissez la topologie qui correspond à votre tolérance pour la perte de données et la latence entre régions. Pour connaître les options coordonnées et leurs compromis, consultez la récupération d’urgence et la géo-distribution dans Durable Functions.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification pour la révision de conception concernant la sécurité.

Appliquez les pratiques de renforcement suivantes aux services classiques qui entourent le travail quantique, quel que soit le modèle d’intégration que vous choisissez :

• Authentifiez-vous pour Azure Quantum et les services environnants à l’aide de Microsoft Entra identités, puis désactivez l’authentification locale où le service le prend en charge. Utilisez des identités managées partout où l’environnement d’hébergement les prend en charge. Pour un client qui ne peut pas utiliser une identité managée, authentifiez-vous avec une autre identité Microsoft Entra, telle qu'un principal de service ou une connexion utilisateur interactive.

• Accordez à chaque composant qui accède à Stockage l’accès au plan de données dont il a besoin via le contrôle d’accès en fonction des rôles Azure (Azure RBAC) avec Microsoft Entra ID, limité à ce composant. N’incorporez pas de clés de compte de stockage dans le code d’application.

En général, appliquez les recommandations de sécurité du Well-Architected Framework le cas échéant.

Sécurité pour l’intégration quantique directe

Contrairement à l’intégration quantique orchestrée par le flux de travail, ce modèle suppose qu’un seul client accède à l’espace de travail Azure Quantum. Le client est généralement une plateforme classique légère qui se concentre sur l’envoi et l’opération des travaux plutôt que sur un état de workflow plus large. Ce scénario entraîne les configurations suivantes :

• Étant donné que le client est connu, vous pouvez lui donner une identité fixe. Lorsque le client s’exécute sur une ressource hébergée Azure, associez une identité managée à celle-ci. Lorsque le client s’exécute en dehors de Azure, utilisez un principal de service ou une connexion utilisateur interactive.

• Vous pouvez implémenter la limitation des requêtes et la mise en cache des résultats dans le client lui-même.

Sécurité de l’intégration orchestrée par flux de travail

Contrairement à l’intégration quantique directe, ce modèle place un niveau de service classique devant le travail quantique. Gestion des API est la porte d’entrée de ce niveau, de sorte que les configurations de sécurité mettent l’accent sur la protection du point d’entrée et du chemin d’accès à l’espace de travail quantique.

• Les clients doivent s’authentifier auprès de l’API. Implémentez cette authentification à l’aide de stratégies d’authentification.

• Vous pouvez implémenter l’authentification des fonctions Azure via identités managées associées aux fonctions. Vous utilisez ces identités pour authentifier les appels sortants vers l’espace de travail Azure Quantum.

• Gestion des API peut appliquer la limitation des demandes pour protéger le back-end quantique et limiter l’utilisation des ressources quantiques. Pour plus d’informations, consultez la limitation du débit des requêtes dans API Management.

• Selon le modèle de requête, vous pouvez implémenter la mise en cache des résultats de l’informatique quantique à l’aide de stratégies de mise en cache gestion des API.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez la liste de vérification de conception pour l’optimisation des coûts.

Le coût global de cette solution dépend de la cible d’informatique quantique que vous sélectionnez pour exécuter le travail quantique. Les composants classiques sont simples à estimer. Pour un déploiement représentatif du modèle orchestré par le flux de travail, consultez cet exemple d’estimation des coûts, qui couvre les composants classiques, notamment Gestion des API, Azure Functions et Stockage. Le modèle d’intégration directe est plus léger, mais ses coûts classiques incluent toujours stockage et tout hébergement, mise en réseau et surveillance que l’application cliente utilise.

Vous pouvez consommer des fournisseurs d’informatique quantique pour Azure Quantum via une offre de place de marché Microsoft. La tarification dépend du type de ressource (simulateur ou matériel), de la référence SKU et de votre utilisation. Pour plus d'informations, accédez à la page de référence du fournisseur de votre scénario à partir de fournisseurs d'informatique quantique sur Azure Quantum.

Contributeurs

Microsoft conserve cet article. Le contributeur suivant a écrit cet article.

Auteur principal :

• Zander Chocron | Ingénieur logiciel principal, Microsoft Quantum

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

• Pour obtenir une vue d’ensemble de l’écosystème d’informatique quantique Microsoft, consultez le site web Microsoft Quantum et suivez le parcours d’apprentissage des bases de l’informatique quantique.
• Pour plus d’informations sur le service Azure Quantum, consultez Qu’est-ce que Azure Quantum ?.
• Pour obtenir des informations générales sur la gestion des travaux Azure Quantum, consultez Travailler avec des travaux Azure Quantum.
• Pour plus d’informations sur la combinaison d’instructions classiques et quantiques dans un travail, consultez Présentation de l’informatique quantique hybride.

Ressources associées

• Principes de conception de l’excellence opérationnelle
• modèle de Request-Reply asynchrone