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 da tag qwen3.8:27b. Em 18 October 2026, a biblioteca do Ollama disponibiliza essa tag para pull local: 27.3 billion parameters, quantização Q4_K_M, licença Apache 2.0, janela de contexto de 256K e um download de 18 GB que inclui um vision projector de cerca de 0.9 GB. O Ollama adicionou o suporte ao Qwen 3.8 27B na v0.32.12, lançada em 14 August 2026, por isso uma instalação mais antiga precisa de ser atualizada primeiro. Em 18 October 2026, a versão estável mais recente é a v0.40.6, publicada em 16 October 2026. Existe uma build v0.40.7, mas apenas como pré-lançamento.

A resposta curta é sim numa VPS com 32 GB ou mais, mas lentamente. 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 é aproximadamente 3 tokens por segundo, o que é mais lento do que a maioria das pessoas lê.

As tags 27B anteriores continuam na biblioteca: qwen3.6:27b e qwen3.5:27b são ambas builds Q4_K_M de tamanho semelhante. O Qwen3.8-27B mantém a arquitetura do Qwen3.6-27B, e os ficheiros de configuração oficiais dos dois modelos apresentam a mesma disposição de camadas, por isso os cálculos de memória abaixo aplicam-se a ambos. Consulte a lista atual antes de copiar qualquer comando, na página da tag qwen3.8 do Ollama. Estes cálculos dependem do número de parâmetros, dos bits por peso e da disposição da atenção, e não do número da versão.

Qual tag do Ollama deve ser obtido e como verificar

Obter um tag que não existe gera um erro claro, por isso é rápido resolver esta questão no próprio servidor. Um tag existente ainda pode não ser executável localmente. É isso que causa problemas com GLM 5.2, listado na biblioteca mas disponibilizado apenas a partir da cloud do Ollama.

ollama --version
ollama pull qwen3.8:27b
ollama show qwen3.8:27b

ollama show mostra a arquitetura, o número de parâmetros, o tamanho do contexto e a quantização do tag que tem efetivamente instalado. Se a linha dos parâmetros indicar 27.3B e a linha da quantização indicar Q4_K_M, tem a compilação usada neste guia. A biblioteca também inclui qwen3.8:27b-q8_0 e qwen3.8:27b-bf16 para os mesmos pesos com maior precisão, variantes 27b-mtp e os tags 27b-nvfp4, 27b-mxfp8, 27b-mlx e 27b-mlx-bf16, que a página de tags identifica como MLX, um formato destinado a Apple Silicon e não a um VPS Linux. Ao contrário de qwen3.6, a entrada qwen3.8 não tem tags 35b-a3b. Esses modelos MoE (mistura de especialistas) continuam em qwen3.6 e comportam-se de forma muito diferente numa CPU. Mais informações abaixo.

Quantidade de parâmetros vezes bytes por peso

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.98,
    "notes": "published tag qwen3.8:27b, language model file"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.5,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 18,
    "bits_per_weight": 5.27,
    "notes": "published tag 27b-nvfp4, MLX build, one file including the vision encoder"
  },
  {
    "label": "Q8_0",
    "size_gb": 29,
    "bits_per_weight": 8.5,
    "notes": "published tag 27b-q8_0, language model file"
  },
  {
    "label": "BF16",
    "size_gb": 55,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16, language model file"
  }
]

A fórmula ocupa uma linha. Bytes dos pesos = parâmetros * bits por peso / 8. Com 4 bits exatos, 27.3 mil milhões de parâmetros ocupariam 13.7 GB. O ficheiro do modelo de linguagem na tag Q4_K_M fornecida tem 17 GB, o que corresponde a 4.98 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 perdem mais qualidade com a compressão recebem mais bits: a listagem de tensores do Ollama para o ficheiro qwen3.8:27b fornecido mostra a camada de saída, as projeções QKV da atenção e algumas projeções down do feed-forward em Q6_K, além dos pequenos tensores de normalização com precisão total de 32 bits, enquanto o embedding de tokens permanece em Q4_K, como acontece com a maior parte do modelo. O nome do formato representa uma média, e essa média fica perto de 5. O mesmo efeito aparece no outro extremo da escala: 55 GB para BF16 correspondem a 16.1 bits por peso, e não a 16 fixos. Nesse caso, o embedding de tokens está em BF16, como todo o restante, e o pequeno excesso vem dos metadados do ficheiro, dos tensores de normalização mantidos em 32 bits e do tamanho apresentado, arredondado ao gigabyte mais próximo.

Reserve memória para a tag completa, não apenas para o ficheiro do modelo de linguagem. Cada tag GGUF de qwen3.8:27b também inclui um projetor de visão com cerca de 0.9 GB, razão pela qual a tag Q4_K_M é apresentada com 18 GB.

Não existe uma tag Q5_K_M publicada para este modelo. Por isso, a linha de 19.5 GB é calculada com os habituais 5.7 bits por peso desse formato, em vez de ser medida. O Q8_0 quase duplica o Q4, chegando a 29 GB. Num sistema apenas com CPU, essa duplicação custa o dobro do tráfego de memória por token e reduz aproximadamente para metade o número de tokens por segundo. Por esse motivo, o Q4_K_M é a opção predefinida adequada neste caso. Se pretende avaliar a qualidade, e não apenas o consumo de 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 que já viu) cresce linearmente com o comprimento do contexto. É aí que a maioria das pessoas fica sem RAM.

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

Estes valores vêm do próprio ficheiro de configuração do modelo. O Qwen3.8-27B, tal como o Qwen3.6-27B, é um modelo de atenção híbrida. Apenas 16 das suas 64 camadas usam atenção completa e mantêm uma cache que cresce com cada token. Essas camadas têm 4 cabeças de chave/valor com GQA (atenção de consultas agrupadas) e uma dimensão de cabeça de 256. As outras 48 camadas usam atenção linear (Gated DeltaNet) e mantêm um estado de tamanho fixo. Pelos meus cálculos, esse estado ocupa cerca de 150 MB por slot de conversa, independentemente do tamanho do contexto. Isso corresponde a 64 KiB por token em f16, ou 2 GB com 32k tokens e 8 GB com 128k. Não tome os meus cálculos como referência para o seu próprio sistema. Carregue o modelo e leia a coluna SIZE de ollama ps. Ela apresenta os pesos, a cache e a sobrecarga como um único valor.

O contexto de 256K indicado no cartão do modelo é viável nesta arquitetura, mas não é gratuito. Preenchê-lo em f16 custa cerca de 16 GB de cache além dos pesos, numa máquina que já gastou 17 GB com os pesos. Por predefinição, o Ollama não fornece toda a janela. Carrega uma janela muito menor, indicada pelas FAQ do Ollama como 4096 tokens, e pode aumentá-la deliberadamente com OLLAMA_CONTEXT_LENGTH. Essa variável aplica-se a todo o servidor, mas não é o único controlo disponível. Definir num_ctx no pedido individual permite manter uma predefinição económica para os restantes pedidos, enquanto um único trabalho longo recebe uma janela maior. Aumente o valor gradualmente e verifique ollama ps depois de cada alteração.

Duas definições mantêm a cache reduzida. OLLAMA_KV_CACHE_TYPE=q8_0 armazena a cache com 8 bits em vez de 16, reduzindo o consumo de 32k tokens de 2 GB para 1 GB. Requer flash attention, por isso defina também OLLAMA_FLASH_ATTENTION=1 e confirme a redução em ollama ps, em vez de assumir que a alteração foi aplicada. Se ainda não alterou o tipo de cache, um guia sobre q8_0 e f16 para a cache KV do Ollama explica como definir ambas as variáveis e consultar os valores antes e depois. 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, aumentar o paralelismo multiplica silenciosamente a cache que foi dimensionada. O valor predefinido atual já é 1, e a substituição abaixo fixa esse valor. Se mais de uma pessoa utilizar este servidor, essa multiplicação é onde começam os problemas. o número de utilizadores simultâneos que um modelo self-hosted pode atender é determinado pelos slots de cache e pela profundidade 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": 128,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room for long context. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 256,
    "q8_max_ctx_ktok": 256,
    "notes": "Both fit with the full 256K window."
  }
]

Leia os dois números como milhares de tokens de contexto que cabem juntamente com os pesos e o projetor de visão, usando cache f16, num 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 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 ultrapassam a RAM, o kernel começa a expulsá-las e a lê-las novamente, e cada token passa 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, o projetor de visão acrescenta cerca de 0.9 GB e ficam aproximadamente 12.5 GB disponíveis. Isso suporta cerca de 128k tokens de contexto f16 com margem. Os pesos Q8_0, com 29 GB, não cabem de todo neste nível.

64 GB oferece uma margem confortável. O Q4 deixa espaço para a janela completa de 256k, e os pesos Q8_0 também cabem com os 256k completos de contexto. 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. O Q4 já alcança 128k tokens num plano de 32 GB, e essa é a melhor relação entre custo e benefício para quase todos.

Quão rápida é a inferência em 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 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
  }
]

Estes 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 que se atinja 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. Um servidor com DDR5-4800 de dois canais tem um limite de 4.5, por isso espere cerca de 3.

As linhas referentes a servidores grandes incluem um aviso. Uma plataforma EPYC com doze canais tem 460.8 GB/s e um limite de 27.1 tokens por segundo, mas não aluga um EPYC completo. A largura de banda da memória é um recurso de todo o host, partilhado por todos os tenants nessa máquina, por isso uma fatia com 8 vCPUs não inclui doze canais de largura de banda exclusivos. Os guias centrados em GPU ignoram completamente este ponto, e é por isso que 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 cedo pela mesma razão. Quando os núcleos começam a pedir dados mais depressa do que o controlador de memória consegue fornecê-los, as threads adicionais apenas acrescentam sobrecarga de agendamento. O Ollama não tem uma variável de ambiente global do servidor para o número de threads. Por isso, defina num_thread no pedido options com o número de núcleos físicos, faça medições e depois experimente metade desse número. Em muitos planos partilhados, a definição mais baixa é mais rápida.

O processamento do prompt comporta-se de forma diferente. O prefill, a passagem pelo input antes de aparecer o primeiro token, é limitado pelo poder de 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 de começar a saída num prompt grande, seguida pela taxa estável e lenta indicada acima. Meça as duas partes separadamente com --verbose, que imprime um prompt eval rate e um eval rate para cada pedido.

Se o modelo denso de 27B for simplesmente demasiado lento, consulte as etiquetas qwen3.6:35b-a3b antes de desistir da CPU. Estas ativam aproximadamente 3 mil milhões de parâmetros por token, em vez de todos os 27.3 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. Em troca, usa mais RAM para obter maior velocidade. A escolha do runtime também é importante aqui, e Ollama e llama.cpp expõem diferentes controlos de ajuste 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 da 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 data center atinge 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, defina o limite com base na carga de trabalho, não na preferência. A inferência na 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 uma pessoa estiver à espera da resposta ou assim que os pedidos chegarem mais depressa do que o seu servidor consegue processá-los. Os runtimes de CPU não estão limitados a um pedido de cada vez: o servidor llama.cpp documenta descodificação paralela e batching contínuo na CPU e na GPU, e o Ollama também pode processar pedidos em paralelo, com o custo de usar mais cache. O que decide é a taxa de processamento medida em comparação com a taxa de chegada dos pedidos. Por isso, cronometre um lote realista no seu próprio servidor. Quando os pedidos chegarem mais depressa do que essa taxa, a fila crescerá.

A comparação de custos é menos óbvia do que parece. Um VPS de 64 GB é cobrado todas as horas do mês, esteja o modelo carregado ou não, enquanto uma instância com GPU só cobra 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 ciclo 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 o vLLM supera o Ollama quando processa pedidos concorrentes numa GPU porque faz o batching corretamente.

Existe uma terceira opção que é frequentemente esquecida. Mantenha o 27B na CPU para tarefas em lote e coloque um modelo de API alojado à frente do caminho interativo. Nada obriga um único modelo a processar os dois tipos de carga.

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

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 apresentar 0.32.12 ou posterior, a primeira versão com suporte para Qwen 3.8 27B. Verifique free -g antes de transferir qualquer coisa. Se a coluna total da linha Mem indicar menos de 32, pare aqui e escolha um modelo menor, porque transferir 18 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, em vez de as definir na shell. O modelo é executado dentro do serviço, por isso não vê o seu 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.8:27b
ollama run qwen3.8:27b --verbose "Name two Linux distributions."

O resultado de --verbose é a medição que procurava. eval rate é a velocidade, em 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: num CPU, recarregar 17 GB do disco em cada pedido custa mais do que o próprio pedido. O tempo limite de inatividade predefinido é 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 a partir de um segundo terminal.

ollama ps

A coluna SIZE mostra a utilização real de memória, incluindo a cache KV. Deve ficar próxima da soma dos pesos, do projetor de visão e da linha correspondente ao seu comprimento de contexto no gráfico KV. Com 8192 tokens e uma cache de 8 bits, a parte crescente da cache ocupa apenas cerca de um quarto de gigabyte, contra 0.5 GB se permanecesse em f16, além do estado fixo de atenção linear. A coluna PROCESSOR deve apresentar 100% CPU. Se apresentar qualquer outro valor, algo está a utilizar uma GPU e os valores de velocidade deste guia não descrevem o seu computador.

Modos de falha e as strings 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 esperada, porque o Ollama verificou os requisitos antes de alocar memória, em vez de deixar o kernel resolver a situação. Reduza o tamanho do contexto, mude para uma tag menor ou escolha um plano maior.

O processo desaparece a meio de uma resposta. O cliente não apresenta informação útil e journalctl -u ollama -n 50 mostra que o serviço está a reiniciar. Execute dmesg -T | tail. Uma linha com o conteúdo Out of memory: Killed process ... (ollama) significa que o OOM killer do kernel terminou o processo. Isto acontece quando a verificação prévia é bem-sucedida, 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. Um número de versão que ainda não foi lançado produz exatamente este erro, tal como qualquer erro de escrita na tag. qwen3.8:27b existe, portanto, se essa tag exata falhar, procure primeiro um erro de escrita. Confirme a tag na página da biblioteca antes de culpar a rede. Se uma tag válida for transferida, mas não arrancar, compare ollama --version com 0.32.12.

Tudo funciona, mas o serviço está insuportavelmente lento. Menos de um token por segundo num sistema com RAM suficiente aponta para paginação, não para 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 o número de modelos carregados. 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 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. Isso é o prefill e é normal. Um prompt de sistema longo é processado em cada pedido que não encontra a cache. Reduza o prompt de sistema 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. Isso é inutilizável para chat, mas funciona perfeitamente numa fila. Um modelo que raciocina antes de responder torna essa conta ainda pior, porque os tokens de raciocínio ocultos são gerados à mesma velocidade lenta da 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 pendente de ficheiros e a revisão de código sem supervisão toleram esse tempo, porque nada fica à espera da resposta. A assistência à programação está mesmo no limite. Por isso, encaminhar um agente de programação para um modelo alojado por si compensa em tarefas executadas em segundo plano, 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. Isso tem muito valor para dados regulamentados, mesmo a três tokens por segundo. Compare esse benefício de forma realista com a alternativa: alojar internamente um modelo de escala de fronteira exige uma ordem de grandeza mais de hardware, e um 27B em CPU é o ponto mais barato dessa curva em que o resultado ainda compensa ser lido.

Para avaliar qualquer um destes casos, precisa de dados estruturados reais. A maioria das APIs públicas de dados exige uma conta antes de permitir sequer medir o throughput. O endpoint de demonstração da Strasmore (somos nós que o executamos) responde a SQL apenas de leitura sobre dados de ações e opções 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 encaminhar diretamente para um ciclo de prompts, juntamente com o SQL exato que produziu os dados. Assim, o modelo tem algo para resumir que pode verificar de forma independente. A demonstração limita cada chamada a 500 linhas e 20 segundos e disponibiliza histórico desde 1 January 2025, mais do que suficiente para uma máquina a dois tokens por segundo. A lista completa de colunas está em https://ai.strasmore.com/api/demo/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 de firewall que este guia pressupõe que já tenha. Não exponha a porta 11434 à Internet. O Ollama não inclui autenticação própria. Qualquer entidade que consiga alcançar essa porta pode usar o seu modelo e ler os seus prompts.

FAQ

Existe um modelo Qwen 3.8 27B no Ollama?

Sim. Em 18 October 2026, a biblioteca Ollama tem uma entrada qwen3.8, e qwen3.8:27b (também identificado como latest) é uma compilação 18 GB Q4_K_M de um modelo denso com 27.3 billion parameters, um vision projector e uma janela de contexto 256K. É executado localmente e precisa do Ollama v0.32.12 ou posterior. As tags qwen3.6:27b e qwen3.5:27b mais antigas continuam listadas. Consulte https://ollama.com/library/qwen3.8/tags para ver a lista atual. 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 vision projector acrescenta cerca de 0.9 GB, o sistema operativo precisa de aproximadamente 1.5 GB e a KV cache acrescenta cerca de 1 GB por cada 16,000 tokens de contexto em f16, porque apenas 16 das 64 camadas do modelo mantêm uma cache que cresce. Um plano de 16 GB não consegue sequer armazenar os pesos, e a 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 deixam espaço para a janela completa de 256K, mesmo com pesos Q8_0 de 29 GB.

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

Divida a largura de banda da memória pelo tamanho dos pesos e considere depois 50 a 70% 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. Uma máquina 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, meça a sua com ollama run qwen3.8: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 29 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, pois isso altera o que o modelo consegue fazer, e não 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á a funcionar. Uma VPS de 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 batch contínuo e de baixa prioridade é o caso em que a VPS sempre ligada compensa.