Un modelo que en FP16 necesitaría 1,5 TB de VRAM, funcionando en solo 192 GB

El martes 6 de octubre intentamos cargar DeepSeek-V4.1-Flash, un modelo de 763B de parámetros, en una máquina con dos tarjetas gráficas de 96 gigas. Los dos primeros intentos fallaron por falta de memoria. El tercero arrancó y se puso a responder.

Lo normal es servir modelos así en máquinas de centro de datos. Queríamos saber si dos tarjetas bastaban y qué daban de sí. Este es el resumen:

Y el modelo merece la pena. En LiveBench, una clasificación independiente que cambia sus preguntas para que nadie se las aprenda, es el primero de 69 en programación con agentes:

Son puntuaciones de los modelos completos, servidos por sus propios proveedores.

Con sus 763B de parámetros a dos bytes cada uno, en FP16 el modelo ocuparía unos 1,5 TB. DeepSeek lo publica ya comprimido, en unos 475 gigas, y la comunidad lo deja en unos 310. Repartido entre las dos tarjetas, a cada una le tocan 102,1 gigas, y cada tarjeta tiene 95,6. Faltan seis gigas por tarjeta, y eso sin contar la memoria que necesita la conversación. Los dos primeros intentos fallaron justo por eso.

DeepSeek-V4.1-Flash funciona como un equipo de especialistas. En cada una de sus 40 capas hay 384, y para cada token (un trozo de palabra) solo trabajan 6. El resto está parado.

Si la mayoría está parada, no hace falta que esté dentro de la tarjeta. El tercer intento usaba un fichero que manda un tercio de esos especialistas, 4.608 de 15.360, a la memoria normal del ordenador. Cuando un token necesita a uno de ellos, la tarjeta lo consulta allí directamente. Así a cada tarjeta le quedan unos 72 gigas, y el modelo entra con margen.

Ese truco no es nuestro, y el resultado es de mucha gente. DeepSeek publicó los pesos del modelo para que cualquiera pudiera usarlos. coolbho3k lo comprimió a 3 bits. turboderp creó el formato de compresión y los programas que lo hacen rápido. Victor Cruz lo conectó con vLLM, un servidor de modelos de código abierto. Diffbot tuvo la idea de mandar especialistas a la memoria del ordenador, la programó y publicó la receta.

Nosotros lo juntamos todo, lo hicimos funcionar de principio a fin y lo medimos: qué entra en memoria, a qué velocidad responde, a cuánta gente atiende, cuánto cuesta y si sigue respondiendo igual de bien. Antes de empezar revisamos quién había escrito cada pieza, para reconocer a cada uno su parte. También comprobamos que, solo con lo que vLLM trae de serie, el modelo no llega a funcionar en estas tarjetas.

Un agente de código trabaja con mucho contexto: el proyecto, el historial, los ficheros abiertos. Así que lo pusimos a prueba con textos enormes.

Con una pregunta corta, el servidor escribía cada token en 7,6 milésimas de segundo. Con un contexto sesenta y cuatro veces más largo, de unos 256.000 tokens, tardaba 8,3, casi lo mismo.

Leer un texto enorme por primera vez sí lleva su tiempo: 18 segundos para 128.000 tokens. Pero un agente trabaja siempre sobre el mismo proyecto, y lo que ya se ha leído no hay que leerlo otra vez. Con cuatro personas trabajando sobre el mismo contexto gigante, la respuesta empezaba a llegar en menos de dos segundos.

Para programar con un agente al lado, hace falta que conteste con fluidez. Pusimos el listón en 40 tokens por segundo para cada persona.

Con un agente trabajando solo, el servidor le daba unos 186 tokens por segundo. Con cuatro a la vez, 59 a cada uno, muy por encima del listón. Lo probamos en seis situaciones, de sesiones cortas a contextos de 256.000 tokens, y en todas las que llegaron hasta ahí aguantó a cuatro agentes a la vez sin bajar de 40.

Cuatro agentes a la vez pueden parecer pocos, pero nadie le pide a la IA que escriba todo el rato.

Medimos una semana real de un desarrollador con Claude Code. De toda la semana, la IA estuvo escribiendo para él unas 2,8 horas, el 1,7%. El resto del tiempo era él quien leía, pensaba y tecleaba.

Imagina un bar con cuatro taburetes en la barra. La gente entra, pide, se va a su mesa y vuelve un rato después. Con cuatro taburetes atiendes a mucha más gente que a cuatro personas. Con 19 desarrolladores como este, menos de una vez de cada cien coincidirán cinco a la vez. Y aun entonces nadie se queda sin respuesta: solo va todo un poco más despacio durante ese rato.

El servidor cuesta 3,73 euros la hora, unos 2.723 euros al mes encendido día y noche. Es lo mismo que 15 suscripciones de 180 euros. Con 19 personas, el servidor ya sale más barato que pagar sus suscripciones.

Y con equipos grandes la cuenta mejora, porque las prisas de mucha gente se reparten mejor. 100 desarrolladores caben en 4 servidores, lo que sale un 39% más barato que pagar sus suscripciones. 250 caben en 7, un 58% más barato.

Son cifras de alquiler de máquinas, sin contar a quien lo monta y lo mantiene, y una suscripción comercial incluye un producto entero. Además, con el modelo en tus máquinas decides qué modelo usas y cuándo lo cambias. Y el código y los secretos que lee el agente, que son muchos (este desarrollador releía 234 tokens de contexto por cada uno que escribía la IA), no salen de casa. En máquinas propias, esa ventaja es completa.

Comprimir un modelo a 3 bits suena a perder calidad. Lo comprobamos poniendo a nuestra versión y al servicio oficial de DeepSeek a hacer los mismos tres exámenes:

• Matemáticas: los dos acertaron el 96% y fallaron exactamente las mismas preguntas.
• Seguir instrucciones: el nuestro un 87%, el oficial un 85%.
• Escribir código: el nuestro un 96%, el oficial un 98%.

En exámenes de unas 150 preguntas, uno o dos puntos son ruido estadístico. En lo que medimos, la versión que funciona en dos tarjetas responde como el servicio oficial.

Cada cifra de este artículo sale de un fichero de datos, y el paper ni siquiera se genera si falta alguno.

El modelo funciona en dos tarjetas, atiende a un equipo de 19 personas y responde como el original. Nos queda una pregunta por contestar: cuánto más rápido iría en una máquina de centro de datos con memoria de sobra para el modelo entero.

El experimento que lo dirá ya está escrito y preparado. Se llama E9.

Los datos exactos, para quien quiera comprobarlos:

• Memoria. En BF16 los pesos ocuparían unos 1.526,7 GB (763,2B parámetros, cálculo de llmrun.dev). Checkpoint original de DeepSeek (FP4 y FP8) 475,2 GiB y pack EXL3 de 3 bits 309,3 GiB. Sin offload hacen falta 102,1 GiB por GPU frente a 95,6 disponibles, y con el plan gen30, 72,4 GiB. Al host van 4.608 de 15.360 expertos enrutados, las dos tablas Engram en int4 y el embedding, leídos directamente por UVA sobre PCIe. 2x RTX PRO 6000 Blackwell.
• Autoría. Pesos de DeepSeek. Pack EXL3 de coolbho3k. EXL3 y ExLlamaV3 de turboderp. vllm-exl3 de Victor Cruz. Plan por experto, lanzamiento dividido y kernels de Diffbot, sobre vLLM. El offload UVA del propio vLLM, con los mismos bytes en host, falla al inicializar con bloque KV de 64 y muere en la primera petición con 128.
• Leer y escribir. TPOT mediano de 7,6 ms tras 4K tokens y de 8,3 ms tras 256K (pod 2). TTFT de 18,33 s para 128K y de 45,07 s para 260.000. Con prefijo de 256K en caché y 4 usuarios: TTFT p95 de 1,66 s y TPOT mediano de 16,6 ms.
• Agentes (E13, pod 3). Turnos de agente, tok/s por stream (mediana / p5): 1: 186/134, 2: 95/68, 3: 70/59, 4: 59/52, 6: 40/34, 8: 31/24. Capacidad de 4 streams con un margen del 10%. Cinco contextos de 128K usaron como mucho el 48% de la caché KV.
• Asientos. q = 7,1% en una ventana de 8 h. P(Binomial(19, q) > 4) ≤ 1%, y con 5% caben 28. Equilibrio en 15,1 suscripciones de 180 euros.
• Calidad. Subconjuntos fijos, sin thinking, contra la API de DeepSeek. GSM8K 0,960 frente a 0,960 (150 ítems). IFEval +0,013 [-0,013, +0,047]. HumanEval -0,018 [-0,049, +0,012].
• Topología. Un pod con las GPUs en nodos NUMA distintos fue entre 1,17 y 1,51 veces más lento. Mira nvidia-smi topo -m antes de medir.
• Límites.
  • Cada experimento sale de un único arranque.
  • No hay todavía referencia con todo en VRAM (E9).
  • Los turnos de agente son sintéticos y el perfil es de un desarrollador.
  • El modelo binomial supone personas independientes, así que es optimista para un equipo con el mismo horario.
  • La calidad cubre tres subconjuntos sin thinking. El dato de LiveBench es del modelo sin cuantizar al máximo esfuerzo.