Saltar al contenido principal

Introducción a los modos de ejecución de Qiskit Runtime

Cuando se introdujo Qiskit Runtime, los usuarios solo podían ejecutar circuits como trabajos individuales. A medida que fueron surgiendo distintos tipos de cargas de trabajo cuánticas, se hizo evidente la necesidad de diferentes estrategias de programación. Los modos de ejecución determinan cómo se programan tus trabajos, y elegir el modo correcto permite que tu carga de trabajo se ejecute de manera eficiente dentro de tu presupuesto. Existen tres modos de ejecución: job, session y batch.

Modo job​

Una solicitud primitiva individual del estimator o del sampler realizada sin un context manager. Los circuits y las entradas se empaquetan como primitive unified blocs (PUBs) y se envían como una tarea de ejecución al ordenador cuántico. Para ejecutar en modo job, especifica mode=backend al instanciar una primitiva. Consulta Ejemplos de primitivas para ver su uso.

Modo batch​

Un gestor de múltiples trabajos para ejecutar eficientemente experimentos que comprenden cargas de trabajo de múltiples trabajos. Estas cargas de trabajo están compuestas por trabajos ejecutables de forma independiente que no tienen ninguna relación condicional entre sí. Con el modo batch, los usuarios envían todos sus trabajos a la vez.

El sistema paraleliza o divide en hilos el paso de preprocesamiento (computación clásica) de cada trabajo primitivo para empaquetar de manera más compacta la ejecución cuántica entre trabajos, y luego ejecuta la parte cuántica de cada trabajo en rápida sucesión para ofrecer los resultados más eficientes. Para más detalles sobre el manejo de hilos, consulta la página de preguntas frecuentes sobre modos de ejecución.

Un conjunto de trabajos ejecutándose en modo batch. La parte de computación clásica de cada trabajo ocurre simultáneamente, luego todos los trabajos se envían a la QPU. La QPU queda reservada para tu uso desde que el primer trabajo llega a la QPU hasta que el último trabajo termina de procesarse. No hay ningún intervalo entre trabajos en el que la QPU esté inactiva.

Notas
  • Al usar el modo batch, no se garantiza que los trabajos se ejecuten en el orden en que se enviaron. Además, aunque tus trabajos batch se ejecutarán lo más juntos posible, no obtienen acceso exclusivo al backend. Por lo tanto, tus trabajos batch podrían ejecutarse en paralelo con los trabajos de otros usuarios si hay suficiente capacidad de procesamiento en la QPU. Además, los trabajos de calibración de la QPU podrían ejecutarse entre los trabajos del batch.
  • El tiempo de espera en cola no disminuye para el primer trabajo enviado dentro de un batch. Por lo tanto, los batches no ofrecen ningún beneficio al ejecutar un único trabajo.

Para ejecutar en modo batch, especifica mode=batch al instanciar una primitiva o ejecuta el trabajo en un context manager de batch. Consulta Ejecutar trabajos en un batch para ver ejemplos.

Modo session​

Una ventana dedicada para ejecutar una carga de trabajo de múltiples trabajos. Durante esta ventana, el usuario tiene acceso exclusivo al sistema y ningún otro trabajo puede ejecutarse, incluidos los trabajos de calibración. Esto permite a los usuarios experimentar con algoritmos variacionales de manera más predecible e incluso ejecutar múltiples experimentos simultáneamente, aprovechando el paralelismo en la pila. Usar sessions ayuda a evitar los retrasos causados por poner en cola cada trabajo por separado, lo cual puede ser especialmente útil para tareas iterativas que requieren comunicación frecuente entre recursos clásicos y cuánticos.

Un conjunto de trabajos ejecutándose en modo session y otro en modo batch. Entre cada trabajo se encuentra el TTL interactivo (tiempo de vida interactivo). La ventana activa comienza cuando el primer trabajo se inicia y termina una vez que el último trabajo se completa. Después de que el último trabajo del primer conjunto finaliza, la ventana activa termina y la session se pausa (pero no se cierra). Luego comienza otro conjunto de trabajos que continúan de manera similar. La QPU está reservada para tu uso durante toda la session.

Para ejecutar en modo session, especifica mode=session al instanciar una primitiva, o ejecuta el trabajo en un context manager de session. Consulta Ejecutar trabajos en una session para ver ejemplos.

Notas
  • El tiempo de espera en cola no disminuye para el primer trabajo enviado dentro de una session. Por lo tanto, las sessions no ofrecen ningún beneficio al ejecutar un único trabajo.
  • Los usuarios del plan Open no pueden enviar trabajos de session.

Flujo de trabajo básico​

El flujo de trabajo básico para batches y sessions es similar:

  1. El primer trabajo en un batch o session entra en la cola normal. En el caso de los batches, todo el batch de trabajos se programa de forma conjunta.
  2. Cuando el primer trabajo comienza a ejecutarse, el temporizador del tiempo de vida máximo (TTL) se inicia y no se detiene ni pausa hasta que llega al final.
  3. El temporizador de TTL interactivo comienza después de que se completa cada trabajo. Si no hay trabajos de carga de trabajo listos dentro de la ventana de TTL interactivo, la carga de trabajo se desactiva temporalmente y se reanuda la selección normal de trabajos. Un trabajo puede reactivar la carga de trabajo desactivada si el batch o la session no ha alcanzado su valor máximo de TTL.
    nota

    El trabajo debe pasar por la cola normal para reactivar la carga de trabajo.

  4. Si se alcanza el valor máximo de TTL, la carga de trabajo finaliza y los trabajos en cola restantes fallan. Cualquier trabajo que se esté ejecutando no llegará a completarse si hacerlo supera el límite de costos de la instancia.

El siguiente video ilustra el flujo de trabajo básico usando sessions como ejemplo:

Para obtener todos los detalles sobre los temporizadores TTL, consulta la guía de Tiempo máximo de ejecución.

Próximos pasos​

Recomendaciones