El dimensionado de servidores para grandes modelos de lenguaje ha seguido una regla tosca: contar los parámetros, multiplicar por la precisión y comprar esa cantidad de memoria de GPU. El V4.1 Flash de DeepSeek rompe la regla. Sus pesos suman 763.000 millones, lo que en FP8 implica un suelo de 763GB de memoria de acelerador, y aun así el modelo puede servirse con unos 567GB porque 196.000 millones de esos parámetros están diseñados para ejecutarse desde la RAM corriente del sistema.
Claves
- Unos 196GB de los pesos de un modelo pueden salir por completo del acelerador, lo que cambia qué configuración de servidor exige el despliegue.
- Los pesos que pueden moverse son tablas de consulta que se leen de unas pocas decenas de entradas cada vez, así que nunca compiten por el ancho de banda de memoria que limita la generación de tokens.
- El ahorro solo se sostiene si el nivel que hay debajo de la GPU es rápido, lo que desplaza el esfuerzo de ingeniería del presupuesto de GPU hacia la planificación de memoria de sistema y de E/S de almacenamiento.
Por qué el techo lo marca el ancho de banda y no la capacidad
Generar un token exige leer de memoria los pesos activos del modelo. Esa lectura, repetida en cada token, explica por qué el ancho de banda de memoria y no la aritmética bruta suele poner el tope al rendimiento, y por qué la memoria del acelerador se paga a ese precio. La capacidad importa, pero la razón de que los pesos estén en la GPU es la velocidad a la que hay que transmitirlos.
Esa lógica solo aplica a los pesos que se transmiten, y algunos no lo hacen. El módulo de memoria condicional de DeepSeek guarda sus 196.000 millones de parámetros como tablas de consulta de N-gramas — asociaciones aprendidas sobre secuencias cortas de tokens — y consultarlas cuesta unas pocas decenas de lecturas por token en lugar de un barrido del bloque entero. Unos pesos a los que se accede con esa dispersión no tienen derecho a ocupar la memoria más rápida del sistema.
La consecuencia práctica es un inventario partido en dos. Unos 8.000 millones de parámetros siguen activos por token y deben ser rápidos. El grupo de consulta puede aparcarse en la RAM del sistema o en una cabina de almacenamiento lo bastante ágil como para responder sin atascarse. La lectura que hace The Register del informe técnico describe el objetivo como separar lo que un modelo sabe de lo que debe calcular.
Qué le hace esto a una negociación de compra
Unos 200GB no son un error de redondeo. Con frecuencia marcan la distancia entre una clase de nodo y la siguiente, y por tanto entre un plan de inversión y otro. Quien dimensiona solo por número de parámetros compra de más; quien dimensiona por la cifra ya descargada sin comprobar el nivel de memoria que hay debajo compra de menos y lo paga en latencia.
Ninguno de los dos errores es fácil de evitar hoy, porque las fichas de modelo publican una cifra de memoria y no dos. La información útil es esa división: cuánto debe residir en el acelerador y cuánto puede vivir un escalón más abajo. Cabe esperar que la pregunta entre antes en las evaluaciones de proveedores que en la documentación.
Hay una segunda cifra que conviene exigir. Los pesos son solo parte de lo que llena una GPU: las cachés de clave-valor crecen con la longitud de contexto y con el número de usuarios simultáneos, y en cargas de chat o de agentes con mucho tráfico suelen dominar. El mismo lanzamiento de DeepSeek atacó eso por separado, con una atención rediseñada y un nuevo codificador-decodificador causal que bajan el uso de caché a entre el 13 y el 25 por ciento del anterior modelo Flash. En términos de capacidad, eso supone entre cuatro y ocho veces más sesiones concurrentes por unidad de memoria, algo que a la mayoría de operadores le toca más de cerca que la aritmética de parámetros.
Hasta dónde se puede trasladar la técnica
El enfoque no es propietario. El equipo de Gemma en Google construyó un mecanismo emparentado, Per-Layer Embedding, para meter modelos útiles en teléfonos, donde todos los niveles de la jerarquía van justos. DeepSeek publicó su variante de N-gramas en enero, y Alibaba ha incorporado desde entonces un grupo de consulta de 51.000 millones de parámetros a un modelo Qwen experimental. El diseño se extiende porque las cuentas resultan legibles para cualquiera que haya comparado el precio de un acelerador con el de un módulo de DRAM.
Lo que sigue sin resolverse es hasta qué punto sobrevive al bajar por la jerarquía. La RAM del sistema es un destino probado. El almacenamiento es todavía una afirmación, y muy dependiente de la cabina. Los equipos que lo evalúen deberían medir su propio motor de inferencia en lugar de fiarse de una cifra de titular, porque el ahorro es real pero condicional, y la condición es una infraestructura que ya se tiene o no.
También añade una variable a la gestión del cambio. Un proveedor que altera lo que corre detrás de un endpoint altera con ello el perfil de memoria, un riesgo que quedó a la vista esta semana cuando un nombre de modelo fijado empezó a servir pesos distintos sin opción de renunciar.
FAQ
¿Se pueden descargar a la RAM del sistema los pesos de cualquier modelo?
No. Solo pueden moverse sin penalización de latencia los pesos a los que se accede con la dispersión suficiente para evitar la transmisión masiva, lo que en la práctica significa parámetros de tipo tabla de consulta y no los pesos activos que se usan en cada token. Descargar pesos densos convencionales reintroduce el cuello de botella de ancho de banda que la GPU existe para resolver.
¿Cuánta memoria de GPU necesita realmente DeepSeek V4.1 Flash?
Sus 763.000 millones de parámetros en FP8 implican un mínimo de 763GB si todo reside en el acelerador. Descargar el grupo de consulta de 196.000 millones baja ese suelo a unos 567GB. Servir en producción exige margen adicional para las cachés de clave-valor, que escalan con la longitud de contexto y los usuarios concurrentes.
¿Descargar pesos ralentiza el modelo?
Depende por entero del nivel que los recibe. Las consultas servidas desde la RAM del sistema son lo bastante rápidas como para que la arquitectura se sostenga, mientras que una cabina de almacenamiento lenta puede atascar una consulta y devolver la latencia que el diseño pretendía ahorrar. Medirlo sobre el propio hardware es la única respuesta fiable.
