VPS com GPU: quando você realmente precisa de uma

Você precisa de uma VPS com GPU ou CPU é suficiente?

Uma VPS com GPU muda duas coisas ao executar um modelo por conta própria: a velocidade de geração dos tokens e o tamanho do modelo que cabe na memória. Não muda mais nada. Se sua carga de trabalho é um modelo de chat quantizado de 7B a 27B respondendo a uma pessoa por vez, um trabalho de embeddings em baixo volume ou transcrição de fala com Whisper small, uma VPS comum com CPU e RAM suficiente já dá conta. Comece com CPU, meça o número que está causando o problema e depois aumente os recursos.

O motivo é a largura de banda da memória. Quando um modelo de linguagem gera um token, ele lê da memória todos os pesos de que precisa. Um modelo 8B quantizado para 4 bits ocupa aproximadamente 4.9 GB em disco e quase o mesmo na memória, portanto gerar um token significa mover cerca de 4.9 GB. Divida a largura de banda da memória da máquina por esse número e você terá o limite máximo de tokens por segundo. Essa única divisão explica quase todos os benchmarks que você verá.

O que uma GPU realmente oferece

Largura de banda. A DDR5 de servidor em um host moderno movimenta dezenas de gigabytes por segundo. A memória da GPU (VRAM, video RAM) movimenta centenas ou mais de mil. Essa proporção é o ganho de velocidade, e ele é grande.

Capacidade com velocidade. Um servidor com CPU e 64 GB de RAM consegue carregar um modelo 70B em 4 bits. Ele será executado em um ritmo mais próximo da leitura do que de uma conversa. Uma GPU só ajuda nesse caso se o modelo couber na VRAM, porque, assim que as camadas transbordam para a RAM do sistema, o caminho lento volta a dominar.

Throughput em lotes. Esta é a parte que as pessoas subestimam. Uma GPU gerando respostas para um usuário deixa a maior parte da capacidade de computação ociosa, porque está aguardando a memória. Atenda 20 solicitações ao mesmo tempo e a mesma leitura dos pesos atenderá às 20. A taxa agregada de tokens por segundo aumenta várias vezes, enquanto a velocidade por usuário quase não cai. Mecanismos de inferência em CPU, como o llama.cpp, também oferecem suporte a processamento em lotes, com ganhos que dependem do hardware e da carga de trabalho. Se você está criando uma API chamada por muitos clientes, o processamento em lotes é o principal argumento a favor de uma GPU, mais do que a velocidade bruta de um único fluxo.

Processamento do prompt. Ler um prompt longo é uma tarefa limitada pela capacidade de computação, não pela memória, e é nesse ponto que as GPUs vencem pela maior margem. Um contexto de 30,000 tokens que uma CPU processa lentamente durante um minuto leva alguns segundos em uma GPU. Configurações de retrieval que inserem documentos em cada solicitação sentem esse efeito continuamente.

Números aproximados e como interpretá-los

O throughput real também fica abaixo da largura de banda dividida pelo tamanho do modelo, porque a atenção sobre um contexto crescente adiciona trabalho que a divisão simples ignora.

Para comparação, a leitura silenciosa de adultos em inglês tem uma média de cerca de 4.0 a 4.3 palavras por segundo: 238 palavras por minuto para não ficção e 260 para ficção. Qualquer velocidade igual ou superior a 15 tokens por segundo já parece uma velocidade normal de digitação para uma única pessoa. Por isso, tantas configurações que usam apenas CPU funcionam bem sem chamar atenção.

Dimensionando a VRAM antes da compra

O tamanho do arquivo do modelo é o piso, não o requisito. Reserve espaço para os pesos, mais o KV cache (key-value cache, a memória por token mantida pelo mecanismo de atenção), mais cerca de 1 GB de overhead.

Calcule o cache em vez de adicionar uma porcentagem fixa, porque quantizar os pesos não quantiza o cache. Para cada token, um modelo com atenção completa armazena uma chave e um valor para cada camada e cada cabeça KV, usando 2 bytes por número em FP16, que é o tipo de cache padrão do Ollama. Os metadados do modelo no Ollama, verificados em 2026-10-27, informam que o Llama 3.1 8B tem 32 camadas e 8 cabeças KV de 128 dimensões, o que resulta em 128 KiB por token: cerca de 1.07 GB em um contexto de 8k e 2.15 GB em 16k. Portanto, um modelo 8B de 4.9 GB precisa de cerca de 7 GB de VRAM em 8k e cerca de 8 GB em 16k. Um modelo 27B em 4 bits ocupa cerca de 17 GB (Gemma 3 27B na biblioteca do Ollama). Os metadados do Gemma 3 informam uma janela deslizante de 1,024 tokens, que impede o crescimento de grande parte do cache. Portanto, planeje 20 GB ou mais. Um modelo 70B em 4 bits ocupa cerca de 43 GB (Llama 3.3 70B). Com 80 camadas, seu cache FP16 adiciona cerca de 2.7 GB em 8k e 5.4 GB em 16k. Assim, ele precisa de uma placa de 48 GB com pouca margem, ou de duas placas menores. O mesmo cálculo continua funcionando para modelos muito maiores, e a matemática da VRAM para um modelo de 2.8 trilhões de parâmetros como o Kimi K3 mostra quando escolher uma placa deixa de ser a questão principal.

Contextos longos são onde isso mais importa. Em modelos com atenção completa, como o Llama 3.1, o KV cache cresce linearmente com o tamanho do contexto e pode superar os próprios pesos em 128k tokens. Modelos com atenção em janela deslizante ou em blocos são diferentes: a documentação do Transformers do Hugging Face cita Mistral, Gemma 2 e Llama 4 como exemplos em que o cache dessas camadas para de crescer quando atinge o tamanho da janela ou do bloco. Assim, o crescimento total é mais lento. Se você pretende usar contextos longos, dimensione primeiro para o cache e verifique o que seu engine oferece para quantização do cache. No Ollama, OLLAMA_KV_CACHE_TYPE=q8_0 usa cerca de metade da memória usada por f16 por padrão, e a quantização do cache só se aplica quando o Flash Attention está habilitado. Defina também o tamanho do contexto explicitamente. O Ollama escolhe o padrão com base na VRAM: 4k abaixo de 24 GiB, 32k de 24 a 48 GiB e 256k em 48 GiB ou mais. Em uma placa de 48 GB executando um modelo 70B, esse padrão solicita muito mais cache do que a placa comporta.

Verifique o que a máquina realmente tem

Em uma instância com GPU, confirme primeiro que o driver detecta a placa.

nvidia-smi

Você deve ver uma tabela com o nome da GPU, a versão do driver e a memória usada em relação ao total. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver significa que o NVIDIA-SMI não consegue acessar o driver; verifique se o driver está instalado e se o módulo do kernel está carregado. Em uma imagem padrão do Ubuntu, a correção normalmente é sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, seguida de uma reinicialização para carregar o novo módulo. Para máquinas de computação, a documentação de servidor do Ubuntu recomenda sudo ubuntu-drivers install --gpgpu, que seleciona a versão do driver para servidores.

Para contêineres, apenas o driver não é suficiente. O Docker precisa do NVIDIA Container Toolkit para encaminhar o dispositivo.

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Depois, confirme que o encaminhamento funciona de dentro de um contêiner:

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

A mesma tabela deve aparecer. Uma linha docker: Error response from daemon: could not select device driver que informe o nome de uma capacidade de GPU que não pode ser atendida significa que o Docker não encontrou um driver de dispositivo compatível com a solicitação; verifique se o toolkit está instalado e execute novamente a linha nvidia-ctk e a reinicialização. No Compose, o equivalente é uma entrada deploy.resources.reservations.devices cujo driver é nvidia e cuja lista de capacidades contém gpu. Essa entrada se encaixa nas definições de serviço comuns abordadas em Docker Compose em um VPS.

Meça antes de atualizar

Execute o modelo que pretende realmente utilizar no servidor CPU que já tem e registe os valores. Com Alojamento próprio de um LLM com Ollama numa VPS, basta uma flag:

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

O resultado termina com os tempos de execução. eval rate é a velocidade de geração, em tokens por segundo. prompt eval rate indica a velocidade a que a máquina leu a sua entrada. Estes dois valores mostram qual é a atualização mais útil: um eval rate baixo indica um problema de largura de banda da memória, enquanto um prompt eval rate baixo em entradas longas indica um problema de capacidade de processamento.

Num servidor com GPU, confirme que o modelo foi realmente carregado nela:

ollama ps

A coluna PROCESSOR apresenta 100% GPU quando tudo cabe na GPU, ou algo como 43%/57% CPU/GPU quando isso não acontece. Uma divisão parcial costuma ser pior do que espera, porque cada token continua a aguardar pela metade mais lenta.

A questão do custo

As instâncias com GPU cobram pelo tempo de computação provisionado, e as tarifas e cobranças por instâncias paradas são definidas pelo provedor. Uma GPU sempre ligada para atender a poucas solicitações por dia passa a maior parte do tempo pago ociosa. O ponto de equilíbrio é a utilização: uma GPU ocupada tem baixo custo por token, enquanto uma GPU ociosa é puro desperdício.

Três padrões funcionam. Mantenha o trabalho contínuo de baixo volume em um VPS com CPU. Envie uma solicitação difícil ocasional para uma API hospedada e pague por token. Alugue uma GPU por hora para jobs em lote, fine-tuning ou uma execução em lote de embeddings e depois destrua a instância. É normal combinar esses padrões, e a disciplina de orçamento descrita em controle de custos de agentes de IA em um VPS sempre ligado também se aplica aqui. A diferença é que o vazamento está no tempo ocioso, não na quantidade de tokens.

O que continua a funcionar bem sem uma GPU

Embeddings em baixo volume. Um modelo de embeddings pequeno processa centenas de documentos curtos por minuto em alguns núcleos de CPU, e um índice criado uma vez não precisa de ser rápido.

Whisper small e base para transcrição. O faster-whisper em CPU transcreve quase em tempo real com o modelo small, o que é suficiente para um pipeline executado durante a noite.

Modelos de chat quantizados até cerca de 27B, para um ou dois utilizadores. Lentos, legíveis e utilizáveis.

Tudo o que possa ser considerado um trabalho em lote. Se ninguém estiver a acompanhar o ecrã, a duração total é uma questão de agendamento, não um requisito.

O que realmente precisa de uma GPU: treino ou fine-tuning para além de um adaptador pequeno, atendimento de muitos utilizadores em simultâneo, geração de imagens e vídeo e voz em tempo real, quando a latência é o próprio produto.

FAQ

De quanta VRAM preciso para um modelo 7B ou 8B?

Cerca de 7 GB para um modelo 8B quantizado a 4 bits com um contexto de 8k, e cerca de 8 GB a 16k, com a cache FP16 predefinida do Ollama. Os pesos ocupam aproximadamente 4.9 GB, a cache KV acrescenta cerca de 1.07 GB a 8k ou 2.15 GB a 16k, e o restante corresponde a cerca de 1 GB de overhead. Uma placa de 8 GB suporta o modelo a 8k, mas fica no limite a 16k. Uma placa de 12 GB deixa uma margem confortável para contextos mais longos. Mudar a cache para q8_0 reduz aproximadamente para metade o espaço ocupado pela cache. Se planeia executar com um contexto de 128k, dimensione a cache separadamente, porque pode crescer mais do que os pesos.

Posso executar o Ollama sem uma GPU?

Sim. O Ollama muda automaticamente para a CPU e precisa apenas de RAM suficiente para manter o modelo. Conte com cerca de 5 a 12 tokens por segundo para um modelo 8B a 4 bits, dependendo da velocidade da memória. Para um utilizador, isso aproxima-se da velocidade de leitura. Prompts longos são o principal problema na CPU, porque ler 30,000 tokens de contexto exige muito processamento e demora bastante mais do que gerar a resposta.

Porque é que a minha GPU é apenas ligeiramente mais rápida do que a CPU?

A causa habitual é o modelo não caber inteiramente na VRAM. Nesse caso, algumas camadas são executadas na CPU e cada token espera pela parte mais lenta. Execute ollama ps e confirme se a coluna PROCESSOR apresenta 100% GPU. Se mostrar uma divisão, use uma quantização menor ou um modelo menor. A outra causa comum é um benchmark curto, em que o tempo de carregamento do modelo domina a medição.

Vale a pena usar um GPU VPS para um único utilizador?

Normalmente, não. A velocidade média de leitura silenciosa de um adulto em inglês é de cerca de 4.0 a 4.3 palavras por segundo. Antes de comparar uma máquina com CPU com essa velocidade, é necessário converter tokens por segundo em palavras por segundo. Os casos que justificam o custo para um único utilizador são prompts longos, geração de imagens e fine-tuning. Servir muitos utilizadores em simultâneo é o argumento mais forte, porque o batching permite que uma GPU partilhe as leituras dos pesos entre os pedidos.

Devo alugar uma GPU à hora ou mantê-la sempre ligada?

Alugue-a à hora quando o trabalho ocorrer em picos: fine-tuning, uma execução em massa de embeddings ou um trabalho de transcrição em lote. Mantenha-a sempre ligada apenas quando a placa permanecer ocupada, porque a computação GPU provisionada é cobrada pelo tempo, e não pelo número de tokens produzidos. Um assistente com pouco tráfego fica mais barato numa CPU VPS ou numa API alojada paga por token do que numa GPU inativa.