O que modelos isolados realmente exigem?

Modelos isolados exigem muito mais do que um servidor com GPU e o cabo de rede desconectado. Uma definição útil descreve um sistema em que dados de inferência, artefatos do modelo, administração, registros e atualizações só atravessam o limite de segurança por um procedimento explícito e inspecionado. Se um engenheiro consegue restaurar a internet para instalar um pacote, ou se um controlador de gerenciamento ainda chama a nuvem de um fornecedor, o projeto tem uma brecha no sentido comum. Ele não tem um isolamento físico no sentido de segurança.

Essa distinção muda a compra. A organização assume capacidade de hardware, custódia do modelo, dependências de software, identidade, observação, recuperação e toda atualização futura. Também aceita que certos recursos hospedados não podem ser levados para dentro por preço algum, porque o fornecedor não distribui os pesos. A escolha pode ser correta para código-fonte, registros de produção, material sob controle de exportação ou cargas reguladas, desde que o modelo operacional seja definido antes da chegada dos servidores.

Um isolamento físico é um limite governado de fluxo

Uma máquina só está isolada quando todo caminho que cruza seu limite está ausente ou é controlado como um evento de transferência. As equipes costumam examinar a rede da aplicação e esquecer o controlador de gerenciamento da placa, o plano do hipervisor, a replicação de armazenamento, o DNS, a sincronização de horário, os exportadores de telemetria, as verificações de licença, os relatórios de falha e o notebook usado por um administrador nos dois lados. Cada item pode transformar um ambiente supostamente fechado em um ambiente parcialmente conectado.

Comece com quatro fluxos: dados de entrada, dados de saída, fornecimento de software e administração. Desenhe cada origem e destino. Marque o protocolo, a identidade usada, quem aprova a passagem e a evidência mantida. Um diagrama escrito «cluster offline» quase nada diz a um auditor. Um inventário escrito «o pacote assinado entra pela estação T1 após aprovação de duas pessoas» descreve um controle que a engenharia pode construir e testar.

Há vários níveis defensáveis de isolamento. Chamar todos de isolamento físico leva a decisões ruins. Uma sub-rede privada com tráfego de saída bloqueado ainda depende de roteadores conectados, planos de controle na nuvem e serviços de identidade. Um ambiente desconectado pode aceitar importações agendadas por um gateway vigiado. Um isolamento físico não tem caminho de rede ativo e move artefatos aprovados por mídia controlada ou um mecanismo unidirecional próprio. Escolha o nível pelo modelo de ameaças e use o nome correto em contratos e análises de arquitetura.

O NIST SP 800-53 separa proteção e transporte de mídia, proteção de limites, gestão de configuração e auditoria. Essa separação ajuda. Remover uma rota não responde quem pode transportar uma atualização, como a mídia é examinada, se o lado receptor a verifica nem como os administradores provam a mudança. Um ambiente isolado precisa de todos esses controles em conjunto.

Teste a afirmação em vez de confiar no diagrama. Faça o inventário de interfaces e rádios, acompanhe portas de switches, inspecione controladores de gerenciamento, tente consultas DNS e conexões de saída em cada espaço de carga e veja para onde vão os registros. Repita depois da manutenção, pois um acesso temporário de diagnóstico costuma virar infraestrutura permanente.

O modelo de ameaças decide o que fica dentro

O limite deve conter os ativos e as operações cuja divulgação ou dependência externa você não aceita. Mesmo assim, muitas implantações executam a inferência internamente enquanto preparam prompts em um serviço conectado, copiam resultados para um sistema hospedado de chamados ou enviam rastros com código-fonte para uma plataforma de observação. A GPU trabalhou localmente, mas a carga completa não.

Separe três planos. O plano de dados transporta prompts, documentos recuperados, respostas, vetores e resultados de ferramentas. O plano de controle gerencia identidade, agendamento, políticas, segredos, registros e administração. O plano de fornecimento traz pesos, contêineres, pacotes do sistema, drivers, firmware e avisos de vulnerabilidade. Fechar apenas o plano de dados deixa duas vias amplas para ataque ou vazamento.

Escreva um modelo de ameaças com adversários e falhas definidos. Uma equipe de registros regulados pode temer principalmente divulgação acidental e exigir custódia comprovável. Um programa de defesa pode ainda supor um invasor capaz na cadeia de fornecimento. Uma fábrica pode priorizar a continuidade quando links externos caem. Essas necessidades geram regras de transferência, redundância e profundidade de análise diferentes. «A segurança exige» é vago demais para escolher hardware ou aprovar uma exceção.

Decida quais saídas podem deixar o ambiente. Uma árvore de código transformada pode conter comentários, credenciais, nomes de clientes e lógica presentes na entrada. Uma resposta do modelo não fica limpa só porque acabou de ser gerada. Se resultados cruzarem o limite, trate a passagem como exportação, com revisão de conteúdo, aprovador, destino e registro. A regra vale para pacotes de suporte: rastros e capturas de prompts muitas vezes contêm o material que o isolamento deveria proteger.

A pergunta incômoda é se as pessoas derrotam o projeto. Se operadores fotografam erros com telefones pessoais, copiam comandos de um chat conectado ou levam qualquer dispositivo USB entre zonas, o limite de rede apenas muda o caminho do vazamento. Forneça documentação interna, procedimentos pesquisáveis, mídias aprovadas e suporte que funcione sob pressão. Controles que impedem a recuperação serão contornados na primeira falha séria.

O hardware é dimensionado pela carga, não pela ficha do modelo

Dimensione o cluster isolado com solicitações, concorrência, tamanho de contexto, latência e disponibilidade medidos. Depois escolha modelo e precisão adequados. Ter memória de GPU para carregar os pesos só prova que um processo pode iniciar. Produção também precisa de memória para cache de chave e valor, ativações, áreas de trabalho, contextos simultâneos e a camada de serviço.

Uma primeira estimativa dos pesos é simples:

weight_bytes ~= parameter_count * bits_per_weight / 8
required_vram = weights + kv_cache + activations + runtime_workspace + safety_margin

A primeira linha é um limite inferior, não um orçamento. Formatos quantizados carregam escalas e metadados. Algumas arquiteturas ativam apenas parte dos parâmetros por token, mas ainda podem manter todos os especialistas residentes. A documentação do TensorRT da NVIDIA diz que um mecanismo serializado aproxima a memória dos pesos, enquanto contextos adicionam memória persistente e de execução. Também recomenda medir a memória livre e definir limites de área de trabalho. Isso é melhor do que multiplicar parâmetros e comprar a próxima GPU.

Meça a versão real do servidor no hardware exato. Use comprimentos representativos de entrada e saída, incluindo solicitações longas que dominam o cache. Meça tempo até o primeiro token, tokens por segundo, espera, pico de memória do dispositivo, RAM, leituras de armazenamento na partida e recuperação após a falha de um processo. Envie solicitações simultâneas suficientes para expor o agendador. Um único prompt interativo esconde o problema de capacidade.

RAM e armazenamento também importam. Pode ser necessário guardar pesos atuais e anteriores, uma cópia descompactada, camadas de contêiner, caches, dados de avaliação e registros de auditoria. Se a reversão exige apagar o único modelo conhecido como bom, faltou armazenamento. Armazenamento local rápido reduz reinicializações; um armazenamento compartilhado lento pode trazer todos os nós de volta juntos e prendê-los no mesmo gargalo.

A execução em várias GPUs resolve um problema de tamanho ou latência, mas acrescenta comunicação e outro domínio de falha. A NVIDIA documenta que dividir a execução reduz a pressão de memória por dispositivo ao custo de comunicação entre GPUs. Valide topologia, caminho direto e bibliotecas coletivas com as versões de driver e firmware planejadas. Duas GPUs numa lista de materiais não garantem paralelismo útil.

A disponibilidade multiplica a necessidade. Se manutenção ou falha de hardware não pode interromper a inferência, reserve capacidade para suportar a maior falha permitida e ainda cumprir a latência. Isso pode pedir um nó sobressalente, margem de GPU distribuída, registros internos redundantes e peças no local. Um fornecedor hospedado esconde parte dessa reserva no preço do serviço. Dentro do perímetro, ela é sua.

Testes de capacidade devem cobrir energia e temperatura, não apenas vazão do software. Um nó denso pode passar num teste curto e reduzir a velocidade sob carga contínua porque o rack não remove o calor ou uma alimentação não sustenta todos os dispositivos. Registre frequências, temperatura, erros de hardware corrigidos e consumo durante um teste prolongado. Pergunte o que ocorre se uma alimentação ou a refrigeração falhar e repita o cálculo nesse estado.

Qualifique uma base completa de hardware e software: firmware do servidor, do controlador e da GPU, driver, ambiente de execução, kernel, imagem de contêiner e mecanismo de inferência. Um mecanismo otimizado pode ter sido compilado para uma geração de GPU ou combinação de software. Importá-lo pronto sem reproduzir o destino pode causar falha de partida dentro da zona. Mantenha o processo de compilação interno ou só promova depois de executar na classe de hardware de produção.

Não suponha que inferência por CPU ofereça um modo emergencial útil. Ela pode manter um modelo pequeno, mas latência e largura de banda podem fazer a carga principal perder todo objetivo. Meça e classifique corretamente: serviço degradado, recuperação só em lote ou nenhum modo alternativo. Seja igualmente franco com um conjunto misto de aceleradores. Dispositivos diferentes podem exigir mecanismos diferentes e complicar o agendamento e a reserva além do que o desconto sugere.

Reserve ainda uma faixa de qualificação. Se todas as GPUs atendem produção, cada mudança de driver, ambiente ou peso deve ser testada em hardware diferente ou no conjunto ativo. Um nó pequeno e representativo pode validar importações, reconstruir mecanismos, executar avaliações e revelar incompatibilidades antes da promoção. Ele custa capacidade, mas descobrir após uma correção urgente que a única imagem interna de compilação não tem uma dependência também custa.

Pesos precisam de custódia, licença e identidade reproduzível

Pesos do modelo são entradas executáveis com condições legais, consequências de segurança e identidade exata. Tratá-los como um arquivo grande copiado de uma estação perde as informações necessárias para reproduzir ou investigar uma implantação. O registro da versão deve ligar pesos, configuração, tokenizador, ambiente de inferência, adaptadores, imagens, licenças e resultado da avaliação.

Use resumos imutáveis, não nomes variáveis como latest ou um rótulo simples. A Open Container Initiative Image Specification exige resumo de conteúdo e tamanho nos descritores e recomenda verificar os bytes recebidos antes do uso. O princípio também vale quando os pesos viajam como arquivos comuns. Um manifesto assinado deve listar cada artefato com SHA-256, tamanho, origem, licença revisada e registro de aprovação.

Um pacote mínimo pode ser conferido com ferramentas presentes em quase todo ambiente controlado:

$ sha256sum -c SHA256SUMS
weights/model-00001-of-00004.safetensors: OK
weights/model-00002-of-00004.safetensors: OK
weights/model-00003-of-00004.safetensors: OK
weights/model-00004-of-00004.safetensors: OK
config/tokenizer.json: OK
images/inference-server.oci.tar: OK

$ sha256sum SHA256SUMS
4b7f...a921  SHA256SUMS

O resumo abreviado mostra o formato da saída, não um valor a copiar. Em produção, registre a soma inteira, verifique a assinatura com uma chave pública já confiável dentro e recalcule cada arquivo após a transferência. Uma soma protege a integridade somente se a esperada chegar por um caminho confiável e autenticado. Colocar um arquivo malicioso e a soma correspondente na mesma unidade não verificada não prova nada.

Guarde o pacote original após a promoção. Se uma saída mudar, será preciso distinguir revisão dos pesos, troca do tokenizador, reconstrução do ambiente, driver, configuração de amostragem ou código da aplicação. Versione a unidade de inferência completa e torne a reversão uma operação normal. Nunca reconstrua uma versão antiga com dependências variáveis durante um incidente.

Licenças podem bloquear uma implantação mesmo quando os arquivos podem ser baixados. Verifique direitos de executar, modificar, redistribuir internamente, criar derivados e usar saídas para a finalidade prevista. Registre as condições de uso que afetam a carga. Um modelo chamado informalmente de código aberto pode usar uma licença fora da definição adotada pela organização, portanto a aprovação de segurança não substitui a análise jurídica.

A rota de atualização faz parte de produção

Um ambiente isolado precisa de uma via planejada de importação porque modelos dependem de uma pilha mutável. Drivers, firmware, ambientes, imagens base, pacotes Python ou do sistema, pesos, tokenizadores, avisos de vulnerabilidade e dados de revogação envelhecem. Congelar tudo poupa trabalho agora, mas acumula defeitos e torna o futuro salto mais difícil de testar.

Use duas zonas de preparação. Uma zona conectada adquire artefatos fixados e registra sua origem. Uma estação de transferência analisa, verifica, inventaria e empacota a versão sem manter segredos de produção. A zona receptora verifica novamente o manifesto, importa para repositórios internos, executa testes de aceitação e promove por resumo imutável. Produção nunca deve puxar direto do dispositivo de transferência.

A documentação da Red Hat para ambientes OpenShift desconectados trata espelhamento e atualizações offline como operações contínuas, não truques de instalação. Esse é o modelo certo fora do OpenShift também. Espelhe os repositórios consumidos, mantenha os metadados e pratique atualizações e reversões sem infraestrutura pública. Se um gerenciador de pacotes tentar acessar um índice externo durante a reconstrução, o pacote está incompleto.

Defina ritmos diferentes para mudanças normais e emergenciais. Versões rotineiras podem agrupar modelo, ambiente e sistema depois da avaliação. Uma vulnerabilidade explorada em um driver ou biblioteca pode exigir um pacote emergencial estreito. Determine quem declara essa rota, quais testes podem ser reduzidos, como o risco é aceito e quando a bateria completa será executada. Caso contrário, cada correção urgente vira um debate improvisado.

Para reescritas reguladas de sistemas legados, a CodeHero fornece os modelos e pode executá-los isolados dentro do perímetro do cliente, em hardware do cliente ou alugado pela CodeHero ao cliente. Cliente e equipe ainda precisam combinar autoridade de transferência, acesso físico, registros, revisão de exportação e destino final dos pesos e do hardware.

Planeje a remoção com o mesmo cuidado da importação. Pesos vencidos, discos com defeito, mídia de transferência, arquivos de registro e hardware alugado podem conter dados protegidos ou ativos do modelo. Defina evidências de limpeza e destruição antes da retirada. Um perímetro fechado sem uma saída documentada apenas adia o problema de custódia.

Operações offline precisam de dependências próprias

O cluster deve continuar funcionando quando toda conveniência pública estiver ausente. Isso inclui identidade, hora, resolução de nomes, certificados, repositórios, monitoramento, alertas, documentação, cópias e suporte. Um servidor de modelo que funciona enquanto os usuários não conseguem autenticar não é um serviço disponível.

Identidade costuma ser a primeira dependência oculta. Se a organização usa um provedor de identidade na nuvem, decida se a zona recebe um diretório independente, uma parte replicada por mecanismo controlado ou contas locais. Planeje criação, desativação e revisão. Duração de cache não é arquitetura de identidade, sobretudo quando um administrador desligado mantém acesso até vencer um token offline.

Hora e certificados falham de forma mais silenciosa. Opere uma fonte interna de horário e documente sincronização e controle de desvio. Opere uma autoridade certificadora interna ou importe certificados por um processo iniciado bem antes do vencimento. Teste o que gateway, registro, monitoramento e automação fazem com certificado vencido. Ajustar o relógio numa emergência pode invalidar registros e assinaturas, portanto não deve ser a correção normal.

Os dados de observação ficam dentro, salvo exportação aprovada. Colete identificadores, latência, fila, contagem de tokens, pressão de memória, erros de hardware, versão, decisões de políticas e ações dos operadores. Evite registrar prompts e saídas completos por padrão. Quando capturar conteúdo for necessário para depuração ou testes de paridade, restrinja por função, retenção e caso, pois o armazenamento de registros pode concentrar uma cópia da carga protegida.

Crie uma fonte interna confiável para procedimentos e problemas conhecidos. O suporte do fornecedor pode pedir diagnósticos que não podem sair. Combine antes se a equipe de suporte pode entrar, se um pacote limpo pode sair e quais comandos o cliente executará. Ensaie falha de GPU, pacote corrompido, registro indisponível, certificado vencido e reversão. O isolamento ganha confiança durante a recuperação, não na apresentação.

Cópias de segurança exigem testes independentes de restauração. Guarde configuração, manifestos, metadados de repositórios, políticas e dados persistentes. Não suponha que pesos precisem de cópia no mesmo sistema se pacotes assinados já são fonte recuperável. Restaure em um segmento limpo e prove que nenhum download externo é necessário.

Modelos fechados impõem um teto de capacidade

Não é possível hospedar um modelo cujo fornecedor não publique os pesos sob licença utilizável. Essa é a renúncia mais clara diante da inferência hospedada, e compras não pode negociar arquivos inexistentes. Um modelo distribuível menor pode bastar para classificação, extração, transformação de código ou busca documental, mas não equivale sempre ao melhor hospedado em raciocínio amplo ou idiomas incomuns.

Serviços hospedados também concentram trabalho que a instalação fechada precisa reproduzir: kernels otimizados, agrupamento de solicitações, ajuste de capacidade, roteamento, controles de abuso, execução de ferramentas, preparação multimodal, saída estruturada e atualizações frequentes. Algumas funções podem ser refeitas dentro. Outras dependem de modelos proprietários ou sistemas do fornecedor e somem. Liste cada capacidade necessária e teste, em vez de aceitar que o modelo local é «igual».

O tamanho de contexto anunciado não prova bom desempenho nesse tamanho. Contextos longos consomem cache, reduzem concorrência e podem piorar o resultado mesmo quando a solicitação cabe. Teste documentos reais e a forma do repositório. Para um milhão de linhas, a pergunta prática não é se tudo cabe num prompt. O sistema precisa analisar a árvore inteira, preservar relações e verificar mudanças contra o comportamento observado.

Atualizações chegam mais devagar por escolha. Um endpoint hospedado pode mudar por trás de uma API estável, para melhor ou pior. Dentro, cada peso ou ambiente passa por aquisição, revisão, transferência, avaliação e promoção. O atraso compra controle e repetibilidade, mas novos recursos e correções não chegam imediatamente. Decida o atraso aceitável para melhorias e quais falhas acionam a emergência.

Ferramentas externas são outra divisão. Pesquisa na web, repositórios hospedados, chamados SaaS, metadados públicos e recuperação gerenciada não estão disponíveis sem espelho ou gateway aprovado. Um fluxo baseado em chamadas ao vivo perde capacidade quando entra. Substitua cada dependência por dados e APIs internos ou declare que a função não existirá.

A qualidade deve ser avaliada por tarefa. Mantenha internamente um conjunto versionado de entradas representativas, invariantes esperadas, divulgações proibidas, limites de latência e orientações de avaliação humana. Compare candidatos com o modelo atual antes da promoção. Avaliações públicas ajudam na seleção inicial, mas não dizem se uma reescrita preserva o fechamento mensal ou se uma extração lida com os formulários mais difíceis.

Custos hospedados e isolados se comportam de forma diferente

A inferência hospedada transforma grande parte da plataforma em gasto variável, enquanto uma implantação isolada concentra custo em capacidade reservada e operações. Comparar preço por token com compra de GPU omite quase tudo dos dois lados. Modele um serviço que atenda aos mesmos requisitos de disponibilidade, latência, contexto, segurança e suporte.

No lado fechado, inclua nós GPU, CPU, RAM, armazenamento rápido, rede interna, rack, energia, refrigeração, reserva, peças, equipamento de transferência, registros, monitoramento, cópia e tempo da equipe. Some prazo de compra e capacidade ociosa mantida para picos ou falhas. Se desenvolvimento, teste e produção exigem zonas separadas, conte todas. Hardware alugado para o projeto continua sendo capacidade dedicada, não cobrança hospedada por token.

No lado hospedado, inclua uso de entrada e saída, regras de cache, vazão reservada, retenção, conexão privada, gateways, registros, tráfego de avaliação, novas tentativas e trabalho para gerenciar mudanças. Some limpeza ou minimização se dados brutos não podem sair. Um endpoint barato que as áreas jurídica ou de segurança recusam não tem economia útil.

Uma comparação simples expõe os pressupostos:

closed_annual_cost = annualized_hardware + facilities + licenses + operations + transfer_and_assurance
hosted_annual_cost = request_volume * blended_request_cost + connectivity + operations + assurance
cost_per_success = total_cost / accepted_task_outputs

A última linha é a mais importante. Tokens por segundo e custo por token podem premiar um sistema rápido cujo trabalho é rejeitado. Defina um resultado aceito, como uma transformação que passe nos testes de paridade ou uma extração acima do limite de revisão, e meça novas tentativas e correção humana. Use faixas para utilização, crescimento, vida do hardware e pessoal em vez de fingir uma previsão exata.

O isolamento tende a fazer sentido com carga constante, hardware ocupado, modelo distribuível adequado e uma restrição que já exige operação local. Hospedagem tende a vencer com demanda irregular, quando capacidade proprietária muda o resultado, escala global importa ou a organização não quer operar aceleradores. Um desenho híbrido pode mandar para fora trabalho aprovado de baixa sensibilidade, mas exige classificação confiável e deve bloquear na dúvida.

A aprovação deve depender de evidência, não do rótulo

Aprove a implantação quando a equipe conseguir demonstrar o limite, reproduzir a unidade de inferência, operar toda dependência offline, atualizar e reverter por rota testada e provar que o modelo cumpre a tarefa. Rejeite propostas com apenas uma GPU desconectada e a promessa de resolver atualizações depois. Isso é um experimento, não produção.

Peça evidências inspecionáveis: inventário de fluxos, modelo de ameaças, teste do hardware, cálculo de capacidade, manifesto assinado, licença, avaliação, procedimento de recuperação, registro de transferências, processo de vulnerabilidades e plano de retirada. Depois observe uma importação e uma reversão. Controles no papel costumam falhar na passagem entre a equipe conectada e os operadores internos.

Revise falhas antes da compra. O que acontece se uma GPU morrer, um administrador perder acesso, o registro corromper, um certificado vencer, o modelo regredir ou uma vulnerabilidade grave for anunciada? Defina o tempo de recuperação tolerável e as pessoas autorizadas. Se a resposta exige reconectar o cluster, inclua e aprove essa exceção agora ou mude a dependência.

Não exija isolamento como símbolo de status. Se inferência privada hospedada com controles contratuais satisfaz o modelo de ameaças, pode oferecer modelos melhores com menos risco operacional. Se código, registros ou políticas não podem cruzar o limite, aceite o custo de capacidade e pessoal em vez de escondê-lo. A CodeHero conclui cada reescrita de sistema legado em menos de 30 dias, portanto perímetro, hardware e transferências precisam ser decididos cedo.

O teste decisivo é operacional: corte toda via externa, introduza uma atualização assinada, execute a carga representativa, exporte um resultado aprovado, reverta e recupere um nó perdido. Se a equipe completa a sequência usando seus repositórios e deixa uma trilha de auditoria, o isolamento pode sustentar produção.