Come verificare se un LLM locale utilizza i file modello e il percorso di archiviazione corretti

Un LLM locale può rispondere a un prompt e comunque usare il percorso modello sbagliato. L'interfaccia dell'app può mostrare il nome del modello che ti aspetti, ma il runtime potrebbe leggere una cache vecchia, una directory interna a Docker, una cartella modello predefinita o un file che è stato scaricato di nuovo altrove.

Il controllo più sicuro non è un singolo comando. È una breve catena di prove: confronta la cartella host, il mount del contenitore, la lista dei modelli del runtime, i metadati del modello, lo stato attivo in memoria, i log e la crescita effettiva dello storage. Quando questi livelli concordano, puoi essere molto più sicuro che l'LLM stia usando i file modello e il percorso di archiviazione corretti.

La cartella che vedi non è sempre il percorso che il runtime usa

Il primo errore è fidarsi troppo presto del percorso del file manager. Una cartella NAS può contenere il modello che hai scaricato, ma questo non prova che il runtime LLM locale possa vederlo o lo stia caricando da lì.

Docker aggiunge un altro livello. Un percorso host come /mnt/storage/ai/models può essere mappato a un percorso del contenitore come /root/.ollama, e il runner del modello vede solo il percorso del contenitore. La documentazione sui bind mount di Docker spiega che source è il percorso lato host e destination o target è il percorso all'interno del contenitore, quindi i due devono essere controllati insieme tramite i bind mount di Docker.

La domanda pratica sul percorso è semplice: non chiedere solo dove hai messo il modello. Chiedi quale percorso vede il runtime e a quale cartella host quel percorso del contenitore punta effettivamente.

Inizia con la lista dei modelli del runtime

Prima di controllare ogni cartella, chiedi alla lista dei modelli di runtime cosa conosce. Per Ollama, inizia con:

ollama list

All'interno di un contenitore Docker, usa lo stesso controllo di runtime dall'interno del confine del servizio:

docker exec -it ollama ollama list

Questo registro di runtime conferma che il runtime ha registrato un tag modello, ma non prova completamente che il percorso del file, la quantizzazione o la posizione di archiviazione siano corretti. Il riferimento CLI di Ollama elenca ollama ps per l'esecuzione dei modelli, mentre le FAQ spiegano la directory di archiviazione del modello e la variabile d'ambiente OLLAMA_MODELS nella sua guida directory di archiviazione del modello.

Usa questo passaggio come primo punto di controllo, non come risposta finale. Se il modello previsto non appare qui, l'app potrebbe puntare a un runtime diverso, il modello potrebbe non essere stato importato o la directory modello configurata potrebbe non essere quella che il servizio sta usando.

Abbina il percorso host al percorso container

Per le distribuzioni Docker, la domanda più importante è se il percorso host e il percorso container corrispondono effettivamente. Esegui:

docker inspect <nome-container>

Poi guarda la sezione Mounts. Il Source dovrebbe puntare alla cartella di archiviazione NAS che intendevi usare, e il Destination dovrebbe puntare alla directory del modello usata all'interno del container. Il comando inspect di Docker restituisce informazioni a basso livello sugli oggetti, il che rende docker inspect Mounts una fonte di verità migliore rispetto alla memoria o agli screenshot.

Una buona mappatura mount di Docker dovrebbe rendere ovvia la relazione di archiviazione:

Se il percorso sorgente punta alla root di Docker, a un percorso temporaneo, a una cartella vecchia o a un piccolo volume di sistema, il modello potrebbe comunque funzionare ma riempire il drive sbagliato.

Controlla i file modello effettivi, non solo il nome del modello

Un nome modello non è lo stesso di un file modello verificato. Lo stesso nome può indicare tag, formati, livelli di quantizzazione, adattatori o blob memorizzati nella cache diversi a seconda del runtime.

Per Ollama, ispeziona i metadati del modello con:

ollama show <nome-modello> --modelfile

All'interno di Docker, esegui lo stesso controllo Modelfile tramite il container:

docker exec -it ollama ollama show <nome-modello> --modelfile

I metadati del Modelfile di Ollama sono importanti qui. La documentazione del Modelfile di Ollama spiega che ollama show --modelfile può rivelare la configurazione del modello, incluso il FROM sorgente dietro il modello. Per i file .gguf scaricati manualmente, la documentazione sulla quantizzazione di llama.cpp mostra GGUF e formati come Q4_K_M, quindi i metadati del file modello GGUF fanno parte della verifica, non solo della regolazione delle prestazioni.

I Log Ti Dicono Quale Percorso è Stato Veramente Caricato

Quando l'interfaccia utente e i percorsi dei file non coincidono, i log sono spesso la prova più chiara. Possono mostrare percorsi di avvio, letture fallite, errori di permessi, file mancanti, download del modello e comportamenti di fallback.

Per Docker, usa questo controllo del log del container:

docker logs <nome-container>

La documentazione sul logging di Docker spiega che i log del container di solito espongono l'output del processo container da STDOUT e STDERR, mentre la pagina di troubleshooting di Ollama nota che i log di Ollama containerizzati possono essere visualizzati con docker logs.

Cerca indizi sul percorso come OLLAMA_MODELS, messaggi di download del modello, errori di caricamento fallito, errori di permessi o directory che non corrispondono alla cartella di storage prevista. Se i log menzionano una directory diversa da quella mappata, fidati dei log e correggi il percorso.

Conferma che il Modello è Attivo in Memoria

Il controllo successivo è lo stato del modello attivo. Un modello può essere installato o registrato ma non caricato attualmente. Dopo aver inviato un prompt breve, esegui immediatamente:

ollama ps

All'interno di Docker, esegui lo stesso controllo del modello attivo dentro il container:

docker exec -it ollama ollama ps

Cosa ollama ps Può Dimostrare

ollama ps mostra quali modelli sono attualmente caricati. La FAQ di Ollama spiega che la colonna Processor può mostrare se un modello è caricato su CPU, GPU o diviso tra CPU e GPU, il che aiuta a confermare lo stato di runtime attivo piuttosto che solo la libreria dei modelli.

Questo è utile quando devi sapere se il modello previsto è attivo ora, se rimane in memoria e se utilizza il percorso processore previsto. È particolarmente utile dopo aver cambiato modello, modificato tag o testato il comportamento GPU / CPU.

Cosa Non Può Dimostrare

ollama ps da solo non dimostra il mapping della cartella host. Può mostrare che un modello è attivo, ma hai comunque bisogno di docker inspect, metadati del modello, log e controlli della crescita dello storage per dimostrare che proviene dal percorso previsto.

Non dimostra nemmeno che un file modello personalizzato abbia esattamente la quantizzazione o la fonte che ti aspettavi. Per questo, usa controlli dei metadati, ispezione del Modelfile e verifica a livello di file.

Segnali di Avvertimento che il Percorso del Modello è Errato

Un percorso modello errato di solito manifesta sintomi prima che diventi evidente. Il segno più comune è una crescita inspiegabile del disco sull'unità di avvio, sulla root di Docker o su un volume dati di un'app che non intendevi utilizzare.

Fai attenzione a questi segnali di disallineamento percorso:

• L’app mostra il modello, ma la cartella modello prevista non cresce.
• docker inspect mostra un percorso Sorgente diverso dalla cartella di storage NAS.
• Il modello viene scaricato di nuovo dopo che pensavi fosse già presente.
• I log menzionano una directory modello predefinita invece del tuo percorso personalizzato.
• ollama list mostra un tag o una dimensione diversa da quella prevista.
• ollama show --modelfile punta a una base o blob diverso da quello previsto.
• ollama ps mostra un modello attivo inatteso dopo un prompt.
• L’unità di avvio perde spazio dopo ogni pull di modello.

Se due livelli di verifica non concordano, semplifica il test. Ferma il container, verifica il mount, riavvia il servizio, scarica un modello piccolo e noto e controlla quale directory cresce.

Un ordine di verifica più pulito per lo storage LLM locale

Usa un ordine di verifica fisso invece di controllare cartelle a caso. Questo ti evita di confondere percorsi host, percorsi container, percorsi app e percorsi runtime.

1. Conferma la cartella di storage host prevista.
2. Controlla lo spazio libero sull’unità di sistema e sull’unità del modello.
3. Esegui docker inspect <nome-container> e verifica Sorgente / Destinazione.
4. Controlla la lista dei modelli runtime con ollama list.
5. Scarica o importa un modello piccolo e noto.
6. Esegui du -sh <cartella-modello> prima e dopo il pull.
7. Ispeziona i metadati con ollama show <nome-modello> --modelfile.
8. Invia un prompt breve.
9. Esegui ollama ps per confermare il modello attivo.
10. Leggi i log del container o del servizio per indizi su percorso, download o permessi.

Una verifica dello storage pulita dovrebbe terminare con tutti i livelli che puntano allo stesso posto: la cartella del modello cresce sull’unità prevista, il mount del container punta a quella cartella, il runtime elenca il modello, i metadati corrispondono al file previsto, i log non mostrano errori di percorso e il modello attivo è quello appena testato.

Cosa mostra ZimaOS AI Search riguardo ai percorsi modello visibili

Una funzione AI locale controllata dovrebbe rendere visibili il percorso del modello, lo stato del download, l’uso delle risorse e i log in modo sufficiente per verificarli. Altrimenti, gli utenti rimangono a chiedersi se il servizio AI stia effettivamente utilizzando i file modello previsti.

ZimaOS-AI è un esempio utile. La guida di ZimaSpace per la ricerca AI spiega che il modulo AI utilizza un LLM locale per estrarre caratteristiche da immagini, audio e video per la ricerca in ZimaOS. La stessa breve nota indica che i file del modello sono memorizzati in /media/ZimaOS-HD/AppData/.models, e se AppData è stato migrato, l’effettivo utilizzo dello spazio segue la posizione migrata di AppData.

La guida descrive anche controlli operativi come download automatici dei modelli, intervalli di estrazione delle funzionalità, Cronologia Chiamate, controlli del traffico di rete e journalctl -xef -u zimaos-ai per la risoluzione dei problemi. Questi sono esattamente i tipi di segnali di cui un carico di lavoro AI locale ha bisogno: percorso visibile, comportamento di download visibile, log visibili e stato runtime visibile.

Per una configurazione cloud privata come ZimaCube 2, questa è la lezione più importante: l'AI locale non dovrebbe essere una scatola nera. Che il carico di lavoro sia ricerca, chat, embedding o analisi media, il percorso del modello e lo stato runtime dovrebbero essere facili da verificare.

FAQ

Come faccio a sapere dove Ollama memorizza i file modello?

Controlla la directory modello predefinita di Ollama per il tuo sistema operativo, poi verifica se OLLAMA_MODELS l'ha modificata. Su Docker, ispeziona anche il mount del contenitore per sapere quale cartella host mappa alla directory modello del runtime.

Come posso verificare se Docker sta usando la cartella modello corretta?

Esegui docker inspect <nome-contenitore> e controlla la sezione Mounts. La Source dovrebbe essere il percorso di archiviazione NAS che intendevi, e la Destination dovrebbe essere la directory modello usata all'interno del contenitore.

Cosa sono manifest e blob in una directory modello Ollama?

In una directory modello in stile Ollama, i manifest descrivono i metadati e i riferimenti del modello, mentre i blob contengono i file payload più grandi del modello. Se la cartella blobs cresce dopo aver scaricato un modello, è un forte segno che questa directory viene utilizzata per l'archiviazione del modello.

Come posso sapere quale modello è attualmente caricato?

Invia un prompt breve, quindi esegui ollama ps. Mostra il modello attualmente caricato e lo stato del processore, il che aiuta a confermare se il modello previsto è attivo su CPU, GPU o una divisione CPU / GPU.

Perché l'app mostra il modello ma il percorso del file sembra ancora errato?

L'app potrebbe leggere un registro runtime, un modello memorizzato nella cache, un percorso interno a Docker o una directory del modello diversa da quella che stai controllando nel file manager. Verifica l'elenco runtime, il mount di Docker, i metadati, i log e la crescita effettiva dello storage prima di fidarti dell'interfaccia utente.

Un controllo del percorso LLM locale è completo solo quando il percorso di archiviazione host, la destinazione del contenitore, l'elenco dei modelli runtime, i metadati del modello, lo stato della memoria attiva, i log e la crescita del disco sono tutti coerenti. Se uno strato punta altrove, correggi il percorso prima di scaricare altri modelli o collegare altre app.