🤖 machine learning

Pipeline-Native Transformers: Co-Designing Model Architecture and CPU Inference for Bandwidth-Efficient Autoregressive Decode

Este artículo presenta cflow, un motor de transmisión orientado prioritariamente a la CPU y codiseñado con arquitecturas de transformadores nativas de segmentación por etapas para superar los cuellos de botella del ancho de banda de memoria en la decodificación autorregresiva de un solo token, logrando una reducción de hasta 2.00x en el ancho de banda de pesos de la ruta crítica y 5.94 tokens/s en un servidor de 32 vCPU mediante la utilización de segmentación de pesos de tamaño L2, selección de expertos top-k y traslape de E/S asíncrona.

Autores originales: Tom Poperszky

Publicado 2026-08-26

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Tom Poperszky

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

En el mundo de la inteligencia artificial, los programas informáticos más potentes se describen a menudo como si tuvieran un "cerebro" compuesto por miles de millones de diminutos interruptores. Estos interruptores, o pesos, se almacenan en la memoria principal de la computadora, como libros en el estante de una vasta biblioteca. Para realizar una predicción o generar una sola palabra de texto, la computadora debe buscar los libros adecuados en el estante, leerlos y realizar un cálculo. Durante años, los ingenieros han asumido que la velocidad de estos cálculos era el factor limitante, creyendo que si tan solo pudieran hacer que el procesador pensara más rápido, el programa funcionaría más rápido. Sin embargo, una nueva línea de investigación sugiere que esta suposición es errónea para la forma más común en que se utilizan estos programas: generando una palabra a la vez. En este modo específico, el procesador no está esperando a que su cerebro piense; está esperando a que la memoria le entregue los datos. El procesador es tan rápido que pasa la mayor parte del tiempo ocioso, mirando fijamente un estante vacío, esperando a que llegue el siguiente libro. Esto crea un cuello de botella donde la velocidad de todo el sistema está dictada no por qué tan rápido puede calcular la computadora, sino por qué tan rápido puede mover los datos desde el estante de la memoria hacia el procesador.

Un investigador llamado Tom Poperszky ha abordado este problema al darse cuenta de que la forma estándar de organizar estos "libros" en el estante fue diseñada para un tipo de computadora completamente diferente. La mayoría de los modelos de IA modernos fueron construidos para ejecutarse en chips gráficos especializados, que son excelentes leyendo muchos libros a la vez. Cuando estos modelos se ejecutan en procesadores de computadora estándar, la vieja organización provoca que el procesador pierda tiempo saltando de un lado a otro en el estante, buscando datos en un orden caótico que el hardware no puede predecir. El trabajo de Poperszky propone una solución radical: en lugar de intentar que los viejos modelos funcionen mejor en el nuevo hardware, él rediseñó tanto el modelo como el software que lo ejecuta para que trabajen juntos desde cero. Creó una nueva forma de almacenar los datos del modelo en trozos pequeños y ordenados que encajan perfectamente en el espacio de trabajo inmediato del procesador, y reescribió las instrucciones internas del modelo para que pueda leer estos trozos en una línea suave y continua sin detenerse nunca a esperar.

El núcleo de este nuevo enfoque es un sistema llamado cflow, que actúa como un bibliotecario altamente eficiente para la computadora. En una configuración estándar, cuando la computadora necesita generar una palabra, a menudo tiene que cargar el conjunto completo de instrucciones para una parte específica del modelo, incluso si solo necesita una fracción mínima de ellas. Esto es como abrir una enciclopedia entera para encontrar un solo dato. El sistema de Poperszky cambia esto organizando los datos en pequeñas baldosas, aproximadamente del tamaño de una sola página, y almacenándolos en el orden exacto en que la computadora los necesitará. Cuando la computadora pide la siguiente pieza de información, el sistema desliza la siguiente baldosa en su lugar instantáneamente, manteniendo ocupado al procesador. Además, para los modelos que utilizan una "mezcla de expertos" —una técnica donde el modelo elige algunas subrutinas especializadas para cada tarea—, el nuevo sistema solo carga las subrutinas específicas necesarias para ese momento, dejando el resto en el estante. Esto elimina el desperdicio de cargar miles de instrucciones no utilizadas para cada palabra generada.

Para que este sistema funcione, el investigador tuvo que cambiar la arquitectura del modelo mismo. Los modelos estándar están construidos como una línea de ensamblaje estricta donde un paso debe terminar completamente antes de que comience el siguiente. Esta estructura obliga a la computadora a esperar a que toda la línea termine antes de poder empezar a leer el siguiente conjunto de instrucciones. Poperszky rediseñó el modelo para permitir un "pipeline vertical", donde la computadora puede comenzar a leer las instrucciones para el siguiente paso mientras aún está terminando el actual. Esto es posible únicamente porque el modelo fue entrenado para aceptar una versión ligeramente retrasada de la información del paso anterior, un cambio que causaría errores en un modelo estándar pero que funciona perfectamente en este nuevo diseño. Al entrenar cinco versiones diferentes de estos modelos rediseñados, el investigador descubrió que una configuración específica podía reducir a la mitad la cantidad de datos que la computadora necesitaba mover. Esta reducción en el movimiento de datos se traduce directamente en velocidad, ya que la computadora pasa menos tiempo esperando y más tiempo trabajando.

Los resultados de este co-diseño se midieron en hardware real, revelando una clara ventaja sobre el software existente. En una computadora servidor estándar, el nuevo sistema generaba texto a una tasa de casi seis palabras por segundo, superando a las mejores alternativas disponibles que lograban solo unas cuatro palabras y media por segundo en la misma máquina. Esta mejora no fue solo un cálculo teórico; fue una aceleración en el mundo real lograda al reducir el número de veces que la memoria de la computadora tenía que ser accedida. El estudio también probó otras ideas, como el uso de instrucciones explícitas para decirle a la computadora dónde buscar los datos a continuación. Sorprendentemente, las pruebas mostraron que estas instrucciones no ayudaron e incluso ralentizaron el sistema, porque el propio hardware de la computadora ya estaba haciendo un mejor trabajo adivinando qué se necesitaba después. Este hallazgo es crucial, ya que descarta una técnica de optimización común y confirma que la verdadera ganancia proviene de la reorganización fundamental de los datos y el modelo.

La investigación también exploró cómo se mantendrían estos cambios a medida que los modelos crecen. El análisis sugiere que, si bien la aceleración es significativa para los modelos probados, los beneficios específicos dependen del tamaño del modelo y del tipo de computadora utilizado. Para modelos muy grandes, el cuello de botella podría desplazarse nuevamente, pero el principio permanece: al alinear la estructura del modelo con la forma en que la computadora lee la memoria, es posible desbloquear velocidades que antes se consideraban imposibles en procesadores estándar. El trabajo demuestra que las limitaciones de la inteligencia artificial actual en computadoras cotidianas no son leyes fijas de la física, sino elecciones de diseño que pueden cambiarse. Al tratar el modelo y el tiempo de ejecución como un sistema único y unificado, en lugar de dos piezas separadas, es posible crear un sistema que mueva los datos con la eficiencia de una biblioteca bien organizada, permitiendo que la computadora piense a la velocidad de su propio hardware. Este enfoque ofrece un camino claro para ejecutar una IA poderosa en dispositivos sin chips especializados, haciendo que la inteligencia avanzada sea más accesible y receptiva en el mundo real.

Resumen Técnico: Transformers Nativos de Pipeline

1. El Problema: El Cuello de Botella de Ancho de Banda en la Inferencia en CPU

El artículo sostiene que la decodificación autorregresiva de un solo token en CPUs está fundamentalmente limitada por el ancho de banda de la memoria, no por el cómputo aritmético. Mientras que las CPUs modernas sostienen aproximadamente 1 TFLOP/s de cómputo, suelen ofrecer solo ~50 GB/s de ancho de banda de memoria principal.

Para un paso de decodificación de un solo token, la intensidad aritmética es aproximadamente de 4 FLOP/byte (asumiendo cuantización Q4), lo cual es cinco veces menor que el balance de la máquina de 20 FLOP/byte. En consecuencia, la CPU pasa la mayor parte de su tiempo esperando a que los bytes de los pesos fluyan desde la RAM en lugar de realizar cálculos.

Los entornos de ejecución de inferencia de CPU existentes (por ejemplo, llama.cpp, ExLlama2) heredan en gran medida decisiones de diseño de arquitecturas optimizadas para GPU. Estas incluyen:

Distribución de pesos en orden de filas (Row-major): Optimizada para acceso por lotes (batched) pero ineficiente para el streaming de un solo token, causando fallos en la caché L1 proporcionales al tamaño de la matriz de pesos.
Carga estándar de Mezcla de Expertos (MoE): Carga todos los pesos de los expertos de una capa incluso si solo un subconjunto (top-k) está activo, desperdiciando hasta 15 veces el ancho de banda en modelos como Gemma 4.
Dependencia estricta de capas: Los transformers estándar requieren la salida completa de la capa $\ell$ antes de que la capa $\ell+1$ pueda comenzar, lo que impide el pipelining vertical donde se procesan concurrentemente etapas de diferentes capas.

El artículo postula que tratar la arquitectura del modelo y el entorno de ejecución como entidades independientes es una desventaja en el régimen de CPU. En su lugar, se requiere un enfoque de codiseño para reducir el total de bytes movidos por token.

2. Metodología: Codiseño de Arquitectura y Entorno de Ejecución

La solución propuesta consta de dos componentes estrechamente acoplados: el entorno de ejecución cflow y una familia de arquitecturas de transformer nativas de pipeline.

2.1 El Entorno de Ejecución cflow

cflow es un motor de inferencia para CPU escrito en Rust, diseñado en torno a la jerarquía de memoria de la CPU.

Formato de Pesos Nativo de Tiles: Los pesos se almacenan como tiles del tamaño de la L2 (matrices de 128×256, ~18 KB en Q4) en orden de consumo de cómputo. Esto asegura que, a medida que se procesa un tile, el vector de activación (que reside en L1) se reutilice en todas las filas del tile, minimizando los fallos de caché L1-d.
Formatos de Archivo:
- .cflow: Un formato por capa para el streaming estándar.
- .vflow: Un formato por etapas principales donde los tiles se agrupan por etapa de ejecución a través de las capas, permitiendo el pipelining vertical.
Carga Condicional de Expertos: El entorno de ejecución utiliza una tabla de desplazamiento de expertos para cargar solo los tiles de los expertos seleccionados en el top-k, saltándose el resto.
Kernels Fusionados: Fusiona las proyecciones QKV y las proyecciones de puerta+up para reducir las recargas de activaciones.
E/S Directa Escalonada (Staged Direct-I/O): Para niveles de expertos residentes en disco, utiliza E/S directa asíncrona para solapar la recuperación de expertos con el cómputo de las capas intermedias.

2.2 Arquitecturas Nativas de Pipeline

El artículo introduce un análisis formal del Grafo Acíclico Dirigido (DAG) de dependencias en los transformers pre-norm estándar. Demuestra que las dependencias estándar impiden el pipelining vertical. Para permitir esto, el autor propone la reescritura del DAG mediante dos transformaciones de retardo:

Retardo Denso ( $\delta_d$ ): La FFN densa en la capa $\ell$ consume el flujo residual de la capa $\ell - \delta_d$ en lugar de la salida de la capa actual.
Retardo de Experto ( $\delta_e$ ): Las salidas de los expertos computadas en la capa $\ell$ se inyectan en el flujo residual en la capa $\ell + \delta_e$ .

Estas transformaciones rompen la cadena secuencial estricta, permitiendo que el entorno de ejecución busque los pesos para la capa $\ell+1$ mientras la capa $\ell$ aún está computando, siempre que se satisfagan las dependencias mediante los buffers retardados.

Se entrenaron cinco arquitecturas candidatas en el dataset TinyStories para explorar la relación entre ancho de banda y calidad:

Arch1 y Arch3: Baselines sin retardos (reducción de ancho de banda de 1.00×).
Arch2_4_combined: Combina $\delta_d=1$ y $\delta_e=2$ . Esto logra la máxima reducción de ancho de banda.
Arch4 (AsyncExperts): Utiliza $\delta_e=2$ con enrutamiento pre-denso (enrutamiento antes de la FFN densa). Esto logra la mejor perplejidad pero ninguna reducción de ancho de banda.
Arch5: Utiliza el intercambio de pesos entre iteraciones para eficiencia de parámetros.

3. Contribuciones Clave

El Entorno de Ejecución cflow: Una implementación completa y de calidad de producción en Rust que cuenta con formatos nativos de tiles, kernels fusionados y carga condicional de expertos. Logra paridad numérica con las referencias de PyTorch.
Taxonomía de Pipeline-Nativo: Una definición formal de las transformaciones de relajación de dependencias (retrasos de densidad y de expertos) y cinco arquitecturas entrenadas que demuestran que estos cambios estructurales permiten un entrenamiento y convergencia estables.
Programador Consciente de Retardos (Delay-Aware Scheduler): Un programador de tiempo de ejecución que construye un historial residual de buffer circular para gestionar las entradas retardadas y las inyecciones de expertos, permitiendo el esquema de pipeline vertical.
Validación Empírica: Una evaluación exhaustiva de ocho afirmaciones específicas, incluyendo resultados negativos donde las hipótesis fueron refutadas.

4. Resultados

4.1 Eficiencia de Ancho de Banda y Caché

Reducción del Camino Crítico: La arquitectura arch2_4_combined logra una reducción de 2.00× en el ancho de banda de pesos del camino crítico (de 9.00 MB/token a 4.50 MB/token) en comparación con un esquema secuencial.
Localidad de Caché: La disposición de streaming de tiles reduce los fallos de lectura L1-d en 7.29× en comparación con una base row-major en un Xeon E5-2650 (medido mediante contadores de rendimiento de hardware).
Carga Condicional: Las garantías estructurales aseguran que solo se lean los tiles de los expertos top-k, ofreciendo una reducción de hasta 16× en el ancho de banda de los pesos de los expertos para modelos MoE grandes.

4.2 Rendimiento de Extremo a Extremo (End-to-End)

Throughput: En un MoE de 30.9B de parámetros ejecutándose en un AWS r6i.8xlarge (Ice Lake, 32 vCPUs), cflow alcanza 5.94 tokens/segundo.
Comparación: Esto supera a llama.cpp (4.75 tok/s en un modelo denso comparable de 32B) y al backend de CPU de vLLM (1.65 tok/s) en el mismo hardware.
Solapamiento de Expertos: En hardware de servidor con almacenamiento NVMe, la ventana de retardo de expertos permite el solapamiento de E/S asíncrona, produciendo una aceleración neta de hasta 1.68× sobre un enfoque de bloqueo sincrónico.

4.3 Resultados Negativos y Refutaciones

El artículo reporta explícitamente afirmaciones refutadas para proporcionar una visión completa:

Afirmación 6 (PREFETCHT0): Las instrucciones de prefetch explícitas no proporcionaron ningún beneficio y fueron en ocasiones perjudiciales (4% más lentas) cuando el cuello de botella era el ancho de banda de almacenamiento a RAM. El prefetcher del hardware ya satura el acceso lineal a la RAM, y las pistas explícitas añaden presión a la caché sin lograr solapamiento.
Afirmación 8 (Readahead de Etapa Principal): El beneficio teórico de readahead de la disposición .vflow fue inconcluso en las escalas probadas. El beneficio requiere un solapamiento de E/S asíncrona que no se implementó completamente para los pesos no expertos; la varianza observada se atribuyó a los estados de caché del SSD.

5. Significado y Afirmaciones

La tesis central del artículo es que codiseñar la arquitectura del modelo y el entorno de ejecución es necesario para superar el cuello de botella del ancho de banda de memoria en la inferencia en CPU.

Factibilidad: El trabajo demuestra que reescribir el grafo de dependencia inter-capa de un transformer no impide un aprendizaje efectivo; las arquitecturas entrenadas convergen con una perplejidad competitiva.
Mecanismo: La reducción de ancho de banda no es una aproximación, sino una consecuencia analítica de los parámetros de retardo y la geometría del modelo.
Practicidad: Los resultados muestran que un MoE nativo de pipeline puede superar a modelos densos de última generación en hardware de CPU estándar cuando el entorno de ejecución está optimizado para la arquitectura específica.

El autor concluye que, si bien el enfoque "nativo de pipeline" requiere cambios arquitectónicos en el tiempo de entrenamiento (lo que lo hace no retrofittable para checkpoints existentes), los principios de carga condicional de expertos y disposiciones de pesos de streaming de tiles son inmediatamente aplicables a los entornos de ejecución existentes para reducir el ancho de banda y mejorar la localidad de la caché. El trabajo establece que el grafo de dependencia del transformer es una elección de diseño, no una restricción fija, y que explotar esta elección junto con la optimización del entorno de ejecución produce optimizaciones que ninguno de los dos podría lograr por sí solo.