Quantum-HPC Software Stacks and the openQSE Reference Architecture: A Survey

Este artigo analisa nove pilhas de software de computação quântica de alto desempenho (QHPC) para identificar padrões comuns e lacunas, propondo a arquitetura de referência openQSE como uma solução unificada que permite interoperabilidade entre diferentes implementações e suporte tanto a cargas de trabalho atuais (NISQ) quanto futuras (FTQC) sem alterar as interfaces de aplicação.

O essencial

Imagine que você está tentando construir um carro de Fórmula 1, mas o motor é feito de peças mágicas que só funcionam se você falar a língua deles, e o resto do carro (o chassi, as rodas, o volante) é feito por fabricantes diferentes que usam manuais completamente distintos.

Isso é o que está acontecendo hoje com a Computação Quântica quando tentamos conectá-la aos supercomputadores mais poderosos do mundo (os chamados HPCs).

Este artigo é como um grupo de engenheiros, cientistas e fabricantes se reunindo para dizer: "Pessoal, estamos todos reinventando a roda. Vamos criar um manual de instruções comum para que todos os carros funcionem juntos, independentemente de quem fez o motor."

Aqui está a explicação simplificada, usando analogias do dia a dia:

1. O Problema: A Torre de Babel Tecnológica

Hoje, existem supercomputadores (que são como bibliotecas gigantescas de dados) e computadores quânticos (que são como oráculos mágicos que resolvem problemas complexos). O problema é que eles não falam a mesma língua.

• A Situação Atual: Cada empresa (como Amazon, IBM, IonQ) criou seu próprio "sistema de conexão". Se você quer usar o computador quântico da Amazon, precisa aprender a linguagem da Amazon. Se quiser usar o da IBM, precisa aprender a da IBM.
• O Resultado: É como se cada loja de eletrônicos tivesse tomadas de parede de formatos diferentes. Você não consegue conectar seu carregador em qualquer lugar sem um adaptador específico. Isso torna tudo caro, lento e difícil de usar para os cientistas.

2. A Solução Proposta: O "openQSE"

Os autores do artigo propuseram um novo projeto chamado openQSE. Pense nele como a criação de um padrão universal de tomadas e cabos para o mundo quântico.

Eles não querem substituir os computadores quânticos existentes nem proibir que as empresas criem seus próprios motores. Eles querem criar uma camada intermediária (um "tradutor" ou "adaptador universal") que permita que qualquer aplicativo fale com qualquer computador quântico, não importa onde ele esteja ou quem o fabricou.

3. Como Funciona a "Arquitetura" (O Mapa do Tesouro)

O artigo desenha um mapa de como esse sistema deve funcionar, dividido em camadas, como um prédio:

• O Andar de Baixo (O Hardware): É o computador quântico real. Ele é frágil, faz barulho (literalmente, precisa de resfriamento extremo) e é difícil de controlar.
• O Tradutor (A Camada de Runtime): É aqui que o openQSE atua. Ele pega o pedido do cientista (ex: "calcule a estrutura de uma nova molécula") e o traduz para a linguagem que aquele computador específico entende.
• O Gerente de Tráfego (Sistema de Agendamento): Imagine um controlador de tráfego aéreo. Como os computadores quânticos são caros e poucos, muitas pessoas querem usá-los ao mesmo tempo. Esse "gerente" decide quem usa o computador, por quanto tempo e em que ordem, garantindo que ninguém fique esperando eternamente.
• O Andar de Cima (O Aplicativo): É onde o cientista trabalha. Com o openQSE, ele não precisa se preocupar com o modelo do computador quântico. Ele apenas envia o trabalho e o sistema cuida do resto.

4. Os Dois Tipos de "Trabalho"

O artigo explica que existem duas formas de usar essa tecnologia, e o novo sistema suporta ambas:

1. O Estilo "Encomenda" (Workflow-Centric): É como pedir um pizza. Você envia o pedido, espera a pizza ser feita e depois vem buscá-la. O computador clássico faz uma parte, envia o pedido ao quântico, espera o resultado e continua o trabalho. É bom para tarefas que não precisam de resposta imediata.
2. O Estilo "Acelerador" (Accelerator-Centric): É como ter um cozinheiro ajudando você na cozinha. O computador clássico e o quântico trabalham juntos, lado a lado, trocando informações em tempo real. É como usar uma placa de vídeo (GPU) para acelerar um jogo; o quântico acelera partes específicas do problema.

5. O Futuro: De "Ruídosos" a "Perfeitos"

Hoje, os computadores quânticos são "ruidosos" (NISQ). Eles cometem erros facilmente, como uma criança tentando escrever um livro. O sistema precisa lidar com esses erros.
No futuro, teremos computadores "tolerantes a falhas" (FTQC), que são como máquinas de escrever perfeitas. O grande trunfo do openQSE é que ele foi desenhado para funcionar hoje com as máquinas imperfeitas e amanhã com as máquinas perfeitas, sem que os cientistas precisem reescrever seus programas.

Resumo Final

Este artigo é um chamado para a unificação. Os autores analisaram 9 sistemas diferentes e disseram: "Olhem, todos nós temos as mesmas peças, mas estamos montando o quebra-cabeça de formas diferentes. Vamos criar uma caixa de montagem padrão (o openQSE) para que, no futuro, qualquer cientista possa usar qualquer computador quântico com a mesma facilidade com que hoje usamos um celular para acessar a internet."

É o passo necessário para transformar a computação quântica de uma "ciência de laboratório" em uma ferramenta prática para resolver problemas do mundo real, como criar novos medicamentos ou materiais mais fortes.

Resumo técnico

Resumo Técnico: Stacks de Software Quantum-HPC e a Arquitetura de Referência openQSE

1. Problema

A integração de recursos quânticos em ambientes de Computação de Alto Desempenho (HPC) e na nuvem está em crescimento, mas as atuais pilhas de software de Computação Quântica de Alto Desempenho (QHPC) permanecem isoladas e fragmentadas. O principal problema identificado é a falta de interfaces comuns entre as camadas de runtime, gerenciamento de recursos, orquestração e execução.

• Fragilidade e Custo: As soluções são frequentemente proprietárias e "full-stack", exigindo que centros de HPC e cientistas recriem lógicas de integração semelhantes para cada provedor. Isso aumenta os custos de manutenção, retarda comparações entre tecnologias e reduz a portabilidade de aplicações.
• Assimetria de Escala: Existe uma diferença fundamental na forma como os recursos clássicos (HPC) e quânticos (QPU) são escalados e alocados. O HPC escala de forma modular (nós, núcleos, memória), enquanto as QPUs são recursos escassos e acoplados que não podem ser pré-agendados ou checkpointados da mesma forma, devido à natureza da informação quântica (não clonagem).
• Falta de Padronização: Interfaces variam entre ambientes de nuvem e locais (on-premises), e as suposições de runtime diferem, dificultando a criação de fluxos de trabalho híbridos eficientes.

2. Metodologia

Os autores realizaram uma análise abrangente do estado da prática (state-of-the-practice) em software QHPC.

• Análise de Nove Pilhas (Stacks): O estudo examinou nove pilhas de software de produção representativas desenvolvidas por grandes provedores e instituições de pesquisa: AWS, IBM, IonQ, JHPC-Quantum, MQSS (Munich Quantum Software Stack), Pasqal, Quantinuum, Quantum Brilliance e Xanadu.
• Eixos de Classificação: Para comparar essas pilhas heterogêneas, os autores definiram quatro eixos de classificação:
  1. Ambiente de Implantação: Nuvem, local (on-premises) ou operação federada.
  2. Modalidade de Hardware: Tipos de qubits (íons presos, supercondutores, átomos neutros, etc.).
  3. Padrões de Interação da Aplicação: Focado em Workflow (etapas clássicas e quânticas separadas) ou Focado em Acelerador (chamadas de kernel quântico acopladas a tempo de execução, similar a GPUs).
  4. Era de Computação Quântica: Suporte para sistemas de escala intermediária ruidosa (NISQ) e/ou computação quântica tolerante a falhas (FTQC).
• Mapeamento de Interfaces: Os autores mapearam o fluxo de trabalho de submissão de tarefas híbridas em todas as pilhas e analisaram interfaces emergentes como QDMI (Quantum Device Management Interface) e QRMI (Quantum Resource Management Interface).

3. Principais Contribuições

O artigo apresenta três contribuições fundamentais:

1. Análise de Pilhas Quantum-HPC: Um mapeamento detalhado de nove frameworks, identificando padrões arquitetônicos comuns e divergências, sintetizados em uma matriz de convergência de interfaces.
2. Framework de Requisitos: Uma estrutura que abrange ambientes de implantação, modalidades de hardware, padrões de aplicação e eras de computação quântica, fornecendo um espaço de design estruturado para sistemas futuros.
3. Arquitetura de Referência openQSE: A proposta da open Quantum-HPC Software Ecosystem (openQSE), uma arquitetura de referência neutra em relação ao fornecedor, projetada para unificar o ecossistema.

4. Resultados e Arquitetura openQSE

A análise revelou que, embora as implementações variem, há uma forte convergência para uma separação em camadas entre aplicações, serviços de runtime, compilação e controle de hardware.

A Arquitetura openQSE Proposta:
A openQSE define uma arquitetura em camadas lógica que permite interoperabilidade sem sacrificar a flexibilidade de implantação. Ela é composta por cinco partes lógicas principais:

1. Nó de Controle HPC: Fornece o plano de controle lógico para submissão de tarefas e abstração de recursos.
2. Camada de Abstração de Submissão de Tarefas: Desacopla a especificação da tarefa do gerenciador de recursos específico (ex: Slurm, Flux), permitindo portabilidade.
3. Nós de Acesso Quântico: Pontos de entrada operacionais que podem hospedar scripts híbridos ou lógica de preparação, atuando como uma camada de cluster com acesso direto às QPUs.
4. Recursos Quânticos: Inclui a QPU, eletrônica de controle, agendador de programas quânticos e uma camada de controle lógico (LCL).
5. Infraestrutura Compartilhada: Rede de alta largura de banda e persistência de dados.

Componentes Chave da Arquitetura:

• Interface de Runtime Quântico (QRI): Uma fronteira de runtime voltada para a aplicação (similar ao HIP para GPUs) que separa a lógica da aplicação dos detalhes específicos do fornecedor, permitindo que o mesmo código funcione em diferentes backends.
• API de Interconexão QHPC: Uma interface bidirecional que permite não apenas a submissão de tarefas, mas também sinalização a montante (upstream), callbacks e solicitações de adaptação dinâmica entre os componentes clássicos e quânticos.
• Pipeline de Ferramentas/Compiladores: Um modelo governado para transformações e passes de compilação, permitindo reutilização de ferramentas e validação de políticas.
• Suporte a FTQC: A arquitetura separa explicitamente a Camada de Controle Lógico (operando no domínio de tempo real) do Motor de Execução Tolerante a Falhas (operando no domínio determinístico), preparando o sistema para a necessidade de correção de erros em tempo real no futuro.

5. Significado e Impacto

• Unificação do Ecossistema: A openQSE oferece um "plano de fundo" comum para que desenvolvedores, fornecedores e centros de HPC colaborem, reduzindo a fragmentação atual.
• Preparação para o Futuro: Ao definir limites de interface estáveis, a arquitetura garante que as aplicações de nível superior não precisem ser reescritas à medida que a tecnologia evolui de NISQ para FTQC.
• Interoperabilidade: A proposta permite que diferentes implementações (ex: um compilador de um fornecedor, um agendador de outro e uma QPU de um terceiro) operem juntas, desde que respeitem as interfaces definidas.
• Base para Padrões Comunitários: O trabalho serve como entrada para iniciativas comunitárias que visam estabelecer padrões abertos, movendo o campo de soluções proprietárias isoladas para um ecossistema integrado e interoperável.

Em resumo, o artigo argumenta que a integração quântica-HPC é um problema de sistemas de ponta a ponta, não apenas de acesso a dispositivos, e que a adoção de uma arquitetura de referência comum (openQSE) é o passo crítico necessário para escalar a computação quântica prática em ambientes de supercomputação.