llama-modchip ejecuta DeepSeek de 284.000 millones de parámetros en 64 GB sin GPU

Si un equipo tiene un servidor sin tarjeta gráfica, puede intentar ejecutar un asistente local en su procesador. Ese es exactamente el escenario que propone llama-modchip. La cuestión práctica es sencilla: ¿puede el hardware ya pagado analizar documentos o ayudar con el código con una latencia aceptable? El proyecto ofrece un motivo para montar un experimento, aunque todavía no hay una respuesta lista para tu máquina.

El autor afirma haber ejecutado DeepSeek-V4-Flash con 284.000 millones de parámetros en un sistema con 64 GB de RAM, con una velocidad de generación de 9,1–14,7 tokens por segundo. Son resultados del desarrollador del proyecto; no los hemos reproducido. Fuente original: el repositorio de llama-modchip.

Cómo cabe un modelo grande en la memoria

El proyecto se basa en la compresión de pesos y en cambios en los núcleos de cálculo de llama.cpp. DeepSeek utiliza una arquitectura MoE: al procesar un token trabaja solo una parte de los parámetros. Por eso el número total de parámetros explica por sí solo muy poco la carga de cálculo. El autor estima el tamaño del modelo tras la compresión en 56,56 GiB y presenta mediciones para un procesador AMD Ryzen 9 9955HX. Las condiciones se describen en el README.

En términos cotidianos, la idea se parece a guardar una enciclopedia grande en un formato más compacto: ocupa menos espacio y, para una respuesta concreta, solo hacen falta algunos apartados. La analogía explica el ahorro de recursos, pero no demuestra nada sobre la calidad. Hay que comprobar por separado cuánto se conservan las respuestas tras la compresión.

Imaginemos un asistente interno para el servicio de atención al cliente. Un empleado le pasa la consulta de un cliente y varios extractos de las instrucciones, y el modelo prepara un borrador de respuesta. En un caso así conviene medir todo el recorrido: enviar la solicitud, esperar el inicio de la respuesta, recibir un borrador completo, verificar los datos. Ese tiempo determina si el empleado querrá usar la herramienta a diario.

Si el asistente genera texto con suficiente rapidez pero confunde con regularidad las condiciones de devolución, el ahorro en equipos pierde sentido. Si responde bien pero obliga a esperar antes de cada mensaje, conviene probar un modelo más compacto. El tamaño que figura en el nombre no sustituye la comparación en una tarea real.

Dónde terminan las promesas de velocidad

Los límites superior e inferior del rango declarado se obtuvieron con distintos modos de aceleración. Otra limitación es la compatibilidad: los archivos especiales del modelo requieren compilar el proyecto; Ollama y LM Studio estándar no los cargarán. Estas salvedades figuran en la documentación.

Para un desarrollador, de aquí se deduce un plan de verificación bastante concreto. Primero, tomar varias decenas de consultas típicas y definir de antemano los rasgos de una buena respuesta. Después, ejecutar el mismo conjunto con la alternativa que el equipo ya está considerando: un modelo local más pequeño o una API externa. Conviene comparar la corrección, la latencia y el volumen de correcciones manuales.

Hace falta una prueba aparte para solicitudes simultáneas. Que el chat funcione bien para una persona no significa que el servidor aguante una jornada laboral del equipo. Es útil comprobar cómo crece la cola, si queda memoria para la aplicación y qué ocurre con una consulta larga. En una máquina virtual estas mediciones son especialmente importantes: los resultados en un procesador concreto de portátil no determinan las capacidades de una instancia alquilada.

A quién le conviene probarlo

El candidato más claro es un equipo con un servidor CPU disponible y tareas que admitan una pausa. Por ejemplo, la preparación de borradores, el análisis de textos internos o el procesamiento de una cola de documentos. Son usos posibles, no resultados confirmados por el proyecto.

Lo razonable es empezar con un entorno de pruebas aparte y una pequeña muestra de materiales reales. Hay que registrar la versión de la compilación, los parámetros de arranque y los resultados para poder repetir el experimento. Después, calcular el coste de una respuesta útil teniendo en cuenta el alquiler, el mantenimiento y la revisión humana.

Para un fundador, el valor de la noticia está en que aparece una opción más de infraestructura. Para un responsable de producto, en la posibilidad de probar un escenario local antes de comprar equipos. Para un desarrollador, en un experimento concreto: averiguar si la CPU disponible basta para la carga necesaria. La decisión de implantarlo llegará después de esa medición.