Como rodar o Qwen 3.8 27B numa VPS com Ollama

É possível executar o Qwen 3.8 27B numa VPS sem GPU?

Para executar o Qwen 3.8 27B numa VPS, precisa primeiro de uma tag de modelo existente. Em 4 de agosto de 2026, a biblioteca Ollama não tinha nenhuma entrada qwen3.8. A tag 27B lançada mais próxima é qwen3.6:27b: 27.8 bilhões de parâmetros, quantização Q4_K_M e licença Apache 2.0. Todos os comandos e números abaixo usam essa tag no Ollama v0.32.5, publicado em 27 de julho de 2026.

A resposta curta é sim, numa VPS com 32 GB ou mais, mas com baixa velocidade. Um modelo denso 27B em Q4 precisa de cerca de 17 GB de RAM apenas para os pesos, antes de armazenar um único token de contexto. Isso exclui completamente os planos de 8 GB e 16 GB. Numa VPS comum com DDR4 de dois canais, o limite é de aproximadamente 3 tokens por segundo. Isso é mais lento do que a velocidade de leitura da maioria das pessoas.

De onde vem o 3.8? Muito provavelmente, da contagem de parâmetros. A página do Ollama para qwen3.6:27b indica 27.8B parâmetros, e é fácil lembrar mais tarde 27.8 como 3.8. Também existe um qwen3.5:27b, a mesma compilação Q4_K_M da versão anterior. Consulte a lista atual antes de copiar qualquer comando, na página da tag qwen3.6 do Ollama. Se uma versão qwen3.8 real for lançada mais tarde, os cálculos continuam válidos, porque dependem da contagem de parâmetros e dos bits por peso, não do número da versão.

Qual tag do Ollama deve ser obtida e como verificar

Obter uma tag que não existe gera um erro claro, por isso é rápido resolver esta questão diretamente no servidor. Uma tag existente ainda pode não ser executável localmente. É isso que costuma causar problemas com GLM 5.2, listado na biblioteca, mas disponibilizado apenas pela cloud do Ollama.

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show mostra a arquitetura, o número de parâmetros, o tamanho do contexto e a quantização da tag que tem instalada. Se a linha dos parâmetros mostrar 27.8B e a linha da quantização mostrar Q4_K_M, tem a compilação usada neste guia. A biblioteca também disponibiliza qwen3.6:27b-q8_0 e qwen3.6:27b-bf16 com os mesmos pesos em maior precisão, além de um conjunto de tags 35b-a3b que são modelos MoE (mixture of experts) e têm um comportamento muito diferente na CPU. Mais detalhes abaixo.

Contagem de parâmetros vezes bytes por peso

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

A fórmula cabe numa linha. Bytes dos pesos = parâmetros * bits por peso / 8. Com 4 bits exatos, 27.8 bilhões de parâmetros ocupariam 13.9 GB. A tag Q4_K_M publicada ocupa 17 GB, o que corresponde a 4.89 bits por peso na prática.

Essa diferença não é um erro. Os formatos K-quant não armazenam todos os tensores na largura nominal. Os tensores que mais perdem qualidade com a compressão são mantidos em 5 ou 6 bits, e as camadas de embedding de tokens e de saída normalmente permanecem em Q6_K ou Q8_0. O nome do formato representa uma média, e essa média fica próxima de 4.9. O mesmo efeito aparece no outro extremo da escala: 56 GB para BF16 correspondem a 16.1 bits por peso, em vez de 16 fixos, porque o ficheiro também inclui metadados e uma tabela de embedding em precisão total.

Q5_K_M não tem uma tag publicada para este modelo, por isso a linha de 19.8 GB é calculada com os habituais 5.7 bits por peso desse formato, em vez de ser medida. Q8_0 quase duplica o tamanho de Q4, chegando a 30 GB. Num servidor apenas com CPU, essa duplicação duplica o tráfego de memória por token e, por isso, também reduz aproximadamente para metade a quantidade de tokens por segundo. Por esse motivo, Q4_K_M é a opção predefinida correta neste caso. Se quiser avaliar o impacto na qualidade, em vez do impacto na memória, uma comparação mais detalhada entre Q4, Q8 e fp16 mostra em que ponto a saída começa efetivamente a degradar-se.

O custo da cache KV à medida que o contexto cresce

Os pesos têm um custo fixo. A cache KV (cache de chaves e valores, o estado de atenção que o modelo mantém para cada token já processado) cresce de forma linear com o tamanho do contexto. É aí que a maioria das pessoas fica sem RAM.

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

Estes valores assumem a arquitetura que a Qwen tem usado nos seus modelos densos recentes desta classe de tamanho: 64 camadas, 8 cabeças de chaves/valores com GQA (atenção por consultas agrupadas) e uma dimensão de cabeça de 128. Isso corresponde a 256 KiB por token em f16, ou 8 GB com 32k tokens e 32 GB com 128k. Não confie apenas nos meus cálculos para a sua máquina. Carregue o modelo e consulte a coluna SIZE de ollama ps, que apresenta os pesos, a cache e a sobrecarga como um único valor.

É por isso que o contexto de 256K indicado no model card é mais um valor de destaque do que um plano prático. Preenchê-lo em f16 custaria 64 GB de cache além dos pesos, numa máquina que já gastou 17 GB com os pesos. O Ollama não disponibiliza por predefinição a janela completa. Carrega uma janela muito menor, que pode aumentar deliberadamente com OLLAMA_CONTEXT_LENGTH. Essa variável aplica-se a todo o servidor, mas não é o único mecanismo de controlo. Definir num_ctx no pedido individual permite manter uma predefinição económica para os restantes pedidos, enquanto um trabalho longo recebe uma janela maior. Aumente o valor gradualmente e consulte ollama ps depois de cada alteração.

Duas definições reduzem a cache para metade ou menos. OLLAMA_KV_CACHE_TYPE=q8_0 armazena a cache a 8 bits em vez de 16, reduzindo o consumo com 32k tokens de 8 GB para 4 GB. Esta opção requer flash attention. Por isso, defina também OLLAMA_FLASH_ATTENTION=1 e confirme a redução em ollama ps, em vez de presumir que a alteração foi aplicada. OLLAMA_NUM_PARALLEL=1 é igualmente importante. O Ollama pode atender vários pedidos em simultâneo, e cada slot recebe a sua própria parte do contexto. Assim, deixar o paralelismo na predefinição multiplica silenciosamente a cache que tinha previsto. Se mais de uma pessoa usar esta máquina, é aí que começam os problemas. O número de utilizadores simultâneos que um modelo self-hosted consegue atender é determinado pelos slots de cache e pelo tamanho da fila muito antes de ser determinado pelo número de cores.

O que cabe em 8, 16, 32 e 64 GB de RAM

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

Leia os dois números como milhares de tokens de contexto que cabem além dos pesos, com cache f16, numa VPS Linux sem interface gráfica, com cerca de 1.5 GB reservados para o sistema operativo e uma pequena margem adicional. Zero significa que nem os próprios pesos cabem e, portanto, nada cabe.

8 GB e 16 GB não são casos limítrofes. 17 GB de pesos não cabem em 16 GB de RAM, e nenhuma definição de contexto altera isso. Adicionar swap também não resolve o problema. O Ollama mapeia o ficheiro GGUF na memória. Quando as páginas residentes excedem a RAM, o kernel começa a expulsá-las e a lê-las novamente. Cada token passa então a transferir gigabytes do disco. O servidor fica com iowait elevado e produz bem menos de um token por segundo.

32 GB é o ponto de entrada. Os pesos ocupam 17 GB e ficam aproximadamente 13 GB disponíveis. Isso suporta cerca de 32k tokens de contexto f16 com alguma margem. Os pesos Q8_0, com 30 GB, não cabem de todo neste nível.

64 GB oferece uma margem confortável. O Q4 deixa espaço para cerca de 128k tokens de contexto, e os pesos Q8_0 cabem com aproximadamente 64k tokens disponíveis depois deles. Antes de pagar por 64 GB para usar Q8, tenha claro o que está a comprar: uma saída ligeiramente melhor, à metade da velocidade, numa máquina que já era lenta. Para quase toda a gente, Q4 com um contexto maior é a melhor escolha.

Quão rápida é a inferência de CPU numa VPS?

Gerar um token de um modelo denso significa ler todos os pesos da memória uma vez. Não apenas alguns. Todos. Por isso, o limite de velocidade não é o número de cores, mas a largura de banda da memória dividida pelo tamanho dos pesos. Em Q4, isso corresponde a 17 GB de tráfego de memória por token.

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

Estes valores são limites máximos, não medições. A saída real fica aproximadamente entre 50 e 70% do valor apresentado, porque a latência da memória e o prefetching imperfeito impedem atingir o pico teórico. Uma VPS com DDR4-3200 de dois canais tem um limite de 3 tokens por segundo, por isso espere cerca de 2. Uma máquina com DDR5-4800 de dois canais tem um limite de 4.5, por isso espere cerca de 3.

As linhas correspondentes a servidores maiores exigem uma ressalva. Uma plataforma EPYC com doze canais tem 460.8 GB/s e um limite de 27.1 tokens por segundo, mas não está a alugar um EPYC inteiro. A largura de banda da memória é um recurso de todo o host, partilhado por todos os tenants dessa máquina, por isso uma fatia com 8 vCPUs não inclui doze canais de largura de banda exclusivos. Os guias focados em GPU ignoram completamente este ponto, que explica por que motivo dois planos VPS com o mesmo número de vCPUs podem ter uma diferença de três vezes no mesmo modelo.

Mais vCPUs deixam de ajudar rapidamente pela mesma razão. Quando os cores solicitam dados mais depressa do que o controlador de memória consegue fornecê-los, as threads adicionais apenas acrescentam overhead de escalonamento. Defina OLLAMA_NUM_THREAD para o número de cores físicos, faça uma medição e depois experimente metade desse número. Em muitos planos partilhados, o valor mais baixo é mais rápido.

O processamento do prompt comporta-se de forma diferente. O prefill, ou seja, a passagem pelo seu input antes de aparecer o primeiro token, é limitado pelo processamento e não pela largura de banda, por isso escala com o número de cores. Na prática, ocorre uma pausa longa antes do início da saída quando o prompt é grande, seguida pela velocidade estável e baixa indicada acima. Meça as duas fases separadamente com --verbose, que apresenta um prompt eval rate e um eval rate para cada pedido.

Se o modelo denso de 27B for simplesmente demasiado lento, consulte as tags qwen3.6:35b-a3b antes de desistir da CPU. Estas ativam aproximadamente 3 mil milhões de parâmetros por token, em vez dos 27.8 mil milhões completos, por isso o tráfego de memória por token diminui quase uma ordem de grandeza, embora o ficheiro em disco seja maior. A troca é entre o consumo de RAM e a velocidade. A escolha do runtime também é importante neste caso, e Ollama e llama.cpp expõem diferentes controlos de otimização da CPU sobre o mesmo código de inferência subjacente.

Quando alugar uma hora de GPU

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

A mesma fórmula aplicada à largura de banda de memória de GPU publicada produz uma resposta de outra categoria. Uma placa de consumo de 24 GB tem um limite de 59 tokens por segundo com estes pesos. Uma placa atual de centro de dados chega a 197. Não é uma diferença que se resolva ajustando o número de threads. A placa executa a memória a 1008 GB/s, enquanto o seu VPS executa a dezenas de GB/s.

Por isso, estabeleça o limite com base na carga de trabalho, não na preferência. A inferência em CPU é a escolha certa quando o trabalho é assíncrono e ninguém fica à espera do resultado: resumir um conjunto de documentos durante a noite ou executar um trabalho de classificação noturno enquanto dorme. Alugue uma GPU assim que houver uma pessoa à espera da resposta ou assim que chegarem pedidos a um ritmo superior a um a cada 30 segundos, porque uma máquina apenas com CPU não tem margem para batching e a fila simplesmente cresce.

A comparação de custos é menos evidente do que parece. Um VPS com 64 GB é faturado todas as horas do mês, esteja o modelo carregado ou não, enquanto uma instância com GPU só fatura as horas em que a mantém em execução. Se o uso real for de duas horas por dia, a GPU alugada pode ser simultaneamente mais rápida e mais barata. Calcule primeiro a percentagem de tempo de utilização e só depois compare os preços. Escolher um VPS com GPU explica o que deve verificar na própria instância, e vLLM supera o Ollama quando serve pedidos concorrentes numa GPU porque agrupa os pedidos corretamente.

Existe uma terceira opção que é frequentemente esquecida. Mantenha o 27B na CPU para trabalhos em lote e coloque um modelo de API alojada à frente do caminho interativo. Nada exige que um único modelo sirva os dois casos.

Instale o Ollama e meça o seu próprio servidor

O script de instalação é o oficial e configura um serviço systemd executado pelo utilizador dedicado ollama.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

ollama --version deve mostrar 0.32.5 ou uma versão posterior. Verifique free -g antes de transferir qualquer conteúdo. Se a coluna total da linha Mem indicar um valor inferior a 32, pare aqui e escolha um modelo menor, porque transferir 17 GB que não consegue executar desperdiça uma hora e muito espaço em disco.

Defina as opções do runtime numa substituição do systemd, não na sua shell. O modelo é executado dentro do serviço e, por isso, não vê o ambiente da sua sessão interativa.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

A saída de --verbose é a medição que procura. eval rate é o número de tokens por segundo durante a geração. prompt eval rate é a velocidade de prefill. load duration é o tempo necessário para ler os pesos do disco, razão pela qual OLLAMA_KEEP_ALIVE=60m está definido: na CPU, recarregar 17 GB do disco em cada pedido custa mais do que o próprio pedido. O tempo limite predefinido para inatividade é de cinco minutos. É suficientemente curto para que uma fila de processamento em lote, com intervalos entre itens, pague esse custo de carregamento repetidamente. As opções para manter um modelo residente abrangem tanto o campo keep_alive por pedido como a persistência da definição após um reboot.

Enquanto o modelo estiver carregado, verifique a utilização de memória num segundo terminal.

ollama ps

A coluna SIZE mostra a utilização real de memória, incluindo a cache KV, e deve ficar próxima da soma dos pesos com a linha correspondente ao seu comprimento de contexto no gráfico KV. Com 8192 tokens e uma cache de 8 bits, espere cerca de um gigabyte adicional aos pesos, em comparação com 2 GB se a cache permanecesse em f16. A coluna PROCESSOR deve mostrar 100% CPU. Se mostrar qualquer outra coisa, algum processo está a utilizar uma GPU e os valores de velocidade deste guia não descrevem o seu servidor.

Modos de falha e as mensagens exatas que verá

O modelo recusa-se a carregar. O Ollama imprime uma linha que identifica ambos os valores, no formato model requires more system memory (18.6 GiB) than is available (15.2 GiB). Esta é a falha preferível, porque o Ollama verificou os requisitos antes de alocar memória, em vez de deixar o kernel resolver o problema. Reduza o tamanho do contexto, mude para uma tag menor ou passe para um plano com mais recursos.

O processo desaparece a meio de uma resposta. O cliente não mostra nada útil e journalctl -u ollama -n 50 mostra que o serviço está a reiniciar. Execute dmesg -T | tail. Uma linha com Out of memory: Killed process ... (ollama) significa que o OOM killer do kernel terminou o processo. Isto acontece quando a verificação antes do carregamento passa, mas a cache ultrapassa a estimativa durante uma conversa longa. Reduza o tamanho do contexto.

O pull falha imediatamente. Error: pull model manifest: file does not exist significa que a tag não existe na biblioteca. Executar qwen3.8:27b produz exatamente esta mensagem, tal como qualquer erro no número da versão. Confirme a tag na página da biblioteca antes de atribuir o problema à rede.

Tudo funciona, mas fica insuportavelmente lento. Menos de um token por segundo num sistema com RAM suficiente indica paginação, não falta de capacidade de processamento. Execute vmstat 1 durante a geração. Um valor diferente de zero na coluna si ou so significa que o kernel está a usar swap. A correção é reduzir o contexto ou carregar menos modelos. Um valor persistentemente elevado em wa sem atividade de swap significa que os pesos mapeados em memória estão a ser lidos novamente do disco. Isto indica que não cabem realmente na memória.

O primeiro token demora 30 segundos e depois a saída acelera. Isto é o prefill e é normal. Um prompt de sistema longo tem de ser processado em cada pedido que não utiliza a cache. Por isso, reduza o prompt de sistema antes de ajustar qualquer outra configuração.

Para que serve realmente um modelo 27B apenas com CPU

Defina as expectativas com base nos números, não na esperança. A dois a quatro tokens por segundo, uma resposta de 500 tokens demora entre dois e quatro minutos. Isto não é utilizável para chat, mas funciona perfeitamente numa fila. Um modelo que raciocina antes de responder torna esta conta ainda pior, porque os tokens de raciocínio ocultos são gerados à mesma velocidade lenta que a resposta. Por isso, ajustar o nível de esforço de raciocínio à tarefa é uma das poucas formas de encurtar uma resposta sem trocar de modelo. O resumo de documentos, a etiquetagem em massa, a extração de campos de um conjunto de ficheiros e a revisão de código sem supervisão toleram esta latência, porque não há ninguém à espera da resposta. A assistência à programação está exatamente no limite. Por isso, atribuir a um agente de programação um modelo que aloja compensa em tarefas de fundo, como mensagens de commit e criação de estruturas de testes, mas não para sugestões inline pelas quais fica à espera.

O argumento da privacidade é o mais importante. O modelo é executado em hardware que aluga e controla, nenhum pedido sai da máquina e não existe um custo por token. Isto vale muito para dados regulamentados, mesmo a três tokens por segundo. Compare esta opção de forma honesta com a alternativa: alojar internamente um modelo de escala frontier exige uma ordem de grandeza mais de hardware, e um modelo 27B apenas com CPU é o ponto mais barato dessa curva em que o resultado ainda compensa ser lido.

Para avaliar qualquer uma destas utilizações, precisa de dados estruturados reais. A maioria das APIs públicas de dados exige uma conta antes de permitir sequer medir o débito. O endpoint de demonstração da Strasmore (somos nós que o executamos) responde a SQL apenas de leitura sobre 22 anos de dados do mercado dos EUA, sem chave e sem registo. Um GET para https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 devolve JSON que pode canalizar diretamente para um ciclo de prompts, juntamente com o SQL exato que o produziu. Assim, o modelo tem algo para resumir que pode verificar de forma independente. Os limites são 500 linhas e 20 segundos por chamada, bastante acima do que uma máquina a dois tokens por segundo consegue consumir. A lista completa de colunas está em https://api.strasmore.com/v1/schema.

Se esta for a sua primeira instalação do Ollama, o guia completo para executar o Ollama numa VPS explica a configuração do serviço, a API HTTP e as regras da firewall que este guia pressupõe que já tem. Não exponha a porta 11434 à internet. O Ollama não inclui autenticação própria, por isso qualquer pessoa que consiga aceder à porta pode usar o seu modelo e ler os seus prompts.

FAQ

Existe um modelo Qwen 3.8 27B no Ollama?

Não. Em 4 August 2026, a biblioteca do Ollama não tem o namespace qwen3.8. As tags 27B existentes são qwen3.5:27b e qwen3.6:27b, ambas compilações Q4_K_M de um modelo denso com 27.8 mil milhões de parâmetros. O 3.8 no termo de pesquisa é quase certamente a contagem de 27.8B parâmetros, lembrada como um número de versão. Consulte https://ollama.com/library/qwen3.6/tags para obter a lista atual e faça pull de qwen3.6:27b se quiser o 27B lançado mais recentemente. Uma tag inexistente falha com Error: pull model manifest: file does not exist.

De quanta RAM preciso para executar um modelo Qwen 27B numa VPS?

32 GB é o mínimo prático para Q4_K_M. Os pesos ocupam 17 GB, o sistema operativo precisa de cerca de 1.5 GB e a cache KV acrescenta aproximadamente 1 GB por cada 4000 tokens de contexto em f16. Um plano de 16 GB não consegue sequer alojar os pesos, e a swap não ajuda porque o ficheiro é mapeado na memória e o kernel volta simplesmente a lê-lo do disco a cada token. 64 GB permite usar um contexto longo ou pesos Q8_0 com 30 GB.

Quantos tokens por segundo produz um modelo 27B na CPU?

Divida a largura de banda da memória pelo tamanho dos pesos e considere depois 50 a 70% desse valor. Uma VPS DDR4-3200 de dois canais tem um limite próximo de 3 tokens por segundo e produz cerca de 2. Uma máquina DDR5-4800 de dois canais tem um limite próximo de 4.5 e produz cerca de 3. As plataformas de servidor com mais canais parecem muito melhores no papel, mas a largura de banda da memória é partilhada por todos os tenants no host. Por isso, faça a sua própria medição com ollama run qwen3.6:27b --verbose e leia a linha eval rate.

Devo usar Q4 ou Q8 numa VPS apenas com CPU?

Q4_K_M, em quase todos os casos. Q8_0 ocupa 30 GB, contra 17 GB, pelo que precisa de um plano de 64 GB e move quase o dobro da memória por token. Isto reduz aproximadamente para metade o número de tokens por segundo. A diferença de qualidade entre Q4_K_M e Q8_0 num modelo 27B é pequena para a maioria das tarefas. Use a RAM para um contexto mais longo, pois isso altera o que o modelo consegue fazer, e não apenas a forma como formula as respostas.

Quando é mais barato alugar uma GPU do que uma VPS com muita RAM?

Quando a utilização é baixa ou há uma pessoa à espera. Uma GPU com 24 GB de memória atinge aproximadamente 59 tokens por segundo com estes pesos, contra 2 ou 3 numa VPS típica, e só é faturada durante as horas em que está em execução. Uma VPS com 64 GB é faturada durante todo o mês, esteja o modelo carregado ou não. Calcule quantas horas por dia realmente precisa de gerar tokens. Com menos de duas ou três horas, o aluguer horário de uma GPU costuma ganhar em velocidade e custo. O processamento contínuo de lotes com baixa prioridade é o cenário em que a VPS sempre ativa compensa.