Ejecutando LLMs en local: primeros pasos con Ollama.

Muchas cosas pueden cambiar en esta nueva era de la IA. Cada día vemos nuevas herramientas de IA superando nuevos hitos, y eso que aún estamos en una fase bastante inicial (aunque, si lo pensamos bien, no es una fase tan inicial, puesto que la IA es una disciplina que ya existe desde los años 40-50).

En contraposición, y según hemos visto los últimos años con las plataformas Cloud, parece que otras cosas no cambiarán mucho en el mundo del desarrollo. Esto se debe a que siguen siendo unas pocas (y grandes) multinacionales las que manejan las principales plataformas de IA que usamos la gran mayoría de las personas. Podemos comprobarlo revisando el detalle de la inversión en IA de las principales compañías y las contrataciones relacionadas con la IA.

Evidentemente, esto conducirá a que seamos más o menos dependientes de lo que dicten dichas compañías en cuanto a nuevas funcionalidades de las herramientas, gestión de datos y privacidad o precios de uso. Aunque este modelo siga existiendo (y, evidentemente, aportando sus beneficios), también disponemos de una alternativa menos centralizada: liberar herramientas y modelos de IA.

Al mismo tiempo que esas grandes plataformas de IA han crecido esas grandes plataformas de IA de las corporaciones, han ido proliferando comunidades abiertas de desarrollo. Estas comunidades pretenden que las aplicaciones y recursos de IA se puedan extender al resto del mundo apostando por el opensource y sin necesidad de vincularse a una compañía o tecnología en concreto.

A lo largo de una serie de posts, nos centraremos en algunas de estas últimas plataformas más descentralizadas para ver qué es lo que nos ofrecen, principalmente a los equipos de desarrollo.

Conceptos previos

Aunque este artículo tiene un enfoque más práctico y veremos cómo interactuar con los LLMs de una forma sencilla, en ciertos momentos aparecerán conceptos que es importante conocer de cara a poder comprender qué es lo que estamos haciendo.

A continuación explicamos un par de conceptos desde un alto nivel para entender cómo pueden afectar algunas configuraciones al comportamiento o precisión de las respuestas del LLM.

Funcionamiento de los LLMs

Se sabe que los LLMs (Large Language Model) son modelos de inteligencia artificial basados en redes neuronales y entrenados con aprendizaje automático auto-supervisado sobre una gran cantidad de datos, lo que los hace capaces de comprender y generar lenguaje natural y otros tipos de contenido para realizar una amplia gama de tareas.

Con esta definición nos podemos hacer una idea general de en qué nos pueden ayudar en nuestro día a día. Pero… ¿cómo funcionan realmente por dentro? Muchos de los LLMs modernos están basados en un arquitectura Transformer compuesta por redes neuronales que han sido entrenadas como modelos de lenguaje.

En la arquitectura Transformer, las palabras (inputs) se transforman en representaciones vectoriales o embeddings para, posteriormente, en base a estas y otras posibles entradas adicionales, generar predicciones (palabras) basadas en probabilidades, para resolver la tarea correspondiente (generación de texto, traducción, resúmenes, etc).

La arquitectura Transformer está formada principalmente por dos piezas:

• Encoder: recibe la entrada y crea una representación de la misma (embedding) en base a su contexto. Esta pieza está pensada para “comprender” la entrada.
• Decoder: recibe la representación producida por el encoder, además de otras entradas adicionales, para poder generar una salida (como probabilidades). Esta pieza está pensada para producir resultados.

A un alto nivel, esta arquitectura se basa en el conocimiento estadístico del lenguaje, es decir, las probabilidades de que una palabra aparezca en un texto. Aunque originalmente estaba pensada para tareas de traducción, se puede adaptar para realizar otras tareas de NLP (Natural Language Processing).

Por ejemplo, para resolver una tarea de generación de textos, la arquitectura Transformer procesa las palabras de entrada de forma paralela para predecir cuál es la siguiente palabra en un texto en base a esas entradas y su contexto.

En base a estas probabilidades se selecciona una palabra para, a continuación, realizar el mismo proceso de forma iterativa, añadiendo la nueva palabra generada a la entrada. La palabra producida por el Decoder se vuelve a incluir junto con las nuevas entradas en el Encoder hasta poder producir un texto completo. Evidentemente, en todo este proceso iterativo pueden variar las probabilidades de salida de las palabras en base a múltiples parámetros configurables en el LLM.

Cuantización

La cuantización (quantization en inglés) es el proceso de reducción de la precisión de los pesos de un modelo o red neuronal, transformando números representados en formato de coma flotante (de, por ejemplo, 16 o 32 bits) a números enteros (de, por ejemplo, 4 u 8 bits).

Esta reducción de precisión afecta a los embeddings (cómo se representan las palabras en la arquitectura Transformer vista en el punto anterior). Este proceso, que tiene múltiples formas de implementarse, permite reducir el tamaño del fichero del modelo y la cantidad de memoria RAM necesaria para su ejecución, además de mejorar la velocidad de inferencia, entre otras cosas.

En última instancia, esto permite la ejecución de modelos más grandes sobre los mismos recursos, teniendo en cuenta que esto deriva en una reducción de la calidad o precisión de la salida, siendo a veces imperceptible.

En la siguiente tabla se puede ver un ejemplo de comparativa de modelos cuantizados (tabla original):

* Perplexity se refiere a una métrica para evaluar el desempeño en las predicciones de un modelo. Cuanto menor sea el valor, mejor será el modelo.

La cuantización de modelos es ampliamente usada en escenarios en donde se tienen pocos recursos como pueden ser aplicaciones en móviles, vehículos autónomos, dispositivos iot, drones, etc.

Los mencionados anteriormente puede que sean algunos de los conceptos más relevantes de cara a la interacción básica con las herramientas de ejecución de LLMs o los propios LLMs, pero existen muchos más a tener en cuenta (tokens, prompts, embeddings, RAG…).

Beneficios de ejecutar LLMs en local

En la actualidad, se pueden ver chatbots basados en LLMs/IA en prácticamente cualquier aplicación o página web para ayudarnos en las múltiples tareas que tenemos en nuestro día a día.

En general, las interacciones con estas aplicaciones son sencillas y no conllevan riesgos de seguridad ni privacidad y, aunque en ocasiones algunas de ellas no nos cobren nada por esta utilidad, en el fondo esta ejecución siempre está asociada a un coste (y suele ser un coste bastante alto).

Aunque los factores anteriores en primera instancia no nos suelen preocupar, sí que se deben tener muy en cuenta, especialmente por empresas, puesto que pueden derivar en problemas de facturación y seguridad. Es en estas situaciones en las que mejor encaja la ejecución de LLMs en máquinas controladas por cada usuario/empresa, encontrando algunos beneficios como los siguientes:

• Privacidad y seguridad: todos los datos generados por la interacción con los LLMs se quedan en tu máquina: prompts, documentos enviados al modelo, respuestas del LLM, etc. Es importante revisar en profundidad la documentación de cada herramienta para saber si se recolecta algún dato o no y de qué tipo. Con esto se asegura una completa privacidad y control de los datos, especialmente útil en casos de uso con manejo de datos altamente sensibles como en los sectores de salud o financieros.
• Ahorro en costes y rendimiento: la gran mayoría de herramientas/aplicaciones de chat basadas en LLMs suelen tener asociado un coste por peticiones o suscripciones mensuales. Más allá del hardware necesario para la ejecución de los LLMs, la ejecución de forma local no incurre en costes adicionales. Al mismo tiempo, al no ser necesaria una conexión a internet debido a la ejecución local del LLM, se mejorarán algunas estadísticas de interacción como puede ser la latencia de las respuestas. Es importante tener esto en cuenta en escenarios donde no exista una conexión a internet o la conexión sea lenta.
• Personalización: ciertas herramientas de ejecución de LLMs en local tienen formas de cambiar el comportamiento de los modelos a través de parámetros. También existen opciones de copiar o importar valores (pesos de modelos) de otros modelos ya generados para poder personalizar modelos existentes de una forma sencilla. Esta personalización a través de formatos de ficheros estándar ha creado una gran comunidad compartiendo modelos para múltiples casos de uso.

A lo largo de esta serie de posts veremos algunas de las plataformas/herramientas que nos permiten ejecutar LLMs en nuestro pc de forma local de una forma sencilla y transparente.

Ollama

Ollama es una aplicación que permite ejecutar e interactuar con LLMs de forma local en una máquina sin una necesidad real de tener una conexión a internet. La ejecución sin una conexión a internet se refiere a la interacción directa con los LLMs puesto que, para instalar la propia aplicación de Ollama o tener los modelos con los que interactuar en la máquina, sí que puede ser necesaria una conexión a internet.

Ollama está basada en la librería llama.cpp, aplicando una capa envolvente sobre la misma para facilitar la interacción y gestión de los LLMs, abstrayendo a los equipos de desarrollo/usuarios de muchos conceptos a bajo nivel.

Requisitos de ejecución

Antes de comenzar con el proceso de instalación debemos tener en cuenta los requisitos que necesita nuestro sistema para que la ejecución de Ollama sea fluida. Realmente, estos valores se deben tener en cuenta para la ejecución de los modelos dentro de Ollama, ya que Ollama como tal es un software que no requiere de muchos recursos. Estos requisitos son:

• RAM: suele ser el recurso más importante a tener en cuenta. En este caso, se deberá pensar en qué modelos se van a utilizar de cara a conocer qué valores de RAM son los adecuados:
  • 8GB: sería el mínimo recomendable, pensando en la ejecución de modelos pequeños (1B, 3B, 7B) y sabiendo que puede presentar problemas de fluidez.
  • 16GB: el valor recomendado con el que se podrían ejecutar modelos de 7B y 13B de una forma fluida.
  • 32GB o más: el valor óptimo, especialmente para modelos más grandes (30B, 40B, 70B).
• GPU: es otro de los recursos más importantes puesto que, gracias a las GPUs, se obtienen importantes mejoras en el rendimiento de los modelos. Esto se debe a su capacidad de realizar una gran cantidad de cálculos matemáticos de forma simultánea, acelerando los procesos de entrenamiento e inferencia de los LLMs. Estas opciones necesitarán instalar y configurar los controladores necesarios compatibles con cada sistema operativo para cada GPU. También existen las opciones de aceleración de GPU para Docker para NVIDIA y AMD.
• Disco: el código de Ollama como tal no ocupa más de unos cientos de MB, pero se deberá contar con un considerable espacio de disco dependiendo, una vez más, de los modelos a usar (los modelos con sus pesos están contenidos en ficheros) y teniendo en cuenta que podrán ir cambiando con el tiempo. En general se suele tomar las siguientes referencias:
  • Modelos cuantizados pequeños -> 2GB de espacio libre necesario.
  • Modelos cuantizados medianos -> 5GB de espacio libre necesario.
  • Modelos cuantizados grandes -> 40GB de espacio libre necesario.
  • Modelos muy grandes -> 200GB de espacio libre necesario (existen algunos modelos que incluso ocupan ¡1,3TB de espacio en disco!)
• CPU: con los procesadores modernos no deberíamos tener problemas de ejecución, si bien lo recomendable sería tener mínimo 4 cores y, para una ejecución óptima, 8 cores o más.
• Sistema operativo: con las últimas versiones de los sistemas operativos más extendidos no deberían existir problemas con la instalación y ejecución de Ollama, si bien es cierto que en ocasiones se pueden necesitar ciertas configuraciones adicionales.

Instalación de Ollama

Existen varias formas de ejecutar Ollama en nuestro ordenador dependiendo de nuestro sistema y necesidades:

• Instalar Ollama en local en los sistemas operativos de Windows, Linux y macOS.
• Usar la imagen Docker de Ollama.

En el caso de este post, instalamos Ollama para Linux siguiendo la documentación oficial. Para ello, simplemente descargamos Ollama como se indica en su página oficial con el siguiente comando de terminal:

curl -fsSL https://ollama.com/install.sh | sh

Una vez instalado Ollama en nuestro sistema, es recomendable conocer ciertos aspectos que resultarán útiles de cara a su ejecución:

Almacenamiento de los modelos

Ruta de la carpeta (diferente para cada sistema operativo) donde Ollama guarda los modelos y que es importante tener en cuenta para cuestiones de gestión de espacio en disco y copias de seguridad de los modelos.

En Linux, con la instalación recomendada por defecto, los modelos se encuentran en la ruta /usr/share/ollama/.ollama/models.

Variables de entorno

Permite personalizar la instalación de Ollama. Algunas de estas variables son:

• OLLAMA_HOST: interfaz de red y puerto en el que escucha el servidor API de Ollama. El valor por defecto es 127.0.0.1:11434.
• OLLAMA_MODELS: ruta personalizada en la que guardar los modelos descargados. Es importante que la carpeta exista y tenga los permisos necesarios para que Ollama pueda descargar y leer los modelos.
• OLLAMA_ORIGINS: maneja el CORS para el API de Ollama evitando las llamadas de orígenes distintos. Como es habitual, se puede indicar el valor “*” para permitir todos los orígenes.
• OLLAMA_DEBUG: configurar a 1 para habilitar el modo debug.
• OLLAMA_KEEP_ALIVE: tiempo que se mantiene un modelo cargado en memoria después de la última petición. Por defecto, está en un tiempo cerca de 5 minutos. Indicando el valor 0, eliminaría el modelo de la memoria justo después de su uso y, con un valor -1, lo mantendría cargado indefinidamente.

Es necesario indicar que la forma de configurar estas variables también depende de la instalación de Ollama que realicemos. En el caso de la instalación por defecto para Linux, se deberá sobreescribir el fichero de configuración correspondiente ejecutando los siguientes comandos:

1. Ejecutar el comando:

sudo systemctl edit ollama.service

2. Incluir las líneas con las variables y sus valores en el fichero de configuración:

[Service]
Environment="OLLAMA_MODELS=/path-personalizado"
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_DEBUG=1"
...

3. Guardar los cambios del fichero. El fichero original en Linux se encuentra en la ruta /etc/systemd/system/ollama.service.d.
4. Ejecutar el siguiente comando para aplicar los cambios:

sudo systemctl daemon-reload

5. Ejecutar el siguiente comando para reiniciar el servicio de Ollama:

sudo systemctl restart ollama

Logs de la aplicación

Específico de cada sistema operativo. En Linux (con la ejecución nativa de Ollama) se puede ejecutar el siguiente comando para ver los logs (añadir la opción -f al comando para ver los logs en tiempo real):

sudo journalctl -u ollama

Produciendo una salida como la siguiente:

...
-- Reboot --
date&time user systemd[1]: Started Ollama Service.

date&time user ollama[2598]: ... routes.go:1230: INFO server config env="map[CUDA_VISIBLE_DEVICES: GPU_DEVICE_ORDINAL: HIP_VISIBLE_DEVICES: HSA_OVERRIDE_GFX_VERSION: HTTPS_PROXY: HTTP_PROXY: NO_PROXY: OLLAMA_CONTEXT_LENGTH:2048 OLLAMA_DEBUG:false OLLAMA_FLASH_ATTENTION:false OLLAMA_GPU_OVERHEAD:0 OLLAMA_HOST:http://127.0.0.1:11434 OLLAMA_INTEL_GPU:false OLLAMA_KEEP_ALIVE:5m0s OLLAMA_KV_CACHE_TYPE: OLLAMA_LLM_LIBRARY: OLLAMA_LOAD_TIMEOUT:5m0s OLLAMA_MAX_LOADED_MODELS:0 OLLAMA_MAX_QUEUE:512 OLLAMA_MODELS:/usr/share/ollama/.ollama/models OLLAMA_MULTIUSER_CACHE:false OLLAMA_NEW_ENGINE:false OLLAMA_NOHISTORY:false OLLAMA_NOPRUNE:false OLLAMA_NUM_PARALLEL:0 OLLAMA_ORIGINS:[http://localhost https://localhost http://localhost:* https://localhost:* ...] OLLAMA_SCHED_SPREAD:false ROCR_VISIBLE_DEVICES: http_proxy: https_proxy: no_proxy:]"

date&time user ollama[2598]: time=... level=INFO source=images.go:432 msg="total blobs: 25"

date&time user ollama[2598]: time=... level=INFO source=images.go:439 msg="total unused blobs removed: 0"

date&time user ollama[2598]: time=... level=INFO source=routes.go:1297 msg="Listening on 127.0.0.1:11434 (version 0.6.1)"

date&time user ollama[2598]: time=... level=INFO source=gpu.go:217 msg="looking for compatible GPUs"

date&time user ollama[2598]: time=... level=INFO source=gpu.go:377 msg="no compatible GPUs were discovered"

date&time user ollama[2598]: time=... level=INFO source=types.go:130 msg="inference compute" id=0 library=cpu variant="" compute="" driver=0.0 name="" total="... GiB" available="... GiB"
...

Indicando la opción -n 100 al comando anterior podremos ver las últimas 100 líneas del log. Con las opciones de pipes de terminal de Linux podemos exportar los logs de Ollama a un fichero con el siguiente comando:

sudo journalctl -u ollama.service > ollama_logs.txt

Errores de permisos

En Linux podrían ocurrir errores en la creación o descarga de modelos por no tener permisos de escritura en la carpeta en donde se guardan los modelos.

History file

Fichero del histórico de conversaciones que se tiene con Ollama. Dicho fichero en Linux se puede encontrar en la ruta ~/.ollama/history.

Aceleración de GPU

Cuando se esté ejecutando un modelo, el comando ollama ps indicará, con el valor cpu/gpu, si se está usando la aceleración de GPU o no. Para el caso que atañe a esta sección, el valor a mostrar en la propiedad PROCESSOR debería indicar el valor 100% GPU. El comportamiento del comando ollama ps se detallará en otra sección más adelante.

También se pueden ver errores como CUDA error/ROCm error en las ejecuciones, debiendo revisar, entre otras, las configuraciones de los controladores de cada GPU y sistema operativo. A continuación se muestra la ejecución del comando ollama ps indicando que no se tiene aceleración por GPU:

Comandos básicos de Ollama

Una vez instalado Ollama, se puede interactuar con él y los modelos correspondientes a través de los siguientes comandos.

PULL

Comando para descargar los modelos disponibles en la web de Ollama. Descargará los ficheros necesarios para ejecutar el modelo, actualizándolo en el caso de existir cambios recientes. Un ejemplo del comando es:

ollama pull llama3.2:1b

Dentro de la web de Ollama, en la sección de modelos tenemos distintas etiquetas para poder filtrar los propios modelos por temática:

Dentro de cada modelo se muestran también múltiples etiquetas siguiendo una estructura común:

• Tamaño: indica el número de parámetros con los que fue entrenado ese modelo, afectando al conocimiento y recursos necesarios del propio modelo. La tendencia es, a mayor número de parámetros, mejor funcionamiento. Algunos valores pueden ser: 1b, 3b, 7b, 13b, 32b, 70b, etc.
• Cuantización: como se mencionaba anteriormente, la cuantización reduce el tamaño del modelo para reducir la cantidad de recursos necesarios para ejecutarlo, eso sí, reduciendo también la precisión. Números más bajos (como q4) significan más compresión y, por lo tanto, menos precisión. Las variantes con sufijos K (tipo de cuantización con k-quants; _K_S, _K_M, _K_L; S por small, M por medium y L por large) se pueden considerar como modelos equilibrados entre tamaño y precisión. Las opciones como fp16 o fp32 significa que no están cuantizados o lo están mínimamente, proporcionando mayor precisión pero necesitando más recursos para su ejecución. Algunos valores que se pueden encontrar son: q2_K, q4_K_M, q8_0, fp16, etc.
  • Variantes: se pueden encontrar distintas etiquetas como:
  • instruct: pensado para seguir instrucciones.
  • chat: pensado para conversaciones.
  • code: pensado para tareas de programación.
  • vision: pensado para manejar imágenes y multimodularidad.
• Latest: es el modelo que se descarga por defecto al no indicar ninguna etiqueta. Esta etiqueta no significa que sea el último modelo en salir, sino más bien un modelo usado habitualmente y equilibrado entre la precisión y el uso de recursos (normalmente suele ser un modelo de tamaño mediano y cuantizado).

Es importante mencionar que este etiquetado de modelos puede cambiar o pueden aparecer nuevas etiquetas. Accediendo a la página de cada uno de los modelos, se puede encontrar información relevante que podrá aclarar mejor cuáles son sus características así como, en ocasiones, los benchmarks sobre los que evalúan su rendimiento.

RUN

Comando para ejecutar un modelo y poder interactuar con él:

ollama run llama3.2:1b

En caso de que el modelo no se haya descargado previamente, lo descargará. Cuando termine de cargar el modelo, aparecerá un prompt interactivo para realizar las peticiones al modelo:

Dentro de este prompt interactivo existen distintos comandos especiales:

• /? o /help: muestra el menú de ayuda con el resto de comandos disponibles.

• /set parameter <nombre del parámetro> <valor del parámetro>: modifica el valor de un parámetro en tiempo de ejecución para la sesión interactiva actual.

• /show: proporciona información del modelo cargado como parámetros, contenido del modelfile (fichero de configuración de los modelos), plantilla (instrucción que define el formato del prompt de entrada-interacción con el modelo) o licencia.

• /save <nombre de la sesión>: guarda el historial del chat creando un nuevo modelo.

• /load <nombre de la sesión>: carga una sesión previa.

• /clear: limpia la sesión
• /bye o /exit: salir de la sesión interactiva.

Igualmente, existen otras variantes del comando run, como pueden ser:

• Ejecutar un modelo multimodal indicando un prompt y el path de una imagen:

ollama run llava "What's in this image? ./multimodal.jpg"

• Indicar el prompt como un argumento:

ollama run llama3.2:1b "Summarize this file: $(cat README.md)"

LIST

Comando para listar los modelos descargados:

ollama list

Muestra información como el nombre del modelo, id, tamaño y en disco y la fecha de modificación:

SHOW

Comando que muestra la información detallada de cada modelo:

ollama show gemma3:1b

Expondrá información como la configuración de parámetros, metadatos o los detalles de la plantilla.

RM

Comando para eliminar un modelo de Ollama:

ollama rm gemma3:1b

CP

Comando para copiar un modelo existente, y se puede usar para personalizaciones de modelos. En realidad, el comando no copia el fichero entero sino su referencia, es decir que si, por ejemplo se copia un modelo de 5Gb, no se creará otro modelo con 5Gb, sino que se copiará el fichero de manifiesto que referencia al modelo:

ollama cp llama3.2:1b llama-custom

PS

Comando para ver qué modelos están cargados en memoria, útil también para ver si se está usando la aceleración por GPU en Ollama:

ollama ps

Proporciona información del modelo, id, tamaño, procesador usado (cpu/gpu) y tiempo desde el último acceso.

STOP

Comando para detener la ejecución de un modelo:

ollama stop llama3.2:1b

PUSH

Comando para subir un modelo creado al registry de Ollama.

ollama push llama-custom

El registry de Ollama es un repositorio centralizado para almacenar los modelos que usa la propia herramienta y en la que se pueden publicar los propios modelos. Este registry implica una serie de beneficios como:
Distribución: posibilita publicar y compartir los modelos personalizados con el resto de la comunidad de usuarios, fomentando la colaboración y reutilización.

• Disponibilidad: una vez publicado, el modelo estará disponible para descargar mediante el comando ollama pull sin existir riesgo de perder el modelo por cualquier problema de nuestro pc.
• Versionado y control: permite la creación de tags para llevar un mejor control de las características de cada modelo.

HELP

Comando para conocer cómo usar el resto de comandos de Ollama.

ollama help

SERVE

Comando para iniciar Ollama. Útil en los casos que no se ejecute Ollama como un proceso en segundo plano del sistema.

ollama serve

¿Cómo seleccionar el modelo adecuado?

Como hemos visto en secciones previas, se deben tener en cuenta múltiples consideraciones técnicas para seleccionar el modelo que se quiere/puede usar: recursos disponibles como RAM, disco, CPU, etc. o particularidades de cada modelo: tamaño, cuantización, variantes, etc.

Pero, además de tener en cuenta la parte más técnica, se pueden seleccionar los modelos según las tareas o casos de uso, atendiendo a las siguientes recomendaciones:

• Casos de uso generales o chat: caso de uso de interacción a través de un chat o peticiones generales de información. Algunos modelos pueden ser: llama3.2, mistral, gemma3, qwen3. Dentro de esta categoría también se podrían incluir los modelos de la etiqueta Thinking de la web de Ollama.
• Tareas de codificación: caso de uso para la generación de código para crear aplicaciones software. Los modelos que encajan aquí serían: codellama o deepseek-coder.
• Resumen o análisis de textos: tareas para poder resumir o interpretar textos (análisis de sentimientos, clasificación, etc). A menudo, los modelos con la etiqueta instruct son mejores.
• Tareas multimodales con imágenes: cuando se necesita interactuar con recursos multimedia como imágenes, vídeos, audios, etc. se deberá seleccionar modelos específicos que lo permitan. En la web de Ollama podemos filtrar por la etiqueta Vision para encontrar este tipo de modelos. Algunos modelos disponibles son: llava, moondream o bakllava.

En última instancia es importante leer la documentación y características de cada modelo y realizar pruebas para evaluar cuál es el que mejor se comporta para nuestro caso de uso y dataset disponible.

Conclusiones

En esta introducción a la ejecución de LLMs en local se han podido explorar algunos de los conceptos importantes a tener en cuenta en la ejecución de los LLMs, así como la selección del más adecuado para nuestro caso de uso.

Centrándonos en la parte práctica, se ha podido comprobar lo simple que es interactuar con los modelos a través de Ollama con sus distintos comandos.

En el siguiente artículo se expondrán opciones más avanzadas de Ollama, incluyendo la personalización de los modelos.

Referencias

• Documentación oficial de Ollama
• Curso de Ollama de Matt Williams
• Tutoriales de New Machina
• Curso LLM Hugging Face