Como Verificar Se um LLM Local Usa os Ficheiros de Modelo e o Caminho de Armazenamento Corretos

Lauren Pan

IceWhale author

Lauren Pan é o fundador da ZimaSpace e o arquiteto por trás da aclamada série ZimaBoard. Combinando design industrial com engenharia embutida, Lauren lançou a ZimaSpace com uma missão clara: democratizar a computação pessoal na nuvem. Ele acredita que o hardware deve ser tanto "hackeável" quanto bonito—fechando a divisão entre servidores de nível industrial e gadgets de consumo. Hoje, ele lidera a equipa de engenharia na criação de ferramentas que dão aos criadores controlo total sobre as suas vidas digitais.

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

Um LLM local pode responder a um prompt e ainda estar a usar o caminho errado do modelo. A interface da aplicação pode mostrar o nome do modelo que espera, mas o runtime pode estar a ler uma cache antiga, um diretório interno do Docker, uma pasta de modelo predefinida ou um ficheiro que foi descarregado novamente noutro local.

A verificação mais segura não é um único comando. É uma cadeia de prova curta: compare a pasta do anfitrião, a montagem do contentor, a lista de modelos do runtime, os metadados do modelo, o estado ativo da memória, os registos e o crescimento real do armazenamento. Quando essas camadas concordam, pode ter muito mais confiança de que o LLM está a usar os ficheiros de modelo e o caminho de armazenamento corretos.

A Pasta Que Vê Nem Sempre É o Caminho Que o Runtime Usa

O primeiro erro é confiar demasiado cedo no caminho do gestor de ficheiros. Uma pasta NAS pode conter o modelo que descarregou, mas isso não prova que o runtime local do LLM o consegue ver ou está a carregar a partir dele.

O Docker adiciona outra camada. Um caminho do anfitrião como /mnt/storage/ai/models pode estar mapeado para um caminho do contentor como /root/.ollama, e o executor do modelo só vê o caminho do contentor. A documentação das montagens bind do Docker explica que source é o caminho do lado do anfitrião e destination ou target é o caminho dentro do contentor, por isso os dois devem ser verificados em conjunto através das montagens bind do Docker.

A questão prática do caminho é simples: não pergunte apenas onde colocou o modelo. Pergunte qual caminho o runtime vê e a qual pasta do anfitrião esse caminho do contentor realmente aponta.

Comece com a Lista de Modelos do Runtime

Antes de verificar cada pasta, pergunte à lista de modelos do runtime o que ela sabe. Para a Ollama, comece com:

ollama list

Dentro de um contentor Docker, use a mesma verificação de runtime a partir do interior do limite do serviço:

docker exec -it ollama ollama list

Este registo de runtime confirma que o runtime registou uma etiqueta de modelo, mas não prova totalmente que o caminho do ficheiro, a quantização ou o local de armazenamento estão corretos. A referência CLI da Ollama lista ollama ps para executar modelos, enquanto o FAQ explica o diretório de armazenamento do modelo e a variável de ambiente OLLAMA_MODELS na sua orientação sobre o diretório de armazenamento de modelos.

Use este passo como o primeiro ponto de verificação, não como a resposta final. Se o modelo esperado não aparecer aqui, a aplicação pode estar a apontar para um runtime diferente, o modelo pode não ter sido importado, ou o diretório do modelo configurado pode não ser o diretório que o serviço está a usar.

Faça corresponder o Caminho do Host ao Caminho do Contentor

Para implementações Docker, a questão mais importante é se o caminho do host e o caminho do contentor correspondem realmente. Execute:

docker inspect <nome-do-contentor>

Depois, veja a seção Montagens. O Source deve apontar para a pasta de armazenamento NAS que pretendia usar, e o Destination deve apontar para o diretório do modelo usado dentro do contentor. O comando inspect do Docker devolve informação de objeto a baixo nível, o que torna a inspeção docker Mounts uma fonte de verdade melhor do que a memória ou capturas de ecrã.

Um bom mapeamento de montagem Docker deve tornar a relação de armazenamento óbvia:

Camada	Exemplo	O Que Significa
Origem do Host	`/mnt/storage/ai/ollama`	A pasta real do NAS que armazena os dados do modelo
Destino do Contentor	`/root/.ollama`	O caminho que o executor do modelo vê dentro do Docker
Comportamento em Runtime	Ollama lê `/root/.ollama`	Os ficheiros devem crescer na pasta de origem do host

Se o caminho de origem apontar para a raiz do Docker, um caminho temporário, uma pasta antiga ou um volume de sistema pequeno, o modelo pode ainda funcionar enquanto preenche a drive errada.

Verifique os Ficheiros Reais do Modelo, Não Apenas o Nome do Modelo

Um nome de modelo não é o mesmo que um ficheiro de modelo verificado. O mesmo nome pode apontar para diferentes etiquetas, formatos, níveis de quantização, adaptadores ou blobs em cache dependendo do runtime.

Para o Ollama, inspecione os metadados do modelo com:

ollama show <nome-do-modelo> --modelfile

Dentro do Docker, execute a mesma verificação Modelfile através do contentor:

docker exec -it ollama ollama show <nome-do-modelo> --modelfile

Os metadados do Ollama Modelfile são importantes aqui. A documentação do Modelfile do Ollama explica que o ollama show --modelfile pode revelar a configuração do modelo, incluindo a origem FROM por trás do modelo. Para ficheiros .gguf descarregados manualmente, a documentação de quantização do llama.cpp mostra GGUF e formatos como Q4_K_M, por isso os metadados do ficheiro de modelo GGUF fazem parte da verificação, não apenas da otimização de desempenho.

Os Registos Dizem Qual Caminho Foi Realmente Carregado

Quando a interface e os caminhos dos ficheiros discordam, os registos são frequentemente a evidência mais clara. Podem mostrar caminhos de arranque, leituras falhadas, erros de permissão, ficheiros em falta, downloads de modelos e comportamento de fallback.

Para o Docker, use esta verificação de registos do contentor:

docker logs <nome-do-contentor>

A documentação de registos do Docker explica que os registos do contentor geralmente expõem a saída do processo do contentor a partir de STDOUT e STDERR, enquanto a página de resolução de problemas do Ollama nota que os registos do Ollama em contentores podem ser vistos com docker logs.

Procure pistas de caminho como OLLAMA_MODELS, mensagens de download do modelo, erros de carregamento falhado, erros de permissão ou diretórios que não correspondem à pasta de armazenamento pretendida. Se os registos mencionarem um diretório diferente do que mapeou, confie nos registos e corrija o caminho.

Confirme que o Modelo Está Ativo na Memória

A próxima verificação é o estado do modelo ativo. Um modelo pode estar instalado ou registado, mas não estar atualmente carregado. Após enviar um prompt curto, execute imediatamente:

ollama ps

Dentro do Docker, execute a mesma verificação de modelo ativo dentro do contentor:

docker exec -it ollama ollama ps

O Que `ollama ps` Pode Provar

ollama ps mostra quais modelos estão atualmente carregados. O FAQ do Ollama explica que a coluna Processor pode mostrar se um modelo está carregado na CPU, GPU ou dividido entre CPU e GPU, o que ajuda a confirmar o estado de execução ativo em vez de apenas a biblioteca de modelos.

Isto é útil quando precisa de saber se o modelo esperado está ativo agora, se está a permanecer na memória e se está a usar o caminho do processador esperado. É especialmente útil após mudar de modelos, alterar etiquetas ou testar o comportamento da GPU / CPU.

O Que Não Pode Provar

ollama ps não prova por si só o mapeamento da pasta anfitriã. Pode mostrar que um modelo está ativo, mas ainda precisa de docker inspect, metadados do modelo, registos e verificações de crescimento de armazenamento para provar que veio do caminho pretendido.

Também não prova que um ficheiro de modelo personalizado tem exatamente a quantização ou a origem que esperava. Para isso, use verificações de metadados, inspeção do Modelfile e verificação ao nível do ficheiro.

Sinais de Alerta de que o Caminho do Modelo Está Errado

Um caminho de modelo errado geralmente apresenta sintomas antes de se tornar óbvio. O sinal mais comum é o crescimento inexplicável do disco na unidade de arranque, na raiz do Docker ou num volume de dados de uma aplicação que não pretendia usar.

Esteja atento a estes sinais de incompatibilidade de caminho:

A aplicação mostra o modelo, mas a pasta do modelo pretendida não cresce.
docker inspect mostra um caminho de Origem diferente da sua pasta de armazenamento NAS.
O modelo é descarregado novamente depois de pensar que já estava presente.
Os registos mencionam um diretório de modelo padrão em vez do seu caminho personalizado.
ollama list mostra uma etiqueta ou tamanho diferente do que esperava.
ollama show --modelfile aponta para uma base ou blob diferente do esperado.
ollama ps mostra um modelo ativo inesperado após um prompt.
A unidade de arranque perde espaço após cada pull de modelo.

Se duas camadas de verificação discordarem, simplifique o teste. Pare o contentor, verifique a montagem, reinicie o serviço, faça pull de um modelo pequeno conhecido e verifique qual diretório cresce.

Uma Ordem de Verificação Mais Limpa para Armazenamento Local de LLM

Use uma ordem de verificação fixa em vez de verificar pastas aleatórias. Isto evita confundir caminhos do host, caminhos do contentor, caminhos da aplicação e caminhos do runtime.

Confirme a pasta de armazenamento pretendida no host.
Verifique o espaço livre na unidade do sistema e na unidade do modelo.
Execute docker inspect <nome-do-contentor> e confirme Origem / Destino.
Verifique a lista de modelos do runtime com ollama list.
Faça pull ou importe um modelo pequeno conhecido.
Execute du -sh <pasta-do-modelo> antes e depois do pull.
Inspecione os metadados com ollama show <nome-do-modelo> --modelfile.
Envie um prompt curto.
Execute ollama ps para confirmar o modelo ativo.
Leia os registos do contentor ou serviço para pistas sobre caminho, download ou permissões.

Uma verificação de armazenamento limpa deve terminar com todas as camadas a apontar para o mesmo local: a pasta do modelo cresce na unidade esperada, o ponto de montagem do contentor aponta para essa pasta, o runtime lista o modelo, os metadados correspondem ao ficheiro esperado, os registos não mostram erros de caminho, e o modelo ativo é aquele que acabou de testar.

O que a Pesquisa AI do ZimaOS Mostra Sobre Caminhos de Modelo Visíveis

Uma funcionalidade AI local controlada deve tornar o seu caminho do modelo, estado de download, uso de recursos e registos suficientemente visíveis para verificação. Caso contrário, os utilizadores ficam a adivinhar se o serviço AI está realmente a usar os ficheiros de modelo esperados.

ZimaOS-AI é um exemplo útil. O guia do ZimaSpace para pesquisa AI explica que o módulo AI usa um LLM local para extrair características de imagens, áudio e vídeo para a pesquisa do ZimaOS. A mesma nota breve indica que os ficheiros do modelo são armazenados em /media/ZimaOS-HD/AppData/.models, e se o AppData foi migrado, o uso real do armazenamento segue a localização migrada do AppData.

O guia também descreve verificações de operação como descarregamentos automáticos de modelos, intervalos de extração de características, Histórico de Chamadas, verificações de tráfego de rede e journalctl -xef -u zimaos-ai para resolução de problemas. Estes são exatamente os tipos de sinais que uma carga de trabalho de IA local precisa: caminho visível, comportamento de descarregamento visível, registos visíveis e estado de execução visível.

Para uma configuração de nuvem privada como o ZimaCube 2, esta é a lição principal: a IA local não deve ser uma caixa preta. Quer a carga de trabalho seja pesquisa, chat, embeddings ou análise de media, o caminho do modelo e o estado de execução devem ser fáceis de verificar.

FAQ

Como posso saber onde o Ollama armazena os ficheiros dos modelos?

Verifique o diretório de modelos padrão do Ollama para o seu sistema operativo, depois verifique se o OLLAMA_MODELS o alterou. No Docker, inspecione também a montagem do contentor para saber qual a pasta do anfitrião que corresponde ao diretório de modelos em execução.

Como posso verificar se o Docker está a usar a pasta de modelos correta?

Execute docker inspect <nome-do-contentor> e reveja a secção Mounts. A Origem deve ser o caminho de armazenamento NAS que pretendia, e o Destino deve ser o diretório do modelo usado dentro do contentor.

O que são `manifests` e `blobs` num diretório de modelos Ollama?

Num diretório de modelos ao estilo Ollama, os manifests descrevem os metadados e referências do modelo, enquanto os blobs contêm os ficheiros maiores do modelo. Se a pasta blobs crescer após puxar um modelo, isso é um forte sinal de que este diretório está a ser usado para armazenamento do modelo.

Como posso saber qual o modelo atualmente carregado?

Envie um prompt curto e depois execute ollama ps. Isto mostra o modelo atualmente carregado e o estado do processador, o que ajuda a confirmar se o modelo esperado está ativo na CPU, GPU ou numa divisão CPU / GPU.

Porque é que a aplicação mostra o modelo mas o caminho do ficheiro ainda parece errado?

A aplicação pode estar a ler um registo de execução, um modelo em cache, um caminho interno do Docker ou um diretório de modelos diferente daquele que está a verificar no gestor de ficheiros. Verifique a lista de execução, a montagem do Docker, os metadados, os registos e o crescimento real do armazenamento antes de confiar na interface.

Uma verificação do caminho LLM local só está completa quando o caminho de armazenamento do anfitrião, o destino do contentor, a lista de modelos em execução, os metadados do modelo, o estado ativo da memória, os registos e o crescimento do disco concordam todos. Se uma camada apontar para outro local, corrija o caminho antes de descarregar mais modelos ou ligar mais aplicações.