Análise da SemiAnalysis sobre HBM 4-hi: por que pilhas mais curtas podem vencer na inferência de IA

A SemiAnalysis questionou a corrida da indústria de memória para IA rumo a configurações mais altas, argumentando que o HBM 4-hi pode fornecer largura de banda total usando apenas um terço dos dies de DRAM.

A afirmação importa porque fabricantes de aceleradores passaram anos adicionando pilhas de memória mais altas. Mais camadas aumentaram a capacidade, apoiaram modelos maiores e ajudaram a consolidar a memória de alta largura de banda como parte essencial da computação de IA.

A análise da SemiAnalysis sobre HBM 4-hi afirma que a inferência muda esse cálculo. Sistemas em escala de rack oferecem mais capacidade agregada, enquanto a quantização e o descarregamento de cache reduzem a quantidade que cada GPU precisa armazenar.

O relatório não afirma que todas as cargas de trabalho precisam de menos memória. Treinamento, lotes grandes e modelos futuros ainda podem favorecer pilhas mais altas. Seu argumento mais incisivo diz respeito à inferência interativa, na qual a largura de banda frequentemente limita a geração de tokens antes que a capacidade se torne escassa.

Isso cria uma disputa direta entre duas prioridades de projeto. Uma favorece a capacidade máxima de memória por acelerador. A outra favorece a largura de banda máxima para tokens a partir de cada wafer de DRAM limitado.

A redução de memória relatada da Nvidia para Rubin Ultra fornece o sinal imediato. A SemiAnalysis afirma que o acelerador terá 192GB de HBM, abaixo dos 288GB do Rubin padrão e do Blackwell Ultra.

A empresa não detalhou publicamente uma configuração Rubin Ultra 4-hi. No entanto, a mudança relatada em direção a pilhas 8-hi sugere que HBM cada vez mais alto deixou de ser uma escolha automática.

Se esse raciocínio se estender ao HBM4E 4-hi, a infraestrutura de IA poderá usar menos dies de DRAM sem sacrificar a largura de banda externa de cada pilha. Isso reduziria os custos de memória e produziria mais pacotes HBM utilizáveis a partir de uma oferta limitada de wafers.

O roteiro de memória da Nvidia já não segue em uma única direção

A mudança relevante não é que a Nvidia de repente precise de pouca memória. É que a capacidade adicional aparentemente já não oferece valor a qualquer custo.

O Blackwell Ultra estabeleceu claramente a direção de alta capacidade. A Nvidia lista 288GB de HBM3E por GPU Blackwell Ultra e 20TB em um rack GB300 NVL72.

As especificações do GB300 da empresa também listam largura de banda agregada de memória GPU de até 576TB por segundo. Esses números mostram por que a Nvidia antes enfatizava tanto capacidade quanto largura de banda.

A SemiAnalysis agora relata que o Rubin Ultra reverterá parte dessa tendência. Os 192GB esperados por GPU representam uma redução de um terço em relação ao Blackwell Ultra e ao Rubin convencional.

A comparação exige algum cuidado. A arquitetura do Rubin Ultra teria mudado de quatro dies de computação para dois. Portanto, sua capacidade de memória esperada anteriormente pertencia a um projeto de sistema diferente.

Mesmo após normalizar essa mudança, a SemiAnalysis estima que a memória cai de 256GB anteriores por die de computação para 96GB. Trata-se de uma redefinição arquitetural substancial, não de um ajuste cosmético de especificação.

O relatório identifica a oferta como um dos motivos. A Nvidia teria garantido capacidade significativa de lógica avançada e empacotamento, mas os wafers HBM disponíveis não conseguem suportar volumes equivalentes de pilhas 12-hi.

Uma pilha 12-hi contém doze dies centrais de DRAM sobre seu die base. Uma pilha 8-hi usa oito, permitindo que a mesma oferta processada de DRAM suporte mais pilhas concluídas.

Isso importa porque o HBM consome mais capacidade de fabricação por bit do que a DRAM convencional. Vias através do silício, conhecidas como TSVs, conduzem sinais e energia verticalmente pela pilha de memória.

Esses TSVs exigem processamento adicional. Os dies HBM também incluem área para conexões verticais, reduzindo a densidade de bits em comparação com memória comum produzida em um processo semelhante.

A SemiAnalysis estimou anteriormente que o HBM consome aproximadamente três vezes mais capacidade de wafer por bit do que a DRAM de commodity. Sua estimativa se aproxima de quatro vezes à medida que a produção migra para HBM4.

Esse número é uma estimativa de analista, não um padrão da indústria. Ainda assim, a carga de fabricação subjacente é bem estabelecida entre os fornecedores de memória.

SK hynix, Samsung e Micron precisam processar, afinar, conectar, testar e empacotar múltiplos dies conhecidos como bons. Cada camada extra aumenta o uso de materiais e expõe o pacote a riscos adicionais de rendimento.

Historicamente, pilhas mais altas justificavam esse esforço porque os aceleradores precisavam de sua capacidade. Pesos de modelos, ativações, gradientes, estados do otimizador e caches de chave-valor competem por memória em diferentes cargas de trabalho.

A nova decisão sugere que a capacidade ultrapassou um limiar para alguns sistemas de inferência. Quando um rack comporta o conjunto de trabalho necessário, adicionar memória a cada GPU gera menos valor.

A Nvidia não confirmou publicamente a divisão exata de capacidade do Rubin Ultra informada pela SemiAnalysis. A alegação, portanto, deve permanecer como uma mudança relatada no roteiro, e não como uma especificação finalizada de produto.

Ainda assim, preparativos na cadeia de suprimentos podem revelar a direção antes de um lançamento público. A SemiAnalysis afirma que os fornecedores estão preparando configurações 8-hi para se tornarem padrão após um movimento da indústria em direção a produtos 12-hi e 16-hi.

A mudança relatada abre espaço para o HBM 4-hi. Se oito camadas forem suficientes, os projetistas precisam perguntar se quatro camadas podem atender implantações selecionadas de inferência de forma mais econômica.

Essa pergunta teria parecido retrógrada durante a recente corrida por capacidade. Sob severas restrições de DRAM, ela se torna uma das escolhas arquiteturais mais práticas da indústria.

O HBM 4-hi da SemiAnalysis mantém a largura de banda enquanto elimina dies

Uma pilha HBM mais curta reduz a capacidade, mas não reduz automaticamente a largura de banda externa do pacote.

O HBM transfere dados por meio de uma interface muito ampla, em vez de depender apenas de velocidade extrema de sinalização. O HBM4 expande essa interface para 2.048 conexões de dados por pilha.

O padrão HBM4 foi publicado pela JEDEC em abril de 2025. Ele define a base para uma nova geração de memória para IA e computação de alto desempenho.

Segundo a SemiAnalysis, cada die de DRAM HBM4 pode acessar até 512 das conexões de dados da pilha. Quatro dies podem, portanto, preencher todas as 2.048 conexões.

Adicionar do quinto ao décimo segundo die aumenta a capacidade. Isso não amplia a interface externa além dessas 2.048 conexões.

Os pinos disponíveis são divididos entre mais camadas de memória em uma pilha mais alta. A pilha ainda apresenta a mesma interface geral ao acelerador.

Esse é o mecanismo central por trás do argumento em favor de pilhas curtas. Um pacote 4-hi, 8-hi e 12-hi pode oferecer largura de banda nominal comparável quando usa a mesma geração e taxa de sinalização.

Suas capacidades diferem acentuadamente. A SemiAnalysis modela dies centrais HBM4E de 32 gigabits, produzindo 16GB para 4-hi, 32GB para 8-hi e 48GB para 12-hi.

Essas são configurações futuras modeladas, não produtos de varejo amplamente disponíveis. Elas ilustram como a contagem de camadas altera a capacidade enquanto mantém intacta a interface do pacote.

A distinção econômica decorre do que os fornecedores consomem. O conteúdo de DRAM determina grande parte do custo de uma pilha HBM, enquanto clientes de inferência frequentemente valorizam a largura de banda que alimenta seus aceleradores.

Um comprador de 4-hi recebe menos gigabytes. Ainda assim, pode receber o caminho de dados necessário para manter as unidades de computação abastecidas.

Isso muda a métrica de eficiência relevante. Aquisições focadas em capacidade perguntam quantos gigabytes cabem ao lado de cada acelerador. Aquisições focadas em largura de banda perguntam quantos tokens esses links de memória podem suportar.

Para inferência, a segunda pergunta pode predominar. A decodificação autorregressiva gera saída sequencialmente, e cada etapa precisa ler da memória os pesos ativos do modelo.

O processo frequentemente executa relativamente pouca aritmética para cada byte movimentado. Isso torna a decodificação limitada pela largura de banda de memória, o que significa que a entrega de dados limita o desempenho antes da computação bruta.

Uma pilha mais alta ajuda apenas quando a carga de trabalho utiliza sua capacidade adicional. Caso contrário, os dies extras carregam informações que a largura de banda disponível não consegue ler com frequência suficiente.

A SemiAnalysis apresenta uma largura de banda ilustrativa de HBM4E de 3.328GB por segundo por pilha. Ela deriva esse número de 2.048 pinos operando a 13 gigabits por segundo.

A 100 tokens gerados por segundo, isso representa 33,28GB de largura de banda teórica para cada token. O conjunto de trabalho útil não pode exceder esse orçamento se cada token precisar lê-lo uma vez.

Uma pilha de 48GB conteria então mais dados do que a largura de banda teórica consegue examinar por token. Parte da capacidade permaneceria indisponível para essa carga de trabalho específica nessa velocidade.

Sistemas reais nunca sustentam toda unidade de largura de banda nominal. Sobrecarga de protocolo, padrões de acesso, comunicação e comportamento do software reduzem o desempenho efetivo.

Essa limitação pode fortalecer o argumento em favor de pilhas curtas. Menor largura de banda utilizável significa que a carga de trabalho atinge seu teto de largura de banda antes de conseguir explorar toda a capacidade instalada.

O HBM 4-hi explicado por esse mecanismo não é simplesmente uma memória mais barata. É uma configuração que separa a largura de banda externa da densidade vertical máxima.

A distinção também afeta a produção de fabricação. Um wafer usado para pilhas de quatro camadas pode, teoricamente, suportar três vezes mais pacotes do que um usado para pilhas de 12 camadas.

Os ganhos reais dependem de rendimentos, disponibilidade de dies base, testes e capacidade de empacotamento. Pilhas mais curtas também devem evitar algumas perdas cumulativas de montagem associadas a camadas adicionais.

A SemiAnalysis argumenta que a largura de banda resultante por wafer HBM importa tanto quanto tokens por watt. Ambas as métricas medem a produção útil de IA diante de um recurso que não pode se expandir rapidamente.

Por que a inferência valoriza mais a largura de banda do que a capacidade máxima

A inferência interativa recompensa memória capaz de alimentar o processador rapidamente, enquanto capacidade não utilizada contribui pouco para o desempenho de tokens.

Treinamento e inferência impõem exigências diferentes ao HBM. O treinamento armazena pesos, ativações, gradientes e dados do otimizador enquanto processa lotes grandes por passagens diretas e reversas.

Essa carga de trabalho pode consumir enorme capacidade. Ela também realiza aritmética suficiente para se tornar limitada por computação em muitas operações.

A decodificação de inferência é diferente. O sistema lê repetidamente os pesos ativos e o cache de chave-valor do usuário, ou cache KV, enquanto produz um token após o outro.

O cache KV armazena informações de atenção de tokens anteriores. Ele evita que o modelo recalcule toda a conversa sempre que gera outro token.

Mais usuários e contextos mais longos ampliam esse cache. Contudo, uma capacidade maior só é valiosa se o sistema puder atender esses usuários dentro de uma meta aceitável de latência.

O processamento em lote complica o cenário. Ao processar diversas solicitações juntas, um servidor pode amortizar uma leitura dos pesos do modelo entre vários usuários.

Lotes maiores melhoram o desempenho total, mas também exigem mais capacidade de cache KV. É nesse ponto que pilhas 8-hi ou 12-hi podem recuperar uma vantagem.

A contrapartida é a interatividade. Um provedor pode esperar mais para formar lotes maiores ou pode retornar tokens rapidamente com lotes menores.

A SemiAnalysis modela essa relação usando Kimi K3 em uma futura configuração Rubin Ultra NVL576. Ela conclui que pilhas mais altas oferecem ganhos decrescentes de desempenho à medida que aumenta a velocidade necessária por usuário.

A 213 tokens por segundo modelados para cada usuário, o relatório não encontra benefício de desempenho além de 4-hi. O teto de largura de banda chega antes que a capacidade extra de memória se torne útil.

Em outros pontos da curva, 8-hi eleva o desempenho máximo em 8 por cento. Uma configuração 12-hi o eleva em 10 por cento em relação a 4-hi.

Essas melhorias são reais dentro do modelo. A questão é se compensam o custo adicional de memória e de sistema.

A SemiAnalysis estima que seu sistema Rubin Ultra modelado com 8-hi custa 12,1% a mais que a linha de base 4-hi. Sua configuração 12-hi acrescenta 26,3%.

Essas são estimativas de analistas baseadas em componentes futuros e preços presumidos de memória. Não são cotações de fornecedores nem custos de propriedade medidos em sistemas Rubin Ultra implantados.

Dentro dessas premissas, o throughput cresce mais lentamente que o custo do sistema. O custo resultante por token é maior para ambas as configurações mais altas.

Essa é a afirmação mais forte no caso da SemiAnalysis para HBM 4-hi. Pilhas mais curtas não apenas reduzem a conta de hardware; elas melhoram a produção modelada por unidade de gasto.

A computação em escala de rack torna o argumento mais plausível. Servidores anteriores conectavam oito GPUs, de modo que a memória em cada dispositivo limitava fortemente todo o sistema de serving.

Um sistema H100 HGX fornecia 640GB de HBM agregada. Pesos de modelos grandes podiam ocupar a maior parte dessa capacidade antes de o sistema armazenar qualquer cache KV substancial.

O H200 aliviou essa pressão ao adicionar memória a cada GPU. Naquela etapa, maior capacidade por dispositivo tinha valor operacional imediato.

O GB300 NVL72 muda a escala. A Nvidia conecta 72 GPUs Blackwell Ultra por meio do NVLink, criando um domínio de comunicação compartilhado muito maior.

O rack comporta cerca de 20TB de memória de GPU. Sua capacidade agregada é muito maior que a de um servidor Hopper com oito GPUs.

A SemiAnalysis compara esse crescimento com o Kimi K3, um modelo mixture-of-experts de 2,8 trilhões de parâmetros. Esses modelos ativam apenas um subconjunto de seus especialistas para cada token.

O relatório estima que uma réplica quantizada do Kimi K3 ocupa 1.561GB. Isso consumiria menos de 8% de uma configuração GB300 NVL72 de aproximadamente 21TB.

A quantização representa números com menos bits, reduzindo o armazenamento dos pesos e o tráfego de memória. Ela troca alguma precisão numérica por requisitos de hardware substancialmente menores.

Grandes domínios NVLink também distribuem especialistas entre mais GPUs. Essa organização aumenta as demandas de comunicação, mas reduz a quantidade de pesos do modelo que cada dispositivo precisa manter.

Segundo relatos, o Rubin Ultra amplia o domínio de NVL72 para NVL576. Esse aumento de oito vezes no número de GPUs conectadas pode superar uma redução de um terço na HBM por acelerador.

Assim, a capacidade deixa de ser um problema de GPU individual e se torna uma questão de alocação em nível de rack. Uma implantação pode abrigar um modelo grande usando pilhas de memória local mais finas.

Isso não elimina as restrições de memória. Muda onde os arquitetos as resolvem e qual recurso se torna escasso primeiro.

O Offloading de Cache Ajuda, mas a HBM 4-hi Não É uma Solução Sem Custos

A estratégia de pilhas curtas funciona apenas quando o software, a memória secundária e o comportamento da carga de trabalho impedem que a capacidade reduzida de HBM se torne o gargalo.

A SemiAnalysis testou parte dessa premissa com uma carga de trabalho InferenceX usando Kimi K3 e 16 GPUs GB300. Oito GPUs processaram o prefill, enquanto oito executaram o decode.

O prefill processa o prompt antes de a geração de tokens começar. Separá-lo do decode permite que os operadores ajustem cada fase para comportamentos diferentes de computação e memória.

O experimento reduziu a utilização permitida de HBM de 92% para 85%. Isso é muito menor que o corte de capacidade entre pilhas 8-hi e 4-hi.

No entanto, o limite reduziu substancialmente o espaço disponível para cache KV. A capacidade agregada de KV para serving caiu de 53GB para 34GB por GPU, segundo o relatório.

Para pares desagregados, o orçamento disponível caiu de 44GB para 24GB. Essas mudanças representaram reduções de 36% e 44%.

O throughput permaneceu semelhante na maior parte dos níveis de concorrência testados. A configuração restrita transferiu dados inativos do cache KV para a DRAM comum do servidor.

Esse processo é chamado de offloading de cache KV. Ele mantém as informações acessadas com frequência na HBM, enquanto transfere o estado de conversas menos ativo para uma memória mais lenta e maior.

Cargas de trabalho agentic podem se adequar a essa abordagem. Elas frequentemente pausam enquanto ferramentas são executadas, CPUs executam código ou serviços externos retornam informações.

Durante essas pausas, a GPU não precisa do cache de cada conversa imediatamente. Transferir dados menos ativos pode liberar HBM cara para solicitações ativas.

O teste restrito encontrou um limite claro. Quando a concorrência ultrapassou 70, o throughput caiu quase 30% em comparação com a configuração de maior memória.

A ocupação de KV na GPU havia alcançado 100%. Preempção, transferências repetidas e enfileiramento reduziram então o trabalho útil.

A execução restrita também registrou mais de dez vezes o número de leituras do cache KV baseado em DRAM. O offloading aliviou a pressão de capacidade, mas aumentou o tráfego por uma camada mais lenta.

Esse resultado é ao mesmo tempo favorável e cautelar. Ele mostra que o software pode preservar o desempenho após uma redução significativa de memória, mas apenas abaixo de um limite que depende da carga de trabalho.

Um serviço de produção com muitos usuários simultâneos de contexto longo pode ultrapassar esse limite. Nesse caso, pilhas HBM mais altas podem suportar lotes maiores e maior throughput total.

A capacidade de rede também importa. Distribuir especialistas e caches por centenas de aceleradores cria comunicação all-to-all intensa.

Um sistema pode deixar de ser limitado pela capacidade de memória e passar a ser limitado pela rede. Esse resultado ainda desperdiça HBM extra, mas não garante desempenho geral eficiente.

A DRAM secundária representa outra restrição. A memória de servidor enfrenta sua própria pressão de oferta à medida que os sistemas de IA ampliam a capacidade do lado da CPU.

O offloading também consome energia e acrescenta complexidade operacional. O software precisa decidir o que permanece ativo, o que é transferido e quando os dados devem retornar.

Decisões ruins podem transformar economias de capacidade em picos de latência. A arquitetura exige agendamento cuidadoso, gerenciamento de cache e isolamento de cargas de trabalho.

O crescimento futuro dos modelos representa a maior incerteza. A SemiAnalysis reconhece que sua análise aplica uma carga de trabalho atual a um hardware previsto para mais adiante.

Servidores de IA frequentemente permanecem implantados por mais de cinco anos. Modelos, contextos, concorrência de usuários e cargas de trabalho de raciocínio podem mudar drasticamente nesse período.

O relatório testa sob estresse um modelo com três vezes o tamanho do Kimi K3 e três vezes a necessidade de cache por usuário. Pilhas mais altas tornam-se mais úteis sob essa premissa.

Sua configuração 8-hi entrega 36% mais tokens totais que a 4-hi. A versão 12-hi entrega 47% mais, embora ambas operem a menor velocidade por usuário.

Após incluir os custos estimados, a 8-hi se torna favorável abaixo de 180 tokens por segundo por usuário. O sistema 12-hi ainda não consegue compensar seu aumento de custo modelado.

Esses resultados demonstram por que a HBM 4-hi não pode se tornar uma prescrição universal. A altura de pilha preferida depende do tamanho do modelo, das metas de latência, do batching e da vida útil do sistema.

Sistemas de treinamento continuam sendo um alvo especialmente inadequado para redução agressiva de capacidade. Suas ativações, gradientes e estados do otimizador podem usar toda a memória disponível.

Sistemas de inferência que atendem muitos modelos independentes também precisam de capacidade. Operadores podem valorizar a flexibilidade mais do que o menor custo para uma única carga de trabalho otimizada.

Compradores de hardware enfrentam um problema de opcionalidade. Um acelerador 4-hi pode ser eficiente para o serviço atual, mas restritivo após mudanças nas cargas de trabalho.

Pesquisadores podem adaptar modelos ao hardware instalado. Computação em loop, quantização, especialistas esparsos e caches menores podem reduzir a dependência de parâmetros armazenados.

Essa adaptação não é garantida. Melhorias na qualidade dos modelos podem voltar a resultar de maiores contagens de parâmetros ou de arquiteturas intensivas em memória.

A melhor interpretação é, portanto, mais limitada. A HBM de quatro camadas oferece uma configuração forte para inferência cuidadosamente caracterizada, não uma substituição automática para memórias mais altas.

Menos Camadas Pressionam Fornecedores de Memória e Fabricantes de Sistemas

Se os compradores otimizarem largura de banda em vez de gigabytes, a pressão econômica se deslocará da produção de DRAM para dies base, encapsulamento, redes e integração completa de sistemas.

SK hynix, Samsung e Micron passaram anos desenvolvendo HBM mais densa e mais alta. Seus roteiros enfatizam capacidade, velocidade de sinalização, rendimento de encapsulamento e controle térmico.

A SK hynix começou a fornecer amostras de HBM4 com 12 camadas em 2025. Seu anúncio da HBM4 descreveu pacotes de 36GB com mais de 2TB por segundo de largura de banda.

Essa direção de produto continua útil para treinamento e inferência com alta demanda de capacidade. Uma mudança significativa para 4-hi acrescentaria uma prioridade de compra muito diferente.

Os clientes poderiam exigir largura de banda total da interface com menos dies de núcleo. Os fornecedores enviariam mais pacotes, mas menos bits de DRAM dentro de cada um.

À primeira vista, isso parece negativo para a receita de HBM. Os fornecedores se beneficiaram ao vender mais conteúdo de DRAM especializado em cada geração de aceleradores.

A SemiAnalysis argumenta que o resultado pode ser mais equilibrado. Pilhas mais curtas poderiam melhorar os rendimentos de montagem e aumentar o número de pacotes comercializáveis produzidos a partir de cada wafer.

Um fornecedor também poderia cobrar pelo valor da largura de banda, em vez de tratar a HBM principalmente como um produto vendido por gigabyte. Ainda não está claro se os clientes aceitariam esse modelo.

O benefício para a oferta é mais claro. A passagem de 12-hi para 4-hi triplica teoricamente o número de grupos de dies em pilha disponíveis a partir de uma quantidade fixa de DRAM.

O aumento efetivo pode exceder a proporção simples se pilhas mais curtas elevarem o rendimento de encapsulamento. Ele ficará abaixo dessa proporção quando outros componentes se tornarem restritos.

Cada pacote HBM ainda precisa de um die base, testes, empilhamento e fixação ao lado de um acelerador. Multiplicar a produção de pacotes aumenta a demanda por todas essas etapas.

A HBM4 torna o die base mais importante porque inclui mais lógica e pode usar um processo avançado de foundry. As economias de DRAM não criam capacidade equivalente de foundry.

Mais pacotes de memória também exigem mais pacotes de aceleradores. Esses pacotes requerem interposers, substratos orgânicos, fornecimento de energia, resfriamento e montagem de alta densidade.

O gargalo pode, portanto, migrar em vez de desaparecer. Wafers lógicos, dies base, substratos, placas de circuito e integração de sistemas enfrentariam maior demanda.

Grandes domínios scale-up intensificam outra restrição. Mais aceleradores exigem comutação e redes extensas antes que sua memória agregada se comporte como um recurso compartilhado prático.

O GB300 NVL72 da Nvidia usa nove bandejas NVSwitch para conectar 72 GPUs. Seu tecido NVLink de quinta geração fornece 130TB por segundo de largura de banda agregada.

Os futuros sistemas NVL576 precisarão ampliar essa escala substancialmente. Sua economia depende de a rede permanecer rápida o bastante para suportar especialistas distribuídos e movimentação de cache.

A energia continua sendo o limite final. Dobrar o número de pacotes HBM ricos em largura de banda ajuda apenas quando os operadores conseguem implantar os aceleradores conectados a eles.

Uma estratégia 4-hi pode ampliar a oferta de DRAM sem produzir nova capacidade elétrica. A construção de data centers, o resfriamento e o acesso à rede elétrica ainda determinam a computação utilizável.

Essa pressão explica por que tokens por wafer de HBM é uma métrica útil, mas não completa. Os operadores precisam otimizar juntos os tokens por watt, rack, porta de rede e orçamento de capital.

A mudança também afetaria os mercados convencionais de memória. A produção de HBM compete com DRAM para servidores, PCs e dispositivos móveis por recursos de fabricação.

Usar menos dies de núcleo de HBM pode devolver parte da capacidade de wafer a esses produtos. Esse alívio importa à medida que a memória do lado da CPU cresce junto com as implantações de IA agentic.

No entanto, o benefício depende da adoção real. Um projeto 4-hi que possibilite muito mais remessas de aceleradores pode consumir parte das economias por meio de maior volume total de unidades.

Os fornecedores de memória também podem resistir a uma mudança rápida se ela enfraquecer a demanda por bits. Sua resposta aparecerá na disponibilidade de produtos, nos cronogramas de qualificação e na alocação de capacidade.

A principal disputa, portanto, não é Nvidia contra um fornecedor de memória. É o design de inferência orientado à largura de banda contra a economia de HBM orientada à capacidade.

Esse mapa de concorrência deixa claras as consequências para o setor. Pilhas mais baixas vencem quando a largura de banda gera receita e os gigabytes instalados não.

Pilhas mais altas vencem quando os clientes conseguem converter capacidade adicional em lotes maiores, mais modelos ou maior flexibilidade de hardware ao longo do tempo.

Três Sinais Mostrarão se a HBM 4-hi Realmente Vence

A tese das pilhas curtas só se torna crível quando roadmaps de produto, disponibilidade de produção e resultados medidos de inferência convergem.

O primeiro sinal é a configuração final do Rubin Ultra da Nvidia. A documentação pública precisa confirmar capacidade de memória, altura da pilha, largura de banda e a arquitetura do sistema NVL576.

Uma configuração confirmada de 192GB usando HBM 8-hi apoiaria o argumento direcional. Um retorno ao modelo 12-hi enfraqueceria as alegações de que os requisitos de capacidade relaxaram de forma ampla.

Um produto Rubin comercial com 4-hi forneceria evidências muito mais fortes. Até lá, a proposta de HBM 4-hi da SemiAnalysis continua sendo uma previsão bem fundamentada sobre futuros ASICs e aceleradores.

O segundo sinal é a qualificação, pelos fornecedores, de HBM4 ou HBM4E 4-hi de alta velocidade. Os fabricantes precisam oferecer esses pacotes nas taxas de sinalização exigidas pelos projetistas de aceleradores.

A largura nominal da interface, por si só, não basta. Os produtos precisam apresentar rendimentos aceitáveis, desempenho térmico, confiabilidade e performance sustentada em sistemas completos.

Observe se SK hynix, Samsung ou Micron adicionam configurações 4-hi aos roadmaps públicos. A distribuição de amostras aos clientes mostraria que as pilhas curtas foram além dos estudos internos de arquitetura.

Observe também o modelo de precificação. Se os custos da 4-hi escalarem principalmente com sua menor capacidade, sua economia de largura de banda se torna atraente.

Se os fornecedores concentrarem a maior parte do valor no die base e na interface, a economia esperada poderá diminuir. A escassez de pacotes também pode manter prêmios elevados apesar do menor conteúdo de DRAM.

O terceiro sinal é a realização de testes independentes de inferência em diferentes cargas de trabalho. Os benchmarks precisam incluir assistentes interativos, serviços agênticos, solicitações de contexto longo e implantações com grandes lotes.

A taxa média de tokens não será suficiente. Os testes precisam avaliar velocidade por usuário, comportamento de filas, taxas de acerto de cache, tráfego de offload e latência de cauda.

Os resultados também devem comparar modelos que diferem em tamanho e arquitetura. Uma configuração otimizada para Kimi K3 não pode determinar a melhor escolha para todos os futuros modelos de fronteira.

A evidência decisiva será uma vantagem estável de custo por token sob metas realistas de nível de serviço. Essa vantagem precisa se manter sob alta concorrência e mudanças na composição das cargas de trabalho.

Os desenvolvedores devem se importar porque as restrições de hardware moldam o design dos modelos. A memória disponível influencia a quantização, o posicionamento de especialistas, o tratamento de contexto e a política de cache.

Os compradores corporativos devem se importar porque a capacidade de destaque pode ser enganosa. Mais HBM não garante inferência mais útil quando a largura de banda, a rede ou a latência define o limite.

As equipes de infraestrutura devem avaliar os conjuntos de trabalho no nível do rack. Elas devem separar cargas de treinamento, prefill, decode e agênticas antes de selecionar um único perfil de memória.

Também devem preservar margem operacional. Um sistema 4-hi estreitamente otimizado pode perder sua vantagem quando a demanda muda para lotes maiores ou mais modelos simultâneos.

A lição mais ampla não é que menos memória sempre vence. É que a memória deve ser adquirida de acordo com o recurso que a carga de trabalho realmente consome.

Para inferência interativa, esse recurso costuma ser a largura de banda. A HBM de quatro camadas pode manter todo o caminho externo de dados usando menos dies escassos de DRAM.

Isso torna a análise de HBM 4-hi da SemiAnalysis um sério desafio às premissas do setor em favor das pilhas mais altas. As próximas divulgações de produtos mostrarão se as equipes de hardware concordam.

Antes de se comprometer com uma futura frota de aceleradores, faça três perguntas. O conjunto de trabalho cabe na escala do rack, os dados frios de cache podem ser movidos com segurança e a capacidade adicional aumenta o throughput útil?

Se as respostas apontarem para a largura de banda, o rei baixo merece um lugar no roadmap.