Requisitos de un stack de IA self-hosted: qué componentes incluye
Para un stack de IA self-hosted con LLM, RAG y base de datos vectorial para un equipo de 10–20 personas necesitas un servidor con 16 vCPU, 64 GB RAM, 1 TB NVMe y una GPU con al menos 24 GB VRAM.
Un stack de IA local completo no se limita a un modelo en Ollama o vLLM. Una arquitectura habitual incluye una LLM para generación, un modelo de embeddings para indexar documentos, una base de datos vectorial, una interfaz como Open WebUI, una capa de API, una cola de tareas y, en algunos casos, un reranker. La carga no se distribuye de forma uniforme: la GPU determina la velocidad de respuesta de la LLM, la RAM influye en el caché y el tamaño del índice, y un disco NVMe rápido es crítico para la base de datos vectorial y la carga masiva de archivos.
El flujo básico es el siguiente: el usuario envía una pregunta en Open WebUI, el orquestador busca fragmentos relevantes en Qdrant, Milvus o pgvector, pasa el contexto a la LLM y devuelve la respuesta. Si al mismo tiempo se reindexan PDF, DOCX y la base de conocimiento, el servidor recibe carga adicional de CPU, RAM, disco y modelo de embeddings.
Qué servicios consumen recursos
- Inferencia de LLM: el principal consumidor de VRAM, cómputo GPU y RAM cuando se usa CPU-offload.
- Modelo de embeddings: puede ejecutarse en CPU, pero una GPU acelera notablemente el procesamiento de decenas de miles de documentos.
- Base de datos vectorial: utiliza activamente RAM para los índices, NVMe para almacenar segmentos y CPU para las búsquedas.
- Open WebUI, Flowise, Dify, Langfuse: normalmente requieren pocos recursos, pero generan conexiones, logs e historial de conversaciones.
- PostgreSQL, Redis, object storage: son necesarios para metadatos, colas, archivos y copias de seguridad.
Para elegir el modelo y la VRAM conviene consultar los requisitos de servidor para IA self-hosted y LLM: el tamaño del modelo, el contexto y el formato de cuantización afectan más a la configuración que la propia interfaz web.
Por qué no debes calcular el servidor solo según el modelo
Un modelo Qwen, Llama o Mistral en formato Q4 puede ocupar 5–6 GB VRAM con 7–8B parámetros, pero ese no es el consumo total. Necesitas margen para el contexto, KV-cache, búferes CUDA, solicitudes paralelas y el modelo de embeddings. Una GPU con 8 GB VRAM puede ejecutar un modelo 8B, pero con un contexto de 16–32K tokens y varios usuarios la latencia será inestable.
Como regla práctica, reserva 20–30% de VRAM adicional sobre el tamaño del modelo cargado, 25% de RAM por encima del consumo calculado de los contenedores y al menos 30% de espacio libre en NVMe para compactación de índices, archivos temporales y actualizaciones de imágenes.
Requisitos de servidor para un stack de IA según la carga
Los requisitos de servidor para un stack de IA dependen del número de conversaciones simultáneas, el tamaño del modelo, el volumen de la base de conocimiento y la frecuencia de indexación, no solo del número de cuentas registradas.
Bloque de datos: escala → configuración
Los precios orientativos indicados abajo corresponden al mercado de VPS y servidores GPU en febrero de 2025; para una carga corporativa permanente, conviene confirmar la configuración con Valebyte antes de realizar el pedido.
Para 10–20 usuarios simultáneos de un sistema RAG, basta con 16 vCPU, 64 GB RAM, 1 TB NVMe y una GPU con 24 GB VRAM.
| Escala de carga | vCPU | RAM | Disco | Puerto de red | Precio, $/mes |
|---|---|---|---|---|---|
| 1–2 usuarios, LLM 7–8B, hasta 20 GB de documentos | 8 vCPU | 32 GB | 500 GB NVMe | 1 Gbps | aproximadamente desde $45 |
| 10–20 usuarios, LLM 8–14B, hasta 200 GB de documentos | 16 vCPU | 64 GB | 1 TB NVMe | 1 Gbps | aproximadamente desde $300 con GPU 24 GB VRAM |
| 20–50 usuarios, LLM 32B Q4, hasta 1 TB de documentos | 24 vCPU | 128 GB | 2 TB NVMe | 1–10 Gbps | aproximadamente desde $700 con GPU 48 GB VRAM |
| Departamento de 50–100 usuarios, varios modelos y RAG | 32 vCPU | 256 GB | 4 TB NVMe RAID 1 | 10 Gbps | aproximadamente desde $1,400 con 2×48 GB VRAM |
Cómo interpretar el cálculo
La primera fila sirve para un asistente personal, búsqueda interna en documentación y pruebas con Qwen2.5 7B, Llama 3.1 8B o Mistral 7B en Q4. En CPU el modelo responderá, pero la velocidad suele limitarse a unos pocos tokens por segundo; para un chat interactivo es mejor una GPU desde 12 GB VRAM.
La configuración para 10–20 personas no presupone 20 generaciones constantes, sino 2–5 solicitudes simultáneas. Si todos los empleados utilizan la IA al mismo tiempo, añade GPU, no solo vCPU. Para un departamento resulta razonable separar los componentes: un servidor GPU dedicado para la LLM, un nodo independiente para Qdrant/PostgreSQL y almacenamiento de documentos.
¿Buscas un servidor fiable para tus proyectos?
VPS desde $10/mes y servidores dedicados desde $9/mes con NVMe, protección DDoS y soporte 24/7.
Ver ofertas →Hardware para IA self-hosted con LLM: GPU, VRAM y CPU
El hardware para un stack de IA self-hosted comienza con la elección de la VRAM, ya que esta determina el tamaño máximo del modelo, el contexto y el número de respuestas simultáneas.
Qué modelos caben en la VRAM
Un modelo cuantizado de 7–8B en Q4 suele requerir 5–6 GB de memoria, uno de 14B necesita unos 10–12 GB, un 32B Q4 requiere 20–24 GB y un 70B Q4 necesita desde 40 GB sin un gran margen para contexto. El consumo real depende del motor, la cuantización GGUF/AWQ/GPTQ, la longitud de contexto y KV-cache.
- 12 GB VRAM: 7–8B Q4, uno o dos usuarios interactivos, contexto limitado.
- 24 GB VRAM: 8–14B con margen suficiente o 32B Q4 con compromisos en el contexto.
- 48 GB VRAM: 32B Q4/Q6, contexto largo, varias sesiones simultáneas.
- 2×48 GB VRAM: 70B Q4, distribución de carga entre modelos o alta concurrencia.
Encontrarás un cálculo detallado para Ollama, incluida la RAM para descargar parcialmente capas a CPU, en el artículo sobre cómo elegir RAM, VRAM y CPU para Ollama.
Qué se puede dejar en la CPU
En CPU puedes ejecutar Open WebUI, PostgreSQL, Redis, Qdrant, pipelines de ingestion y modelos de embeddings pequeños. Por ejemplo, bge-small o multilingual-e5-small indexan documentos con 8–16 vCPU sin GPU, aunque a menor velocidad. La inferencia LLM en CPU se justifica para uso personal, tareas nocturnas y consultas poco frecuentes, pero para un equipo la latencia de generación suele ser inaceptable.
Para un servidor solo CPU, elige núcleos modernos con una frecuencia desde 3.0 GHz y NVMe rápido. 16 vCPU y 64 GB RAM son el mínimo práctico para una LLM 7–8B Q4 más RAG, pero espera aproximadamente 3–10 tokens/s según el procesador y el motor. Una GPU suele proporcionar decenas de tokens/s con modelos de la misma clase.
Requisitos de servidor para LLM, RAG y base de datos vectorial: RAM, índice y NVMe
Los requisitos de servidor para LLM, RAG y base de datos vectorial dependen del número de chunks, la dimensionalidad de los embeddings, el tipo de índice HNSW y la necesidad de mantener los segmentos activos en memoria.
Cómo calcular el tamaño de una base de datos vectorial
Un embedding de dimensión 768 en float32 ocupa aproximadamente 3 KB sin datos de servicio. Un millón de vectores requerirá unos 3 GB solo para el array de valores; con el grafo HNSW, payload, replicación y segmentos internos, debes planificar 8–15 GB RAM y 10–20 GB de disco por cada millón de vectores. Con dimensión 1536, las cifras iniciales se duplican aproximadamente.
Los documentos se convierten en chunks. Si divides el texto en fragmentos de 500 tokens con overlap de 50 tokens, 1 GB de texto limpio puede generar cientos de miles de chunks. Los PDF escaneados requieren además OCR, mientras que las tablas e imágenes aumentan el tiempo del proceso de ingestion.
# Пример минимальной конфигурации Qdrant для Docker Compose
services:
qdrant:
image: qdrant/qdrant:v1.12.5
volumes:
- /srv/qdrant:/qdrant/storage
ports:
- "6333:6333"
deploy:
resources:
limits:
memory: 16GQdrant, pgvector o Milvus
Qdrant es práctico como base de datos vectorial dedicada para RAG: se inicia rápidamente en un contenedor y funciona bien para la mayoría de bases de conocimiento de hasta decenas de millones de vectores. pgvector es una opción racional si la aplicación ya usa PostgreSQL y necesitas metadatos transaccionales junto a los embeddings. Milvus se elige con más frecuencia para grandes volúmenes, alta concurrencia y equipos de ingeniería dedicados.
No alojes los archivos de LLM, imágenes Docker, Qdrant, PostgreSQL WAL y copias de seguridad en un único SSD lleno. Para una base de hasta 200 GB, 1 TB NVMe es suficiente, pero para 1 TB de documentos de origen planifica al menos 2–4 TB NVMe y almacenamiento independiente compatible con S3. Para guardar archivos de origen y snapshots, puede servirte el enfoque del artículo sobre requisitos de MinIO y almacenamiento de objetos S3.
Cómo dimensionar hardware RAG self-hosted para documentos y usuarios
El dimensionamiento de hardware para RAG self-hosted debe comenzar con un inventario de documentos: volumen, formatos, frecuencia de actualización y número esperado de búsquedas simultáneas.
Fórmula de planificación
Para un cálculo preliminar, utiliza cuatro valores: número de documentos, número medio de chunks por documento, tamaño del vector de embedding y coeficiente del índice. Por ejemplo, 100 000 documentos con 20 chunks cada uno generan 2 millones de vectores. Con 768 float32, esto equivale a unos 6 GB de vectores en bruto; con HNSW, payload y margen, es razonable asignar 32 GB RAM y 100 GB NVMe exclusivamente al almacenamiento vectorial.
Si los documentos se actualizan a diario, no solo importa la capacidad, sino también la velocidad de reindexación. Un modelo de embeddings en una GPU con 24 GB VRAM puede procesar colas grandes mucho más rápido que una CPU. Para ingestion periódico, crea un worker separado, limita el número de tareas paralelas y ejecuta la indexación masiva fuera de las horas punta.
Contexto, reranker y calidad de respuesta
RAG no debe enviar a la LLM todo el texto encontrado. Una configuración habitual es: top_k=20 para la búsqueda inicial, el reranker deja 4–8 fragmentos y el modelo recibe 3 000–8 000 tokens de contexto. Esto reduce el consumo de VRAM y el tiempo de generación, manteniendo la respuesta vinculada a las fuentes.
# Переменные для консервативного RAG-пайплайна
TOP_K=20
RERANK_TOP_N=6
CHUNK_SIZE=500
CHUNK_OVERLAP=50
EMBEDDING_BATCH_SIZE=64
OLLAMA_NUM_CTX=8192Al aumentar OLLAMA_NUM_CTX de 8K a 32K, KV-cache puede ocupar varios GB VRAM adicionales. No aumentes el contexto «por si acaso»: primero mide el volumen medio de los documentos, el prompt real y la calidad de búsqueda.
Especificaciones y despliegue de OpenWebUI, Ollama y base de datos vectorial
Las especificaciones de servidor para OpenWebUI, Ollama y una base de datos vectorial en producción requieren contenedores separados, volúmenes persistentes, límites de recursos y acceso cerrado a los puertos internos.
Arquitectura básica de contenedores
En un solo servidor puedes empezar con Docker Compose: Ollama sirve el modelo, Open WebUI proporciona SSO o cuentas locales, Qdrant almacena los vectores y PostgreSQL guarda metadatos e historial. Para un equipo, no expongas Qdrant ni Ollama directamente a Internet: deja accesible externamente solo el reverse proxy con TLS y autenticación.
services:
ollama:
image: ollama/ollama:latest
volumes:
- /srv/ollama:/root/.ollama
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: 1
capabilities: [gpu]
openwebui:
image: ghcr.io/open-webui/open-webui:main
volumes:
- /srv/openwebui:/app/backend/data
environment:
- OLLAMA_BASE_URL=http://ollama:11434Qué configuraciones son obligatorias
- Activa TLS en el reverse proxy y deshabilita el registro anónimo.
- Limita el tamaño de los archivos subidos, por ejemplo a 50–100 MB, para que un solo PDF no llene la cola de OCR.
- Configura límites Docker: Qdrant no debe desplazar a Ollama de la RAM y Open WebUI no debe acceder a la GPU si no es necesario.
- Guarda los secretos de API y las contraseñas de PostgreSQL en variables de entorno o en un almacén de secretos, no en un archivo Compose público.
- Separa roles: los usuarios del chat no deben tener acceso administrativo a las colecciones de la base de datos vectorial.
Al desplegar varios servicios internos, resultan útiles los principios generales de la guía sobre cómo elegir hardware para aplicaciones self-hosted: la reserva de recursos, el aislamiento de contenedores y la medición de la carga real son más importantes que el número nominal de cuentas.
Hardware para un stack de IA local: red, disco y copias de seguridad
El hardware para un stack de IA local debe proporcionar no solo rendimiento GPU, sino también I/O predecible, almacenamiento seguro de documentos y recuperación de la base de datos vectorial.
Disco y red sin cuellos de botella
Para un servidor personal, un puerto de 1 Gbps y 500 GB NVMe son suficientes. Para un departamento con carga periódica de archivos, object storage independiente y varios nodos, es mejor usar 1–10 Gbps. El tráfico externo del chat es reducido: una respuesta de 1 000 tokens ocupa apenas unos kilobytes, pero la descarga de datasets, modelos de 5–50 GB y copias de seguridad consume rápidamente el ancho de banda.
No utilices HDD como disco activo para Qdrant o PostgreSQL. Los discos duros sirven para archivos fríos, pero la búsqueda HNSW, WAL y la compactación de segmentos requieren la baja latencia de NVMe. RAID 1 protege frente al fallo de una unidad, pero no sustituye las copias de seguridad.
Qué incluir en el backup
Guarda diariamente PostgreSQL, las configuraciones, las colecciones de Qdrant y los documentos de origen. Los modelos de Ollama pueden descargarse de nuevo, por lo que no es obligatorio incluirlos en el backup diario si se conservan las etiquetas y versiones. Para 1 TB de datos de trabajo, mantén al menos 2–3 TB de espacio de respaldo con historial de versiones.
Un servidor independiente o almacenamiento de objetos reduce el riesgo de perder la base por un error de administrador, ransomware o corrupción del volumen. La práctica de snapshots, deduplicación y cálculo de capacidad se explica en el artículo sobre requisitos de Proxmox Backup Server.
Cómo comprobar el rendimiento de un stack de IA self-hosted
Los requisitos de un stack de IA self-hosted se validan con pruebas de carga: mide tokens por segundo, TTFT, latencia de búsqueda, consumo de VRAM e IOPS durante solicitudes paralelas.
Qué métricas se consideran normales
Para un chat interno, el objetivo de TTFT es hasta 2–4 segundos en una solicitud normal, una velocidad de generación desde 15 tokens/s por usuario y búsqueda en la base de datos vectorial de hasta 300–500 ms sin reranker. Estas referencias dependen del modelo y de la calidad de la respuesta: un modelo 32B será más lento que uno 8B, pero puede manejar mejor instrucciones complejas.
Durante las pruebas, ejecuta al menos 3–5 conversaciones paralelas, comprueba por separado la carga masiva de documentos y supervisa la cola. Si la VRAM está ocupada en más de 90% y el p95 TTFT aumenta varias veces, reduce el contexto, disminuye la concurrencia o añade GPU.
# Наблюдение за GPU и контейнерами
watch -n 1 nvidia-smi
docker stats --no-stream
iostat -xz 1Para producción, Prometheus y Grafana son útiles: recopila GPU utilization, temperatura, VRAM, CPU steal, espacio libre, p95 latency y número de solicitudes. Una alerta al 80% de disco ocupado te permitirá ampliar el NVMe antes de que Qdrant deje de compactar segmentos.
Preguntas frecuentes
¿Se pueden ejecutar LLM, RAG y una base de datos vectorial sin GPU?
Sí, para 1–2 usuarios un stack solo CPU funciona con 8–16 vCPU, 32–64 GB RAM y disco NVMe. Un modelo 7–8B en Q4 responderá más lentamente que con GPU, con frecuencia en el rango de 3–10 tokens por segundo. La CPU sirve para pruebas, una base de conocimiento personal e indexación periódica, pero no para un chat activo de equipo.
¿Cuánta VRAM necesita un sistema RAG para 20 empleados?
Para 10–20 empleados, el mínimo práctico es una GPU con 24 GB VRAM, 16 vCPU y 64 GB RAM. Este volumen permite servir un modelo 8–14B con margen para KV-cache y tareas de embeddings. Si necesitas un modelo 32B, contexto superior a 16K tokens o 5+ generaciones simultáneas, elige 48 GB VRAM.
¿Hace falta una máquina independiente para Qdrant o pgvector?
Hasta 1 millón de vectores, Qdrant o pgvector pueden alojarse junto a la LLM en un servidor con 64 GB RAM y 1 TB NVMe, si la inferencia GPU no está limitada por la CPU. Con 5–10 millones de vectores, reindexación activa o más de 20 usuarios simultáneos, es mejor mover la base de datos vectorial a un nodo independiente con 64–128 GB RAM.
¿Qué disco se necesita para almacenar documentos y el índice vectorial?
Para un stack RAG personal, normalmente bastan 500 GB NVMe; para un equipo con 100–200 GB de documentos de origen, es mejor planificar 1 TB NVMe. Para 1 millón de vectores de dimensión 768, calcula aproximadamente 10–20 GB de disco para el índice y los metadatos. Deja al menos 30% de espacio libre para compactación y copias de seguridad.
Conclusiones
Para un RAG personal, bastan 8 vCPU, 32 GB RAM y 500 GB NVMe; para un equipo de 10–20 personas, elige 16 vCPU, 64 GB RAM, 1 TB NVMe y una GPU con 24 GB VRAM. Si la base de conocimiento supera 1 millón de vectores o necesitas un modelo 32B, pasa a 48 GB VRAM y 128 GB RAM, o separa la LLM y la base de datos vectorial en servidores independientes.
VPS NVMe con activación en 60 segundos: acceso root completo, más de 20 ubicaciones y pago con tarjeta o criptomonedas.
Elegir plan
