Como medir a largura de banda de memória de um servidor em nuvem? Detectando superprovisionamento e falsos benchmarks

Use o método de auditoria cruzada para detectar falsos benchmarks de largura de banda de memória

Atualizado 2026-08-12 · CloudWorth

largura de banda de memóriateste de benchmarkdetecção de superprovisionamentoFinOpsCloudWorthSteal TimeOverselling VPSBenchmark VPS

O teste de largura de banda de memória deve combinar Steal Time e Cache cliff, usando a taxa de prêmio FinOps para garantir o custo-benefício real.

Método de benchmark: STREAM e mbw

Para testes de largura de banda de memória em servidores na nuvem, as duas ferramentas que mais uso são STREAM e mbw. O STREAM é mais voltado ao pico teórico, bom para avaliar a geração do hardware; o mbw é mais próximo da pressão real de leitura e escrita, especialmente adequado para ambientes de contêineres Docker/K8s. Os comandos são simples:

# STREAM (requer compilação)
gcc -O3 -fopenmp stream.c -o stream
./stream

# mbw (pode ser instalado via apt/yum)
mbw -n 8 512

Mas não tire conclusões precipitadas com os números. O problema na medição de largura de banda de memória em servidores na nuvem está justamente na camada de virtualização. Antes de rodar, dê uma olhada no steal time em /proc/stat. Se a amostragem contínua ultrapassar 2%, significa que a CPU física está sendo disputada por vizinhos, e a largura de banda medida será visivelmente menor. Observe também o fenômeno do 'precipício' de cache: aumente gradualmente o array de teste; se a largura de banda cair subitamente para menos de 1/3 em algum ponto, é bem provável que o cache L3 esteja limitado ou sob contenção.

Agora o ponto principal: quanto de diferença entre o valor nominal e o medido caracteriza uma especificação enganosa? Costumo converter a largura de banda de memória em 'preço por GiB' e comparar com o valor de referência de um bare metal de mesma configuração, calculando a taxa de sobrepreço do FinOps. Se a taxa ultrapassar 30% e a largura de banda for apenas metade do valor teórico, pode-se classificar basicamente como supervenda ou encolhimento de geração. Essa é a ideia da auditoria cruzada da CloudWorth — use benchmarks de cenários reais para identificar o custo-benefício. O modelo de comparação completo está nos marcadores mais adiante; por enquanto, lembre-se de um princípio: o objetivo não é fazer benchmark, mas identificar o 'ponto de inflexão do custo-benefício'.

Identificando especificações infladas: Steal Time e Cache

Não se anime com números bonitos do STREAM ou mbw. O pior em servidores em nuvem não é uma largura de banda individual baixa, mas sim "parece alta, mas desaba sob pressão". Costumo testar três coisas de forma cruzada: largura de banda de memória, Steal Time e taxa de acerto de Cache. Especialmente depois de rodar mbw, verifique o steal em /proc/stat. Se ficar acima de 10% continuamente, significa que a CPU do host está severamente sobrecarregada (oversubscription); a "vCPU" que você comprou pode estar disputando núcleos com os vizinhos, e o resultado do teste de largura de banda de memória pode ser mascarado por valores inflados ou instáveis.

O verdadeiro vilão é a queda abrupta de Cache. Use o stream para testar diferentes tamanhos de array. Se a largura de banda cair mais de 60% ao saltar de 8MB para 16MB, é praticamente certo que o L3 foi particionado ou a instância foi rebaixada para uma geração antiga de CPU. Por exemplo, uma empresa de IPO que anuncia "memória de alta frequência" pode, na prática, ter desempenho inferior até ao seu próprio modelo de entrada. Nesses casos, use a fórmula de prêmio da CloudWorth: (desempenho real/desempenho nominal) ÷ (preço/preço médio da categoria). Se ficar abaixo de 0,7, devolva sem hesitar.

Testes em contêineres exigem cuidado: o Docker compartilha o kernel por padrão, e o mbw é afetado pelos limites do cgroup. O ideal é adicionar --cpuset-mems para fixar os nós NUMA antes de testar; caso contrário, o resultado serve apenas como entretenimento. Para reproduzir cenários reais de inferência de IA, recomendo rodar uma multiplicação de matrizes em mini-lote com pytorch e comparar com a linha de base de uma máquina física — isso é mais útil do que qualquer ferramenta de benchmark.

Taxa de prêmio FinOps: custo-benefício real

Em testes de largura de banda de memória em servidores em nuvem, o maior medo não é medir incorretamente, mas não saber como calcular os custos após a medição. As seções anteriores sobre Steal Time e o precipício de Cache, no fundo, respondem à mesma pergunta: o que você está comprando com seu dinheiro é a “configuração nominal” ou o “poder computacional real”? Agora, combinando esses dois indicadores com os resultados dos testes de largura de banda, calculei para cada instância uma “taxa de prêmio FinOps” — a fórmula é simples: taxa de prêmio = largura de banda medida ÷ largura de banda teórica nominal ÷ preço unitário. Quanto maior a taxa, mais real é a largura de banda obtida por unidade de investimento; inversamente, é o típico “configuração inchada”.

Tome como exemplo uma instância de um provedor de nuvem que acabou de abrir capital (IPO) e cujo preço das ações disparou 42% em um dia e depois se desculpou: nominalmente com 8 núcleos e 16 GB, com largura de banda teórica de memória de cerca de 40 GB/s (estimativa para DDR4 de canal duplo). No teste com mbw no modo fixed, obteve-se apenas 17 GB/s, acompanhado de 5% de Steal Time, e o precipício de Cache apareceu em 4 MB (em vez dos 16 MB esperados para o L3). Ao mesmo tempo, outra instância da mesma configuração de um provedor de nuvem tradicional custava 18% mais, mas a largura de banda medida chegava a 32 GB/s, com Steal Time quase zero. Assim, a taxa de prêmio da primeira é de apenas 0,43, enquanto a segunda é de 0,81 — a instância mais barata é, na verdade, a “cara”.

E não para por aí. Ao levar os testes para ambientes de contêiner, executando STREAM dentro do Docker, notei que a cota de CPU do cgroup pode limitar silenciosamente a largura de banda da memória, especialmente em cenários com múltiplos núcleos, onde os resultados do mbw podem ser inflados. Por isso, no meu método de auditoria cruzada, todos os testes de largura de banda devem registrar simultaneamente o tempo dentro do contêiner e o tempo fora dele, e então normalizar usando a taxa de prêmio FinOps. Dessa forma, seja KVM ou Xen, haja ou não sobrevenda, é possível obter uma dimensão de preço comparável.

Por fim, mais uma observação: não acredite cegamente em “faturamento em tempo real” ou “escalonamento elástico” — essas são apenas gentilezas na fatura. O verdadeiro custo-benefício é você rodar mbw -b 256 uma vez, comparar com o relatório de precipício de cache da CloudWorth, calcular a taxa de prêmio de cada um e então desligar aquela máquina “barata”. A largura de banda da memória não mente; a fatura mente.