Escopo: tudo o que a plataforma precisa para ser executada. A capacidade
de GPU para servir modelos e realizar ajuste fino é excluída — essa
capacidade é provisionada separadamente pelo plano de controle de computação
e dimensionada conforme o portfólio de modelos, não conforme a plataforma.
O próprio plano de controle de computação está incluído (sua
configuração é insignificante: uma fração de um núcleo de CPU).
Perfis de dimensionamento em resumo
Funções dos nós
A plataforma é agendada em um pequeno conjunto de funções de nós. Os tamanhos são fornecidos como classes genéricas de vCPU / memória — qualquer família de instâncias em nuvem ou hardware local que atenda à classe funciona.
Os nós de sandbox são deliberadamente superprovisionados em relação ao estado
estável: a plataforma mantém uma reserva de capacidade neles
(aproximadamente 7–28 vCPU dependendo da escala) para que as cargas de
trabalho dos usuários sejam iniciadas instantaneamente, em vez de aguardarem
o provisionamento de nós.
Demanda de computação
Solicitações agendadas em estado estável, provenientes de manifestos de implantação renderizados:- Perfil de réplica única: ~18–23 vCPU / ~50–60 GiB de solicitações para a própria plataforma, mais a reserva de capacidade do sandbox (7–28 vCPU / 28–56 GiB). A margem dos nós acima das solicitações é o que absorve picos.
- Perfil com várias réplicas: os serviços voltados ao público executam 2–5 réplicas (resolução de identidade em maior quantidade, seguida por gateways e workers), elevando as solicitações para ~40 vCPU / ~120 GiB. O escalonamento horizontal automático pode aproximadamente dobrar isso no pico; dimensione a capacidade dos nós para o máximo do escalonador automático, não para seu mínimo.
- Cada nó também executa um pequeno agente de observabilidade (~0.1 vCPU / 200 MiB por nó).
Armazenamento
Todos os volumes em bloco devem ser de classe SSD. Os bancos de dados e o
armazenamento de telemetria são os consumidores sensíveis à latência.
Pré-requisitos da plataforma
- Kubernetes 1.30+ com um driver CSI de armazenamento em bloco e (opcionalmente) um driver de sistema de arquivos compartilhado.
- Balanceamento de carga: balanceadores de carga L4 com endereços estáticos para a borda da API e, se a voz estiver habilitada, para sinalização de mídia e TURN (TLS em uma porta não privilegiada).
- Egress: NAT com um endereço estável para tráfego de saída.
- TLS: um certificado curinga para o domínio da plataforma.
- DNS: capacidade de direcionar nomes de host da plataforma para os balanceadores de carga.
- Registro de contêineres: um registro acessível a partir do cluster. Implantações isoladas da internet pré-espelham todas as imagens em um registro local e usam armazenamento de objetos do provedor no lugar do S3 no cluster.
- Segredos: os segredos da plataforma são criptografados em repouso e descriptografados no momento da implantação pelo operador — o próprio cluster não precisa de acesso ao serviço de gerenciamento de chaves.
- Portas: todos os serviços escutam em portas ≥ 1025; o tráfego entre nós em portas privilegiadas pode permanecer bloqueado.
O que o mínimo sacrifica
A configuração mínima executa todas as capacidades, mas com pontos únicos de falha que o perfil escalado elimina:- A maioria dos serviços executa uma réplica — uma falha de pod ou nó interrompe essa capacidade até que o reagendamento seja concluído.
- Um nó de armazenamento de telemetria — a observabilidade fica indisponível se ele falhar (a própria plataforma continua em execução).
- Um nó de mídia e um nó de sandbox — sessões de voz ou execução de código são pausadas na perda do nó.
- Um único caminho de egress e endereços únicos de balanceador de carga.
- A maioria dos bancos de dados executa uma instância; o perfil escalado adiciona réplicas para os armazenamentos críticos e backups contínuos em armazenamento de objetos.