¿Qué VPS para ejecutar una IA? API o modelo en el servidor

Dos necesidades, dos tamaños de servidor

La mayoría de las aplicaciones que «usan IA» (asistentes, agentes, resúmenes, extracción de datos, búsqueda en documentos) llaman a un modelo alojado por su proveedor, mediante una API. El cálculo se hace en su infraestructura; su servidor prepara la petición, espera la respuesta y la procesa. Se dimensiona entonces como cualquier aplicación web: por su lenguaje, su base de datos y el número de usuarios simultáneos.

El otro caso es el modelo ejecutado en el propio servidor, con Ollama, llama.cpp o una biblioteca de Python. Los motivos son conocidos: datos que permanecen en su infraestructura, un coste fijo sea cual sea el número de peticiones, un procesamiento en segundo plano sobre grandes volúmenes, un modelo especializado. Ahí, el modelo entero debe caber en memoria, y es él quien fija el tamaño.

Por API: dimensionar la aplicación, no el modelo

Una petición a un modelo por API dura de uno a varias decenas de segundos, sobre todo cuando la respuesta se transmite a medida que se genera (streaming). Mientras tanto, su servidor casi no calcula nada: espera. Lo que cuenta es su capacidad para mantener muchas peticiones en espera sin bloquear las demás:

• Un servidor asíncrono: Node.js, FastAPI con Uvicorn, o workers asíncronos de Gunicorn. Un worker síncrono que espera una respuesta de 20 segundos es un worker bloqueado para todos los demás visitantes.
• Una cola de tareas para los procesos largos (resumen de un documento, análisis de un lote): la petición del visitante responde enseguida y un worker procesa en segundo plano.
• Tiempos de espera ajustados en el proxy: por defecto, Nginx corta una respuesta que permanece en silencio más de 60 segundos (proxy_read_timeout).

La memoria que prever es la de la aplicación y su base de datos: 4 GB cubren una aplicación Python o Node.js con PostgreSQL en el lanzamiento. Una configuración habitual, una interfaz Next.js, una API FastAPI y una base PostgreSQL que llaman a un modelo por API, cabe en 6 a 8 GB, compilación de la interfaz incluida.

Embeddings y búsqueda vectorial: la memoria de los vectores

Una aplicación que busca en sus documentos (RAG, retrieval-augmented generation) transforma cada fragmento en un vector y, después, encuentra los más cercanos a una pregunta. Dos partidas que dimensionar:

• El modelo de embeddings, si se ejecuta en su servidor: los modelos habituales pesan de 100 MB a 1,5 GB y calculan en procesador sin dificultad. all-MiniLM-L6-v2, por ejemplo, ocupa menos de 100 MB.
• Los vectores: con pgvector, un vector ocupa 4 bytes por dimensión, más 8. Un millón de fragmentos de 1536 dimensiones representan unos 6 GB de datos, a los que se suma el índice HNSW que acelera la búsqueda. Para búsquedas rápidas, el índice y los vectores consultados deben caber en memoria.

El tipo halfvec de pgvector almacena cada dimensión en 2 bytes en lugar de 4: la mitad de memoria, con una calidad de búsqueda muy próxima.

Un modelo en el servidor: primero, la memoria

Un modelo de lenguaje es un archivo de pesos, que se carga entero en memoria para responder. Su tamaño depende del número de parámetros y de la cuantización, la precisión con la que se almacena cada peso. El formato GGUF, el de llama.cpp y Ollama, ofrece cuantizaciones de 2 a 16 bits; la variante Q4_K_M, en torno a 4 bits, es el equilibrio habitual entre tamaño y calidad.

A este peso se suman dos partidas:

• El contexto (la caché KV): cada token de la conversación en curso ocupa memoria. Para Llama 3.1 8B, cuente unos 128 KB por token con precisión de 16 bits, es decir, 1 GB para un contexto de 8000 tokens, y otro tanto por cada conversación procesada en paralelo.
• El resto del servidor: sistema, aplicación, base de datos, como en cualquier aplicación web.

Ejemplo. Llama 3.1 8B en 4 bits, dos conversaciones simultáneas de 8000 tokens y una aplicación pequeña: 5 GB de modelo, 2 GB de contexto, 2 GB para la aplicación y el sistema, es decir, 9 GB, y unos 12 GB con un 25 % de margen.

En procesador: lo que fija la velocidad

Para producir cada token, el modelo vuelve a leer todos sus pesos en memoria. En procesador, la velocidad de generación está limitada, por tanto, por el ancho de banda de la memoria más que por el número de núcleos: un modelo de 5 GB, en una máquina que lee 25 GB por segundo, se queda en torno a 5 tokens por segundo, antes incluso de contar el cálculo.

Se distinguen dos fases:

• La lectura de la pregunta (prompt processing) es un cálculo intensivo: más vCPU la hacen más rápida, lo que cuenta para los documentos largos.
• La generación de la respuesta depende sobre todo del ancho de banda de la memoria y del tamaño del modelo: un modelo dos veces más pequeño responde unas dos veces más rápido.

En la práctica, con unos pocos vCPU, un modelo de 7 a 8 mil millones de parámetros cuantizado en 4 bits produce unos pocos tokens por segundo. Es cómodo para un procesamiento en segundo plano (clasificar mensajes, extraer campos de un documento, resumir por la noche lo que ha llegado durante el día) y para un asistente interno. Los usos interactivos a gran escala, y los modelos de varias decenas de miles de millones de parámetros, se ejecutan en tarjeta gráfica (GPU).

La medición decide: llama-bench, incluido en llama.cpp, da la velocidad de las dos fases en su servidor, para su modelo.

llama-bench -m modelo-Q4_K_M.gguf -p 512 -n 128

El disco: los modelos, sus versiones, los vectores

Un modelo ocupa en disco más o menos lo mismo que en memoria: 5 GB para un modelo de 8 mil millones de parámetros en 4 bits. Prevea espacio para dos o tres modelos o versiones, los índices vectoriales, los documentos de origen y la base de datos. Un SSD NVMe carga un modelo en pocos segundos al arrancar el servicio, lo que cuenta en cada reinicio.

Orden de magnitud: 50 GB para una aplicación que llama a un modelo por API, de 80 a 120 GB en cuanto un modelo y sus documentos viven en el servidor.

La puesta en marcha, con seguridad

Con Ollama, la puesta en marcha cabe en dos comandos:

curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3.1:8b

Ollama escucha por defecto en 127.0.0.1:11434, es decir, solo desde el propio servidor. Conserve este ajuste: su API no pide ninguna autenticación, y una instancia abierta a Internet sirve a cualquiera, con sus recursos. Su aplicación, en el mismo servidor, se comunica con él en local; si otro servidor debe consultarlo, pase por un proxy que autentique las peticiones o por una red privada.

Ajuste después el tamaño del contexto (num_ctx) a lo que necesitan sus peticiones: es lo que hace crecer la memoria ocupada, conversación tras conversación.