Lumaktaw sa pangunahing nilalaman

Gabay ng gumagamit ng SPANK plugin

Ang SPANK plugin para sa Quantum Resource Management Interface (QRMI) ay ginagamit upang i-configure ang access sa mga quantum resource mula sa mga user job sa isang compute environment na pinamamahalaan ng workload manager na Slurm. Ito ay isang gabay para sa mga gumagamit ng plugin upang i-configure ang paglalaan ng QPU resource kapag gumagawa ng mga Slurm job.

Tinutukoy ng mga Slurm QPU resource definition kung anong mga pisikal na resource ang maaaring gamitin ng mga Slurm job sa mga high-performance compute (HPC) na kapaligiran. Ang source code ng gumagamit ay dapat na agnostic sa mga partikular na backend instance, at kahit sa mga uri ng backend hangga't maaari. Pinapanatili nitong portable ang source code habang ang mga pamantayan sa pagpili ng QPU ay bahagi ng resource definition (na itinuturing na configuration kaysa source code).

I-configure ang mga QPU resource sa paglikha ng job​

babala

Tandaan na ang plugin na ito ay aktibong pinauunlad at ang eksaktong syntax ay maaaring magbago.

Saklaw ng administrator​

Kino-configure ng mga HPC administrator ang SPANK plugin upang tukuyin kung anong mga pisikal na resource ang maaaring ibigay sa mga Slurm job. Naglalaman ang configuration na ito ng lahat ng impormasyon na kailangan para ma-access ng mga Slurm job ang mga pisikal na resource, tulad ng mga endpoint at mga kredensyal sa pag-access.

Basahin ang qrmi_config.json.example para sa isang komprehensibong halimbawa ng configuration.

Sa slurm.conf, maaaring italaga ang mga QPU resource sa ilan o lahat ng node para sa paggamit:

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

Saklaw ng gumagamit​

Nagsusumite ang mga HPC user ng mga job gamit ang mga QPU resource na nakatali sa mga Slurm QPU resource. Tinutukoy ng attribute na name kung ano ang itinakda ng HPC administrator. Sa panahon ng runtime ng isang Slurm job, maaaring isagawa ang pagpili ng backend batay sa mga pamantayang iba sa isang paunang natukoy na pangalan na tumutukoy sa isang partikular na backend (halimbawa, ayon sa kapasidad at mga qualifier ng error rate, upang makatulong sa pag-filter sa hanay ng mga natukoy na backend).

Maaaring may mga karagdagang environment variable na kailangan, depende sa uri ng backend.

Ang mga parameter ng SBATCH ay magtaturo sa isa o higit pang mga QPU resource na itinalaga sa application bilang mga generic resource. Ang mga environment variable na ibinibigay sa pamamagitan ng plugin ay magbibigay ng kinakailangang impormasyon sa application (tingnan ang seksyong Saklaw ng HPC application para sa mga detalye).

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

srun ...

Upang gumamit ng higit pang mga QPU resource, magdagdag ng higit pang mga QPU sa parameter na --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 ...

Saklaw ng HPC application​

Ginagamit ng mga HPC application ang mga Slurm QPU resource na itinalaga sa Slurm job.

Nagbibigay ang mga environment variable ng higit pang mga detalye para magamit ng application; halimbawa, inililista ng SLURM_JOB_QPU_RESOURCES ang mga pangalan ng quantum resource (pinaghihiwalay ng kuwit kung ilang ang ibinibigay). Gagamitin ng QRMI ang mga variable na ito. (Tingnan ang mga README file sa iba't ibang QRMI directory (IBM, pasqal) para sa higit pang mga detalye.)

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()))

Tingnan ang examples directory para sa mga halimbawang file.

Mga detalye ng Backend​

IBM Direct Access API​

Saklaw ng administrator​

Kasama sa configuration ng mga Direct Access API backend (saklaw ng HPC admin) ang mga endpoint at kredensyal sa Direct Access endpoint at mga serbisyo ng authentication, pati na rin sa S3 endpoint. Partikular, kasama dito ang:

  • IBM Cloud® API key para sa paglikha ng mga bearer token
  • Endpoint ng Direct Access API
  • S3 bucket at mga detalye ng access

Hindi dapat makita ng mga HPC user o iba pang mga non-privileged na user sa system ang mga kredensyal sa pag-access. Kaya naman, maaaring ilagay ang sensitibong data sa mga hiwalay na file, na maaaring protektahan ang access nang naaangkop.

Tandaan na ang Slurm ay may buong access sa backend. Mayroon itong ilang mga implikasyon:

  • Ang Slurm plugin ang responsable sa multi-tenancy (tinitiyak na hindi makikita ng mga user ang mga resulta ng mga job ng ibang user)
  • Ang bahagi ng HPC cluster ang responsable sa pag-verify ng mga user (kung sino ang pinapayagang mag-access sa QPU) at pagtitiyak ng naaangkop na access
  • Ang kapasidad at priyoridad ng paggamit ng QPU ay pamamahalaan lamang sa pamamagitan ng Slurm; walang ibang scheduling ng mga user na sangkot sa labas ng Slurm
Saklaw ng gumagamit​

Hindi direktang inilalantad ang mga execution lane sa HPC administrator o gumagamit. Sa halip, sa panahon ng runtime, maaaring may dalawang magkaibang mode na maaaring tukuyin ng mga HPC user:

  • Tinutukoy ng exclusive=true na walang ibang job ang maaaring gumamit ng resource sa parehong oras. Ang isang exclusive mode job ay nakakakuha ng lahat ng execution lane at hindi maaaring tumakbo sa parehong oras bilang isang non-exclusive na job
  • Pinapayagan ng exclusive=false ang iba pang mga job na tumakbo nang sabay-sabay. Sa kasong ito, maaaring mayroon ng kasinami na mga job tulad ng mga execution lane, lahat ay tumatakbo sa parehong oras, at ang job ay itinalaga ng isang lane

Qiskit Runtime Service​

Saklaw ng gumagamit​

Inaasahang tutukuyin ng mga user ang mga karagdagang detalye ng access sa mga environment variable. Partikular, kasama dito ang mga sumusunod:

  • Qiskit Runtime service instance (CRN, Cloud Resource Name)
  • Endpoint para sa Qiskit Runtime (maliban kung awtomatikong natukoy mula sa CRN)
  • API key, na may access sa CRN
  • S3 instance, bucket, at access token/credentials para sa mga paglilipat ng data

Tinutukoy ng mga detalyeng ito kung saang user at service instance ginagamit ang Qiskit Runtime service. Kaya naman, isinasaalang-alang ng IBM Quantum® Platform scheduling ang mga kakayahan ng user at service instance para sa scheduling.

Sa ngayon, dapat ibigay ng mga user ang mga detalyeng nabanggit sa itaas (walang shared na cluster-wide na quantum access).

Pasqal Cloud Services​

Saklaw ng HPC admin​

Walang partikular na setup na kailangan mula sa mga HPC admin para sa paggamit ng PCS.

Saklaw ng HPC user​

Inaasahang tutukuyin ng mga user ang mga karagdagang detalye ng access sa mga environment variable. Kasalukuyan, kasama dito ang mga sumusunod:

  • PCS resource na target (FRESNEL, EMU_FRESNEL, EMU_MPS)
  • Authorization token