Por Canuto  

La High Bandwidth Flash promete llevar enormes cantidades de memoria a los aceleradores de inteligencia artificial, pero una presentación de OXMIQ Labs muestra que su ventaja no está en sustituir a HBM. La tecnología podría encontrar un espacio más limitado, especialmente en modelos de mezcla de expertos y tareas de contexto largo.
***

  • HBF puede ofrecer hasta 16 veces más capacidad que HBM, aunque con menor ancho de banda agregado.
  • OXMIQ estima que una configuración solo con HBF alojaría muchas más instancias de Kimi-K2 por rack.
  • Los expertos MoE poco consultados y las cachés KV de contexto largo aparecen como casos de uso prioritarios.

La High Bandwidth Flash (HBF) llegó al debate sobre la memoria para inteligencia artificial con una promesa ambiciosa: entregar terabytes de capacidad a los aceleradores a un costo considerablemente menor que la High Bandwidth Memory (HBM). Sin embargo, una presentación de OXMIQ Labs en Hot Chips 2026 plantea una conclusión más cautelosa, porque la nueva tecnología no puede reemplazar a HBM en la mayoría de las cargas de trabajo. Su principal oportunidad estaría en almacenar datos enormes y relativamente fríos, no en competir de forma general por el máximo rendimiento.

El planteamiento resulta relevante para los centros de datos que intentan ejecutar modelos cada vez más grandes sin multiplicar indefinidamente el número de GPU. La capacidad adicional puede evitar que varios aceleradores se dediquen únicamente a alojar los pesos de un modelo, pero esa ventaja desaparece cuando la aplicación necesita mover datos de manera constante y a gran velocidad. Por eso, OXMIQ propone entender HBF como una capa especializada de memoria de alta capacidad, situada entre la HBM rápida y otros niveles de almacenamiento más lentos.

Una promesa de capacidad con un costo de rendimiento

El concepto de HBF fue presentado por SanDisk a comienzos de 2025 como una posible forma de equipar aceleradores de IA con terabytes de memoria relativamente económica. La especificación emergente contempla tres grados de rendimiento, con un ancho de banda aproximado de entre 0,4 TB/s y 3 TB/s, capacidades de hasta 512 GB y conexión mediante UCIe.

Como HBF se basa en memoria NAND 3D, busca ofrecer una capacidad mucho mayor que HBM manteniendo un ancho de banda suficiente para determinados escenarios de inferencia. La comparación planteada por OXMIQ muestra que su ventaja no consiste en superar a HBM en rendimiento general, sino en ampliar el espacio disponible para modelos y datos que no necesitan permanecer constantemente en la memoria más rápida.

Según OXMIQ, HBF podría proporcionar aproximadamente entre ocho y 16 veces más capacidad que HBM, pero la economía de una arquitectura de memoria también depende de la velocidad con que los datos deben llegar al procesador. Si el ancho de banda se convierte en el límite del sistema, añadir memoria flash barata puede terminar siendo menos conveniente que utilizar una cantidad mayor de HBM.

La empresa resumió esa tensión con una idea sencilla: HBM debe permanecer en el rack cuando la prioridad es el rendimiento total, mientras HBF tendría más sentido dentro de cada caja para ampliar la capacidad local. La propuesta no elimina la necesidad de HBM, sino que divide el trabajo entre una memoria rápida para los datos activos y otra con mayor espacio para la información que se consulta con menor frecuencia. Esa separación, no obstante, exige cambios importantes en el hardware y en el software de inferencia.

El modelo de Kimi-K2 muestra el dilema

Para medir el intercambio entre capacidad y velocidad, OXMIQ modeló un rack con 72 GPU ejecutando Kimi-K2, un modelo de 1 billón de parámetros en escala corta inglesa, es decir, 1 trillón de parámetros en la convención estadounidense, con precisión FP4. En igualdad de costo y potencia, una arquitectura equipada únicamente con HBM alcanzaría 20,7 TB de memoria y 1.584 TB/s de ancho de banda agregado. Al sustituir HBM por HBF, la capacidad subiría a unos 294,9 TB, pero el ancho de banda agregado caería a 922 TB/s.

La alternativa híbrida ofrecería 89,3 TB de capacidad y un ancho de banda situado entre 279 TB/s y 1.418 TB/s, dependiendo de las condiciones de la carga. Esa diferencia explica por qué HBF luce atractiva cuando el problema principal consiste en alojar un modelo demasiado grande. En cambio, cuando la aplicación exige alimentar continuamente a las unidades de cómputo, el menor ancho de banda puede convertir la capacidad adicional en un beneficio insuficiente.

El efecto sobre la cantidad de instancias resulta especialmente llamativo. En el modelo de OXMIQ, una configuración solo con HBF permitiría que cada GPU mantuviera su propia instancia de Kimi-K2 y que el rack ejecutara 72 instancias, mientras una configuración exclusivamente basada en HBM necesitaría ocho GPU por instancia y solo podría ejecutar nueve instancias por rack. HBF, por tanto, reduce el número de GPU utilizadas simplemente para alojar el modelo, aunque no necesariamente mejora el rendimiento de cada consulta.

La situación cambia cuando crecen los usuarios simultáneos y la tasa de generación de tokens. En ese escenario, la menor velocidad de HBF se transforma en un cuello de botella, mientras el rack con HBM aprovecha su ancho de banda superior y puede terminar ofreciendo un menor costo por token, según la simulación citada. La conclusión es incómoda para quienes esperaban una sustitución directa: una solución con más memoria no garantiza una inferencia más barata si los datos deben circular constantemente.

Modelos MoE y contexto largo, los nichos más claros

Los modelos de mezcla de expertos, conocidos como MoE, aparecen entre los casos de uso más favorables para HBF porque almacenan grandes conjuntos de pesos que no se activan en cada operación. En el ejemplo de Kimi-K3 presentado por OXMIQ, los pesos suman 1,56 TB y 1,45 TB, equivalentes al 93%, corresponden a expertos MoE. Como solo se seleccionan determinados expertos para cada token, una parte importante de ese conjunto se escribe una vez y se lee con poca frecuencia.

La arquitectura propuesta mantendría esos expertos menos activos en HBF, mientras reservaría HBM para los pesos que reciben accesos frecuentes. La estrategia busca que la memoria rápida funcione como una especie de caché para los datos calientes, sin obligar a mantener todo el modelo en HBM. Su eficacia dependería de que la aplicación pueda anticipar qué bloques serán necesarios y trasladarlos a tiempo, una condición mucho más difícil cuando las consultas son impredecibles.

La capacidad local también podría reducir la comunicación entre aceleradores. En el paralelismo de expertos convencional, los expertos se distribuyen entre las GPU y cada capa requiere comunicación all-to-all; al alojar más expertos localmente con HBF, OXMIQ sostiene que sería posible reducir el número de fragmentos de ese paralelismo y disminuir el tráfico de red. En términos prácticos, la arquitectura intercambiaría capacidad de memoria por menor demanda de interconexión y potencialmente por un consumo energético más bajo.

La inferencia de contexto largo ofrece otro escenario posible, especialmente con modelos de atención dispersa. Estos sistemas consultan solo una fracción de su enorme caché KV durante cada paso de decodificación, de modo que el resto podría permanecer en la capa HBF y transferirse a HBM únicamente cuando el acelerador lo necesite. El atractivo reside en conservar una memoria contextual masiva sin pagar el precio de instalar toda esa capacidad en la memoria más rápida.

El software puede convertirse en el mayor obstáculo

El uso de HBM como caché no resuelve por sí solo la complejidad de la jerarquía. Colocar a los expertos populares en HBM y a los menos solicitados en HBF puede funcionar con lotes pequeños o cuando las consultas similares se agrupan deliberadamente, pero la popularidad de los expertos se aplana a medida que aumentan el tamaño del lote y la heterogeneidad de las solicitudes. En consecuencia, el conjunto de trabajo puede superar la caché HBM y obligar a realizar transferencias más frecuentes desde HBF.

OXMIQ no imagina HBF como una memoria de GPU simplemente más lenta, sino como un sustituto de parte de la DRAM del host para datos de acceso infrecuente. Los expertos MoE y las cachés KV ocuparían esa capa, mientras HBM conservaría la información activa y la memoria remota o las unidades SSD almacenarían los datos todavía más fríos. Esta visión se aparta de la idea inicial de colocar HBF junto a los aceleradores como una alternativa amplia a HBM.

El rendimiento máximo también exige mover los datos en transferencias grandes: lecturas de 64 KB y escrituras de 1 MB, realizadas mediante acceso directo a memoria, o DMA, en lugar de la jerarquía de caché tradicional de CPU o GPU. El software tendría que decidir qué bloques residen en cada nivel, anticipar las transferencias y vigilar la resistencia limitada de las celdas NAND ante las escrituras. Esa administración añade una capa de coordinación que hoy no forma parte de los flujos habituales de inferencia.

OXMIQ considera que vLLM necesitaría soporte específico para asignar la memoria, ubicar los datos, precargar información antes de cada uso y monitorear la resistencia de HBF. Una implementación funcional requeriría colaboración entre fabricantes de memoria, desarrolladores de aceleradores y autores de frameworks de inferencia, además de mecanismos de hardware, controladores y runtimes para transferir datos entre HBF y HBM. AMD, Nvidia y otros proveedores tendrían que decidir si una ventaja limitada a cargas concretas justifica asumir la complejidad de una jerarquía multinivel.

Causas de movimientos recientes

La presentación de OXMIQ en Hot Chips 2026 constituye el catalizador confirmado de la atención reciente sobre HBF: la compañía expuso cómo esta memoria podría aliviar las restricciones de capacidad en cargas de inferencia, aunque también subrayó que no reemplaza a HBM de manera general. La publicación de la primera especificación abierta de HBF por parte de SK hynix y SanDisk aporta contexto adicional al interés por la tecnología, pero no demuestra por sí sola una adopción comercial amplia.

Una tecnología incipiente y de alcance selectivo

SambaNova aparece como uno de los candidatos conceptuales más claros para adoptar HBF, porque su SN40L ya utiliza una jerarquía de tres niveles compuesta por SRAM, HBM y DDR. El sistema cuenta con hasta 520 MB de SRAM, 64 GB de HBM y 1,5 TB de DDR, por lo que HBF podría convertirse en otro nivel o reemplazar una parte de esa capacidad DDR. La posibilidad sigue siendo especulativa, ya que no se presentó una adopción concreta.

El modelo de OXMIQ deja una relación difícil de ignorar: HBF entregaría alrededor de 14 veces más capacidad de memoria que HBM en el rack analizado, pero solo cerca de 0,6 veces su ancho de banda agregado. Cuando una carga de trabajo está limitada por la capacidad, esa diferencia puede justificar el diseño; cuando está limitada por el ancho de banda, la ventaja de espacio pierde valor con rapidez. HBF resuelve un problema real, pero no necesariamente el problema dominante de los aceleradores modernos.

La combinación HBM más HBF puede ser útil en modelos con expertos poco consultados, cachés KV enormes y necesidades de alojamiento que obligan a usar demasiadas GPU. Sin embargo, las solicitudes heterogéneas y los lotes grandes pueden reducir la eficiencia de HBM como caché, porque obligan al sistema a tocar un rango cada vez más amplio de expertos. La arquitectura híbrida necesita políticas de ubicación precisas y mecanismos capaces de ocultar la latencia de la memoria flash.

Por ahora, los tres casos más convincentes consisten en reducir las GPU necesarias para alojar modelos enormes, conservar conjuntos masivos de expertos MoE con baja frecuencia de acceso y almacenar cachés KV para inferencia dispersa de contexto largo. En todos ellos, la capacidad es crítica y la demanda de ancho de banda resulta relativamente moderada, justo el escenario en el que HBF puede entregar su mayor valor. La tecnología todavía no parece una sustituta general de HBM, sino una herramienta especializada que deberá demostrar que su complejidad operativa compensa el ahorro de capacidad.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados