¿Cómo puedo gestionar múltiples motores de IA en un mismo servidor?

Para gestionar varios motores de IA en un mismo servidor, pon delante una sola capa de acceso (un gateway o API propia compatible con el estándar OpenAI) que reciba todas las peticiones y decida a qué motor enviarlas. Corre cada motor local en su propio contenedor, con límites de CPU y RAM y sus propios puertos internos, y manda a una API externa los modelos que tu hardware no puede mover. En un servidor sin GPU lo realista es combinar modelos locales pequeños para tareas simples con modelos grandes por API (por ejemplo, Dongee AI Router: varios modelos con una sola clave).

Qué significa gestionar varios motores de IA en un servidor

Aquí un «motor» es cualquier pieza que recibe una entrada y devuelve el resultado de un modelo. Puede ser un ejecutor de inferencia local (un servidor de modelos tipo Ollama, llama.cpp o vLLM), un servicio de embeddings, uno de reconocimiento de voz, uno de OCR o una API de modelos comerciales que consumes por internet. Gestionarlos en un mismo servidor no es solo instalarlos uno al lado del otro. Tienen que convivir sin estorbarse y tu aplicación los tiene que poder usar sin conocer los detalles de cada uno.

Cuando varios motores comparten una máquina aparecen siempre los mismos problemas:

• Memoria compartida: cada modelo cargado ocupa RAM (o VRAM si hay GPU). Si dos motores cargan modelos al mismo tiempo, el sistema puede quedarse sin memoria, empezar a usar swap o matar procesos.
• Puertos: cada motor escucha en su propio puerto. Si los expones todos a internet, multiplicas la superficie de ataque.
• Versiones: un motor puede necesitar una versión de librerías que rompe a otro si están instalados directamente en el sistema.
• Claves: las APIs externas usan claves que no deben quedar en el código ni repartidas en varias apps.
• Costos: los motores locales tienen costo fijo (el servidor) y las APIs costo variable (por uso). Sin control, el gasto variable se dispara.
• Quién usa qué: si varios equipos, clientes o apps comparten el servidor, necesitas saber cuánto consume cada uno y poder limitarlo.

Si todavía estás definiendo qué tipo de servidor usar, primero revisa qué es un VPS y en qué se diferencia de otros tipos de alojamiento.

Arquitectura recomendada

La idea central es que tu aplicación hable con un solo punto de entrada y nunca directamente con los motores. Así puedes cambiar, agregar o quitar motores sin tocar el código de la app.

1. Cliente o aplicación: tu backend, un bot, una herramienta interna o un script.
2. Reverse proxy (por ejemplo, Nginx): termina TLS (HTTPS), filtra tráfico y reenvía solo al gateway. Si dudas entre servidores web, aquí tienes una comparación de Nginx vs Apache.
3. Gateway de IA con API única compatible con OpenAI: puede ser un proxy tipo LiteLLM o un servicio propio. Se encarga de:

• Autenticar con claves internas (una por app, equipo o cliente).
• Enrutar por nombre de modelo o por tipo de tarea.
• Aplicar límites por usuario o por clave.
• Registrar el uso (peticiones, tokens, errores, latencia).
• Hacer fallback: si un motor falla o está saturado, enviar la petición a otro.

1. Motores locales en contenedores: cada uno con su límite de memoria y CPU, escuchando en un puerto interno que no se expone a internet.
2. APIs externas: modelos que no puedes o no te conviene correr localmente, con sus claves guardadas en variables de entorno del gateway.

Internet (HTTPS) | +-------------+ |    Nginx    |  TLS, reenvío +-------------+ | +-------------------------------+ |  Gateway de IA (API OpenAI)   | |  claves internas · límites    | |  enrutamiento · logs · fallback| +-------------------------------+ |          |           |         \ red interna   red interna  red interna   salida a internet |          |           |           | +-----------+ +-----------+ +---------+ +------------------+ | Motor LLM | | Embeddings| | Voz/OCR | | APIs externas    | | pequeño   | | (local)   | | (local) | | (modelos grandes)| | límite RAM| | límite RAM| | límite  | | clave en env     | +-----------+ +-----------+ +---------+ +------------------+

Sobre cómo decidir a qué modelo va cada consulta, profundiza en esta comparativa para enrutar consultas entre modelos de lenguaje. Y si te confunde la diferencia entre repartir tráfico y elegir modelo, lee enrutamiento de modelos de IA vs balanceo de carga.

Paso a paso

Haz un inventario de modelos y tareas. Lista qué necesita tu producto: chat, clasificación, resúmenes, embeddings para búsqueda, transcripción de audio, OCR de documentos. Para cada tarea anota qué tan exigente es en calidad, qué volumen esperas y si los datos pueden salir de tu servidor. Con eso ya ves qué conviene local y qué por API.

Dimensiona el servidor empezando por la RAM. La regla es simple: la memoria debe alcanzar para los modelos que tendrás cargados al mismo tiempo, más el sistema operativo, el gateway y tu app. Un modelo cuantizado ocupa bastante menos que su versión completa, pero también pierde algo de calidad. Después mira la CPU, porque en un servidor sin GPU la inferencia corre en los núcleos y más núcleos ayudan con la latencia y la concurrencia. Por último, el disco: los pesos de los modelos son archivos grandes y un SSD NVMe acelera su carga.

Instala Docker y Docker Compose. Aislar cada motor en un contenedor evita choques de versiones y te deja limitar recursos por servicio. Usa un usuario sin privilegios para administrar y mantén el sistema actualizado.

Crea un contenedor por motor, con límites. Cada motor va en su propio servicio, con límite de memoria y CPU y sin puertos publicados hacia afuera. Este es un ejemplo ilustrativo: las imágenes son genéricas y los valores son solo de ejemplo, así que debes ajustarlos a tu servidor y a tus modelos.

# docker-compose.yml — EJEMPLO ilustrativo, ajusta imágenes y valores
services:
  motor-chat:
    image: ejemplo/servidor-llm:version        # imagen de ejemplo
    volumes:
      - pesos-chat:/modelos
    networks: [ia-interna]
    deploy:
      resources:
        limits:
          cpus: "3"          # valor de ejemplo
          memory: 8g         # valor de ejemplo
    restart: unless-stopped
    # sin "ports": solo accesible desde la red interna

  motor-embeddings:
    image: ejemplo/servidor-embeddings:version # imagen de ejemplo
    volumes:
      - pesos-emb:/modelos
    networks: [ia-interna]
    deploy:
      resources:
        limits:
          cpus: "1"          # valor de ejemplo
          memory: 2g         # valor de ejemplo
    restart: unless-stopped

  gateway:
    image: ejemplo/gateway-ia:version          # p. ej. un proxy tipo LiteLLM
    env_file: .env                             # claves fuera del código
    volumes:
      - ./gateway.yaml:/config/gateway.yaml:ro
    networks: [ia-interna, salida]
    ports:
      - "127.0.0.1:4000:4000"                  # solo Nginx local lo alcanza
    depends_on: [motor-chat, motor-embeddings]
    restart: unless-stopped

networks:
  ia-interna:
    internal: true     # sin salida a internet
  salida: {}           # el gateway necesita salir hacia APIs externas

volumes:
  pesos-chat:
  pesos-emb:

Con internal: true los motores no tienen salida a internet. Descarga los pesos de los modelos antes o en una etapa aparte. Así, aunque un motor tenga una vulnerabilidad, no queda expuesto ni puede sacar datos.

Carga y descarga modelos bajo demanda. No tengas todo en memoria todo el tiempo. Muchos servidores de modelos permiten descargar un modelo después de un tiempo sin uso o limitar cuántos modelos quedan cargados a la vez. Deja residentes solo los que se usan constantemente (por ejemplo, embeddings) y carga los demás cuando se necesiten, aceptando una primera respuesta más lenta.

Configura el gateway con nombres de modelo lógicos. Tu app no debe pedir «el modelo X versión Y en el puerto Z», sino algo como rapido, preciso o embeddings. El gateway traduce cada nombre a un motor real. Así, mañana puedes cambiar un modelo local por uno de API, o al revés, sin desplegar de nuevo la app.

# gateway.yaml — EJEMPLO conceptual (la sintaxis depende de tu gateway)
modelos:
  - nombre: rapido
    destino: http://motor-chat:8080/v1        # motor local
  - nombre: embeddings
    destino: http://motor-embeddings:8080/v1  # motor local
  - nombre: preciso
    destino: https://api-externa.ejemplo/v1   # API externa
    clave: ${CLAVE_API_EXTERNA}
    fallback: rapido

Saca claves y secretos del código. Guarda las claves de APIs externas en un archivo .env con permisos restringidos o en un gestor de secretos, y no lo subas al repositorio. Entrega a cada app o cliente una clave interna del gateway, nunca la clave del proveedor externo. Si una clave interna se filtra, la revocas sin afectar a los demás.

Pon límites y colas para tareas pesadas. Limita peticiones por minuto y concurrencia por clave en el gateway. Para trabajos largos (transcribir audios, procesar lotes de PDFs con OCR, generar embeddings de miles de documentos), usa una cola de trabajos con workers que procesen pocos a la vez. Así una carga masiva no deja sin respuesta al chat en tiempo real.

Monitorea y registra sin guardar datos sensibles. Mide uso de RAM y CPU por contenedor, latencia por modelo, tasa de errores y consumo por clave. Herramientas como Prometheus y Grafana son comunes para esto. En los logs guarda metadatos (modelo, clave, duración, tokens, código de respuesta) y evita guardar el contenido de prompts y respuestas, sobre todo si manejas datos personales.

Haz respaldo o snapshot antes de actualizar. Actualizar un motor o cambiar un modelo puede alterar respuestas, formatos o consumo de memoria. Toma un snapshot del servidor, fija versiones de imágenes en el compose y prueba primero con una clave interna de pruebas antes de cambiar el nombre lógico en producción.

Si buscas controlar el gasto en tokens dentro de esta arquitectura, revisa cómo optimizar el consumo de tokens con enrutadores de IA.

¿Todo local, todo por API o híbrido?

Cuándo un solo servidor ya no alcanza

Un servidor bien organizado aguanta mucho, pero hay señales claras de que llegó a su límite:

• El sistema usa swap de forma habitual y las respuestas se vuelven erráticas.
• Las colas de trabajos crecen más rápido de lo que se vacían.
• Los modelos se expulsan de memoria y se vuelven a cargar todo el tiempo.
• Un motor afecta a otro: cuando corre el OCR o la transcripción, el chat se vuelve lento.
• Ya no puedes subir los límites de un contenedor sin quitarle recursos a otro.

El siguiente paso es separar: por ejemplo, un servidor para el gateway y la app, otro para motores de lenguaje y otro para tareas por lotes (voz, OCR, embeddings masivos). Conéctalos por una red privada para que los motores sigan sin exponerse a internet. Si además replicas el gateway en varias instancias, puedes montar tu propio balanceador con Nginx o HAProxy delante. Para planear ese crecimiento, revisa esta guía de infraestructura cloud para escalar aplicaciones de IA.

Errores comunes

• Exponer los puertos de cada motor a internet en lugar de dejarlos en una red interna detrás del gateway.
• No poner límites de memoria a los contenedores, de modo que un solo modelo tumba todo el servidor.
• Intentar correr modelos grandes en CPU esperando la velocidad de una GPU.
• Escribir nombres de modelos concretos en el código de la app, lo que obliga a desplegar de nuevo cada vez que cambias de motor.
• Compartir la clave de la API externa entre todas las apps, sin forma de saber quién consume qué ni de revocar una sola.
• Mezclar tareas por lotes con tráfico en tiempo real sin colas ni prioridades.
• Guardar prompts y respuestas completos en los logs, incluidos datos personales.
• Actualizar motores o modelos sin snapshot ni versiones fijas, sin camino para volver atrás.

Cómo hacerlo con Dongee

Para montar esta arquitectura puedes usar Dongee Cloud: un servidor cloud con procesadores Intel Xeon y acceso root completo por SSH, en el que puedes instalar Docker y Docker Compose sin restricciones, y que se despliega en menos de 3 minutos. Incluye SSD NVMe, red privada entre tus instancias sin costo extra, snapshots, backup de disco incluido en todos los planes, IP dedicada, panel de control, 99,9 % de uptime garantizado y soporte 24/7. Dongee Backup, para copias de archivos internos, es un producto aparte de pago. Hay ubicaciones en Atlanta, Miami, NY, Dallas, México, São Paulo, Santiago de Chile, Frankfurt, Madrid, Londres y Amsterdam.

Algunos planes de ejemplo, según la web de Dongee al 14 de noviembre de 2026 (USD/mes):

Si ninguna combinación encaja, con Cloud On Demand eliges CPU, RAM y disco a medida. Ten en cuenta que los planes de Dongee Cloud son de CPU (Intel Xeon), sin GPU. Por eso lo recomendable es el enfoque híbrido: modelos locales pequeños o cuantizados para embeddings, clasificación y tareas simples, y modelos grandes por API.

Para la parte de API está Dongee AI Router, una API unificada de varios modelos de IA que da prioridad a modelos rápidos alojados en el data center de Dongee en Canadá. Cómo funciona:

• Usas una sola clave para varios modelos y es compatible con el estándar OpenAI: en tu gateway solo cambias la URL base y la clave.
• Admite streaming: la respuesta del modelo va llegando por partes mientras se genera.
• Puedes limitar cada clave a determinados modelos.
• Es prepago desde 3 USD, sin mensualidad, y las cuentas nuevas reciben 3 USD de crédito gratis. Si se acaba el saldo, las peticiones se detienen sin generar deuda.
• No guarda el contenido de las conversaciones, solo los datos de facturación de cada petición.
• Ves el consumo por modelo, por clave y por petición en el área de cliente, desde donde también lo activas.

La elección de modelo y el fallback los programas tú en tu gateway. AI Router se puede usar como destino desde un gateway propio, por ejemplo un proxy tipo LiteLLM: es un destino más dentro de tu enrutamiento y no sirve para alojar tus propios modelos (esos corren en tu servidor cloud).

Si lo que quieres es publicar la app web (hecha con ChatGPT, Lovable, Bolt, v0, Cursor…) sin administrar servidor, Dongee Live publica apps Node.js y sitios estáticos. Eso sí, Live no ejecuta ni despliega modelos de IA. Y si necesitas ayuda, el soporte te atiende en tu idioma porque la plataforma traduce al vuelo.

Preguntas frecuentes

¿Puedo correr varios modelos de IA en un VPS sin GPU?

Sí, si son modelos pequeños o cuantizados y aceptas una latencia mayor que con GPU. Funcionan bien para embeddings, clasificación, extracción y respuestas cortas. Los modelos grandes no son viables en CPU para uso real, así que lo práctico es consumirlos por API.

¿Cuánta RAM necesito?

Depende de qué modelos tengas cargados al mismo tiempo. La regla es que la memoria alcance para esos modelos, más el sistema operativo, el gateway y tu app, con margen para que no entre en swap. Las versiones cuantizadas ocupan bastante menos. Mide el consumo real de cada contenedor con tus modelos antes de elegir el plan definitivo.

¿Docker es obligatorio?

No, pero es muy recomendable. Sin contenedores tendrías que manejar a mano las dependencias, los límites de recursos y el aislamiento de red de cada motor. Docker Compose te deja describir todo en un archivo y repetir la instalación en otro servidor. En Dongee Cloud puedes instalar Docker y Docker Compose sin restricciones.

¿Cómo evito que un modelo consuma toda la memoria?

Pon un límite de memoria a cada contenedor, limita cuántos modelos puede tener cargados cada motor, configura la descarga automática de modelos inactivos y controla la concurrencia desde el gateway. Las tareas pesadas mándalas a una cola.

¿Cómo expongo una sola API para todos los motores?

Con un gateway compatible con el estándar OpenAI detrás de Nginx. Tus apps llaman siempre a la misma URL con su clave interna y un nombre de modelo lógico, y el gateway decide a qué motor local o API externa enviar la petición.

¿Es más barato local o por API?

Depende del volumen. Lo local es costo fijo: con uso alto y constante de tareas simples se aprovecha mejor. La API es costo variable: con volumen bajo o irregular, o cuando necesitas modelos grandes, suele salir mejor. Por eso el híbrido es la opción más común.

¿Puedo usar Dongee AI Router junto con modelos locales?

Sí. Como es compatible con el estándar OpenAI, lo agregas en tu gateway como un destino más, con su URL base y su clave. Tu gateway decide cuándo usar el modelo local y cuándo enviar a AI Router, incluido el fallback que tú configures.

¿Dongee Live sirve para alojar modelos?

No. Dongee Live publica apps Node.js y sitios estáticos, pero no ejecuta ni despliega modelos de IA. Para motores locales necesitas un servidor como Dongee Cloud.

¿Cuándo separar en varios servidores?

Cuando veas swap habitual, colas que no bajan, modelos que se cargan y descargan todo el tiempo o motores que se afectan entre sí. En ese punto separa los motores en instancias conectadas por red privada y, si replicas el gateway, pon tu propio balanceador Nginx o HAProxy delante.

Empieza por lo simple

No necesitas tener todos los motores desde el primer día. Monta primero el gateway con nombres lógicos, agrega uno o dos motores locales con límites claros y conecta una API para lo pesado. Mide el uso real y crece cuando los datos lo indiquen. Puedes desplegar tu servidor en Dongee Cloud y activar Dongee AI Router desde tu área de cliente para probar la arquitectura híbrida con el crédito inicial.