Gemma 4 de Google: análisis real de los mejores modelos de IA local en 2026 — velocidad, calidad y recomendaciones

Los benchmarks publicados por los fabricantes de modelos de IA suelen mostrar sus versiones más grandes corriendo en hardware de servidor. Pero, ¿qué pasa cuando los pruebas en tu propio equipo, con una GPU de consumo y condiciones reales de uso?

Esto es exactamente lo que hice: tomé ocho de los modelos más relevantes disponibles hoy en Ollama, los corrí en el mismo hardware, con las mismas preguntas, y medí no solo la velocidad de generación sino también el retraso por pensamiento, el consumo de VRAM, el overflow a RAM y el uso de CPU. Los resultados me obligaron a revisar mis opiniones más de una vez — este artículo refleja la tercera y definitiva ronda de evaluación.

El foco especial está en Gemma 4 de Google DeepMind, un modelo que en las comparativas publicadas aparece por debajo de otros competidores, pero que en mis pruebas reales demostró ser consistentemente el mejor para uso cotidiano en hardware de 12 GB.


Hardware usado para las pruebas

  • CPU: AMD Ryzen 7 5700G (8 núcleos, arquitectura Zen 3)
  • RAM: 32 GB DDR4 a 3200 MHz
  • GPU: Gigabyte GeForce RTX 3060 12 GB GDDR6
  • Almacenamiento de modelos: HDD 1.8 TB
  • Sistema operativo: Debian 12 Bookworm
  • Motor de inferencia: Ollama en Docker con CUDA

La RTX 3060 de 12 GB representa el punto de entrada más sensato para IA local en 2026: suficiente VRAM para correr modelos de 14B parámetros completamente en GPU, con una relación precio/rendimiento difícil de superar en el mercado de segunda mano.


Una métrica que nadie menciona: el retraso por pensamiento

Antes de entrar en los datos, hay una métrica que define la experiencia de uso más que cualquier otra y que rara vez aparece en las comparativas: el retraso por pensamiento.

Los modelos modernos con capacidad de razonamiento generan un proceso interno de análisis antes de producir la respuesta visible. Durante ese tiempo, el usuario ve una pantalla en blanco o un indicador de carga. Dependiendo del modelo y la complejidad de la pregunta, ese retraso puede ir de segundos a más de un minuto.

En la práctica, un modelo que genera a 45 tokens por segundo pero tarda 60 segundos en empezar puede sentirse más lento que uno que genera a 30 t/s con 6 segundos de retraso. Evaluar modelos únicamente por velocidad de generación es engañoso.


Tabla comparativa completa

ModeloVelocidad (t/s)VRAM usadaOverflow RAMCPUArranque fríoRetraso thinking
gemma4:e4b73.06~10 GB0 GB~0%~90 seg~6 seg
qwen3.5:9b45.228.8 GB0 GB~0%~60 seghasta 60 seg
qwen3.5:9b (/nothink)45.228.8 GB0 GB~0%~60 seg~10 seg
phi4-reasoning:14b21.28~12 GB~2 GB~3%~90 seg~120 seg
mistral-nemo:12b46.127.7 GB0 GB~0%~30 seg0 seg
deepseek-r1:14b33.54~10 GB0 GB~0%~60 seg~20 seg
qwen3:14b32.5810 GB0 GB~0%~20 seg~13 seg
mistral-small3.2:24b6.58~12 GB~5 GB31%~170 seg0 seg
gemma4:26b1812 GB8 GB41%~240 seg~50 seg

Ranking final por calidad de respuesta

  1. 🥇 gemma4:e4b — Mejor calidad general, más rápido, multimodal
  2. 🥈 qwen3.5:9b — Buen contenido, excelente formato, thinking lento
  3. 🥉 phi4-reasoning:14b — Contenido similar a Qwen3.5, formato menos pulido
  4. 4️⃣ mistral-nemo:12b — Sólido, rápido, sin esperas
  5. 5️⃣ deepseek-r1:14b — Razonamiento profundo y visible
  6. 6️⃣ qwen3:14b — Competente pero superado por la nueva generación
  7. 7️⃣ mistral-small3.2:24b — No escala bien en 12 GB de VRAM
  8. 8️⃣ gemma4:26b — Descartado en este hardware

Análisis detallado por modelo

1. Gemma 4 E4B — El mejor modelo para hardware de 12 GB

Gemma 4 es la familia de modelos open source más reciente de Google DeepMind, lanzada en abril de 2026. La variante E4B es el punto dulce de la familia para GPUs de 12 GB: cabe completamente en VRAM, no toca la RAM del sistema y no genera carga en el CPU.

¿Qué tiene de especial Gemma 4?

  • Multimodal nativo: procesa texto, imágenes y audio en el mismo modelo, sin herramientas adicionales
  • Thinking mode con mínimo retraso: solo 6 segundos antes de la primera respuesta — el más bajo del grupo
  • 128K tokens de contexto: suficiente para proyectos de código extensos o documentos largos
  • Arquitectura MoE eficiente: 4.5B parámetros efectivos en un paquete de 9.6 GB

Datos reales medidos

  • Velocidad: 73.06 tokens por segundo
  • VRAM: ~10 GB, sin overflow
  • CPU: ~0% durante generación
  • Arranque en frío: ~90 segundos
  • Retraso por thinking: ~6 segundos

A 73 tokens por segundo, el modelo genera texto mucho más rápido de lo que puedes leerlo. Es la experiencia de uso más fluida que he tenido con un modelo local en hardware de consumo.

En las comparativas publicadas, Gemma4 aparece un poco por debajo de modelos como Qwen3.5 en los rankings generales. Sin embargo, en mis pruebas reales la calidad percibida de las respuestas supera a todos los demás del grupo. Hay una brecha clara entre los benchmarks de laboratorio con versiones cloud y la experiencia de uso real con versiones locales en hardware de consumo.

La capacidad multimodal añade una dimensión completamente nueva: pasar una captura de pantalla de un error, un diagrama de arquitectura o un documento y recibir análisis inmediato es algo que ningún otro modelo de esta comparativa ofrece de forma tan integrada.

Veredicto: primer lugar en calidad de respuesta y primer lugar en velocidad. La mejor opción para hardware de 12 GB sin discusión.


2. Qwen 3.5 9B — Buen formato, contenido sobrevalorado por los benchmarks

Qwen3.5 es la familia más reciente de Alibaba. En las comparativas de su versión cloud (Qwen3.5-Plus) aparece al nivel de GPT-5.2 o Claude Opus 4.5. La versión local de 9B es una historia diferente.

Las respuestas tienen muy buen formato y presentación: estructura clara, uso apropiado de listas y encabezados, organización visual cuidada. Sin embargo, el contenido en sí no está a la altura de lo que sugieren los benchmarks de sus versiones cloud. La apariencia de calidad que da el formato puede crear una primera impresión mejor de la que merece el fondo de las respuestas.

El thinking mode introduce el mayor retraso del grupo: hasta 60 segundos antes de la primera respuesta en preguntas complejas. Desactivarlo con /nothink reduce ese tiempo a unos 10 segundos, haciendo el modelo mucho más usable en el día a día, aunque sacrificando parte de su capacidad de razonamiento.

Veredicto: segundo lugar en calidad. Mejor con /nothink para uso cotidiano. Los benchmarks de su versión cloud no reflejan el rendimiento real de la versión local de 9B.


3. Phi4 Reasoning 14B — Potencial sin pulir

Phi4-reasoning es el modelo de razonamiento de Microsoft, parte de la familia Phi4. Con 14B parámetros genera a 21.28 t/s con un ligero overflow de 2 GB a RAM y apenas 3% de uso de CPU.

La calidad del contenido es comparable a Qwen3.5:9b — buen nivel de análisis técnico y respuestas bien razonadas. La diferencia está en el formato: donde Qwen3.5 presenta respuestas visualmente organizadas, Phi4-reasoning tiende a entregar el mismo nivel de contenido de forma más cruda, sin la estructuración visual que facilita la lectura.

Es un modelo prometedor que probablemente mejore con versiones futuras. Para quien prioriza el contenido sobre la presentación, es una alternativa válida en el rango de 14B.

Veredicto: tercer lugar en calidad. Mismo nivel de contenido que Qwen3.5:9b, presentación menos cuidada.


4. Mistral Nemo 12B — El equilibrado que nadie menciona

Mistral Nemo es un modelo que suele quedar fuera de los titulares pero que en las pruebas resulta ser una opción muy práctica. Con solo 7.7 GB de VRAM cabe en GPUs de 8 GB, genera a 46.12 t/s sin ningún retraso por thinking y sin overflow a RAM.

Su valor principal es la consistencia: el arranque más rápido del grupo (~30 segundos), respuesta inmediata sin pausa de pensamiento y compatibilidad con hardware más modesto. La calidad de sus respuestas es competente aunque no destaca especialmente frente a los primeros tres modelos del ranking.

Veredicto: cuarto lugar. La mejor opción para GPUs de 8 GB y para quien necesita respuesta inmediata sin ninguna configuración adicional.


5. DeepSeek R1 14B — El especialista en razonamiento visible

DeepSeek R1 está diseñado específicamente para razonamiento profundo y transparente. Su proceso de pensamiento es visible paso a paso, lo que permite entender no solo la respuesta sino el camino para llegar a ella. Esto tiene valor real en debugging complejo, análisis de sistemas o decisiones arquitectónicas donde el proceso importa tanto como el resultado.

A 33.54 t/s sin overflow a RAM, el rendimiento es sólido. El retraso de ~20 segundos por thinking es aceptable dado el nivel de análisis que produce. Quinto lugar en calidad de respuesta del grupo.

Veredicto: quinto lugar en calidad general. Recomendado cuando el razonamiento visible y trazable es un requisito.


6. Qwen3 14B — Superado por la nueva generación

Qwen3:14b fue durante meses una referencia sólida para tareas de código y arquitectura. A 32.58 t/s sin overflow, sigue siendo competente, y el modo /think activa razonamiento paso a paso cuando se necesita.

El problema es que modelos más nuevos y en algunos casos más pequeños lo superan en calidad. Qwen3.5:9b entrega mejor resultado siendo más pequeño. Phi4-reasoning ofrece análisis comparable con reasoning más explicado. Qwen3:14b ya no es la primera opción en ninguna categoría de esta comparativa.

Veredicto: sexto lugar. Todavía funcional pero sin ventaja frente al resto del grupo.


7. Mistral Small 3.2 24B — No escala bien en 12 GB de VRAM

Mistral Small 3.2 tiene buenas credenciales: 24B parámetros, arquitectura MoE, sin retraso por thinking. En hardware con 24 GB de VRAM probablemente brillaría. En una GPU de 12 GB los números son difíciles de defender.

6.58 t/s de generación, 5 GB de overflow a RAM, 31% de CPU constante y casi 3 minutos de arranque en frío. Para obtener una respuesta comparable a la de los modelos del top 3, el tiempo de espera total es varias veces mayor. La ausencia de retraso por thinking no compensa la lentitud general del modelo en este hardware.

Veredicto: séptimo lugar. Necesita 24 GB de VRAM para ser competitivo. No recomendado en 12 GB.


8. Gemma4 26B — La versión grande que decepciona en este hardware

Con 8 GB de overflow a RAM, 41% de CPU constante, 4 minutos de arranque y ~50 segundos de retraso por thinking, el Gemma4:26b ofrece la peor experiencia de uso del grupo en este hardware. Su versión pequeña, el E4B, es superior en todos los aspectos prácticos cuando la VRAM disponible es de 12 GB.

La mejora de calidad frente al E4B no justifica en ningún caso la penalización de rendimiento. Para este modelo se necesita idealmente una GPU de 24 GB donde pueda correr completamente en VRAM.

Veredicto: último lugar. Usar gemma4:e4b en su lugar para este nivel de hardware.


¿Cuándo usar cada modelo?

Para el día a día y consultas cotidianas: gemma4:e4b. Velocidad, calidad y soporte multimodal. Sin competencia en este hardware.

Para análisis de imágenes, diagramas o documentos: gemma4:e4b. Es el único modelo del grupo con soporte multimodal real integrado.

Para análisis técnico con buen formato: qwen3.5:9b con /nothink. Respuestas bien estructuradas visualmente para documentación o explicaciones.

Para razonamiento trazable paso a paso: deepseek-r1:14b. Cuando el proceso importa tanto como la respuesta.

Para GPUs de 8 GB o menos: mistral-nemo:12b. Cabe cómodo, responde sin esperas y no requiere configuración.

Para autocomplete en el editor: deepcoder:1.5b o phi4-mini:3.8b. Modelos ultraligeros que se quedan cargados en background sin impactar el rendimiento de los modelos principales.


El stack que uso actualmente

  • gemma4:e4b — modelo principal para todo el trabajo cotidiano y análisis de imágenes
  • qwen3.5:9b — para cuando necesito respuestas bien formateadas o análisis con thinking activado
  • deepseek-r1:14b — para debugging complejo y razonamiento técnico profundo
  • mistral-nemo:12b — para consultas rápidas sin ninguna espera
  • deepcoder:1.5b — autocomplete permanente en VS Code y Visual Studio

Lo que viene en esta serie

Este análisis de modelos es el segundo artículo de una serie sobre IA local. Los próximos temas que planeo cubrir:

  • Integración con clientes de codificación: Claude Code, Codex y OpenCode — cómo conectarlos a tu servidor Ollama local y qué diferencias hay entre ellos para el trabajo diario de desarrollo
  • Compatibilidad con GitHub Copilot: ¿es posible usar tus modelos locales como backend de Copilot?
  • Implementación de un sistema RAG: cómo conectar tu propia base de documentos a los modelos para obtener respuestas basadas en tu conocimiento privado, sin que nada salga de tu red

Si quieres recibir notificación cuando salgan esos artículos, suscríbete al blog.


Conclusiones

Tres lecciones que me llevé de estas pruebas después de tres rondas de evaluación:

1. Los benchmarks de laboratorio no predicen la experiencia real en hardware de consumo. Gemma4 aparece por debajo de Qwen3.5 en muchas comparativas publicadas. En hardware real, Gemma4:e4b gana en calidad percibida, velocidad y experiencia de uso. La versión cloud de un modelo y su versión local de 9B son productos muy distintos.

2. El retraso por thinking puede arruinar un modelo perfectamente capaz. Qwen3.5:9b tiene buenas respuestas pero su retraso de hasta 60 segundos por thinking lo hace frustrante para uso cotidiano. Desactivarlo con /nothink es la solución práctica, aunque implica sacrificar parte de su capacidad de razonamiento.

3. Con una RTX 3060 de 12 GB ya se puede hacer trabajo serio con IA local. Gemma4:e4b a 73 t/s con soporte multimodal, completamente en local, sin suscripciones y sin que tus datos salgan de tu red. Eso habría parecido imposible hace dos años en hardware de consumo.

¿Has probado alguno de estos modelos? ¿Tu experiencia coincide con la mía o llegaste a conclusiones diferentes? Los comentarios están abiertos.

Cómo montar tu propio servidor de IA local con Ollama y Open WebUI en Linux — Guía completa 2026

¿Cansado de los límites de uso, las suscripciones mensuales y la preocupación de que tus conversaciones con una IA sean almacenadas en servidores de terceros? Existe una alternativa real: montar tu propio servidor de inteligencia artificial en casa, con hardware que probablemente ya tienes o puedes conseguir por una fracción del costo de una suscripción anual.

En este artículo te explico exactamente cómo lo hice, qué hardware usé, qué software necesitas y cómo dejarlo funcionando desde cualquier dispositivo de tu red local.


¿Por qué correr una IA localmente?

Antes de entrar al tutorial, vale la pena entender por qué tiene sentido hacer esto:

  • Privacidad total: tus conversaciones, tu código y tus documentos nunca salen de tu red. Nadie los lee, nadie los usa para entrenar modelos.
  • Sin costo por uso: una vez que tienes el hardware, el costo marginal de cada consulta es prácticamente cero (electricidad).
  • Sin límites de mensajes: no hay “has alcanzado tu límite diario” ni planes de pago por niveles.
  • Funciona offline: no dependes de internet ni de la disponibilidad de servidores externos.
  • Control total: tú decides qué modelos corres, con qué configuración y quién tiene acceso.

¿Qué es Ollama y qué es Open WebUI?

Ollama es una herramienta open source que permite descargar, gestionar y servir modelos de lenguaje grandes (LLMs) localmente. Funciona como un servidor con API REST, lo que significa que cualquier aplicación en tu red puede hacer consultas a tus modelos como si fuera una API de OpenAI.

Open WebUI es una interfaz web tipo ChatGPT que se conecta a Ollama. Te da una experiencia visual amigable desde cualquier navegador, sin necesidad de usar la terminal para interactuar con los modelos.

Juntos forman un stack completo: Ollama gestiona los modelos y la inferencia, Open WebUI le da la interfaz. Docker se encarga de que todo corra de forma aislada y reproducible.


Requerimientos de hardware

La clave para un servidor de IA funcional es la GPU. Los modelos de lenguaje corren dramáticamente más rápido en GPU que en CPU — hablamos de una diferencia de 10x a 15x en velocidad de generación.

Hardware mínimo recomendado

  • CPU: procesador x86-64 de 6 o más núcleos (AMD Ryzen o Intel Core de generación reciente)
  • RAM: 16 GB DDR4 mínimo, 32 GB recomendado. La RAM del sistema sirve como desbordamiento cuando los modelos no caben completamente en la VRAM de la GPU
  • GPU: NVIDIA con mínimo 8 GB de VRAM. La RTX 3060 de 12 GB es el punto dulce en relación precio/rendimiento para modelos locales
  • Almacenamiento: SSD de 256 GB para el sistema operativo y Docker. Un disco adicional (HDD o SSD) de al menos 500 GB para almacenar los modelos, ya que cada uno pesa entre 4 y 20 GB
  • Sistema operativo: Debian 12 (Bookworm) o Ubuntu 22.04/24.04 LTS

Hardware real usado en este tutorial

El servidor que uso como base para esta guía tiene las siguientes especificaciones:

  • Placa madre: MSI MPG B550 Gaming Plus
  • CPU: AMD Ryzen 7 5700G (8 núcleos)
  • RAM: 32 GB DDR4 a 3200 MHz
  • GPU: Gigabyte GeForce RTX 3060 12 GB
  • SSD: 256 GB M.2 NVMe PCIe 4.0 (sistema y Docker)
  • HDD: 1.8 TB (almacenamiento de modelos)
  • Sistema operativo: Debian 12 Bookworm

Con este hardware, modelos de 14B parámetros corren completamente en GPU a 25-35 tokens por segundo, y modelos más pequeños como Gemma4:e4b alcanzan 73 tokens por segundo, más rápido de lo que puedes leer.

Nota sobre GPU: aunque este tutorial usa una RTX 3060 de NVIDIA (que funciona con CUDA, el estándar de la industria), también es posible usar GPUs AMD con ROCm, aunque requiere configuración adicional. Si tu presupuesto es limitado, busca una RTX 3060 de 12 GB de segunda mano — es específicamente la versión de 12 GB, no la Ti que tiene 8 GB.


Software necesario

Antes de empezar, estos son los componentes de software que vamos a instalar:

  1. Docker + Docker Compose: para ejecutar Ollama y Open WebUI como contenedores
  2. Drivers NVIDIA: para que Linux reconozca y use la GPU
  3. NVIDIA Container Toolkit: para que Docker pueda acceder a la GPU
  4. Ollama (imagen Docker): el servidor de modelos
  5. Open WebUI (imagen Docker): la interfaz web

Instalación paso a paso

Paso 1: Instalar Docker en Debian

Primero agrega los repositorios oficiales de Docker para Debian:

# Instalar dependencias
apt update && apt install -y ca-certificates curl gnupg

# Agregar la clave GPG de Docker
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
chmod a+r /etc/apt/keyrings/docker.gpg

# Agregar el repositorio de Docker para Debian
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/debian \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  tee /etc/apt/sources.list.d/docker.list > /dev/null

# Instalar Docker
apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

Verifica que Docker quedó instalado correctamente:

docker --version

Paso 2: Instalar drivers NVIDIA

Primero hay que agregar los repositorios non-free de Debian. Edita el archivo de fuentes:

nano /etc/apt/sources.list

Asegúrate de que cada línea incluya contrib non-free non-free-firmware:

deb http://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware

Luego instala el driver:

apt update
apt install -y nvidia-driver firmware-misc-nonfree

# Deshabilitar el driver genérico nouveau
echo "blacklist nouveau" >> /etc/modprobe.d/blacklist-nouveau.conf
echo "options nouveau modeset=0" >> /etc/modprobe.d/blacklist-nouveau.conf
update-initramfs -u

reboot

Después del reinicio, verifica que el driver funciona:

nvidia-smi

Deberías ver tu GPU listada con el uso de VRAM y la versión del driver.

Paso 3: Instalar NVIDIA Container Toolkit

Este paquete permite que los contenedores Docker accedan a la GPU:

# Agregar el repositorio de NVIDIA
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \
  gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

apt update
apt install -y nvidia-container-toolkit

# Configurar Docker para usar NVIDIA
nvidia-ctk runtime configure --runtime=docker
systemctl restart docker

Paso 4: Crear el docker-compose.yml

Crea un directorio de trabajo y el archivo de configuración:

mkdir -p ~/ollama
cd ~/ollama
nano docker-compose.yml

Pega el siguiente contenido:

services:
  ollama:
    image: ollama/ollama
    container_name: ollama
    restart: unless-stopped
    ports:
      - "11434:11434"
    volumes:
      - /ruta/a/tu/disco/ollama:/root/.ollama
    environment:
      - OLLAMA_HOST=0.0.0.0
      - OLLAMA_NUM_THREADS=8
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - /opt/open-webui:/app/backend/data
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    depends_on:
      - ollama

Importante: en la línea de volumen de Ollama, sustituye /ruta/a/tu/disco/ollama por la ruta real donde quieres almacenar los modelos. Si tienes un disco secundario montado (recomendado), apunta ahí. Los modelos pueden ocupar desde 4 GB hasta 20 GB cada uno.

Paso 5: Levantar los servicios

cd ~/ollama
docker compose up -d

Verifica que ambos contenedores están corriendo:

docker ps

Deberías ver ollama y open-webui en estado Up.

Paso 6: Verificar que Ollama usa la GPU

# Verificar que el contenedor ve la GPU
docker exec -it ollama nvidia-smi

Si ves tu GPU listada, todo está funcionando correctamente.

Paso 7: Descargar tu primer modelo

# Descargar Gemma4:e4b (recomendado para empezar)
docker exec -it ollama ollama pull gemma4:e4b

# Verificar que se descargó
docker exec -it ollama ollama list

Paso 8: Acceder a Open WebUI

Desde cualquier dispositivo en tu red local, abre el navegador y ve a:

http://IP_DE_TU_SERVIDOR:8080

La primera vez te pedirá crear una cuenta de administrador. Es local, no sale a internet. Una vez dentro, selecciona el modelo que descargaste y empieza a chatear.


Modelos recomendados para empezar

Con una GPU de 12 GB de VRAM, estos son los modelos que mejor funcionan:

Para uso general y velocidad máxima

docker exec -it ollama ollama pull gemma4:e4b

El modelo estrella para hardware como el nuestro. Cabe completamente en los 12 GB de VRAM, genera a 73 tokens por segundo (más rápido de lo que puedes leer), soporta imágenes y audio, y tiene thinking mode. Es el punto de partida ideal.

Para razonamiento y código

docker exec -it ollama ollama pull qwen3:14b

Excelente para tareas que requieren más razonamiento: analizar arquitecturas de software, revisar código, resolver problemas complejos. Genera a unos 30 tokens por segundo con buena calidad de respuesta.

Para máxima calidad de respuesta

docker exec -it ollama ollama pull mistral-small3.2:24b

Este modelo de 24B parámetros usa arquitectura MoE (Mixture of Experts), lo que le permite ofrecer la calidad de un modelo grande con un consumo razonable. Ocupa algo más de VRAM y desborda un poco a RAM del sistema, pero la calidad de sus respuestas es notablemente superior para análisis complejos.

Para autocomplete en el editor de código

docker exec -it ollama ollama pull deepcoder:1.5b

Un modelo ultraligero especializado en código. Solo ocupa 2 GB de VRAM y se puede dejar cargado en background para autocomplete en tiempo real desde VS Code o Visual Studio.


Verificar que todo funciona

Para confirmar que un modelo está corriendo en GPU y no en CPU:

docker exec -it ollama ollama ps

En la columna PROCESSOR deberías ver 100% GPU. Si ves CPU, revisa que el NVIDIA Container Toolkit esté instalado y que el docker-compose tenga la sección de GPU correctamente.

También puedes monitorear el uso de GPU en tiempo real mientras el modelo genera:

watch -n 1 nvidia-smi

Acceder desde otros dispositivos de la red

Una vez que el servidor está funcionando, cualquier dispositivo en tu red WiFi o LAN puede usar la IA:

  • Desde el navegador: http://IP_DEL_SERVIDOR:8080 para la interfaz web
  • Desde VS Code: instala la extensión Continue.dev y apunta el modelo a http://IP_DEL_SERVIDOR:11434
  • Desde Visual Studio: instala EntwineLLM y configura la misma URL
  • Desde Claude Code: configura las variables de entorno para apuntar a tu servidor local

Conclusión

Montar un servidor de IA local no es tan complicado como parece, y los beneficios son inmediatos: privacidad total, sin límites de uso y sin costo recurrente. Con una GPU de 12 GB de VRAM como la RTX 3060, puedes correr modelos que compiten de tú a tú con herramientas de pago para tareas cotidianas de desarrollo.

En la próxima publicación de esta serie hago un análisis detallado de los diferentes modelos que probé en este mismo servidor, incluyendo datos reales de velocidad, consumo de VRAM y calidad de respuesta para cada uno.

¿Tienes preguntas sobre algún paso de la instalación o quieres saber si tu hardware es compatible? Déjame un comentario abajo.