system onlinepath: /guias/inteligencia-artificial/ejecutar-modelos-de-ia-localmente-con-ollama/mode: knowledge_baselocal:
Inteligencia artificial · Nivel inicial

Cómo ejecutar modelos de IA localmente con Ollama

Instalarlo y correr un modelo son dos comandos. Lo que separa una prueba de algo utilizable son dos cosas que casi nadie ajusta: el tamaño de modelo que entra en tu placa y la longitud de contexto, que por defecto puede quedar en 4k.

13 min de lectura▣ Actualizada el ◇ Por Underc0de
Respuesta rápida

Ollama permite descargar y ejecutar modelos de lenguaje en tu propia máquina, y corre en macOS, Windows y Linux. Se instala desde el sitio oficial y con ollama run <modelo> ya se puede conversar. Lo que decide si sirve para trabajar son dos ajustes: el tamaño del modelo, limitado por la memoria de video disponible, y la longitud de contexto, que la documentación define como «la cantidad máxima de tokens a los que el modelo tiene acceso en memoria» y que por defecto queda en 4k con menos de 24 GiB de VRAM. Para agentes, programación o búsqueda web, la propia documentación recomienda al menos 64000 tokens. Además expone una API local en el puerto 11434, con compatibilidad parcial con la API de OpenAI.

Ver índice de contenidos
  1. 01Qué se gana y qué se pierde
  2. 02Instalación
  3. 03Los comandos que se usan
  4. 04Elegir modelo según tu equipo
  5. 05La longitud de contexto
  6. 06La API local
  7. 07Personalizar con Modelfile
  8. 08Para qué sirve de verdad
  9. 09Errores frecuentes
  10. 10Preguntas frecuentes
  11. 11Fuentes

Qué se gana y qué se pierde

Correr un modelo en tu equipo tiene ventajas concretas y un costo concreto, y conviene tener las dos columnas a la vista antes de decidir:

Ventajas y limitaciones de ejecutar modelos localmente
Se ganaSe pierde
Los datos no salen del equipo: no hay nada que aceptar en términos de usoCapacidad: los modelos que entran en una máquina común son más chicos
Sin costo por uso y sin límite de peticionesVelocidad, si no hay placa de video adecuada
Funciona sin conexiónHay que administrarlo: actualizaciones, espacio en disco, memoria
La versión del modelo no cambia bajo tus piesTampoco mejora sola: las mejoras se buscan y se prueban
Se puede experimentar sin miedo a la facturaServir a varias personas a la vez no es viable en un escritorio

La honestidad acá importa porque hay un reflejo instalado: «lo corro local por privacidad». Está bien como criterio, pero incompleto. Si el modelo local hace mal la tarea, el resultado es un sistema privado que no sirve, y eso no es una mejora. La decisión razonable es por tarea, no por principio: clasificar textos, extraer datos estructurados, resumir, traducir y generar embeddings son trabajos donde un modelo local suele alcanzar de sobra.

Instalación

La documentación es escueta a propósito: «Ollama corre en macOS, Windows y Linux» y la descarga sale de ollama.com/download. En macOS y Windows es un instalador con interfaz gráfica; en Linux, el instalador que ofrece el sitio.

Después de instalar, la comprobación de que quedó bien es correr un modelo. La primera vez descarga los pesos, así que tarda:

bash
ollama run gemma4              # descarga si hace falta y abre el chat

# Para entrada de varias líneas, se envuelve con tres comillas
#   >>> """Hola,
#   ... mundo!
#   ... """

# Con modelos multimodales se pasa la ruta de la imagen en el pedido
ollama run gemma4 "¿Qué hay en esta imagen? /ruta/a/imagen.png"
!
Los nombres de modelo cambian seguido

El catálogo de modelos se mueve rápido: los nombres que aparecen en la documentación hoy pueden no ser los recomendados en unos meses. Antes de copiar un nombre de cualquier tutorial, conviene mirar el catálogo oficial en ollama.com/search. Los ejemplos de esta guía usan los nombres que figuran en la documentación al momento de escribirla.

Los comandos que se usan

Son pocos y se aprenden en una tarde. Estos son los de la referencia oficial de línea de comandos:

Comandos de Ollama y qué hace cada uno
ComandoQué hace
ollama run <modelo>Ejecuta un modelo y abre el chat interactivo
ollama pull <modelo>Descarga un modelo sin ejecutarlo
ollama lsLista los modelos que tenés descargados
ollama psLista los modelos en ejecución. Es el que muestra si el modelo está en placa o en procesador
ollama stop <modelo>Detiene un modelo en ejecución y libera la memoria
ollama rm <modelo>Borra un modelo del disco
ollama create -f ModelfileCrea un modelo propio a partir de un archivo de configuración
ollama serveArranca el servicio. Con --help lista las variables de entorno disponibles
ollama launchConfigura y arranca aplicaciones externas para que usen tus modelos

Dos merecen atención especial. ollama ps es el comando de diagnóstico más útil que tiene: muestra bajo la columna de procesador si el modelo está corriendo en la placa de video o si se descargó parcialmente al procesador, que es la causa número uno de «anda lentísimo». Y ollama launch conecta herramientas externas —hay integraciones documentadas con asistentes de programación y editores— para que usen el modelo local en lugar de uno remoto.

Elegir modelo según tu equipo

Cómo decidir y configurar la ejecución local de modelos con Ollama. A la izquierda, la comparación entre local y remoto: local gana en que los datos no salen del equipo, sin costo por uso, funciona sin conexión y la versión no cambia sola; pierde en capacidad del modelo, velocidad sin placa adecuada, administración a cargo de uno y en que no sirve para atender muchas peticiones simultáneas. Al centro, los comandos de la referencia oficial: run para ejecutar y abrir el chat, pull para descargar sin ejecutar, ls para listar lo descargado, ps para ver lo que está corriendo y si está en placa o en procesador, stop para detener y liberar memoria, rm para borrar del disco, create con un Modelfile para armar un modelo propio, serve para arrancar el servicio y launch para conectar aplicaciones externas. A la derecha, los dos ajustes que deciden si sirve para trabajar. Primero el soporte de hardware: Nvidia con capacidad de cómputo 5.0 o superior y controlador 550 o más nuevo, con la salvedad de que las de capacidad 5.0 a 6.2 requieren el 570; AMD por medio de ROCm, que en Linux pide el controlador ROCm v7, con soporte adicional por Vulkan; y sin placa funciona en procesador, más lento. Segundo, la longitud de contexto, definida como la cantidad máxima de tokens a los que el modelo tiene acceso en memoria, con los valores por defecto que fija Ollama según la memoria de video: menos de 24 GiB usan 4k, entre 24 y 48 GiB usan 32k, y 48 GiB o más usan 256k; y la recomendación de la documentación de usar al menos 64000 tokens para búsqueda web, agentes y herramientas de programación, ajustable con la variable de entorno OLLAMA_CONTEXT_LENGTH al arrancar el servicio. Al pie, la API local en el puerto 11434, con la ruta api para la API propia y la ruta v1 para la compatibilidad parcial con la API de OpenAI, donde la clave es requerida pero ignorada.
La memoria de video es el límite real. Todo lo demás se ajusta alrededor de ese número.

La documentación de soporte de hardware es específica. En Nvidia, Ollama soporta placas con capacidad de cómputo 5.0 o superior y controlador 550 o más nuevo, con una salvedad: las de capacidad 5.0 a 6.2 requieren el controlador 570 o posterior. En AMD funciona por medio de ROCm —en Linux hace falta el controlador ROCm v7— y hay soporte adicional a través de Vulkan. Sin placa compatible, corre en el procesador: funciona, con paciencia.

Pero el número que gobierna todo no es el modelo de placa: es la memoria de video disponible, porque de ella dependen dos cosas a la vez —el tamaño del modelo que entra y el contexto que se le puede dar—. Y las dos compiten por el mismo espacio.

De ahí el criterio práctico para elegir: empezar por un modelo chico que entre con holgura y subir, no al revés. Un modelo más grande que apenas entra queda parcialmente en el procesador y termina siendo más lento y peor que uno más chico que corre entero en la placa. Si ollama ps muestra reparto entre placa y procesador, ese es el diagnóstico.

La longitud de contexto

Este es el ajuste que explica la mayoría de las decepciones con modelos locales, y casi nadie lo toca. La documentación lo define así: la longitud de contexto es «la cantidad máxima de tokens a los que el modelo tiene acceso en memoria». Y fija valores por defecto según la memoria de video:

Longitud de contexto que Ollama usa por defecto según la memoria de video
Memoria de videoContexto por defectoQué implica
Menos de 24 GiB4kUna conversación larga o un documento mediano no entran
Entre 24 y 48 GiB32kAlcanza para trabajo normal con documentos
48 GiB o más256kContexto amplio, sin ajustes

Con 4k de contexto —el caso de la mayoría de los equipos— pasa lo previsible: la conversación avanza, lo viejo se descarta y el modelo «se olvida» de lo que se dijo al principio. No es una limitación del modelo, es un valor por defecto conservador para que no se quede sin memoria.

Y la documentación es explícita sobre cuándo no alcanza: «las tareas que requieren contexto grande, como búsqueda web, agentes y herramientas de programación, deberían configurarse en al menos 64000 tokens». Se ajusta al arrancar el servicio:

bash
# Subir el contexto al arrancar el servicio
OLLAMA_CONTEXT_LENGTH=64000 ollama serve

# Verificar dónde quedó el modelo: mirá la columna PROCESSOR.
# Si aparece reparto con CPU, el contexto o el modelo no entran en la placa.
ollama ps

El compromiso está declarado en la propia documentación: «configurar una longitud de contexto mayor va a aumentar la cantidad de memoria requerida». Es un balance de tres variables —tamaño de modelo, contexto y memoria— y hay que elegir dos.

La API local

Acá es donde Ollama deja de ser un juguete de terminal y se vuelve una pieza de infraestructura. Después de instalar, queda una API servida en http://localhost:11434/api:

bash
# API propia de Ollama
curl http://localhost:11434/api/generate -d '{
  "model": "gemma4",
  "prompt": "¿Por qué el cielo es azul?"
}'

Y la función que más ahorra trabajo: compatibilidad parcial con la API de OpenAI, «para ayudar a conectar aplicaciones existentes con Ollama». Se expone en http://localhost:11434/v1/, así que una aplicación ya escrita con ese SDK funciona cambiando dos líneas:

python
from openai import OpenAI

client = OpenAI(
    base_url='http://localhost:11434/v1/',
    api_key='ollama',   # «requerida pero ignorada»
)

respuesta = client.chat.completions.create(
    model='gpt-oss:20b',
    messages=[{'role': 'user', 'content': 'Decí que esto es una prueba'}],
)
print(respuesta.choices[0].message.content)

Esa compatibilidad es lo que permite una estrategia útil: desarrollar y probar contra un modelo local —sin costo, sin límites de peticiones, sin mandar datos afuera— y cambiar la URL base al proveedor remoto solo cuando la tarea lo justifique. El mismo código, dos destinos.

Personalizar con Modelfile

Para fijar un comportamiento no hace falta entrenar nada. Un Modelfile parte de un modelo existente y le agrega configuración; en su forma mínima son dos líneas:

bash
# Archivo: Modelfile
FROM gemma4
SYSTEM """Sos un asistente que responde solo en español rioplatense,
en un máximo de tres oraciones, y aclara cuando no sabe algo."""

# Después:
ollama create -f Modelfile

Conviene tener claro qué es y qué no: no es entrenamiento ni ajuste fino, es configuración empaquetada con un nombre. Y para la mayoría de los casos en los que se cree necesitar ajuste fino —fijar un rol, un tono, un idioma, un formato de salida— esto alcanza, cuesta un archivo de texto y se puede versionar en el repositorio junto al código que lo usa.

Para qué sirve de verdad

Los casos donde un modelo local es la opción correcta, no un compromiso:

  • Datos que no pueden salir. Historias clínicas, documentación interna, código propietario, datos personales de terceros. Es el caso más claro y el que justifica cualquier pérdida de capacidad.
  • Generar embeddings para un sistema RAG. Es una tarea donde los modelos chicos rinden bien, y es la que más contenido procesa: indexar mil documentos con un proveedor externo significa mandarle mil documentos.
  • Trabajo de volumen y bajo criterio. Clasificar, etiquetar, extraer campos, normalizar texto. Sin costo por llamada, procesar cien mil registros deja de ser una decisión de presupuesto.
  • Desarrollar y probar. Iterar sobre un prompt o un conjunto de evaluación contra un modelo local no consume cuota ni factura.
  • Aprender cómo funcionan. Ver el efecto del contexto, de la temperatura y del tamaño del modelo en tu propia máquina enseña más que leerlo.

Errores frecuentes

  • Dejar el contexto por defecto. Con menos de 24 GiB de memoria de video son 4k, y ahí «se olvida» de todo.
  • Elegir el modelo más grande que «entra». Si queda repartido con el procesador, uno más chico va a andar mejor.
  • No mirar ollama ps. Es el comando que responde por qué está lento, en una línea.
  • Copiar nombres de modelo de tutoriales viejos. El catálogo cambia rápido; conviene mirar el oficial.
  • Esperar la calidad de un modelo grande remoto. En razonamiento largo y tareas difíciles la diferencia es real y se nota.
  • Exponer el puerto a la red sin pensarlo. Es una API sin autenticación por defecto: quien la alcance, la usa.
  • Olvidarse del disco. Cada modelo pesa varios gigabytes y se acumulan; ollama ls y ollama rm son parte del mantenimiento.
  • Usarlo por privacidad sin medir si sirve. Un sistema privado que responde mal no es una mejora.

Preguntas frecuentes

¿Qué se gana y qué se pierde ejecutando un modelo localmente?

Se gana que los datos no salen del equipo, que no hay costo por uso ni límite de peticiones, que funciona sin conexión y que la versión del modelo no cambia bajo tus pies. Se pierde capacidad: los modelos que corren en una máquina común son bastante más chicos que los más grandes disponibles por API, y la diferencia se nota en razonamiento largo, en tareas difíciles y en idiomas con menos material. La decisión honesta es por tarea: para clasificar, extraer datos, resumir y generar embeddings, un modelo local suele alcanzar.

¿Qué placa de video hace falta?

No hace falta ninguna para empezar: Ollama corre en procesador, más lento. Si hay placa, la documentación indica que soporta placas Nvidia con capacidad de cómputo 5.0 o superior y controlador 550 o más nuevo, con la aclaración de que las de capacidad 5.0 a 6.2 requieren el 570 o posterior. En AMD funciona por medio de ROCm, que en Linux exige el controlador ROCm v7, y hay soporte adicional por Vulkan. Lo que más importa en la práctica no es el modelo de placa sino la memoria de video disponible, porque de ella dependen el tamaño de modelo y el contexto que entran.

¿Por qué el modelo local se olvida de lo que le dije?

Casi siempre por la longitud de contexto, que es «la cantidad máxima de tokens a los que el modelo tiene acceso en memoria». Ollama la fija por defecto según la memoria de video: menos de 24 GiB usan 4k, entre 24 y 48 GiB usan 32k, y 48 GiB o más usan 256k. Con 4k de contexto, una conversación larga o un documento mediano no entran, y lo viejo se descarta. La documentación recomienda al menos 64000 tokens para tareas de contexto grande como búsqueda web, agentes y herramientas de programación.

¿Se puede usar Ollama desde una aplicación propia?

Sí, expone una API local. Por defecto queda servida en http://localhost:11434/api, con un endpoint de generación al que se le manda el modelo y el prompt. Además ofrece compatibilidad con parte de la API de OpenAI en http://localhost:11434/v1/, de modo que una aplicación escrita con el SDK de OpenAI funciona cambiando la URL base y poniendo cualquier valor como clave, porque es «requerida pero ignorada». Eso permite probar local sin reescribir código.

¿Cómo se personaliza un modelo sin reentrenarlo?

Con un archivo Modelfile, que parte de un modelo existente y le agrega configuración. En su forma mínima son dos líneas: una que indica el modelo base y otra con el mensaje de sistema que define el comportamiento. Después se ejecuta el comando de creación y queda un modelo propio con ese nombre, que se usa como cualquier otro. No es entrenamiento ni ajuste fino: es configuración empaquetada, y alcanza para la mayoría de los casos donde solo se quiere fijar un rol, un tono o un formato de salida.

¿Para qué no conviene un modelo local?

Para tareas donde la capacidad del modelo es el factor limitante: razonamiento largo con muchos pasos, problemas difíciles de programación, análisis que requieren conocimiento amplio y preciso. También para servir muchas peticiones simultáneas desde un equipo de escritorio, porque la memoria de video no da para varias instancias. Y conviene desconfiar del reflejo de correr todo local por privacidad: si la tarea la hace mal, el resultado es un sistema privado que no sirve, y eso no es una mejora.

Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.

Aportes de la comunidad Underc0de

  1. Underc0de, blog. Malware en Hugging Face suplanta modelo de OpenAI, 12 de mayo de 2026. Los pesos de un modelo se descargan de un registro público: aplican los mismos cuidados que con cualquier dependencia.
  2. Underc0de, foro. Sección GNU/Linux. Material de la comunidad sobre controladores, servicios y diagnóstico en Linux.

Documentación oficial

  1. Ollama. CLI Reference. Todos los comandos y la sintaxis del Modelfile usados en esta guía.
  2. Ollama. Context length. La definición de longitud de contexto, los valores por defecto según memoria de video y la recomendación de 64000 tokens, citadas textualmente.
  3. Ollama. Hardware support. Requisitos de capacidad de cómputo y controladores para Nvidia y AMD.
  4. Ollama. OpenAI compatibility. La ruta de compatibilidad y el detalle de la clave «requerida pero ignorada».
  5. Ollama. API introduction. La dirección y el puerto de la API local.