Uso do workload

Uso representa o consumo do Serviço IBM Quantum Compute e é determinado pelo tempo em que um QPU fica bloqueado para executar workloads.

• O uso de sessão é medido como o tempo decorrido enquanto a sessão permanece ativa, pois a capacidade do QPU fica reservada durante toda a sessão, independentemente de workloads estarem ativamente em execução. Veja Duração da sessão para mais informações sobre as transições de status da sessão.

• O uso de batch é medido como o tempo acumulado em que o QPU fica bloqueado para executar todos os jobs no batch.

• O uso de um único job é medido como o tempo em que o QPU fica bloqueado para executar o job.

Observe que jobs com falha ou cancelados contam para o seu uso em certas circunstâncias — veja a seção Jobs com falha e cancelados para detalhes.

Para usuários do Plano Pay-As-You-Go, veja Gerenciar custo para detalhes sobre como definir um limite de custo.

Uso para jobs com falha e cancelados

Quando um job falha ou é cancelado, o uso reportado é o seguinte:

• Job ou batch mode: Se a falha ou cancelamento ocorreu devido a um erro do sistema, o uso reportado é zero. Para jobs que falharam devido a erro do usuário ou quando um usuário cancelou um job, o uso reportado é o consumo que ocorreu até aquele ponto, incluindo a sobrecarga incorrida para preparar o QPU para executar o job.

• Session mode: O uso reportado é o tempo de relógio de parede em que a sessão está ativa, independentemente do número de jobs que falham ou são cancelados.

Consultar o uso real de um workload

Após a conclusão de um workload, há várias formas de visualizar seu uso real:

• No qiskit-ibm-runtime v0.30 ou posterior, execute job.usage() para um único job, ou batch.usage() ou session.usage() ao usar batch ou session mode. Se estiver usando uma versão mais antiga do qiskit-ibm-runtime (>= 0.23 e < 0.30), o uso ainda pode ser encontrado em session.details()["usage_time"] e batch.details()["usage_time"].

• Use GET /sessions/{id} para ver o uso de um batch ou sessão específico (o endpoint é o mesmo para ambos os modos de execução).

• Use GET /jobs/{id} para ver o uso de um único job.

Visualizar o uso da instância

Você pode visualizar o uso de uma instância na página Instâncias ou, para quem tiver a autoridade adequada, na página Analytics. Observe que as páginas podem mostrar números de uso diferentes porque calculam o uso de formas diferentes.

A página Instâncias exibe o uso em tempo real dos últimos 28 dias (contínuo), até o momento atual do dia corrente. O uso da página Analytics é recalculado a cada hora e inclui os últimos 28 dias completos; ou seja, exibe o uso de 00:00 de 28 dias atrás até hoje, no topo da hora.

Estimar o uso antes de enviar um job

Embora obter uma estimativa local precisa seja complicado pelas operações extras realizadas para supressão e mitigação de erros, você pode usar esta fórmula de referência para obter uma aproximação do uso estimado:

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

• <per sub-job overhead> é uma sobrecarga de aproximadamente 2s por sub-job. Isso inclui operações como carregar o payload na eletrônica de controle. Seu job primitive pode ser dividido em múltiplos sub-jobs se for grande demais para o motor de execução processar de uma vez.

• rep_delay é uma opção personalizável pelo usuário, e o padrão é dado por backend.default_rep_delay, que é 250 microssegundos na maioria dos backends IBM Quantum. Observe que diminuir o rep_delay reduz o tempo total de execução no QPU, mas ao custo de uma taxa de erro de preparação de estado aumentada; veja o guia Execução com taxa de repetição dinâmica para mais informações.

• <circuit length> é o comprimento total das instruções. Cada instrução leva um tempo diferente no QPU, portanto o comprimento total varia de circuit para circuit. Uma medição, por exemplo, pode levar 56 vezes mais tempo que uma gate x. backend.target[<instruction>][<qubit>].duration pode ser usado para encontrar a duração exata de cada instrução. Um comprimento de circuit típico fica entre 50-100 microssegundos. Se você estiver usando técnicas de supressão ou mitigação de erros com as primitives, instruções extras podem ser inseridas no seu circuit, o que aumentaria o comprimento total do circuit.

  nota

  A opção experimental scheduler_timing retorna o tempo total do circuit, mas este NÃO é o tempo usado para cobrança.

• <num executions> é o número total de circuits multiplicado pelo número de shots, onde os circuits são aqueles gerados após o broadcasting dos elementos PUB.

  • Se você estiver usando técnicas de mitigação de erros com as primitives, circuits extras podem ser executados como parte do processo de mitigação, o que aumentaria o número total de execuções. Além disso, técnicas avançadas de mitigação de erros, como PEA e PEC, têm uma sobrecarga muito maior porque exigem a execução de circuits para aprendizado de ruído.
  • O Estimator agrupa observáveis com comutação qubit a qubit, o que reduz o número de execuções.

Se você não estiver usando nenhuma técnica avançada de mitigação de erros ou rep_delay personalizado, pode usar 2+0.00035*<num executions> como uma fórmula rápida.

Estimar o uso localmente com o Qiskit

Este exemplo de código demonstra como usar o Qiskit para calcular o tempo do circuit:

# 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 passos

Recomendações

• Revise estas dicas: Minimizar o tempo de execução do job.
• Defina o Tempo máximo de execução.
• Aprenda como transpilar localmente na seção Transpile.
• Experimente o guia Comparar configurações do Transpiler.