IA Local para Começar: Como Correr um Agente de IA numa Placa Gráfica de 2018

Paulo Rodrigues8 min de leitura

IA Local para Começar: Como Correr um Agente de IA numa Placa Gráfica de 2018

"Precisa de pelo menos 24GB de VRAM para um modelo local útil" é o mito mais caro da IA self-hosted. Empurra as pessoas diretamente para uma subscrição de cloud — e diretamente para enviar os seus prompts e documentos para a máquina de outra pessoa.

O meu agente de IA do dia a dia não funciona assim. Corre um modelo de 12 mil milhões de parâmetros numa RTX 2080 Ti — uma placa de jogos de 2018, com 11GB — inteiramente na máquina debaixo da minha secretária. Sem chave de API. Sem prompts a sair do edifício para um modelo de terceiros. Não é um projeto de laboratório; é a ferramenta que uso mesmo para pesquisar, ler, resumir e verificar.

Eis exatamente como cabe, a stack que o serve e — tão importante quanto isso — o que não consegue fazer.

O que significa "útil" aqui

Antes do hardware, o enquadramento honesto: isto não é uma demonstração de chatbot. O agente faz trabalho real num ciclo — corre uma pesquisa na web, abre as páginas, lê-as e escreve uma síntese com fontes. É esta a forma da maior parte das tarefas de "agente de IA" do dia a dia, e quase nada disto precisa do modelo mais caro do mundo. Precisa de um modelo decente que esteja sob o seu controlo.

Essa distinção — capacidade que se aluga versus capacidade de que se é dono — é o ponto central. Vamos então tornar a posse concreta.

O orçamento de memória: como um modelo de 12B cabe numa placa de 11GB

A ideia mais útil em IA local é o treino consciente da quantização (QAT). Uma quantização ingénua de um modelo a 4 bits perde precisão de forma visível. Um modelo QAT é treinado para sobreviver aos 4 bits, por isso mantém uma qualidade próxima da precisão total com cerca de um quarto da memória. O modelo que corro — Gemma 4 12B QAT — fica em cerca de 10GB dos 11GB da placa.

Isto deixa cerca de 1GB. Eis o que esse GB compra, e porque cada peça importa:

  • Uma janela de contexto de 96 mil tokens. Suficiente para alimentar documentos reais ao modelo, não prompts de brincar. O contexto vive na cache KV, e a forma como se quantiza essa cache decide quanto contexto cabe na memória que sobra.
  • Um pequeno modelo "auxiliar" de 0,4B para descodificação especulativa. Prevê vários tokens à frente e o modelo grande verifica-os de uma só vez. Na minha configuração, isto eleva a geração para cerca de 93 tokens por segundo — rápido o suficiente para trabalho real, não para uma demonstração. O modelo auxiliar partilha a cache do modelo grande, por isso quase não custa VRAM extra.
  • Margem de segurança. Para a placa não ficar sem memória a meio de uma tarefa.

A lição não é "compre uma 2080 Ti". É que o número de VRAM na caixa não é a limitação que as pessoas assumem. A quantização, as definições da cache KV e um modelo auxiliar opcional decidem o que cabe de facto — e a maior parte dos conselhos do tipo "precisa de uma GPU maior" ignora os três.

A stack de serviço: llama.cpp, e porque dispensei o CUDA

O modelo é servido pelo llama.cpp com o backend Vulkan — não CUDA. Essa escolha surpreende, por isso medi em vez de assumir.

Nesta placa Turing, os resultados foram claros:

  • A geração de tokens — a velocidade que se sente em cada turno de conversa ou de agente — quase não mudou com o CUDA. No máximo, uns 8%.
  • O processamento de prompt (o contexto longo) é onde o CUDA ganha, cerca de 1,5x.

A razão é física, não software. A geração de tokens é limitada pela largura de banda da memória, não pelo cálculo bruto. A minha configuração já corre perto do teto de largura de banda da placa, cerca de 616 GB/s, por isso um backend diferente não consegue ultrapassar a parede. E o CUDA traz um imposto: não há binário oficial pré-compilado para a minha configuração, o que obriga a recompilar uma toolkit de vários gigabytes a um ritmo de lançamentos quase diário. O caminho Vulkan já é acelerado em Turing e sobrevive às atualizações do kernel sem ser tocado.

Se a maior parte do seu trabalho é gerar — conversa, agentes — está limitado pela largura de banda, e o backend por omissão é provavelmente suficiente. Só se a maior parte for ingerir documentos enormes é que a velocidade de prompt vale a pena otimizar. Meça a sua carga de trabalho antes de copiar o ritual do "instalar CUDA".

Quanto custa — e o que se recebe em troca

O custo marginal de cada pergunta é eletricidade, não uma fatura mensal que cresce com o uso. Uma placa de jogos usada é um custo único que se paga depressa face a qualquer fatura de cloud ao token. (Já escrevemos sobre a infraestrutura de 107 euros por trás de toda esta configuração — a filosofia é a mesma: ser dono das partes aborrecidas.)

Mas o verdadeiro retorno não é o dinheiro. São duas coisas que a cloud não consegue dar:

  • Privacidade por construção. Cada chamada de IA na cloud coloca os seus dados — ou os do seu cliente — no modelo de outra pessoa. Corra o modelo na sua máquina e os seus prompts nunca chegam a terceiros. Não há contrato de tratamento de dados para ler, porque não há terceiros.
  • Postura de conformidade. As principais obrigações de alto risco do Regulamento Europeu da IA entram em vigor a 2 de agosto de 2026. "Onde é que isto é processado?" deixa de ser uma nota de rodapé técnica e passa a ser uma pergunta a que poderá ter de responder. "Em hardware de que sou dono, na UE, sem nada a sair do edifício" é uma boa resposta.

Os limites honestos

Um guia de iniciação que só vende as vantagens está a mentir. Dois limites importam.

Os modelos pequenos inventam na síntese difícil. Um modelo de 8 mil milhões de parâmetros conduz ferramentas muito bem e depois mistura factos com confiança quando lhe pedem para raciocinar sobre eles — um dos meus já "calculou" 366 dias num ano. A falha é mau raciocínio sobre bons dados, não dados em falta, o que a torna fácil de não notar. Para síntese de vários passos, um 12B é mais ou menos o mínimo em que confio, e mesmo assim verifico.

A fiabilidade vem das redes de segurança, não só do modelo. O meu agente já repetiu a mesma linha 4262 vezes e manteve a GPU a 100% durante mais de seis minutos sem parar. A correção óbvia — uma penalização de repetição — piorou as coisas, porque essas penalizações corrompem precisamente os tokens que se querem intactos: URLs, números de versão, datas. A correção certa foi um guarda determinístico que observa a resposta e aborta um ciclo descontrolado, mais uma verificação de que o modelo nunca cita uma página que não abriu de facto. Em IA local, o modelo é metade do trabalho. A outra metade são as salvaguardas à volta dele.

A conclusão

Não precisa de um datacenter nem de uma subscrição de cloud para correr um agente de IA genuinamente útil. Precisa de uma GPU usada, de um modelo consciente da quantização, de uma stack de serviço sensata e da disciplina de construir algumas redes de segurança.

A estratégia que daqui resulta é simples: seja dono dos 80% aborrecidos — o pesquisar, ler, resumir e verificar do dia a dia — em hardware que controla, e alugue os 20% de fronteira apenas quando uma tarefa o exigir mesmo. Para uma empresa europeia, isto não é só mais barato. É uma postura de privacidade e conformidade que se consegue defender.

Se uma placa de jogos de sete anos consegue fazer isto, a pergunta que vale a pena fazer não é "conseguimos correr IA localmente?". É "afinal, o que é que estamos a alugar à cloud?".

Perguntas Frequentes

Quanta VRAM é mesmo precisa para correr um LLM local útil?

Muito menos do que o 'mínimo de 24GB' que se costuma ouvir. Eu corro um modelo de 12 mil milhões de parâmetros numa placa de 11GB. O truque é o treino consciente da quantização (QAT) a 4 bits, que mantém uma qualidade próxima da precisão total enquanto os pesos ocupam cerca de 10GB. O número na caixa da placa não é a verdadeira limitação — a quantização, as definições da cache KV e um pequeno modelo auxiliar opcional decidem o que cabe de facto.

Preciso de CUDA para correr IA numa GPU NVIDIA?

Não necessariamente. Numa placa Turing mais antiga, comparei o CUDA com o backend Vulkan no llama.cpp. A geração de tokens — a velocidade que se sente num turno de conversa ou de agente — quase não mudou, porque a geração é limitada pela largura de banda da memória, não pelo cálculo. O CUDA ajuda sobretudo no processamento de contextos longos (cerca de 1,5x aí) e traz um custo de manutenção real. Para conversa e trabalho de agente, o Vulkan por omissão chegou.

Um modelo local é tão bom como um modelo de fronteira na cloud?

Não, e essa é a pergunta errada. Um modelo local pequeno é excelente nos 80% aborrecidos do trabalho de agente — pesquisar, ler, resumir, verificar — e mais fraco na síntese difícil de vários passos, onde os modelos pequenos podem inventar. A postura certa é ser dono da carga de trabalho do dia a dia localmente e recorrer a um modelo de fronteira apenas para os 20% que realmente precisam.

Pronto para automatizar o seu negócio?

Construímos ferramentas de IA e sistemas de automação para PMEs europeias — desde MVPs rápidos até sistemas em produção, sempre em conformidade com o GDPR.

it's human stuff

Insights semanais de IA para PMEs europeias. Sem exageros, apenas o que funciona.

Continue a Ler