Protocolo de decisão para inferência local: da restrição de VRAM à validação do isolamento de rede

Definição do orçamento de memória: pesos, KV cache e sobrecarga

O primeiro passo do protocolo é determinar a pegada de memória real de um modelo, que não se limita aos parâmetros quantizados. A memória total necessária é a soma de quatro componentes independentes: os pesos do modelo, o cache chave-valor (KV cache), as ativações transitórias e a sobrecarga do framework de inferência.

Um erro comum é aplicar uma margem fixa de 20% sobre os pesos, o que é impreciso porque esses termos escalam de forma diferente. Por exemplo, em um modelo de 7B parâmetros com quantização Q4_K_M, os pesos ocupam aproximadamente 4,9 GB (0,61 bytes por parâmetro, não 0,5 como sugere a fórmula simplificada de 4 bits). A isso deve-se somar o KV cache, que cresce linearmente com o comprimento do contexto. Para um contexto de 8.000 tokens, o KV cache pode adicionar entre 1 e 2 GB adicionais, dependendo da arquitetura de atenção (GQA ou MHA) e da precisão do cache (FP16 ou FP8).

Separar os quatro componentes transforma uma estimativa de capacidade em um orçamento de memória mais útil. Os pesos representam os parâmetros do modelo carregado; o KV cache conserva informações de atenção associadas aos tokens que ainda fazem parte do contexto. As ativações são dados temporários gerados durante o cálculo, e sua quantidade depende de como o runtime executa a inferência. A sobrecarga, por sua vez, abrange memória usada pelo framework e pelo ambiente de computação. Portanto, o tamanho do arquivo do modelo, sozinho, não determina se uma GPU consegue executá-lo.

O KV cache varia com o comprimento do contexto e com a arquitetura de atenção. Assim, configurações que usam os mesmos pesos podem exigir quantidades diferentes de memória ao processar contextos de comprimentos distintos. GQA e MHA organizam de formas diferentes as cabeças de atenção, enquanto FP16 e FP8 alteram o espaço ocupado pelos valores armazenados no cache. O intervalo estimado de 1 a 2 GB para 8.000 tokens depende dessas variáveis e não representa uma exigência fixa para todo modelo de 7B parâmetros.

A tabela apresenta uma estimativa para uma combinação específica: modelo de 7B parâmetros, arquivo Q4_K_M e contexto de 8.000 tokens. Os valores aproximados somam 7,4 GB, mas podem variar conforme o modelo e o runtime. A estimativa de cerca de 1,5 GB para o KV cache depende, entre outros fatores, de n_kv_heads e head_dim; não deve ser transferida sem ajustes para outra arquitetura. Da mesma forma, a sobrecarga indicada é uma estimativa mínima para a configuração descrita, não um valor universal para todas as GPUs.

Uma GPU com 8 GB pode atender a essa estimativa, mas o total calculado não representa, por si só, todas as condições de execução. O orçamento também precisa considerar as ativações transitórias e a sobrecarga efetiva do framework, que podem não estar refletidas em um cálculo simplificado. Um contexto maior pode elevar o consumo do cache, enquanto outra quantização altera o espaço necessário para os pesos. Por isso, cada componente deve ser estimado para a configuração concreta, em vez de se aplicar automaticamente a mesma margem percentual a qualquer modelo.

Seleção da quantização: precisão efetiva vs. bits nominais

A escolha da quantização deve basear-se nos bits efetivos, não no nome do arquivo. Os formatos GGUF misturam precisões: Q4_K_M equivale a cerca de 4,9 bits efetivos (0,61 bytes/parâmetro), enquanto Q8_0 são 8,5 bits (1,06 bytes/parâmetro). Supor 4,0 bits para Q4 subdimensiona os pesos em aproximadamente 20%, o que pode levar a uma seleção de hardware insuficiente.

A degradação de qualidade varia conforme a tarefa. Q4_K_M oferece um equilíbrio aceitável para a maioria dos casos de uso geral, com uma perda de qualidade estimada entre 1% e 3% em relação ao FP16. Q5_K_M é recomendável se houver VRAM adicional e for necessária maior precisão em raciocínio ou código. Q8_0 se aproxima da qualidade original, mas duplica o consumo de memória em relação a Q4, sendo viável apenas em hardware de alto desempenho ou para tarefas de avaliação crítica.

Os bits nominais identificam uma família de quantização, mas não indicam necessariamente o armazenamento médio de cada parâmetro no arquivo inteiro. No GGUF, diferentes tensores podem usar precisões distintas, e o arquivo também inclui valores auxiliares, como escalas por bloco. Os tensores de embedding que permanecem sem quantização também contribuem para o tamanho final. Por isso, Q4_K_M não corresponde exatamente a quatro bits por parâmetro: a estimativa efetiva de cerca de 4,9 bits representa melhor o espaço ocupado pelos pesos.

Essa diferença afeta diretamente o cálculo de capacidade. Usar quatro bits exatos resulta em uma estimativa inferior à obtida com 0,61 byte por parâmetro para Q4_K_M; multiplicado pelo número total de parâmetros, esse erro pode alterar a escolha do hardware. A mesma cautela se aplica a Q8_0, estimado em cerca de 8,5 bits ou 1,06 byte por parâmetro. O nome do formato identifica a quantização, mas os bytes efetivos são a medida pertinente para estimar a memória.

A perda de qualidade não é igual em todas as tarefas nem em todos os modelos. A estimativa de 1% a 3% para Q4_K_M em comparação com FP16 é uma orientação geral, não uma garantia de resultado. Uma avaliação específica pode apontar diferenças distintas conforme a tarefa e o critério de medição. Da mesma forma, recomendar Q5_K_M quando há mais VRAM e se busca maior precisão em raciocínio ou código é uma escolha condicionada, não uma promessa de que a quantização assegure respostas corretas.

Na comparação apresentada, Q8_0 usa aproximadamente o dobro da memória de Q4 e se aproxima da qualidade original. Essas descrições, porém, não garantem resultados idênticos para todos os modelos ou tarefas. A escolha prática combina o espaço disponível com a qualidade que se pretende avaliar. Se o orçamento exigir Q4_K_M, os bytes efetivos ajudam a estimar o espaço dos pesos, mas a variação de qualidade ainda precisa ser avaliada na tarefa correspondente. Mais memória permite considerar outra quantização; não elimina a necessidade de testar o comportamento do modelo.

Configuração do runtime de inferência: Ollama, LM Studio ou vLLM

A seleção do motor de inferência depende da carga de trabalho. Para um único usuário em um computador de mesa, Ollama e LM Studio (baseados em llama.cpp) são comparáveis em desempenho e oferecem uma API compatível com OpenAI em localhost. Ollama destaca-se pela facilidade de uso e gerenciamento de modelos com um único comando, enquanto o LM Studio oferece uma interface gráfica mais completa para experimentação.

Para ambientes de produção com múltiplos usuários simultâneos, o vLLM é superior devido ao seu uso de atenção paginada e processamento por lote contínuo. Em testes de concorrência, o vLLM pode servir até 44 vezes mais tokens por segundo que o llama.cpp sob alta carga. No entanto, para um único usuário, a diferença é mínima, portanto a escolha deve priorizar a facilidade de auditoria e a integração com o fluxo de trabalho existente.

A carga de trabalho determina quais características do runtime são mais importantes. Em um computador de mesa usado por uma pessoa, a facilidade de instalação, a gestão de modelos e as ferramentas de experimentação podem pesar mais do que o processamento simultâneo de muitas solicitações. Para esse cenário, Ollama e LM Studio são descritos como opções baseadas em llama.cpp, com desempenho comparável e uma API compatível com OpenAI acessível em localhost. Isso não significa que todas as versões, modelos ou configurações terão desempenho idêntico.

Ollama prioriza a simplicidade na gestão de modelos pela linha de comando; LM Studio oferece uma interface gráfica mais ampla para experimentação. A tabela também destaca a gestão de vetores associada ao LM Studio e o controle mais limitado sobre parâmetros avançados atribuído ao Ollama. Essas características podem orientar a escolha conforme o fluxo de trabalho, mas não substituem a verificação dos requisitos específicos de hardware e software. A indicação de um caso de uso ideal é uma orientação, não uma restrição de propósito.

O vLLM é voltado a cargas com várias solicitações simultâneas e utiliza atenção paginada e processamento contínuo em lotes. Sob certas condições, essas técnicas permitem aproveitar o processamento conjunto. A cifra de até 44 vezes mais tokens por segundo em comparação com llama.cpp descreve um teste específico de concorrência; não representa uma proporção esperada para qualquer modelo, GPU ou configuração. O resultado depende das condições do benchmark e da carga, portanto não prevê, por si só, o desempenho de outra instalação.

Na comparação descrita, a diferença entre os runtimes é pequena para uma única pessoa, de modo que o desempenho maior sob concorrência não torna automaticamente o vLLM a opção mais adequada para todos. Sua configuração e seus requisitos de GPU também devem entrar na decisão. Para uso pessoal, pode ser preferível priorizar a facilidade de auditoria e a integração ao fluxo de trabalho existente; em produção com solicitações simultâneas, o processamento em lotes pode ser mais relevante. Uma comparação representativa deve manter constantes o modelo, o hardware e as condições de carga.

Auditoria de isolamento de rede: verificando a privacidade

O isolamento de rede é uma estratégia de segurança que envolve dividir a rede em segmentos independentes para prevenir acesso não autorizado ou vazamento de dados. No contexto de inferência local, o objetivo é garantir que o processo de inferência não estabeleça conexões de saída não autorizadas, mantendo os dados dentro da jurisdição controlada pelo operador.

Para verificar empiricamente o isolamento, devem-se utilizar ferramentas de monitoramento de tráfego como Wireshark ou tcpdump para capturar as conexões do processo de inferência. Além disso, podem-se configurar regras de firewall para bloquear todo o tráfego de saída, exceto as conexões necessárias (se houver). Em ambientes corporativos, isso se alinha com as práticas de isolamento de rede gerenciado, onde o acesso de saída é controlado por meio de pontos de conexão privados e etiquetas de serviço.

O isolamento de rede divide uma rede em segmentos para controlar quais comunicações podem passar entre eles. Em uma instalação de inferência local, esse desenho busca limitar as conexões de saída do processo e manter os dados sob o controle de quem opera o ambiente. Executar um modelo na máquina local não demonstra, por si só, que o processo esteja sem acesso à rede: a privacidade também depende das rotas habilitadas, das conexões remotas e das regras aplicadas ao equipamento.

Wireshark e tcpdump permitem observar o tráfego durante um teste, enquanto as regras de firewall podem bloquear conexões de saída não autorizadas. Uma captura mostra as comunicações que ocorreram durante o intervalo examinado e sob aquelas condições; não demonstra que nenhuma outra conexão possa ocorrer com uma carga ou configuração diferente. Por isso, o procedimento propõe repetir a observação com cargas variadas e combinar a captura com controles de firewall, em vez de tratar um único teste como certificação absoluta.

A auditoria deve distinguir as conexões esperadas daquelas que não foram autorizadas para a instalação. Se o sistema precisar de alguma conexão de saída, uma regra poderá permiti-la explicitamente; se não precisar, um bloqueio geral reduzirá as rotas disponíveis. Os comandos e mecanismos de firewall citados são exemplos de ferramentas, não uma política completa aplicável sem adaptação a qualquer sistema operacional ou rede corporativa. A configuração concreta deve refletir a infraestrutura e os serviços autorizados pelo operador.

Uma interface local não determina, por si só, a política de privacidade de todo o fluxo. Ativar modelos na nuvem, busca na web, APIs remotas, servidores MCP externos ou envios de arquivos pode encaminhar dados para fora do equipamento, embora a interface principal seja executada localmente. Portanto, a auditoria precisa considerar as conexões do processo e os serviços realmente ativados. O isolamento de rede ajuda a controlar esses caminhos, mas seu alcance depende das regras e dos componentes incluídos no teste.

Validação da integridade do artefato e teste de fumaça

Antes de integrar o modelo no fluxo de trabalho, é crucial verificar a integridade do artefato baixado. Isso implica comparar a soma de verificação (checksum) do arquivo GGUF ou safetensors com a publicada pelo fornecedor ou pela comunidade. Uma discrepância indica possível corrupção ou manipulação do arquivo.

Uma vez validada a integridade, deve-se executar um teste de fumaça mínimo: gerar uma resposta simples para confirmar que o modelo carrega corretamente na memória e produz saída coerente. Este teste deve ser realizado em um ambiente isolado de rede para não comprometer a auditoria de privacidade. Se o teste falhar, deve-se revisar a compatibilidade entre a quantização, o runtime e o hardware antes de prosseguir.

A soma de verificação permite conferir se os bytes do artefato correspondem a uma referência publicada. Para que a comparação seja útil, o valor esperado precisa corresponder ao mesmo arquivo e vir de uma fonte considerada válida pelo operador. Se os valores diferirem, o arquivo não coincide com essa referência; a divergência pode decorrer de corrupção ou manipulação, mas o resultado, sozinho, não identifica a causa. Um hash coincidente tampouco demonstra que o modelo seja seguro ou que seu comportamento esteja correto: ele verifica a identidade dos dados comparados.

O teste de fumaça responde a uma questão mais limitada: se o runtime consegue carregar o artefato na configuração atual e gerar uma resposta simples. Uma saída coerente nesse teste não valida de forma abrangente a qualidade, a precisão ou a segurança do modelo, nem demonstra que todos os contextos ou cargas funcionarão. Se o carregamento falhar, revisar a compatibilidade entre quantização, runtime e hardware pode ajudar a localizar possíveis incompatibilidades antes da integração ao fluxo de trabalho.

Executar o teste em um ambiente com a rede isolada evita que a verificação do carregamento dependa de conexões de saída imprevistas. A captura de tráfego e as regras de firewall complementam o cálculo de memória e a conferência do checksum: cada controle trata de um aspecto diferente. O checksum compara o arquivo com uma referência; o teste de fumaça observa uma execução básica; e a auditoria de rede examina as comunicações nas condições testadas. Nenhuma dessas etapas substitui as demais nem transforma uma verificação limitada em uma certificação completa.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.