Self-hosting de pesos abertos: a matemática de VRAM que decide antes do benchmark

A conversa sobre rodar modelo próprio quase sempre começa pelo lugar errado: qual modelo é melhor.

Comece por uma pergunta de aritmética: ele cabe?

Essa conta leva cinco minutos e elimina a maior parte das opções antes de qualquer benchmark. Depois dela vem a segunda, igualmente aritmética: em que volume a GPU própria fica mais barata que pagar por token. Juntas, as duas decidem mais do que qualquer tabela de acurácia.

Setembro de 2026 tornou a pergunta relevante para muito mais gente: há checkpoints MIT e Apache 2.0 resolvendo cerca de 80% do SWE-bench Verified, e um preço de API que caiu pela metade na mesma semana. As duas pontas se moveram. A conta mudou.

TL;DR

• Memória total ≈ pesos + KV cache + overhead. Quase todo mundo esquece os dois últimos.
• Pesos em bytes ≈ parâmetros × bytes por parâmetro. FP16 = 2, INT8 = 1, INT4 ≈ 0,5.
• Em MoE, os parâmetros totais ocupam memória mesmo quando só os ativos calculam.
• KV cache cresce com contexto × concorrência, e é ele que estoura a GPU em produção, não os pesos.
• Reserve ~15% para fragmentação, ativações e CUDA graphs.
• INT8 é o ponto doce na maioria dos casos. INT4 vale quando cabe e o eval não reprovou.
• Ponto de equilíbrio típico fica na casa de milhões de tokens por dia. Abaixo disso, API quase sempre ganha.
• Privacidade, latência previsível e independência de alias são razões válidas para self-hosting mesmo fora do ponto de equilíbrio.

A conta de memória, em três termos

def vram_gb(
    total_params_b: float,       # bilhões de parâmetros TOTAIS
    bytes_per_param: float,      # 2.0 FP16 | 1.0 INT8 | 0.5 INT4
    context_tokens: int,
    concurrent_requests: int,
    n_layers: int,
    n_kv_heads: int,
    head_dim: int,
    kv_bytes: int = 2,           # FP16 no cache
) -> dict[str, float]:
    weights = total_params_b * 1e9 * bytes_per_param / 1e9

    # KV cache: 2 (K e V) x camadas x heads_kv x dim x tokens x bytes
    per_token = 2 * n_layers * n_kv_heads * head_dim * kv_bytes
    kv = per_token * context_tokens * concurrent_requests / 1e9

    overhead = (weights + kv) * 0.15      # fragmentação, ativações, CUDA graphs
    return {
        "pesos_gb": round(weights, 1),
        "kv_cache_gb": round(kv, 1),
        "overhead_gb": round(overhead, 1),
        "total_gb": round(weights + kv + overhead, 1),
    }

Rodando para um modelo denso de 70B com contexto de 32k e 16 requisições simultâneas:

vram_gb(70, 2.0, 32_000, 16, n_layers=80, n_kv_heads=8, head_dim=128)
# {'pesos_gb': 140.0, 'kv_cache_gb': 10.7, 'overhead_gb': 22.6, 'total_gb': 173.3}

Cento e setenta e três GB. Duas H100 de 80 GB não bastam; você precisa de três, ou de quantização.

Agora repare no que acontece quando o contexto cresce:

Os pesos são constantes. O KV cache é a variável que estoura a máquina, e ele escala com o produto contexto × concorrência. Dimensionar pelo tamanho do modelo e esquecer disso é o erro mais comum de quem monta a primeira GPU.

MoE: parâmetros ativos enganam

Modelos Mixture-of-Experts publicam dois números, e a diferença entre eles é enorme. Alguns exemplos de checkpoints abertos disponíveis em setembro de 2026:

A regra que importa: ativos determinam o custo de compute, totais determinam o custo de memória. Você precisa dos experts residentes para poder rotear até eles.

O DeepSeek V4 Flash em INT8 pede ~284 GB só de pesos. O Qwen3-Coder-Next, com 80 B totais, pede ~80 GB em INT8 e ~40 GB em INT4 — que cabe em uma única GPU de 48 GB com contexto moderado.

Por isso a lista de "melhores modelos abertos" é quase inútil sem a coluna de classe de deploy:

Quantização: o que você troca

Quantização não é gratuita, mas o preço costuma ser menor do que o medo sugere.

A regra prática: INT8 primeiro. Ele corta a memória pela metade com degradação que costuma sumir dentro do intervalo de confiança do seu eval. INT4 só depois de medir — e medir no seu conjunto, não no relatório de quem publicou a quantização.

Um detalhe subestimado: quantizar os pesos não quantiza o KV cache. Se a memória apertar com contexto longo, cache em INT8 (kv_cache_dtype="fp8" em vLLM, por exemplo) costuma render mais que descer os pesos de INT8 para INT4.

Throughput: a conta que dimensiona a frota

Memória diz se roda. Throughput diz se atende.

def throughput_estimate(
    active_params_b: float,
    gpu_tflops: float,            # TFLOPs efetivos, não de catálogo
    batch_size: int,
    mfu: float = 0.35,            # utilização realista: 30-45%
) -> dict[str, float]:
    # ~2 FLOPs por parâmetro ativo por token gerado
    flops_per_token = 2 * active_params_b * 1e9
    effective = gpu_tflops * 1e12 * mfu
    tokens_s = effective / flops_per_token * min(batch_size, 32) ** 0.5
    return {
        "tokens_s_total": round(tokens_s, 1),
        "tokens_s_por_req": round(tokens_s / batch_size, 1),
    }

Duas escolhas conscientes nessa estimativa: mfu em 0,35 porque utilização de 90% não acontece em serving real, e o expoente 0.5 porque o ganho de batching satura — dobrar o batch não dobra o throughput.

Use isso para dimensionar, não para prometer. A medição real com vllm bench no seu padrão de tráfego é a única fonte confiável, e ela costuma ficar 20–30% abaixo da estimativa.

O ponto de equilíbrio

Aqui está a conta que a maioria das discussões sobre self-hosting evita.

def break_even(
    api_price_per_1m_out: float,
    gpu_hourly_usd: float,
    n_gpus: int,
    tokens_s: float,
    utilization: float = 0.4,      # tráfego real não é 24/7 em pico
) -> dict[str, float]:
    gpu_daily = gpu_hourly_usd * n_gpus * 24
    tokens_daily = tokens_s * 86_400 * utilization

    self_cost_1m = gpu_daily / (tokens_daily / 1e6)
    break_even_daily = gpu_daily / api_price_per_1m_out * 1e6

    return {
        "custo_self_1m_tokens": round(self_cost_1m, 3),
        "tokens_dia_equilibrio": round(break_even_daily),
        "custo_gpu_dia": round(gpu_daily, 2),
    }

Um cenário concreto: duas GPUs a US$ 2,50/hora, 900 tokens/s agregados, 40% de utilização, contra uma API de saída a US$ 0,50 por milhão.

break_even(0.50, 2.50, 2, 900)
# {'custo_self_1m_tokens': 1.607, 'tokens_dia_equilibrio': 240000000, 'custo_gpu_dia': 120.0}

Leia com atenção: o custo self-hosted por milhão de tokens é US$ 1,61, contra US$ 0,50 da API. Nesse cenário, self-hosting é três vezes mais caro — e o ponto de equilíbrio está em 240 milhões de tokens por dia, volume que poucas aplicações alcançam.

Essa é a conclusão desconfortável de 2026: com a queda de preço de setembro, o argumento puramente econômico para self-hosting ficou mais difícil. Uma API a US$ 0,10 de entrada e US$ 0,50 de saída é muito barata para competir com GPU ociosa.

E note a sensibilidade a utilization. A 40%, você paga GPU parada mais da metade do tempo. Subir para 80% divide o custo por dois — o que explica por que self-hosting funciona melhor para carga batch contínua do que para tráfego interativo com picos.

As razões que não são custo

Seria desonesto terminar a análise no ponto de equilíbrio, porque as melhores razões para self-hosting não são econômicas.

Dado que não pode sair. Regulação, contrato ou política interna. Não existe preço de API que resolva isso; é uma restrição binária.

Latência previsível. Sua GPU não tem fila compartilhada, não tem rate limit e não tem vizinho barulhento. Para p99 apertado, a diferença é estrutural, não marginal.

Independência de alias. Pesos em disco com revisão fixada não mudam de comportamento porque alguém promoveu uma versão. Para sistemas auditáveis, isso vale bastante.

Custo previsível em vez de baixo. GPU reservada é uma linha fixa no orçamento. API é uma linha variável que escala com o sucesso do produto — inclusive de formas que ninguém planejou.

Fine-tuning barato de iterar. Se o seu caso exige especialização, ter os pesos em casa transforma cada experimento em horas de GPU em vez de um ciclo com fornecedor.

Se nenhuma dessas se aplica e você está abaixo do ponto de equilíbrio, a API é a resposta certa — e admitir isso é engenharia, não derrota.

Serving: o que muda na prática

Se a decisão for self-hosting, três configurações resolvem a maior parte do desempenho:

# vLLM, os parâmetros que mais importam
engine_args = {
    "model": "Qwen/Qwen3-Coder-Next",
    "quantization": "awq",                  # INT4 quando cabe; "fp8" para INT8
    "tensor_parallel_size": 2,              # número de GPUs do nó
    "gpu_memory_utilization": 0.90,         # deixe folga; 0.95 causa OOM sob pico
    "max_model_len": 32_768,                # o teto real do seu caso, não o do modelo
    "enable_prefix_caching": True,          # prompt de sistema estável vira cache
    "kv_cache_dtype": "fp8",                # metade do KV cache
}

Os dois de maior impacto costumam ser max_model_len e enable_prefix_caching.

Declarar max_model_len no tamanho real do seu caso, em vez do máximo do modelo, libera GB de KV cache que viram concorrência. E prefix caching faz pelo self-hosting o que o cache de entrada faz pela API: se o seu prompt de sistema tem 1.200 tokens estáveis, ele para de ser recomputado a cada requisição.

Checklist

• A conta de memória inclui pesos, KV cache e 15% de overhead.
• Em MoE, o cálculo usa parâmetros totais para memória.
• O KV cache foi calculado no contexto e na concorrência reais de pico.
• INT8 foi testado antes de considerar INT4.
• A quantização foi avaliada no seu eval, não no relatório de terceiros.
• max_model_len reflete o seu caso, não o máximo do modelo.
• Prefix caching está ligado para o prompt de sistema.
• O ponto de equilíbrio foi calculado com utilização realista.
• Se está abaixo do equilíbrio, existe uma razão não econômica documentada.
• A licença do checkpoint foi lida — MIT, Apache 2.0 e "custom" não são a mesma coisa.

Conclusão

A escolha entre GPU própria e API raramente se decide por qualidade de modelo. Ela se decide por duas contas de aritmética que cabem em uma folha.

A primeira — pesos, KV cache e overhead — elimina metade das opções em cinco minutos, e quase sempre pelo termo que ninguém calculou: o cache, que escala com contexto vezes concorrência.

A segunda — custo por milhão de tokens contra o ponto de equilíbrio — dá uma resposta que, em setembro de 2026, ficou menos favorável ao self-hosting do que era há um ano. Os preços de API caíram pela metade na mesma semana em que os pesos abertos ficaram bons.

O que sobrevive a essa conta são as razões não econômicas: dado que não pode sair, latência previsível, independência de alias e custo fixo em vez de variável. Se uma delas se aplica ao seu caso, self-hosting é uma escolha sólida. Se nenhuma se aplica, a aritmética já respondeu.

Leituras relacionadas

• Opus 5, GPT-6 Sol e GPT-6 Luna: o que os benchmarks realmente dizem
• Custo por tarefa: a métrica que substitui preço por token
• Seu eval de domínio em um dia

Contagens de parâmetros e licenças foram verificadas em 22 de setembro de 2026 nos cartões de modelo do Hugging Face. Preços de GPU e de API são snapshots e variam por região e contrato; recalcule com os seus números antes de decidir.