Uso de carga de trabajo

El uso representa el consumo de IBM Quantum Compute Service y viene determinado por el tiempo que una QPU permanece bloqueada para ejecutar cargas de trabajo.

• El uso de sesión se mide como el tiempo transcurrido mientras la sesión permanece activa, ya que la capacidad de la QPU se reserva durante toda la sesión, independientemente de si hay cargas de trabajo en ejecución activa. Consulta Duración de la sesión para más información sobre las transiciones de estado de la sesión.

• El uso por lote se mide como el tiempo acumulado que la QPU permanece bloqueada para ejecutar todos los trabajos del lote.

• El uso de un trabajo individual se mide como el tiempo que la QPU permanece bloqueada para ejecutar el trabajo.

Ten en cuenta que los trabajos fallidos o cancelados cuentan para tu uso en determinadas circunstancias; consulta la sección Trabajos fallidos y cancelados para más detalles.

Para los usuarios del Plan de Pago Por Uso, consulta Administrar costos para más detalles sobre cómo establecer un límite de costos.

Uso para trabajos fallidos y cancelados

Cuando un trabajo falla o se cancela, el uso reportado es el siguiente:

• Job mode o batch mode: Si el fallo o la cancelación se debió a un error del sistema, el uso reportado es cero. Para los trabajos que fallaron por un error del usuario o cuando el usuario canceló un trabajo, el uso reportado es cualquier consumo que haya ocurrido hasta ese momento, incluida la sobrecarga incurrida para preparar la QPU para ejecutar el trabajo.

• Session mode: El uso reportado es el tiempo de reloj que la sesión estuvo activa, independientemente del número de trabajos que fallen o se cancelen.

Consultar el uso real de una carga de trabajo

Una vez que una carga de trabajo ha finalizado, hay varias formas de ver su uso real:

• En qiskit-ibm-runtime v0.30 o posterior, ejecuta job.usage() para un solo trabajo, o batch.usage() o session.usage() cuando uses batch mode o session mode. Si usas una versión anterior de qiskit-ibm-runtime (>= 0.23 y < 0.30), el uso aún puede encontrarse en session.details()["usage_time"] y batch.details()["usage_time"].

• Usa GET /sessions/{id} para ver el uso de un lote o sesión específicos (el endpoint es el mismo para ambos modos de ejecución).

• Usa GET /jobs/{id} para ver el uso de un trabajo individual.

Ver el uso de la instancia

Puedes ver el uso de una instancia en la página Instancias o, para quienes tengan la autoridad correspondiente, en la página Análisis. Ten en cuenta que las páginas pueden mostrar cifras de uso diferentes porque calculan el uso de forma distinta.

La página de Instancias muestra el uso en tiempo real de los últimos 28 días (período móvil), hasta el momento actual del día en curso. El uso de la página de Análisis se recalcula cada hora e incluye los últimos 28 días completos; es decir, muestra el uso desde las 00:00 de hace 28 días hasta hoy, al inicio de la hora en punto.

Estimar el uso antes de enviar un trabajo

Aunque obtener una estimación local precisa se complica por las operaciones adicionales realizadas para la supresión y mitigación de errores, puedes usar esta fórmula base para obtener una aproximación del uso estimado:

<per sub-job overhead> + (rep_delay + <circuit length>) * <num executions>

• <per sub-job overhead> es una sobrecarga de aproximadamente 2s por sub-trabajo. Esto incluye operaciones como la carga de la carga útil en la electrónica de control. Tu trabajo primitivo puede dividirse en varios sub-trabajos si es demasiado grande para que el motor de ejecución lo procese de una sola vez.

• rep_delay es una opción personalizable por el usuario, y el valor predeterminado está dado por backend.default_rep_delay, que es 250 microsegundos en la mayoría de los backends de IBM Quantum. Ten en cuenta que reducir rep_delay disminuye el tiempo total de ejecución en la QPU, pero a expensas de una mayor tasa de error en la preparación de estados; consulta la guía Ejecución con tasa de repetición dinámica para más información.

• <circuit length> es la longitud total de instrucciones. Cada instrucción toma una cantidad de tiempo diferente en el QPU, por lo que la longitud total varía de un circuito a otro. Una medición, por ejemplo, puede tardar 56 veces más que una puerta x. backend.target[<instruction>][<qubit>].duration puede usarse para encontrar la duración exacta de cada instrucción. Una longitud de circuito típica probablemente esté entre 50 y 100 microsegundos. Si estás usando técnicas de supresión o mitigación de errores con los primitivos, es posible que se inserten instrucciones adicionales en tu circuito, lo que aumentaría la longitud total del circuito.

  nota

  La opción experimental scheduler_timing devuelve el tiempo total del circuito, pero este NO es el tiempo usado para la facturación.

• <num executions> es el número total de circuitos multiplicado por el número de shots, donde los circuitos son los generados después de que se difunden (broadcast) los elementos PUB.

  • Si estás usando técnicas de mitigación de errores con los primitivos, es posible que se ejecuten circuitos adicionales como parte del proceso de mitigación, lo que aumentaría el número total de ejecuciones. Además, las técnicas avanzadas de mitigación de errores como PEA y PEC conllevan una sobrecarga mucho mayor porque requieren ejecutar circuitos para el aprendizaje de ruido.
  • Estimator agrupa observables que conmutan a nivel de qubit, lo que reduce el número de ejecuciones.

Si no estás usando ninguna técnica avanzada de mitigación de errores ni un rep_delay personalizado, puedes usar 2+0.00035*<num executions> como fórmula rápida.

Estimar el uso localmente con Qiskit

Este ejemplo de código muestra cómo usar Qiskit para calcular el tiempo de un circuito:

# Schedule the circuit to get more accurate timing
pm = generate_preset_pass_manager(
    target=backend.target,
    optimization_level=0,
    scheduling_method="alap"
)

scheduled_circuits = pm.run(isa_circuits)

init_duration = backend.target["reset"][(0,)].duration
rep_delay = sampler.options.execution.rep_delay or backend.default_rep_delay

circuit_duration = 0

for circuit in scheduled_circuits:
    # Estimate circuit length
    circuit_duration += circuit.estimate_duration(backend.target)

    # Add INIT time
    if sampler.options.execution.init_qubits:
        circuit_duration += init_duration

    # Add rep_delay
    circuit_duration += rep_delay

total_time = 2 + (circuit_duration*shots)
print(f"Total estimated usage is {math.ceil(total_time)} seconds")

Próximos pasos

Recomendaciones

• Revisa estos consejos: Minimizar el tiempo de ejecución de trabajos.
• Establece el Tiempo máximo de ejecución.
• Aprende a transpilar localmente en la sección Transpile.
• Prueba la guía Comparar configuraciones del Transpiler.