HBF em Computação de IA: HBF Não É Uma Versão Mais Barata da HBM: Cargas de Trabalho Orientadas à Capacidade e de Baixa Largura de Banda Representam uma Oportunidade, Enquanto a Inferência Densa e de Lotes Elevados Pode se Tornar uma Armadilha de Custo

Visão geral

Este tutorial da Hot Chips 2026 examina os limites de aplicabilidade da HBF na inferência de IA sob a perspectiva da arquitetura de sistemas. Sua conclusão central é que a HBF deriva seu valor da alta capacidade, e não da alta largura de banda: ela pode aprimorar MoE de lotes pequenos, KV esparso de contexto longo e armazenamento local de especialistas, mas a HBM continua sendo a escolha mais econômica para modelos densos, lotes grandes ou implantações que enfatizam o throughput de rack.

Visões principais

O relatório primeiro posiciona a HBF em um panorama de tecnologia de memória descrito por β e α: β representa o custo por GB, enquanto α representa a largura de banda disponível por unidade de capacidade. A HBF ocupa uma posição orientada à capacidade, de baixo β e baixo α, e pode fornecer aproximadamente 8—16 vezes a capacidade da HBM ao mesmo custo, mas não deve ser vista como uma versão mais barata da HBM. O relatório usa a fórmula “$mem = β·max(C, I·b/α)” para determinar o custo de memória, em que C é a quantidade de dados que deve ser acomodada e I·b é o requisito de largura de banda. O que realmente determina a economia não é quantos GB baratos são adquiridos, mas o maior entre a restrição de capacidade e a restrição de largura de banda de fornecimento de dados. Portanto, baixo $/GB não significa automaticamente baixo $/token. As características da carga de trabalho determinam se a HBF se enquadra em sua faixa efetiva. Modelos MoE podem armazenar integralmente vastos pesos de especialistas, mas cada token ativa apenas um pequeno número de especialistas. Assim, com tamanho de lote B pequeno e menor intensidade de acesso I, o modelo é limitado principalmente pela capacidade, e baixa largura de banda pode ser suficiente. Modelos densos exigem leituras de pesos mais amplas; à medida que o tamanho do lote, a intensidade de acesso ou I·b aumentam, a largura de banda insuficiente da HBF força o sistema a provisionar mais capacidade para atender aos requisitos de fornecimento de dados e, além do ponto de cruzamento, a HBM passa a ser mais barata. Portanto, o relatório limita a vantagem da HBF à sub-região MoE de “B pequeno, I baixo”, deixando cargas de trabalho densas e de B alto para a HBM. A comparação de implantação inclui configurações totalmente HBM, totalmente HBF e uma híbrida “2×HBF＋6×HBM”. Todas as três podem alcançar o mesmo custo, mas oferecem capacidades e larguras de banda diferentes. Em simulações de contexto curto e lote pequeno, a HBF pode vencer em custo, mas aproximadamente 85% de sua capacidade permanece ociosa; a HBM, por sua vez, pode cobrar por desempenho além do limite de capacidade. Em casos de contexto longo, mais capacidade também não é necessariamente melhor: a capacidade adicional só tem valor econômico quando I·b permanece baixo. A configuração híbrida tenta usar a HBM como cache de especialistas quentes, mas a popularidade dos especialistas tende a se achatar sob consultas mistas, de modo que o cache é eficaz apenas em tamanhos de lote baixos ou quando consultas semelhantes são agrupadas para processamento. O relatório também realiza uma simulação de 72 GPUs, em nível de rack e centrada em decodificação, usando o modelo Kimi-K2 1T em FP4. O contexto principal consiste em 1 milhão de tokens de entrada e 1.000 tokens de saída, complementado por cenários de 32k/8k e 1k/8k. O tamanho de lote por instância de paralelismo de dados varia de 1—512; o paralelismo de tensor é usado para atender aos requisitos de capacidade, o paralelismo de dados preenche o rack e o custo é expresso como uma razão após amortizar despesas de capital e operacionais ao longo de três anos. A configuração totalmente HBM é TP8·DP9, a totalmente HBF é TP1·DP72 e a híbrida é TP2·DP36. A capacidade por instância de paralelismo de dados para as configurações totalmente HBM, totalmente HBF e híbrida é de 2,3 TB, 4,1 TB e 2,5 TB, respectivamente; a capacidade total do rack é de 20,7 TB, 294,9 TB e 89,3 TB, respectivamente, equivalente a 1 vez, aproximadamente 14 vezes e 4,3 vezes. A expansão de capacidade vem acompanhada de um custo de largura de banda. A largura de banda agregada do rack é de 1.584 TB/s para HBM total e 922 TB/s, ou aproximadamente 0,6 vez tanto, para HBF total; a configuração híbrida fornece 1.418→279 TB/s. A largura de banda por GPU correspondente é de 22,0 TB/s, 12,8 TB/s e 19,7→3,9 TB/s, respectivamente. Com custo de rack e consumo de energia comparáveis, o relatório conclui que a HBM sempre pode processar mais tokens. A HBF é mais adequada para implantações limitadas pela capacidade de uma única máquina ou instância, pois pode acomodar em uma única GPU um modelo que, de outra forma, exigiria múltiplas GPUs. Em outras palavras, “custo por token em nível de rack” e “se o modelo cabe em uma máquina” levam a escolhas de memória diferentes. As características de hardware da HBF também restringem como ela pode ser usada. As três classes listadas no relatório fornecem largura de banda máxima ao usuário de 0,384, 1,536 e 3,072 TB/s, respectivamente, com taxas de interconexão de 8, 16 e 32 GT/s; as configurações de capacidade incluem 256 GiB de 8 camadas e 512 GiB de 16 camadas. A interface suporta leituras de 64 B—4 KiB, escritas de 4 KiB e páginas de 4 KiB, enquanto alcançar a largura de banda máxima requer leituras de 64 KB e escritas de 1 MB alinhadas a 64 KB. A HBF realiza leituras e escritas via DMA e não faz parte da hierarquia de cache da GPU; quando usada juntamente com HBM, requer gerenciamento de memória independente. Seu tempo de retenção de dados ligada a 85°C é de aproximadamente 24 horas, seu ciclo de vida deve ser gerenciado pelo host e as escritas devem ser cuidadosamente controladas para alcançar uma vida útil de aproximadamente 10 anos ou evitar esgotar 100% da endurance. Em geral, é um meio otimizado para leitura, restrito para escrita e gerenciado pelo host, tornando o posicionamento de dados principalmente um problema de software. Quanto ao ecossistema de software, o relatório trata o vLLM como o foco padrão atual para implantação em produção, ao mesmo tempo em que lista mecanismos de inferência de uso geral como SGLang, LMDeploy e Modular MAX, além de stacks otimizadas por fornecedores como TensorRT-LLM, OpenVINO, AWS Neuron e Google JetStream. Os caminhos existentes do vLLM visam principalmente CPUs ou LMCache e não suportam diretamente HBF. O uso de HBF requer um novo alocador ou backend, políticas de posicionamento de dados quentes/frios, pré-busca assíncrona e telemetria de endurance; caso contrário, sua vantagem de capacidade de hardware não pode ser convertida em ganhos de inferência em produção. O exemplo Kimi K3 demonstra um esquema relativamente claro de posicionamento de dados. O modelo de 2,8T possui pesos totais de 1,56 TB, dos quais 93% dos bytes, aproximadamente 1,45 TB, são pesos de especialistas MoE com características de escrita única e leitura fria que o relatório considera adequadas para um pool de especialistas HBF. Os 7% restantes, aproximadamente 110 GB de pesos, são mais adequados para HBM. O Cache KV para cada sequência de 1 milhão de tokens é de aproximadamente 30 GB. A HBF também pode servir como pool de offload de KV e cache de prefixo, substituindo a DRAM do host fixada por maior capacidade. Isso cria uma arquitetura em camadas: a HBF armazena vastos pesos de especialistas relativamente frios e KV descarregado, enquanto a HBM armazena pesos ativos e dados de alta largura de banda. A atenção esparsa amplia ainda mais a aplicabilidade da HBF. Para KV de contexto longo ou múltiplas interações, o sistema pode reter o contexto completo a baixo custo enquanto lê apenas a porção top-k. O relatório fornece uma razão de leitura de φ＝top-k/contexto de aproximadamente 1%—2%, abaixo do limiar φ*=α/l. Nessa condição, a capacidade da HBF pode reter todo o KV, enquanto o menor volume de leitura evita atingir o limite de largura de banda. Contudo, essa vantagem depende explicitamente de modelos de atenção esparsa como DSA, CSA e Kimi-Linear e não se aplica a arquiteturas que exigem leituras densas de todo o contexto. A capacidade da HBF também pode reduzir a comunicação de paralelismo de especialistas. Um exemplo convencional distribui especialistas por 8 GPUs e realiza all-to-all em cada camada. Se dois nós puderem armazenar especialistas localmente em HBF, o particionamento de paralelismo de especialistas pode ser reduzido, diminuindo significativamente ou eliminando a comunicação all-to-all. Portanto, a capacidade não apenas resolve se um modelo cabe, mas também pode recuperar parte da sobrecarga de comunicação, embora o benefício ainda dependa da localidade de acesso aos especialistas e da largura de banda de pré-busca. A conclusão final é que a HBF é uma ferramenta de precisão, e não uma substituição universal: ela oferece uma vantagem de custo apenas para cenários MoE de demanda de baixa largura de banda, lote pequeno/baixa intensidade de acesso e KV esparso com contextos longos; fora dessa faixa, pode se tornar uma armadilha. Para ampliar seu valor, a largura de banda de leitura α deve aumentar, a diferença de custo por GB β em relação à HBM deve permanecer suficientemente grande, e questões de endurance de escrita, largura de banda de escrita, latência e suporte de software também devem ser resolvidas.

Estrutura de análise

O relatório primeiro estabelece uma equação de custo de memória usando β, α, capacidade C e requisito de largura de banda I·b, depois segmenta cargas de trabalho por MoE versus Dense, tamanho de lote, comprimento de contexto e esparsidade de acesso. Posteriormente, compara configurações totalmente HBM, totalmente HBF e híbridas e usa uma simulação de rack com 72 GPUs do Kimi-K2 para avaliar capacidade, largura de banda e custos amortizados em três anos. Por fim, combina o layout de dados do Kimi K3, o caminho de software vLLM, atenção esparsa e comunicação de paralelismo de especialistas para determinar as condições e limites de implantação da HBF.

Notas metodológicas

• (Método Fora do Vocabulário)Outro

  Equação de Custo de Memória β—α

  O relatório usa β para representar o custo por GB e α para representar a largura de banda por unidade de capacidade, e compara o custo de memória necessário para atender às necessidades de capacidade e largura de banda de fornecimento de dados por meio de $mem = β·max(C, I·b/α), explicando por que um baixo preço por GB não reduz necessariamente o custo por token.

• (Método Fora do Vocabulário)Outro

  Simulação de Custo por Token em Nível de Rack

  Sob as mesmas premissas de rack com 72 GPUs, custo e consumo de energia, o relatório ajusta as configurações de paralelismo de tensor e de dados para comparar a capacidade e a largura de banda de memória totalmente HBM, totalmente HBF e híbrida, avaliando a economia da inferência com base em despesas de capital e operacionais amortizadas em três anos.

• Estrutura de Análise de Indústria/SetorAnálise do Efeito de Substituição

  Limites Baseados em Carga de Trabalho para Substituição por HBF

  Em vez de tratar a HBF como uma substituição abrangente da HBM, o relatório determina os pools de dados específicos nos quais ela pode substituir HBM ou DRAM do host com base em MoE versus Dense, tamanho de lote, esparsidade de contexto e escala de implantação.

Mapeamento e comparação de ativos

Mapeamento estruturado da tese para ativos nomeados (pontos fortes, pontos fracos, pares e riscos).

• HBF

  Funciona como uma camada de memória de alta capacidade e baixa largura de banda na inferência de IA e pode acomodar pools de especialistas MoE, KV descarregado e caches de prefixo.

  Pontos fortes

  Ao mesmo custo, a capacidade pode alcançar aproximadamente 8—16 vezes a da HBM; é adequada para dados de escrita única e leitura fria e pode reduzir o particionamento de especialistas e a comunicação all-to-all.

  Pontos fracos

  Possui menor largura de banda, escritas restritas e requer DMA e gerenciamento de memória independente, enquanto o suporte de software de produção permanece incompleto.

  Comparação

  Na simulação com 72 GPUs, a capacidade é aproximadamente 14 vezes a da HBM total, mas a largura de banda agregada é aproximadamente 0,6 vez maior; o throughput de tokens em nível de rack é inferior ao da HBM.

  Riscos

  Se o tamanho de lote ou a intensidade de acesso aumentarem, ou se as leituras de atenção não forem esparsas, o limite de largura de banda a transformará de uma solução de capacidade de baixo custo em uma armadilha de custo.

• HBM

  Usada para pesos ativos de alta largura de banda e inferência densa ou de lotes elevados, servindo como a solução de memória de referência do relatório.

  Pontos fortes

  Oferece maior largura de banda e throughput de tokens em nível de rack e é adequada para dados Dense, B alto e frequentemente acessados.

  Pontos fracos

  Seu custo por GB é mais alto e, quando a capacidade é restrita, é necessário paralelismo de tensor adicional ou GPUs para acomodar o modelo.

  Comparação

  O rack totalmente HBM possui 20,7 TB de capacidade e 1.584 TB/s de largura de banda agregada; o rack totalmente HBF possui 294,9 TB e 922 TB/s, respectivamente.

  Riscos

  Em cargas de trabalho de baixa largura de banda limitadas principalmente pela capacidade de uma única máquina, os usuários podem pagar por largura de banda além dos requisitos reais.

Dados principais

• Posicionamento de Capacidade Relativa da HBFAproximadamente 8—16× a capacidade da HBM ao mesmo custoA HBF troca menor largura de banda por uma vantagem de capacidade e não é uma versão mais barata da HBM.
• Largura de Banda Máxima ao Usuário das Três Classes de HBF0,384 / 1,536 / 3,072 TB/sCorrespondente à Classe 1, Classe 2 e Classe 3.
• Taxas de Interconexão da HBF8 / 16 / 32 GT/sCorrespondente às três classes de hardware.
• Configurações de Capacidade da HBF256 GiB de 8 camadas; 512 GiB de 16 camadasRefletindo seu posicionamento de alta capacidade.
• Capacidade de Rack com 72 GPUsHBM 20,7 TB; HBF 294,9 TB; híbrida 89,3 TBEquivalente a 1×, aproximadamente 14× e 4,3×, respectivamente.
• Capacidade por Instância de Paralelismo de DadosHBM 2,3 TB; HBF 4,1 TB; híbrida 2,5 TBAs configurações de simulação são TP8·DP9, TP1·DP72 e TP2·DP36, respectivamente.
• Largura de Banda Agregada do RackHBM 1.584 TB/s; HBF 922 TB/s; híbrida 1.418→279 TB/sA HBF total é aproximadamente 0,6× a HBM total.
• Largura de Banda por GPUHBM 22,0 TB/s; HBF 12,8 TB/s; híbrida 19,7→3,9 TB/sRefletindo o custo de largura de banda das configurações de alta capacidade.
• Modelo de Simulação de RackKimi-K2 1T @ FP4O contexto principal é de 1 milhão de tokens de entrada/1.000 tokens de saída, com tamanho de lote de 1—512 por DP.
• Base de CustoAmortização de três anosInclui despesas de capital e operacionais e é apresentada como uma razão.
• Utilização de Capacidade HBF em Lotes PequenosAproximadamente 85% de capacidade ociosaEmbora a HBF tenha uma vantagem de custo com B baixo, uma grande quantidade de capacidade permanece sem uso.
• Pesos Totais do Kimi K31,56 TBO tamanho do modelo é 2,8T.
• Pesos de Especialistas MoE1,45 TB, correspondendo a 93% dos bytesEles têm características de escrita única e leitura fria, que o relatório considera adequadas para HBF.
• Pesos Restantes110 GB, correspondendo a 7%O relatório os considera mais adequados para HBM.
• Cache KV por Sequência Longa30 GB/sequência de 1 milhão de tokensA HBF pode ser usada para um pool de offload de KV e cache de prefixo.
• Razão de Leitura de Atenção Esparsaφ aproximadamente 1%—2%O relatório afirma que isso está abaixo do limiar φ*=α/l, permitindo que todo o KV seja armazenado em HBF enquanto apenas top-k é lido.
• Retenção de Dados LigadaAproximadamente 24 horas a 85°CO host deve gerenciar o ciclo de vida dos dados.
• Vida Útil AlvoAproximadamente 10 anosAs escritas devem ser cuidadosamente gerenciadas; caso contrário, 100% da endurance poderá ser esgotada.

Impacto e implicações

O relatório argumenta que as configurações de memória para IA devem ser determinadas conjuntamente pela carga de trabalho e pela escala de implantação, em vez de apenas comparar o preço por GB. A HBF pode acomodar modelos extremamente grandes ou pools de KV em menos GPUs, em uma única máquina ou em nós locais, e pode reduzir a comunicação de paralelismo de especialistas. No entanto, ao buscar alto throughput de rack, usar modelos densos ou aumentar o tamanho de lote, sua baixa largura de banda eleva o custo por token. As implantações reais têm maior probabilidade de usar uma abordagem em camadas: a HBF carrega vastos dados frios, enquanto a HBM retém dados ativos e sensíveis à largura de banda.

Riscos

• À medida que o tamanho de lote, a intensidade de acesso ou I·b aumentam, a HBF atingirá o limite de largura de banda, e a HBM poderá se tornar a escolha de menor custo.
• O cache de especialistas quentes pode falhar sob consultas mistas porque a popularidade dos especialistas tende a se achatar.
• A endurance de escrita, a largura de banda de escrita e a latência da HBF exigem gerenciamento rigoroso no lado do host; caso contrário, a vida útil e a disponibilidade podem ser afetadas.
• Os caminhos existentes do vLLM visam principalmente CPUs ou LMCache e não possuem alocador HBF, políticas de posicionamento, pré-busca assíncrona e telemetria de endurance.
• A vantagem em cenários de KV esparso depende de modelos de atenção esparsa; ela não se aplica quando o contexto é lido densamente.

Pontos a observar

• Monitorar se a largura de banda de leitura α da HBF pode aumentar e se a diferença de custo por GB β em relação à HBM pode ser mantida.
• Monitorar se os problemas de endurance de escrita, largura de banda de escrita e latência podem ser resolvidos.
• Monitorar se mecanismos de inferência como vLLM adicionam backends HBF, alocadores dedicados, políticas de posicionamento, pré-busca assíncrona e telemetria de endurance.
• Monitorar a localidade de acesso multiagente, os limites de largura de banda de pré-busca e a adequação entre configurações de memória e cargas de trabalho.
• Monitorar se modelos de atenção esparsa e o agrupamento de consultas semelhantes podem manter a razão de acesso real dentro da faixa efetiva da HBF.