zHBM da Samsung: como a nova memória muda LLMs em produção

O gargalo real da IA não é a GPU — é a memória que trava ela

Quando eu comecei a treinar modelos de linguagem em produção, há alguns anos, percebi rápido que a maior parte do dinheiro queimado nos meus clusters vinha não da capacidade bruta de cálculo, mas do tempo ocioso das GPUs esperando dados. A Samsung acabou de anunciar uma resposta direta para esse problema com a nova arquitetura zHBM, e o que vi no Tecnoblog.net me chamou atenção não pelo hype, mas pelos números concretos: até 8x mais velocidade de transferência e 3x mais eficiência energética. Isso muda a conta de数据中心 de verdade, e por isso vale destrinchar tecnicamente.

O que a Samsung apresentou no Future of Memory and Storage 2026

A fabricante coreana empilhou mais de 400 camadas de células de armazenamento em um único chip, criando uma arquitetura 3D onde a memória fica literalmente em cima do processador, não ao lado. Quem trabalha com hardware de servidor sabe o que isso significa: a distância física entre dado e processamento — aquela maldita latência de barramento — encolhe para quase zero.

Na arquitetura tradicional, mesmo em HBM (High Bandwidth Memory) de gerações anteriores, a memória mora num pacote隔壁 lateral conectado por interposer de silício. Já no zHBM, o stack é verticalizado direto sobre o die de processamento. É a mesma filosofia que a AMD e a Intel vinham explorando com chiplets, mas aplicada ao acoplamento memória-lógica, que historicamente era tratado como dois mundos separados.

Por que isso importa para quem treina LLM

Treinar ou servir um modelo com bilhões de parâmetros é, no fundo, um problema de throughput de memória. Veja a conta que faço quando dimensiono um cluster:

• Um modelo Llama 70B em FP16 ocupa ~140 GB só de pesos.
• Em inferência com KV cache para contexto longo, cada token gerado precisa ler e escrever megabytes de estado de atenção.
• Se a banda entre memória e compute é baixa, o GPU fica starved, e você paga caro por FLOPS que nunca vai usar.

Quando multiplico a taxa de transferência por 8 e a eficiência energética por 3, o que obtenho é a possibilidade de rodar mais sessões concorrentes no mesmo rack, ou de servir modelos maiores no mesmo orçamento de energia. Para OpenAI, Microsoft e Google — citados pela Samsung como alvos — isso representa data centers inteiros repensados. Para quem usa APIs deles, significa preços potencialmente menores nos próximos 18 meses.

Comparação com alternativas reais do mercado

HBM3e vs HBM4 vs zHBM

O pulo da Samsung não é apenas incremental — é arquitetural. Concorrentes como SK Hynix e Micron também trabalham em empilhamento agressivo, mas a integração vertical direta com o processador é o diferencial que observei no anúncio. É o tipo de mudança que, em dois anos, vai ditar quem atende a próxima geração de accelerators da Nvidia e da AMD.

Implicações para quem programa

Na prática, o que muda no meu código? Menos do que parece, mas mais do que parece. Vou ser direto:

• Batch sizes maiores: se a banda sobe, posso alimentar o accelerator com mais tokens em paralelo sem estourar o pipeline.
• Contextos mais longos: a barreira para rodar LLMs com 1M+ tokens de contexto cai quando ler/escrever KV cache deixa de ser gargalo.
• Menor dependência de quantização agressiva: hoje comprimimos modelos para INT4/INT8 porque memória é cara. Com mais banda, posso rodar em FP16/BF16 com latência aceitável.

Na Prática — Como medir se a memória é mesmo seu gargalo

Antes de sair comprando hardware novo, o primeiro passo é confirmar que o problema é mesmo memória. Em vários projetos que auditei, o culpado era outra coisa: I/O de disco para carregar o modelo, ou código Python mal otimizado no pre-processing. Aqui vai um snippet que uso para identificar o gargalo real com torch.profiler:

import torch
from torch.profiler import profile, ProfilerActivity, record_function

model = torch.nn.Transformer(d_model=2048, nhead=32, num_layers=24).cuda()
inputs = torch.randint(0, 50000, (32, 512)).cuda()

# Warmup para estabilizar caches e JIT
for _ in range(3):
    _ = model(inputs)

with profile(
    activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA],
    record_shapes=True,
    with_stack=True,
) as prof:
    with record_function("forward_pass"):
        for _ in range(10):
            output = model(inputs)

print(prof.key_averages().table(
    sort_by="cuda_time_total",
    row_limit=15,
))

O que procuro nesse output:

1. “atenção” ou “softmax” dominando o tempo → gargalo é compute, memória ajuda pouco.
2. “cudaMemcpyAsync” ou “atenção” mostrando longas esperas → gargalo é banda de memória, exatamente o que o zHBM ataca.
3. “DataLoader” alto → o problema nem é GPU, é disco.

Depois de identificar, um teste simples é medir tokens/segundo variando o batch size. Se o throughput satura rápido, é memória. Se escala linearmente, é compute.

import time
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "meta-llama/Llama-3.2-3B-Instruct"  # ajuste ao seu setup
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype=torch.bfloat16,
    device_map="cuda",
)

prompt = "Explique o que é HBM em termos simples."
inputs = tokenizer(prompt, return_tensors="pt").to("cuda")

for batch in [1, 4, 8, 16, 32]:
    # repete o prompt para simular batch
    batched = {k: v.repeat(batch, 1) for k, v in inputs.items()}
    torch.cuda.synchronize()
    start = time.perf_counter()
    out = model.generate(**batched, max_new_tokens=128, do_sample=False)
    torch.cuda.synchronize()
    elapsed = time.perf_counter() - start
    tps = (batch * 128) / elapsed
    print(f"batch={batch:>3} | {elapsed:.2f}s | {tps:.1f} tokens/s")

Rode isso no seu ambiente, anote onde a curva achata, e você tem a régua para comparar quando hardware novo chegar.

Erros Comuns — o que devs fazem errado ao avaliar memória para IA

1. Confundir capacidade (GB) com bandwidth (GB/s)

É o erro mais frequente que vejo em times que estão começando. Compram GPU com 80 GB de VRAM achando que isso resolve tudo. Não resolve. Se a banda entre memória e compute é de 3 TB/s mas o modelo precisa de 6 TB/s, você tem capacidade sobrando e performance travada. Sempre olho os dois números lado a lado.

2. Ignorar o custo do KV cache em inferência

Muitos devs dimensionam só pensando nos pesos do modelo. Esquecem que, durante inferência com contexto longo, o KV cache cresce proporcionalmente a batch_size × sequence_length × num_layers × hidden_dim. Em um setup servindo 100 usuários simultâneos com contexto de 32k, o KV cache consome mais VRAM que o próprio modelo. Aumentar a banda da memória ajuda a gerenciar isso sem despejar para CPU.

3. Subestimar o impacto da topologia NUMA

Em servidores multi-socket, memória ainda é NUMA. Mesmo com HBM no pacote, ao cruzar sockets a latência explode. O zHBM sendo vertical sobre o die elimina parte desse problema, mas se você está usando clusters hoje, lembre de fixar threads e memória no mesmo NUMA node com numactl --membind=0 --cpunodebind=0.

4. Otimizar o que não precisa

Já peguei gente reescrevendo CUDA kernels em C++ quando o gargalo era claramente Python overhead no data loader. Profile antes de otimizar. Sempre.

FAQ — Perguntas que todo dev faz sobre isso

O zHBM é compatível com GPUs atuais (H100, B200, MI300X)?

Não. Trata-se de uma nova arquitetura física de封装. As GPUs atuais foram projetadas para HBM lateral via interposer. O zHBM exige novos accelerators projetados especificamente para essa topologia — provavelmente a próxima geração, 2027 em diante.

Quando o zHBM chega aos data centers de OpenAI e Google?

Pela cadência típica da Samsung (anúncio → sampling → produção em volume), espero ver primeiros deployments reais entre final de 2026 e 2027. Os efeitos em preços de API viriam depois, com a renovação dos contratos.

Vale esperar para comprar hardware novo?

Se você está dimensionando infraestrutura agora, não. A diferença entre HBM3e (atual) e zHBM será gradual — primeiro em hyperscalers, depois em placas profissionais. Para workstation local, a melhor jogada continua sendo maximizar VRAM e banda dentro do que existe hoje.

Isso afeta preços de NVIDIA e AMD?

Indiretamente, sim. Mais concorrência entre fornecedores de memória pressiona margens, e a Samsung como terceira player forte dá aos clientes de accelerators (Nvidia, AMD, Google TPU) mais poder de negociação. Historicamente, isso esfria preços de GPU em 6–12 meses.

Como a Samsung lucrou 56% no último trimestre?

É o reflexo da corrida armamentista de IA. Quem fornece memória de alta banda vende como água no deserto. A nova arquitetura zHBM reforça esse posicionamento estratégico — não é só um anúncio técnico, é um movimento de mercado.

O que tirar de tudo isso

Não é marketing vazio. Empilhar 400 camadas e integrar memória-logica verticalmente é um salto arquitetural real, do tipo que redefine o que é possível em inferência de larga escala. Para quem programa, o efeito prático vai chegar em cadeia: APIs mais baratas, modelos maiores servíveis, e menos tempo perdido esperando dado. Mas, até lá, continua valendo a velha disciplina de medir antes de otimizar, porque o gargalo do seu setup pode não ser onde você imagina.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.