Un modelo de 753 000 millones de parámetros cabe en un ordenador de sobremesa. No porque la GPU tenga memoria de sobra, sino porque FreeToken deja de tratar la máquina como una tarjeta gráfica pequeña y empieza a tratarla como un sistema con tres depósitos de memoria y dos procesadores. Este artículo explica el mecanismo, repasa las cifras que publica su paper con el hardware al que corresponden, y detalla los cuatro requisitos que las notas de prensa se saltan. La versión en inglés está en /en/freetoken-local-ai-engine/.

Puntos clave

  • FreeToken es un motor de inferencia Apache 2.0 para modelos Mixture-of-Experts, publicado el 17 de agosto de 2026 por un equipo de UC Berkeley y UT Austin que incluye a Matei Zaharia e Ion Stoica.
  • Su idea central es una fórmula, q* ≈ m · BP/BH, que decide en cada paso cuántos expertos ausentes se traen por PCIe y cuántos se calculan en la CPU, midiendo el ancho de banda real de tu equipo.
  • En una RTX 5090 sirve Qwen3.6-35B-A3B a 77-83 tokens por segundo, entre 1,8 y 2,3 veces más rápido que llama.cpp; en una RTX PRO 6000 mueve GLM-5.2, de 753B, a 14,9 tokens por segundo.
  • El requisito que casi nadie menciona no es la VRAM sino la RAM del sistema: el pool de expertos de DeepSeek-V4-Flash ocupa unos 140 GB en FP4 y vive en memoria del host.
  • La línea de comandos exige Linux x86_64 con GPU NVIDIA y CUDA 13. Ni AMD, ni Apple Silicon, ni Windows fuera de la aplicación de escritorio.
  • Va por la versión 0.1.2, con seis semanas de repositorio público y 247 incidencias abiertas. Es software temprano, por prometedor que sea.

Qué es FreeToken y qué problema resuelve

FreeToken es un motor de servicio de modelos pensado para ejecutarse en el equipo del usuario, no en un centro de datos. Se especializa en una familia concreta: los modelos Mixture-of-Experts, o MoE, en los que cada token activa sólo una fracción de los parámetros totales. GLM-5.2 tiene 753B parámetros pero activa unos 40B por token; DeepSeek-V4-Flash tiene 284B y activa 13B.

Esa dispersión es justo lo que hace viable la aritmética en una máquina modesta, y a la vez lo que la complica. El cálculo por token es pequeño, pero el conjunto completo de expertos tiene que estar disponible en alguna parte, porque el router puede pedir cualquiera de ellos en cualquier momento. Un modelo de 284B en MXFP4 son unos 140 GB de pesos que no caben en ninguna GPU de consumo.

Las herramientas anteriores resolvían esto congelando una estrategia al cargar el modelo. llama.cpp reparte capas entre GPU y CPU con un número fijo. KTransformers coloca los expertos más frecuentes en la GPU y deja el resto fuera. Ambas decisiones se toman una vez, sin saber qué va a pedir el modelo después.

El planteamiento de FreeToken es distinto y sus autores lo resumen así en el resumen del paper: el sistema «trata una máquina personal no como una GPU pequeña, sino como una plataforma de inferencia unificada y elástica». En vez de fijar el reparto, lo recalcula continuamente contra los recursos que realmente hay.

Cómo funciona el reparto adaptativo entre CPU y GPU

Cuando el router selecciona los expertos de una capa, algunos ya están en la caché de la GPU y otros no. A los que faltan el paper los llama m. La pregunta operativa es qué hacer con ellos, y hay dos caminos posibles: traerlos por el bus PCIe hasta la GPU, o dejarlos donde están y calcular esa parte en la CPU.

FreeToken no elige un camino, los usa a la vez en la proporción que corresponde a la máquina. La política se reduce a una expresión:

q* ≈ m · BP/BH

  m   = expertos ausentes en la caché de la GPU
  BP  = ancho de banda de transferencia por PCIe
  BH  = ancho de banda de proceso en el host (CPU + RAM)
  q*  = cuántos de esos m se traen por PCIe; los m - q* restantes se calculan en CPU

La gracia de la fórmula es que se adapta sola a hardware muy distinto sin cambiar de código. En la RTX 5090 del paper la relación entre ambos anchos de banda es de 52,7 frente a 77,3; en el portátil con RTX 4060 es de 11,8 frente a 47,5, porque el enlace PCIe del portátil es de sólo x8. El mismo reparto matemático produce dos comportamientos muy distintos, que es exactamente lo que se busca.

Alrededor de esa política hay tres piezas más que importan:

  • Caché LRU global de expertos. La residencia en GPU sigue a lo que pide el router. Los tokens contiguos tienden a elegir expertos que se solapan, así que la localidad temporal existe y se puede explotar. El resultado medido: con un 37 % del pool de expertos en la GPU, FreeToken falla el 16 % de las veces, frente al 41 % de KTransformers y el 62 % de llama.cpp.
  • Doble búfer en el prefill. Mientras la GPU calcula los expertos de la capa l desde un búfer, un flujo de transferencia dedicado carga la capa l+1 en el otro. La transferencia queda escondida detrás del cálculo.
  • Anclas semánticas de caché. En flujos con agentes, el contexto se edita constantemente (llamadas a herramientas, bloques de razonamiento). Estas anclas evitan recalcular el contexto entero en cada edición, y ahí está la diferencia más visible: FreeToken pierde menos del 12 % de velocidad al pasar de un turno a una conversación multiturno, mientras KTransformers pierde el 31 %.

Todo ese control dinámico va dentro de grafos CUDA capturados estáticamente, para no pagar sincronizaciones en cada paso.

Las cifras del paper, con su hardware

Los números sueltos no significan nada sin la máquina que los produjo. Esta es la tabla completa tal como aparece en la evaluación:

Hardware Modelo FreeToken llama.cpp Factor
RTX 4060 Laptop (8 GB) Qwen3.6-35B-A3B 39,3 tok/s n/d n/d
RTX 5090 Qwen3.6-35B-A3B (BF16) 77-83 tok/s n/d 1,8-2,3x
RTX 5090 DeepSeek-V4-Flash 284B (MXFP4) 22-25 tok/s 12 tok/s 1,9x
RTX PRO 6000 (96 GB) GLM-5.2 753B 14,9 tok/s 7,3 tok/s 2,0x

Frente a KTransformers la ventaja en Qwen3.6 es de 1,5 veces. El tiempo hasta el primer token se mantiene por debajo de 44 segundos en todas las cargas evaluadas, mientras los sistemas de referencia superan los 150 segundos en el peor caso. Los baselines del paper son llama.cpp, KTransformers, Ollama y MoE-Infinity.

Conviene leer esa cifra de 44 segundos con calma. Es una mejora enorme sobre la alternativa, y sigue siendo una espera larguísima comparada con cualquier API en la nube. FreeToken cambia lo que tu máquina puede servir, no lo convierte en un centro de datos.

Cómo instalarlo y arrancar un servidor

La aplicación de escritorio para Windows y Linux está en flashml.ai y configura el motor sola. Por línea de comandos el camino es este:

# Requisitos: Linux x86_64, GPU NVIDIA, driver r580+ (CUDA 13), Python 3.10 o superior
uv venv && source .venv/bin/activate
uv pip install "freetoken[accel]"

## Calibra el reparto CPU/PCIe de esta máquina. Una sola vez, y es lo que
## habilita el backend hybrid del que salen las cifras del paper.
ft bench bw

## Arranca el servidor. --model acepta una ruta o un identificador de Hugging Face.
ft serve --model Qwen/Qwen3.6-35B-A3B

## Listo cuando el log dice: API server is ready to serve on 127.0.0.1:1919
curl http://127.0.0.1:1919/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"Qwen3.6-35B-A3B","messages":[{"role":"user","content":"hola"}]}'

Los kernels CUDA se compilan en el primer uso, así que necesitas nvcc de CUDA 13 en el PATH. El paso de ft bench bw es el que más se pasa por alto: el modo auto resuelve a offload en los modelos MoE y sólo asciende a hybrid si encuentra un perfil de ancho de banda cacheado. Sin ese comando, no estás midiendo el motor del que habla el paper.

El servidor expone a la vez la API de OpenAI (/v1/chat/completions, /v1/responses, /v1/models) y la de Anthropic (/v1/messages), lo que significa que cualquier cliente de una de las dos funciona apuntando su URL base al puerto 1919. Hay incluso un atajo para agentes de programación:

# Escribe la configuración de proveedor del agente y lo arranca contra tu servidor
ft launch claude    # también: codex, dsh, hermes, openclaw, opencode
ft launch claude --dry-run   # previsualiza los cambios sin tocar nada

Entre los modelos admitidos están DeepSeek-V4, GLM-5.2 y GLM-4.7, la familia Qwen3.6 y Qwen3.8, gpt-oss de 20B y 120B, Gemma-4, MiniMax-M2.5 y Muse-Glimmer, en formatos MXFP4, NVFP4, FP8 y BF16. Si vienes de cuantización con llama.cpp, el cambio de mentalidad está en que aquí se cargan safetensors de Hugging Face directamente y GGUF sólo se admite de forma nativa para Gemma-4.

Los cuatro límites que casi nadie menciona

Aquí es donde la cobertura entusiasta se queda corta. Ninguno de estos puntos invalida el proyecto, pero los cuatro cambian quién puede usarlo hoy.

1. El coste oculto es la RAM del sistema, no la VRAM. El titular dice «284B en un PC gamer». La letra pequeña es que el pool completo de expertos de DeepSeek-V4-Flash ocupa unos 140 GB en FP4 y reside en memoria del host. Un equipo de juego bien equipado lleva 32 GB. Servir ese modelo exige una placa capaz de aceptar 192 GB de DDR5, lo que sitúa la factura mucho más cerca de una estación de trabajo. Qwen3.6-35B-A3B, en cambio, sí entra con holgura en una máquina normal, y ese es el caso de uso realista para la mayoría.

2. El hardware admitido es estrecho. GPUs NVIDIA de las series RTX 30, 40 y 50. La documentación de instalación pide Linux x86_64 y driver r580 o posterior. No hay soporte para AMD ni para Apple Silicon, así que quien trabaje en un Mac se queda con Ollama o LM Studio. Windows sólo entra por la aplicación de escritorio.

3. Es software de seis semanas. El repositorio se creó el 20 de julio de 2026, la única publicación etiquetada es la v0.1.2 del 19 de agosto y hay 247 incidencias abiertas frente a 10 488 estrellas. Ese cociente entre atención e madurez merece prudencia antes de montar nada estable encima.

4. Hay trampas documentadas por modelo. Qwen3.8-Flash-Next mantiene fija una tabla PLE de 47,7 GiB en RAM del host, por encima de los pesos. Los checkpoints de DeepSeek-V4 deben conservar el subdirectorio inference/config.json o el motor no encuentra los argumentos autorizados. Y los checkpoints multimodales se sirven sólo como texto.

Cuándo compensa frente a Ollama o llama.cpp

La comparación honesta depende del modelo que quieras ejecutar, no de cuál motor es «mejor».

Situación Herramienta razonable
Modelos densos de 7B a 30B en cualquier sistema operativo Ollama o llama.cpp
Mac con Apple Silicon Ollama o LM Studio, sin alternativa
Modelo MoE grande que no cabe en VRAM, con GPU NVIDIA y Linux FreeToken
Servir a varios usuarios con lotes y alta concurrencia vLLM en un servidor
Un agente de programación contra un modelo abierto en tu propia máquina FreeToken, por su compatibilidad con la API de Anthropic

El nicho de FreeToken es concreto y hasta ahora estaba vacío: modelos MoE de pesos abiertos demasiado grandes para la GPU, en una máquina con GPU NVIDIA y RAM abundante. Fuera de ahí, las herramientas de siempre siguen siendo la respuesta correcta. Si el interés de fondo es la viabilidad de los modelos de pesos abiertos en la empresa, este motor amplía bastante el terreno de lo que se puede probar sin contratar GPUs por horas.

Merece la pena señalar que el propio proyecto reconoce haber reutilizado diseño y código de SGLang, vLLM, FlashInfer, LightLLM y llama.cpp. No aparece de la nada: es una síntesis cuidadosa de una década de trabajo previo en servicio de modelos, aplicada a un escenario que hasta ahora se consideraba marginal.

Preguntas frecuentes

¿FreeToken funciona en un Mac con chip Apple Silicon?

No. La documentación de instalación exige Linux x86_64 con una GPU NVIDIA y CUDA 13, y la aplicación de escritorio se publica sólo para Windows y Linux. Todo el diseño gira alrededor del reparto entre memoria de la GPU y RAM del host a través de PCIe, un problema que la memoria unificada de Apple no plantea de la misma forma. En un Mac, Ollama o LM Studio siguen siendo la opción.

¿Cuánta memoria RAM necesito de verdad?

Depende por completo del modelo, y esta es la cifra que conviene calcular antes de descargar nada. El pool de expertos vive en memoria del sistema, así que necesitas cubrir el tamaño del modelo cuantizado. Qwen3.6-35B-A3B es cómodo en un equipo con 32 GB. DeepSeek-V4-Flash, con sus 140 GB en FP4, exige una estación de trabajo. La VRAM determina la velocidad, la RAM determina si el modelo arranca.

¿Puedo usarlo con Claude Code u otro agente de programación?

Sí, y es uno de los usos que el proyecto trata como prioritarios. El servidor expone la API de Anthropic en /v1/messages además de la de OpenAI, y el comando ft launch claude escribe la configuración de proveedor del agente y lo arranca apuntando a tu servidor. También cubre codex, hermes, openclaw y opencode. Si te interesa este terreno, el artículo sobre llamadas a funciones con Ollama cubre las bases del uso de herramientas con modelos abiertos.

Conclusión

FreeToken cambia la pregunta. Durante tres años, ejecutar modelos grandes en tu propio equipo consistía en buscar el modelo más pequeño que hiciera el trabajo. Con un reparto adaptativo entre GPU, CPU y RAM, la pregunta pasa a ser cuánta memoria de sistema tienes, y esa es una restricción mucho más barata de levantar que la VRAM.

Dicho esto, la versión 0.1.2 y las 247 incidencias abiertas piden un uso exploratorio, no productivo. La forma sensata de empezar es con Qwen3.6-35B-A3B en una GPU NVIDIA con Linux, ejecutando ft bench bw antes de la primera medición para que el modo hybrid entre en juego. Si funciona en tu hardware, habrás duplicado el tamaño de modelo que tu máquina puede servir sin comprar nada.

Fuentes

  1. FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution (arXiv 2608.16157)
  2. Repositorio y documentación oficial en GitHub
  3. Paquete freetoken 0.1.2 en PyPI
  4. Meet FreeToken, an Edge-Native MoE Serving Engine (MarkTechPost)
  5. Checkpoint Qwen3.6-35B-A3B en Hugging Face