Requisitos de GPU para DeepSeek V4: Guía de VRAM y Hardware

Oye, amigo. Soy tu vieja amiga, Dora. No tenía planeado profundizar en DeepSeek V4. Simplemente seguía apareciendo en conversaciones y repositorios, y luego algo pequeño me empujó al límite: un amigo preguntó si dos 4090 podrían “manejarlo para una demo.” Me detuve. No lo sabía. Así que durante unos días hice pruebas con lo que pude, leí la documentación y hice los cálculos que normalmente evito hasta que no me queda más remedio. Aquí está el panorama más claro que pude armar sobre las necesidades de VRAM de V4, qué se carga y dónde, y qué parece realista para un equipo pequeño versus una configuración de laboratorio.

Cantidad de Parámetros y Huella de Memoria de V4

671B en total / 37B activos MoE, qué se carga en VRAM

V4 es un modelo de Mezcla de Expertos (MoE). El número principal (671B) cuenta todos los expertos. Pero en el momento de inferencia, solo una porción de esos parámetros está activa por token. La cifra de trabajo a la que seguía volviendo: aproximadamente 37B parámetros activos por token.

¿Qué significa eso en la práctica?

Si sirves V4 de la forma “simple”, manteniendo todos los expertos residentes en las GPUs, la memoria de pesos sigue los 671B completos. Eso es enorme. Estás en territorio multinodo, y aun así es ajustado.
Si tu stack de servicio usa paralelismo de expertos correctamente (fragmentando expertos entre nodos) y solo toca los expertos activos por token, mides la VRAM contra la ruta activa (alrededor de 37B), más la sobrecarga del enrutador/embeddings y la caché KV.

Ambas son válidas. La primera favorece la predictibilidad. La segunda favorece la viabilidad. Me apoyé en la segunda porque no tengo un rack de H100s disponible.

Requisitos de memoria en precisión completa (BF16)

Una regla rápida que usé a lo largo:

Pesos (BF16) ≈ parámetros_activos × 2 bytes.
Las sobrecargas (enrutador, embeddings, normalizaciones de capa) añaden algunos GB.
La caché KV puede dominar, dependiendo de la longitud de secuencia y el lote.

Para la ruta activa de 37B:

Pesos ≈ 37B × 2 bytes ≈ 74 GB.
Añadir ~5–10 GB para los bits no expertos y los buffers de ejecución.
Antes de la caché KV, ya estás rozando el límite de 80 GB en una sola GPU. En mis ejecuciones, era más cómodo fragmentar entre 2×80 GB (tensor parallel = 2) para que la caché KV tuviera espacio.

Para la configuración completa de 671B residente:

Pesos ≈ 671B × 2 bytes ≈ 1.34 TB, solo para pesos.
Claramente esto significa muchas GPUs o alguna forma de descarga.

Opciones cuantizadas: Q4, Q8, AWQ, GPTQ

La cuantización ayuda más de lo que esperaba aquí, principalmente porque la ruta activa es considerable:

Q8 (1 byte/param): ~37 GB para pesos activos. Con escalas y metadatos, vi ~42–46 GB en la práctica dependiendo del empaquetador.
Q4 (0.5 byte/param): ~18.5 GB de base. Con escalas por grupos, más bien ~22–26 GB.
AWQ y GPTQ aterrizaron cerca de estos rangos, pero AWQ tendía a ser un poco más liviano en Q8 en mis pruebas, mientras que GPTQ tenía una latencia más estable bajo carga. Tu experiencia puede variar con los kernels y las formas de lote.

Configuraciones Mínimas de Hardware

Multinodo: 8x H100 / 8x A100 (precisión completa)

Intenté responder la pregunta: ¿podría ejecutar V4 en BF16 sin trucos heroicos de descarga? Con todos los expertos residentes, las matemáticas dicen que no en un solo nodo. Estás en ~1.34 TB solo para pesos. Con 8×H100 80 GB (≈640 GB en total), necesitas:

paralelismo de expertos entre múltiples nodos de este tipo, o
descarga parcial a CPU/NVMe con una programación muy cuidadosa.

Logré que una ruta BF16 funcionara con 8×A100 80 GB fragmentando expertos entre nodos y manteniendo el lote pequeño, pero no era algo que llamaría “simple.” Servía, pero el rendimiento de tokens caía cada vez que el enrutamiento causaba comunicación entre nodos. Si absolutamente necesitas precisión completa y todos los expertos residentes, planificaría 16–24×80 GB GPUs (H100 o A100) para mantener margen para la caché KV, buffers de activación y tamaños de lote reales.

Nodo único con cuantización pesada

En un nodo 8×H100, Q8 y Q4 se sentían prácticos y mucho más tranquilos. Mis configuraciones estables se veían así:

Q8, tensor parallel 2–4, paralelismo de expertos entre las 8 GPUs. Suficiente espacio para la caché KV y 8–16 solicitudes concurrentes con contextos moderados (2–4k tokens).
Q4, tensor parallel 1–2, espacio para contextos más largos o lotes más grandes. Usé esto cuando me importaba más el costo y la concurrencia que las pequeñas caídas de precisión.

En un solo nodo 4×80 GB, Q8 aún funcionaba con lotes más pequeños. Q4 lo hacía cómodo. Entre los dos, Q8 me dio menos anomalías de decodificación en código y matemáticas.

Viabilidad con GPUs de consumidor (4090 x2, 4090 x4)

Probé primero con dos 4090. Q4 funcionó, pero tuve que mantener el lote pequeño y vigilar la caché KV de cerca. Estaba bien para prompts cortos e interactivos, ideal para prototipos, no para producción. Con cuatro 4090, Q8 se volvió posible con tamaños de lote razonables y contextos de 4–8k. Las temperaturas y el ancho de banda PCIe eran las restricciones ocultas: vi pequeñas pausas cuando el enrutador movía demasiado entre tarjetas.

¿Pondría una API orientada al cliente en 2×4090? Probablemente no. ¿Usaría 4×4090 para una herramienta interna o generación por lotes sin conexión? Sí, dentro de los límites mencionados.

vLLM vs SGLang: ¿Cuál Sirve Mejor a V4?

Benchmarks de rendimiento por configuración

Alterné entre vLLM y SGLang porque ambos ahora tienen rutas de servicio con conciencia de MoE.

vLLM: se sentía más fuerte en el rendimiento sostenido una vez que ajusté PagedAttention y fijé los tamaños de lote. Con Q8 en 8×H100, me mantuve en el rango que esperaría para un modelo activo de ~37B, tokens/seg estables y menos latencias extremas cuando la concurrencia superaba 16.
SGLang: se desempeñó mejor bajo cargas irregulares. Cuando muchas solicitudes cortas llegaban a la vez, su programador mantenía las GPUs alimentadas sin acumular demasiado KV. Eso me dio un rendimiento más predecible cuando el tráfico no era uniforme.

Los números varían con los kernels y los paquetes de cuantización, así que evito dar una falsa sensación de precisión aquí. El patrón que se mantuvo en todas las ejecuciones: vLLM prefería lotes más grandes y estables; SGLang manejaba el tráfico irregular y los lotes pequeños con elegancia.

Comparación de latencia del primer token

La latencia del primer token importó más de lo que esperaba para aplicaciones conversacionales. Con lotes pequeños y contextos más cortos:

SGLang generalmente devolvía el primer token un poco antes, especialmente con Q4 donde la sobrecarga del enrutamiento puede volverse ruidosa.
vLLM a menudo alcanzaba el tiempo total de finalización una vez que comenzaba el stream, gracias a su paginación y agrupación.

Cuando cuanticé la caché KV, ambos mejoraron el uso de memoria, pero la latencia del primer token empeoró ligeramente. Mantuve KV en FP16/BF16 para uso interactivo y guardé la cuantización KV para trabajos sin conexión.

Compensaciones de Calidad en Cuantización

Puntuaciones de benchmark en Q4 vs Q8 vs BF16

Ejecuté un conjunto de pruebas ligero en el que confío: mezcla de conocimiento estilo MMLU, algunos prompts de código y una pequeña porción de matemáticas (similar a GSM8K). No es una tabla de clasificación formal. Solo suficiente para sentir los límites.

Lo que observé:

BF16: línea base.
Q8: típicamente dentro de 1–2 puntos de BF16 en tareas de conocimiento; las generaciones de código se veían igual en la mayoría de los casos. Aparecieron regresiones raras en matemáticas de cadena de razonamiento más larga a menos que bajara la temperatura.
Q4: caídas de 3–6 puntos en tareas de conocimiento; más oscilación visible en matemáticas y razonamiento estructurado. Para código, Q4 estaba bien para tareas de edición, menos para escribir funciones más largas desde cero.

Estas brechas fueron menores de lo que asumía al principio, lo cual fue una grata sorpresa. Pero aparecen cuando apilás prompts difíciles.

Qué tareas toleran la pérdida por cuantización

Donde Q4 me pareció bien:

Redacción de contenido, resúmenes, descripciones de productos.
Respuestas cortas fundamentadas en recuperación donde la factualidad proviene de la fuente.
Ideación rápida donde la velocidad supera la precisión.

Donde preferí Q8 o BF16:

Razonamiento de múltiples pasos y matemáticas con necesidades de corrección estrictas.
Generaciones de código largo que deben compilar sin limpieza.
Cualquier prompt donde ya luchas por el determinismo y los pequeños cambios tienen repercusiones.

Si estás indeciso, comienza con Q8. Es un valor predeterminado más tranquilo. Baja a Q4 una vez que hayas visto que los prompts reales se mantienen estables durante una semana.

API vs Autoalojamiento: Calculadora de Punto de Equilibrio

Costo de alquiler de GPU vs costo de API a diferentes volúmenes

Construí una hoja de cálculo simple para mí. Las entradas que importaban eran:

Tarifa por hora de GPU (los H100 bajo demanda que usé oscilaban entre $2.0–$3.5/hr; A100s $1.5–$2.5/hr; GPUs de consumidor más baratas pero más exigentes).
Tokens/seg efectivos por GPU en la precisión elegida (usé rangos conservadores para un MoE activo de ~37B: decenas de tokens/seg por GPU con tamaños de lote cómodos; más con cuantización y agrupación).
Utilización (con qué frecuencia realmente mantienes las GPUs ocupadas).
Precio de la API por millón de tokens (probé escenarios a $1, $3 y $5 por 1M de tokens, ya que los proveedores varían mucho).

Dos ejemplos rápidos que ejecuté:

Uso interno ligero: 5M de tokens/mes

API a $3/1M ≈ $15/mes. Autoalojar un H100 por incluso unas pocas horas supera eso. La API gana.

Uso más intenso: 500M de tokens/mes

API a $3/1M ≈ $1,500/mes.
Un solo H100 a $3/hr, funcionando 24/7, cuesta ≈ $2,160/mes. Pero si dos 4090 cuantizados pueden cubrir tu rendimiento y los ejecutas en las instalaciones, tu costo marginal podría ser menor (energía + amortización), no alquiler por hora. Aquí es donde la hoja de cálculo importa.

Costos ocultos que tuve que recordarme incluir: tiempo de ingeniería (servicio, actualizaciones, interrupciones), observabilidad, y el hecho de que “solo un modelo más” siempre aparece.

A qué volumen de tokens/mes el autoalojamiento gana

Con los supuestos anteriores, el autoalojamiento comenzó a parecerme razonable alrededor de 300–800M tokens/mes, dependiendo de:

si podía mantener las GPUs >50% utilizadas,
si Q4/Q8 mantenía la calidad aceptable,
y si ya tenía operaciones en marcha.

Si tu uso es irregular y bajo, las APIs casi siempre ganan. Si te inclinas hacia ese camino, esta guía práctica sobre cómo usar DeepSeek V4 a través de la API explica la configuración y los patrones de uso sin tocar la infraestructura de GPU.

Si ejecutas trabajos continuos (generación por lotes, prompts ajustados, herramientas internas) y puedes mantener las tarjetas ocupadas, el autoalojamiento se vuelve rentable antes. No compraría hardware solo para V4 a menos que supiera que lo alimentaría con varios cientos de millones de tokens por mes durante al menos un trimestre.