Computador para rodar LLM local: GPU, memória e o que comprar

Computador para rodar LLM local: GPU, memória e o que comprar

Para rodar um LLM local na empresa, o que mais pesa é a memória da placa de vídeo (VRAM), ou a memória unificada em um Mac, porque o modelo precisa caber nela com folga para o contexto. O caminho seguro é escolher primeiro o menor modelo que resolve a tarefa, estimar quantas pessoas vão usar ao mesmo tempo e só então definir o computador. Comprar pela potência da GPU sem olhar o tamanho do modelo é o erro mais comum.

Principais pontos

• A VRAM define quais modelos rodam bem. A velocidade da GPU define o quanto a resposta será rápida, mas só importa depois que o modelo cabe.
• O tamanho do modelo e o nível de quantização determinam a memória necessária. Contexto longo e vários usuários simultâneos aumentam esse consumo.
• Uma tarefa bem delimitada, como classificar mensagens ou resumir documentos, costuma funcionar com modelos pequenos. Isso reduz muito o hardware necessário.
• Teste o modelo candidato em uma máquina emprestada ou alugada antes de comprar. A decisão deve vir de um piloto com uso real, não de uma tabela de especificações.
• Hardware local resolve privacidade e controle, mas traz manutenção, energia e responsabilidade de segurança. Nem todo caso precisa disso.

Por que a VRAM manda mais do que a potência da placa

Um modelo de linguagem é, na prática, um conjunto grande de números chamados parâmetros. Para gerar texto, esses números precisam estar na memória mais rápida disponível. Em uma placa de vídeo dedicada, essa memória é a VRAM. Se o modelo não cabe nela, o sistema passa parte do trabalho para a memória RAM comum e para o processador, e a resposta fica muito mais lenta.

Por isso duas placas com potência parecida podem ter experiências bem diferentes. A que tem mais VRAM roda modelos maiores ou com contexto mais longo. A que tem menos obriga a escolher um modelo menor ou aceitar lentidão. Para um dono de empresa, a pergunta útil não é qual GPU é a mais forte, e sim qual o maior modelo que a tarefa realmente exige.

A documentação de cada ferramenta de execução local costuma indicar requisitos de memória por modelo. Trate esses valores como ponto de partida e confirme com o seu uso, porque o consumo muda com o tamanho do contexto e com a configuração.

Como relacionar tamanho do modelo, memória e uso esperado

Há três variáveis que se somam no consumo de memória.

• Tamanho do modelo: quanto mais parâmetros, mais memória os pesos ocupam.
• Quantização: técnica que guarda os pesos com menos precisão para ocupar menos espaço. Em geral reduz a memória com perda de qualidade que depende do modelo e da tarefa, por isso precisa ser testada.
• Contexto e simultaneidade: o texto que o modelo "lê" a cada pedido gera uma memória adicional (o cache de contexto). Contexto longo e várias conversas ao mesmo tempo aumentam esse valor. Para entender esse ponto, vale ler sobre janela de contexto em IA.

A lógica de dimensionamento fica assim: some a memória dos pesos, some a memória do contexto esperado e deixe uma margem para o sistema operacional e para picos. Se a soma passa da VRAM, você tem três saídas: modelo menor, quantização mais agressiva ou mais hardware.

O uso esperado ajuda a decidir. Um assistente interno que resume documentos para uma pessoa por vez tem uma carga. Um agente que atende vários clientes ao mesmo tempo no WhatsApp tem outra, porque cada conversa ocupa contexto e disputa a mesma GPU. Antes de pensar em compra, escreva quantas pessoas ou fluxos usarão o modelo no horário de pico e quão longos são os textos.

Modelo pequeno basta? Teste antes de pagar por hardware grande

Muita tarefa de empresa não exige o maior modelo. Classificar uma mensagem por assunto, extrair campos de um documento, reescrever um texto em tom padrão ou responder perguntas sobre uma base de conhecimento curta costuma funcionar com modelos menores, desde que o contexto seja bem preparado. O artigo sobre modelos pequenos de IA na empresa detalha quando eles bastam e como montar o teste.

O raciocínio econômico é simples: cada degrau de tamanho do modelo empurra o requisito de hardware para cima, e o salto nem sempre se traduz em ganho visível para a tarefa. Monte um conjunto pequeno de exemplos reais da sua operação, com a resposta esperada, e compare modelos de tamanhos diferentes. Se o menor entrega o que você precisa, o computador também pode ser menor.

Tarefas que exigem raciocínio longo, código complexo ou muitas instruções ao mesmo tempo tendem a pedir modelos maiores. Nesses casos, pode ser mais sensato usar um serviço em nuvem do que montar um servidor local, tema tratado mais abaixo.

GPU dedicada, Mac com memória unificada ou só CPU?

Existem três famílias de máquina que costumam aparecer nas conversas sobre IA local. Cada uma tem um perfil.

• PC ou servidor com GPU dedicada: é o caminho mais comum para quem quer velocidade e várias conversas simultâneas. O ecossistema da NVIDIA é o mais amplamente suportado pelas ferramentas de execução, enquanto o suporte a outras marcas varia por ferramenta e versão, e deve ser conferido na documentação antes da compra. O limite é a VRAM da placa.
• Mac com chip Apple Silicon: usa memória unificada, compartilhada entre processador e GPU. Isso permite carregar modelos maiores do que caberiam em uma placa de consumo com pouca VRAM, em geral com velocidade de geração menor do que uma GPU dedicada de alto desempenho. É uma opção atraente para uso individual ou de equipe pequena, com poucos acessos simultâneos.
• Máquina só com CPU: funciona para modelos pequenos e para testes, com respostas mais lentas. Serve para validar uma ideia, não costuma servir para atendimento com expectativa de resposta rápida.

A escolha depende do que você precisa priorizar: velocidade, tamanho do modelo que cabe, número de usuários ou simplicidade de operação. Não existe resposta única, e qualquer comparação de desempenho deve ser feita com o seu modelo e a sua carga.

O que mais pesa além da GPU

O orçamento de um computador para IA local não termina na placa. Alguns itens são esquecidos até aparecerem como problema.

• Memória RAM: precisa acomodar o sistema, as ferramentas e eventualmente parte do modelo. Ter pouca RAM faz a máquina travar mesmo com boa GPU.
• Armazenamento rápido: modelos ocupam bastante espaço em disco e carregam mais rápido em SSD. Se você testa vários modelos, o disco enche rápido.
• Fonte de energia e refrigeração: placas potentes consomem energia e geram calor. Em escritório sem ventilação adequada, a máquina reduz o desempenho ou falha.
• Estabilidade elétrica: nobreak ou estabilizador evita corrupção de dados e reinicializações em quedas de energia.
• Rede e acesso: se mais de uma pessoa vai usar, é preciso definir quem acessa, de onde e com qual autenticação. Um modelo local exposto sem controle vira um risco de segurança.
• Manutenção: alguém precisa atualizar o software, observar falhas e trocar o modelo quando houver versão melhor.

Sobre operação, o texto sobre Ollama na empresa mostra como rodar um modelo local sem improvisar, com atenção a acesso, atualização e registro de uso.

Roteiro para escolher sem superdimensionar

Siga esta ordem. Ela evita comprar antes de saber o que se precisa.

• Descreva a tarefa em uma frase e o resultado esperado. Exemplo: resumir atas de reunião internas e devolver tópicos de ação.
• Defina os dados envolvidos e o motivo para mantê-los locais. Se há dados pessoais, consulte as orientações da ANPD e avalie a necessidade com seu jurídico.
• Reúna alguns exemplos reais, com a resposta que você considera boa. Eles serão seu teste.
• Compare um modelo pequeno, um médio e, se necessário, um grande, usando uma máquina emprestada ou um servidor alugado por poucos dias.
• Anote a memória usada, a velocidade percebida e a qualidade da resposta em cada teste.
• Estime o pico de uso: quantas pessoas ao mesmo tempo e qual o tamanho típico do texto.
• Escolha o menor hardware que atende o pico com margem. Se estiver em dúvida entre dois níveis, comece pelo menor e deixe espaço para ampliar.
• Compare com a alternativa em nuvem usando o custo por tarefa concluída, conceito explicado em unit economics, do FinOps Foundation.

Cenário ilustrativo

Imagine uma empresa de serviços com equipe administrativa pequena que quer resumir contratos e ofícios internos sem enviar os documentos para fora. Esse é um cenário ilustrativo, não um caso real.

O responsável lista a tarefa: ler um documento e devolver um resumo com prazos e obrigações. Ele separa alguns documentos reais, escreve o resumo esperado de cada um e testa um modelo pequeno e um médio em uma máquina emprestada. O modelo médio produz resumos um pouco mais organizados, mas o pequeno entrega os prazos corretamente nos exemplos testados. O uso previsto é de uma pessoa por vez, em horário comercial.

Com isso, a empresa descobre que não precisa de um servidor com várias placas. Uma máquina com GPU de VRAM moderada, boa quantidade de RAM e SSD rápido atende o piloto. Se o uso crescer para várias pessoas ao mesmo tempo, a decisão é revista com dados de uso, não por palpite.

Quando o hardware local não é a melhor resposta

Rodar localmente faz sentido quando há exigência de privacidade, necessidade de operar sem internet, controle sobre a versão do modelo ou volume estável que justifique o investimento. Não faz sentido quando a carga é irregular, quando a tarefa exige o maior modelo disponível ou quando ninguém tem tempo de manter a máquina.

Nesses casos, um serviço em nuvem pode ser mais adequado, mas traz questões próprias de contrato e de dados. Se o provedor processa dados fora do Brasil, vale conferir o que a LGPD exige em transferência internacional de dados com IA. Uma arquitetura mista também é possível: modelo local para dados sensíveis e serviço externo para tarefas que não envolvem dados pessoais.

O método que aplicamos segue quatro passos: mapear o processo e a linha de base atual, limitar dados e ações do sistema, pilotar um fluxo real com registro e uma métrica de sucesso combinada, e transferir a operação com a decisão de expandir, ajustar ou parar. Aplicado ao hardware, isso significa que a compra vem depois do piloto, e não antes. Para riscos de forma mais ampla, o AI Risk Management Framework do NIST oferece uma referência de governança.

Perguntas frequentes

Qual a configuração mínima de computador para rodar LLM local? Não existe um mínimo único, porque ele depende do modelo. Modelos pequenos rodam em máquinas modestas, inclusive só com CPU, enquanto modelos maiores exigem muita VRAM ou memória unificada. Consulte a documentação da ferramenta e do modelo que você pretende usar e confirme em teste.

Vale mais a pena comprar uma GPU potente ou uma com mais VRAM? Para rodar modelos maiores, mais VRAM costuma ter prioridade, porque o modelo precisa caber na memória. Potência extra melhora a velocidade, mas só depois que o modelo cabe. Defina primeiro o modelo e o contexto, depois escolha a placa.

Um Mac serve para rodar IA local na empresa? Serve para muitos casos de uso individual ou de equipe pequena, porque a memória unificada permite carregar modelos relativamente grandes. A velocidade e o número de acessos simultâneos costumam ser menores do que em um servidor com GPU dedicada. Teste com o seu modelo antes de decidir.

IA local resolve a LGPD sozinha? Não. Manter os dados dentro da empresa reduz alguns riscos, como o envio a terceiros, mas continuam valendo finalidade, base legal, controle de acesso, retenção e segurança. Trate o servidor local como qualquer sistema que processa dados pessoais e valide a configuração com o jurídico.

Fontes

• ANPD: Autoridade Nacional de Proteção de Dados
• FinOps Foundation: unit economics
• NIST AI Risk Management Framework