Ollama con varios modelos en paralelo: configuración práctica de Qwen, Llama y DeepSeek

Desde Ollama 0.2, varios modelos pueden ejecutarse a la vez. Ya no hace falta ollama run deepseek-coder para código y luego ollama run qwen2.5 para traducción, recargando y esperando más de diez segundos en cada cambio. Un solo servicio, tres modelos bajo demanda: DeepSeek para código, Qwen para chino, Llama para preguntas generales.
Tres variables de entorno habilitan la carga en paralelo: OLLAMA_MAX_LOADED_MODELS controla cuántos modelos permanecen cargados, OLLAMA_NUM_PARALLEL la concurrencia por modelo y OLLAMA_KEEP_ALIVE el tiempo en espera. Este artículo explica la configuración, los puntos fuertes de cada modelo y la gestión de memoria: precargar modelos de uso frecuente, cargar bajo demanda los poco usados y usar la RAM del sistema cuando la VRAM se quede corta.
Configuración básica para ejecutar varios modelos en paralelo con Ollama
Primero la buena noticia: desde Ollama 0.2, la ejecución en paralelo de varios modelos es una función nativa. No necesitas plugins extra ni archivos de configuración complejos. Con unas pocas variables de entorno, varios modelos quedan listos para usarse.
La mala: si la VRAM de tu GPU no alcanza, esos modelos pueden llenar toda la memoria del sistema y tu equipo se sentirá como un buey tirando de un carro, tan lento que te hará dudar de la vida.
Tres variables de entorno clave
Abre la terminal y revisa estas tres variables:
# Máximo de modelos cargados simultáneamente
export OLLAMA_MAX_LOADED_MODELS=3
# Máximo de solicitudes concurrentes por modelo
export OLLAMA_NUM_PARALLEL=2
# Longitud máxima de la cola de espera (rechaza nuevas solicitudes al superarse)
export OLLAMA_MAX_QUEUE=512
OLLAMA_MAX_LOADED_MODELS es la clave. Con valor 3, puedes ejecutar Qwen, Llama y DeepSeek a la vez. Pero no te apresures a subirlo: el límite lo marca tu hardware. Más adelante detallo los requisitos de memoria.
OLLAMA_NUM_PARALLEL controla la concurrencia de un solo modelo. Si tu servicio recibe varias solicitudes a la vez, puedes subir este valor. En uso personal, la verdad, el valor por defecto suele bastar.
Configuración del servicio del sistema (Linux)
Si gestionas Ollama con systemd (lo habitual en la mayoría de distribuciones Linux), la configuración es sencilla:
sudo systemctl edit ollama.service
Luego añade en el editor:
[Service]
Environment="OLLAMA_MAX_LOADED_MODELS=3"
Environment="OLLAMA_NUM_PARALLEL=2"
Environment="OLLAMA_KEEP_ALIVE=30m"
Guarda, cierra y reinicia el servicio:
sudo systemctl restart ollama
OLLAMA_KEEP_ALIVE es interesante: controla cuánto tiempo los modelos permanecen en memoria en espera. Con 30m, un modelo cargado se mantiene 30 minutos y la siguiente llamada no requiere recarga. Para dejarlos indefinidamente, usa -1.
¿Te alcanza la memoria? Una comprobación rápida
Configuración lista, pero ¿memoria suficiente?
Estimación aproximada: un modelo 7B necesita unos 4-5 GB de VRAM (cuantización FP16), un 14B unos 8-10 GB. Para cargar tres modelos 7B a la vez, necesitas al menos 16 GB de VRAM.
Mi RTX 3060 solo tiene 12 GB de VRAM. Con dos modelos 7B va fluido; el tercero debe usar memoria del sistema y la velocidad cae bastante. En Mac con Apple Silicon, memoria del sistema y GPU se comparten; con 32 GB de memoria unificada, tres modelos van sobrados.
Características de los tres modelos y estrategia de selección
Bien, configuración hecha. Veamos cómo elegir entre estos tres modelos. Al principio yo también dudaba: descargué los tres, pero cada vez no sabía cuál invocar. Tras probar un tiempo, resumí algunas reglas.
Qwen: rey del chino y del multilingüismo
La serie Qwen de código abierto de Alibaba tiene una capacidad en chino muy sólida. La he usado para documentación en chino y para traducir artículos técnicos en inglés con buenos resultados. Según datos oficiales, Qwen soporta más de 100 idiomas: no solo chino e inglés, sino japonés, coreano, francés, español y más.
Si trabajas mucho con contenido en chino o haces traducción multilingüe, Qwen es la primera opción. Con qwen2.5:7b traduje un documento técnico de 5000 palabras con calidad superior a muchas herramientas online. En términos técnicos no traduce “API endpoint” a algo raro como “API 终点”.
Llama: el más equilibrado en lo general
La serie Llama de Meta es el referente entre modelos open source. Si no estás seguro del tipo de tarea, usa Llama: lo más probable es que aciertes.
Tiene una gran ventaja: licencia comercial muy permisiva. Si tu producto tiene menos de 700 millones de usuarios activos mensuales, puedes usarlo gratis en producción. Para muchos desarrolladores independientes y equipos pequeños, eso importa.
Otra ventaja es la ventana de contexto amplia. Llama 3.2 llega a 128K tokens, casi el tamaño de una novela entera. Si procesas documentos muy largos, la ventaja es evidente.
DeepSeek: potencia para código y razonamiento
DeepSeek lo empecé a usar hace poco, pero me convenció rápido. En tareas de código me sorprendió: genera código de buena calidad y explica la lógica con claridad.
Según el informe comparativo de Premai, el coste de razonamiento de DeepSeek es un 95 % menor que el de modelos similares. Para quien necesita mucho razonamiento, es una ventaja real. Menor coste implica más tareas en hardware limitado.
¿Cuál elegir? Tabla de referencia
| Tipo de tarea | Modelo recomendado | Motivo |
|---|---|---|
| Redacción y traducción en chino | Qwen | Mejor capacidad en chino, soporte de 100+ idiomas |
| Contenido multilingüe | Qwen | Procesamiento multilingüe líder |
| Generación y depuración de código | DeepSeek | Fuerte en código, explicaciones claras |
| Razonamiento y análisis técnico | DeepSeek | Menor coste de razonamiento, alta eficiencia |
| Preguntas generales, conversación | Llama | Capacidades equilibradas, difícil fallar |
| Documentos largos | Llama | Ventana de contexto de 128K |
| Proyectos comerciales (<700M MAU) | Llama | Licencia comercial más permisiva |
Mi hábito: DeepSeek para código, Qwen para documentos en chino, Llama para inglés o tareas inciertas. Cada uno tiene su rol y rara vez dudo cuál usar.
Cambio de modelos y gestión de memoria
Al empezar con varios modelos, mi mayor dolor era la lentitud al cambiar. Cada invocación distinta implicaba esperar: recarga del modelo, ventiladores de la GPU a toda marcha, una espera frustrante. Luego supe que ese retardo se puede optimizar.
¿De dónde viene el retardo al cambiar?
El retardo al cambiar de modelo ronda entre 10 y 30 segundos. Depende del tamaño del modelo, la velocidad del disco y el estado de la memoria. Cargar un 7B del disco a la GPU tarda unos 10-15 segundos; un 14B puede tardar 20-30.
En la práctica es molesto. Depuras código con DeepSeek, generas una función y quieres que Qwen traduzca los comentarios, y toca esperar.
keep_alive: mantener modelos en espera
La solución es OLLAMA_KEEP_ALIVE, que ya vimos.
El principio es simple: tras cargarse una vez, el modelo permanece en memoria sin descargarse. La siguiente llamada al mismo modelo es directa, sin recarga.
Puedes configurarlo globalmente:
export OLLAMA_KEEP_ALIVE=30m # Mantener 30 minutos tras la carga
# o
export OLLAMA_KEEP_ALIVE=-1 # Mantener indefinidamente hasta descarga manual
También puedes sobrescribirlo en una solicitud concreta:
curl http://localhost:11434/api/generate \
-d '{"model": "qwen2.5:7b", "prompt": "", "keep_alive": "60m"}'
Enviar una solicitud vacía (prompt vacío) carga el modelo y lo mantiene en memoria. Es un buen método de precarga: cargas de antemano los modelos habituales y las llamadas posteriores responden al instante.
Descarga manual de modelos
Si la memoria aprieta, puedes descargar un modelo manualmente:
curl http://localhost:11434/api/generate \
-d '{"model": "qwen2.5:7b", "keep_alive": 0}'
Con keep_alive en 0, el modelo se descarga de inmediato de la memoria. No borra el archivo del modelo, solo libera la memoria ocupada.
Requisitos de memoria según el tamaño del modelo
Esta tabla la fui armando con el tiempo; es orientativa (datos de la comunidad y mis pruebas):
| Tamaño del modelo | Cuantización FP16 | Cuantización Q4 | GPU recomendada |
|---|---|---|---|
| 7B | 14-16 GB | 4-5 GB | RTX 3060 (12 GB) o superior |
| 14B | 28-32 GB | 8-10 GB | RTX 4070 (12 GB) o superior |
| 32B | 64-70 GB | 18-20 GB | RTX 4090 (24 GB) o superior |
Mi RTX 3060 tiene 12 GB de VRAM. Con cuantización Q4 puedo ejecutar un 14B y un 7B a la vez, o tres modelos 7B. El tercero usa memoria del sistema: más lento, pero no se cae.
Si la VRAM no alcanza pero tienes mucha RAM (32 GB+), también puedes inferir en CPU. Mucho más lento, pero funciona. A veces con que funcione basta.
Un truco: priorizar modelos de uso frecuente
Mi hábito: cargar primero en GPU el modelo que más uso y dejar que los demás usen memoria del sistema.
En mi flujo, DeepSeek es el más usado, así que lo dejo en GPU en espera. Qwen y Llama los uso menos; se cargan al invocarlos y a veces usan RAM del sistema.
Así las tareas frecuentes responden más rápido y las poco frecuentes un poco más lento, con mejor experiencia global. Ajusta el orden según tus hábitos.
Escenarios de aplicación práctica
Basta de teoría; veamos el uso real. Aquí van escenarios que uso a menudo; quizá te den ideas.
Asistente de código: código + documentación
Es mi escenario más habitual. Al escribir código, dos modelos colaboran:
- DeepSeek genera lógica, explica código y depura bugs
- Qwen traduce comentarios y genera documentación en chino
Por ejemplo, al escribir una API, primero pido a DeepSeek el esqueleto del código:
curl http://localhost:11434/api/generate \
-d '{"model": "deepseek-coder:6.7b", "prompt": "Escribe una API RESTful en Express.js para registro e inicio de sesión de usuarios"}'
Tras generar el código, Qwen traduce los comentarios al chino:
curl http://localhost:11434/api/generate \
-d '{"model": "qwen2.5:7b", "prompt": "Traduce al chino los comentarios en inglés de este código:\n[contenido del código]"}'
Dos modelos repartiendo tareas es mucho más eficiente que uno solo. El código de DeepSeek es fiable y las traducciones de Qwen suenan naturales.
Atención al cliente inteligente: bilingüe chino-inglés
Si montas un sistema de soporte para usuarios internacionales:
- Llama atiende consultas en inglés
- Qwen atiende consultas en chino
La implementación no es compleja. Detectas el idioma del usuario e invocas el modelo correspondiente:
import requests
def get_response(user_input, language):
model = "llama3.2:3b" if language == "en" else "qwen2.5:7b"
response = requests.post(
"http://localhost:11434/api/generate",
json={"model": model, "prompt": user_input, "stream": False}
)
return response.json()["response"]
Cada usuario recibe respuestas naturales en su idioma, mejor que con un solo modelo monolingüe.
Preguntas y respuestas: razonamiento + conversación
A veces el tipo de pregunta exige enfoques distintos:
- DeepSeek para preguntas que requieren razonamiento (por qué, cómo)
- Llama para Q&A abierta (qué opinas, hablemos de)
Las preguntas de razonamiento necesitan análisis lógico; DeepSeek razona mejor y ordena mejor la respuesta. La Q&A abierta no exige rigor; Llama responde de forma más natural, más conversacional.
Puedes clasificar por palabras clave. Si la pregunta incluye por qué, causa o principio, usa DeepSeek; si incluye qué opinas o hablemos, usa Llama.
Ejemplo completo de invocación
Un script Python sencillo que elige el modelo según el tipo de tarea:
import requests
def call_ollama(task_type, prompt):
"""Elige el modelo adecuado según el tipo de tarea"""
model_map = {
"code": "deepseek-coder:6.7b",
"chinese": "qwen2.5:7b",
"english": "llama3.2:3b",
"reasoning": "deepseek-coder:6.7b",
"general": "llama3.2:3b"
}
model = model_map.get(task_type, "llama3.2:3b")
# Precargar modelo (opcional)
requests.post(
"http://localhost:11434/api/generate",
json={"model": model, "prompt": "", "keep_alive": "30m"}
)
# Llamada real
response = requests.post(
"http://localhost/11434/api/generate",
json={"model": model, "prompt": prompt, "stream": False}
)
return response.json()["response"]
# Ejemplo de uso
result = call_ollama("code", "Escribe una función Python que calcule el término N de la secuencia de Fibonacci")
print(result)
El script es simple pero ya implementa un scheduler básico multi-modelo. Puedes ampliarlo con más tipos de tarea, lógica de selección más compleja o combinar respuestas de varios modelos.
Si quieres profundizar en lo básico de Ollama, mira los dos primeros artículos de la serie: «Ollama para empezar: tu primer paso para ejecutar LLM en local» y «Parámetros de Modelfile en Ollama: guía completa para modelos personalizados». Este artículo continúa la serie con el tema avanzado del despliegue multi-modelo.
Tabla rápida de configuración
| Variable | Valor recomendado | Función |
|---|---|---|
OLLAMA_MAX_LOADED_MODELS | 2-3 | Número de modelos cargados simultáneamente |
OLLAMA_NUM_PARALLEL | 2 | Solicitudes concurrentes por modelo |
OLLAMA_KEEP_ALIVE | 30m o -1 | Tiempo en espera del modelo |
OLLAMA_MAX_QUEUE | 512 | Longitud de la cola de espera |
Resumen
En esencia, tres puntos:
-
Configura tres variables de entorno y la ejecución multi-modelo queda lista.
OLLAMA_MAX_LOADED_MODELScontrola la cantidad;OLLAMA_KEEP_ALIVE, el tiempo en espera. -
Elige el modelo según la tarea. Código con DeepSeek, chino con Qwen, general con Llama. No te compliques: cada uno tiene su fortaleza.
-
La gestión de memoria importa. Precarga modelos frecuentes; carga bajo demanda los poco usados. ¿VRAM insuficiente? Usa RAM del sistema; a veces basta con que funcione.
Si tienes una GPU con 16 GB+ de VRAM o un Mac con 32 GB+ de memoria unificada, prueba el despliegue de tres modelos en paralelo. Al principio puede costar un poco, pero configurado, la experiencia supera con creces a un solo modelo. Sin cambios constantes ni esperas de carga: esa fluidez se nota.
Si tienes dudas o has tropezado con algún problema, deja un comentario. Yo también sigo aprendiendo; quizá tenga la respuesta a lo que te atasca.
FAQ
Mi GPU solo tiene 8 GB de VRAM, ¿puedo ejecutar varios modelos?
¿Consumir mucha energía si ejecuto tres modelos a la vez?
¿Cómo decido qué modelo usar?
11 min de lectura · Publicado el: 6 abr 2026 · Actualizado el: 21 ago 2026
Guía de Ollama local LLM
Si llegaste desde búsqueda, lo más rápido es ir al artículo anterior o siguiente de esta misma serie.
Anterior
Optimización del rendimiento de Ollama: guía completa de cuantización, batch processing y ajuste de memoria
Estrategias de cuantización Q4/Q5/Q8 para Ollama, configuración de num_batch para aumentar el throughput un 50-150%, gestión de memoria GPU y soluciones a OOM. Incluye benchmarks por hardware.
Parte 9 de 18
Siguiente
Ollama + Open WebUI: monta una interfaz local tipo ChatGPT (guía completa)
Guía paso a paso para montar en local una interfaz de chat con IA al estilo ChatGPT usando Ollama y Open WebUI: instalación, elección de modelos, base de conocimiento RAG, integración API y optimización del rendimiento en 30 minutos
Parte 11 de 18



Comentarios
Inicia sesión con GitHub para dejar un comentario