Preguntas frecuentes sobre los modos de ejecución de Qiskit Runtime
¿El modo de prueba local de Qiskit Runtime admite diferentes modos de ejecución?
El modo de prueba local admite la sintaxis de los distintos modos de ejecución, pero como no hay programación involucrada al probar localmente, los modos se ignoran.
¿Cuántos jobs pueden ejecutarse en paralelo para un backend específico?
El número de jobs que se ejecutan en paralelo se basa en el grado de paralelismo configurado para el backend, que es cinco para la mayoría de los backends hoy en día.
¿Cómo se reporta el uso para jobs fallidos o cancelados?
Consulta la sección Jobs fallidos y cancelados en la página de modos de ejecución.
Sesiones
¿Qué ocurre con mis jobs si se cierra una sesión?
Si estás usando la clase Session en qiskit-ibm-runtime:
Session.close()significa que la sesión ya no acepta nuevos jobs, pero los jobs existentes se ejecutan hasta completarse.Session.cancel()cancela todos los jobs pendientes de la sesión.
Si estás usando la API REST directamente:
PATCH /sessions/{id}conaccepting_jobs=Falsesignifica que la sesión ya no acepta nuevos jobs, pero los jobs existentes se ejecutan hasta completarse.DELETE /sessions/{id}/closecancela todos los jobs pendientes de la sesión.
Si estoy usando el modo de sesión y espero que mi experimento tarde muchas horas, ¿hay alguna forma de solicitar que se realicen calibraciones?
No. La calibración bajo demanda no está disponible.
¿Existe un tiempo de espera interactivo (TTL interactivo) en el modo de sesión?
Sí. Esto reduce costos no deseados si un usuario olvida cerrar su sesión.
¿Puedo cambiar el TTL interactivo o el TTL máximo de una sesión?
No puedes cambiar el valor del TTL interactivo. Puedes cambiar el valor del TTL máximo de una sesión (consulta Especificar la duración de la sesión), pero debe ser menor que el máximo definido por el sistema. Pide a tu administrador que contacte con el soporte de IBM si necesitas un TTL interactivo o un TTL máximo del sistema diferente.
¿Cómo afecta el uso de sesiones a los miembros de IBM Quantum Network que no se facturan por uso?
Los miembros de IBM Quantum Network obtienen capacidad reservada en las QPUs de IBM Quantum®. El uso se deduce de esta capacidad y las instancias con menor capacidad tienen tiempos de espera en cola más largos.
¿Obtengo el mismo paralelismo en el modo de sesión que en el modo batch?
Sí. Si envías múltiples jobs simultáneamente en una sesión, estos jobs se ejecutarán en paralelo.
¿Pueden las sesiones ser interrumpidas por actualizaciones de QPU o calibraciones?
No. Las sesiones se ejecutan en modo dedicado, lo que significa que el usuario tiene acceso total al backend. Las sesiones nunca son interrumpidas por calibraciones ni actualizaciones de software.
¿El tiempo de compilación se contabiliza como uso en el modo de sesión?
Sí. En el modo de sesión, el uso es el tiempo de reloj de pared que la QPU está comprometida con la sesión. Comienza cuando arranca el primer job de la sesión y termina cuando la sesión queda inactiva, se cierra o cuando se completa el último job, lo que ocurra último. Por lo tanto, el uso continúa acumulándose después de que finaliza una sesión si la QPU todavía está ejecutando un job. Además, el tiempo transcurrido después de que se completa un job mientras la QPU espera otro job de sesión (el TTL interactivo) cuenta como uso. Por eso debes asegurarte de cerrar la sesión tan pronto como termines de enviar jobs.
Batch
¿Cuántos jobs se ejecutan en paralelo en el modo batch?
El número de jobs que se ejecutan en paralelo se basa en el grado de paralelismo configurado para el backend, que es cinco para la mayoría de los backends. Sin embargo, el número de jobs concurrentes en un batch activo podría ser menor porque puede haber otros jobs ya en ejecución cuando el batch se active.
¿En qué se diferencia ejecutar N PUBs en modo job de ejecutar N jobs de un solo PUB en modo batch?
La diferencia principal está en el balance entre tiempo y costo:
Modo batch:
- El tiempo total de ejecución es menor porque el procesamiento clásico puede ejecutarse en paralelo.
- Existe un pequeño overhead por ejecutar cada job, por lo que terminas pagando un poco más por los jobs en batch. Este overhead está correlacionado con el tamaño del job. Por ejemplo, el uso total de dos jobs, cada uno con 40 circuitos de 100x100, es seis segundos más que un solo job con 80 circuitos.
- Como el modo batch no te da acceso exclusivo a un backend, los jobs dentro de un batch pueden ejecutarse junto con los jobs de otros usuarios o jobs de calibración.
- Si algunos jobs fallan, igual obtienes resultados de los jobs completados.
- Puedes tomar medidas en medio de una carga de trabajo batch basándote en los resultados de los jobs completados. Por ejemplo, puedes cancelar el resto de los jobs si los resultados iniciales parecen incorrectos.
Modo job:
- El tiempo total de ejecución probablemente sea mayor porque no hay paralelismo.
- No pagas el overhead adicional por job asociado con las cargas de trabajo en batch.
- Todos tus circuitos se ejecutarán juntos.
- Si este único job falla, no obtienes resultados parciales.
- Tu job podría alcanzar el límite si contiene demasiados circuitos o si los circuitos son muy grandes.
En general, si cada uno de tus jobs consume menos de un minuto de tiempo de QPU, considera combinarlos en un job más grande (esto aplica a todos los modos de ejecución).
¿Cuántos jobs puedo enviar en un batch?
Si bien no hay límites en el número de jobs que puedes enviar en un batch, existe un tiempo máximo asociado a un batch. Es decir, cuando el tiempo de reloj de pared de un batch (que comienza cuando el primer job del batch empieza a ejecutarse) supera el tiempo máximo definido por el sistema, el batch no aceptará nuevos jobs y cualquier job en cola que no esté ejecutándose será cancelado. Además, existen límites sobre cuánto uso pueden consumir tus jobs según tu plan. Para determinar el tiempo máximo asociado a un batch, usa el método batch.details() y busca el valor max_time.
¿Cuándo se ejecutarían mis jobs en modo batch en paralelo con los jobs de otros usuarios?
El grado de paralelismo configurado para un backend también se denomina "carriles de ejecución". Si hay uno o más carriles de ejecuci ón disponibles y tus jobs en batch son los siguientes en la cola, el planificador inicia suficientes jobs para llenar los carriles. Del mismo modo, si tu batch no tiene suficientes jobs para llenar los carriles, el planificador inicia los jobs de otros usuarios.
Ejemplo: El backend que eliges tiene cinco carriles de ejecución, y dos de ellos están actualmente ocupados por jobs de otros usuarios. Tu batch de seis jobs es el siguiente en la cola.
Como hay tres carriles disponibles, el planificador inicia tres de tus seis jobs del batch. Continúa iniciando jobs de tu batch a medida que los jobs terminan y los carriles de ejecución quedan disponibles. Si un carril queda disponible y no hay más jobs en tu batch, el planificador inicia el siguiente job en la cola.
¿Todos mis jobs en batch necesitan esperar en la cola?
Dado que las QPUs son recursos limitados y compartidos, todos los jobs necesitan esperar en la cola. Sin embargo, cuando el primer job de tu batch comienza a ejecutarse, todos los demás jobs de ese batch esencialmente pasan al frente de la cola y son priorizados por el planificador.
¿Un batch termina automáticamente cuando finaliza el último job asociado?
Sí. Sin embargo, hay un pequeño overhead asociado a esta detección automática, por lo que siempre debes cerrar tu batch y sesión.
¿Pueden los batches ser interrumpidos por calibraciones o actualizaciones de software?
Sí. Las cargas de trabajo en batch pueden ser interrumpidas por calibraciones o actualizaciones de software.
¿El tiempo de compilación se contabiliza como uso en el modo batch?
No. En el modo batch, solo el tiempo dedicado al hardware cuántico cuenta como uso.