Jobs de dry-run

Um job de dry-run executa sua carga de trabalho no IBM Quantum® Compute Service sem usar nenhum tempo de QPU. Use um job de dry-run para fazer o seguinte antes de se comprometer com uma execução real:

• **Obter o uso que o job teria na QPU real.

• Validar o job. O Quantum Compute verifica os parâmetros do job, da mesma forma que faz com um job real.

• Obter o cronograma de temporização do circuito, se você solicitá-lo, para depurar o job antes de executá-lo de verdade.

Ao contrário dos jobs de dry-run, o teste local (fake backends e Qiskit Aer) é executado na sua própria máquina e, por isso, não pode fornecer números de uso, validação do lado do serviço nem informações de temporização do serviço. Para comparar as duas abordagens, veja Dispositivos mock comparados a fake backends.

nota

• qiskit-ibm-runtime v0.51.0 ou posterior é necessário para jobs de dry-run.
• Os jobs de dry-run estão disponíveis em todas as regiões e somente nos planos Flex, Premium e On-Prem. Eles não estão disponíveis nos planos Open ou Pay-As-You-Go.

Como funciona

Para executar um job de dry-run, passe dry_run=True ao método run() da 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 é um argumento do método run() (o padrão é False), não uma opção de runtime. Ele está disponível para todas as primitivas.

Um job de dry-run tem as seguintes características:

• Ele é executado no IBM Quantum Compute Service na nuvem, não na sua máquina.

• Ele usa os dados de calibração da QPU real, não apenas um instantâneo.

• Seus resultados mantêm o esquema esperado e seguem o formato esperado dos resultados da QPU real, mas contêm dados mock aleatórios. Eles não são resultados de medição reais nem simulados, portanto não os use para verificar a correção física.

• O processamento acontece no servidor, então o job pode não terminar imediatamente.

O tamanho do circuito, os shots e outros limites são os mesmos de qualquer job desse programa.

dry_run=True também funciona quando o backend já é um dispositivo mock.

Leia o uso

O uso de um job de dry-run concluído é o uso que o mesmo job teria na QPU real, exceto em raras situações em que os dados de calibração mudam significativamente depois do job de dry-run e antes do job em uma QPU real.

• job.usage() retorna o uso em segundos.

• job.metrics()["usage"] retorna os mesmos dados junto com o status do uso.

O uso de dry-run não é cobrado, não consome a alocação do seu plano e não conta para nenhum limite.

Não use job.usage_estimation com jobs de dry-run

Não use job.usage_estimation em um job de dry-run. Use job.usage().

job.usage() retorna 0 até que o cálculo do uso seja final, então espere o job terminar antes de lê-lo.

Cronograma de temporização do circuito

Para solicitar o cronograma de temporização do circuito, use a mesma opção de um job real. Para mais detalhes, veja Visualizar a temporização do circuito.

Limitações

• Somente job mode e batch mode. Os jobs de dry-run só podem ser executados em job mode e batch mode.

• Somente os planos Flex, Premium e On-Prem. Os jobs de dry-run não estão disponíveis nos planos Open ou Pay-As-You-Go.

Dispositivos mock

Os dispositivos mock são a implementação por trás dos jobs de dry-run. Os jobs de dry-run ocultam os dispositivos mock por padrão, mas você os encontra nestes casos:

• Instâncias configuradas para acessar apenas dispositivos mock. Exemplo: se você usa service.backend("ibm_phoenix") para enviar um job de dry-run em ibm_phoenix, mas sua instância não tem acesso a ibm_phoenix, você receberá um QiskitBackendNotFoundError. Em vez disso, selecione o dispositivo mock diretamente com service.backend("mock_phoenix").

• Recursos de computação. Os dispositivos mock ficam ocultos por padrão na página Compute resources. A tabela da página tem uma opção de filtro para incluí-los, mas somente os planos Flex, Premium e On-Prem têm acesso a dispositivos mock.

• Tabela de cargas de trabalho. Os jobs de dispositivos mock ficam ocultos por padrão na página Workloads. A tabela tem uma opção de filtro (o ícone de funil) para exibi-los.

• API Python. service.backends() e service.jobs() excluem dispositivos mock, a menos que você os chame com include_mocks=True. IBMBackend.is_mock indica se um backend é um dispositivo mock. service.least_busy() nunca retorna um dispositivo mock.

Dispositivos mock comparados a fake backends

Os nomes são parecidos, mas um dispositivo mock e um fake backend são coisas diferentes. Um fake backend é um objeto local no seu ambiente Python. Um dispositivo mock é um recurso na nuvem no IBM Quantum Compute Service.

	Dispositivo mock (por exemplo mock_phoenix)	Fake backend (por exemplo FakeManilaV2)
O que é	Um dispositivo no IBM Quantum Compute Service	Uma classe Python em qiskit_ibm_runtime.fake_provider
Onde é executado	Na nuvem, no serviço	Localmente, na sua máquina
Como obtê-lo	service.backend("mock_phoenix"), ou automaticamente com run(..., dry_run=True)	from qiskit_ibm_runtime.fake_provider import ...
Conta e instância	Somente planos específicos (Flex, Premium ou On-Prem)	Todas as instâncias e planos
Calibração	Ao vivo, corresponde ao dispositivo real a qualquer momento	Instantâneo fixo que acompanha o pacote instalado
Resultados	Dados aleatórios com o esquema esperado. Não é uma simulação	Simulação com ruído que usa o modelo de ruído do instantâneo
Resultados fisicamente significativos	Não. Nunca os use para verificar a correção	Aproximadamente, dentro dos limites do modelo de ruído
Uso informado	Sim	Nenhum
Cobrado ou contabilizado na alocação ou nos limites do plano	Não	Não
Validação do job	Feita pelo serviço, igual a um job real	Limitada ao que o cliente verifica
Cronograma de temporização	Disponível sob solicitação	Não disponível
Modos de execução	Somente job mode e batch mode. Sessions são bloqueadas	A sintaxe de session é aceita, mas ignorada (o modo local não tem sessions nem batches reais)
Conclusão	Assíncrona, no servidor	Executa localmente e retorna quando termina
Exibido na interface da plataforma e nas listas da API	Oculto por padrão (Compute resources, tabela Workloads, backends(), jobs()). Ative para exibir	Nunca, porque nada é enviado ao serviço

Como escolher

• Para descobrir quanto uso o job consumirá, ou se o serviço o aceitará, use um job de dry-run.

• Para descobrir como a saída pode ser, ou para trabalhar offline, use um fake backend ou o Aer.

• Para fazer as duas coisas, itere nos circuitos e resultados com um fake backend e depois faça um dry-run como verificação final antes da QPU real.

Pontos comuns de confusão

• Um dispositivo mock não é um simulador. A saída dele é aleatória, então amostrar um circuito de Bell em mock_phoenix não retorna uma distribuição de Bell. Se você quer uma saída ruidosa realista, use um fake backend.

• Um fake backend não é o dispositivo ao vivo. A calibração dele é um instantâneo e pode estar desatualizada. Um dispositivo mock acompanha a calibração real, então os circuitos transpilados e a temporização correspondem ao que a QPU vê hoje.

• Nenhum dos dois é executado em hardware real. Nenhum consome tempo de QPU, mas somente um job de dry-run passa pelo serviço.

• usage_estimation não é a estimativa do dry-run. Em um job de dry-run, job.usage() retorna os segundos de uso que seu job seria cobrado em uma QPU real.

Casos de uso

Estudantes e cursos

Um administrador restringe uma instância apenas a dispositivos mock, usando a opção de personalização de QPU ao criar ou editar a instância. Os estudantes então validam seus payloads de ponta a ponta sem consumir tempo real de QPU ou RUs. Como a instância tem acesso apenas a dispositivos mock, os estudantes selecionam o backend pelo nome mock:

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

Planejamento de projeto

Uma equipe prestes a começar um projeto executa dry-runs de jobs representativos para ver as RUs de que o projeto precisa, antes de escolher um plano ou uma alocação:

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

Verificação final antes de executar em uma QPU real

Valide os parâmetros e inspecione o cronograma de temporização com dry_run=True, depois remova o argumento e execute na QPU real. Nada mais no seu código muda:

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 passos

Recomendações

• Teste programas na sua própria máquina com o Modo de teste local.
• Saiba como o uso da carga de trabalho é medido.
• Visualize o cronograma de temporização do circuito.
• Entenda as unidades de recurso e os planos disponíveis.