High Bandwidth Flash: mucha capacidad, poco ancho de banda

OXMIQ Labs, una empresa de propiedad intelectual para GPU, reveló en Hot Chips 2026 que la High Bandwidth Flash (HBF) no puede reemplazar a la High Bandwidth Memory (HBM) en la gran mayoría de las cargas de trabajo. Para algunas aplicaciones, la HBF podría emerger como un nivel de memoria especializado para conjuntos de datos enormes pero relativamente fríos. Para otras, puede hacer más daño que beneficio.

Cuando SanDisk presentó su concepto de HBF a comienzos de 2025, la tecnología prometía equipar a los aceleradores de IA con terabytes de memoria relativamente barata y reducir la necesidad de HBM tradicional, una promesa que levantó dudas desde el primer momento.

¿Qué es exactamente la High Bandwidth Flash?

La especificación emergente de HBF incluye tres grados de rendimiento:

Como la HBF se apoya en NAND 3D, soporta bloques de lectura de entre 64 bytes y 4 kilobytes, escrituras de 4 KB y páginas de 4 KB. Mientras el Grado 1 apenas puede competir contra la HBM contemporánea, el Grado 3 sí podría competir contra HBM4E, aunque no hay ninguna certeza sobre cuándo estaría disponible una memoria así.

Sin embargo, la característica principal de la HBF no es tanto el rendimiento como la capacidad: entre 8 y 16 veces más capacidad que la HBM a un costo aproximadamente igual.

Memoria barata no significa tokens baratos

OXMIQ cree que la HBF debe verse como una tecnología de alta capacidad y no como una HBM barata. La economía de la memoria no depende solo de cuántos gigabytes necesita almacenar una aplicación, sino también de qué tan rápido deben entregarse esos bytes al procesador. A medida que sube la demanda de ancho de banda, agregar HBF barata pero relativamente lenta termina siendo menos económico que usar HBM, según las estimaciones de la firma.

OXMIQ demostró el compromiso modelando un rack de 72 GPU corriendo el modelo Kimi-K2 de un billón de parámetros en FP4. A paridad de costo y consumo:

Reemplazar la HBM con HBF multiplica la capacidad del rack por 14 veces, pero reduce el ancho de banda agregado a 922 TB/s. Esa diferencia es la razón por la cual la HBF luce excelente cuando el límite del sistema es la capacidad de memoria, y pierde cuando el límite pasa a ser el rendimiento de transferencia.

En el modelo de OXMIQ, una configuración solo con HBF permite que cada GPU aloje su propia instancia de Kimi-K2 y corra 72 instancias por rack. Una configuración solo con HBM requiere ocho GPU para alojar cada instancia, con el consiguiente desperdicio de rendimiento de cómputo, y por lo tanto solo puede correr nueve instancias por rack.

Eso vuelve a la HBF particularmente atractiva cuando es la capacidad la que determina cuántas GPU se necesitan. Pero a medida que crece el número de usuarios simultáneos y su tasa de generación de tokens, el menor ancho de banda de la HBF se transforma en el cuello de botella, mientras el rack basado en HBM aprovecha mejor su ancho de banda superior y termina entregando un costo por token más bajo.

Al cierre de su presentación, OXMIQ concluye: "HBM para el rack, HBF para la caja".

¿Para qué sirve entonces?

Aunque la HBF no beneficia a todas las cargas de IA e incluso puede perjudicar el rendimiento de muchas, hay aplicaciones que sí sacan provecho de un excedente de memoria local.

Los modelos de mezcla de expertos (MoE) parecen especialmente adecuados. El ejemplo Kimi-K3 de OXMIQ tiene 1,56 TB de pesos, de los cuales 1,45 TB, un 93%, corresponde a pesos de expertos MoE. Como solo se activan expertos seleccionados por cada token, ese enorme conjunto se escribe una vez y se lee con poca frecuencia. La propuesta es mantener esos expertos en HBF y dejar en HBM los pesos restantes, los de acceso frecuente.

Además, más capacidad local podría reducir la comunicación entre aceleradores. El paralelismo de expertos convencional los distribuye entre GPU y exige comunicación de todos contra todos en cada capa. OXMIQ sostiene que la capacidad barata de la HBF permitiría que residan localmente muchos más expertos, reduciendo el número de fragmentos y el tráfico de red. En ese caso, la HBF cambia capacidad de memoria por ancho de banda de interconexión y consumo.

La inferencia de contexto largo es otro caso de uso potencial. Los modelos de atención dispersa acceden solo a una porción pequeña de su gran caché de claves y valores en cada paso de decodificación, lo que permite que el resto permanezca en memoria HBF más lenta.

La idea de usar HBM como caché tiene una limitación seria. Intuitivamente uno pondría los expertos populares en HBM y los fríos en HBF. Esa estrategia funciona sobre todo con lotes pequeños o cuando se pueden agrupar consultas similares de forma deliberada. Pero al crecer el tamaño del lote y volverse heterogéneas las consultas, la popularidad de los expertos se aplana y la carga accede a un rango más amplio. El conjunto de trabajo entonces supera la caché HBM, relativamente pequeña, lo que provoca transferencias más frecuentes desde HBF y reduce el beneficio del caché.

La parte más difícil es el software

OXMIQ no espera que la HBF funcione simplemente como memoria de GPU más lenta. Propone en cambio usarla en lugar de la DRAM del anfitrión, para almacenar grandes volúmenes de datos de acceso poco frecuente, como expertos MoE y caché de claves y valores. Los datos de uso frecuente quedarían en HBM, y los datos aún más fríos en memoria remota o unidades de estado sólido. Eso contradice la visión original de SanDisk para la HBF, que la ubicaba junto a los aceleradores de IA.

El lado del software es particularmente complicado. Para alcanzar el ancho de banda máximo, la HBF requiere transferencias grandes, lecturas de 64 KB y escrituras de 1 MB, y los datos se mueven por acceso directo a memoria en vez de por la jerarquía de caché del CPU o la GPU. Cuando HBF y HBM se usan en conjunto, el software además debe decidir qué datos van a cada tipo de memoria y administrar la limitada resistencia a escritura de la flash.

El software de inferencia actual no está listo para semejante configuración. Según OXMIQ, vLLM necesitaría soporte dedicado para gestionar la asignación y colocación de datos, precargar información antes de necesitarla y monitorear la resistencia de la flash, lo que exige una reescritura mayor. Un esfuerzo así tendría que ser conjunto entre los fabricantes de hardware HBF, los de aceleradores de IA y los desarrolladores de marcos de inferencia.

En el nivel más bajo, AMD, NVIDIA y otros fabricantes de aceleradores deberían proveer los mecanismos de hardware, controlador y entorno de ejecución para mover datos eficientemente entre HBF y HBM. Después los desarrolladores de vLLM implementarían el asignador de memoria y las políticas que deciden qué expertos y qué bloques de caché viven en cada nivel, cuándo deben moverse y cómo ocultar la latencia de la HBF.

La pregunta mayor es si fabricantes como AMD o NVIDIA necesitan la HBF. Según OXMIQ, su ventaja se limita a casos de uso selectos, así que puede no tener sentido soportarla de forma universal, sobre todo considerando lo difícil que es administrar una jerarquía de memoria de múltiples niveles.

SambaNova es quizás el candidato más obvio para adoptarla. Su SN40L ya usa una jerarquía de tres niveles, SRAM hacia HBM y hacia DDR, con hasta 520 MB de SRAM, 64 GB de HBM y 1,5 TB de DDR. Conceptualmente, la HBF podría convertirse en otro nivel o reemplazar parte de esa capacidad DDR.

Una tecnología todavía naciente

El modelo de OXMIQ sugiere que la HBF tiene una propuesta de valor de propósito general mucho más débil de lo que insinuaba la promesa original de 2025. No es inútil: es una solución especializada cuyas aplicaciones más fuertes dependen de características particulares de la carga de trabajo.

El problema de fondo es que la HBF resuelve capacidad de memoria, mientras los aceleradores de IA modernos suelen estar limitados por ancho de banda. La simulación lo deja bastante claro: la HBF entrega cerca de 14 veces más capacidad pero solo 0,6 veces el ancho de banda agregado de la HBM. Una vez que la carga se vuelve suficientemente intensiva en ancho de banda, la capacidad enorme deja de compensar el déficit.

Por ahora, la HBF tiene tres casos de uso especialmente convincentes: reducir el número de GPU necesarias solo para que quepa un modelo enorme, almacenar conjuntos masivos de expertos MoE de acceso infrecuente, y mantener cachés grandes de claves y valores para inferencia de contexto largo con atención dispersa. En los tres casos funciona porque los requisitos de capacidad son enormes mientras la demanda de ancho de banda se mantiene relativamente baja.