¿De verdad pueden 64 GB de RAM ejecutar DeepSeek V4 Flash 284B sin una GPU?

Un proyecto comunitario informa que ejecutó DeepSeek V4 Flash 284B en una máquina Linux con 64 GB usando solo la CPU. La configuración descrita emplea llama-modchip, un punto de control personalizado con aproximadamente 1,71 bits por peso y una CPU de sobremesa con un ancho de banda de memoria considerable. Considéralo un experimento documentado con una compilación específica, no una recomendación general de dimensionamiento para el punto de control oficial.

El resultado es útil porque permite medir tres cuestiones que normalmente se confunden: si el archivo de pesos cabe, si el proceso puede conservar suficiente memoria durante la generación y si el resultado sigue siendo útil con ese nivel de compresión. El proyecto se dio a conocer en un debate de la comunidad del 8 de noviembre. Las mediciones que aparecen a continuación proceden del repositorio del responsable de mantenimiento de llama-modchip, no de pruebas independientes.

¿Qué modelo de DeepSeek y entorno de ejecución se utilizan?

El proyecto está dirigido a DeepSeek V4 Flash, que en su documentación se describe como un modelo con unos 284B parámetros totales y cerca de 13B activos por token. En un modelo de mezcla de expertos, el enrutador selecciona expertos para cada token. Esto limita el cómputo por token, mientras que es necesario almacenar y tener accesible el conjunto completo de expertos. Consulta la ficha del modelo del desarrollador y el resumen de requisitos de hardware para conocer el contexto habitual de implementación.

El experimento utiliza una transcodificación especializada y parches para el ecosistema ggml/llama.cpp. Incluso otro archivo que anuncie la misma familia de modelos puede tener una disposición de tensores o una precisión diferente. Un binario estándar de llama.cpp y un GGUF convencional deben considerarse una vía aparte. La guía de actualización de llama.cpp existente cubre la vía de lanzamiento oficial.

¿Cómo caben 284 mil millones de parámetros en 64 GB de RAM?

Con un promedio de 1.71 bits por peso, 284 mil millones de pesos implican unos 61 GB de datos empaquetados en unidades decimales. El proyecto informa de un archivo de 56.56 GiB y una memoria residente máxima del proceso de 57.61 GiB en su configuración de 256K. GiB y GB representan unidades distintas. Consulta la memoria realmente disponible en el sistema durante la prueba para entender el margen. Las reservas del firmware, los gráficos integrados y otros procesos pueden consumir gran parte de un margen reducido.

La memoria residente y el tamaño del archivo de pesos son mediciones relacionadas, pero ninguna refleja todas las asignaciones del sistema. Durante la carga, el kernel puede liberar caché del sistema de archivos o mantener búferes temporales. Vigila tanto la memoria del proceso de ejecución como la memoria disponible del sistema. Un conjunto residente elevado durante una prueba capturada tampoco caracteriza todas las longitudes de contexto ni todos los tipos de entrada.

¿Por qué difieren la velocidad del prompt y la velocidad de generación?

El procesamiento del prompt maneja una entrada ya conocida, por lo que el entorno de ejecución puede agrupar el trabajo de varios tokens. La generación es secuencial: el siguiente token depende de los ya generados. La generación en CPU de un modelo MoE depende de la rapidez con la que la máquina pueda cargar desde la memoria los pesos de los expertos seleccionados y su estado. La frecuencia de reloj, la cantidad de canales, los tiempos de memoria y la asignación de hilos pueden cambiar el resultado.

Separa una prueba de prompt breve de un prompt largo del repositorio. Mide por separado el tiempo hasta el primer token y la generación posterior. Un prefijo más largo puede dominar la latencia total aunque la transmisión parezca ágil una vez que comienza. Registra si el entorno de ejecución reutilizó el estado en caché. Un prefijo precalentado y una ejecución en frío responden a preguntas distintas. La documentación de la herramienta de pruebas de rendimiento del proyecto original explica las mediciones del prompt y de la generación.

¿Cuánta calidad se pierde con esta precisión?

Los bits por peso resumen el almacenamiento, no la calidad del modelo. Se puede asignar una precisión distinta a cada tensor, y dos conversiones de tamaño similar pueden comportarse de forma diferente. Conviene comprobar aspectos como el razonamiento extenso, la sintaxis exacta, los argumentos de herramientas y el vocabulario poco común. Una respuesta legible a una pregunta demuestra que la generación funciona. No demuestra que la misma compilación sea fiable para un flujo de trabajo de programación.

Elige un conjunto de referencia pequeño antes de probar. Incluye una tarea con formato de salida exacto, una función con una prueba fallida conocida, una búsqueda en un contexto largo y una solicitud que el modelo debería abordar con cautela. Compara con una referencia compatible de mayor precisión o más pequeña usando las mismas instrucciones. Mantén estables las entradas de prueba y registra las salidas incompletas, las llamadas a herramientas mal formadas y los tiempos de espera agotados. Fija las revisiones del modelo y del entorno de ejecución para poder atribuir cualquier mejora posterior.

¿Cómo reproducirías el resultado de forma responsable?

Empieza con una máquina de prueba Linux aislada, suficiente espacio en el SSD y el checkpoint y la revisión exactos del mantenedor. Lee las instrucciones de compilación y de inicio rápido del proyecto, inspecciona los scripts antes de ejecutarlos y anota tu CPU, la configuración de memoria y el kernel. Una instrucción breve sin herramientas de shell habilitadas es una primera prueba útil. Aumenta el contexto solo cuando sepas que el equipo anfitrión sigue respondiendo con normalidad.

1. Mide la memoria libre y la actividad del espacio de intercambio antes de cargarlo. Detén otros experimentos que consuman muchos recursos en la misma máquina.
2. Anota el tamaño exacto del archivo del checkpoint y su hash, la versión del ejecutor y cualquier ajuste especial de transcodificación o asignación de expertos.
3. Registra el pico de RSS, el tiempo hasta el primer token, los tokens de salida por segundo y si se usó el espacio de intercambio. Ejecuta la prueba dos veces para separar el comportamiento en frío de los efectos de la caché.
4. Compara la corrección de los resultados antes de usar el modelo en un trabajo más largo. Comprueba la exposición de datos y el acceso al sistema de archivos si más adelante conectas un agente.

Usa árboles de trabajo aislados de Git para las tareas del repositorio. Si el equipo anfitrión también proporciona almacenamiento doméstico o servicios de copia de seguridad, haz el primer experimento en una máquina de cómputo aparte. Un proceso de inferencia que ocupa toda la RAM puede interferir con esos servicios mucho antes de que se produzca un error por falta de memoria.

¿Cuándo conviene elegir un modelo más pequeño?

Elige un punto de control más pequeño si necesitas una velocidad interactiva constante, actualizaciones sencillas o margen suficiente para varias sesiones. El experimento comunitario es más interesante si puedes aceptar código personalizado, menor precisión y una reproducción cuidadosa. Un modelo para uso diario que funcione en un entorno de ejecución compatible puede ser más fácil de mantener y quizá complete más tareas útiles por hora. Compara ambos con la misma tarea antes de cambiar una configuración de producción.

Preguntas frecuentes

¿Se necesita una GPU dedicada?

El responsable del proyecto informa de una ejecución solo con CPU para el punto de control 284B especificado. Otras configuraciones del repositorio incluyen variantes con asistencia de GPU, así que mantén separados los perfiles de prueba.

¿Cualquier PC con 64 GB alcanzará la velocidad indicada?

La memoria instalada por sí sola no permite afirmar que se alcanzará una velocidad determinada. La generación en CPU depende del ancho de banda de memoria, los núcleos y la asignación de hilos, y el sistema necesita suficiente RAM disponible.

¿Veré una velocidad de 44 tok/s en el flujo del chat?

La cifra de aproximadamente 44 tok/s se refiere al procesamiento del prompt en la configuración citada. El repositorio informa un rango independiente más bajo para la generación autorregresiva.

¿El contexto de 256K es la primera configuración que debería probar?

Empieza con una configuración más corta y mide. La cifra de memoria del responsable del proyecto corresponde a una configuración específica del ejecutor y del punto de control.

¿Esto reemplaza la guía de hardware publicada?

Usa la guía oficial del modelo para la implementación estándar. Considera llama-modchip una alternativa comunitaria, con sus propias limitaciones de precisión, compatibilidad y rendimiento.

Conclusión

El resultado interesante es que un tiempo de ejecución específico para CPU y un punto de control personalizado de pocos bits pueden permitir que un modelo MoE sorprendentemente grande quepa dentro de un presupuesto de memoria reducido. Reproduce la compilación exacta, distingue entre el prellenado y la decodificación, y prueba la calidad de los resultados antes de confiar en él. Un modelo más pequeño sigue siendo un control útil al evaluar la latencia cotidiana.