HBF en Computación de IA: HBF No Es una Versión Más Barata de HBM: Las Cargas de Trabajo Orientadas a Capacidad y de Bajo Ancho de Banda Representan una Oportunidad, Mientras que la Inferencia Densa y de Lotes Grandes Podría Convertirse en una Trampa de Costos

Visión general

Este tutorial de Hot Chips 2026 examina los límites de aplicabilidad de HBF en la inferencia de IA desde una perspectiva de arquitectura de sistemas. Su conclusión central es que HBF deriva su valor de su alta capacidad en lugar de un alto ancho de banda: puede mejorar MoE de lotes pequeños, KV disperso de contexto largo y el almacenamiento local de expertos, pero HBM sigue siendo la opción más económica para modelos densos, lotes grandes o implementaciones que enfatizan el rendimiento de rack.

Perspectivas principales

El informe sitúa primero a HBF en un panorama de tecnología de memoria descrito por β y α: β representa el costo por GB, mientras que α representa el ancho de banda disponible por unidad de capacidad. HBF ocupa una posición orientada a capacidad, de β bajo y α bajo, y puede proporcionar aproximadamente 8—16 veces la capacidad de HBM al mismo costo, pero no debe considerarse una versión más barata de HBM. El informe utiliza la fórmula “$mem = β·max(C, I·b/α)” para determinar el costo de memoria, donde C es la cantidad de datos que debe alojarse e I·b es el requisito de ancho de banda. Lo que realmente determina la economía no es cuántos GB baratos se compran, sino el mayor entre la restricción de capacidad y la restricción de ancho de banda de suministro de datos. Por lo tanto, un bajo $/GB no significa automáticamente un bajo $/token. Las características de la carga de trabajo determinan si HBF se encuentra dentro de su rango efectivo. Los modelos MoE pueden almacenar enormes pesos de expertos en su totalidad, pero cada token activa solo un pequeño número de expertos. Así, con un tamaño de lote pequeño B y una menor intensidad de acceso I, el modelo está limitado principalmente por la capacidad más que por el ancho de banda, y un ancho de banda bajo puede ser suficiente. Los modelos densos requieren lecturas de pesos más amplias; a medida que aumentan el tamaño de lote, la intensidad de acceso o I·b, el ancho de banda insuficiente de HBF obliga al sistema a aprovisionar más capacidad para satisfacer los requisitos de suministro de datos y, más allá del punto de cruce, HBM se vuelve más barato. Por ello, el informe limita la ventaja de HBF a la subregión MoE de “B pequeño, I bajo”, dejando las cargas de trabajo Dense y de B alto para HBM. La comparación de implementación incluye configuraciones totalmente HBM, totalmente HBF y una híbrida de “2×HBF＋6×HBM”. Las tres pueden lograr el mismo costo, pero ofrecen distinta capacidad y ancho de banda. En simulaciones de contexto corto y lotes pequeños, HBF puede ganar en costo, pero aproximadamente el 85% de su capacidad permanece ociosa; HBM, mientras tanto, puede cobrar por rendimiento más allá del límite de capacidad. En casos de contexto largo, una mayor capacidad tampoco es necesariamente mejor: la capacidad adicional tiene valor económico solo cuando I·b se mantiene bajo. La configuración híbrida intenta usar HBM como caché de expertos activos, pero la popularidad de los expertos tiende a aplanarse bajo consultas mixtas, por lo que el almacenamiento en caché es efectivo solo con tamaños de lote bajos o cuando se agrupan consultas similares para su procesamiento. El informe también realiza una simulación de 72 GPU a nivel de rack y centrada en decodificación usando el modelo Kimi-K2 1T en FP4. El contexto principal consta de 1 millón de tokens de entrada y 1,000 tokens de salida, complementado por escenarios de 32k/8k y 1k/8k. El tamaño de lote por instancia de paralelismo de datos varía de 1—512; se usa paralelismo tensorial para cumplir los requisitos de capacidad, el paralelismo de datos llena el rack y el costo se expresa como una proporción tras amortizar los gastos de capital y operativos durante tres años. La configuración totalmente HBM es TP8·DP9, la totalmente HBF es TP1·DP72 y la híbrida es TP2·DP36. La capacidad por instancia de paralelismo de datos para las configuraciones totalmente HBM, totalmente HBF e híbrida es de 2.3 TB, 4.1 TB y 2.5 TB, respectivamente; la capacidad total del rack es de 20.7 TB, 294.9 TB y 89.3 TB, respectivamente, equivalentes a 1 vez, aproximadamente 14 veces y 4.3 veces. La expansión de capacidad conlleva un costo de ancho de banda. El ancho de banda agregado del rack es de 1,584 TB/s para totalmente HBM y de 922 TB/s, o aproximadamente 0.6 veces, para totalmente HBF; la configuración híbrida ofrece 1,418→279 TB/s. El ancho de banda por GPU correspondiente es de 22.0 TB/s, 12.8 TB/s y 19.7→3.9 TB/s, respectivamente. Con costos y consumo de energía de rack comparables, el informe concluye que HBM siempre puede procesar más tokens. HBF es más adecuado para implementaciones limitadas por la capacidad de una sola máquina o una sola instancia, porque puede alojar en una única GPU un modelo que de otro modo requeriría múltiples GPU. En otras palabras, el “costo por token a nivel de rack” y “si el modelo cabe en una máquina” conducen a distintas elecciones de memoria. Las características de hardware de HBF también restringen cómo puede utilizarse. Los tres grados enumerados en el informe proporcionan anchos de banda máximos de usuario de 0.384, 1.536 y 3.072 TB/s, respectivamente, con velocidades de interconexión de 8, 16 y 32 GT/s; las configuraciones de capacidad incluyen 256 GiB de 8 capas y 512 GiB de 16 capas. La interfaz admite lecturas de 64 B—4 KiB, escrituras de 4 KiB y páginas de 4 KiB, mientras que lograr el ancho de banda máximo requiere lecturas de 64 KB y escrituras de 1 MB alineadas a 64 KB. HBF realiza lecturas y escrituras mediante DMA y no forma parte de la jerarquía de caché de la GPU; cuando se usa junto con HBM, requiere gestión de memoria independiente. Su tiempo de retención de datos encendido a 85°C es de aproximadamente 24 horas, su ciclo de vida debe ser gestionado por el host y las escrituras deben controlarse cuidadosamente para lograr una vida útil de aproximadamente 10 años o evitar agotar el 100% de la resistencia. En general, es un medio optimizado para lectura, restringido para escritura y gestionado por el host, lo que convierte la colocación de datos principalmente en un problema de software. Respecto al ecosistema de software, el informe considera vLLM como el enfoque predeterminado actual para la implementación en producción, al tiempo que enumera motores de inferencia de propósito general como SGLang, LMDeploy y Modular MAX, así como stacks optimizados por proveedores como TensorRT-LLM, OpenVINO, AWS Neuron y Google JetStream. Las rutas existentes de vLLM se dirigen principalmente a CPU o LMCache y no admiten HBF directamente. El uso de HBF requiere un nuevo asignador o backend, políticas de colocación de datos calientes/fríos, prefetching asíncrono y telemetría de resistencia; de lo contrario, su ventaja de capacidad de hardware no puede convertirse en ganancias de inferencia en producción. El ejemplo de Kimi K3 demuestra un esquema de colocación de datos relativamente claro. El modelo de 2.8T tiene pesos totales de 1.56 TB, de los cuales el 93% de los bytes, aproximadamente 1.45 TB, son pesos de expertos MoE con características de escritura única y lectura en frío que el informe considera adecuados para un pool de expertos HBF. El 7% restante, aproximadamente 110 GB de pesos, es más adecuado para HBM. La caché KV para cada secuencia de 1 millón de tokens es de aproximadamente 30 GB. HBF también puede servir como pool de descarga de KV y caché de prefijos, reemplazando DRAM de host fijada con mayor capacidad. Esto crea una arquitectura por niveles: HBF almacena grandes pesos de expertos relativamente fríos y KV descargado, mientras que HBM almacena pesos activos y datos de alto ancho de banda. La atención dispersa amplía aún más la aplicabilidad de HBF. Para KV de contexto largo o de múltiples turnos, el sistema puede retener el contexto completo a bajo costo mientras lee solo la porción top-k. El informe proporciona una proporción de lectura de φ＝top-k/context de aproximadamente 1%—2%, por debajo del umbral φ*=α/l. Bajo esta condición, la capacidad de HBF puede retener todo el KV, mientras que el menor volumen de lectura evita alcanzar el límite de ancho de banda. Sin embargo, esta ventaja depende explícitamente de modelos de atención dispersa como DSA, CSA y Kimi-Linear, y no se aplica a arquitecturas que requieren lecturas densas de todo el contexto. La capacidad de HBF también puede reducir la comunicación paralela de expertos. Un ejemplo convencional fragmenta expertos entre 8 GPU y realiza all-to-all en cada capa. Si dos nodos pueden almacenar expertos localmente en HBF, la fragmentación paralela de expertos puede reducirse, disminuyendo significativamente o eliminando la comunicación all-to-all. Por lo tanto, la capacidad no solo resuelve si un modelo cabe, sino que también puede recuperar parte de la sobrecarga de comunicación, aunque el beneficio sigue dependiendo de la localidad de acceso a expertos y del ancho de banda de prefetch. La conclusión final es que HBF es una herramienta de precisión y no un reemplazo universal: ofrece una ventaja de costo únicamente para MoE de lotes pequeños/baja intensidad de acceso y escenarios de KV disperso con contextos largos de baja demanda de ancho de banda; fuera de este rango, puede convertirse en una trampa. Para ampliar su valor, el ancho de banda de lectura α debe aumentar, la brecha de costo por GB β respecto a HBM debe mantenerse suficientemente amplia y también deben resolverse los problemas de resistencia de escritura, ancho de banda de escritura, latencia y soporte de software.

Marco de análisis

El informe establece primero una ecuación de costo de memoria utilizando β, α, capacidad C y requisito de ancho de banda I·b, y luego segmenta las cargas de trabajo según MoE frente a Dense, tamaño de lote, longitud de contexto y dispersión de acceso. Posteriormente compara configuraciones totalmente HBM, totalmente HBF e híbridas, y utiliza una simulación de rack de 72 GPU de Kimi-K2 para evaluar capacidad, ancho de banda y costos amortizados a tres años. Finalmente, combina la disposición de datos de Kimi K3, la ruta de software vLLM, la atención dispersa y la comunicación paralela de expertos para determinar las condiciones y límites de implementación de HBF.

Notas metodológicas

• (Método Fuera de Vocabulario)Otro

  Ecuación de Costo de Memoria β—α

  El informe utiliza β para representar el costo por GB y α para representar el ancho de banda por unidad de capacidad, y compara el costo de memoria necesario para satisfacer las necesidades de capacidad y de ancho de banda de suministro de datos mediante $mem = β·max(C, I·b/α), explicando por qué un bajo precio por GB no necesariamente reduce el costo por token.

• (Método Fuera de Vocabulario)Otro

  Simulación de Costo por Token a Nivel de Rack

  Bajo los mismos supuestos de rack de 72 GPU, costo y consumo de energía, el informe ajusta las configuraciones de paralelismo tensorial y paralelismo de datos para comparar la capacidad y el ancho de banda de memoria totalmente HBM, totalmente HBF e híbrida, evaluando la economía de inferencia con base en gastos de capital y operativos amortizados durante tres años.

• Marco de Análisis de Industria/SectorAnálisis del Efecto de Sustitución

  Límites Basados en la Carga de Trabajo para la Sustitución por HBF

  En lugar de tratar HBF como un reemplazo integral de HBM, el informe determina los pools de datos específicos en los que puede sustituir HBM o DRAM de host según MoE frente a Dense, tamaño de lote, dispersión del contexto y escala de implementación.

Correspondencia y comparación de activos

Correspondencia estructurada entre la tesis y activos concretos (fortalezas, debilidades, pares y riesgos).

• HBF

  Sirve como un nivel de memoria de alta capacidad y bajo ancho de banda en la inferencia de IA y puede alojar pools de expertos MoE, KV descargado y cachés de prefijos.

  Fortalezas

  Al mismo costo, la capacidad puede alcanzar aproximadamente 8—16 veces la de HBM; es adecuada para datos de escritura única y lectura en frío, y puede reducir la fragmentación de expertos y la comunicación all-to-all.

  Debilidades

  Tiene menor ancho de banda, escrituras restringidas y requiere DMA y gestión de memoria independiente, mientras que el soporte de software de producción sigue incompleto.

  Comparación

  En la simulación de 72 GPU, la capacidad es aproximadamente 14 veces la de totalmente HBM, pero el ancho de banda agregado es aproximadamente 0.6 veces mayor; el rendimiento de tokens a nivel de rack es inferior al de HBM.

  Riesgos

  Si aumentan el tamaño de lote o la intensidad de acceso, o si las lecturas de atención no son dispersas, el límite de ancho de banda lo transformará de una solución de capacidad de bajo costo en una trampa de costos.

• HBM

  Se utiliza para pesos activos de alto ancho de banda e inferencia densa o de lotes grandes, y sirve como la solución de memoria de referencia del informe.

  Fortalezas

  Ofrece mayor ancho de banda y rendimiento de tokens a nivel de rack, y es adecuada para datos Dense, B alto y de acceso frecuente.

  Debilidades

  Su costo por GB es mayor y, cuando la capacidad está restringida, se requiere paralelismo tensorial adicional o más GPU para alojar el modelo.

  Comparación

  El rack totalmente HBM tiene 20.7 TB de capacidad y 1,584 TB/s de ancho de banda agregado; el rack totalmente HBF tiene 294.9 TB y 922 TB/s, respectivamente.

  Riesgos

  En cargas de trabajo de bajo ancho de banda limitadas principalmente por la capacidad de una sola máquina, los usuarios pueden pagar por ancho de banda que excede los requisitos reales.

Datos clave

• Posicionamiento de Capacidad Relativa de HBFAproximadamente 8—16× la capacidad de HBM al mismo costoHBF intercambia menor ancho de banda por una ventaja de capacidad y no es una versión más barata de HBM.
• Ancho de Banda Máximo de Usuario de Tres Grados de HBF0.384 / 1.536 / 3.072 TB/sCorresponde a Grado 1, Grado 2 y Grado 3.
• Velocidades de Interconexión de HBF8 / 16 / 32 GT/sCorresponde a los tres grados de hardware.
• Configuraciones de Capacidad de HBF256 GiB de 8 capas; 512 GiB de 16 capasReflejan su posicionamiento de alta capacidad.
• Capacidad de Rack de 72 GPUHBM 20.7 TB; HBF 294.9 TB; híbrido 89.3 TBEquivalente a 1×, aproximadamente 14× y 4.3×, respectivamente.
• Capacidad por Instancia de Paralelismo de DatosHBM 2.3 TB; HBF 4.1 TB; híbrido 2.5 TBLas configuraciones de simulación son TP8·DP9, TP1·DP72 y TP2·DP36, respectivamente.
• Ancho de Banda Agregado del RackHBM 1,584 TB/s; HBF 922 TB/s; híbrido 1,418→279 TB/sTotalmente HBF es aproximadamente 0.6× totalmente HBM.
• Ancho de Banda por GPUHBM 22.0 TB/s; HBF 12.8 TB/s; híbrido 19.7→3.9 TB/sRefleja el costo de ancho de banda de las configuraciones de alta capacidad.
• Modelo de Simulación de RackKimi-K2 1T @ FP4El contexto principal es de 1 millón de tokens de entrada/1,000 tokens de salida, con un tamaño de lote de 1—512 por DP.
• Base de CostosAmortización a tres añosIncluye gastos de capital y operativos y se presenta como una proporción.
• Utilización de Capacidad HBF de Lote PequeñoAproximadamente 85% de capacidad ociosaAunque HBF tiene una ventaja de costo con B bajo, una gran cantidad de capacidad permanece sin usar.
• Pesos Totales de Kimi K31.56 TBEl tamaño del modelo es 2.8T.
• Pesos de Expertos MoE1.45 TB, representando el 93% de los bytesTienen características de escritura única y lectura en frío, que el informe considera adecuadas para HBF.
• Pesos Restantes110 GB, representando el 7%El informe los considera más adecuados para HBM.
• Caché KV por Secuencia Larga30 GB/secuencia de 1 millón de tokensHBF puede utilizarse para un pool de descarga de KV y caché de prefijos.
• Proporción de Lectura de Atención Dispersaφ aproximadamente 1%—2%El informe afirma que esto está por debajo del umbral φ*=α/l, lo que permite almacenar el KV completo en HBF mientras se lee únicamente top-k.
• Retención de Datos EncendidoAproximadamente 24 horas a 85°CEl host debe gestionar el ciclo de vida de los datos.
• Vida Útil ObjetivoAproximadamente 10 añosLas escrituras deben gestionarse cuidadosamente; de lo contrario, podría agotarse el 100% de la resistencia.

Impacto e implicaciones

El informe sostiene que las configuraciones de memoria de IA deben determinarse conjuntamente por la carga de trabajo y la escala de implementación, en lugar de comparar solo el precio por GB. HBF puede alojar modelos extremadamente grandes o pools KV en menos GPU, una sola máquina o nodos locales, y puede reducir la comunicación paralela de expertos. Sin embargo, al buscar alto rendimiento de rack, utilizar modelos densos o aumentar el tamaño de lote, su bajo ancho de banda eleva el costo por token. Es más probable que las implementaciones reales utilicen un enfoque por niveles: HBF transporta grandes volúmenes de datos fríos, mientras HBM retiene datos activos y sensibles al ancho de banda.

Riesgos

• A medida que aumentan el tamaño de lote, la intensidad de acceso o I·b, HBF alcanzará el límite de ancho de banda y HBM podría convertirse en la opción de menor costo.
• El almacenamiento en caché de expertos activos puede fallar con consultas mixtas porque la popularidad de los expertos tiende a aplanarse.
• La resistencia de escritura, el ancho de banda de escritura y la latencia de HBF requieren una estricta gestión del lado del host; de lo contrario, la vida útil y la disponibilidad pueden verse afectadas.
• Las rutas existentes de vLLM se dirigen principalmente a CPU o LMCache y carecen de un asignador HBF, políticas de colocación, prefetching asíncrono y telemetría de resistencia.
• La ventaja en escenarios de KV disperso depende de modelos de atención dispersa; no se aplica cuando el contexto se lee densamente.

Aspectos que vigilar

• Monitorear si el ancho de banda de lectura α de HBF puede aumentar y si puede mantenerse la brecha de costo por GB β respecto a HBM.
• Monitorear si pueden resolverse los problemas de resistencia de escritura, ancho de banda de escritura y latencia.
• Monitorear si motores de inferencia como vLLM añaden backends HBF, asignadores dedicados, políticas de colocación, prefetching asíncrono y telemetría de resistencia.
• Monitorear la localidad de acceso multiagente, los límites de ancho de banda de prefetch y la correspondencia entre las configuraciones de memoria y las cargas de trabajo.
• Monitorear si los modelos de atención dispersa y la agrupación de consultas similares pueden mantener la proporción de acceso real dentro del rango efectivo de HBF.