- Estado de FreeToken docker: La compatibilidad nativa con Docker no está disponible en el estado de la versión reportada actualmente.
- Entorno compatible: FreeToken está orientado a cargas de trabajo Nvidia CUDA en Linux y Windows.
- Limitación principal: Los problemas de instalación en Windows y la ausencia de compatibilidad con contenedores siguen siendo preocupaciones pendientes.
- Mejor preparación: Valida primero los controladores Nvidia, el acceso a CUDA, el almacenamiento del modelo y la memoria del host.
- Enfoque seguro: Sigue las actualizaciones del repositorio oficial en lugar de utilizar imágenes de contenedor no verificadas.
Estado de FreeToken docker en 2026
FreeToken es un sistema de inferencia de IA local diseñado para hacer prácticos los modelos de mezcla de expertos de gran tamaño en hardware de estaciones de trabajo. La situación actual de FreeToken docker es sencilla: los informes disponibles indican que la compatibilidad con Docker aún no está incluida, mientras que una solicitud específica de compatibilidad con Docker permanece abierta en el registro de incidencias de GitHub del proyecto.
Esto significa que los usuarios no deben tratar FreeToken como una imagen de contenedor lista para ejecutar ni asumir que funcionará un comando estándar docker run. Una implementación mediante contenedor podría ser posible más adelante gracias a experimentos de la comunidad, pero una imagen no oficial puede introducir problemas de compatibilidad, seguridad y reproducibilidad.
Aspectos destacados del video:
- FreeToken utiliza una asignación dinámica de expertos en lugar de una división fija entre CPU y GPU.
- Los resultados reportados incluyen hardware Nvidia de estaciones de trabajo y portátiles.
- El proyecto fue descrito como centrado en Linux y Windows con compatibilidad con CUDA.
- Docker, GGUF, las configuraciones con dos GPU y Apple Silicon fueron señalados como áreas sin compatibilidad disponible.
No copies comandos aleatorios de contenedores de FreeToken publicados en redes sociales a menos que la imagen, el Dockerfile, el commit y los requisitos de hardware puedan verificarse mediante el repositorio oficial del proyecto.
La página pública de incidencias del proyecto incluye Docker Support · Issue #11, abierta el 21 de agosto de 2026. En el momento de la captura referenciada, la página mostraba la solicitud como abierta, sin un mantenedor asignado ni una rama de desarrollo vinculada. Consulta la incidencia oficial sobre la compatibilidad con Docker antes de planificar una implementación en producción.
| Área de implementación | Estado reportado | Significado práctico |
|---|---|---|
| Imagen nativa de Docker | No se ha informado de su disponibilidad | No asumas que existe una imagen oficial |
| Nvidia CUDA | Enfoque compatible | El objetivo relevante es el hardware Nvidia en Linux o Windows |
| Instalación en Windows | Se han informado problemas | Prueba primero el entorno nativo antes de añadir contenedores |
| Modelos GGUF | Se han informado como no compatibles | No asumas que se cargarán archivos de modelo de llama.cpp |
| Apple Silicon | Se ha informado como no compatible | La implementación en Mac no es un objetivo actual |
| Funcionamiento con dos GPU | Se ha informado como no compatible | Un plan de Docker con varias tarjetas podría no resolver la limitación |
Por qué es difícil contenerizar FreeToken
La principal idea técnica de FreeToken no consiste simplemente en cargar un modelo grande en una sola GPU. El sistema reportado gestiona una arquitectura de mezcla de expertos seleccionando solo un subconjunto de expertos para cada token y administrando dinámicamente las lecturas de los expertos. Este comportamiento hace que la ubicación de la memoria y el movimiento de datos sean elementos centrales del rendimiento.
Un contenedor tradicional puede empaquetar bibliotecas y procesos, pero no resuelve automáticamente los límites de memoria de la GPU. El host sigue necesitando controladores Nvidia compatibles, acceso a CUDA, RAM del sistema, ancho de banda de almacenamiento y permisos para que el runtime del contenedor se comunique con la GPU.
Los pesos del modelo son otra consideración importante. El análisis citado describe un modelo de 753 mil millones de parámetros cuyos pesos de cuatro bits ocupan aproximadamente 433 GB en disco. Para cada token solo se necesita un conjunto más pequeño de expertos activos, pero los expertos inactivos también deben almacenarse y estar disponibles cuando cambie el enrutamiento.
Acceso a la GPU
El contenedor necesitaría un acceso fiable al runtime de Nvidia, controladores compatibles y un entorno CUDA alineado con la compilación de FreeToken.
Almacenamiento del modelo
Las grandes colecciones de expertos requieren un almacenamiento considerable en el host y una estrategia de montaje predecible. Las capas del contenedor no sustituyen la planificación del almacenamiento del modelo.
Enrutamiento del runtime
La selección dinámica de expertos produce cambios en la carga de trabajo durante la inferencia. Las divisiones fijas de memoria pueden rendir mal cuando los expertos activos cambian entre tokens.
La comparación reportada con la descarga estática de expertos muestra por qué un simple envoltorio de contenedor no es suficiente. Un contenedor puede aislar las dependencias, pero no mejora la política de enrutamiento, reduce las transferencias PCIe ni aumenta la VRAM disponible.
| Recurso | Por qué importa | Pregunta previa |
|---|---|---|
| GPU Nvidia | Ejecuta las operaciones activas del modelo | ¿El host expone correctamente la GPU? |
| VRAM | Contiene los pesos activos, las cachés y los búferes del runtime | ¿Hay suficiente memoria disponible para la carga de trabajo seleccionada? |
| RAM del sistema | Almacena los pesos de los expertos descargados | ¿El host puede contener los archivos completos del modelo? |
| Almacenamiento NVMe | Proporciona los datos del modelo y reduce los retrasos de carga | ¿El modelo está almacenado en una unidad local rápida? |
| Runtime de CUDA | Conecta la aplicación con el hardware Nvidia | ¿Coinciden las versiones del controlador y del runtime con la compilación? |
| Runtime del contenedor | Proporciona aislamiento y dependencias repetibles | ¿Hay disponible una imagen oficial o un Dockerfile reproducible? |
Una capa de Docker puede mejorar el aislamiento de dependencias, pero no puede sustituir a los controladores de GPU compatibles, suficiente memoria del sistema, almacenamiento rápido ni una ruta de ejecución oficialmente compatible.
Comprobación paso a paso de la preparación para FreeToken Docker
Hasta que se documente la compatibilidad oficial con contenedores, el flujo de trabajo más seguro es una evaluación de preparación en lugar de una implementación improvisada. Estos pasos ayudan a separar los problemas del host de los problemas del runtime de FreeToken y reducen la posibilidad de solucionar varias variables desconocidas a la vez.
Verifica el estado oficial del proyecto
Abre el repositorio de FreeToken y revisa su README actual, las versiones publicadas, las notas de instalación y las incidencias abiertas. Confirma si se ha añadido un Dockerfile oficial, una entrada en un registro de imágenes o una guía específica para contenedores desde el 29 de agosto de 2026.
Valida el hardware del host
Confirma que el equipo utiliza hardware Nvidia destinado a cargas de trabajo CUDA. Registra la VRAM disponible, la RAM del sistema, la capacidad de almacenamiento y las versiones de los controladores antes de intentar configurar el modelo.
Separa las pruebas nativas de las pruebas con contenedores
Si está disponible la instalación nativa documentada por el proyecto, prueba primero esa ruta. Una línea base nativa facilita determinar si un problema posterior del contenedor procede de FreeToken, del acceso a CUDA, de los montajes del sistema de archivos o de la configuración de la imagen.
Planifica los montajes del modelo y la caché
Mantén los archivos grandes del modelo fuera de las capas desechables del contenedor. Utiliza directorios del host claramente documentados para los pesos del modelo, las cachés, los registros y la configuración, de modo que reconstruir un contenedor no requiera volver a descargar ni reconstruir el entorno.
Registra versiones reproducibles
Guarda el commit de FreeToken, la revisión del modelo, el controlador Nvidia, el runtime de CUDA, el sistema operativo y los detalles del hardware. Evita actualizar varios componentes a la vez mientras diagnosticas fallos de rendimiento o de inicio.
El proceso debería terminar con una decisión documentada: esperar a la compatibilidad oficial con Docker, continuar con una instalación nativa o probar una compilación de la comunidad claramente etiquetada en un entorno aislado. No presentes una imagen de la comunidad como una versión oficial de FreeToken.
| Punto de comprobación | Condición para aprobar | Si falla |
|---|---|---|
| Revisión del repositorio | Hay instrucciones oficiales y actualizadas para contenedores | Utiliza la ruta nativa documentada o espera |
| Visibilidad de la GPU | El runtime puede acceder al dispositivo Nvidia | Corrige los controladores del host y los permisos del runtime |
| Capacidad de almacenamiento | Los archivos del modelo caben en el almacenamiento local persistente | Amplía el almacenamiento o selecciona un modelo más pequeño |
| Planificación de memoria | La RAM y la VRAM se ajustan a la carga de trabajo prevista del modelo | Reduce el alcance o cambia el hardware |
| Registro de versiones | Se han registrado todas las versiones de software | Detente y documenta primero el entorno |
Trata la configuración del host como parte de la implementación. Registra cada versión y ruta de montaje antes de cambiar el runtime para que los resultados de rendimiento sigan siendo significativos.
Expectativas de rendimiento y compensaciones
El rendimiento reportado de FreeToken depende en gran medida del modelo, la GPU, el comportamiento de la memoria y el método de medición. Las cifras citadas incluyen aproximadamente entre 77 y 83 tokens por segundo para una carga de trabajo reportada de Qwen 35B en una estación de trabajo de clase RTX 5090, entre 22 y 25 tokens por segundo para DeepSeek V4 Flash y 14,9 tokens por segundo para GLM 5.2 en una comparación. En los informes también se destacó un resultado de 39,3 tokens por segundo en un portátil.
Estas cifras deben tratarse como resultados reportados por el proyecto, no como benchmarks universales de Docker. La sobrecarga del contenedor suele ser menor que el coste de ejecución del modelo, pero una configuración incorrecta de la GPU, montajes de volúmenes lentos, la traducción del sistema de archivos o bibliotecas incompatibles pueden producir resultados muy diferentes.
El argumento económico también es más amplio que una simple etiqueta de “gratis”. La inferencia local puede reducir el uso recurrente de API y mantener los prompts en hardware privado, pero la inversión en hardware, la electricidad, el mantenimiento, el almacenamiento de modelos y el tiempo de configuración siguen siendo factores importantes.
| Factor de la carga de trabajo | Efecto reportado o relevante | Interpretación para la implementación |
|---|---|---|
| Cantidad de expertos activos | Solo los expertos seleccionados trabajan para cada token | El enrutamiento dinámico puede hacer impredecible el acceso a la memoria |
| Descarga estática a la CPU | Se ha informado que pierde más lecturas de expertos | Una división fija básica puede reducir el rendimiento |
| Clase de GPU | Los resultados de estaciones de trabajo y portátiles difieren | Haz benchmarks en el host exacto en lugar de copiar cifras destacadas |
| Longitud del contexto | Un contexto más grande aumenta la presión sobre la memoria | Controla el tamaño de la caché y de los prompts durante las pruebas |
| Ruta de almacenamiento | Los modelos grandes dependen de archivos persistentes | Prefiere el almacenamiento local rápido a los montajes de red lentos |
| Método de medición | Las velocidades de decodificación y de extremo a extremo son diferentes | Compara métricas equivalentes, no denominadores distintos |
Para los usuarios de contenedores, la métrica más importante no es una única velocidad máxima de tokens. Registra el éxito del inicio, el tiempo de carga del modelo, la velocidad de decodificación sostenida, el uso de memoria, la tasa de errores y el comportamiento con la longitud de contexto prevista.
Compara las ejecuciones nativas y en contenedor usando el mismo modelo, prompt, contexto, configuración de caché, hardware y definición de medición. Un resultado basado únicamente en la decodificación no debe compararse directamente con un resultado de extremo a extremo.
Una configuración local todavía puede resultar atractiva por la privacidad, la disponibilidad y el control sobre las versiones de los modelos. Sin embargo, esas ventajas deben sopesarse frente a la actual falta de compatibilidad y a la posibilidad de que un flujo de trabajo en contenedores requiera mantenimiento por parte de la comunidad.
Límites conocidos y alternativas seguras
La situación actual de compatibilidad de FreeToken tiene varios límites que afectan directamente a la planificación con Docker. Los informes citados indican que no hay compatibilidad con Docker, GGUF, configuraciones con dos GPU ni Apple Silicon. También describen fallos de instalación en Windows. Estas limitaciones significan que un contenedor no es una capa de compatibilidad universal.
Si tu hardware está fuera del objetivo de Nvidia CUDA, añadir Docker difícilmente hará compatible el runtime. Del mismo modo, un contenedor no puede convertir automáticamente archivos GGUF no compatibles ni crear una planificación multin GPU que la propia aplicación no proporcione.
Utiliza la siguiente guía de decisión para elegir el próximo paso de forma responsable sin exagerar las capacidades actuales.
Host Linux con Nvidia
Es la opción más adecuada para investigar el flujo de trabajo orientado a CUDA documentado. Establece una línea base nativa antes de experimentar con contenedores.
Host Windows
Procede con cuidado porque se han informado problemas de instalación. Confirma las indicaciones actuales del proyecto antes de cambiar de runtime.
Apple Silicon
No es un objetivo actual según la situación de compatibilidad mencionada. No esperes que Docker añada automáticamente compatibilidad con las GPU de Apple.
Sistema multin GPU
No asumas que dos tarjetas se combinarán correctamente. Espera a que se documente el funcionamiento con dos GPU o a una actualización oficial.
Antes de probar un contenedor:
- Comprueba si el repositorio oficial de FreeToken incluye un Dockerfile o una imagen actualizados
- Confirma los requisitos de controlador Nvidia, CUDA, VRAM, RAM y almacenamiento
- Mantén los archivos del modelo en almacenamiento persistente del host en lugar de capas de imagen desechables
- Registra el commit del repositorio, la revisión del modelo y la configuración del benchmark
- Evita exponer servicios de inferencia privados hasta configurar la autenticación y los controles de red
Para recibir actualizaciones, consulta el repositorio de FreeToken en GitHub y la incidencia sobre la compatibilidad con Docker. Estos enlaces son más fiables que fragmentos de configuración no verificados porque muestran los cambios del proyecto, el estado de las incidencias y las conversaciones de los mantenedores.
Nunca expongas directamente a Internet un endpoint de inferencia experimental. Utiliza el acceso local o una red protegida hasta confirmar la autenticación, la autorización, los registros y los límites de recursos.
Preguntas frecuentes sobre FreeToken Docker
Q: ¿FreeToken tiene compatibilidad oficial con Docker?
El estado del proyecto de agosto de 2026 al que se hace referencia no muestra un flujo de trabajo oficial de Docker disponible. La compatibilidad con Docker se sigue en la incidencia n.º 11 de GitHub, así que consulta esa incidencia y el repositorio para conocer las actualizaciones posteriores.
Q: ¿Puede Docker hacer que FreeToken funcione en Apple Silicon?
No. Docker puede empaquetar dependencias de software, pero no proporciona automáticamente un backend para GPU de Apple. Según la situación de compatibilidad actual, Apple Silicon no está disponible.
Q: ¿Debería utilizar una imagen de contenedor de FreeToken creada por la comunidad?
Solo después de verificar su origen, commit, Dockerfile, dependencias y prácticas de seguridad. Una imagen de la comunidad debe etiquetarse como no oficial y probarse en un entorno aislado.
Q: ¿Qué hardware debo preparar para FreeToken?
El enfoque documentado es el hardware Nvidia compatible con CUDA, junto con una cantidad considerable de RAM del sistema y almacenamiento para los archivos grandes del modelo. Los requisitos exactos dependen del modelo, el tamaño de la caché y la configuración del runtime.
FreeToken es prometedor para la inferencia local con mezcla de expertos, pero actualmente Docker debe considerarse un tema en seguimiento de compatibilidad y no un método de instalación garantizado.