El servidor de una aplicación de IA debe dimensionarse para el modelo, el número de solicitudes, la longitud del contexto y el tipo de respuesta. No basta con preguntar cuánta RAM necesita una aplicación: una API externa, un modelo local y un flujo con documentos tienen necesidades diferentes.
La arquitectura debe separar aplicación, datos, modelo y observabilidad para poder cambiar una pieza sin perder el control del conjunto.
Definir la carga
Estima usuarios concurrentes, solicitudes por minuto, tokens de entrada y salida, tiempo de respuesta y disponibilidad deseada. Una aplicación de chat y un proceso nocturno de clasificación pueden usar el mismo modelo, pero no deben dimensionarse con el mismo objetivo.
CPU, GPU y memoria
Una API externa desplaza el cálculo del modelo y deja en tu servidor la aplicación, colas, autenticación, caché y datos. Un modelo local necesita RAM o VRAM para pesos, contexto y concurrencia. La CPU también importa para tokenización, red, almacenamiento y tareas auxiliares.
Almacenamiento y datos
Calcula el tamaño de modelos, índices, documentos, logs y copias. Si la aplicación usa embeddings o búsqueda vectorial, la base de datos y sus índices deben crecer con el contenido. Separa datos persistentes de contenedores o procesos que puedan recrearse.
Red y latencia
Una llamada a una API añade DNS, conexión, TLS, cola y transmisión. Un modelo local reduce trayecto, pero puede tener menos capacidad de cálculo. Mide tiempo hasta el primer token y tiempo total, y define qué ocurre cuando el modelo o una dependencia no responde.
Seguridad y operación
Protege claves, documentos, endpoints y registros. Limita permisos del proceso y evita guardar prompts sensibles sin una razón. Actualiza runtime y dependencias, monitoriza CPU, RAM, VRAM, disco, latencia y errores, y prueba restauraciones.
Una arquitectura que pueda crecer
Una cola puede suavizar picos, pero añade espera. Un caché reduce consultas repetidas, pero no debe mezclar respuestas privadas. Varias réplicas requieren repartir solicitudes y gestionar estado. Si el proyecto necesita recursos propios, compara servidores dedicados con una opción virtual según carga y capacidad de administración.
Qué comprobar antes de elegir
Prueba el modelo, contexto, concurrencia y ruta de error con datos representativos. El servidor adecuado es el que mantiene una experiencia y una operación razonables, no el que presenta la cifra más alta de CPU o memoria.
Separar servicios
La aplicación web, la cola, la base de datos, el almacén de documentos y el runtime del modelo pueden compartir máquina al principio, pero tienen perfiles distintos. Separarlos facilita limitar recursos y localizar fallos. Un proceso que consume VRAM no debería impedir que la API responda con un error controlado.
Concurrencia y colas
Si llegan más solicitudes de las que el modelo puede atender, una cola evita saturar memoria, aunque aumenta la espera. Define máximo de cola, timeout y prioridad. Para cargas interactivas, una petición antigua no debería bloquear indefinidamente a todas las demás.
Datos persistentes
Modelos, documentos, índices y logs deben tener rutas de copia y retención distintas. Un contenedor recreable no debe ser el único lugar donde vive una base de datos. Prueba restaurar la aplicación y sus datos en un entorno separado.
Seguridad y secretos
Protege claves de API, documentos y endpoints. No guardes prompts sensibles en logs por defecto y limita qué procesos pueden leer los pesos o el almacén vectorial. Una instalación local requiere las mismas decisiones de acceso y monitorización que cualquier otro servidor.
Medir antes de escalar
Observa CPU, RAM, VRAM, I/O, red, tiempo hasta el primer token, tokens por segundo, errores y coste. Añadir una GPU o más nodos sin conocer el cuello de botella puede aumentar complejidad sin mejorar la respuesta. Empieza con una carga representativa y documenta el límite que obliga a cambiar de arquitectura.
Observabilidad y mantenimiento
Registra latencia por etapa, cola, uso de memoria, errores de modelo, coste y tamaño de entrada y salida. Separa logs técnicos de contenido sensible y define una retención. Sin métricas por etapa, una aplicación lenta puede atribuirse erróneamente al modelo.
Escalar sin perder control
Más réplicas requieren repartir tráfico, compartir o evitar estado y coordinar modelos y versiones. Una base de datos o almacén vectorial puede seguir siendo el cuello de botella. Añadir nodos no elimina la necesidad de límites y copias.
Prueba una ruta de degradación y una restauración antes de depender de la infraestructura.
API externa o modelo local
Una API reduce la carga de hardware del servidor, pero añade dependencia de red, proveedor y política de datos. El modelo local ofrece control operativo, pero exige memoria, actualizaciones, seguridad y capacidad propia.
Planificación gradual
Empieza con una carga medida, define límites y escala solo cuando una métrica lo justifique. Conserva una ruta de error y prueba copias de datos, configuración y modelos.
La capacidad debe dejar margen para actualizaciones y restauración, no solo para el tráfico medio. Un servidor sin margen puede funcionar en pruebas y fallar durante una incidencia.
La arquitectura se revisa con datos.
Capacidad para mantenimiento y recuperación
El servidor debe dejar margen para actualizaciones, copias y restauración, no solo para el tráfico medio. Un sistema que funciona en una demostración puede fallar cuando coinciden solicitudes, logs y tareas de mantenimiento.
Registra latencia por etapa, cola, memoria, errores, coste y tamaño de entrada y salida. Con esas métricas puedes decidir si ampliar CPU, memoria, GPU, red o almacenamiento, en vez de aumentar recursos sin conocer el cuello de botella.