Quais modelos de IA posso hospedar na minha VPS?

O que determina quais modelos de IA pode alojar por conta própria

Quais modelos de IA pode alojar por conta própria é determinado por um único número: a RAM disponível na máquina. 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 alguma margem. Este artigo apresenta a aritmética necessária para calcular isso. Instalar um runtime é uma tarefa separada, explicada em guia para executar o Ollama numa 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 que muitas pessoas esquecem até um modelo que carregou ontem se recusar a carregar hoje.

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

Um ficheiro de modelo é quase totalmente composto por pesos. Cada peso é armazenado com um determinado número de bits. A quantização consiste em armazená-los com menos bits do que a precisão usada no treino. Isto causa uma pequena perda de 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, quase ninguém usa a precisão original num VPS. Estas são as quantizações que encontrará na prática, com o número médio real de bits por peso:

• Q8_0 armazena cerca de 8.5 bits por peso, ou aproximadamente 1.1 GB por mil milhões de parâmetros.
• Q6_K armazena cerca de 6.6 bits, ou aproximadamente 0.83 GB por mil milhões.
• Q5_K_M armazena cerca de 5.7 bits, ou aproximadamente 0.71 GB por mil milhões.
• Q4_K_M armazena cerca de 4.8 bits, ou 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 sistema limitado pela memória: a perda de qualidade em relação a 8 bits é pequena na maioria das tarefas, e o ficheiro tem quase metade do tamanho. Abaixo de 4 bits, a perda aumenta rapidamente. Por isso, um 70B comprimido para 2 bits normalmente responde pior do que um 32B a 4 bits da mesma geração. Quando a memória é limitada, reduza uma classe de tamanho antes de baixar 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 de parâmetros. Os ficheiros GGUF reais ficam a poucos por cento desse valor, porque as camadas de embedding e de saída são mantidas com uma precisão superior à do restante modelo. Um modelo 3B a 4 bits ocupa cerca de 1.8 GB. Um 8B ocupa 4.8 GB. Um 32B ocupa 19.2 GB, e um 70B ocupa 42 GB.

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

O cache KV (cache de key-value, 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 de acordo com o comprimento de contexto solicitado e aumenta linearmente com esse comprimento.

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

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

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

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

Um modelo residente permanece na RAM até ser descarregado

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

ollama ps
ollama stop qwen3:4b

ollama ps apresenta os modelos residentes, com uma coluna SIZE que mostra quanta memória cada modelo ocupa e uma coluna UNTIL que mostra quando expira. Para fixar um modelo permanentemente, 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 dez minutos depois. O modelo continua listado, que é precisamente o objetivo: mantém essa RAM ocupada, esteja ou não alguém a utilizá-la. 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 considerando o modelo e a aplicação, não apenas o modelo. Fixar um modelo na memória aborda o compromisso com a latência de um arranque a frio.

O que pode ser executado num VPS de 4 GB

Reserve cerca de 1 GB para o sistema operativo e o servidor do modelo. Isso deixa aproximadamente 3 GB. Nesse limite, cabe um modelo de 1B a 4B com 4 bits, usando o contexto predefinido de 4096 tokens. Em agosto de 2026, essa classe 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 o tamanho, 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 instrução adicional resolve essa limitação.

O problema típico nesta faixa é o swap. Se o modelo não couber, 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 significam que o modelo é demasiado grande para este plano.

O que é possível executar numa VPS com 8 a 16 GB

É neste ponto que um modelo auto-hospedado se torna geralmente útil. Com 8 GB, é possível 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, é possível 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 cerca de 1.5 a 3.5. Uma pessoa lê aproximadamente 5 a 10 tokens por segundo. Por isso, um modelo 8B numa VPS com CPU dá a sensação de acompanhar 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 superiores numa VPS mostram o comportamento na prática.

O que funciona 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 em 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, interprete a velocidade de forma realista. Um modelo 32B em CPU processa cerca de 0.6 a 1.5 tokens por segundo, e um modelo 70B processa de 0.2 a 0.5. Uma resposta com 500 tokens desse modelo 70B demora cerca de vinte minutos. Nesse ritmo, o pedido normalmente falha antes de o modelo terminar, porque algum timeout do cliente ou proxy à frente do Ollama é acionado primeiro. É daí que vem o erro de prazo de contexto excedido. Estas são ferramentas para processamento em lote. Envie-lhes uma fila de documentos durante a noite e a velocidade deixa de ser relevante. Coloque-as atrás de uma janela de chat e ela passa a ser muito importante.

O encaminhamento de mixture of experts altera este cálculo, e é o único detalhe de arquitetura que vale a pena aprender. Um modelo MoE envia cada token apenas por uma pequena parte dos seus pesos. Um modelo com 30B de parâmetros totais e 3B de parâmetros ativos por token precisa da memória de um modelo 30B e gera a uma velocidade próxima da de um modelo denso 3B, porque cada token lê apenas os experts ativos. Numa máquina com 32 GB, um MoE com estas características é 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 é a velocidade da inferência na CPU, na prática?

Gerar um token exige ler todos os pesos ativos da memória uma vez. Não há como evitar isso. Por isso, a velocidade de geração numa CPU é determinada pela largura de banda da memória, e 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. Uma VPS partilhada pequena fornece realisticamente 10 a 25 GB por segundo entre as vCPUs. Assim, 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 comum de VPS. Não são um benchmark de uma máquina específica. O seu valor depende da geração da memória, do número de canais no host e da quantidade de vizinhos que competem pelos mesmos recursos. Meça o seu próprio valor 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 os tokens por segundo explica como obter um valor adequado para comparação.

Há dois resultados que surpreendem muitas pessoas. Adicionar vCPUs deixa rapidamente de ajudar, porque, a partir de cerca de 8 núcleos, os núcleos adicionais ficam à espera da memória em vez de executarem operações aritméticas. Além disso, num plano partilhado, o mesmo comando devolve valores diferentes de hora para hora. Isso é tempo de CPU roubado por um vizinho com carga elevada, e não algo que tenha configurado incorretamente.

Ler o prompt é uma tarefa diferente de gerar a resposta. O processamento do prompt é limitado pelo poder de processamento. Por isso, escala com o número de núcleos e é a área em que uma GPU obtém a maior vantagem. Um documento longo demora minutos a ser lido por uma CPU e segundos por uma GPU. Esse é o primeiro limite encontrado ao apontar um agente de programação para um modelo que aloja, porque cada interação reenvia o contexto do ficheiro e as definições das ferramentas antes de ser devolvido um único token da resposta.

O que muda quando se 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 apresenta 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 parte executada na CPU determina o ritmo, porque cada token continua à espera dessas camadas. Assim, um modelo com um quarto das camadas na CPU funciona muito mais perto da velocidade da CPU do que da velocidade da GPU. Se vir uma divisão que não pretendia, reduza primeiro o comprimento do contexto. Normalmente, é a cache que fez o modelo ultrapassar o limite.

A simultaneidade é outro motivo para escolher uma configuração maior. Os pesos são partilhados entre pedidos simultâneos, mas cada pedido ativo precisa da sua própria cache KV. Por isso, 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 autoalojado explica até onde esse limite chega.

Saber se vale a pena alugar a GPU também é uma questão de aritmética. Tudo depende do número de tokens que 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 pode alojar localmente

Existem aqui duas barreiras diferentes, e é útil saber qual delas está a encontrar.

A primeira são os pesos fechados. Os modelos comerciais de fronteira não são distribuídos, por isso não existe um ficheiro para descarregar e nenhuma quantidade de RAM altera esse facto. Pode alojar localmente tudo o que os envolve: a interface, a camada de retrieval, o ciclo do agente e os logs. O próprio modelo continua a ser uma API remota. Se pode alojar Claude localmente explica este ponto em detalhe.

A segunda são os pesos abertos que são simplesmente demasiado grandes. Os maiores releases abertos usam arquiteturas de mixture of experts com centenas de milhares de milhões de parâmetros totais. Aplica-se a mesma regra: um modelo com 400B parâmetros totais a 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 alojar localmente um modelo da classe Kimi explica os requisitos reais. A mesma separação aparece na própria biblioteca do Ollama, onde GLM 5.2 está listado apenas como modelo cloud e um modelo irmão muito mais pequeno é o que efetivamente é descarregado para uma VPS.

A distinção prática é esta: faça self-hosting quando a carga é estável e os dados não devem sair do servidor. Compre tokens quando a carga é variável ou quando precisa realmente da qualidade de resposta dos modelos de fronteira.

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, não na coluna total, porque total inclui a 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 valor restante por 0.6 para obter o maior número de parâmetros, em milhares de milhões, que pode suportar a 4 bits. Depois, 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

De quanta RAM preciso para executar um modelo 8B?

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

Porque é que o meu modelo é lento, embora o VPS tenha muitos vCPUs?

Porque a geração é limitada pela largura de banda da memória, não pelo número de núcleos. Cada token exige carregar todo o conjunto de pesos ativo a partir da RAM. Assim que alguns núcleos saturam os canais de memória, os restantes ficam à espera. A outra causa comum é o 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 processada a partir do disco, o que custa muito mais do que seria 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. Por isso, 8192 tokens ocupam 1 GB e 131072 tokens ocupam 16 GB. O cache é alocado quando o modelo é carregado, não quando a conversa cresce. Portanto, pedir um contexto de 128k reserva essa memória imediatamente, mesmo que cada prompt enviado tenha 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 comprimido para 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 chegam a centenas de milhares de milhões de parâmetros. Com 4 bits, isso significa mais de 200 GB de RAM antes de considerar o 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. Nessa situação, um modelo pequeno, restrito e bem orientado muitas vezes iguala um modelo geral. Se precisar de qualidade de nível frontier, compare o custo da API com o do hardware antes de comprar qualquer um dos dois.