Saltar al contenido principal
Este proyecto está en fase beta. ¿Encontraste un error? Abre un issue en GitHub. ¿Tienes una pregunta o una idea? Pregunta en Discussions — ¡nos encantaría tu opinión!
¿Cómo es la calidad de la traducción en esta página?

Introducción a los flujos de trabajo gestionados

Disponibilidad del plan

Qiskit Functions y los flujos de trabajo gestionados son funciones beta disponibles solo para usuarios de los planes Premium, Flex y On-Prem (a través de la API de IBM Quantum® Platform).

Los flujos de trabajo gestionados ejecutan tu código Python personalizado en cómputo clásico que IBM Quantum Platform gestiona por ti. Usa los flujos de trabajo gestionados para ejecutar flujos de trabajo híbridos cuántico-clásicos, diagonalización a gran escala y tareas paralelas de larga duración sin gestionar infraestructura de cómputo ni almacenamiento.

Cuándo usar un flujo de trabajo gestionado​

Usa un flujo de trabajo gestionado cuando ninguna Catalog Function prediseñada cubra tu tarea, o cuando quieras empaquetar tu propio método como una función reutilizable. Los flujos de trabajo gestionados son una buena opción cuando quieres hacer lo siguiente:

  • Ejecutar jobs largos en la nube. Un flujo de trabajo gestionado sigue ejecutándose cuando cierras tu portátil, y puedes volver a conectarte al job más tarde.

  • Usar nodos con gran memoria y GPU. Elige los recursos de memoria, CPU y GPU que necesita la carga de trabajo.

  • Ejecutar tareas en paralelo. Inicia muchos jobs de un solo nodo al mismo tiempo.

Tú proporcionas el código del flujo de trabajo, sus dependencias y los tamaños de cómputo que admite. Los flujos de trabajo gestionados ejecutan el flujo de trabajo en cómputo gestionado por IBM® en un entorno prediseñado con tus paquetes instalados, y proporcionan almacenamiento en la nube para los archivos que el flujo de trabajo lee y escribe.

Cómo funcionan los flujos de trabajo gestionados​

Subes un flujo de trabajo una sola vez y ejecutas todos los jobs que necesites. Cada job funciona de las siguientes maneras:

  • El job se inicia en un entorno nuevo con un disco local vacío. Los flujos de trabajo gestionados apagan el entorno cuando el job termina.

  • El job se ejecuta en uno de los tamaños de cómputo que defines al subir el flujo de trabajo. Puedes elegir un tamaño diferente para cada ejecución.

  • El job puede leer y escribir en el almacenamiento de archivos del flujo de trabajo. Los archivos del almacenamiento de archivos permanecen después de que el job termina.

Como cada job comienza con un disco local vacío, un job posterior solo puede encontrar los archivos que un job anterior guardó en el almacenamiento de archivos.

Ciclo de vida de una ejecución​

Cada job se ejecuta de forma asíncrona durante un máximo de 24 horas. Puedes tener hasta 50 jobs activos al mismo tiempo si tu instancia tiene asignación suficiente.

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.

La siguiente tabla describe cada etapa del diagrama y el estado del job que ves durante esa etapa:

EtapaQué ocurreEstado del job
SubidaSubes el código del flujo de trabajo, sus dependencias y sus tamaños. El flujo de trabajo rechaza una subida no válida antes de que se ejecute cualquier job.Ninguno (aún no hay job)
ColaLlamas a run(). El flujo de trabajo comprueba si tu instancia tiene asignación suficiente y programa el job cuando hay cómputo disponible.QUEUED
InicioEl flujo de trabajo crea un entorno con el perfil de cómputo que seleccionaste.INITIALIZING
EjecuciónSe ejecuta el punto de entrada de tu flujo de trabajo. El punto de entrada puede informar de su progreso con update_status(), y puedes leer sus registros con logs() mientras se ejecuta.RUNNING, o una etapa que establezcas, como RUNNING: WAITING_FOR_QPU
ResultadoEl job termina y el flujo de trabajo apaga su entorno, conservando el resultado y los registros.DONE, ERROR o CANCELED

A qué puede acceder un job en ejecución​

Cada job se ejecuta en un entorno aislado. El siguiente diagrama y la siguiente tabla muestran los recursos que puede usar un job en ejecución.

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.

RecursoQué puede usar el job
CómputoLa CPU, la memoria y las GPU del perfil de cómputo que seleccionaste para el job.
Código y paquetesLos archivos que subiste con el flujo de trabajo y los paquetes admitidos que están instalados en el entorno.
ArgumentosLos argumentos que pasaste a run(). Léelos con get_arguments().
Acceso a QPULas credenciales y la instancia que usaste para llamar a run(). Los jobs de QPU que envía el flujo de trabajo se ejecutan en tu instancia y cuentan para tu uso.
SalidasUn resultado que el job guarda con save_result(), los registros que el job imprime y las actualizaciones de estado que el job establece con update_status().
Almacenamiento de archivosArchivos que comparten todas tus ejecuciones del flujo de trabajo. Los archivos permanecen en el almacenamiento después de que el job termina.
InternetSin acceso. Un job no puede establecer conexiones salientes. Declara los paquetes al subir el flujo de trabajo y proporciona los datos como argumentos o archivos.

Seguridad y aislamiento​

Los flujos de trabajo gestionados aíslan cada job de los demás jobs y limitan los privilegios del código que se ejecuta en él. Los límites de acceso de la tabla anterior forman parte de este aislamiento. Los flujos de trabajo gestionados también aplican las siguientes protecciones:

  • Aislamiento de jobs. Ningún otro job se ejecuta en el entorno de tu job. Esto incluye los jobs de otros usuarios y tus propios jobs que se ejecutan al mismo tiempo.

  • Resultados, registros y almacenamiento. Solo el usuario que ejecutó un job puede leer sus resultados y registros.

  • Credenciales. Los flujos de trabajo gestionados cifran las credenciales que usa un job, incluido tu token de API, cuando las almacenan. El código de tu flujo de trabajo puede leer estas credenciales mientras el job se ejecuta.

  • Privilegios. Los flujos de trabajo gestionados eliminan los privilegios de nivel de administrador del entorno antes de que se inicie tu punto de entrada.

Comparación con HPC local​

Los flujos de trabajo gestionados difieren de un clúster HPC local en cómo obtienes tiempo de cómputo, configuras el software y envías jobs. La siguiente tabla compara tareas habituales.

TareaClúster HPC localFlujos de trabajo gestionados
Obtener tiempo de cómputoSolicita una asignación o una reserva al administrador del clúster.Usa la asignación de tu instancia de IBM Quantum. El flujo de trabajo pone en cola cada job cuando llamas a run().
Acceder al sistemaConéctate a un nodo de inicio de sesión con SSH.Usa el cliente de Python en tu computadora local. Los flujos de trabajo gestionados no proporcionan un nodo de inicio de sesión.
Instalar softwareCompila software, carga módulos o pide a un administrador que instale paquetes.Usa los paquetes admitidos que están instalados en cada entorno, o sube wheels para otros paquetes.
Enviar un jobEscribe un script por lotes y envíalo al planificador.Llama a run() con los argumentos del job.
Solicitar recursosSolicita nodos, CPU, memoria y GPU.Selecciona uno de los tamaños de cómputo definidos para el flujo de trabajo. Cada job se ejecuta en un único nodo.
Ejecutar un barrido de parámetrosEnvía un arreglo de jobs.Llama a run() una vez por cada conjunto de argumentos.
Almacenar archivos compartidosEscribe en un sistema de archivos scratch compartido.Escribe en el almacenamiento de archivos del flujo de trabajo.
Limitar el tiempo de ejecuciónEstablece un límite de tiempo de reloj.El flujo de trabajo cancela un job después de 24 horas.
Guardar puntos de control en jobs largosEscribe puntos de control en el almacenamiento scratch.Guarda los resultados intermedios en el almacenamiento de archivos.
Volver a ejecutar un job fallidoVuelve a enviar el job.Llama a run() de nuevo. El flujo de trabajo no reintenta automáticamente los jobs fallidos.
Supervisar jobsConsulta la cola y los archivos de registro desde el nodo de inicio de sesión.Consulta el estado, los registros y el resultado de cada job desde tu sesión local de Python.

Próximos pasos​

Recomendaciones
Fuente: Documentación de IBM Quantum — actualizado el 6 nov 2026
Versión en inglés en doQumentation — actualizado el 6 nov 2026
¿Problema con el sitio o la traducción?¿Problema de contenido? Editar en IBM Quantum docs