Tareas de prueba

Una ejecución de prueba procesa tu carga de trabajo a través del servicio « IBM Quantum® Compute » sin consumir tiempo de la QPU. Utiliza una ejecución de prueba para realizar lo siguiente antes de pasar a una ejecución real:

• **Calcular el consumo que generaría el trabajo en la QPU real.
• Valida el trabajo. Quantum Compute comprueba los parámetros del trabajo, igual que lo hace con un trabajo real.
• Solicita el calendario de tiempos del circuito, si lo necesitas, para depurar el trabajo antes de ejecutarlo de verdad.

A diferencia de los trabajos de simulación, las pruebas locales (backends simulados y Qiskit Aer ) se ejecutan en tu propio equipo y, por lo tanto, no pueden proporcionar datos de uso, validación del lado del servicio ni información sobre los tiempos del servicio. Para comparar ambos enfoques, consulta «Comparación entre dispositivos simulados y backends falsos ».

Cómo funciona

Para ejecutar un trabajo de simulación, pasa dry_run=True al run() método 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 parámetro del run() método (el valor por defecto es False), no una opción de tiempo de ejecución. Está disponible para todas las primitivas.

Un trabajo de prueba presenta las siguientes características:

• Se ejecuta en el servicio « IBM Quantum Compute » en la nube, no en tu ordenador.
• Utiliza los datos de calibración de la QPU real, no solo una instantánea.
• Sus resultados mantienen el esquema previsto y siguen la estructura esperada de los resultados de la QPU real, pero contienen datos simulados aleatorios. No se trata de resultados de medición reales ni simulados, por lo que no debes utilizarlos para comprobar la corrección física.
• El procesamiento se realiza en el servidor, por lo que es posible que la tarea no finalice de inmediato.

El tamaño del circuito, el número de disparos 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 simulado.

Lee las instrucciones de uso

El consumo de un trabajo de simulación completado es el mismo que el que generaría ese mismo trabajo en una QPU real, salvo en contadas ocasiones en las que los datos de calibración cambien significativamente tras el trabajo de simulación y antes de que se ejecute el trabajo en una QPU real.

• job.usage() devuelve el tiempo de uso en segundos.
• job.metrics()["usage"] devuelve los mismos datos junto con el estado de uso.

El uso en modo de prueba no se cobra, no consume la asignación de tu plan y no cuenta a efectos de ningún límite.

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

Calendario de la temporada

Para solicitar el calendario de horarios del circuito, utiliza la misma opción que para un encargo real. Para obtener más información, consulta «Visualización de la sincronización de circuitos ».

Limitaciones

• Solo en modo de trabajo y por lotes. Los trabajos de prueba solo se pueden ejecutar en modo de trabajo y en modo por lotes.
• Solo para los planes Flex, Premium y « On-Prem ». Los trabajos de prueba no están disponibles en los planes «Open» ni «Pay-As-You-Go».

Dispositivos simulados

Los dispositivos simulados son la implementación que hay detrás de los trabajos de simulación. Los trabajos de prueba ocultan los dispositivos simulados de forma predeterminada, pero los encontrarás en los siguientes casos:

• Instancias configuradas para acceder únicamente a dispositivos simulados. Ejemplo: si utilizas service.backend("ibm_phoenix") para enviar un trabajo de prueba en ibm_phoenix, pero tu instancia no tiene acceso a ibm_phoenix, obtendrás un QiskitBackendNotFoundError. En su lugar, selecciona el dispositivo simulado directamente con service.backend("mock_phoenix").
• Recursos informáticos. Los dispositivos simulados aparecen ocultos por defecto en la página «Recursos de Compute ». La tabla de la página cuenta con una opción de filtro para incluirlos, pero solo los planes Flex, Premium y « On-Prem » tienen acceso a dispositivos de simulación.
• Tabla de cargas de trabajo. Los trabajos procedentes de dispositivos simulados aparecen ocultos por defecto en la página «Cargas de trabajo ». La tabla cuenta con una opción de filtro (el icono del embudo) para mostrarlos.
• API de Python. service.backends() y excluye service.jobs() los dispositivos simulados, a menos que los invoques con include_mocks=True. IBMBackend.is_mock indica si un backend es un dispositivo simulado. service.least_busy() Nunca devuelve un dispositivo simulado.

Dispositivos simulados frente a backends falsos

Los nombres son parecidos, pero un dispositivo simulado y un backend falso son cosas diferentes. Un backend falso es un objeto local en tu entorno de Python. Un dispositivo simulado es un recurso en la nube del servicio « IBM Quantum Compute ».

Cómo elegir

• Para saber cuánto recursos consumirá el trabajo o si el servicio lo aceptará, utiliza un trabajo de prueba.
• Para ver cómo podría ser el resultado o para trabajar sin conexión, utiliza un backend ficticio o Aer.
• Para hacer ambas cosas, realiza iteraciones sobre los circuitos y los resultados con un backend simulado y, a continuación, lleva a cabo una simulación como última comprobación antes de pasar a la QPU real.

Puntos que suelen generar confusión

• Un dispositivo de simulación no es un simulador. Su salida es aleatoria, por lo que el muestreo de un circuito de Bell en no mock_phoenix da como resultado una distribución de Bell. Si quieres obtener un resultado realista con ruido, utiliza un backend ficticio.
• Un backend falso no es el dispositivo en producción. Su calibración es una instantánea y puede que esté desactualizada. Un dispositivo simulado reproduce la calibración real, de modo que los circuitos transpilados y la sincronización coinciden con lo que ve actualmente la QPU.
• Ninguno de los dos funciona en hardware real. Ninguna de las dos opciones consume tiempo de la QPU, pero solo el trabajo de simulación pasa por el servicio.
• usage_estimation no es la estimación preliminar. En el caso de un trabajo de prueba, job.usage() devuelve los segundos de uso que se facturarían a tu trabajo en una QPU real.

Casos de uso

Estudiantes y cursos

Un administrador limita una instancia únicamente a dispositivos simulados mediante el conmutador de personalización de la QPU al crear o editar la instancia. A continuación, los estudiantes validan sus cargas útiles de principio a fin sin consumir tiempo real de la QPU ni unidades de recursos (RU). Dado que la instancia solo tiene acceso a dispositivos simulados, los alumnos seleccionan el backend por su nombre simulado:

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á a punto de iniciar un proyecto realiza simulacros de tareas representativas para determinar las unidades de trabajo (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 ejecutarlo en una QPU real

Valida los parámetros y comprueba el calendario de ejecución con dry_run=True, a continuación, elimina el argumento y ejecuta el programa en la QPU real. El resto del código no cambia:

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