Como escolher o modelo de código aberto e o hardware certos

Implementar um LLM privado começa com duas decisões profundamente interligadas: que modelo executar e em que hardware executá-lo. Se a combinação for errada, ou se gasta demasiado em capacidade que não se usa ou se fornece insuficiente o poder de cálculo que o caso de uso realmente necessita. A boa notícia é que o ecossistema de código aberto amadureceu ao ponto de existir um modelo bem testado para quase todos os orçamentos e tarefas — se souber como associá-los.

Comece pelo caso de uso, não pelo benchmark

O erro mais comum na seleção de modelos é liderar com pontuações de benchmark em vez de requisitos de tarefa. Um modelo que alcança resultados de última geração num benchmark de programação pode ser excessivo para resumir tickets de suporte e pode introduzir latência que o torna inadequado para uso em tempo real. Antes de escolher um tamanho de modelo, defina o seu caso de uso com precisão: qual é o comprimento médio de entrada em tokens? A tarefa requer raciocínio em múltiplas etapas ou é principalmente classificação e extração? Quantos utilizadores simultâneos o sistema servirá? Qual é a latência de resposta aceitável? Que idiomas o modelo deve dominar com fluência? Estas questões restringem o seu espaço de pesquisa de forma muito mais útil do que qualquer tabela de classificação.

Categorias de tamanho de modelo: 7–8 mil milhões, 32–70 mil milhões e 405 mil milhões+

O panorama de modelos de código aberto consolidou-se em torno de três categorias práticas de tamanho. Os modelos na faixa de 7–8 mil milhões de parâmetros — como o Mistral 7B, o Llama 3.1 8B e o Qwen2.5 7B — são extraordinariamente capazes para tarefas focadas: classificação de documentos, extração, sumarização e resposta a perguntas frequentes sobre um corpus de recuperação. Correm confortavelmente numa única GPU de consumidor ou semi-profissional e entregam latência baixa mesmo sem otimização pesada. A categoria de 32–70 mil milhões — Llama 3.3 70B, Qwen2.5 32B, Mixtral 8x7B — é onde o raciocínio de uso geral, a fluência multilíngue e a qualidade de seguimento de instruções melhoram substancialmente. Estes modelos podem lidar com tarefas analíticas complexas, contextos mais longos e geração mais matizada. Requerem GPUs de grau profissional mas permanecem acessíveis para uma implementação de servidor único. Acima dos 70 mil milhões, modelos como o Llama 3.1 405B entregam capacidade de fronteira mas exigem configurações multi-GPU e planeamento cuidadoso de infraestrutura; são melhor reservados para casos de uso onde a qualidade é a restrição principal e o orçamento não é.

• Modelos de 7–8 mil milhões: melhores para tarefas focadas de alto rendimento — classificação, extração, RAG sobre dados estruturados. GPU única, custo mais baixo.
• Modelos de 32–70 mil milhões: raciocínio geral sólido, suporte multilíngue, contextos mais longos. GPU única de alta gama ou nó multi-GPU pequeno.
• Modelos de 405 mil milhões+: qualidade de fronteira para as tarefas mais exigentes. Multi-GPU necessário; planear a infraestrutura cuidadosamente.
• As arquiteturas de mistura de especialistas (MoE) (p. ex. Mixtral) podem entregar qualidade de 70 mil milhões a um custo mais próximo de 13 mil milhões de parâmetros ativos — vale a pena avaliar se o rendimento importa.

Associar modelos a GPUs: a VRAM é a restrição vinculante

A VRAM da GPU é a restrição principal que determina quais modelos pode executar e a que velocidade. Um modelo tem de caber na VRAM para inferência — com espaço adicional para a cache KV, que cresce com o comprimento do contexto e o tamanho do lote. Como orientação aproximada: um modelo de 7–8 mil milhões em precisão de 16 bits requer cerca de 14–16 GB de VRAM; um modelo de 32 mil milhões necessita de aproximadamente 64 GB; um modelo de 70 mil milhões precisa de cerca de 140 GB. É por isso que uma única GPU de 24 GB (como a NVIDIA RTX 3090 ou 4090) é o lar natural dos modelos de 7–8 mil milhões, um cartão de 48 GB (RTX 6000 Ada) ou A100/H100 de 80 GB cobre a faixa de 32–70 mil milhões num único cartão, e qualquer coisa maior requer configurações multi-GPU com interligações NVLink ou InfiniBand.

Quantização: alcançar além do seu orçamento de VRAM

A quantização reduz a precisão dos pesos do modelo — de floats de 16 bits para inteiros de 8 bits (INT8) ou 4 bits (GPTQ, AWQ, GGUF Q4) — reduzindo drasticamente os requisitos de VRAM. Um modelo de 70 mil milhões quantizado para 4 bits pode caber em aproximadamente 35–40 GB de VRAM, tornando-o acessível numa configuração de duas GPUs de 24 GB. O compromisso de qualidade depende do método de quantização e da tarefa: para a maioria dos casos de uso de produção, o INT8 é quase sem perdas, e a quantização de 4 bits bem implementada preserva a maioria da qualidade do modelo para tarefas que não são altamente sensíveis a erros de raciocínio subtis. A quantização não é um contorno — é uma estratégia de implementação de primeira classe que a Privonis utiliza regularmente para maximizar a capacidade por euro de orçamento de hardware.

A questão certa não é "qual é o melhor modelo?" mas "qual modelo é suficiente para esta tarefa, no orçamento de hardware que temos?" A quantização aproxima as duas respostas mais do que a maioria das equipas espera.

Benchmarking antes de comprar: a abordagem avaliação-primeiro

Nenhum benchmark substitui a avaliação de um modelo nos seus dados e tarefas reais. Antes de se comprometer com hardware, a Privonis recomenda executar uma avaliação estruturada: definir um conjunto representativo de entradas do seu caso de uso de produção, estabelecer critérios de qualidade (precisão, aderência ao formato, latência no tamanho de lote pretendido) e testar dois ou três modelos candidatos em instâncias de GPU alugadas na cloud. Isto custa algumas centenas de euros e normalmente demora um dia ou dois. O resultado é uma especificação de hardware baseada em evidências em vez de uma suposição — e frequentemente revela que um modelo menor e mais rápido satisfaz as suas necessidades, poupando despesas de capital significativas.

• Defina entradas de avaliação a partir de dados de produção reais antes de escolher um modelo.
• Teste primeiro em capacidade de GPU alugada — instâncias de cloud para avaliação, on-premise para produção.
• Meça o que importa: precisão da tarefa, latência p95, tokens por segundo no tamanho de lote esperado.
• Considere ajustar um modelo menor antes de escalar para um maior — um modelo de 7 mil milhões ajustado frequentemente supera um de 70 mil milhões genérico em tarefas específicas.
• Planeie para a cache KV: contextos mais longos consomem VRAM rapidamente; faça benchmark no comprimento máximo de contexto esperado.

Como a Privonis orienta o processo de seleção

Escolher a combinação certa de modelo e hardware é uma das decisões de maior alavancagem numa implementação de IA privada. Uma infraestrutura bem combinada entrega a qualidade necessária a um custo que torna o caso de negócio claro; uma mal combinada ou gasta demasiado em poder de cálculo ocioso ou tem desempenho insuficiente em tarefas que importam. A Privonis traz experiência prática na seleção, quantização, ajuste fino e benchmarking de LLMs de código aberto numa variedade de casos de uso empresarial europeus. Ajudamo-lo a evitar o ciclo caro de tentativa e erro e a chegar a uma configuração de implementação dimensionada corretamente desde o início — e que permanece sustentável à medida que os modelos e os seus casos de uso evoluem.