Lumaktaw sa pangunahing nilalaman
Ang proyektong ito ay nasa beta. Nakakita ng bug? Mag-bukas ng GitHub issue. May tanong o ideya? Magtanong sa Discussions — gusto naming marinig ang iyong feedback!
Gaano kaganda ang kalidad ng pagsasalin sa pahinang ito?

Panimula sa mga managed workflow

Availability ng plan

Ang Qiskit Functions at mga managed workflow ay mga beta feature na available lang sa mga user ng Premium, Flex, at On-Prem (sa pamamagitan ng IBM Quantum® Platform API) na plan.

Pinapatakbo ng mga managed workflow ang custom Python code mo sa classical compute na pinamamahalaan para sa iyo ng IBM Quantum Platform. Gamitin ang mga managed workflow para magpatakbo ng hybrid quantum-classical workflow, malakihang diagonalization, at mahahabang parallel task nang hindi nangangasiwa ng compute infrastructure o storage.

Kailan gagamit ng managed workflow​

Gumamit ng managed workflow kapag walang pre-built na Catalog Function na sumasaklaw sa gawain mo, o kapag gusto mong i-package ang sarili mong method bilang reusable na function. Bagay ang mga managed workflow kapag gusto mong gawin ang mga sumusunod:

  • Magpatakbo ng mahahabang job sa cloud. Patuloy na tumatakbo ang managed workflow kahit isara mo ang laptop mo, at puwede kang kumonekta ulit sa job mamaya.

  • Gumamit ng mga node na malaki ang memory at may GPU. Piliin ang memory, CPU, at GPU resource na kailangan ng workload.

  • Magpatakbo ng mga task nang parallel. Magsimula ng maraming single-node na job nang sabay-sabay.

Ikaw ang magbibigay ng workflow code, mga dependency nito, at mga compute size na sinusuportahan nito. Pinapatakbo ng mga managed workflow ang workflow sa IBM®-managed na compute sa isang pre-built na environment na naka-install ang mga package mo, at nagbibigay ng cloud storage para sa mga file na binabasa at isinusulat ng workflow.

Paano gumagana ang mga managed workflow​

Mag-upload ka ng workflow nang isang beses at magpatakbo ng kasing dami ng job na kailangan mo. Gumagana ang bawat job sa mga sumusunod na paraan:

  • Nagsisimula ang job sa bagong environment na may walang lamang local disk. Isinasara ng mga managed workflow ang environment pagkatapos matapos ang job.

  • Tumatakbo ang job sa isa sa mga compute size na tinukoy mo noong ina-upload ang workflow. Puwede kang pumili ng ibang size sa bawat run.

  • Puwedeng magbasa at magsulat ang job sa file storage ng workflow. Nananatili ang mga file sa file storage pagkatapos matapos ang job.

Dahil nagsisimula ang bawat job sa walang lamang local disk, makikita lang ng susunod na job ang mga file na na-save ng naunang job sa file storage.

Lifecycle ng isang run​

Tumatakbo nang asynchronous ang bawat job hanggang 24 oras. Puwede kang magkaroon ng hanggang 50 active job nang sabay kung sapat ang allocation ng instance mo.

From your Python session, you call upload() one time to upload the workflow's code, packages, and compute profiles. No job exists yet. Each call to run(args) creates a job that moves through these stages: Queue, where it waits for allocation with status QUEUED; Start, where the managed workflow creates the environment with status INITIALIZING; Running, where your code can optionally set stages with update_status(): Mapping (RUNNING: MAPPING), Optimizing (RUNNING: OPTIMIZING_FOR_HARDWARE), Waiting for QPU (RUNNING: WAITING_FOR_QPU), Executing QPU (RUNNING: EXECUTING_QPU), and Post-processing (RUNNING: POST_PROCESSING); and Result, where the environment shuts down with status DONE, ERROR, or CANCELED. While running, the job reads and writes workflow file storage, which exists outside the job, is shared by all runs, and persists before and after each job. From your session, you can read status() from Queue onward, logs() from Running onward, and result() after the job reaches Result. All three remain available after the job ends.

Inilalarawan ng sumusunod na table ang bawat stage sa diagram at ang job status na makikita mo sa stage na iyon:

StageAno ang nangyayariJob status
UploadIna-upload mo ang code, mga dependency, at mga size ng workflow. Tinatanggihan ng workflow ang invalid na upload bago tumakbo ang anumang job.Wala (wala pang job)
QueueTinatawag mo ang run(). Tine-tsek ng workflow kung sapat ang allocation ng instance mo, at ini-schedule ang job kapag available na ang compute.QUEUED
StartGumagawa ang workflow ng environment gamit ang compute profile na pinili mo.INITIALIZING
RunTumatakbo ang entrypoint ng workflow mo. Puwedeng i-report ng entrypoint ang progress nito gamit ang update_status(), at mababasa mo ang mga log nito gamit ang logs() habang tumatakbo ito.RUNNING, o isang stage na itinakda mo, tulad ng RUNNING: WAITING_FOR_QPU
ResultNatatapos ang job, at isinasara ng workflow ang environment nito, habang pinapanatili ang result at mga log.DONE, ERROR, o CANCELED

Ano ang maa-access ng tumatakbong job​

Tumatakbo ang bawat job sa isolated na environment. Ipinapakita ng sumusunod na diagram at table ang mga resource na magagamit ng tumatakbong job.

You call run() with arguments from your Python session and receive status, logs, and the result. Inside the managed workflow, each run executes in an isolated job environment with access to its compute (CPU, RAM, and optionally GPU), your code and packages, and its arguments. The job produces outputs with save_result(), logs, and update_status(), and submits QPU jobs that run on your instance. File storage and your instance, which provides access and cost management, are shared across all managed workflow jobs and persist after the job ends. The job has no internet access.

ResourceAno ang magagamit ng job
ComputeAng CPU, memory, at mga GPU ng compute profile na pinili mo para sa job.
Code at mga packageAng mga file na in-upload mo kasama ng workflow, at ang mga sinusuportahang package na naka-install sa environment.
Mga argumentAng mga argument na ipinasa mo sa run(). Basahin ang mga ito gamit ang get_arguments().
QPU accessAng mga credential at instance na ginamit mo sa pagtawag ng run(). Tumatakbo sa instance mo ang mga QPU job na isinusumite ng workflow at bumibilang ang mga ito sa usage mo.
Mga outputAng result na sine-save ng job gamit ang save_result(), mga log na pini-print ng job, at mga status update na itinatakda ng job gamit ang update_status().
File storageMga file na pinagsasaluhan ng lahat ng run mo ng workflow. Nananatili ang mga file sa storage pagkatapos matapos ang job.
InternetWalang access. Hindi makakagawa ng outbound na koneksyon ang job. I-declare ang mga package kapag ina-upload ang workflow, at magbigay ng data bilang mga argument o file.

Seguridad at isolation​

Ini-isolate ng mga managed workflow ang bawat job mula sa ibang mga job at nililimitahan ang mga privilege ng code na tumatakbo rito. Bahagi ng isolation na ito ang mga access boundary sa naunang table. Naglalapat din ang mga managed workflow ng mga sumusunod na proteksyon:

  • Job isolation. Walang ibang job na tumatakbo sa environment ng job mo. Kasama rito ang mga job ng ibang user at ang sarili mong mga job na sabay na tumatakbo.

  • Mga result, log, at storage. Ang user lang na nagpatakbo ng job ang makakabasa ng mga result at log nito.

  • Mga credential. Ine-encrypt ng mga managed workflow ang mga credential na ginagamit ng job, kasama ang API token mo, kapag sine-store ang mga ito. Mababasa ng workflow code mo ang mga credential na ito habang tumatakbo ang job.

  • Mga privilege. Inaalis ng mga managed workflow ang administrator-level na privilege sa environment bago magsimula ang entrypoint mo.

Ikumpara sa on-premises HPC​

Iba ang mga managed workflow sa on-premises HPC cluster sa kung paano ka kumukuha ng compute time, nagse-set up ng software, at nagsusumite ng mga job. Inihahambing ng sumusunod na table ang mga karaniwang gawain.

GawainOn-premises HPC clusterMga managed workflow
Kumuha ng compute timeHumiling ng allocation o reservation sa administrator ng cluster.Gamitin ang allocation ng IBM Quantum instance mo. Ini-queue ng workflow ang bawat job kapag tinawag mo ang run().
I-access ang systemKumonekta sa login node gamit ang SSH.Gamitin ang Python client sa local computer mo. Hindi nagbibigay ng login node ang mga managed workflow.
Mag-install ng softwareMag-build ng software, mag-load ng mga module, o humingi sa administrator na mag-install ng mga package.Gamitin ang mga sinusuportahang package na naka-install sa bawat environment, o mag-upload ng mga wheel para sa ibang package.
Magsumite ng jobSumulat ng batch script at isumite ito sa scheduler.Tawagin ang run() kasama ang mga argument ng job.
Humiling ng mga resourceHumiling ng mga node, CPU, memory, at GPU.Pumili ng isa sa mga compute size na tinukoy para sa workflow. Tumatakbo ang bawat job sa iisang node.
Magpatakbo ng parameter sweepMagsumite ng job array.Tawagin ang run() nang isang beses para sa bawat set ng mga argument.
Mag-store ng shared na fileSumulat sa shared scratch file system.Sumulat sa file storage ng workflow.
Limitahan ang run timeMagtakda ng wall-time limit.Kinakansela ng workflow ang job pagkatapos ng 24 oras.
Mag-checkpoint ng mahahabang jobSumulat ng mga checkpoint sa scratch storage.Mag-save ng mga intermediate result sa file storage.
Patakbuhin ulit ang na-fail na jobIsumite ulit ang job.Tawagin ulit ang run(). Hindi awtomatikong nire-retry ng workflow ang mga na-fail na job.
Mag-monitor ng mga jobTingnan ang queue at mga log file mula sa login node.Tingnan ang status, mga log, at result ng bawat job mula sa local Python session mo.

Mga susunod na hakbang​

Mga rekomendasyon
Pinagmulan: Dokumentasyon ng IBM Quantum — na-update noong Nob 6, 2026
Bersyong Ingles sa doQumentation — na-update noong Nob 6, 2026
Isyu sa site o pagsasalin?Isyu sa nilalaman? I-edit sa IBM Quantum docs