Un único equipo interno, acceso limitado, un caso de uso y documentos bien elegidos.
Arquitectura de IA local para empresa: desde el navegador hasta la GPU
Sin empezar por una arquitectura compleja: la guía práctica para ponerlo en marcha, sin proyecto — tus documentos respondiendo, el resumen del correo y los datos de cada cliente a una pregunta de distancia.
Diseña una plataforma que pueda crecer desde un piloto con Ollama hasta un servicio para varios usuarios a la vez con vLLM o NVIDIA NIM. El plano separa la identidad del usuario, la interfaz, la coordinación de pasos, el motor que genera la respuesta, la búsqueda documental con RAG, los datos, las métricas y las copias para que cada componente tenga permisos y responsabilidades claros.
La arquitectura mínima para una pyme cabe en pocas piezas
Para empezar no necesitas desplegar todas las capas de esta guía. Un equipo, Ollama, una interfaz, cuentas separadas, una carpeta de documentos y una copia probada cubren muchos primeros casos.
Un equipo dedicado cuando el servicio deba estar siempre disponible, el modelo no quepa o haya varios usuarios.
Alta disponibilidad, colas, redes separadas, inicio de sesión corporativo y motores de servicio para varios usuarios avanzados.
La explicación avanzada continúa debajo. Puedes consultarla cuando el uso, los datos o el número de personas lo justifiquen.
Las nueve capas de una plataforma empresarial
Una instalación seria se organiza como un restaurante: la sala (lo que ve el empleado), la cocina (los modelos trabajando) y el almacén (tus datos) — cada zona con su puerta y su llave. Las "capas" de esta guía son exactamente eso: qué habitación es cada cosa y quién puede entrar en cada una.
El flujo no siempre es lineal. Una aplicación puede buscar información autorizada, preparar las instrucciones que recibirá el modelo, llamar al programa que lo ejecuta y validar la salida. Un agente puede repetir varias herramientas, pero los permisos y los límites deben permanecer fuera del modelo.
Responsabilidad de cada capa
| Capa | Pregunta que resuelve | Ejemplos | No debe hacer |
|---|---|---|---|
| Entrada | ¿Cómo llega la petición? | Apache, Nginx, Caddy, balanceador | Confiar en cabeceras no verificadas |
| Identidad | ¿Quién es el usuario? | OIDC, LDAP, Entra ID, Keycloak | Delegar identidad al texto del prompt |
| Interfaz | ¿Cómo conversa o revisa? | Open WebUI, portal propio, extensión | Convertirse en fuente única de permisos |
| Coordinación de pasos | ¿Qué pasos se ejecutan? | Aplicación, n8n, cola, worker | Guardar secretos en mensajes |
| Política | ¿Qué está permitido? | RBAC, allowlists, validadores | Confiar en que el modelo se limite solo |
| RAG y datos | ¿Qué evidencia puede usar? | Qdrant, pgvector, SQL, APIs | Indexar todo sin clasificación |
| Inferencia | ¿Qué modelo genera? | Ollama, vLLM, NVIDIA NIM | Acceder directamente a sistemas de negocio |
| Observabilidad | ¿Qué ocurrió y cómo rinde? | Métricas, logs, trazas, evaluaciones | Registrar prompts sensibles sin necesidad |
| Continuidad | ¿Cómo se recupera? | Backups, réplicas, runbooks | Considerar la imagen del contenedor una copia |
Elige la menor plataforma que cubra el nivel de servicio
Piloto de una persona o pequeño grupo
- Ollama instalado directamente o en contenedor.
- Interfaz local o Open WebUI.
- Un modelo y un dataset de evaluación.
- Datos sintéticos o colección limitada.
- Sin acciones automáticas.
Objetivo: demostrar utilidad, memoria y calidad.
Servicio interno de departamento
- Host dedicado con GPU o memoria coherente.
- Proxy TLS y acceso por red interna o VPN.
- Identidad corporativa y registro cerrado.
- RAG con permisos, Postgres y vectorial.
- n8n para flujo de trabajos con aprobación.
- Copias y monitorización.
Objetivo: servicio repetible y administrado.
Plataforma empresarial concurrente
- Motor de servicio para varios usuarios orientado a lotes y concurrencia.
- Colas, workers y límites por usuario.
- Separación de entornos y despliegue automatizado.
- Alta disponibilidad según impacto.
- Observabilidad central y evaluación continua.
- Capacidad y recuperación documentadas.
Objetivo: cumplir un nivel de servicio y escalar cargas.
Una entrada pública o interna; todos los demás puertos privados
La topología recomendada separa usuarios, proxy, aplicaciones, datos y administración. En un único servidor puedes representar esas zonas con redes de contenedor y puertos ligados a localhost. En varias máquinas, usa VLAN, firewall y reglas explícitas.
Zona de usuario
Equipos corporativos o VPN. Solo necesitan HTTPS hacia el proxy.
Zona de aplicación
Open WebUI, API propia y n8n. Reciben tráfico únicamente del proxy o de servicios autorizados.
Zona de inferencia
Ollama, vLLM o NIM. Solo admite llamadas de aplicaciones y workers.
Zona de datos
Postgres, vectorial y almacenamiento. No recibe tráfico de usuario.
Zona de gestión
SSH, métricas administrativas y copias. Acceso por red de administración y cuentas separadas.
Reglas de firewall conceptuales
USUARIOS -> PROXY_TLS : 443/TCP
PROXY_TLS -> OPEN_WEBUI : 8080/TCP
PROXY_TLS -> API_EMPRESA : puerto interno
OPEN_WEBUI -> RUNTIME : 11434/TCP o endpoint compatible
API_EMPRESA -> RUNTIME : endpoint compatible
API_EMPRESA -> POSTGRES : 5432/TCP
API_EMPRESA -> VECTORIAL : puerto interno
N8N -> APIs_APROBADAS : solo destinos necesarios
MONITORIZACION -> SERVICIOS : endpoints de métricas
ADMIN_VPN -> HOSTS : SSH y administración
CUALQUIERA -> RUNTIME/DATOS : DENEGADO si no está arribaNo confíes únicamente en que una aplicación no muestre un enlace. Aplica el control en red, proxy y servicio. Para salida a Internet, utiliza una allowlist o un proxy de egreso cuando el caso requiera descargar modelos, consultar una API autorizada o enviar correo.
Autenticar no basta: cada recuperación y herramienta necesita autorización
Cadena de identidad
El proveedor autentica
OIDC o el sistema corporativo emite identidad y grupos. La interfaz valida emisor, audiencia, firma, caducidad y nonce.
La aplicación crea contexto de autorización
Transforma grupos corporativos en roles de aplicación sin aceptar roles aportados por el prompt.
RAG filtra antes de buscar
El filtro de colección y fragmentos se aplica en la consulta, no después de generar la respuesta.
Las herramientas usan identidad técnica o delegada
La elección depende de la API. Cada una debe tener alcance mínimo y trazabilidad al usuario.
| Rol | Puede | No puede |
|---|---|---|
| Usuario | Conversar y consultar colecciones autorizadas | Subir modelos, cambiar prompts globales o ver logs |
| Gestor de colección | Publicar documentos de su ámbito | Asignar grupos corporativos |
| Operador | Reiniciar servicios, ver métricas y ejecutar runbooks | Leer contenido sensible por defecto |
| Administrador | Configurar plataforma y acceso | Usar la cuenta administrativa para trabajo diario |
| Auditor | Consultar evidencias y cambios | Modificar datos o modelos |
Ollama, vLLM y NVIDIA NIM ocupan posiciones distintas
| Motor | Encaje | Ventajas | Validaciones |
|---|---|---|---|
| Ollama | Piloto, escritorio, pequeño servicio interno | Instalación y API sencillas; biblioteca accesible | Concurrencia, registros y avisos, formatos y política local/cloud |
| vLLM | Serving concurrente de modelos compatibles | Batching continuo, API compatible y opciones de paralelismo | Modelo, cuantización, arquitectura GPU, métricas y despliegue |
| NVIDIA NIM | Microservicios de inferencia en ecosistema NVIDIA | Contenedor y perfiles optimizados para modelos compatibles | Licencia, catálogo, hardware, registro y operación |
El programa que ejecuta el modelo debe ser reemplazable para la aplicación. Define una interfaz compatible y una capa de configuración. No permitas que cada equipo llame a un puerto diferente con credenciales propias.
Contrato de inferencia
- Nombre lógico del modelo separado de la imagen o variante concreta.
- Límite de entrada y salida.
- Timeout y cancelación.
- Streaming opcional.
- Formato de errores estable.
- Identificador de petición.
- Métricas de tokens, tiempo y cola.
- Política de logs y datos sensibles.
Enrutado por tarea
routes:
chat_general:
model: instruct_compacto
max_input_tokens: 12000
max_output_tokens: 1200
rag_tecnico:
model: instruct_mayor
max_input_tokens: 32000
max_output_tokens: 1800
clasificacion:
model: clasificador_compacto
response_schema: ticket_category_v2
codigo:
model: code_family
tools: [buscar_repositorio, leer_archivo_autorizado]
visual:
worker_pool: comfyui_gpu
queue: visual_jobsSepara el original, el texto extraído, el índice y la evidencia
Documento tal como se recibió, con hash, propietario, versión y permisos.
Texto, estructura, tablas y metadatos listos para fragmentar.
Embeddings, términos y filtros. Es reconstruible desde originales y configuración.
Usuarios, colecciones, trabajos, prompts, aprobaciones y estados.
Evaluaciones, cambios y eventos necesarios para auditoría y soporte.
Datos críticos cifrados, fuera del host y con restauración probada.
Postgres, vectorial y object storage
Una pequeña prueba puede usar la base incluida en una aplicación. En un servicio compartido, una base administrada facilita copia, integridad y concurrencia. Qdrant o pgvector son opciones habituales para vectores; la elección depende de filtros, escala, operación y experiencia. El original puede vivir en el repositorio corporativo o en almacenamiento de objetos, no necesariamente dentro de la interfaz.
Modelo de metadatos mínimo
{
"document_id": "proc-calidad-042",
"title": "Control de recepción",
"version": "rev-c",
"status": "vigente",
"owner": "calidad",
"language": "es",
"valid_from": "fecha gestionada por el repositorio",
"source_uri": "repositorio://calidad/proc-calidad-042",
"allowed_groups": ["calidad", "recepcion"],
"classification": "interna",
"content_hash": "sha256:..."
}El modelo no debe decidir si un usuario pertenece a allowed_groups. Esa decisión se realiza en la aplicación con la identidad validada.
n8n coordina; el LLM participa en pasos delimitados
Un flujo de trabajo robusto conserva el evento original, asigna un identificador, valida, llama al modelo, valida la respuesta, solicita aprobación y ejecuta la acción. Cada reintento debe ser idempotente.
Separación de credenciales
- El programa que ejecuta el modelo no necesita la contraseña del ERP.
- n8n o el worker conserva la credencial en su almacén de secretos.
- La herramienta expone una operación concreta, no una API genérica.
- El log registra un identificador, no el secreto.
- La rotación no exige volver a entrenar ni cambiar prompts.
Esqueleto para separar redes y persistencia
Este archivo muestra relaciones, no una receta universal. Fija imágenes, comprueba soporte de cada variable, añade healthchecks reales y adapta permisos. Solo el proxy externo debe publicar el servicio a usuarios.
name: ia-empresa
services:
runtime:
image: ollama/ollama:${OLLAMA_TAG}
restart: unless-stopped
gpus: all
networks: [inference]
volumes: [models:/root/.ollama]
security_opt: [no-new-privileges:true]
webui:
image: ghcr.io/open-webui/open-webui:${WEBUI_TAG}
restart: unless-stopped
depends_on: [runtime, postgres]
networks: [frontend, inference, data]
ports: ["127.0.0.1:3000:8080"]
environment:
OLLAMA_BASE_URL: http://runtime:11434
DATABASE_URL: ${WEBUI_DATABASE_URL}
WEBUI_SECRET_KEY: ${WEBUI_SECRET_KEY}
ENABLE_SIGNUP: "false"
volumes: [webui_data:/app/backend/data]
security_opt: [no-new-privileges:true]
postgres:
image: postgres:${POSTGRES_TAG}
restart: unless-stopped
networks: [data]
environment:
POSTGRES_DB: ia
POSTGRES_USER: ia_service
POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password
secrets: [postgres_password]
volumes: [postgres_data:/var/lib/postgresql/data]
security_opt: [no-new-privileges:true]
qdrant:
image: qdrant/qdrant:${QDRANT_TAG}
restart: unless-stopped
networks: [data]
volumes: [qdrant_data:/qdrant/storage]
security_opt: [no-new-privileges:true]
n8n:
image: n8nio/n8n:${N8N_TAG}
restart: unless-stopped
networks: [automation, data, inference]
ports: ["127.0.0.1:5678:5678"]
environment:
N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
DB_TYPE: postgresdb
DB_POSTGRESDB_HOST: postgres
DB_POSTGRESDB_DATABASE: ia
DB_POSTGRESDB_USER: ia_service
DB_POSTGRESDB_PASSWORD_FILE: /run/secrets/postgres_password
volumes: [n8n_data:/home/node/.n8n]
security_opt: [no-new-privileges:true]
networks:
frontend: {}
inference:
internal: true
data:
internal: true
automation: {}
volumes:
models: {}
webui_data: {}
postgres_data: {}
qdrant_data: {}
n8n_data: {}
secrets:
postgres_password:
file: ./secrets/postgres_password.txtdocker compose config, escanea imágenes, limita el egreso y prueba la restauración en un entorno separado. El ejemplo evita un cap_drop: ALL común a todas las imágenes porque la inicialización de volúmenes puede necesitar capacidades distintas. Endurece cada servicio después de comprobar UID, GID, rutas de escritura y healthcheck; nunca recurras a modo privilegiado como solución general.Mide la plataforma sin convertir los logs en una copia de los datos
Infraestructura
- GPU, memoria, temperatura y potencia.
- CPU, RAM, disco e I/O.
- Disponibilidad de contenedores.
- Red y errores de conexión.
Inferencia
- Peticiones, cola y errores.
- Entrada y salida en tokens.
- Primer token y latencia total.
- Uso de modelo y rechazos.
Calidad
- Fuentes encontradas.
- Abstenciones y feedback.
- Validación de esquema.
- Regresiones del dataset.
Política de logging
Registra identificador, usuario o pseudónimo cuando esté justificado, modelo lógico, versión de prompt, colección, herramientas llamadas, tiempos, código de resultado y aprobación. No guardes por defecto prompt completo, documentos, tokens, cabeceras de autenticación o secretos. Para depuración con contenido, habilita una ventana limitada, acceso restringido y borrado explícito.
Replica servicios cuando el impacto lo exija, no por apariencia
Componentes con estado y sin estado
| Componente | Estado | Estrategia |
|---|---|---|
| Proxy | Bajo | Dos instancias y balanceo si el servicio es crítico |
| API/worker | Idealmente sin estado | Réplicas y cola compartida |
| Programa que ejecuta el modelo | Modelos cargados y caché | Réplicas por modelo; enrutado y calentamiento |
| Postgres | Crítico | Copia, réplica y failover probado según nivel |
| Vectorial | Reconstruible pero costoso | Copia o snapshot y pipeline de reindexación |
| Originales | Fuente de verdad | Repositorio corporativo y copia independiente |
| n8n | Flujo de trabajos, credenciales y ejecuciones | Base externa, cola y copia coherente |
Escalado de modelos
Para un único modelo, primero optimiza contexto, lote y motor. Después añade réplicas para peticiones independientes. El paralelismo tensorial o de pipeline requiere hardware, interconexión y soporte del motor. El enlace oficial de dos DGX Spark es un caso específico para modelos compatibles; no implica que diez unidades formen automáticamente una memoria única.
Cálculo de capacidad
peticiones_hora_pico = usuarios_concurrentes * peticiones_por_usuario
trabajo_total = sum(tokens_entrada + tokens_salida)
capacidad_efectiva = tokens_por_segundo_medidos * factor_utilizacion_seguro
latencia_objetivo = cola + prefill + generacion + herramientas
margen = crecimiento + fallos + actualizaciones + picosUtiliza percentiles y el caso largo, no una media con prompts cortos. La guía de operación desarrolla capacidad y continuidad.
Secuencia para un técnico júnior
Host y GPU
Actualiza, verifica
nvidia-smi, crea rutas, cuentas y red.Programa que ejecuta el modelo aislado
Arranca Ollama en localhost, descarga un modelo pequeño y prueba API.
Proxy e interfaz
Publica Open WebUI por HTTPS, cierra registro y crea roles.
Dataset y modelo
Compara familias con parámetros fijos y registra memoria.
RAG pequeño
Indexa una colección vigente, añade metadatos y prueba permisos.
Automatización de borrador
Integra un sistema con lectura o borrador; nunca una escritura crítica inicial.
Observabilidad y copias
Activa métricas, logs mínimos y restauración en otro entorno.
Pruebas y aceptación
Calidad, seguridad, carga, volver a la versión anterior y formación antes de ampliar usuarios.
Decisiones de arquitectura
¿Necesito Kubernetes?
No para empezar. Docker Compose y un host administrado permiten validar y servir alcances moderados. Kubernetes aporta valor cuando existe experiencia operativa, múltiples nodos, despliegues frecuentes y requisitos que justifican su complejidad.
¿Puedo instalar Open WebUI y Ollama en el mismo servidor?
Sí para un piloto o equipo, separando redes, persistencia y permisos. En cargas mayores puedes separar interfaz, datos e inferencia para escalar y mantener cada capa de forma independiente.
¿Qdrant o pgvector?
Ambos pueden ser válidos. pgvector reduce componentes si ya operas Postgres y la escala encaja; un motor vectorial dedicado puede ofrecer funciones y operación específicas. Evalúa filtros, latencia, copia, experiencia y volumen real.
¿Cuándo cambio Ollama por vLLM o NIM?
Cuando las mediciones muestran que concurrencia, batching, registros y avisos o despliegue necesitan un motor de servicio para varios usuarios distinto y el modelo es compatible. Mantén una API estable para evitar reescribir la aplicación.
¿Dónde deben estar los documentos originales?
En el repositorio gobernado de la empresa o almacenamiento con propietario, versión y permisos. El índice es una representación derivada; debe poder reconstruirse y no sustituye a la fuente de verdad.
- Dos nodos: mantienen la referencia oficial de hasta 405B con software compatible y un enlace QSFP directo.
- Tres o cuatro nodos: NVIDIA Sync valida un anillo de tres y topologías de hasta cuatro mediante switch; repartir un modelo exige un programa que ejecuta el modelo compatible y pruebas reales.
- Más usuarios: si el modelo cabe en una unidad, suele ser más sencillo añadir réplicas o colas que dividir el modelo. Ver topologías y límites →
No pasa nada: empieza por lo esencial y vuelve aquí cuando el uso crezca. Para muchas pymes, el primer paso se reduce a un equipo, un uso concreto y una receta — la guía práctica para pymes — y esta página seguirá aquí, esperándote, el día que toque crecer.
Fuentes técnicas y criterio editorial
Las especificaciones, funciones y límites descritos se contrastan con documentación primaria de Despliegue y operación, Open WebUI, documentos y agentes. Las recomendaciones de compra, el orden de los pasos y los márgenes de planificación son criterios editoriales de AI Supercomputers: deben confirmarse con la versión instalada y una prueba real.
Docker Engine: instalación · Ollama: documentación oficial · Open WebUI: documentación oficial · Workspace de Open WebUI · Knowledge y RAG · Modelos configurados · Seguridad de Tools