Como rodar 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, primeiro é necessário usar uma tag de modelo existente. Em 4 August 2026, a biblioteca Ollama não tem nenhuma entrada qwen3.8. A tag 27B lançada mais próxima é qwen3.6:27b: 27.8 billion parameters, 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 July 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 com 8 GB e 16 GB. Numa VPS comum com DDR4 de dois canais, o limite é aproximadamente 3 tokens por segundo, uma velocidade inferior à 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 informa 27.8B parameters, e 27.8 é fácil de recordar mais tarde como 3.8. Também existe um qwen3.5:27b, a mesma build Q4_K_M da versão anterior. Consulte a lista atualizada antes de copiar qualquer comando, na página de tags qwen3.6 do Ollama. Se uma versão qwen3.8 real for lançada posteriormente, os cálculos aqui continuarão 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 produz um erro claro. Por isso, é rápido confirmar a tag diretamente no servidor.

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 apresenta a arquitetura, a quantidade de parâmetros, o tamanho do contexto e a quantização da tag que está efetivamente instalada. Se a linha de parâmetros indicar 27.8B e a linha de quantização indicar Q4_K_M, a build corresponde à utilizada 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 (mistura de especialistas) e têm um comportamento muito diferente em CPU. Estes modelos são abordados mais 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 ocupa uma linha. Bytes dos pesos = parâmetros * bits por peso / 8. Com 4 bits exatos, 27.8 mil milhões de parâmetros ocupariam 13.9 GB. A tag Q4_K_M disponibilizada tem 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 com a largura nominal. Os tensores que perdem mais qualidade com a compressão são mantidos a 5 ou 6 bits, e as camadas de embedding dos 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, e não a 16 fixos, porque o ficheiro também contém metadados e uma tabela de embedding em precisão total.

Não existe uma tag Q5_K_M 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, para 30 GB. Num sistema apenas com CPU, essa duplicação duplica o tráfego de memória por token e, por isso, reduz aproximadamente para metade o número de tokens por segundo. Por esse motivo, Q4_K_M é a opção predefinida adequada neste caso.

O custo do cache KV à medida que o contexto cresce

Os pesos têm um custo fixo. O cache KV (cache de chaves e valores, o estado de atenção que o modelo mantém para cada token que já viu) cresce linearmente com o tamanho do contexto. É aí que a maioria dos utilizadores 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 chave/valor com GQA (grouped-query attention) 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 nestes cálculos para a sua máquina. Carregue o modelo e consulte a coluna SIZE de ollama ps. Ela apresenta os pesos, o cache e a sobrecarga como um único valor.

É por isso que o contexto de 256K indicado no model card é uma capacidade anunciada, não um plano de utilização. Preenchê-lo em f16 consumiria 64 GB de cache além dos pesos, numa máquina que já reservou 17 GB para os pesos. O Ollama não disponibiliza por predefinição toda a janela. Carrega uma janela muito menor, que pode aumentar deliberadamente com OLLAMA_CONTEXT_LENGTH. Aumente-a gradualmente e consulte ollama ps depois de cada alteração.

Duas definições reduzem o cache para metade ou menos. OLLAMA_KV_CACHE_TYPE=q8_0 armazena o cache com 8 bits em vez de 16, reduzindo o consumo com 32k tokens de 8 GB para 4 GB. Esta opção precisa de flash attention. Por isso, defina também OLLAMA_FLASH_ATTENTION=1 e confirme a redução em ollama ps, em vez de presumir que foi aplicada. OLLAMA_NUM_PARALLEL=1 é igualmente importante. O Ollama pode processar vários pedidos em simultâneo, e cada slot recebe a sua própria parte do contexto. Por isso, manter o paralelismo no valor predefinido aumenta silenciosamente o cache que tinha previsto.

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 juntamente com os 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. O valor zero significa que os próprios pesos não cabem, portanto não cabe contexto algum.

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 esse facto. 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 um iowait elevado e produz bem menos de um token por segundo.

32 GB é o ponto de entrada. Os pesos ocupam 17 GB e sobram aproximadamente 13 GB. 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. 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 opção.

Qual é a velocidade da inferência de CPU numa VPS?

Gerar um token de um modelo denso implica 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 núcleos, 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
  }
]

Esses valores são limites máximos, não medições. Na prática, a saída fica aproximadamente entre 50 e 70 por cento 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, portanto espere cerca de 2. Uma máquina com DDR5-4800 de dois canais tem um limite de 4.5, portanto espere cerca de 3.

As linhas referentes 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 completo. A largura de banda da memória é um recurso de todo o host, partilhado por todos os tenants dessa máquina. Por isso, uma fração com 8 vCPUs não inclui doze canais de largura de banda exclusivos. Os guias centrados em GPU ignoram completamente este ponto. É também a razão pela qual dois planos VPS com o mesmo número de vCPUs podem diferir por um fator de três no mesmo modelo.

Mais vCPUs deixam de ajudar rapidamente pela mesma razão. Quando os núcleos 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 núcleos físicos, faça uma medição e depois experimente metade desse valor. Em muitos planos partilhados, a definição mais baixa é mais rápida.

O processamento do prompt comporta-se de forma diferente. O prefill, que é a passagem pelo 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 núcleos. Na prática, há uma pausa longa antes do início da saída quando o prompt é grande, seguida pela taxa estável e lenta indicada acima. Meça ambas as fases separadamente com --verbose. Este comando mostra um prompt eval rate e um eval rate para cada pedido.

Se o modelo denso 27B for simplesmente demasiado lento, verifique as tags qwen3.6:35b-a3b antes de desistir da CPU. Essas tags ativam aproximadamente 3 mil milhões de parâmetros por token, em vez de todos os 27.8 mil milhões. Assim, 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. Ollama e llama.cpp expõem controlos de otimização de CPU diferentes 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 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 trabalha na ordem das dezenas.

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

A comparação de custos é menos evidente do que parece. Um VPS de 64 GB é faturado em todas as horas do mês, esteja o modelo carregado ou não, enquanto uma instância com GPU é faturada apenas durante as horas em que a mantém em execução. Se a utilização real for de duas horas por dia, a GPU alugada pode ser simultaneamente mais rápida e mais barata. Calcule primeiro o seu duty cycle 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 Ollama quando serve pedidos concorrentes numa GPU porque faz o batching corretamente.

Existe uma terceira opção que é frequentemente esquecida. Mantenha o modelo 27B na CPU para tarefas em lote e coloque um modelo de API alojado à frente do caminho interativo. Nada obriga um único modelo a servir 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 com um utilizador dedicado ollama.

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

ollama --version deve apresentar 0.32.5 ou uma versão posterior. Verifique free -g antes de descarregar qualquer coisa. Se a coluna total na linha Mem indicar menos de 32, pare aqui e escolha um modelo mais pequeno. Descarregar 17 GB que não consegue executar desperdiça uma hora e muito espaço em disco.

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

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."

O resultado de --verbose é a medição que procurava. 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. Por isso, OLLAMA_KEEP_ALIVE=60m está definido: num CPU, recarregar 17 GB do disco em cada pedido custa mais do que o próprio pedido.

Enquanto o modelo estiver carregado, verifique o consumo a partir de um segundo terminal.

ollama ps

A coluna SIZE mostra o consumo real de memória, incluindo a cache KV. Deve ficar próxima do tamanho dos pesos somado ao valor correspondente ao seu comprimento de contexto no gráfico KV. Com 8192 tokens e uma cache de 8 bits, conte com cerca de um gigabyte adicional aos pesos, em comparação com 2 GB se a cache permanecesse em f16. A coluna PROCESSOR deve apresentar 100% CPU. Se apresentar outro valor, algo ocupou uma GPU e os valores de velocidade deste guia não descrevem o seu servidor.

Modos de falha e as strings exatas que verá

O modelo recusa-se a carregar. O Ollama apresenta uma linha que indica os dois 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 a situação. Reduza o comprimento do contexto, mude para uma tag menor ou escolha um plano com mais recursos.

O processo desaparece a meio de uma resposta. O cliente não apresenta informações úteis 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 anterior ao carregamento foi bem-sucedida, mas a cache cresceu além da estimativa durante uma conversa longa. Reduza o comprimento 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 este resultado, tal como qualquer erro de digitação no número da versão. Confirme a tag na página da biblioteca antes de atribuir o problema à rede.

Tudo funciona, mas o desempenho é insuportavelmente lento. Menos de um token por segundo num sistema com RAM suficiente aponta para paginação, não para falta de capacidade de cálculo. 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 elevado e constante em wa, sem atividade de swap, significa que os pesos mapeados em memória estão a ser lidos novamente a partir do disco. Isto indica que não cabem realmente na memória disponível.

O primeiro token demora 30 segundos e depois a saída acelera. Isto é o prefill e é normal. Um system prompt longo tem de ser processado em todos os pedidos que não aproveitam a cache. Reduza o system prompt antes de ajustar qualquer outro parâmetro.

Para que serve realmente um modelo 27B apenas com CPU

Defina as expectativas com base nos números, não na esperança. A uma velocidade de dois a quatro tokens por segundo, uma resposta com 500 tokens demora entre dois e quatro minutos. Isto não é utilizável para chat, mas funciona perfeitamente numa fila. A sumarização de documentos, a atribuição em massa de etiquetas, a extração de campos de um conjunto pendente de ficheiros e a revisão de código sem supervisão toleram esta latência, porque nada fica à espera da resposta.

O argumento da privacidade é o principal. O modelo é executado em hardware que aluga e controla, nenhum pedido sai da máquina e não existe uma cobrança por token. Isto é muito importante para dados regulamentados, mesmo a três tokens por segundo. Compare esta opção de forma realista com a alternativa: a hospedagem própria de um modelo de escala frontier exige uma ordem de grandeza mais de hardware, e um modelo 27B em CPU é o ponto mais barato dessa curva em que o resultado ainda vale a pena ler.

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 de firewall que este guia pressupõe que já configurou. 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 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 o número de parâmetros 27.8B, memorizado como um número de versão. Consulte https://ollama.com/library/qwen3.6/tags para ver a lista atual e execute 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 conter os pesos, e o swap não ajuda porque o ficheiro é mapeado em memória e o kernel volta simplesmente a lê-lo do disco a cada token. 64 GB deixa margem para contextos longos ou para pesos Q8_0 com 30 GB.

Quantos tokens por segundo me dará um modelo 27B na CPU?

Divida a largura de banda da memória pelo tamanho dos pesos e considere depois 50 a 70 por cento desse valor. Uma VPS com DDR4-3200 de dois canais tem um limite próximo de 3 tokens por segundo e fornece cerca de 2. Um servidor com DDR5-4800 de dois canais tem um limite próximo de 4.5 e fornece 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, por isso precisa de um plano de 64 GB e move quase o dobro da memória por token, o que reduz aproximadamente para metade os 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, porque isso altera as capacidades do modelo e não apenas a forma como formula as respostas.

Quando é mais barato alugar uma GPU do que usar 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 ser melhor tanto em velocidade como em custo. O processamento contínuo de lotes com baixa prioridade é o cenário em que a VPS sempre ativa compensa.