Jak sprawdzić, czy lokalny LLM używa właściwych plików modelu i ścieżki przechowywania

Lokalny LLM może odpowiedzieć na zapytanie, a mimo to używać niewłaściwej ścieżki modelu. Interfejs aplikacji może pokazywać oczekiwaną nazwę modelu, ale środowisko uruchomieniowe może czytać stary cache, katalog wewnętrzny Dockera, domyślny folder modelu lub plik pobrany ponownie gdzie indziej.

Najbezpieczniejsza kontrola to nie jedno polecenie. To krótki łańcuch dowodowy: porównaj folder hosta, montowanie kontenera, listę modeli środowiska uruchomieniowego, metadane modelu, aktywny stan pamięci, logi i faktyczny wzrost przechowywania. Gdy te warstwy się zgadzają, możesz być znacznie pewniejszy, że LLM używa właściwych plików modelu i ścieżki przechowywania.

Folder, który widzisz, nie zawsze jest ścieżką używaną przez środowisko uruchomieniowe

Pierwszym błędem jest zbyt wczesne zaufanie ścieżce menedżera plików. Folder NAS może zawierać pobrany model, ale to nie dowodzi, że lokalne środowisko LLM go widzi lub z niego ładuje.

Docker dodaje kolejną warstwę. Ścieżka hosta, taka jak /mnt/storage/ai/models, może być mapowana na ścieżkę kontenera, taką jak /root/.ollama, a uruchamiacz modelu widzi tylko ścieżkę kontenera. Dokumentacja montowania wiązanego Dockera wyjaśnia, że source to ścieżka po stronie hosta, a destination lub target to ścieżka wewnątrz kontenera, więc obie muszą być sprawdzane razem przez montowania wiązane Dockera.

Praktyczne pytanie o ścieżkę jest proste: nie pytaj tylko, gdzie umieściłeś model. Zapytaj, jaką ścieżkę widzi środowisko uruchomieniowe i do którego folderu hosta ta ścieżka kontenera faktycznie wskazuje.

Zacznij od listy modeli środowiska uruchomieniowego

Zanim sprawdzisz każdy folder, zapytaj listę modeli środowiska uruchomieniowego, co wie. Dla Ollama zacznij od:

ollama list

Wewnątrz kontenera Docker użyj tego samego sprawdzenia środowiska uruchomieniowego z wnętrza granicy usługi:

docker exec -it ollama ollama list

Ten rejestr czasu wykonywania potwierdza, że środowisko uruchomieniowe zarejestrowało tag modelu, ale nie dowodzi w pełni, że ścieżka pliku, kwantyzacja lub lokalizacja przechowywania są poprawne. Referencja CLI Ollama wymienia ollama ps do uruchamiania modeli, podczas gdy FAQ wyjaśnia katalog przechowywania modeli i zmienną środowiskową OLLAMA_MODELS w swoim przewodniku po katalogu przechowywania modeli.

Użyj tego kroku jako pierwszego punktu kontrolnego, a nie ostatecznej odpowiedzi. Jeśli oczekiwany model nie pojawia się tutaj, aplikacja może wskazywać na inne środowisko uruchomieniowe, model może nie zostać zaimportowany lub skonfigurowany katalog modelu może nie być katalogiem używanym przez usługę.

Dopasuj ścieżkę hosta do ścieżki kontenera

Dla wdrożeń Dockera najważniejsze pytanie brzmi, czy ścieżka hosta i ścieżka kontenera faktycznie się zgadzają. Uruchom:

docker inspect <container-name>

Następnie spójrz na sekcję Mounts. Source powinno wskazywać na folder storage NAS, który zamierzałeś użyć, a Destination powinno wskazywać na katalog modelu używany wewnątrz kontenera. Polecenie inspect Dockera zwraca informacje o obiektach na niskim poziomie, co czyni docker inspect Mounts lepszym źródłem prawdy niż pamięć lub zrzuty ekranu.

Dobre mapowanie montowania Dockera powinno jasno pokazywać relację ze storage:

Jeśli ścieżka źródłowa wskazuje na root Dockera, ścieżkę tymczasową, stary folder lub małą partycję systemową, model może nadal działać, ale zapisywać na niewłaściwym dysku.

Sprawdź rzeczywiste pliki modelu, a nie tylko nazwę modelu

Nazwa modelu nie jest tym samym co zweryfikowany plik modelu. Ta sama nazwa może wskazywać na różne tagi, formaty, poziomy kwantyzacji, adaptery lub buforowane pliki w zależności od środowiska uruchomieniowego.

Dla Ollama sprawdź metadane modelu za pomocą:

ollama show <model-name> --modelfile

W środku Dockera uruchom to samo sprawdzenie pliku Modelfile przez kontener:

docker exec -it ollama ollama show <model-name> --modelfile

Metadane pliku modelu Ollama są tutaj ważne. Dokumentacja Modelfile Ollama wyjaśnia, że ollama show --modelfile może ujawnić konfigurację modelu, w tym źródło FROM stojące za modelem. W przypadku ręcznie pobranych plików .gguf, dokumentacja kwantyzacji llama.cpp pokazuje GGUF i formaty takie jak Q4_K_M, więc metadane pliku modelu GGUF są częścią weryfikacji, a nie tylko strojenia wydajności.

Logi mówią, która ścieżka została naprawdę załadowana

Gdy interfejs użytkownika i ścieżki plików się nie zgadzają, logi często są najczystszym dowodem. Mogą pokazać ścieżki startowe, nieudane odczyty, błędy uprawnień, brakujące pliki, pobieranie modeli i zachowanie zapasowe.

Dla Dockera użyj tej kontroli logów kontenera:

docker logs <nazwa-kontenera>

Dokumentacja logowania Dockera wyjaśnia, że logi kontenera zwykle pokazują wyjście procesu kontenera z STDOUT i STDERR, podczas gdy strona rozwiązywania problemów Ollama zauważa, że logi Ollama w kontenerze można przeglądać za pomocą docker logs.

Szukaj wskazówek dotyczących ścieżki, takich jak OLLAMA_MODELS, komunikaty o pobieraniu modelu, błędy ładowania, błędy uprawnień lub katalogi, które nie odpowiadają zamierzonemu folderowi przechowywania. Jeśli logi wspominają inny katalog niż ten, który zmapowałeś, zaufaj logom i popraw ścieżkę.

Potwierdź, że model jest aktywny w pamięci

Następna kontrola to stan aktywnego modelu. Model może być zainstalowany lub zarejestrowany, ale niekoniecznie aktualnie załadowany. Po wysłaniu krótkiego promptu natychmiast uruchom:

ollama ps

Wewnątrz Dockera uruchom tę samą kontrolę aktywnego modelu wewnątrz kontenera:

docker exec -it ollama ollama ps

Co ollama ps Może udowodnić

ollama ps pokazuje, które modele są aktualnie załadowane. FAQ Ollama wyjaśnia, że kolumna Processor może pokazać, czy model jest załadowany na CPU, GPU lub podzielony między CPU i GPU, co pomaga potwierdzić aktywny stan uruchomienia, a nie tylko bibliotekę modeli.

Jest to przydatne, gdy musisz wiedzieć, czy oczekiwany model jest teraz aktywny, czy pozostaje w pamięci oraz czy używa oczekiwanej ścieżki procesora. Szczególnie pomocne po zmianie modeli, tagów lub testowaniu zachowania GPU / CPU.

Czego nie może udowodnić

ollama ps samo w sobie nie dowodzi mapowania folderu hosta. Może pokazać, że model jest aktywny, ale nadal potrzebujesz docker inspect, metadanych modelu, logów i kontroli wzrostu zajętości, aby potwierdzić, że pochodzi z zamierzonej ścieżki.

Nie dowodzi to również, że niestandardowy plik modelu ma dokładną kwantyzację lub źródło, jakiego oczekiwałeś. W tym celu użyj kontroli metadanych, inspekcji Modelfile i weryfikacji na poziomie pliku.

Ostrzegawcze sygnały, że ścieżka modelu jest błędna

Błędna ścieżka modelu zwykle daje objawy zanim stanie się to oczywiste. Najczęstszym znakiem jest niewyjaśniony wzrost zajętości dysku na dysku startowym, Docker root lub woluminie danych aplikacji, którego nie zamierzałeś używać.

Zwróć uwagę na te sygnały niezgodności ścieżek:

• Aplikacja pokazuje model, ale twój zamierzony folder modelu nie rośnie.
• docker inspect pokazuje ścieżkę Źródło inną niż folder pamięci NAS.
• Model pobiera się ponownie, mimo że myślałeś, że jest już obecny.
• Logi wspominają domyślny katalog modeli zamiast twojej niestandardowej ścieżki.
• ollama list pokazuje inną etykietę lub rozmiar niż oczekiwano.
• ollama show --modelfile wskazuje na inną bazę lub blob niż oczekiwano.
• ollama ps pokazuje nieoczekiwanie aktywny model po poleceniu.
• Dysk rozruchowy traci miejsce po każdym pobraniu modelu.

Jeśli dwie warstwy weryfikacji się nie zgadzają, uprość test. Zatrzymaj kontener, zweryfikuj montowanie, uruchom ponownie usługę, pobierz jeden mały znany model i sprawdź, który katalog rośnie.

Czystsza kolejność weryfikacji lokalnej pamięci LLM

Użyj ustalonej kolejności weryfikacji zamiast sprawdzania losowych folderów. Zapobiega to myleniu ścieżek hosta, kontenera, aplikacji i środowiska uruchomieniowego.

1. Potwierdź zamierzony folder pamięci hosta.
2. Sprawdź wolne miejsce na dysku systemowym i dysku modelu.
3. Uruchom docker inspect <container-name> i zweryfikuj Źródło / Cel.
4. Sprawdź listę modeli w środowisku uruchomieniowym za pomocą ollama list.
5. Pobierz lub zaimportuj jeden mały znany model.
6. Uruchom du -sh <model-folder> przed i po pobraniu.
7. Sprawdź metadane za pomocą ollama show <model-name> --modelfile.
8. Wyślij jedno krótkie polecenie.
9. Uruchom ollama ps aby potwierdzić aktywny model.
10. Przeczytaj logi kontenera lub usługi, aby znaleźć wskazówki dotyczące ścieżek, pobierania lub uprawnień.

Czysta weryfikacja pamięci powinna zakończyć się tym, że wszystkie warstwy wskazują na to samo miejsce: folder modelu rośnie na oczekiwanym dysku, punkt montowania kontenera wskazuje na ten folder, środowisko uruchomieniowe wyświetla model, metadane odpowiadają oczekiwanemu plikowi, logi nie pokazują błędów ścieżek, a aktywny model to ten, który właśnie testowałeś.

Co pokazuje wyszukiwanie ZimaOS AI o widocznych ścieżkach modeli

Kontrolowana lokalna funkcja AI powinna udostępniać swój ścieżkę modelu, stan pobierania, zużycie zasobów i logi na tyle widocznie, aby można było to zweryfikować. W przeciwnym razie użytkownicy pozostają w niepewności, czy usługa AI faktycznie korzysta z oczekiwanych plików modelu.

ZimaOS-AI to przydatny przykład. Przewodnik ZimaSpace dotyczący wyszukiwania AI wyjaśnia, że moduł AI używa lokalnego LLM do wyodrębniania cech z obrazów, dźwięku i wideo dla wyszukiwania ZimaOS. Ta sama krótka notatka informuje, że pliki modeli są przechowywane w /media/ZimaOS-HD/AppData/.models, a jeśli AppData zostało przeniesione, faktyczne użycie pamięci podąża za nową lokalizacją AppData.

Przewodnik opisuje także kontrole operacyjne takie jak automatyczne pobieranie modeli, interwały ekstrakcji cech, historię połączeń, kontrole ruchu sieciowego oraz journalctl -xef -u zimaos-ai do rozwiązywania problemów. To dokładnie takie sygnały, jakich potrzebuje lokalne obciążenie AI: widoczna ścieżka, widoczne zachowanie pobierania, widoczne logi i widoczny status runtime.

Dla prywatnej chmury, takiej jak ZimaCube 2, to jest większa lekcja: lokalne AI nie powinno być czarną skrzynką. Niezależnie od tego, czy obciążenie to wyszukiwanie, czat, osadzanie czy analiza mediów, ścieżka modelu i stan runtime powinny być łatwe do zweryfikowania.

FAQ

Jak mogę sprawdzić, gdzie Ollama przechowuje pliki modeli?

Sprawdź domyślny katalog modelu Ollama dla twojego systemu operacyjnego, a następnie sprawdź, czy OLLAMA_MODELS go zmienił. W Dockerze sprawdź także montowanie kontenera, aby wiedzieć, który folder hosta jest mapowany na katalog modelu runtime.

Jak sprawdzić, czy Docker używa właściwego folderu modelu?

Uruchom docker inspect <nazwa-kontenera> i przejrzyj sekcję Mounts. Źródło powinno być ścieżką magazynu NAS, którą zamierzałeś, a miejsce docelowe powinno być katalogiem modelu używanym wewnątrz kontenera.

Co to są manifesty i bloby w katalogu modelu Ollama?

W katalogu modelu w stylu Ollama manifesty opisują metadane modelu i odniesienia, podczas gdy bloby przechowują większe pliki modelu. Jeśli folder blobs rośnie po pobraniu modelu, to silny znak, że ten katalog jest używany do przechowywania modeli.

Jak mogę sprawdzić, który model jest aktualnie załadowany?

Wyślij krótki prompt, a następnie uruchom ollama ps. Pokazuje on aktualnie załadowany model i stan procesora, co pomaga potwierdzić, czy oczekiwany model jest aktywny na CPU, GPU lub w podziale CPU / GPU.

Dlaczego aplikacja pokazuje model, ale ścieżka pliku nadal wydaje się nieprawidłowa?

Aplikacja może odczytywać rejestr runtime, pamięć podręczną modelu, wewnętrzną ścieżkę Dockera lub inny katalog modelu niż ten, który sprawdzasz w menedżerze plików. Zweryfikuj listę runtime, montowanie Dockera, metadane, logi oraz faktyczny wzrost magazynu przed zaufaniem interfejsowi użytkownika.

Sprawdzenie lokalnej ścieżki LLM jest kompletne tylko wtedy, gdy ścieżka magazynu hosta, miejsce docelowe kontenera, lista modeli runtime, metadane modelu, aktywny stan pamięci, logi oraz wzrost dysku są zgodne. Jeśli jedna warstwa wskazuje gdzie indziej, napraw ścieżkę przed pobraniem kolejnych modeli lub podłączeniem kolejnych aplikacji.