Como viabilizar um cluster HPC próprio na sua instituição pública (sem travar na legislação ou errar no dimensionamento)

O maior gargalo da pesquisa pública hoje não é falta de conhecimento. É falta de capacidade computacional.

Projetos travam em filas do SINAPAD. Pesquisas perdem prazo de publicação. Modelos de IA deixam de ser treinados por limitação de infraestrutura.

E enquanto isso, a alternativa — montar um cluster próprio — parece complexa demais: legislação, importação, dimensionamento, custo e risco de erro técnico.

O resultado é previsível: dependência de infraestrutura externa e perda de competitividade científica.

Mas esse cenário não é inevitável.

Com a estrutura correta, é possível viabilizar um ambiente HPC próprio dentro da realidade do setor público, com segurança jurídica e previsibilidade técnica.

Este guia mostra exatamente como fazer isso.

Por que depender do SINAPAD limita sua capacidade de pesquisa (e quando isso vira um problema crítico)

O SINAPAD é um ativo estratégico do país: filas compartilhadas, governança federativa e acesso a equipamentos de alto desempenho sem que cada instituição tenha de operar tudo sozinha. Para muitos grupos, é o ponto de partida natural.

O limite aparece quando o tempo de fila deixa de ser um incômodo e passa a ser um risco ao planejamento científico: janelas de editais, parcerias internacionais, teses com prazo fixo ou pipelines que dependem de execução contínua. Quando toda demanda competição pelo mesmo recurso nacional, a instituição não controla prioridade nem SLA.

Nesses cenários, depender apenas do acesso compartilhado pode significar postergar resultados que tinham janela — ou fragmentar o trabalho em pedaços que não refletem o experimento original.

O impacto disso vai além da operação.

Instituições com acesso limitado a HPC:

• publicam menos;
• levam mais tempo para validar hipóteses;
• perdem competitividade em editais e parcerias.

Infraestrutura computacional deixou de ser suporte. Hoje, ela define a capacidade científica da instituição.

O erro mais comum ao tentar especificar HPC: pensar em hardware antes do workload

Cluster não é lista de servidores “potentes”. É um sistema dimensionado para workloads concretos: tipo de simulação, uso de GPU, padrões de I/O, sensibilidade à latência de rede, necessidade de armazenamento temporário versus persistente e políticas de fila.

Quando o edital nasce do hardware — fabricante, modelo ou marca como âncora — o risco é comprar capacidade mal alinhada ao uso real: CPUs ociosas enquanto o gargalo é rede; GPUs caras para workload CPU-bound; ou storage que não acompanha o volume de dados gerado.

O caminho correto é o inverso: caracterizar workload (ou famílias de workloads), estimar requisitos e só então derivar arquitetura, política de escalonamento e métricas de aceite. Isso também fortalece o processo licitatório: objeto e critérios passam a refletir necessidade mensurável, não catálogo.

Como viabilizar um projeto de HPC no setor público: caminhos legais, riscos e quando usar cada modelo

No setor público, o projeto de HPC precisa conviver com Lei nº 14.133/2021, possibilidades de compra internacional (quando aplicável, inclusive Lei nº 8.010/90 para aquisição no exterior), exigências de fundamentação técnica e regras de governança institucional. Cada via tem ritmo, documentação e perfil de risco diferentes.

Licitação aberta é o padrão quando não cabe justificar outro instrumento: robustez e transparência, com ciclo mais longo. Pregão e concorrência são comuns conforme o objeto e o valor. Compras internacionalizadas exigem atenção a normas de importação, especificação neutra e, em muitos casos, coordenação com áreas jurídicas e de compras para evitar retrabalho.

Atas de registro de preços entram como acelerador quando existe demanda compatível e objeto bem especificado — desde que a instituição verifique aderência técnica e jurídica ao caso.

Em alguns casos, quando existe ata vigente com equipamentos compatíveis, a execução pode ser feita via adesão, reduzindo drasticamente o tempo de contratação.

Mas isso só funciona quando o projeto já está tecnicamente bem definido.

Sem isso, o risco não desaparece — apenas muda de etapa.

Sua instituição realmente precisa de um cluster próprio?

Antes de avançar, responda:

• sua demanda é contínua ou pontual?
• você depende de filas externas para rodar pesquisas críticas?
• precisa de controle total do ambiente?
• trabalha com dados sensíveis ou restritos?

Se a resposta for sim para a maioria, a infraestrutura própria deixa de ser opcional. Passa a ser estratégica.

Arquitetura e dimensionamento: por que o cluster é um sistema, não uma soma de equipamentos

Um projeto HPC maduro descreve funções de computação (CPU/GPU), topologia de rede, camadas de armazenamento, sistema de arquivos paralelo quando necessário, agendamento de jobs e continuidade operacional. O dimensionamento liga cada componente ao perfil de uso — filas longas, jobs embutidos, aplicações memory-bound, pipelines de dados massivos etc.

Em HPC, erro de arquitetura não é detalhe.

Um cluster mal dimensionado pode:

• limitar performance mesmo com hardware caro;
• gerar gargalos de rede ou storage;
• inviabilizar workloads críticos.

Por isso, a arquitetura deve ser pensada como sistema — não como soma de equipamentos.