Cómo verificar si un LLM local utiliza los archivos de modelo y la ruta de almacenamiento correctos

Lauren Pan

IceWhale author

Lauren Pan es el fundador de ZimaSpace y el arquitecto detrás de la aclamada serie ZimaBoard. Combinando diseño industrial con ingeniería embebida, Lauren lanzó ZimaSpace con una misión clara: democratizar la computación en la nube personal. Él opera bajo la creencia de que el hardware debe ser tanto "hackeable" como hermoso—cerrando la brecha entre servidores de grado industrial y dispositivos de consumo. Hoy, lidera el equipo de ingeniería en la creación de herramientas que brindan a los creadores control total sobre sus vidas digitales.

How to Check If a Local LLM Uses the Right Model Files and Storage Path - Zima Store Online

Un LLM local puede responder a un prompt y aún así estar usando la ruta de modelo incorrecta. La interfaz de la aplicación puede mostrar el nombre del modelo que espera, pero el tiempo de ejecución puede estar leyendo una caché antigua, un directorio interno de Docker, una carpeta de modelo predeterminada o un archivo que se descargó nuevamente en otro lugar.

La verificación más segura no es un solo comando. Es una cadena de pruebas corta: compare la carpeta del host, el montaje del contenedor, la lista de modelos del tiempo de ejecución, los metadatos del modelo, el estado activo en memoria, los registros y el crecimiento real del almacenamiento. Cuando esas capas coinciden, puede estar mucho más seguro de que el LLM está usando los archivos de modelo y la ruta de almacenamiento correctos.

La carpeta que ves no siempre es la ruta que usa el tiempo de ejecución

El primer error es confiar demasiado pronto en la ruta del administrador de archivos. Una carpeta NAS puede contener el modelo que descargó, pero eso no prueba que el tiempo de ejecución local del LLM pueda verlo o esté cargando desde allí.

Docker añade otra capa. Una ruta del host como /mnt/storage/ai/models puede estar mapeada a una ruta del contenedor como /root/.ollama, y el ejecutor del modelo solo ve la ruta del contenedor. La documentación de montaje de enlaces de Docker explica que source es la ruta del lado del host y destination o target es la ruta dentro del contenedor, por lo que ambas deben verificarse juntas a través de los montajes de enlace de Docker.

La pregunta práctica sobre la ruta es simple: no pregunte solo dónde colocó el modelo. Pregunte qué ruta ve el tiempo de ejecución y a qué carpeta del host apunta realmente esa ruta del contenedor.

Comience con la lista de modelos del tiempo de ejecución

Antes de revisar cada carpeta, pregunte a la lista de modelos en tiempo de ejecución qué sabe. Para Ollama, comience con:

ollama list

Dentro de un contenedor Docker, use la misma verificación en tiempo de ejecución desde dentro del límite del servicio:

docker exec -it ollama ollama list

Este registro en tiempo de ejecución confirma que el tiempo de ejecución ha registrado una etiqueta de modelo, pero no prueba completamente que la ruta del archivo, la cuantización o la ubicación de almacenamiento sean correctas. La referencia de la CLI de Ollama lista ollama ps para ejecutar modelos, mientras que las preguntas frecuentes explican el directorio de almacenamiento de modelos y la variable de entorno OLLAMA_MODELS en su guía del directorio de almacenamiento de modelos.

Usa este paso como el primer punto de control, no como la respuesta final. Si el modelo esperado no aparece aquí, la aplicación puede estar apuntando a un entorno de ejecución diferente, el modelo puede no haberse importado o el directorio configurado para el modelo puede no ser el directorio que el servicio está usando.

Haz coincidir la ruta del host con la ruta del contenedor

Para despliegues con Docker, la pregunta más importante es si la ruta del host y la ruta del contenedor realmente coinciden. Ejecuta:

docker inspect <nombre-del-contenedor>

Luego mira la sección de montajes. El Source debería apuntar a la carpeta de almacenamiento NAS que pretendías usar, y el Destination debería apuntar al directorio del modelo usado dentro del contenedor. El comando inspect de Docker devuelve información de bajo nivel del objeto, lo que hace que docker inspect Mounts sea una fuente de verdad mejor que la memoria o capturas de pantalla.

Un buen mapeo de montaje Docker debería hacer obvia la relación de almacenamiento:

Capa	Ejemplo	Qué significa
Origen del host	`/mnt/storage/ai/ollama`	La carpeta real del NAS que almacena los datos del modelo
Destino del contenedor	`/root/.ollama`	La ruta que el ejecutor del modelo ve dentro de Docker
Comportamiento en tiempo de ejecución	Ollama lee `/root/.ollama`	Los archivos deberían crecer en la carpeta de origen del host

Si la ruta de origen apunta a la raíz de Docker, una ruta temporal, una carpeta antigua o un volumen pequeño del sistema, el modelo puede funcionar pero estar llenando la unidad incorrecta.

Verifica los archivos reales del modelo, no solo el nombre del modelo

Un nombre de modelo no es lo mismo que un archivo de modelo verificado. El mismo nombre puede apuntar a diferentes etiquetas, formatos, niveles de cuantización, adaptadores o blobs en caché dependiendo del entorno de ejecución.

Para Ollama, inspecciona los metadatos del modelo con:

ollama show <nombre-del-modelo> --modelfile

Dentro de Docker, ejecuta la misma verificación del archivo de modelo a través del contenedor:

docker exec -it ollama ollama show <nombre-del-modelo> --modelfile

Los metadatos del archivo de modelo Ollama son importantes aquí. La documentación del archivo de modelo de Ollama explica que ollama show --modelfile puede revelar la configuración del modelo, incluyendo la fuente FROM detrás del modelo. Para archivos .gguf descargados manualmente, la documentación de cuantización de llama.cpp muestra GGUF y formatos como Q4_K_M, por lo que los metadatos del archivo de modelo GGUF son parte de la verificación, no solo de la optimización del rendimiento.

Los registros te dicen qué ruta se cargó realmente

Cuando la interfaz y las rutas de archivo no coinciden, los registros suelen ser la evidencia más clara. Pueden mostrar rutas de inicio, lecturas fallidas, errores de permisos, archivos faltantes, descargas de modelos y comportamiento de respaldo.

Para Docker, usa esta verificación de registro del contenedor:

docker logs <nombre-del-contenedor>

La documentación de registro de Docker explica que los registros del contenedor suelen exponer la salida del proceso del contenedor desde STDOUT y STDERR, mientras que la página de solución de problemas de Ollama señala que los registros de Ollama en contenedores pueden verse con docker logs.

Busca pistas de ruta como OLLAMA_MODELS, mensajes de descarga del modelo, errores de carga fallida, errores de permisos o directorios que no coincidan con tu carpeta de almacenamiento prevista. Si los registros mencionan un directorio diferente al que mapeaste, confía en los registros y corrige la ruta.

Confirma que el modelo está activo en memoria

La siguiente verificación es el estado del modelo activo. Un modelo puede estar instalado o registrado pero no cargado actualmente. Después de enviar un prompt corto, ejecuta inmediatamente:

ollama ps

Dentro de Docker, ejecuta la misma verificación de modelo activo dentro del contenedor:

docker exec -it ollama ollama ps

Qué `ollama ps` Puede probar

ollama ps muestra qué modelos están cargados actualmente. Las preguntas frecuentes de Ollama explican que la columna Processor puede mostrar si un modelo está cargado en CPU, GPU o dividido entre CPU y GPU, lo que ayuda a confirmar el estado de ejecución activo en lugar de solo la biblioteca de modelos.

Esto es útil cuando necesitas saber si el modelo esperado está activo ahora, si permanece en memoria y si está usando el camino del procesador esperado. Es especialmente útil después de cambiar modelos, modificar etiquetas o probar el comportamiento de GPU/CPU.

Lo que no puede probar

ollama ps no prueba por sí mismo el mapeo de la carpeta host. Puede mostrar que un modelo está activo, pero aún necesitas docker inspect, metadatos del modelo, registros y verificaciones de crecimiento de almacenamiento para demostrar que proviene del camino previsto.

Tampoco prueba que un archivo de modelo personalizado tenga la cuantización o fuente exacta que esperabas. Para eso, usa verificaciones de metadatos, inspección del archivo de modelo y verificación a nivel de archivo.

Señales de advertencia de que el camino del modelo es incorrecto

Un camino de modelo incorrecto suele mostrar síntomas antes de volverse obvio. La señal más común es un crecimiento inexplicable del disco en la unidad de arranque, la raíz de Docker o un volumen de datos de la aplicación que no pretendías usar.

Atento a estas señales de desajuste de ruta:

La app muestra el modelo, pero la carpeta de modelo prevista no crece.
docker inspect muestra una ruta de Origen diferente a la carpeta de almacenamiento NAS.
El modelo se descarga de nuevo después de que pensabas que ya estaba presente.
Los registros mencionan un directorio de modelo predeterminado en lugar de tu ruta personalizada.
ollama list muestra una etiqueta o tamaño diferente al esperado.
ollama show --modelfile apunta a una base o blob diferente a la esperada.
ollama ps muestra un modelo activo inesperado después de un prompt.
La unidad de arranque pierde espacio después de cada descarga de modelo.

Si dos capas de verificación no coinciden, simplifica la prueba. Detén el contenedor, verifica el montaje, reinicia el servicio, descarga un modelo pequeño conocido y revisa qué directorio crece.

Un orden de verificación más limpio para el almacenamiento local de LLM

Usa un orden de verificación fijo en lugar de revisar carpetas al azar. Esto evita confundir rutas del host, rutas del contenedor, rutas de la app y rutas del runtime.

Confirma la carpeta de almacenamiento del host prevista.
Verifica el espacio libre en la unidad del sistema y en la unidad del modelo.
Ejecuta docker inspect <nombre-del-contenedor> y verifica Origen / Destino.
Revisa la lista de modelos en runtime con ollama list.
Descarga o importa un modelo pequeño conocido.
Ejecuta du -sh <carpeta-del-modelo> antes y después de la descarga.
Inspecciona los metadatos con ollama show <nombre-del-modelo> --modelfile.
Envía un prompt corto.
Ejecuta ollama ps para confirmar el modelo activo.
Lee los registros del contenedor o servicio para pistas sobre rutas, descargas o permisos.

Una verificación de almacenamiento limpia debería terminar con todas las capas apuntando al mismo lugar: la carpeta del modelo crece en la unidad esperada, el punto de montaje del contenedor apunta a esa carpeta, el runtime lista el modelo, los metadatos coinciden con el archivo esperado, los registros no muestran errores de ruta y el modelo activo es el que acabas de probar.

Lo que muestra la búsqueda AI de ZimaOS sobre las rutas visibles del modelo

Una función AI local controlada debería hacer visible su ruta del modelo, estado de descarga, uso de recursos y registros lo suficiente para verificarlo. De lo contrario, los usuarios quedan con la duda de si el servicio AI realmente está usando los archivos de modelo esperados.

ZimaOS-AI es un ejemplo útil. La guía de ZimaSpace para la búsqueda AI explica que el módulo AI usa un LLM local para extraer características de imágenes, audio y video para la búsqueda en ZimaOS. La misma nota breve indica que los archivos del modelo se almacenan en /media/ZimaOS-HD/AppData/.models, y si AppData ha sido migrado, el uso real del almacenamiento sigue la ubicación migrada de AppData.

La guía también describe verificaciones de operación como descargas automáticas de modelos, intervalos de extracción de características, historial de llamadas, verificaciones de tráfico de red y journalctl -xef -u zimaos-ai para solución de problemas. Esos son exactamente los tipos de señales que una carga de trabajo de IA local necesita: ruta visible, comportamiento visible de descarga, registros visibles y estado visible en tiempo de ejecución.

Para una configuración de nube privada como ZimaCube 2, esta es la lección principal: la IA local no debe ser una caja negra. Ya sea que la carga de trabajo sea búsqueda, chat, incrustaciones o análisis de medios, la ruta del modelo y el estado en tiempo de ejecución deben ser fáciles de verificar.

Preguntas frecuentes

¿Cómo sé dónde Ollama almacena los archivos del modelo?

Revisa el directorio de modelos predeterminado de Ollama para tu sistema operativo, luego verifica si OLLAMA_MODELS lo ha cambiado. En Docker, también inspecciona el montaje del contenedor para saber qué carpeta del host se asigna al directorio de modelos en tiempo de ejecución.

¿Cómo verifico si Docker está usando la carpeta correcta del modelo?

Ejecuta docker inspect <nombre-del-contenedor> y revisa la sección Mounts. La Fuente debe ser la ruta de almacenamiento NAS que pretendías, y el Destino debe ser el directorio del modelo usado dentro del contenedor.

¿Qué son `manifiestos` y `blobs` ¿en un directorio de modelos Ollama?

En un directorio de modelos estilo Ollama, los manifiestos describen los metadatos y referencias del modelo, mientras que los blobs contienen los archivos de carga útil más grandes del modelo. Si la carpeta blobs crece después de descargar un modelo, es una señal clara de que este directorio se está usando para el almacenamiento del modelo.

¿Cómo puedo saber qué modelo está cargado actualmente?

Envía un prompt corto y luego ejecuta ollama ps. Muestra el modelo cargado actualmente y el estado del procesador, lo que ayuda a confirmar si el modelo esperado está activo en CPU, GPU o en una división CPU/GPU.

¿Por qué la aplicación muestra el modelo pero la ruta del archivo parece incorrecta?

La aplicación puede estar leyendo un registro en tiempo de ejecución, un modelo en caché, una ruta interna de Docker o un directorio de modelos diferente al que estás verificando en el administrador de archivos. Verifica la lista de tiempo de ejecución, el montaje de Docker, los metadatos, los registros y el crecimiento real del almacenamiento antes de confiar en la interfaz.

La verificación de la ruta local de LLM se completa solo cuando la ruta de almacenamiento del host, el destino del contenedor, la lista de modelos en tiempo de ejecución, los metadatos del modelo, el estado activo de la memoria, los registros y el crecimiento del disco coinciden. Si una capa apunta a otro lugar, corrige la ruta antes de descargar más modelos o conectar más aplicaciones.