Hardware
Caber no es correr: modelos gigantes en una estación de trabajo
Esta semana hemos analizado un presupuesto real: una estación de trabajo con dos Xeon de 28 núcleos, 1 TB de RAM DDR5, un disco NVMe de 1 TB y cuatro NVIDIA RTX 6000 Ada de 48 GB. Un pedido de cinco cifras, de un configurador serio, con una pregunta encima: ¿podría ejecutar en local uno de los mayores modelos abiertos publicados hasta hoy? La respuesta corta: cabe, pero no corre. La larga es una cuenta de servilleta que cualquier empresa puede hacer antes de firmar un presupuesto de hardware, y que casi nadie hace. Este artículo la hace contigo, con el presupuesto de verdad sobre la mesa.
El presupuesto y la pregunta
La máquina del presupuesto no es mala: dos procesadores de servidor, un terabyte de memoria en 16 módulos y cuatro GPUs profesionales con 48 GB cada una, 192 GB de VRAM en total. El configurador deja elegir CPU, memoria, disco y número de GPUs, como el de cualquier integrador. El problema nunca es la máquina en abstracto: es si esta máquina sirve para lo que se quiere hacer con ella.
La pregunta concreta era ejecutar Kimi K3, un modelo abierto de mezcla de expertos con 2,8 billones de parámetros, de los que activa unos 104.000 millones por token (16 de sus 896 expertos). Sus pesos nativos ocupan alrededor de 1,5 TB. Comprimido a unos 2 bits por parámetro se queda en unos 850 GB, y ahí nace la idea: 850 GB caben en 1 TB de RAM más 192 GB de VRAM. Sobre el papel, la caja lo carga. Y caber es la parte fácil.
Caber no es correr
La memoria total decide qué modelos caben. La velocidad la decide otra cosa: cuántos bytes hay que leer por cada token que el modelo escribe, y a qué velocidad los sirve la memoria donde viven esos bytes. En esta configuración los expertos viven en la RAM del sistema, porque no caben en las GPUs, así que cada token generado obliga a leer de RAM los expertos activos de ese paso.
En un modelo de mezcla de expertos la lectura no es el modelo entero, solo la parte activa. Con unos 104.000 millones de parámetros activos a unos 2 bits, son cerca de 30 GB de lectura por token. Ese número es el corazón de toda la cuenta: da igual lo que digan las GPUs, el chasis o el procesador; escribir un token cuesta leer 30 GB de la RAM.
Treinta gigabytes por token, y lo que da de sí la RAM
El presupuesto monta 16 módulos DDR5 a 4.800 MHz: 16 canales de memoria, unos 614 GB/s teóricos entre los dos procesadores. En la práctica, entre la eficiencia real y el peaje de repartir un modelo entre dos zócalos (la mitad de la RAM cuelga de cada procesador, y cruzar de uno a otro cuesta), quedan entre 300 y 400 GB/s útiles. Divide: de 300 a 400 GB/s entre 30 GB por token dan un techo de 10 a 13 tokens por segundo, y por debajo de 10 con un runtime real.
Diez tokens por segundo es, más o menos, la velocidad a la que lees. Para un usuario solo, aguantable; en cuanto haya dos generando a la vez, se sufre. Las cuatro GPUs no arreglan eso: aceleran la ingesta del prompt (leer un contrato largo iría rápido) y alojan la atención y la caché de contexto, pero la escritura de cada token sigue esperando a la RAM. En resumen: esta máquina ejecuta el modelo gigante como demostración, no como servicio para un equipo de personas.
Cuando el modelo vive en RAM, compras canales, no gigahercios
Si el objetivo real fuera esta carga, el presupuesto está optimizado en el eje equivocado. Lo que manda es el número de canales de memoria: cada canal DDR5 a 4.800 MHz aporta unos 38 GB/s, y la plataforma Xeon del presupuesto tiene 8 por procesador. La alternativa AMD EPYC ofrece 12 por procesador: 24 canales en total, un 50 por ciento más de ancho de banda, con procesadores comparables o más baratos. Para inferencia con el modelo en RAM, ese es el parámetro del configurador que hay que mirar primero, y casi ningún configurador lo enseña.
Dos cambios más saltan a la vista. El disco: 1 TB de NVMe no alberga ni una segunda copia del modelo que se quiere cargar, y sin sitio para versiones, modelos alternativos y datos, la máquina nace estrecha; 4 u 8 TB es el mínimo sensato aquí. Y las GPUs: para este uso, dos harían el mismo trabajo que cuatro, porque el cuello de botella está en la RAM; las otras dos son presupuesto que rendiría más convertido en canales de memoria o en disco.
Cuantizar por debajo de lo nativo tiene un precio
Queda la parte que casi ningún vendedor cuenta. K3 se publica en 4 bits nativos (MXFP4): el modelo ya sale de fábrica comprimido, y bajarlo a 2 bits es comprimir lo comprimido. En modelos de mezcla de expertos, las cuantizaciones agresivas de la comunidad tienen un modo de fallo documentado y silencioso: algunos expertos quedan dañados por la compresión, el enrutador aprende a evitarlos y la calidad baja sin dar un solo error. El modelo contesta, pero ya no es el modelo que sale en los benchmarks.
Para una pyme, la conclusión honesta es que perseguir el modelo más grande a la peor precisión es el camino equivocado. Un modelo abierto de tamaño medio, a su precisión nativa y ajustado a tu tarea, da mejor servicio que un gigante mutilado. Qué tamaño pide tu caso concreto, con la aritmética de memoria completa, está en la guía de qué GPU necesita tu empresa.
Comprar o alquilar: entrenar no es servir
La última lección del presupuesto no va de esta máquina, sino de cuándo comprar máquina. Entrenar un modelo desde cero o hacer un experimento grande de ajuste es un pico: días u horas de cálculo intensivo, y se acaba. Para picos, alquilar GPUs de centro de datos por horas gana casi siempre: pagas el experimento, no el hierro, y el hierro no se te queda anticuado en la estantería.
Servir inferencia es lo contrario: una carga estable, todos los días, con tus datos dentro de cada petición. Ahí el hardware propio se amortiza con el uso y añade lo que ningún alquiler ofrece: que los datos no salen de tu edificio. Por eso nuestros equipos se dimensionan para el servicio diario, con margen para el ajuste periódico de tus modelos, y no para perseguir el récord de tamaño. Si el presupuesto que tienes delante es para un entrenamiento puntual, la respuesta honesta es alquilar ese pico; si es para servir cada día, dimensiónalo para servir.