Guide utilisateur du plugin SPANK

Le plugin SPANK pour l'interface de gestion des ressources quantiques (QRMI) permet de configurer l'accès aux ressources quantiques depuis les jobs utilisateur dans un environnement de calcul administré par le gestionnaire de charge de travail Slurm. Ce guide s'adresse aux utilisateurs du plugin pour configurer l'allocation des ressources QPU lors de la création de jobs Slurm.

Les définitions de ressources QPU dans Slurm déterminent quelles ressources physiques peuvent être utilisées par les jobs Slurm dans des environnements de calcul haute performance (HPC). Le code source utilisateur doit être indépendant des instances de backend spécifiques, et même des types de backend dans la mesure du possible. Cela rend le code source portable, tandis que les critères de sélection du QPU font partie de la définition des ressources (considérée comme de la configuration plutôt que du code source).

Configurer les ressources QPU lors de la création d'un job

attention

Note : ce plugin est en cours de développement actif et la syntaxe exacte est susceptible de changer.

Périmètre administrateur

Les administrateurs HPC configurent le plugin SPANK pour définir quelles ressources physiques peuvent être fournies aux jobs Slurm. Cette configuration contient toutes les informations nécessaires pour que les jobs Slurm accèdent aux ressources physiques, comme les points de terminaison et les identifiants d'accès.

Consulte le fichier qrmi_config.json.example pour un exemple de configuration complet.

Dans slurm.conf, les ressources QPU peuvent être affectées à certains nœuds ou à tous les nœuds pour utilisation :

...
GresTypes=qpu,name
NodeName=node[1-5000] Gres=qpu,name:ibm_fez
...

Périmètre utilisateur

Les utilisateurs HPC soumettent des jobs en utilisant des ressources QPU liées aux ressources QPU Slurm. L'attribut name fait référence à ce que l'administrateur HPC a défini. Pendant l'exécution d'un job Slurm, la sélection du backend peut reposer sur des critères autres qu'un nom prédéfini faisant référence à un backend spécifique (par exemple, des qualificateurs de capacité et de taux d'erreur, pour affiner la sélection parmi l'ensemble de backends définis).

Des variables d'environnement supplémentaires peuvent être requises, selon le type de backend.

Les paramètres SBATCH pointent vers une ou plusieurs ressources QPU assignées à l'application en tant que ressources génériques. Les variables d'environnement fournies par le plugin transmettent les informations nécessaires à l'application (voir la section Périmètre de l'application HPC pour les détails).

#SBATCH --time=100
#SBATCH --output=<LOGS_PATH>
#SBATCH --gres=qpu:1
#SBATCH --qpu=ibm_fez
#SBATCH --... # other options

srun ...

Pour utiliser davantage de ressources QPU, ajoute d'autres QPU au paramètre --qpu :

#SBATCH --time=100
#SBATCH --output=<LOGS_PATH>
#SBATCH --gres=qpu:3
#SBATCH --qpu=my_local_qpu,ibm_fez,ibm_marrakesh
#SBATCH --... # other options

srun ...

Périmètre de l'application HPC

Les applications HPC utilisent les ressources QPU Slurm assignées au job Slurm.

Les variables d'environnement fournissent des détails supplémentaires à l'application ; par exemple, SLURM_JOB_QPU_RESOURCES liste les noms des ressources quantiques (séparés par des virgules si plusieurs sont fournis). Ces variables seront utilisées par QRMI. (Consulte les fichiers README dans les différents répertoires QRMI (IBM, pasqal) pour plus de détails.)

from qiskit import QuantumCircuit
# Using an IBM QRMI flavor:
from qrmi.primitives import QRMIService
from qrmi.primitives.ibm import SamplerV2, get_backend

# define circuit

circuit = QuantumCircuit(2)
circuit.h(0)
circuit.cx(0, 1)
circuit.measure_all()

# instantiate QRMI service and
# get quantum resource (we'll take the first one should there be several of them)
# inject credentials needed for accessing the service at this point
load_dotenv()
service = QRMIService()

resources = service.resources()
qrmi = resources[0]

# Generate transpiler target from backend configuration & properties and transpile
backend = get_backend(qrmi)
pm = generate_preset_pass_manager(
    optimization_level=1,
    backend=backend,
)

isa_circuit = pm.run(circuit)

# Run the circuit
options = {}
sampler = SamplerV2(qrmi, options=options)

job = sampler.run([(isa_circuit, isa_observable, param_values)])
print(f">>> Job ID: {job.job_id()}")

result = job.result()

if job.done():
    pub_result = result[0]
    print(f"Counts for the 'meas' output register: {pub_result.data.meas.get_counts()}")
elif job.cancelled():
    print("Cancelled")
elif job.errored():
    print(qrmi.task_logs(job.job_id()))

Consulte le répertoire d'exemples pour des fichiers d'exemples.

Spécificités des backends

API IBM Quantum System

Périmètre administrateur

La configuration des backends de l'API Quantum System (périmètre admin HPC) inclut les points de terminaison et les identifiants d'accès au point de terminaison Quantum System et aux services d'authentification, ainsi qu'au point de terminaison S3. Cela comprend notamment :

• Clé API IBM Cloud® pour la création de jetons Bearer

• Point de terminaison de l'API Quantum System

• Compartiment S3 et détails d'accès

Les identifiants d'accès ne doivent pas être visibles par les utilisateurs HPC ou les autres utilisateurs non privilégiés du système. Par conséquent, les données sensibles peuvent être stockées dans des fichiers séparés, qui peuvent être protégés en accès de manière appropriée.

Note que Slurm dispose d'un accès complet au backend. Cela a plusieurs implications :

• Le plugin Slurm assure l'isolation multilocataire (multi-tenant) (s'assurer que les utilisateurs ne voient pas les résultats des jobs des autres utilisateurs)

• Le côté cluster HPC est responsable de la vérification des utilisateurs (qui est autorisé à accéder au QPU) et de la garantie d'un accès conforme

• La capacité et la priorité d'utilisation du QPU sont gérées exclusivement par Slurm ; aucune autre planification des utilisateurs n'est impliquée en dehors de Slurm

Périmètre utilisateur

Les couloirs d'exécution ne sont pas directement exposés à l'administrateur HPC ou à l'utilisateur. En revanche, pendant l'exécution, les utilisateurs HPC peuvent spécifier deux modes différents :

• exclusive=true indique qu'aucun autre job ne peut utiliser la ressource en même temps. Un job en mode exclusif obtient tous les couloirs d'exécution et ne peut pas s'exécuter en même temps qu'un job non exclusif

• exclusive=false permet à d'autres jobs de s'exécuter en parallèle. Dans ce cas, il peut y avoir autant de jobs qu'il y a de couloirs d'exécution, tous s'exécutant simultanément, et le job se voit attribuer un couloir

IBM Quantum Compute Service

Périmètre utilisateur

Les utilisateurs doivent indiquer des informations d'accès supplémentaires dans des variables d'environnement. Cela comprend notamment :

• Instance IBM Quantum Compute Service (CRN, Cloud Resource Name)

• Point de terminaison pour Quantum Compute (sauf détection automatique depuis le CRN)

• Clé API ayant accès au CRN

• Instance S3, compartiment et jeton d'accès/identifiants pour les transferts de données

Ces détails déterminent sous quel utilisateur et quelle instance de service IBM Quantum Compute Service est utilisé. Par conséquent, la planification d'IBM Quantum® Platform tient compte des capacités de l'utilisateur et de l'instance de service.

Pour l'instant, les utilisateurs doivent fournir les détails ci-dessus (pas d'accès quantique partagé à l'échelle du cluster).

Services Cloud Pasqal

Périmètre admin HPC

Aucune configuration spécifique n'est requise de la part des admins HPC pour l'utilisation de PCS.

Périmètre utilisateur HPC

Les utilisateurs doivent indiquer des informations d'accès supplémentaires dans des variables d'environnement. Actuellement, cela comprend :

• Ressource PCS à cibler (FRESNEL, EMU_FRESNEL, EMU_MPS)

• Jeton d'autorisation