High Bandwidth Flash (HBF) quiere ocupar un espacio que hasta ahora estaba prácticamente vacío en los aceleradores de inteligencia artificial: una memoria con mucha más capacidad que HBM y bastante más ancho de banda que el almacenamiento NAND convencional. Sin embargo, un análisis presentado por OXMIQ Labs en Hot Chips 2026 muestra que esa combinación tiene límites importantes. HBF puede resultar muy atractiva cuando el problema es conseguir que un modelo enorme quepa cerca del procesador, pero pierde buena parte de su ventaja cuando la carga necesita mover esos datos continuamente a gran velocidad.
Las claves de High Bandwidth Flash en 20 segundos
- HBF utiliza NAND apilada para acercar cientos de gigabytes de capacidad a los aceleradores de IA.
- La especificación contempla hasta 512 GB por pila y unos 3 TB/s en su nivel más avanzado.
- Puede ofrecer entre 8 y 16 veces la capacidad de HBM a costes comparables, según sus promotores.
- OXMIQ advierte de que HBM continúa siendo mejor cuando el ancho de banda determina el rendimiento.
- Modelos Mixture of Experts y contextos muy largos aparecen entre los usos más prometedores.
La tecnología todavía está dando sus primeros pasos. Sandisk y SK hynix publicaron a principios de agosto la primera especificación técnica de HBF a través de Open Compute Project (OCP), apenas seis meses después de iniciar formalmente el trabajo de estandarización. Google y Tenstorrent también se han incorporado al grupo y han participado en la validación de la tecnología.
El planteamiento de HBF resulta sencillo de entender: la IA necesita cada vez más memoria y HBM es extremadamente rápida, pero también cara y limitada en capacidad. NAND ofrece muchísima capacidad a menor coste, aunque tradicionalmente ha sido demasiado lenta para trabajar directamente junto a una GPU.
HBF intenta construir algo intermedio.
Entre HBM y un SSD, pero con una arquitectura diferente
High Bandwidth Flash utiliza memoria NAND 3D organizada en pilas y conectada mediante interfaces de gran ancho de banda.
La primera especificación contempla tres niveles de rendimiento.
El denominado Grade 1 parte de una pila de 256 GB y proporciona aproximadamente 384 GB/s. Grade 2 eleva la capacidad hasta 512 GB y el ancho de banda hasta aproximadamente 1,536 TB/s.
Grade 3 mantiene 512 GB pero alcanza aproximadamente 3,072 TB/s, utilizando UCIe 2.0 a 32 GT/s.
| Tecnología | Capacidad característica | Ancho de banda | Punto fuerte |
|---|---|---|---|
| HBM | Decenas de GB por pila | Muy alto | Alimentar continuamente GPU/IA |
| HBF Grade 1 | 256 GB | 384 GB/s | Capacidad |
| HBF Grade 2 | 512 GB | 1,536 TB/s | Equilibrio capacidad/ancho de banda |
| HBF Grade 3 | 512 GB | 3,072 TB/s | Acercarse al rendimiento de HBM |
| SSD NVMe | Varios TB | Mucho menor | Capacidad y persistencia |
Las cifras dejan claro por qué HBF está despertando interés.
Un acelerador podría disponer de varios terabytes de memoria local sin tener que equipar una cantidad equivalente de HBM.
Sandisk sostiene que HBF puede proporcionar entre 8 y 16 veces más capacidad que HBM con un coste comparable. Es una estimación de la compañía y dependerá de cómo evolucionen los productos comerciales, pero resume bien la propuesta: HBF busca competir principalmente mediante capacidad, no convertirse simplemente en una HBM barata.
Y esa diferencia resulta esencial.
Tener 14 veces más memoria no significa procesar 14 veces más rápido
OXMIQ Labs utilizó Hot Chips para analizar qué ocurre cuando HBF se enfrenta a una carga de IA realista.
Uno de sus modelos estudia un rack de 72 aceleradores ejecutando Kimi K2, un modelo Mixture of Experts (MoE) con aproximadamente un billón de parámetros.
Manteniendo un presupuesto similar de coste y potencia, la configuración basada exclusivamente en HBM proporciona alrededor de 20,7 TB de capacidad y 1.584 TB/s de ancho de banda agregado.
Al sustituir HBM por HBF, la capacidad aumenta hasta unos 294,9 TB, alrededor de 14 veces más.
El problema es que el ancho de banda agregado desciende hasta unos 922 TB/s.
La diferencia ilustra perfectamente el dilema.
Si el principal problema consiste en hacer que un modelo quepa en memoria, HBF puede proporcionar una ventaja enorme.
Si el modelo ya cabe y el objetivo consiste en producir la mayor cantidad posible de tokens por segundo, HBM puede terminar siendo más eficiente.
En el ejemplo de OXMIQ, la enorme capacidad de HBF permitiría alojar una instancia completa del modelo en cada acelerador y ejecutar hasta 72 instancias por rack.
La configuración HBM necesitaría ocho aceleradores simplemente para alojar cada instancia completa, reduciendo el número de instancias independientes que caben en el mismo rack.
Pero cuando aumenta el número de usuarios simultáneos y cada GPU necesita acceder constantemente a grandes cantidades de información, el ancho de banda empieza a dominar el rendimiento.
En ese escenario, HBM recupera ventaja.
Por eso el coste por gigabyte no determina necesariamente el coste por token.
Los modelos MoE son uno de los casos más interesantes
High Bandwidth Flash puede encontrar un uso especialmente adecuado en los modelos Mixture of Experts.
Estos modelos contienen múltiples grupos de parámetros especializados, denominados expertos, pero no utilizan todos ellos para generar cada token.
El sistema selecciona únicamente determinados expertos según la información que está procesando.
Esto crea una característica muy interesante desde el punto de vista de memoria: el modelo puede contener una cantidad enorme de parámetros que necesitan estar disponibles, aunque una gran parte de ellos permanezca inactiva en cada instante.
OXMIQ utilizó como ejemplo un modelo con aproximadamente 1,56 TB de pesos, de los cuales unos 1,45 TB, el 93 %, corresponderían a expertos MoE.
Guardar todo ese conjunto en HBM sería costoso.
HBF permitiría mantener cerca del acelerador una cantidad mucho mayor de esos parámetros, reservando HBM para los datos que necesitan accesos frecuentes.
La arquitectura podría parecerse conceptualmente a una jerarquía:
HBM para los datos calientes, HBF para grandes conjuntos menos utilizados y SSD o almacenamiento remoto para información todavía más fría.
La diferencia respecto a un SSD convencional es que HBF estaría mucho más cerca del procesador y ofrecería un ancho de banda muy superior.
Menos tráfico entre GPU puede compensar una memoria más lenta
Existe además otra posible ventaja.
Los modelos MoE de gran tamaño suelen repartir sus expertos entre múltiples aceleradores.
Cuando un token necesita un experto alojado en otra GPU, los sistemas deben intercambiar información mediante la red de interconexión.
A gran escala estas comunicaciones all-to-all pueden consumir una parte considerable del ancho de banda disponible y de la energía del sistema.
Con varios terabytes de HBF cerca de cada acelerador sería posible mantener localmente una proporción mucho mayor de expertos.
Eso podría reducir la necesidad de repartirlos entre tantas GPU y disminuir parte del tráfico entre aceleradores.
En ese caso, HBF estaría intercambiando una cosa por otra: menos ancho de banda de memoria a cambio de más capacidad local y menos dependencia de la red.
Pero tampoco funcionará siempre.
Cuando aumenta el tamaño del batch y llegan muchas peticiones diferentes simultáneamente, el sistema puede terminar accediendo a una variedad mucho mayor de expertos.
La parte del modelo considerada «fría» deja entonces de serlo.
Si los datos tienen que trasladarse continuamente desde HBF hacia HBM, la menor velocidad de NAND empieza a penalizar el rendimiento.
Los contextos gigantes ofrecen otra oportunidad
El segundo escenario especialmente interesante es la inferencia con contextos muy largos.
Los modelos de lenguaje mantienen una estructura conocida como KV cache para conservar información de los tokens ya procesados y evitar recalcular determinadas operaciones.
Cuando el contexto alcanza cientos de miles o incluso millones de tokens, esa caché puede consumir enormes cantidades de memoria.
Pero algunas arquitecturas de atención dispersa no necesitan consultar todo ese contenido en cada paso de generación.
Una gran KV cache podría permanecer entonces en HBF mientras únicamente los bloques necesarios en cada momento se trasladan hacia HBM.
La idea vuelve a ser la misma.
HBF funciona mejor cuando una aplicación necesita tener muchísima información cerca, pero únicamente accede a una pequeña parte de ella en cada momento.
Si necesita leer prácticamente todo constantemente, HBM resulta mucho más apropiada.
NAND también introduce limitaciones que HBM no tiene
Existe además una diferencia física que no puede solucionarse simplemente aumentando el ancho de banda.
HBF sigue utilizando memoria NAND Flash.
Eso significa que sus operaciones no funcionan igual que las de DRAM.
La especificación contempla lecturas en bloques y escrituras mayores, y para obtener el máximo rendimiento es necesario realizar transferencias relativamente grandes. OXMIQ señala además que los movimientos de datos se realizarían mediante DMA en lugar de integrarse directamente en la jerarquía convencional de caché de CPU o GPU.
También existe la cuestión de la durabilidad.
NAND soporta un número limitado de ciclos de escritura. Los sistemas tendrían que controlar cómo se utilizan las celdas para evitar un desgaste prematuro.
Esto hace que HBF sea especialmente adecuada para datos que se escriben pocas veces y posteriormente se leen repetidamente, como los pesos de un modelo.
Para cargas con escrituras constantes puede resultar mucho menos atractiva.
El mayor problema puede terminar estando en el software
Construir los chips es solamente una parte del desafío.
Los actuales frameworks de inferencia están diseñados fundamentalmente pensando en DRAM y HBM.
Un sistema híbrido tendría que decidir constantemente qué información permanece en HBM, qué datos pueden trasladarse a HBF y cuándo deben regresar.
Además tendría que anticiparse.
Esperar hasta que una GPU necesite un dato para empezar a copiarlo desde una memoria más lenta puede detener el procesamiento. El software tendría que realizar prefetching y mover información antes de que sea necesaria.
OXMIQ señala específicamente que plataformas como vLLM necesitarían soporte dedicado para HBF, incluyendo asignadores de memoria, políticas de colocación, mecanismos de precarga y monitorización del desgaste de la NAND.
También sería necesaria la participación de los fabricantes de aceleradores.
AMD, NVIDIA u otros diseñadores tendrían que proporcionar mecanismos de hardware, drivers y runtimes capaces de mover eficientemente información entre HBM y HBF.
La tecnología puede estar definida sobre el papel, pero construir un ecosistema de software capaz de aprovecharla será probablemente bastante más complicado.
HBF no pretende matar a HBM
La primera especificación abierta de HBF ayuda también a corregir una interpretación que acompañó a la tecnología desde sus primeras presentaciones.
Sandisk comenzó a hablar públicamente de High Bandwidth Flash en 2025 como una respuesta al creciente problema de capacidad de memoria de los sistemas de IA.
Desde entonces la propuesta ha evolucionado.
Sandisk y SK hynix formalizaron en febrero de 2026 un grupo de trabajo dentro de Open Compute Project y publicaron en agosto la primera especificación técnica. Google y Tenstorrent participan ya en el proceso.
La propia arquitectura que empieza a perfilarse hace cada vez menos probable que HBF sustituya completamente a HBM.
Resulta más lógico pensar en una nueva capa dentro de la jerarquía de memoria de los aceleradores.
HBM seguiría ocupándose de los datos que necesitan el máximo ancho de banda.
HBF almacenaría cientos de gigabytes o varios terabytes que deben permanecer cerca pero no necesitan accederse constantemente.
Y los SSD continuarían proporcionando capacidades todavía mayores a menor coste y con mayor latencia.
La utilidad final dependerá de los modelos.
Un modelo denso ejecutado con grandes lotes puede obtener poco beneficio de HBF. Un gigantesco Mixture of Experts con muchos parámetros inactivos puede ser un candidato mucho mejor.
Por eso la conclusión presentada por OXMIQ en Hot Chips resulta especialmente apropiada: HBF es una herramienta especializada, no una solución universal para el problema de memoria de la IA.
Si la industria consigue integrar hardware, drivers y frameworks de inferencia, High Bandwidth Flash podría ocupar un espacio importante entre HBM y los SSD.
Pero su éxito probablemente no dependerá de demostrar que puede sustituir a HBM.
Dependerá de encontrar las cargas donde disponer de terabytes junto al acelerador sea más importante que mover cada byte a la máxima velocidad posible.
Preguntas frecuentes
¿Qué es High Bandwidth Flash o HBF?
HBF es una tecnología basada en NAND Flash diseñada para proporcionar mucha más capacidad y ancho de banda que el almacenamiento flash convencional y situarse cerca de los aceleradores de inteligencia artificial.
¿Puede HBF sustituir a HBM?
No en todas las cargas. HBM continúa siendo más adecuada cuando el rendimiento depende de acceder constantemente a grandes cantidades de datos, mientras HBF resulta más interesante cuando la capacidad es el principal problema.
¿Cuánta capacidad puede ofrecer HBF?
La primera especificación contempla pilas de hasta 512 GB. La combinación de varias pilas permitiría construir aceleradores con varios terabytes de memoria cercana al procesador.
¿Cuándo veremos HBF en sistemas comerciales?
La especificación abierta se publicó en agosto de 2026 y la tecnología continúa en desarrollo. Sandisk había situado anteriormente las primeras muestras en 2026, pero la adopción comercial dependerá también del soporte de fabricantes de aceleradores y del ecosistema de software.
