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

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.