Aller au contenu principal

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 QPUs 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 Direct Access IBM​

Périmètre administrateur​

La configuration des backends API Direct Access (périmètre admin HPC) inclut les points de terminaison et les identifiants d'accès au point de terminaison Direct Access 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 Direct Access
  • 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 est responsable de la multi-location (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

Service Qiskit Runtime​

Périmètre utilisateur​

Il est attendu que les utilisateurs spécifient des détails d'accès supplémentaires dans des variables d'environnement. Cela comprend notamment :

  • Instance du service Qiskit Runtime (CRN, Cloud Resource Name)
  • Point de terminaison pour Qiskit Runtime (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 le service Qiskit Runtime est utilisé. Par conséquent, la planification sur IBM Quantum® Platform tient compte des capacités de l'utilisateur et de l'instance de service pour la planification.

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​

Il est attendu que les utilisateurs spécifient des détails d'accès supplémentaires dans des variables d'environnement. Actuellement, cela comprend :

  • Ressource PCS à cibler (FRESNEL, EMU_FRESNEL, EMU_MPS)
  • Jeton d'autorisation