La inferencia de modelos de lenguaje grandes (LLMs) en dispositivos con memoria limitada, como laptops de consumo, presenta un desafío fundamental en la computación distribuida y de sistemas. Tradicionalmente, la ejecución de modelos con decenas de miles de millones de parámetros requiere cargar el modelo completo en la memoria de la GPU, lo que excede la capacidad de muchos sistemas. TurboFieldfare aborda este problema aplicando principios de gestión de memoria virtual y paginación a la arquitectura de Mixture-of-Experts (MoE) de Gemma 4.
El problema central es cómo mantener la latencia de inferencia aceptable mientras se reduce drásticamente el footprint de memoria. Esto se logra explotando la escasez de activación de expertos en modelos MoE: no todos los expertos son necesarios para cada token. Al cargar solo los expertos activos bajo demanda desde un almacenamiento más lento (SSD) a una caché de memoria, se puede ejecutar un modelo mucho más grande de lo que la RAM disponible permitiría, transformando un problema de capacidad de memoria en un problema de ancho de banda de I/O y latencia de caché.
Arquitectura del Sistema
TurboFieldfare se implementa en Swift y utiliza Metal para la ejecución de kernels en la GPU de Apple Silicon. El sistema está diseñado específicamente para el modelo Gemma 4 26B-A4B, que emplea una arquitectura Mixture-of-Experts (MoE). De los 26 mil millones de parámetros totales, aproximadamente 3.88 mil millones están activos por token. El runtime mantiene en memoria un núcleo compartido de 1.35 GB y una caché KV (Key-Value) en FP16, mientras que los 'expertos' restantes se almacenan en SSD (aproximadamente 14.3 GB).
Cuando se procesa un token, la CPU utiliza los IDs de los 8 expertos principales (top-8) determinados por el router de la capa Transformer. Esto activa un mecanismo de caché LFU (Least Frequently Used) de 16 slots para expertos. Si un experto necesario no está en la caché, se realiza una lectura paralela (pread) desde el SSD a buffers visibles por Metal. Mientras estas lecturas están en curso, Metal calcula la rama del experto compartido residente. Una vez que los expertos requeridos están disponibles, Metal combina las salidas del experto compartido y los expertos ruteados. La pre-rellenado (prefill) del prompt se realiza en chunks de hasta 128 tokens para optimizar el uso de expertos cargados, mientras que la generación de tokens individuales repite este ciclo. El instalador del modelo también utiliza un enfoque de streaming, descargando y reempaquetando rangos de bytes directamente desde Hugging Face al formato .gturbo sin materializar el checkpoint completo en disco, lo que mantiene la memoria scratch acotada.
Flujo de Inferencia de Token con Expertos Ruteados
- 1 Capa Transformer Metal calcula atención y router con pesos residentes.
- 2 CPU (Planificación) Usa IDs de top-8 expertos del router para planificar contra caché LFU de 16 s...
- 3 I/O (Miss de Caché) Si hay miss, CPU inicia pread paralelos desde SSD a buffers visibles por Metal.
- 4 Metal (Cálculo Paralelo) Mientras I/O, Metal calcula rama de experto compartido residente.
- 5 Metal (Combinación) Combina salidas de experto compartido y expertos ruteados (una vez cargados).
Flujo de Instalación del Modelo en Streaming
- 1 App/CLI Inicia descarga y reempaquetado del modelo.
- 2 Hugging Face TurboFieldfare solicita rangos de bytes específicos del checkpoint.
- 3 Streaming Repack Los rangos de bytes se reempaquetan directamente al formato .gturbo en disco.
- 4 Validación Manifiesto y hashes de archivos se validan al completar la instalación.
- 5 Modelo .gturbo Instalación finalizada, lista para cargar (14.3 GB).
| Capa | Tecnología | Justificación |
|---|---|---|
| compute | Apple Silicon (M2, M5 Pro) | Hardware de ejecución principal, aprovechando su arquitectura unificada de memoria y unidades de procesamiento neuronal. 8 GB de RAM mínimo, macOS 26, Metal 4. |
| compute | Metal | Framework de bajo nivel para programación de GPU en Apple. Utilizado para kernels de inferencia optimizados (GEMV, atención, MoE, normalización, RoPE, sampling). vs Core ML, MLX |
| orchestration | Swift | Lenguaje de programación principal para el runtime, CLI, servidor y la aplicación nativa de macOS, facilitando la interacción con Metal y el sistema operativo. vs C++, Rust Swift 6.2 o superior. |
| storage | SSD | Almacenamiento secundario para los 'expertos' del modelo que no residen en RAM, permitiendo un footprint de memoria reducido. 14.3 GB de espacio requerido para el modelo instalado. |
| cache | LFU Cache | Caché de 16 slots para los 'expertos' del modelo, gestionando qué expertos se mantienen en memoria para reducir lecturas de SSD. vs LRU, FIFO |
| storage | FP16 KV Cache | Almacenamiento en memoria de las claves y valores (Key-Value) de la atención, con una gestión circular para capas de ventana deslizante y lineal para capas de atención completa. Bounded circular storage para 25 capas, lineal para 5 capas. |
Trade-offs
Ganancias
- ▲▲ Footprint de memoria
- ▲ Accesibilidad de hardware
Costes
- △ Latencia de inferencia
- ▲ Complejidad del runtime
swift run -c release TurboFieldfareCLI \
--model scratch/gemma4.gturbo \
--prompt "The capital of France is" \
--max-new 64 \
--temperature 0swift run -c release TurboFieldfareRepack \
--output scratch/gemma4.gturbo \
--overwrite
swift run -c release TurboFieldfareRepack \
--verify-install \
--input-gturbo scratch/gemma4.gturboFundamentos Teóricos
El concepto de cargar componentes de un programa o datos bajo demanda desde un almacenamiento secundario a la memoria principal es un principio fundamental de la computación, conocido como paginación o 'swapping'. Este mecanismo fue formalizado en sistemas operativos desde los años 60, con trabajos seminales de Peter Denning sobre el modelo de conjunto de trabajo (working set model) en 1968, que buscaba optimizar la eficiencia de la memoria virtual. TurboFieldfare aplica una variante de este principio al dominio de la inferencia de LLMs, donde los 'expertos' de un modelo MoE actúan como 'páginas' que se cargan y descargan según su necesidad.
La arquitectura MoE en sí misma tiene raíces en la investigación de redes neuronales de los años 90, con trabajos como los de Jacobs et al. (1991) sobre 'Adaptive Mixtures of Local Experts'. La combinación de MoE con mecanismos de carga bajo demanda se alinea con la idea de 'computación elástica' o 'sparse computing', donde solo una fracción de los recursos (en este caso, parámetros del modelo) se activa en un momento dado, optimizando el uso de recursos limitados. La gestión de la caché LFU para expertos es análoga a las políticas de reemplazo de páginas en sistemas de memoria virtual.