Uso do workload
Uso representa o consumo do serviço Qiskit Runtime 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:
-
Modo job ou batch: 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.
-
Modo sessão: 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:
- Execute
batch.usage()ousession.usage()noqiskit-ibm-runtime0.30 ou posterior. Se estiver usando uma versão mais antiga doqiskit-ibm-runtime(>= 0.23 e < 0.30), o uso ainda pode ser encontrado emsession.details()["usage_time"]ebatch.details()["usage_time"]. - Use
GET /sessions/{id}para ver o uso de um batch ou sessão específico. - 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 porbackend.default_rep_delay, que é 250 microssegundos na maioria dos backends IBM Quantum. Observe que diminuir orep_delayreduz 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 gatex.backend.target[<instruction>][<qubit>].durationpode 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.notaA opção experimental
scheduler_timingretorna 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 os elementos PUB serem transmitidos.- 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
- 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.