CPU dedicada ou compartilhada: qual VPS escolher?

Resposta direta

CPU dedicada é a escolha mais segura quando a aplicação precisa de desempenho previsível, mantém processamento constante ou sofre impacto financeiro com picos de latência. CPU compartilhada costuma atender sites pequenos, ambientes de desenvolvimento, homologação, bots, VPNs e APIs com tráfego irregular, desde que exista monitoramento. A quantidade de vCPUs, sozinha, não resolve a decisão. É preciso observar tempo de CPU disponível, frequência sustentada, política de compartilhamento do provedor, uso de steal, latência da aplicação e comportamento durante horários de maior ocupação do host físico.

Na prática, uma VPS com 2 vCPUs compartilhadas pode responder muito bem durante períodos tranquilos e perder consistência quando outras instâncias do mesmo host aumentam o consumo. Uma opção com 2 vCPUs dedicadas tende a oferecer uma parcela de processamento mais estável, mas não significa acesso exclusivo a dois processadores físicos completos. A implementação depende do hypervisor, do plano e da política do provedor.

Considere uma API Node.js que usa 35% de CPU na maior parte do dia, mas chega a 90% por dez minutos durante importações. Ela pode funcionar em CPU compartilhada se essas rajadas forem aceitas pelo plano. Já um banco PostgreSQL executando relatórios durante todo o expediente precisa de menor variação para não ampliar o tempo das consultas. Nesse caso, CPU dedicada ou uma instância com política explícita de uso sustentado reduz uma fonte de incerteza.

A decisão deve combinar telemetria e custo. Comece medindo CPU, carga, steal, filas, tempo de resposta e I/O por pelo menos sete dias. Se o processador permanece ocupado, a latência varia sem aumento proporcional de tráfego ou o sistema depende de processamento contínuo, a CPU dedicada passa a ser tecnicamente justificável.

Resumo rápido

• CPU compartilhada divide ciclos do processador físico com outras máquinas virtuais e pode apresentar maior variação de desempenho.
• CPU dedicada reserva uma parcela mais previsível de processamento, embora a implementação varie entre provedores e famílias de instância.
• Uma vCPU normalmente representa uma thread virtual, não necessariamente um núcleo físico completo e exclusivo.
• Sites pequenos, homologação, VPN, bots e serviços de baixo uso costumam funcionar bem com recursos compartilhados.
• Bancos de dados ativos, compilação contínua, transcodificação e APIs críticas se beneficiam de CPU mais previsível.
• Steal time, load average, latência percentil 95 e filas de execução ajudam a identificar contenção.
• RAM insuficiente, swap e disco lento podem parecer problema de CPU, por isso o diagnóstico precisa considerar o servidor inteiro.

O rótulo do plano não deve ser analisado isoladamente. Dois provedores podem usar o termo CPU dedicada para produtos com políticas diferentes de agendamento, frequência e oversubscription. Também existem instâncias compartilhadas com bom desempenho sustentado e planos baseados em créditos, nos quais rajadas são permitidas até determinado saldo ou limite. A documentação oficial precisa indicar o comportamento esperado.

Para uma aplicação simples, começar com 2 vCPUs compartilhadas, 4 GB de RAM e armazenamento SSD ou NVMe pode ser uma escolha equilibrada. Um serviço de produção que comprime arquivos, processa filas ou executa consultas pesadas pode exigir 4 vCPUs dedicadas e 8 GB de RAM. Esses números são pontos de partida, não garantias de capacidade. Código, banco, cache, região e padrão de tráfego alteram o resultado.

Antes de contratar, compare a política de CPU e estime o custo total mensal, incluindo backup, tráfego excedente e armazenamento. O artigo sobre quanto custa uma VPS no Brasil ajuda a organizar essa conta sem reduzir a análise ao valor anunciado na página do plano. Uma instância barata que precisa ser duplicada para manter estabilidade pode custar mais do que uma configuração previsível desde o início.

Como a CPU de uma VPS é realmente entregue

vCPU não é o mesmo que núcleo físico

Em uma VPS, a vCPU é uma unidade de processamento apresentada pelo hypervisor ao sistema operacional convidado. Frequentemente ela corresponde a uma thread de hardware, mas essa relação não é universal. Um servidor com processador de 16 núcleos e 32 threads pode hospedar várias instâncias, e o hypervisor distribui tempo de execução conforme limites, prioridades e disponibilidade. Por isso, comparar apenas 4 vCPUs contra 2 vCPUs não revela frequência, geração do processador nem capacidade sustentada.

Em CPU compartilhada, várias VPS podem executar tarefas nas mesmas threads físicas em momentos diferentes. Um blog WordPress que usa 5% de CPU durante a madrugada não precisa manter um núcleo ocioso reservado. O compartilhamento melhora a utilização do hardware e reduz o custo do plano. A contrapartida aparece quando várias instâncias exigem processamento simultaneamente, criando contenção e maior variação no tempo de resposta.

Compartilhamento, limites e rajadas

CPU dedicada geralmente significa que uma quantidade definida de threads ou capacidade computacional fica reservada para a instância. Isso melhora a previsibilidade, mas não autoriza concluir que o cliente recebeu um processador físico inteiro. O provedor ainda pode usar virtualização, aplicar limites de frequência ou executar tarefas administrativas no host. É preciso consultar a definição específica de cada produto.

Algumas plataformas também trabalham com instâncias burstable. Elas entregam uma base de CPU e permitem rajadas temporárias, muitas vezes controladas por créditos. Esse modelo funciona para um painel administrativo que fica ocioso por horas e sobe para 100% durante uma exportação de três minutos. Ele é inadequado para um encoder de vídeo que usa todos os núcleos durante seis horas, pois o desempenho pode cair quando os créditos terminam.

Outro exemplo é um runner de integração contínua. Compilar uma aplicação quatro vezes por dia pode funcionar bem em CPU compartilhada. Manter dez builds simultâneos exige capacidade sustentada e isolamento maior. Ao comparar planos, procure termos como shared, dedicated, reserved, burstable, baseline e fair use. Se a documentação não explicar limites e comportamento sob uso contínuo, trate a previsibilidade como desconhecida e teste antes de migrar uma carga crítica.

O que muda no desempenho da aplicação

Latência previsível contra throughput eventual

A principal diferença percebida pelo usuário não costuma ser a velocidade máxima de uma execução isolada, mas a consistência. Uma API pode responder em 90 ms na mediana e chegar a 800 ms no percentil 95 quando o host está disputado. A média ainda parece aceitável, porém uma parcela relevante das requisições fica lenta. CPU dedicada tende a reduzir essa variação quando a causa é contenção, embora código ineficiente, coleta de lixo e consultas ao banco também possam produzir o mesmo sintoma.

Pense em três cargas. Um site institucional gera páginas por poucos milissegundos e passa grande parte do tempo aguardando rede ou banco. Ele dificilmente aproveita um núcleo reservado o dia inteiro. Uma loja virtual recebe campanhas em horários conhecidos e recalcula carrinhos, fretes e sessões. Ela precisa de folga para os picos. Um serviço de processamento de imagens mantém workers ativos, redimensionando arquivos em sequência. Nesse último cenário, o consumo sustentado torna a CPU dedicada mais coerente.

O papel da RAM, do disco e da rede

Nem toda lentidão atribuída ao processador nasce nele. Quando a RAM acaba, o Linux pode mover páginas para swap. O wa exibido pelo top cresce enquanto processos aguardam disco, e a aplicação parece travada mesmo com CPU ociosa. Um PostgreSQL com 2 GB de RAM e uma base de 20 GB pode reler muitos blocos do armazenamento porque o cache é pequeno. Trocar CPU compartilhada por dedicada não corrige esse padrão.

O mesmo raciocínio vale para disco e rede. Uma importação de catálogo pode ser limitada pelas operações por segundo do volume, enquanto uma API que consulta serviços externos passa a maior parte do tempo esperando respostas. Para equilibrar o servidor, consulte também o material sobre como escolher CPU, RAM e NVMe. A análise conjunta evita pagar por quatro vCPUs quando o gargalo real é swap ou armazenamento.

Em produção, acompanhe mediana e percentis 95 e 99 da latência, não apenas médias. Registre também CPU por processo, I/O wait, memória disponível e tempo das consultas. Se a latência sobe junto com steal, sem aumento de I/O ou chamadas externas, o compartilhamento se torna uma hipótese forte. Se steal permanece próximo de zero e o processo ocupa 100% de uma vCPU, a aplicação provavelmente precisa de mais paralelismo, otimização ou capacidade computacional.

Como dimensionar CPU dedicada ou compartilhada

Configurações iniciais por carga

O dimensionamento começa pelo padrão de uso, não pelo nome da tecnologia. Uma aplicação com tráfego esporádico pode usar mais CPU no pico do que um serviço contínuo, mas permanecer econômica em um plano compartilhado. Já uma tarefa de processamento que ocupa 70% da capacidade durante oito horas por dia precisa de desempenho sustentado. A tabela apresenta pontos de partida para testes, sem prometer volume fixo de usuários ou requisições.

Perfil de carga	Configuração inicial	Tipo de CPU sugerido	Métricas prioritárias	Exemplo prático
Blog, portfólio ou homologação	2 vCPUs, 2 a 4 GB de RAM, 40 GB SSD	Compartilhada	CPU, RAM disponível, cache hit	WordPress com cache de página e tráfego irregular
API pequena com banco local	2 a 4 vCPUs, 4 a 8 GB de RAM, 80 GB SSD ou NVMe	Compartilhada com monitoramento	p95, steal, conexões e I/O wait	API Node.js ou Laravel com picos curtos
Banco de dados ativo	4 vCPUs, 8 a 16 GB de RAM, volume rápido	Dedicada ou sustentada	latência de consulta, IOPS, cache e locks	PostgreSQL atendendo sistema comercial
Workers e processamento contínuo	4 a 8 vCPUs, 8 a 16 GB de RAM	Dedicada	fila, tempo por job, CPU por worker	conversão de mídia, OCR ou compilação

Um WordPress com cache Nginx ou FastCGI pode começar com 2 vCPUs compartilhadas e 4 GB de RAM. Se o WooCommerce executa consultas dinâmicas e recebe campanhas concentradas, 4 vCPUs e 8 GB oferecem margem melhor. Para uma API Laravel com Redis e dois workers de fila, 4 GB podem ser suficientes no início, mas jobs grandes competirão com PHP-FPM se todos rodarem na mesma máquina.

Métricas que orientam o upgrade

Colete dados por sete a quatorze dias, incluindo o período mais movimentado. CPU acima de 80% por poucos segundos não exige upgrade automático. O sinal mais forte é a saturação recorrente acompanhada de fila crescente, aumento do p95 ou atraso em jobs. Em Linux, load average acima do número de vCPUs por períodos longos indica processos aguardando execução ou recursos, mas precisa ser interpretado junto com estado dos processos e I/O.

Também reserve capacidade para falhas e picos. Se uma aplicação usa continuamente 3,7 de 4 vCPUs, qualquer rotina de backup, rotação de logs ou aumento de tráfego pode degradar o serviço. Um alvo inicial de 50% a 70% de uso nos horários normais cria margem operacional. Depois, ajuste com testes de carga reproduzíveis e métricas reais.

Quando pagar por CPU dedicada faz sentido

Cargas críticas e previsíveis

CPU dedicada faz sentido quando a variação de desempenho custa mais do que a diferença do plano. Uma plataforma de pagamentos, um sistema de reservas ou uma API usada por caixas de loja precisa responder dentro de uma faixa previsível. Se uma pausa de dois segundos gera repetição de transações ou abandono, reduzir a contenção tem valor operacional. Ainda será necessário configurar banco, timeouts, filas e redundância, pois a CPU não elimina outros pontos de falha.

Bancos de dados ativos são outro caso comum. Consultas analíticas, criação de índices e autovacuum podem competir com requisições transacionais. Em uma instância com 4 vCPUs dedicadas e 16 GB de RAM, a equipe consegue estabelecer limites mais confiáveis para consultas paralelas. Isso não garante uma quantidade específica de transações por segundo, mas reduz uma variável externa durante medições e planejamento.

Processamento contínuo também favorece recursos dedicados. Um worker que converte vídeos, compila projetos ou executa modelos de inferência em CPU pode manter todos os núcleos ocupados. Em plano compartilhado sujeito a fair use, essa carga pode receber limitação ou prejudicar a experiência de outras instâncias. Para dez builds diários de cinco minutos, o compartilhamento ainda pode ser econômico. Para builds durante todo o expediente, compare tempo total de execução e custo da equipe esperando o pipeline.

Quando a CPU compartilhada ainda é suficiente

Ambientes de desenvolvimento, staging e demonstração passam longos períodos ociosos. Reservar capacidade exclusiva para eles costuma desperdiçar orçamento. Uma VPS compartilhada com 2 vCPUs e 4 GB de RAM pode hospedar documentação, Git privado pequeno, VPN e aplicações de teste, desde que os serviços não disputem memória.

Projetos novos também se beneficiam de uma entrada mais econômica. O cuidado é não escolher apenas pelo menor preço. O texto VPS barata vale a pena? explica como limites de CPU, suporte, backup e renovação afetam o custo real. Comece compartilhado quando a carga for tolerante a variações, configure alertas e mantenha um caminho de migração. Se o provedor permite redimensionamento simples, a transição para uma família dedicada pode ocorrer quando as métricas justificarem, não com base em suposição.

Como testar contenção e diagnosticar gargalos

Comandos úteis no Linux

O primeiro passo é observar o servidor durante o problema, não apenas depois. Execute top ou htop e verifique as colunas de CPU. O campo st, chamado steal time, representa o tempo em que a máquina virtual estava pronta para executar, mas o hypervisor usou o processador em outra atividade. Picos isolados podem ocorrer. Valores recorrentes acompanhados de aumento de latência merecem investigação com o provedor.

Use mpstat -P ALL 1 para acompanhar cada vCPU por segundo. Uma aplicação limitada a uma única thread pode saturar um núcleo enquanto os outros ficam ociosos. Nesse caso, contratar mais vCPUs não acelera o processo automaticamente. Um servidor Node.js pode precisar de múltiplos processos com cluster ou contêineres replicados. Uma rotina PHP executada em série talvez exija divisão do trabalho em filas menores.

O comando vmstat 1 ajuda a separar CPU, memória e I/O. Observe processos na fila de execução, swap, blocos lidos e tempo de espera. Para disco, iostat -xz 1 mostra utilização, latência e filas dos dispositivos. Se a CPU está em 30%, mas o volume permanece saturado, migrar para CPU dedicada terá pouco efeito. Também examine consultas lentas do banco e métricas internas da aplicação.

Teste controlado antes da migração

Crie uma linha de base reproduzível. Em uma API, use uma ferramenta como wrk, hey ou k6 para enviar a mesma taxa de requisições durante 15 a 30 minutos. Registre throughput, erros, p50, p95 e p99. Para compilação, execute o mesmo commit cinco vezes e compare duração e variação. Para banco, utilize uma cópia anonimizada e consultas representativas, evitando testes destrutivos na produção.

Depois repita o cenário em horários diferentes. Se o teste entrega 1.000 requisições por segundo pela manhã e 650 à noite sem alteração na aplicação, investigue contenção, frequência, rede e serviços vizinhos. Uma única execução não basta para afirmar superioridade entre provedores. A comparação precisa usar mesma região, sistema operacional, versões, configuração e duração.

Durante uma migração, mantenha rollback. Sincronize dados, reduza o TTL do DNS e teste saúde antes de direcionar todo o tráfego. Para aplicações críticas, envie uma pequena parcela das requisições à nova instância e compare erros e latência. Esse processo mostra se a CPU dedicada resolve o gargalo ou apenas desloca o problema para banco, disco ou rede.

Recomendações por perfil

A melhor escolha depende do impacto da instabilidade, do padrão de processamento e da capacidade da equipe para monitorar. CPU compartilhada não é sinônimo de baixa qualidade, assim como CPU dedicada não corrige automaticamente aplicações mal dimensionadas. Use os perfis abaixo como ponto inicial e valide a decisão com métricas.

Desenvolvedor solo e projetos pequenos

Para portfólios, bots leves, ambientes de estudo, VPN, pequenos sites e APIs em fase inicial, comece com 2 vCPUs compartilhadas, 2 a 4 GB de RAM e 40 a 80 GB de armazenamento. Configure cache, limite processos e acompanhe memória para evitar swap. Se houver banco no mesmo servidor, 4 GB oferecem uma margem mais prática para sistema operacional, aplicação e cache.

Escolha um provedor que permita redimensionamento ou migração sem reconstrução complexa. Faça backup fora da VPS e teste restauração. Alertas para CPU acima de 85%, espaço abaixo de 20% e memória disponível baixa já cobrem falhas comuns. A CPU dedicada só deve entrar quando compilações, tarefas agendadas ou tráfego real mostrarem variação prejudicial.

Equipes, agências e produtos em crescimento

Uma equipe que hospeda vários clientes, executa CI ou mantém uma API comercial precisa separar cargas. Uma configuração inicial possível é 4 vCPUs, 8 GB de RAM e 100 GB de SSD ou NVMe. CPU compartilhada pode atender se o uso for irregular e o plano tolerar rajadas, mas bancos ativos e workers constantes devem ser monitorados separadamente.

Evite colocar dez sites, banco, painel, e-mail e backup no mesmo servidor apenas porque a soma média de CPU parece baixa. Rotinas simultâneas criam picos difíceis de diagnosticar. Separe banco ou workers quando o impacto justificar. Se o p95 piora em horários previsíveis e steal acompanha a mudança, teste uma família dedicada mantendo as demais variáveis iguais.

Produção crítica e cargas constantes

Para sistemas transacionais, bancos movimentados, filas contínuas, compilação frequente e processamento de mídia, priorize CPU dedicada ou uma instância com capacidade sustentada documentada. Quatro vCPUs e 8 a 16 GB de RAM formam uma base comum, mas o número final depende do software, volume de dados e redundância. Serviços críticos não devem depender de uma única VPS, mesmo que ela tenha recursos dedicados.

Distribua aplicação e banco quando necessário, use balanceamento, mantenha backups externos e ensaie restauração. Monitore p95, p99, taxa de erros, filas, locks e tempo por job. Se disponibilidade for requisito contratual, confirme SLA, política de manutenção e opções de região diretamente com o provedor. A escolha madura não é dedicada a qualquer custo, mas aquela em que previsibilidade, arquitetura e orçamento estão alinhados com o risco do negócio.