Perguntas frequentes sobre modos de execução do Qiskit Runtime

O modo de teste local do Qiskit Runtime oferece suporte a diferentes modos de execução?

O modo de teste local suporta a sintaxe dos diferentes modos de execução, mas como não há agendamento envolvido nos testes locais, os modos são ignorados.

Quantos jobs podem ser executados em paralelo para um backend específico?

O número de jobs em execução em paralelo é baseado no grau de paralelismo configurado para o backend, que é cinco para a maioria dos backends atualmente.

Como o uso é reportado para jobs que falharam ou foram cancelados?

Consulte a seção Jobs com falha e cancelados na página de modos de execução.

Sessões

O que acontece com meus jobs se uma sessão for encerrada?

Se você estiver usando a classe Session em qiskit-ibm-runtime:

• Session.close() significa que a sessão não aceita mais novos jobs, mas os jobs existentes são executados até a conclusão.
• Session.cancel() cancela todos os jobs pendentes da sessão.

Se você estiver usando a API REST diretamente:

• PATCH /sessions/{id} com accepting_jobs=False significa que a sessão não aceita mais novos jobs, mas os jobs existentes são executados até a conclusão.
• DELETE /sessions/{id}/close cancela todos os jobs pendentes da sessão.

Se estou usando o modo de sessão e espero que meu experimento leve muitas horas, há alguma forma de solicitar calibrações?

Não. A calibração sob demanda não está disponível.

Existe um tempo limite interativo (TTL interativo) no modo de sessão?

Sim. Isso reduz custos indesejados caso o usuário se esqueça de encerrar a sessão.

Posso alterar o TTL interativo ou o TTL máximo de uma sessão?

Você não pode alterar o valor do TTL interativo. Você pode alterar o valor do TTL máximo de uma sessão (veja Especificar a duração da sessão), mas ele deve ser menor que o máximo definido pelo sistema. Peça ao seu administrador para entrar em contato com o suporte da IBM se precisar de um TTL interativo diferente ou de um TTL máximo do sistema diferente.

Como o uso de sessões impacta os membros da IBM Quantum Network que não são cobrados por uso?

Os membros da IBM Quantum Network obtêm capacidade reservada nos QPUs da IBM Quantum®. O uso é deduzido dessa capacidade, e instâncias com menor capacidade têm maior tempo de fila.

Tenho o mesmo paralelismo no modo de sessão que no modo de lote?

Sim. Se você enviar múltiplos jobs simultaneamente em uma sessão, esses jobs serão executados em paralelo.

As sessões podem ser interrompidas por atualizações ou calibrações do QPU?

Não. As sessões são executadas em modo dedicado, o que significa que o usuário tem acesso total ao backend. As sessões nunca são interrompidas por calibrações ou atualizações de software.

O tempo de compilação é contabilizado como uso no modo de sessão?

Sim. No modo de sessão, o uso é o tempo de relógio de parede que o QPU está comprometido com a sessão. Ele começa quando o primeiro job da sessão inicia e termina quando a sessão fica inativa, é encerrada ou quando o último job é concluído, o que ocorrer por último. Portanto, o uso continua a acumular após o término de uma sessão caso o QPU ainda esteja executando um job. Além disso, o tempo após a conclusão de um job enquanto o QPU aguarda outro job da sessão (o TTL interativo) conta como uso. Por isso, você deve garantir que a sessão seja encerrada assim que terminar de enviar jobs para ela.

Lote

Quantos jobs são executados em paralelo no modo de lote?

O número de jobs em execução em paralelo é baseado no grau de paralelismo configurado para o backend, que é cinco para a maioria dos backends. No entanto, o número de jobs simultâneos em um lote ativo pode ser menor, pois pode haver outros jobs já em execução quando o lote se tornar ativo.

Qual é a diferença entre executar N PUBs no modo de job e executar N jobs com um único PUB no modo de lote?

A principal diferença é o equilíbrio entre tempo e custo:

Modo de lote:

• O tempo total de execução é menor porque o processamento clássico pode ocorrer em paralelo.
• Há uma pequena sobrecarga para a execução de cada job, então você acaba pagando um pouco mais pelos jobs em lote. Essa sobrecarga está relacionada ao tamanho do job. Por exemplo, o uso total de dois jobs, cada um contendo 40 circuitos 100x100, é seis segundos a mais do que um único job contendo 80 circuitos.
• Como o modo de lote não oferece acesso exclusivo a um backend, os jobs dentro de um lote podem ser executados junto com os jobs de outros usuários ou jobs de calibração.
• Se alguns jobs falharem, você ainda obtém os resultados dos jobs concluídos.
• Você pode agir no meio de uma carga de trabalho em lote com base nos resultados dos jobs concluídos. Por exemplo, você pode cancelar o restante dos jobs se os resultados iniciais parecerem incorretos.

Modo de job:

• O tempo total de execução tende a ser maior porque não há paralelismo.
• Você não paga pela sobrecarga adicional por job associada às cargas de trabalho em lote.
• Todos os seus circuitos serão executados juntos.
• Se esse único job falhar, você não obterá resultados parciais.
• Seu job pode atingir o limite se contiver muitos circuitos ou se os circuitos forem muito grandes.

Em geral, se cada um dos seus jobs consome menos de um minuto de tempo de QPU, considere combiná-los em um job maior (isso se aplica a todos os modos de execução).

Quantos jobs posso enviar em um lote?

Embora não haja limites para o número de jobs que você pode enviar em um lote, há um tempo máximo associado a um lote. Ou seja, quando o tempo de relógio de parede de um lote (que começa quando o primeiro job do lote inicia a execução) excede o tempo máximo definido pelo sistema, o lote não aceita mais novos jobs, e os jobs na fila que não estão em execução são cancelados. Além disso, há limites de quanto uso seus jobs podem consumir com base no seu plano. Para determinar o tempo máximo associado a um lote, use o método batch.details() e procure o valor max_time.

Quando meus jobs no modo de lote seriam executados em paralelo com os jobs de outros usuários?

O grau de paralelismo configurado para um backend também é chamado de "faixas de execução". Se houver uma ou mais faixas de execução disponíveis e seus jobs em lote forem os próximos na fila, o agendador inicia jobs suficientes para preencher as faixas. Da mesma forma, se seu lote não tiver jobs suficientes para preencher as faixas, o agendador inicia os jobs de outros usuários.

Exemplo: O backend escolhido tem cinco faixas de execução, e duas delas estão atualmente ocupadas pelos jobs de outros usuários. Seu lote de seis jobs é o próximo na fila.

Como há três faixas disponíveis, o agendador inicia três dos seus seis jobs em lote. Ele continua iniciando jobs do seu lote conforme os jobs são concluídos e as faixas de execução ficam disponíveis. Se uma faixa ficar disponível e não houver mais jobs no seu lote, o agendador inicia o próximo job na fila.

Todos os meus jobs em lote precisam aguardar na fila?

Como os QPUs são recursos limitados e compartilhados, todos os jobs precisam aguardar na fila. No entanto, quando o primeiro job do seu lote começa a ser executado, todos os outros jobs desse lote essencialmente avançam para o início da fila e são priorizados pelo agendador.

Um lote é encerrado automaticamente quando o último job associado termina?

Sim. No entanto, há uma pequena sobrecarga associada a essa detecção automática, por isso você deve sempre encerrar explicitamente seu lote e sua sessão.

Os lotes podem ser interrompidos por calibrações ou atualizações de software

Sim. As cargas de trabalho em lote podem ser interrompidas por calibrações ou atualizações de software.

O tempo de compilação é contabilizado como uso no modo de lote?

Não. No modo de lote, apenas o tempo gasto no hardware quântico conta como uso.