Planificacion de Capacidad de AI Empresarial: Como Dimensionar Tu Infraestructura On-Premise

El error mas costoso en AI on-premise es comprar el hardware equivocado. Sobre-dimensionar significa cientos de miles de dolares en computo ocioso. Sub-dimensionar significa cuellos de botella de rendimiento que socavan el caso de negocio para on-premise en primer lugar. Y a diferencia de la nube, no puedes redimensionar un cluster GPU con un cambio de configuracion — estas ordenando hardware con tiempos de entrega de 8-16 semanas.

Esta guia recorre un proceso estructurado de planificacion de capacidad: inventariar tus cargas de trabajo, calcular requisitos de computo, considerar almacenamiento y redes, y planificar para el crecimiento. El objetivo es una recomendacion de hardware especifica y defendible — no un vago "compra unas GPUs."

Paso 1: Inventariar Tus Cargas de Trabajo de AI

Antes de seleccionar cualquier hardware, construye un inventario completo de cada carga de trabajo de AI que correra en tu infraestructura on-premise. Esto incluye cargas de trabajo corriendo hoy (incluso si estan en la nube) y cargas de trabajo planificadas dentro de los proximos 18 meses.

Para cada carga de trabajo, documenta:

Construye este inventario como una hoja de calculo. Se convierte en la base para cada decision de dimensionamiento que sigue.

Brecha comun: Las organizaciones inventarian su carga de trabajo principal pero olvidan las cargas de trabajo de soporte. Un chatbot basado en RAG no solo necesita computo de inferencia — tambien necesita:

• Generacion de embeddings para ingesta de documentos (corre en GPU)
• Modelo de reranking para recuperacion (corre en GPU)
• Base de datos vectorial (corre en CPU, necesita almacenamiento rapido)
• Pipeline de procesamiento de documentos (CPU/GPU mixto)

Cada uno de estos consume recursos que deben planificarse.

Paso 2: Calcular Requisitos de Computo

Dimensionamiento de VRAM

La VRAM (memoria GPU) es usualmente la restriccion vinculante. Un modelo debe caber en VRAM para ejecutarse — no hay degradacion gradual, solo fallo al cargar.

Requisitos de VRAM del modelo por tamano y cuantizacion:

Estos numeros representan solo los pesos del modelo. En tiempo de inferencia, tambien necesitas VRAM para:

• Cache KV: Escala con la longitud de contexto y el tamano del lote. Para un modelo de 14B con contexto de 8K sirviendo 8 solicitudes concurrentes, agrega ~4-8GB.
• Memoria de activacion: Tipicamente 1-3GB dependiendo del tamano del lote.
• Overhead del framework: PyTorch, vLLM o TensorRT-LLM cada uno agrega 1-2GB de memoria base.

Regla general: Reserva 30-40% de margen de VRAM por encima del tamano de los pesos del modelo. Un modelo de 14B INT4 que necesita 8GB de almacenamiento de pesos deberia planificarse para 11-12GB de uso total de VRAM.

Dimensionamiento de Throughput

Calcula cuantas instancias GPU necesitas para servir tus consultas objetivo por segundo (QPS):

1. Mide el throughput de una sola instancia. Para un modelo de 14B INT4 en una L40S, espera aproximadamente 70-110 tokens/segundo por GPU. Con una salida promedio de 400 tokens, eso es aproximadamente 0.17-0.28 solicitudes/segundo por GPU.

2. Calcula las instancias necesarias. Si tu QPS pico es 15, y cada GPU maneja 0.2 solicitudes/segundo: 15 / 0.2 = 75 GPUs? No — esa matematica es para generacion secuencial. Con inferencia por lotes (vLLM, TensorRT-LLM), una sola GPU puede servir 4-8 solicitudes concurrentes con degradacion minima de throughput por solicitud. Capacidad realista: 1-2 solicitudes/segundo por GPU para un modelo de 14B con batching.

3. Agrega margen. Apunta a 60-80% de utilizacion de GPU en pico, no 100%. Al 100% de utilizacion, cualquier pico de trafico causa degradacion de latencia. Para el ejemplo anterior: 15 QPS / 1.5 QPS por GPU / 0.7 objetivo de utilizacion = ~14 GPUs.

Objetivos de Utilizacion de GPU

No planifiques para 100% de utilizacion de GPU. Esta es la razon:

La utilizacion tambien depende de los patrones de carga. Un chatbot orientado al cliente con horas pico (9am-5pm) promediara 30-40% de utilizacion incluso si el pico alcanza 70-80%. Un pipeline interno de procesamiento de documentos corriendo 24/7 puede mantener 70-80% consistentemente.

Paso 3: Considerar Requisitos de Almacenamiento

El computo GPU se lleva toda la atencion, pero la planificacion de almacenamiento es donde la planificacion de capacidad mas frecuentemente falla.

Categorias de Almacenamiento

Pesos del Modelo

Cada version del modelo necesita almacenamiento. Un modelo de 14B FP16 es ~28GB. Si mantienes 5 versiones (actual + 4 versiones de rollback), eso son 140GB por modelo. Multiplica por el numero de modelos que sirves.

Datasets de Entrenamiento

Si estas haciendo fine-tuning on-premise, tus datos de entrenamiento necesitan almacenamiento rapido. Los tamanos varian enormemente:

• Datasets de fine-tuning de texto: 1GB-50GB tipico
• Corpus de documentos para RAG: 10GB-1TB+
• Datasets de imagen/multimodal: 100GB-10TB+

Checkpoints del Modelo

Durante el fine-tuning, los checkpoints se guardan a intervalos regulares. Un checkpoint completo para un modelo de 14B es ~28GB. Si guardas checkpoints cada 500 pasos para una ejecucion de entrenamiento de 5,000 pasos, eso son 10 checkpoints x 28GB = 280GB por ejecucion de entrenamiento. Los checkpoints se acumulan rapidamente si no se limpian.

Base de Datos Vectorial

Las cargas RAG necesitan almacenamiento vectorial. Un estimado aproximado: 1 millon de fragmentos de documentos con embeddings de 1,536 dimensiones requiere aproximadamente 6GB de almacenamiento vectorial, mas metadatos e indices que pueden duplicar o triplicar el tamano crudo.

Logs de Auditoria y Telemetria

Cada solicitud y respuesta de inferencia deberia registrarse para cumplimiento y monitoreo. Un par de solicitud/respuesta promedia 2-5KB. A 50,000 solicitudes/dia, eso es 100-250MB/dia, o 36-91GB/ano. No es enorme, pero se acumula y debe estar en almacenamiento rapido y confiable si necesitas capacidad de auditoria en tiempo real.

Hoja de Calculo de Dimensionamiento de Almacenamiento

Usa SSDs NVMe para pesos del modelo y datos de entrenamiento activos — los discos giratorios no pueden seguir el ritmo de carga de datos de GPU. Una configuracion tipica empareja 2-4TB de almacenamiento NVMe por servidor GPU con un NAS o SAN mas grande para almacenamiento de archivo (checkpoints viejos, logs de auditoria historicos).

Paso 4: Requisitos de Red

La planificacion de red depende de si estas ejecutando entrenamiento multi-nodo o cargas de solo inferencia.

Entrenamiento Multi-Nodo

Si estas entrenando o ajustando modelos a traves de multiples servidores (entrenamiento distribuido), necesitas interconexion de alta velocidad entre nodos. La comunicacion GPU durante el entrenamiento es continua y sensible a la latencia.

• InfiniBand HDR (200 Gb/s) o NDR (400 Gb/s): El estandar para entrenamiento GPU multi-nodo. Cada servidor necesita un HCA de InfiniBand, y necesitas un switch InfiniBand. Costo: $5,000-$15,000 por servidor + $10,000-$30,000 por el switch.
• RoCE (RDMA over Converged Ethernet): Una alternativa mas barata usando NICs Ethernet estandar con capacidades RDMA. El rendimiento es 80-90% del InfiniBand para la mayoria de las cargas. Costo: $2,000-$5,000 por servidor con switches de red existentes.

Solo Inferencia

Si solo estas ejecutando inferencia (sin entrenamiento distribuido), las redes estandar son suficientes:

• 25 GbE: Adecuado para la mayoria de las cargas de inferencia. Maneja la carga de modelos y el trafico de solicitud/respuesta de clientes sin cuellos de botella.
• 100 GbE: Util si transfieres datasets grandes frecuentemente o sirves QPS muy alto con ventanas de contexto grandes.

1 GbE estandar es demasiado lento para carga de modelos (cargar un modelo de 28GB sobre 1 GbE toma ~4 minutos — inaceptable para escenarios de failover).

Ancho de Banda a Clientes

Calcula el ancho de banda que tu servicio de inferencia necesita para servir clientes:

• Respuesta promedio: 400 tokens x ~4 bytes/token = 1.6KB por respuesta
• A 15 QPS: 24KB/segundo — insignificante
• Pero las respuestas en streaming token por token agregan overhead de conexion: planifica para 100-500 conexiones WebSocket concurrentes si sirves interfaces de chat en tiempo real

El ancho de banda de clientes rara vez es un cuello de botella, pero el conteo de conexiones puede serlo. Asegurate de que tu servidor de inferencia (o balanceador de carga frente a el) este configurado para suficientes conexiones concurrentes.

Paso 5: Energia y Enfriamiento

Este es el paso que mata los proyectos on-premise que se veian geniales en papel.

Requisitos de Energia

Antes de comprar hardware, verifica con tu equipo de instalaciones:

1. Capacidad de energia disponible en tu sala de servidores/data center. Muchas salas de servidores empresariales fueron dimensionadas para servidores basados en CPU a 2-5kW por rack, no servidores GPU a 8-15kW por rack.
2. Disponibilidad de circuitos. Un solo servidor 8xH100 puede necesitar su propio circuito dedicado.
3. Capacidad del UPS. Tu fuente de alimentacion ininterrumpida debe manejar la carga GPU mas tiempo de ejecucion para apagado seguro.

Requisitos de Enfriamiento

Las GPUs generan calor proporcional a su consumo de energia. Cada watt de energia GPU requiere aproximadamente 0.3-0.5 watts de energia de enfriamiento (depende del PUE — eficiencia del uso de energia).

Si la capacidad de enfriamiento de tu sala de servidores esta al maximo, agregar servidores GPU puede requerir mejoras de HVAC que cuestan $20,000-$100,000+. Verifica la capacidad de enfriamiento antes de comprometerte con compras de hardware.

La Hoja de Calculo de Dimensionamiento

Unelo todo en una sola tabla de dimensionamiento:

En este ejemplo, 26 GPUs L40S a traves de 3-4 servidores manejarian las cargas de inferencia, con la carga de fine-tuning compartiendo el mismo hardware durante horas no pico o ejecutandose en un servidor dedicado de 4 GPUs.

Costo total estimado: 4x servidores de 8 GPUs L40S x $79,000 = $316,000, mas almacenamiento, redes e infraestructura de soporte: aproximadamente $380,000-$420,000 en total.

Errores Comunes de Planificacion de Capacidad

Error 1: Comprar H100s Cuando L40S Seria Suficiente

Las H100s son la mejor GPU disponible, pero cuestan 4x el precio del hardware L40S. Si tus cargas son de inferencia intensiva con modelos de menos de 30B parametros, la L40S proporciona 80-90% del rendimiento practico al 25% del costo. Las ventajas de la H100 — ancho de banda HBM3, NVLink, MIG — importan mas para entrenamiento de modelos grandes e inferencia multi-inquilino. Si no estas haciendo eso, estas pagando por capacidades que no usaras.

Error 2: Sub-dimensionar el Almacenamiento

Los checkpoints del modelo son la sorpresa de almacenamiento mas comun. Una sola ejecucion de fine-tuning puede generar 200-500GB de checkpoints. Las organizaciones que presupuestan 2TB de NVMe para "suficiente almacenamiento" se encuentran llenas dentro de semanas de comenzar experimentos de fine-tuning. Presupuesta 2-3x mas almacenamiento de lo que tu calculo inicial sugiere.

Error 3: Ignorar las Restricciones de Energia y Enfriamiento

El hardware llega, se instala en el rack, y luego dispara el breaker del circuito. O la temperatura de la sala de servidores sube a 35 grados Celsius en horas. Siempre verifica la capacidad de energia y enfriamiento con tu equipo de instalaciones antes de comprar hardware, no despues.

Error 4: No Planificar para Servicio Multi-Modelo

La mayoria de las organizaciones comienzan con un modelo pero rapidamente se expanden a 3-5 modelos sirviendo diferentes casos de uso. Si dimensionas tu infraestructura para un solo modelo, estaras sin capacidad dentro de 6 meses. Planifica para al menos 2-3x tu conteo inicial de modelos.

Error 5: Dimensionar para el Promedio en Lugar del Pico

Una carga de trabajo que promedia 5 QPS pero tiene picos de 20 QPS durante horas laborales necesita dimensionarse para 20 QPS (con margen). Dimensionar para el promedio significa rendimiento degradado durante las horas cuando el uso importa mas.

Error 6: Olvidar la Redundancia

Si tienes exactamente las GPUs suficientes para servir tu carga de trabajo, perder una sola GPU significa servicio degradado. Para cargas con requisitos de disponibilidad del 99.9%+, planifica redundancia N+1 — como minimo, una GPU de repuesto por servidor, o un servidor en standby que pueda absorber la carga durante mantenimiento o fallas.

Horizonte de Planificacion: 18-24 Meses

Los clusters GPU no son trivialmente expandibles. Agregar GPUs a un servidor existente puede no ser posible (depende del chasis), y agregar un nuevo servidor requiere adquisicion, instalacion en rack, cableado y configuracion que toma 2-4 meses desde la decision hasta produccion.

Dimensiona tu despliegue inicial para 18-24 meses de crecimiento proyectado. Es mejor tener 20% de exceso de capacidad en el primer ano que enfrentar una crisis de capacidad en el mes ocho mientras esperas la adquisicion de hardware.

Sin embargo, no intentes predecir necesidades mas alla de 24 meses. El panorama de hardware de AI cambia rapidamente — la GPU que comprarías en dos anos puede no existir todavia, y los patrones de carga cambiaran a medida que el uso de AI de tu organizacion madure.

Planifica para lo que puedes ver. Construye margen para lo que no puedes.