AI Supercomputers es el portal de IA local del grupo ietres.La compra se realiza en nuestras tiendas oficiales. Si una referencia no aparece con stock, consulta la posibilidad de reserva y la siguiente entrada prevista.

Arquitectura de referencia · componentes reemplazables

Arquitectura de IA local para empresa: desde el navegador hasta la GPU

¿Eres una pyme y quieres empezar por algo útil?

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.

Ruta para pymes

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.

Empieza por esto

Un único equipo interno, acceso limitado, un caso de uso y documentos bien elegidos.

Compra cuando

Un equipo dedicado cuando el servicio deba estar siempre disponible, el modelo no quepa o haya varios usuarios.

Deja para después

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.

Plano lógico

Las nueve capas de una plataforma empresarial

En palabras sencillas

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.

1Usuario y aplicaciónNavegador, Office, ERP, API
2Entrada seguraTLS, proxy, límites
3IdentidadOIDC, grupos, MFA
4Coordinación de pasosOpen WebUI, app, n8n
5PolíticaPermisos, validación
6ConocimientoRAG, SQL, APIs
7InferenciaOllama, vLLM, NIM
8ObservabilidadMétricas, logs, trazas
9ContinuidadCopias, restauración

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.

Traducción de los términos del diagrama. OIDC permite iniciar sesión con la identidad corporativa; MFA añade una segunda comprobación; RBAC asigna permisos según el rol; RAG busca fragmentos autorizados antes de generar la respuesta; el programa que ejecuta el modelo es el programa que carga y ejecuta el modelo; y la registros y avisos reúne métricas, registros técnicos y el seguimiento de cada petición para saber qué ocurrió.

Responsabilidad de cada capa

CapaPregunta que resuelveEjemplosNo debe hacer
Entrada¿Cómo llega la petición?Apache, Nginx, Caddy, balanceadorConfiar en cabeceras no verificadas
Identidad¿Quién es el usuario?OIDC, LDAP, Entra ID, KeycloakDelegar identidad al texto del prompt
Interfaz¿Cómo conversa o revisa?Open WebUI, portal propio, extensiónConvertirse en fuente única de permisos
Coordinación de pasos¿Qué pasos se ejecutan?Aplicación, n8n, cola, workerGuardar secretos en mensajes
Política¿Qué está permitido?RBAC, allowlists, validadoresConfiar en que el modelo se limite solo
RAG y datos¿Qué evidencia puede usar?Qdrant, pgvector, SQL, APIsIndexar todo sin clasificación
Inferencia¿Qué modelo genera?Ollama, vLLM, NVIDIA NIMAcceder directamente a sistemas de negocio
Observabilidad¿Qué ocurrió y cómo rinde?Métricas, logs, trazas, evaluacionesRegistrar prompts sensibles sin necesidad
Continuidad¿Cómo se recupera?Backups, réplicas, runbooksConsiderar la imagen del contenedor una copia
Tres tamaños de arquitectura

Elige la menor plataforma que cubra el nivel de servicio

Nivel 1

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.

Nivel 2

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.

Nivel 3

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.

Red y exposición

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

Matriz de flujos
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á arriba

No 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.

Identidad y autorización

Autenticar no basta: cada recuperación y herramienta necesita autorización

Cadena de identidad

  1. El proveedor autentica

    OIDC o el sistema corporativo emite identidad y grupos. La interfaz valida emisor, audiencia, firma, caducidad y nonce.

  2. La aplicación crea contexto de autorización

    Transforma grupos corporativos en roles de aplicación sin aceptar roles aportados por el prompt.

  3. RAG filtra antes de buscar

    El filtro de colección y fragmentos se aplica en la consulta, no después de generar la respuesta.

  4. 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.

RolPuedeNo puede
UsuarioConversar y consultar colecciones autorizadasSubir modelos, cambiar prompts globales o ver logs
Gestor de colecciónPublicar documentos de su ámbitoAsignar grupos corporativos
OperadorReiniciar servicios, ver métricas y ejecutar runbooksLeer contenido sensible por defecto
AdministradorConfigurar plataforma y accesoUsar la cuenta administrativa para trabajo diario
AuditorConsultar evidencias y cambiosModificar datos o modelos
Programa que ejecuta el modelo de inferencia

Ollama, vLLM y NVIDIA NIM ocupan posiciones distintas

MotorEncajeVentajasValidaciones
OllamaPiloto, escritorio, pequeño servicio internoInstalación y API sencillas; biblioteca accesibleConcurrencia, registros y avisos, formatos y política local/cloud
vLLMServing concurrente de modelos compatiblesBatching continuo, API compatible y opciones de paralelismoModelo, cuantización, arquitectura GPU, métricas y despliegue
NVIDIA NIMMicroservicios de inferencia en ecosistema NVIDIAContenedor y perfiles optimizados para modelos compatiblesLicencia, 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

Configuración conceptual
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_jobs
RAG y almacenamiento

Separa el original, el texto extraído, el índice y la evidencia

Original

Documento tal como se recibió, con hash, propietario, versión y permisos.

Normalizado

Texto, estructura, tablas y metadatos listos para fragmentar.

Índice

Embeddings, términos y filtros. Es reconstruible desde originales y configuración.

Base operativa

Usuarios, colecciones, trabajos, prompts, aprobaciones y estados.

Evidencia

Evaluaciones, cambios y eventos necesarios para auditoría y soporte.

Copia

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_metadata.json
{
  "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.

Coordinación de pasos e integraciones

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.

1EventoCorreo, webhook, cola
2NormalizarEsquema y tamaño
3LLMClasificar o redactar
4ValidarReglas y permisos
5AprobarCuando proceda
6EjecutarAPI mínima
7VerificarEstado real

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.
Compose de referencia

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.

compose-empresa.yaml
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.txt
Antes de arrancar: revisa que las aplicaciones acepten los nombres de variables mostrados en la versión que has fijado. Los proyectos cambian. Ejecuta docker 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.
Observabilidad

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.

Alta disponibilidad y capacidad

Replica servicios cuando el impacto lo exija, no por apariencia

Componentes con estado y sin estado

ComponenteEstadoEstrategia
ProxyBajoDos instancias y balanceo si el servicio es crítico
API/workerIdealmente sin estadoRéplicas y cola compartida
Programa que ejecuta el modeloModelos cargados y cachéRéplicas por modelo; enrutado y calentamiento
PostgresCríticoCopia, réplica y failover probado según nivel
VectorialReconstruible pero costosoCopia o snapshot y pipeline de reindexación
OriginalesFuente de verdadRepositorio corporativo y copia independiente
n8nFlujo de trabajos, credenciales y ejecucionesBase 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

Variables de planificación
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 + picos

Utiliza percentiles y el caso largo, no una media con prompts cortos. La guía de operación desarrolla capacidad y continuidad.

Orden de montaje

Secuencia para un técnico júnior

  1. Host y GPU

    Actualiza, verifica nvidia-smi, crea rutas, cuentas y red.

  2. Programa que ejecuta el modelo aislado

    Arranca Ollama en localhost, descarga un modelo pequeño y prueba API.

  3. Proxy e interfaz

    Publica Open WebUI por HTTPS, cierra registro y crea roles.

  4. Dataset y modelo

    Compara familias con parámetros fijos y registra memoria.

  5. RAG pequeño

    Indexa una colección vigente, añade metadatos y prueba permisos.

  6. Automatización de borrador

    Integra un sistema con lectura o borrador; nunca una escritura crítica inicial.

  7. Observabilidad y copias

    Activa métricas, logs mínimos y restauración en otro entorno.

  8. Pruebas y aceptación

    Calidad, seguridad, carga, volver a la versión anterior y formación antes de ampliar usuarios.

Del piloto a la compra

Compra hardware cuando el caso ya esté validado

Primero confirma que la tarea ahorra tiempo o mejora el resultado. Después mide memoria, latencia, usuarios y disponibilidad necesaria.

  • Conserva ejemplos correctos e incorrectos para repetir la prueba.
  • Lleva esas medidas al recomendador antes de abrir una ficha comercial.
Preguntas frecuentes

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.

Las reglas de conexión · ¿1, 2, 3 o 4 nodos?
¿Todavía no necesitas toda esta parte avanzada?

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