Trabajos dry-run

Un trabajo dry-run ejecuta tu carga de trabajo a través de IBM Quantum® Compute Service sin usar tiempo de QPU. Usa un trabajo dry-run para hacer lo siguiente antes de comprometerte con una ejecución real:

• **Obtener el uso que el trabajo tendría en la QPU real.

• Validar el trabajo. Quantum Compute comprueba los parámetros del trabajo, igual que lo hace con un trabajo real.

• Obtener el calendario de temporización del circuito, si lo solicitas, para depurar el trabajo antes de ejecutarlo de verdad.

A diferencia de los trabajos dry-run, las pruebas locales (backends falsos y Qiskit Aer) se ejecutan en tu propia máquina y, por lo tanto, no pueden proporcionar cifras de uso, validación del lado del servicio ni información de temporización del servicio. Para comparar ambos enfoques, consulta Dispositivos mock frente a backends falsos.

nota

• Se requiere qiskit-ibm-runtime v0.51.0 o posterior para los trabajos dry-run.
• Los trabajos dry-run están disponibles en todas las regiones y solo en los planes Flex, Premium y On-Prem. No están disponibles en los planes Open ni Pay-As-You-Go.

Cómo funciona

Para ejecutar un trabajo dry-run, pasa dry_run=True al método run() de la primitiva:

backend = service.backend("ibm_phoenix")
isa_circuit = pm.run(circuit)  # transpiled for ibm_phoenix
sampler = Sampler(mode=backend)
job = sampler.run([isa_circuit], dry_run=True)
job.result()  # wait for completion
print(job.usage())

dry_run es un argumento del método run() (el valor predeterminado es False), no una opción de runtime. Está disponible para todas las primitivas.

Un trabajo dry-run tiene las siguientes características:

• Se ejecuta en IBM Quantum Compute Service en la nube, no en tu máquina.

• Usa los datos de calibración de la QPU real, no solo una instantánea.

• Sus resultados conservan el esquema esperado y siguen la forma esperada de los resultados de la QPU real, pero contienen datos mock aleatorizados. No son resultados de medición reales ni simulados, así que no los uses para comprobar la corrección física.

• El procesamiento ocurre en el servidor, por lo que es posible que el trabajo no termine de inmediato.

El tamaño del circuito, los shots y otros límites son los mismos que para cualquier trabajo de ese programa.

dry_run=True también funciona cuando el backend ya es un dispositivo mock.

Lee el uso

El uso de un trabajo dry-run completado es el uso que el mismo trabajo tendría en la QPU real, salvo en raras situaciones en las que los datos de calibración cambian de forma significativa después del trabajo dry-run y antes del trabajo en una QPU real.

• job.usage() devuelve el uso en segundos.

• job.metrics()["usage"] devuelve los mismos datos junto con el estado del uso.

El uso de dry-run no se cobra, no consume la asignación de tu plan y no cuenta para ningún límite.

No uses job.usage_estimation con trabajos dry-run

No uses job.usage_estimation en un trabajo dry-run. Usa job.usage().

job.usage() devuelve 0 hasta que el cálculo del uso sea definitivo, así que espera a que el trabajo termine antes de leerlo.

Calendario de temporización del circuito

Para solicitar el calendario de temporización del circuito, usa la misma opción que para un trabajo real. Para más detalles, consulta Visualizar la temporización del circuito.

Limitaciones

• Solo modos job y batch. Los trabajos dry-run solo pueden ejecutarse en job mode y batch mode.

• Solo planes Flex, Premium y On-Prem. Los trabajos dry-run no están disponibles en los planes Open ni Pay-As-You-Go.

Dispositivos mock

Los dispositivos mock son la implementación que hay detrás de los trabajos dry-run. Los trabajos dry-run ocultan los dispositivos mock de forma predeterminada, pero te los encontrarás en estos casos:

• Instancias configuradas para acceder solo a dispositivos mock. Ejemplo: si usas service.backend("ibm_phoenix") para enviar un trabajo dry-run a ibm_phoenix, pero tu instancia no tiene acceso a ibm_phoenix, obtendrás un QiskitBackendNotFoundError. En su lugar, selecciona el dispositivo mock directamente con service.backend("mock_phoenix").

• Recursos de cómputo. Los dispositivos mock están ocultos de forma predeterminada en la página de Recursos de cómputo. La tabla de la página tiene una opción de filtro para incluirlos, pero solo los planes Flex, Premium y On-Prem tienen acceso a los dispositivos mock.

• Tabla de cargas de trabajo. Los trabajos de dispositivos mock están ocultos de forma predeterminada en la página de Cargas de trabajo. La tabla tiene una opción de filtro (el icono de embudo) para mostrarlos.

• API de Python. service.backends() y service.jobs() excluyen los dispositivos mock a menos que los llames con include_mocks=True. IBMBackend.is_mock indica si un backend es un dispositivo mock. service.least_busy() nunca devuelve un dispositivo mock.

Dispositivos mock frente a backends falsos

Los nombres son parecidos, pero un dispositivo mock y un backend falso son cosas distintas. Un backend falso es un objeto local en tu entorno de Python. Un dispositivo mock es un recurso en la nube en IBM Quantum Compute Service.

	Dispositivo mock (por ejemplo mock_phoenix)	Backend falso (por ejemplo FakeManilaV2)
Qué es	Un dispositivo en IBM Quantum Compute Service	Una clase de Python en qiskit_ibm_runtime.fake_provider
Dónde se ejecuta	En la nube, en el servicio	Localmente, en tu máquina
Cómo se obtiene	service.backend("mock_phoenix"), o automáticamente con run(..., dry_run=True)	from qiskit_ibm_runtime.fake_provider import ...
Cuenta e instancia	Solo planes específicos (Flex, Premium u On-Prem)	Todas las instancias y planes
Calibración	En vivo, coincide con el dispositivo real en todo momento	Instantánea fija incluida con el paquete instalado
Resultados	Datos aleatorizados con el esquema esperado. No es una simulación	Simulación con ruido que usa el modelo de ruido de la instantánea
Resultados con significado físico	No. Nunca los uses para comprobar la corrección	Aproximadamente, dentro de los límites del modelo de ruido
Uso informado	Sí	Ninguno
Cobrado o contabilizado en la asignación del plan o en los límites	No	No
Validación del trabajo	La realiza el servicio, igual que con un trabajo real	Limitada a lo que comprueba el cliente
Calendario de temporización	Disponible bajo solicitud	No disponible
Modos de ejecución	Solo job mode y batch mode. Las sesiones están bloqueadas	La sintaxis de sesión se acepta pero se ignora (el modo local no tiene sesiones ni batches reales)
Finalización	Asíncrona, en el servidor	Se ejecuta localmente y devuelve el resultado al terminar
Se muestra en la interfaz de la plataforma y en las listas de la API	Oculto de forma predeterminada (Recursos de cómputo, tabla de cargas de trabajo, backends(), jobs()). Actívalo para mostrarlo	Nunca, porque no se envía nada al servicio

Cómo elegir

• Para saber cuánto uso consumirá el trabajo o si el servicio lo aceptará, usa un trabajo dry-run.

• Para saber qué aspecto podría tener la salida, o para trabajar sin conexión, usa un backend falso o Aer.

• Para hacer ambas cosas, itera sobre circuitos y resultados con un backend falso y luego haz un dry-run como comprobación final antes de la QPU real.

Puntos de confusión comunes

• Un dispositivo mock no es un simulador. Su salida es aleatoria, así que muestrear un circuito de Bell en mock_phoenix no devuelve una distribución de Bell. Si quieres una salida con ruido realista, usa un backend falso.

• Un backend falso no es el dispositivo en vivo. Su calibración es una instantánea y puede estar desactualizada. Un dispositivo mock sigue la calibración real, de modo que los circuitos transpilados y la temporización coinciden con lo que la QPU ve hoy.

• Ninguno se ejecuta en hardware real. Ninguno consume tiempo de QPU, pero solo un trabajo dry-run pasa por el servicio.

• usage_estimation no es la estimación de dry-run. Para un trabajo dry-run, job.usage() devuelve los segundos de uso que se te cobrarían por tu trabajo en una QPU real.

Casos de uso

Estudiantes y cursos

Un administrador restringe una instancia solo a dispositivos mock, usando el interruptor de personalización de QPU al crear o editar la instancia. Así, los estudiantes validan sus cargas de extremo a extremo sin consumir tiempo real de QPU ni RU. Como la instancia solo tiene acceso a dispositivos mock, los estudiantes seleccionan el backend por su nombre mock:

backend = service.backend("mock_phoenix")
sampler = Sampler(mode=backend)
job = sampler.run([isa_circuit], dry_run=True)

Planificación de proyectos

Un equipo que está por comenzar un proyecto ejecuta dry-run de trabajos representativos para ver las RU que necesita el proyecto, antes de elegir un plan o una asignación:

backend = service.backend("ibm_phoenix")
sampler = Sampler(mode=backend)
job = sampler.run([isa_circuit], dry_run=True)
job.result()
print(job.usage()) 

Comprobación final antes de ejecutar en una QPU real

Valida los parámetros e inspecciona el calendario de temporización con dry_run=True, luego quita el argumento y ejecuta en la QPU real. Nada más cambia en tu código:

sampler = Sampler(mode=backend)

# Pre-flight check
job = sampler.run([isa_circuit], dry_run=True)
job.result()

# Real run - same code, without dry_run
job = sampler.run([isa_circuit])

Próximos pasos

Recomendaciones

• Prueba programas en tu propia máquina con el modo de pruebas local.
• Aprende cómo se mide el uso de la carga de trabajo.
• Visualiza el calendario de temporización del circuito.
• Comprende las unidades de recursos y los planes disponibles.