FreeToken llama: Guía y consejos para configurar MoE local

FreeToken llama se entiende mejor como un término de búsqueda relacionado con la inferencia local, no como el nombre de un producto Llama independiente. FreeToken es un motor de serving nativo para el edge, diseñado para ejecutar modelos de Mixture-of-Experts de pesos abiertos y escala avanzada en hardware de consumo. El proyecto combina el procesamiento de la GPU, la ejecución de la CPU, la memoria del host y el ancho de banda de las interconexiones en una única plataforma de inferencia.

La información disponible del proyecto no establece una compatibilidad universal con todos los modelos de la familia Llama. Considera la compatibilidad con Llama como una cuestión específica de cada modelo: confirma la arquitectura, el formato de los pesos, el tokenizador, el comportamiento del contexto y la ruta de ejecución compatible antes de comprometerte con una configuración. Esto evita confundir una familia de modelos con el motor de serving.

La página oficial del proyecto FreeToken describe aplicaciones de escritorio para Windows y Linux, además de la instalación mediante línea de comandos a través de uv o pip. La misma página identifica funciones como la coejecución CPU–GPU adaptada al ancho de banda, el streaming de prefill con doble búfer, la caché global de expertos con política de uso menos reciente (LRU), la ejecución compatible con grafos y el formato rápido de pesos FTW.

Terminología principal:

Descripción general oficial del proyecto: FreeToken en GitHub

FreeToken aborda un problema central de la inferencia MoE a gran escala: el modelo completo puede ser mucho más grande que la memoria gráfica disponible, mientras que cada token solo activa una parte de los expertos. Por ello, el runtime debe decidir qué pesos permanecen en la GPU, cuáles se mantienen en la memoria del host y cuáles deben ejecutarse directamente en la CPU.

Durante el prefill, muchos tokens del prompt acceden colectivamente a un amplio conjunto de expertos. FreeToken utiliza streaming con doble búfer para la capa completa, de modo que una capa pueda calcularse mientras se transfiere la siguiente. Esta superposición pretende ocultar parte del coste de movimiento tras el trabajo aritmético, en lugar de esperar a que cada transferencia termine de forma secuencial.

Durante el decode, los patrones de acceso se vuelven dispersos e interactivos. La colocación estática de expertos puede no mantener los expertos solicitados con frecuencia, por lo que FreeToken mantiene una caché global de expertos LRU. Su política adaptada al ancho de banda mide el equilibrio real de la máquina entre las cargas en la GPU y la ejecución en la CPU, y después distribuye los fallos de caché según la ruta que probablemente termine antes.

El proyecto también incluye almacenamiento en caché con conciencia semántica para contextos agénticos. Cuando se producen llamadas a herramientas, bloques de razonamiento u otras ediciones del contexto, los checkpoints de anclaje semántico pueden ayudar a evitar el recálculo del contexto que no ha cambiado. Esto es especialmente importante en cargas de trabajo interactivas de larga duración, más que en prompts cortos y aislados.

Aspectos destacados del vídeo:

• FreeToken separa el prefill y el decode como problemas distintos de ancho de banda.
• La colocación de expertos y los fallos de caché influyen en el tiempo de respuesta interactivo.
• El hardware local puede servir modelos más grandes que la memoria disponible de la GPU.
• La latencia del peor turno importa en las sesiones de agentes, no solo la velocidad media.

FreeToken está diseñado para sistemas de consumo heterogéneos, por lo que la memoria de la GPU es solo una parte del cálculo de capacidad. La RAM del sistema proporciona espacio adicional para los pesos del modelo, mientras que la ejecución de la CPU y el enlace entre los distintos grupos de memoria influyen en la rapidez con la que pueden entregarse los expertos que faltan.

Los materiales del proyecto informan de que una GPU de portátil con 8 GB puede servir un modelo de 35.000 millones de parámetros a aproximadamente 39 tokens por segundo con una configuración de prueba concreta. También informan de un modelo de 753.000 millones de parámetros ejecutándose en una única GPU de estación de trabajo a casi 15 tokens por segundo. Estos son resultados de referencia, no garantías para todos los checkpoints de Llama, sistemas operativos, cuantizaciones, prompts o configuraciones de hardware.

La misma discusión sobre el rendimiento destaca la latencia de cola. En cuatro cargas de trabajo interactivas de agentes, el turno más lento de FreeToken se mantuvo por debajo de 44 segundos en la comparación citada, mientras que las configuraciones de referencia alcanzaron al menos 150 segundos en algún punto de las pruebas. Una configuración de referencia necesitó 946 segundos para un solo turno. Estas cifras describen condiciones experimentales específicas y no deben considerarse benchmarks universales.

Para un experimento con la familia Llama, registra el checkpoint exacto, el formato, la longitud del contexto, la cuantización o representación de los pesos, la GPU, la memoria del sistema y la versión del runtime. Sin estos detalles, las comparaciones pueden resultar engañosas. Un modelo más pequeño con una mejor localidad puede parecer más ágil que un modelo más grande que mueve repetidamente expertos fríos a través de un enlace lento.

Utiliza el siguiente flujo de trabajo para pasar de una idea vaga sobre el modelo a una prueba local controlada. La secuencia es intencionadamente conservadora: valida primero el motor, confirma la compatibilidad del modelo y después ajusta el rendimiento.

Una primera prueba práctica debería incluir tanto un prompt conversacional corto como uno más largo que se parezca a la carga de trabajo prevista. Los prompts cortos revelan el comportamiento básico de inicio, mientras que los largos ponen a prueba el streaming de prefill y la gestión del contexto. Si el sistema va a utilizar agentes con herramientas, prueba varios turnos con ediciones del contexto en lugar de depender de una única finalización.

Cuando una configuración de FreeToken llama parezca lenta, identifica si el problema ocurre durante la carga, el prefill o el decode. Cada etapa apunta a un cuello de botella diferente. Los retrasos prolongados durante el inicio suelen indicar problemas de almacenamiento o del movimiento inicial de los pesos. Las primeras respuestas lentas pueden reflejar el procesamiento del prompt y las transferencias de capas. Una generación irregular de tokens puede indicar fallos de caché, uso alternativo de la CPU, presión de memoria o limitación térmica.

Evita optimizar únicamente para la velocidad media. Una configuración que produzca prompts sencillos con rapidez, pero se bloquee durante un turno más largo de un agente, puede no ser adecuada para el uso real. La arquitectura de FreeToken se preocupa explícitamente por el comportamiento interactivo en el peor caso, por lo que las cargas de trabajo repetidas y mixtas ofrecen una evaluación más útil.

Prioridades habituales de ajuste:

• Mantén suficiente memoria del sistema disponible para los pesos del modelo transmitidos y el estado del runtime.
• Reduce el contexto innecesario cuando la aplicación no necesite todo el historial.
• Prueba conversaciones sensibles a la caché en lugar de utilizar solo prompts aislados.
• Compara el uso alternativo de la CPU con el comportamiento de carga en la GPU en la máquina real.
• Supervisa el rendimiento sostenido en lugar de observar solo los primeros tokens generados.
• Conserva una configuración conocida y estable antes de cambiar varios ajustes.

Como contexto de investigación, el proyecto identifica su artículo como “FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution.” La información de citación está disponible en el repositorio oficial y en el registro del artículo en arXiv. El repositorio también reconoce la inspiración y las ideas de diseño reutilizadas de proyectos como SGLang, vLLM, FlashInfer, LightLLM y llama.cpp.