Quais modelos de IA você pode hospedar localmente?

O que determina quais modelos de IA pode alojar localmente

Quais modelos de IA pode alojar localmente é determinado por um único valor: a RAM disponível no servidor. A família do modelo e o framework têm muito menos importância do que saber se os pesos cabem na memória com margem disponível. Este artigo apresenta os cálculos necessários para determinar isso. Instalar um runtime é uma tarefa separada, abordada em o guia para executar o Ollama num VPS.

Dois custos determinam a resposta. Os pesos são o custo fixo, definido pelo número de parâmetros e pela quantização. A janela de contexto é o custo variável, e é o fator que muitas pessoas esquecem até um modelo que carregou ontem deixar de carregar hoje.

A aritmética do dimensionamento: bits por parâmetro

Um ficheiro de modelo é quase todo composto por pesos. Cada peso é armazenado com um determinado número de bits. A quantização consiste em armazenar os pesos com menos bits do que a precisão usada no treino. Isto reduz ligeiramente a precisão e poupa muita memória. O tamanho resulta diretamente daí:

weights in GB = (parameters in billions x bits per weight) / 8

Os modelos são lançados com 16 bits, o que corresponde a 2 GB por mil milhões de parâmetros. É por isso que quase ninguém executa a precisão de lançamento numa VPS. Estas são as quantizações que encontrará na prática, com a respetiva média real de bits por peso:

• Q8_0 armazena cerca de 8.5 bits por peso, ou seja, aproximadamente 1.1 GB por mil milhões de parâmetros.
• Q6_K armazena cerca de 6.6 bits, ou seja, aproximadamente 0.83 GB por mil milhões.
• Q5_K_M armazena cerca de 5.7 bits, ou seja, aproximadamente 0.71 GB por mil milhões.
• Q4_K_M armazena cerca de 4.8 bits, ou seja, aproximadamente 0.6 GB por mil milhões.

Use 0.6 GB por mil milhões de parâmetros como valor de referência. Q4_K_M é a opção predefinida adequada num servidor limitado pela memória: na maioria das tarefas, a perda de qualidade face a 8 bits é pequena e o ficheiro tem quase metade do tamanho. Abaixo de 4 bits, a perda aumenta rapidamente. Por isso, um modelo 70B comprimido para 2 bits normalmente responde pior do que um modelo 32B com 4 bits da mesma geração. Quando a memória é limitada, reduza uma classe de tamanho antes de passar para menos de 4 bits.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

A coluna de pesos acima aplica a regra de 0.6 GB por mil milhões. Os ficheiros GGUF reais ficam a poucos pontos percentuais desse valor, porque as camadas de embeddings e de saída são mantidas com uma precisão superior à do restante modelo. Um modelo 3B com 4 bits ocupa cerca de 1.8 GB. Um modelo 8B ocupa 4.8 GB. Um modelo 32B ocupa 19.2 GB, e um modelo 70B ocupa 42 GB.

Por que o tamanho do contexto consome mais RAM do que os pesos

O cache KV (cache de chave e valor, o estado de atenção que o modelo mantém para cada token atualmente presente na conversa) é o segundo custo. Ele é alocado quando o modelo é carregado, dimensionado para o tamanho de contexto solicitado e cresce linearmente com esse tamanho.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

Com o contexto padrão do Ollama, esse modelo 8B usa meio gigabyte para o cache. Com 8192 tokens, ele usa 1 GB. Com o contexto de 128k anunciado no cartão do modelo, ele usa 16 GB, mais de três vezes o tamanho dos pesos. O 70B apresenta o caso oposto: o cache com 128k é de 40 GB, menos do que os próprios pesos, porque a atenção de consulta agrupada impede que o custo por token cresça próximo da mesma proporção que a quantidade de parâmetros.

O tamanho de contexto padrão do Ollama é de 4096 tokens em um servidor que usa apenas CPU. Quando há uma GPU, ele escolhe o padrão com base na VRAM: 32k entre 24 e 48 GiB e 256k com 48 GiB ou mais. Aumente esse valor com a variável OLLAMA_CONTEXT_LENGTH no servidor. Em seguida, verifique o valor efetivamente atribuído ao modelo em execução na coluna CONTEXT de ollama ps. O cálculo de memória por trás dessa configuração é explicado em no artigo sobre num_ctx e tamanho de contexto.

Há duas formas de reduzir novamente o cache. Solicite o contexto de que precisa, em vez do contexto anunciado no cartão do modelo, pois a maior parte das tarefas de chat e programação cabe em 8k a 32k. Outra opção é quantizar o próprio cache para 8 bits. Isso reduz o tamanho pela metade, com algum custo na recuperação de informações em contextos longos.

Um modelo residente mantém-se na RAM até ser descarregado

Ollama mantém um modelo na memória durante 5 minutos após o último pedido e, em seguida, descarrega-o. Esse valor predefinido é adequado para um portátil, mas não para um servidor, onde o primeiro pedido depois de cada período de inatividade volta a pagar o tempo de carregamento.

ollama ps
ollama stop qwen3:4b

ollama ps apresenta os modelos residentes. A coluna SIZE mostra a quantidade de memória ocupada e a coluna UNTIL mostra quando o modelo expira. Para manter um modelo permanentemente na memória, defina OLLAMA_KEEP_ALIVE=-1 no serviço. Um valor de 0 descarrega-o assim que cada resposta termina.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

Envie um prompt e execute ollama ps novamente 10 minutos depois. O modelo continua listado. Esse é precisamente o objetivo: mantém essa RAM ocupada, quer esteja a ser utilizado ou não. Um modelo fixado não representa capacidade disponível. Numa VPS de 16 GB, um modelo 8B com contexto de 8k ocupa aproximadamente 6 GB enquanto o serviço estiver em execução. Por isso, dimensione o servidor para o modelo e a sua aplicação, não apenas para o modelo. Fixar um modelo na memória aborda o compromisso entre essa ocupação e a latência de um arranque a frio.

O que funciona num VPS com 4 GB

Reserve cerca de 1 GB para o sistema operativo e o servidor do modelo. Isso deixa aproximadamente 3 GB. É suficiente para um modelo de 1B a 4B com 4 bits, no contexto predefinido de 4096 tokens. Em agosto de 2026, essa categoria inclui Llama 3.2 com 3B, Qwen 3 com 1.7B e 4B, além das versões pequenas de Gemma e Phi. Use estes exemplos apenas para indicar tamanhos, não como recomendações. Os nomes mudam a cada poucos meses, mas a aritmética não.

Espere aproximadamente 6 a 14 tokens por segundo. Modelos deste tamanho executam bem tarefas restritas: classificação, extração de etiquetas, resumos curtos e reescrita de um parágrafo segundo o estilo da organização. São fracos em raciocínio com várias etapas e em código que abrange vários ficheiros. Nenhuma quantidade de instruções resolve essa limitação.

O problema típico neste nível é o swap. Se o modelo não couber na memória, o Linux não recusa carregá-lo. Em vez disso, transfere páginas de memória para o disco. Como a geração de cada token lê todos os pesos uma vez, o desempenho cai para segundos por token. Monitorize free -h e as colunas si e so de vmstat 1 enquanto o modelo responde. Valores diferentes de zero em swap in e swap out durante a geração indicam que o modelo é demasiado grande para esse plano.

O que funciona num VPS com 8 a 16 GB

É neste ponto que um modelo self-hosted se torna geralmente útil. Com 8 GB, pode executar um modelo 7B ou 8B a 4 bits, com cerca de 4.8 GB de pesos e um contexto de 8k. Com 16 GB, pode executar um modelo 13B ou 14B a 4 bits, com cerca de 8.4 GB, ou manter um modelo 8B a 8 bits se preferir usar a memória para obter mais precisão em vez de aumentar o número de parâmetros.

A velocidade é a principal limitação. Um modelo 8B numa CPU gera cerca de 3 a 7 tokens por segundo, e um modelo 14B gera cerca de 1.5 a 3.5. Uma pessoa lê aproximadamente 5 a 10 tokens por segundo, por isso um modelo 8B num VPS com CPU parece um datilógrafo lento. Isto é aceitável para uma tarefa em segundo plano, mas torna-se cansativo num chat interativo. Execuções medidas do Qwen 3 a 8B e de modelos maiores num VPS mostram o resultado na prática.

O que roda numa VPS de 32 a 64 GB

Um modelo 32B a 4 bits ocupa cerca de 19.2 GB, por isso cabe num plano de 32 GB com um contexto curto e funciona confortavelmente com 48 GB ou 64 GB. Um modelo 70B a 4 bits ocupa cerca de 42 GB, por isso precisa de 64 GB antes de adicionar qualquer cache.

Depois, avalie a velocidade de forma realista. Um modelo 32B em CPU processa cerca de 0.6 a 1.5 tokens por segundo, enquanto um modelo 70B processa 0.2 a 0.5. Uma resposta de 500 tokens desse modelo 70B demora cerca de vinte minutos. Estas ferramentas são adequadas para processamento em lote. Pode colocá-las a processar uma fila de documentos durante a noite, e a velocidade deixa de ser relevante. Mas, se as colocar atrás de uma interface de chat, a velocidade passa a ser muito importante.

O encaminhamento de mixture of experts altera estes cálculos, e este é o único detalhe de arquitetura que vale a pena aprender. Um modelo MoE encaminha cada token apenas por uma pequena parte dos seus pesos. Um modelo com 30B de parâmetros no total e 3B ativos por token precisa da memória de um modelo 30B e gera texto a uma velocidade próxima da de um modelo denso 3B, porque cada token lê apenas os especialistas ativos. Numa máquina com 32 GB, um MoE com esta configuração é muito mais utilizável do que um modelo denso 30B. A regra principal é: o total de parâmetros determina a memória; os parâmetros ativos determinam a velocidade.

Qual é, na prática, a velocidade da inferência na CPU?

Gerar um token exige ler todos os pesos ativos da memória uma vez. Nada evita isso, portanto a velocidade de geração numa CPU é determinada pela largura de banda da memória, não pelo número de núcleos. O limite é uma divisão: a largura de banda utilizável da memória dividida pelo tamanho dos pesos em bytes. Um VPS partilhado pequeno fornece realisticamente 10 a 25 GB por segundo através das suas vCPUs, portanto um modelo de 4.8 GB atinge no máximo cerca de 2 a 5 tokens por segundo.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

Estes são intervalos normalmente observados em hardware VPS comum, não um benchmark de uma máquina específica. O seu resultado depende da geração da memória, do número de canais no host e da quantidade de vizinhos que estão a competir pela largura de banda. Meça o seu próprio resultado, usando qualquer tag de modelo que já tenha:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

O resumo apresentado depois do fim da resposta termina com uma linha que contém eval rate: ... tokens/s. Essa é a velocidade de geração. Ignore a primeira execução de uma sessão, porque load duration no mesmo resumo inclui a leitura dos pesos a partir do disco. Medir corretamente tokens por segundo explica como obter um valor que possa ser comparado.

Há dois resultados que surpreendem muitas pessoas. Adicionar vCPUs deixa rapidamente de ajudar, porque, depois de aproximadamente 8 núcleos, os núcleos adicionais ficam à espera da memória em vez de fazerem cálculos. Num plano partilhado, o mesmo comando também devolve valores diferentes de hora para hora. Isto é tempo de CPU roubado por um vizinho ruidoso, e não algo que tenha configurado incorretamente.

Ler o seu prompt é uma tarefa diferente de gerar a resposta. O processamento do prompt é limitado pelo poder de cálculo, portanto escala com o número de núcleos e é onde uma GPU obtém a maior vantagem. Um documento longo demora minutos a ser lido por uma CPU e segundos por uma GPU. Essa é a primeira limitação que encontra ao apontar um agente de programação para um modelo alojado por si, porque cada turno reenvia o contexto do ficheiro e as definições das ferramentas antes de ser devolvido um único token da resposta.

O que muda quando adiciona uma GPU

A aritmética não muda. Muda apenas o conjunto ao qual ela se aplica. A VRAM é um limite rígido, por isso calcule o que cabe antes de alugar:

• 8 GB de VRAM comportam um modelo 7B ou 8B a 4 bits com um contexto curto.
• 16 GB comportam um modelo 14B a 4 bits com um contexto real, ou um modelo 8B a 8 bits.
• 24 GB comportam um modelo 32B a 4 bits com o contexto curto.
• 48 GB ou mais comportam um modelo 70B a 4 bits, com espaço para cache e simultaneidade.

Quando um modelo não cabe, o Ollama divide-o: algumas camadas ficam na GPU e as restantes na CPU. ollama ps mostra essa divisão na coluna PROCESSOR, com um valor semelhante a 78%/22% CPU/GPU. Interprete isso como um aviso, não como uma funcionalidade. A metade executada na CPU define o ritmo, porque cada token continua à espera dessas camadas. Por isso, um modelo com um quarto das camadas na CPU executa a uma velocidade muito mais próxima da CPU do que da GPU. Se encontrar uma divisão que não pretendia, reduza primeiro o comprimento do contexto. Normalmente, é o cache que faz o modelo ultrapassar o limite.

A simultaneidade é outra razão para escolher uma GPU maior. Os pesos são partilhados entre pedidos simultâneos, mas cada pedido ativo precisa do seu próprio cache KV. Assim, dez utilizadores simultâneos de um modelo 8B com contexto de 8k precisam de dez vezes 1 GB de cache, além dos pesos. Servir utilizadores simultâneos a partir de um único modelo alojado localmente mostra até onde esse limite permite chegar.

Também é uma questão de cálculo determinar se vale a pena alugar a GPU. Tudo depende de quantos tokens realmente gera por mês. O ponto de equilíbrio entre uma VPS com GPU e tokens de API apresenta esses valores.

O que não é possível hospedar localmente

Há duas limitações diferentes, e é importante saber qual delas está a enfrentar.

A primeira são os pesos fechados. Os modelos comerciais de fronteira não são distribuídos, por isso não existe nenhum ficheiro para descarregar e nenhuma quantidade de RAM altera esse facto. É possível hospedar localmente tudo o que os envolve: a interface, a camada de recuperação, o ciclo do agente e os logs. O próprio modelo continua a ser uma API remota. A possibilidade de hospedar Claude localmente explica isso em detalhe.

A segunda são os pesos abertos que são simplesmente demasiado grandes. As maiores releases abertas usam arquiteturas de mistura de especialistas, com centenas de milhares de milhões de parâmetros no total. A mesma regra aplica-se a esses modelos: um modelo com 400B de parâmetros no total, quantizado para 4 bits, precisa de cerca de 240 GB apenas para os pesos, antes de qualquer cache. Isso exige hardware especializado, e alugá-lo mensalmente custa muito mais do que a maioria das pessoas gasta em tokens de API num ano. O que é necessário para hospedar localmente um modelo da classe Kimi explica os requisitos reais.

A distinção prática entre os dois casos é esta: hospede localmente quando a carga é constante e os dados não devem sair do servidor. Compre tokens quando a carga for variável ou quando a qualidade das respostas dos modelos de fronteira for aquilo de que realmente precisa.

Verifique o que tem antes de escolher

free -h
nproc
lscpu | grep 'Model name'

Faça o planeamento com base na coluna available de free -h, e não na coluna total, porque total inclui memória que o sistema já está a utilizar. Subtraia cerca de 1 GB para o sistema operativo e o servidor de modelos. Divida o que resta por 0.6 para obter o maior número de parâmetros, em milhares de milhões, que pode alojar com 4 bits. Em seguida, subtraia a cache KV correspondente ao contexto que pretende utilizar. O valor restante é a resposta. Ao contrário de uma lista de nomes de modelos, não fica desatualizado.

FAQ

Quanta RAM é necessária para executar um modelo 8B?

Cerca de 4.8 GB para os pesos com quantização de 4 bits, mais a cache KV para o comprimento do contexto, e aproximadamente 1 GB para o sistema operativo e o servidor do modelo. Num contexto de 8192 tokens, a cache acrescenta cerca de 1 GB. Por isso, um plano de 8 GB funciona, mas um plano de 4 GB não. Se quiser o contexto completo de 128k anunciado no cartão do modelo, só a cache ocupa 16 GB. Nesse caso, precisará de um plano de 32 GB.

Porque é que o meu modelo está lento, apesar de o VPS ter vCPUs suficientes?

A geração é limitada pela largura de banda da memória, não pelo número de núcleos. Para gerar cada token, é necessário ler todo o conjunto ativo de pesos da RAM. Quando alguns núcleos saturam os canais de memória, os restantes ficam à espera. A outra causa comum é a swap. Se vmstat 1 mostrar um valor diferente de zero em si e so enquanto o modelo responde, os pesos não cabem na RAM. Parte de cada token está a ser lida do disco, o que tem um custo muito superior ao esperado.

Uma janela de contexto maior precisa realmente de mais memória?

Sim. O crescimento é linear em relação ao número de tokens. Um modelo 8B típico usa cerca de 128 KiB de cache KV por token. Assim, 8192 tokens ocupam 1 GB e 131072 tokens ocupam 16 GB. A cache é alocada quando o modelo é carregado, não quando a conversa cresce. Por isso, pedir um contexto de 128k reserva imediatamente essa memória, mesmo que cada prompt enviado tenha apenas 200 tokens.

Devo executar um modelo grande com 2 bits ou um modelo menor com 4 bits?

Escolha o modelo menor com 4 bits. A qualidade diminui lentamente de 8 para 4 bits e rapidamente abaixo de 4 bits. Por isso, um modelo 70B reduzido a 2 bits normalmente produz respostas piores do que um modelo 32B com 4 bits da mesma geração de modelos. A quantização agressiva manifesta-se como repetições e instruções ignoradas, não como uma mensagem de erro. Por isso, é fácil atribuir o problema ao prompt. Considere 4 bits como o limite mínimo e altere o número de parâmetros.

Posso alojar localmente um modelo tão capaz como os grandes modelos comerciais?

Não num VPS comum. Os modelos open weight mais fortes têm centenas de milhares de milhões de parâmetros. Com 4 bits, isso requer mais de 200 GB de RAM antes de considerar a cache KV. Além disso, os modelos comerciais mais fortes não são distribuídos. O hardware comum é adequado para executar um bom modelo 8B a 32B para uma tarefa específica. Nesse caso, um modelo pequeno, especializado e bem configurado pode igualar um modelo geral. Se precisar de qualidade de fronteira, compare o custo da API com o do hardware antes de comprar qualquer uma das opções.