TurboFieldfare: motor open source para ejecutar Gemma 4 26B con 2 GB de RAM en cualquier Mac serie M

 (github.com/drumih)
1 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • TurboFieldfare ejecuta Gemma 4 26B-A4B con alrededor de 2 GB de memoria, sin cargar el modelo completo de 14.3 GB en memoria, lo que permite inferencia local incluso en Macs Apple Silicon de 8 GB
  • Mantiene residentes solo el núcleo compartido de 1.35 GB y la caché KV FP16, y transmite desde el SSD los pesos de expertos MoE necesarios para cada token; limita la E/S con una caché LFU de 16 slots y pread en paralelo
  • Gemma 4 26B-A4B activa aproximadamente 3.88B parámetros por token, y la velocidad de decodificación medida es de 5.1~6.3 tok/s en una MacBook Air M2 de 8 GB y de 31~35 tok/s en una M5 Pro de 24 GB
  • Es un runtime dedicado implementado en Swift 6.2 y Metal 4, que ofrece una app nativa para Mac, CLI, herramienta de instalación y un servidor experimental compatible con OpenAI sobre el mismo directorio de modelo .gturbo
  • Su alcance actual se limita a inferencia solo de texto en Macs Apple Silicon con macOS 26 o superior y al menos 8 GB de RAM; no admite imágenes, voz, video ni autenticación remota de servidor o TLS

Estructura de ejecución para reducir memoria

  • TurboFieldfare no carga por completo en memoria el modelo instruction-tuned Gemma 4 26B-A4B
    • Mantiene en memoria el núcleo compartido de 1.35 GB y la caché KV FP16
    • Lee desde el SSD solo los routed experts necesarios para cada token hacia buffers visibles para Metal
    • El modelo instalado solo de texto ocupa alrededor de 14.3 GB, pero la memoria usada por los pesos y la caché KV de 4K es de unos 2 GB
  • El modelo activa aproximadamente 3.88B parámetros por token de un total de 26B parámetros
  • Los pesos usan MLX affine de 4 bits basado en grupos de 64; el router es de 8 bits, y los expertos compartidos y routed son de 4 bits
  • No es una configuración que envuelva MLX o llama.cpp, sino un runtime dedicado en Swift y Metal creado para Gemma 4 26B-A4B

Proceso de generación de tokens

  • En cada capa Transformer, Metal calcula attention y router con los pesos residentes
  • La CPU compara los 8 expert ID principales seleccionados por el router con una caché LFU de 16 slots por capa
    • Los cache misses se completan con un número limitado de llamadas pread en paralelo
    • Mientras se realiza la lectura desde el SSD, Metal calcula la rama shared-expert residente
    • Cuando termina la lectura, combina el shared output y el routed output
  • El prefill del prompt usa chunks de hasta 128 tokens para que un expert traído una vez pueda procesar varias filas
  • En la etapa de generación, el bucle de routed layers se repite token por token
  • La caché KV usa almacenamiento circular limitado para 25 capas sliding-window y almacenamiento lineal para 5 capas full-attention
  • La attention de decodificación es un método exact split-K/V que separa las rutas normalizadas de K y V

Instalación y formato del modelo

  • En la primera ejecución, al elegir Download, descarga unos 15 GB desde una revisión fija de Hugging Face mediante range requests
  • El instalador no crea el checkpoint original completo en un archivo temporal ni en memoria
    • Recibe los rangos de bytes necesarios y los reempaqueta directamente en el layout .gturbo
    • Al no preparar shards ni tensors completos por separado, limita el uso de memoria temporal
    • La instalación terminada debe pasar la verificación del manifest y los hashes de archivos para poder usarse
  • Tras la instalación, el modelo ocupa alrededor de 14.3 GB de almacenamiento, y el proceso de instalación en sí no carga el modelo en memoria
  • El runtime solo acepta directorios .gturbo completos que tengan el manifest.json final
  • Admite reanudar descargas interrumpidas, borrar estados de descarga parcial y verificar la instalación sin cargar el modelo

Entorno de ejecución y rendimiento

  • Los requisitos son una Mac Apple Silicon, macOS 26, Metal 4, Xcode 26 y Swift 6.2 o superior
  • El paquete es solo arm64 y no admite versiones anteriores de macOS ni de Metal
  • El objetivo de validación es una MacBook Air M2 de 8 GB; se requiere espacio libre de almacenamiento para instalar el modelo y conexión a internet para la primera descarga
  • El rendimiento de decodificación medido es el siguiente
    • MacBook Air M2 de 8 GB: 5.1~6.3 tok/s
    • M5 Pro de 24 GB: 31~35 tok/s
  • El throughput varía según la longitud del prompt, la longitud de generación, el estado de la page cache y el hardware, por lo que las mediciones son puntos de referencia y no límites superiores de rendimiento
  • Antes de ejecutar el modelo, se deben cerrar apps que usen mucha memoria y verificar la memoria libre con memory_pressure -Q
  • La app, el decode service, la CLI, el servidor, las pruebas u otros procesos locales de modelos deben ejecutarse solo de a uno a la vez

Productos incluidos y modo de uso

  • El paquete Swift ofrece seis productos
    • TurboFieldfare: biblioteca Swift que incluye el runtime y los kernels Metal
    • TurboFieldfareMac: app nativa para Mac para instalación y generación
    • TurboFieldfareDecodeService: proceso local de un solo uso que posee el modelo y Metal, usado por la app de Mac
    • TurboFieldfareCLI: chat de instrucciones por línea de comandos y raw completion
    • TurboFieldfareServer: servidor loopback de Chat Completions compatible con OpenAI
    • TurboFieldfareRepack: herramienta de instalación por streaming y verificación de instalación
  • En la app de Mac, se descarga el modelo, se elige Load Model y se introduce un prompt para generar texto
    • La barra de estado permite ver el progreso, la velocidad de decodificación y el uso de memoria
    • Se pueden ajustar sampling, context length, slots de expert-cache y opciones del runtime
  • El instruction chat de la CLI recibe un arreglo de mensajes JSON y lo convierte al mismo formato que la app de Mac
    • El valor predeterminado del límite de respuesta --max-new es de 1,024 tokens
    • La app de Mac puede generar hasta que se llene la context window seleccionada
  • --prompt se usa para raw completion sin aplicar formato de chat y para comparaciones reproducibles
  • El texto generado se envía a la salida estándar, las estadísticas de tiempo al error estándar, y con --quiet se puede desactivar la salida de estadísticas

Prompts y alcance soportado

  • La app de Mac trata la entrada como una instrucción y aplica automáticamente el formato de chat de Gemma
  • La configuración predeterminada de sampling es temperature 0.2, Top-K 64 y Top-P 0.95
    • Si se configura temperature en 0, usa salida greedy determinista
    • El modelo puede repetir o responder incorrectamente, por lo que los resultados importantes deben verificarse
  • La app y la CLI admiten mensajes de usuario y de modelo, además de system guidance opcional, pero no exponen ni ejecutan herramientas
  • Actualmente la entrada y salida del modelo son solo de texto; no se admiten imágenes, audio ni video
  • La CLI ofrece --max-context, --temperature, --top-k, --top-p, --repetition-penalty, --seed y cadenas --stop repetibles

Servidor local compatible con OpenAI

  • El servidor experimental se ejecuta en 127.0.0.1:8080/v1 y admite Chat Completions, streaming, declaraciones de herramientas de función y reutilización de prompts con un único prefix
  • El servidor devuelve los tool calls generados por el modelo, pero la aprobación y ejecución de todas las llamadas a herramientas queda a cargo del cliente
  • Como no cuenta con autenticación remota ni TLS, el servidor debe mantenerse solo en loopback
  • La app de Mac, la CLI y el servidor usan el mismo directorio .gturbo, pero solo un producto que posea el modelo debe ejecutarse a la vez

Alcance de implementación y registro experimental

  • Los kernels Metal personalizados manejan GEMV cuantizado, attention, MoE, normalization, RoPE, sampling y fusion de producción
  • El runtime implementa streaming de routed experts basado en SSD, caché limitada de experts, prefill de un solo prompt por chunks y generación token por token
  • Mantiene como registro experimental 103 resultados de mediciones que abarcan kernels, caching, E/S, prefill y decode
  • La documentación experimental incluye optimizaciones de alto impacto, ideas fallidas y resultados iniciales que se revirtieron tras una validación más sólida
  • El trabajo futuro incluye el desarrollo de apps para iPhone y iPad, mediciones de velocidad de inferencia y memoria en móviles, y benchmarks en una Mac mini M4 de 16 GB y otras Macs Apple Silicon de 8 GB

Licencia y condiciones del modelo

  • El código fuente y la documentación se distribuyen bajo la Apache License 2.0
  • Los pesos del modelo no se incluyen en el repositorio; el instalador los descarga por separado desde un checkpoint fijo de Hugging Face
  • Los pesos siguen sujetos a las condiciones de distribución originales
  • TurboFieldfare es un proyecto de investigación independiente, no afiliado a Google ni patrocinado o aprobado por Google

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 시간 전
Comentarios de Hacker News

  • Siempre me he preguntado por qué cada vez hay que meter todo el modelo en memoria como si hiciera falta hasta saber quién es el rey Charles. La tecnología para dividir archivos grandes y leerlos de forma eficiente con poca memoria ya me parecía algo resuelto.
    En la industria de IA de punta, da la impresión de que son muy buenos construyendo modelos, pero le dejan la escalabilidad y la practicidad al equipo de infraestructura. Si al final se usa menos del 10% del conocimiento real, quizá con ajuste fino y optimización se podrían bajar mucho los costos

    • Tener el modelo completo en memoria es mucho más rápido que intercambiar con disco
    • Básicamente acabas de describir una arquitectura de mezcla de expertos (MoE). Si las capas expertas son lo bastante pequeñas y el SSD es rápido, se pueden cargar solo cuando se necesiten.
      Los LLM densos suelen rendir mejor, pero si mandas capas al almacenamiento externo se vuelven mucho más lentos que un MoE

  • Hoy en día, cuando descargas proyectos de origen desconocido, te toca correr tú mismo este tipo de revisión de seguridad. Le pedí que ignorara las instrucciones de agentes y los archivos Markdown del repositorio, y que inspeccionara el código fuente Swift/Metal, los scripts de build, la configuración de CI y las dependencias; no encontró malware, puertas traseras, robo de credenciales ni endpoints de red ocultos, pero concluyó que siguen existiendo riesgos de compilación, cadena de suministro y runtime.
    Si alguien tiene un mejor prompt, estaría bien que lo compartiera; correrlo con Composer 2.5 de Cursor costó menos de 0.20 dólares

  • Si usas macOS 15 en una MacBook Air M1, compila si borras estas dos líneas o las envuelves con if #available(macOS 26.0, *): opts.languageVersion = .version4_0
    Según el comentario, te pierdes la atención 11.24 veces más rápida y el prefill 2.4 veces más veloz, pero aun así da 5–6 tokens por segundo en una M1 Air con GPU de 8 núcleos

    • Dato útil. Más adelante quizá intentemos bajar la versión mínima soportada.
      La mejora de 2.4x en prefill solo funciona en la familia de GPU apple10; si no recuerdo mal, M1 es apple7

  • Me da curiosidad cómo se compara este proyecto con un mmap normal. llama.cpp también puede correr el modelo 26B con 2GB de RAM si activas mmap y desactivas el repacking.
    La diferencia clave parece ser que sincroniza las lecturas del SSD con el trabajo de inferencia para minimizar la latencia, y el sistema operativo no toma en cuenta ese contexto de ejecución

    • La primera versión usaba mmap. En una M2 de 8GB, leer un experto frío de 3.36MB tardaba 10ms con mmap, mientras que pread tardaba 2.8ms; la simulación completa daba 0.50 tokens por segundo frente a 4 tokens por segundo, respectivamente.
      Con mmap, el sistema operativo lee de forma reactiva cuando el modelo toca una página, así que no sabe qué experto fue elegido ni cuándo puede solapar lecturas con trabajo de GPU. Los pesos compartidos siguen usando mmap por simplicidad; llama.cpp quizá también pueda correr por debajo de 2GB, pero probablemente más lento
    • Para comprobar la velocidad real, me gustaría verlo comparado directamente con el SSD offloading de llama.cpp

  • La frase “las mediciones son una referencia, no el techo del rendimiento” suena a redacción típica de Claude

    • Esa forma de escribir ya está tan extendida que me preocupa seguir leyendo estilo Claude y terminar copiando la misma costumbre
    • “Hice más de 100 experimentos y la mayoría fallaron, pero algunos me trajeron hasta aquí” también suena a la misma marca
    • Tal vez originalmente era una expresión más de ChatGPT, pero tampoco voy a acusarlo de destilar a empresas occidentales. Puede que blogs de recetas posteriores a 2022 hayan terminado en los datos de entrenamiento de la 4.6–4.8
    • Creo que ya es hora de dejar de hacer este tipo de detección. No es muy distinto de una nueva policía gramatical y no aporta mucho valor.
      Si el autor solo pulió la redacción con un LLM y no agregó relleno innecesario, da igual. Si el texto en sí es basura generada, simplemente hay que votarlo mal

  • Es impresionante ver 12 tokens por segundo y una respuesta casi instantánea en una Mac Studio M1 Max con un SSD más rápido. Muestra la posibilidad de ejecutar modelos grandes directamente desde SSD en vez de memoria

    • Por desgracia, aquí la velocidad de lectura del SSD es el mayor cuello de botella

  • Ahora hay muchos motores de streaming desde SSD, pero pocos intentan funciones más ambiciosas. Los modelos principales tienen cabezas MTP para speculative decoding, así que podrían usarse para precargar desde el SSD los pesos de los expertos.
    Si preparas los pesos antes de que la GPU los necesite, puedes reducir mucho el costo de los fallos de caché en VRAM; si se demuestra útil, los modelos futuros podrían entrenarse con una cabeza dedicada a precargar expertos desde el inicio

    • En el streaming desde SSD, la GPU casi siempre está esperando al SSD hasta que llegan los expertos correctos, así que del lado del SSD prácticamente no hay tiempo libre para precargar. Si lees expertos mal predichos, sales perdiendo; por eso, en entornos típicos sin batching masivo, incluso el MTP tradicional tampoco ayuda mucho
    • En la práctica es más difícil de lo que parece. Cada capa tiene un conjunto distinto de expertos, y un router pequeño decide qué experto usar basándose en el estado de salida de los expertos de capas inferiores.
      Con los tokens borrador generados por MTP puedes predecir hasta los expertos de la primera capa, pero para saber los de la capa 10 primero tienes que ejecutar las capas 1 a 9 y leer esos expertos. Así que, en lugar de un predictor del siguiente token, haría falta un mecanismo entrenado para predecir la activación de expertos de todas las capas de una vez

  • Ya casi está listo un proyecto para ejecutar DiffusionGemma, y combinar ambos proyectos podría encajar muy bien. En una M3 de 36GB da alrededor de 20 tokens por segundo, y hay muchas probabilidades de que puedan reutilizar los kernels más rápidos del otro.
    El código actual está en https://github.com/mmastrac/diffgemma, pero todavía no está en estado desplegable

    • Lo revisé hace poco, pero concluí que correr modelos de difusión en local aporta poco valor práctico: https://eamag.me/2026/why-parallel-diffusion-llms-are-slow-o...
      Me interesa saber qué opinas al respecto
    • Diffusion Gemma apareció a mitad del proyecto y consideré seriamente cambiarme, pero decidí terminar con la dirección actual. Ambos proyectos encajarían muy bien, y puedes usar libremente el código que necesites o escribirme por LinkedIn al final del README

  • Me intriga por qué hay una diferencia tan grande entre 5–6 tokens por segundo en una MacBook Air M2 de 8GB y 31–35 tokens por segundo en una MacBook Pro M5. No parecía que la diferencia de rendimiento del SSD fuera tan grande, pero esperaba que en este enfoque el cuello de botella dominante fuera el SSD

    • La mejora de rendimiento del SSD en la M5 es considerable incluso comparada con la generación anterior. En Blackmagic Disk Speed Test, la MacBook Pro M5 registró hasta 6,323MB/s, mientras que la MacBook Pro M4 registró 2,031MB/s, una diferencia de más de 3x
      https://www.tomshardware.com/laptops/macbooks/m5-macbook-pro...
    • También es muy probable que la M5 tenga más memoria y que el sistema operativo ya haya cacheado la mayor parte del archivo. La M2, al tener más presión de memoria, probablemente cachee menos los resultados de lectura del SSD
      Si incluyendo la caché del sistema solo se pueden usar 2GB en total, la velocidad de inferencia podría ser aún menor
    • Depende bastante de la caché del sistema y de pread. Aunque el proceso se mantenga por debajo de 2GB, la Mac M5 puede cachear una parte y el hardware en sí también es mucho más rápido
      La lectura por token fue de 83ms en la M2 y 12ms en la M5 Pro, y el tiempo total fue de 163ms y 30ms respectivamente. Es el resultado de que tanto la lectura como el procesamiento en GPU se volvieron más rápidos
    • Por la antigüedad de la generación, incluso comparando modelos Pro el SSD es mucho más lento, y aun dentro de la misma generación es posible que el SSD y el ancho de banda de memoria del Air sean inferiores a los del Pro
    • La MacBook Pro M5 tiene 24GB de RAM, así que también podría mantener más contexto en memoria

  • En adelante, espero que con sistemas que tengan 30–60GB de memoria y SSDs muy rápidos se puedan ejecutar también modelos gigantescos con este tipo de técnica