Hospede o Ollama em um Servidor LLM e Tenha Controle sobre a Censura de IA

Palavras-chave

Antes de mergulhar na configuração, aqui estão os termos com maior probabilidade de confundir os leitores neste guia. Este glossário rápido mantém o vocabulário de Linux, GPU e modelos locais claro desde o início.

Por Que Vale a Pena Auto-Alojar um LLM

Se já fez a parte difícil — alugou o servidor GPU, instalou o Ubuntu, aprendeu a navegar pelo SSH e manteve os seus próprios serviços a funcionar — torna-se rapidamente frustrante quando uma IA alojada ainda controla o último troço. Pode recusar um pedido perfeitamente normal, enterrar a resposta sob avisos, alterar o estilo de resposta sem aviso, e manter cada prompt a fluir através da fronteira de outra pessoa. Para muitos utilizadores técnicos, essa é a verdadeira frustração: não apenas o que o modelo diz, mas quem controla a camada de serviço quando o diz.

Este guia trata de resolver isso com modelos abertos e locais, não com truques de contorno para APIs proprietárias. Irá auto-alojar o Ollama num servidor Ubuntu GPU, executar inferência localmente, verificar que o caminho GPU é real, e ver o que muda quando escolhe uma família de modelos diferente. Um equívoco a esclarecer desde cedo: auto-alojado não significa automaticamente irrestrito. Significa que controla muito mais da pilha — e deixa de depender de um caminho de serviço controlado pelo fornecedor — mas o modelo que executa pode ainda ter o seu próprio comportamento de alinhamento.

📝 Nota: Os comandos neste guia são validados com base na documentação atual do Ollama, mas os resultados de terminal mostrados abaixo são exemplos representativos em vez de capturas de benchmarks em tempo real. Utilize-os como padrão de sucesso, não como uma afirmação de desempenho.

No final, terá um serviço Ollama a funcionar no Ubuntu, uma API local verificada em 127.0.0.1:11434, prova de que a inferência suportada por GPU está realmente a acontecer, e uma comparação fundamentada entre um modelo alinhado mainstream e uma alternativa menos restrita. Este tutorial foi escrito para leitores confortáveis com SSH, Ubuntu, sudo e systemd, mas que não precisam de experiência prévia com Ollama.

O Servidor Ubuntu GPU Exato Utilizado para Este Guia

Esta demonstração está ancorada numa máquina Ubuntu real com uma única GPU, porque conselhos vagos de “deve funcionar na maioria dos servidores” é como os guias de auto-alojamento se tornam enganosos. A máquina de referência aqui é a classe real de host utilizada para este guia: o tipo de máquina que um indivíduo avançado, laboratório ou pequena equipa alugaria quando quer inferência local privada sem saltar diretamente para um rack de aceleradores empresariais. Ainda irá discutir o comportamento multi-GPU mais tarde, porque o Ollama muda quando um modelo ultrapassa uma placa, mas trate essa parte como contexto orientado para o futuro em vez de prova deste servidor exato.

Servidor GPU — Ryzen 9 3950X + RTX 4070 Ti Super

Na prática, esta é uma configuração muito forte para modelos do dia a dia da classe 8B e ainda útil para trabalho local maior até ao ponto em que 16GB de VRAM se torna a verdadeira limitação. Um modelo como llama3.1:8b com aproximadamente 4.9GB cabe facilmente nesta placa. Um modelo como gpt-oss:20b com aproximadamente 14GB é o tipo de teste de topo de gama para uma única GPU que ainda faz sentido aqui. Um modelo como qwen3:30b com aproximadamente 19GB é melhor tratado como ponto de referência para o que muda num host maior ou de dual-GPU do que como um ajuste limpo para esta máquina exata.

Essa distinção importa porque o objetivo deste artigo não é espremer o maior número possível para uma manchete. É mostrar como é um servidor LLM auto-alojado sensato quando se quer privacidade, controlo local e memória GPU suficiente para executar modelos úteis sem compromisso constante. Esta classe de hardware é onde a inferência auto-alojada se torna realista, não teórica.

Também explica algumas escolhas que verá mais tarde: mistral é usado primeiro porque proporciona uma prova rápida e com pouco atrito de que a pilha funciona, enquanto a comparação de comportamento fica na classe 8B onde esta máquina está confortável. qwen3:30b ainda aparece mais tarde, mas como exemplo teórico do tipo de modelo que pode desencadear a colocação multi-GPU num host maior em vez de como prova em tempo real deste servidor. Com as expectativas definidas, o próximo passo é validar o host antes de o Ollama o tocar.

Execute Estas Verificações de Pré-Instalação Antes de Tocar no Ollama

Comece com nvidia-smi. Se este comando estiver ausente ou falhar, pare aí e corrija primeiro o driver NVIDIA. Não instale o Ollama ainda, porque uma pilha NVIDIA com problemas fará com que cada sintoma posterior pareça uma falha de aplicação quando na realidade é uma falha de plataforma.

Execute primeiro a verificação de GPU:

❗Se o Ubuntu indicar que o nvidia-smi está em falta, não assuma que o servidor não tem GPU. Um modo de falha comum em máquinas Ubuntu alugadas é que a placa está presente mas ainda ligada ao nouveau em vez do driver NVIDIA. Consulte primeiro a secção “Corrigir Problema de Driver Nvidia no Ubuntu“.

Um resultado saudável nesta classe de servidor deve ter um aspeto semelhante a este:

Depois de o nvidia-smi funcionar e a GPU estar visível, continue com as verificações abaixo.

O que pretende confirmar é simples: a GPU instalada está visível, reporta aproximadamente 16GB de VRAM neste host, e o driver está carregado de forma limpa. Se estiver num servidor multi-GPU, o mesmo comando deve listar cada placa.

❗ Importante: A documentação atual de suporte GPU do Ollama utiliza o driver NVIDIA 531+ como o piso real para inferência NVIDIA suportada. Trate o 531+ como o requisito para este guia, mesmo que tenha visto notas da comunidade mais antigas a citar versões mais baixas.

Agora confirme que o host é realmente o ambiente Ubuntu que este guia assume:

Por fim, verifique o espaço livre em disco antes de começar a descarregar modelos. A instalação em si é pequena; os modelos não são. Depois de avançar para além de testes pequenos, uma biblioteca de 20B-30B pode consumir dezenas de gigabytes rapidamente, por isso 100GB+ livres é a mentalidade certa antes de trabalho sério com modelos locais.

Se estas verificações passarem, eliminou as principais incógnitas de infraestrutura: as GPUs estão presentes, a base do driver é sã, o Ubuntu está confirmado, e o disco tem espaço para descarregamentos reais de modelos. Esse é o ponto em que instalar o Ollama se torna um próximo passo limpo em vez de uma suposição.

Corrigir Problema de Driver Nvidia no Ubuntu

Siga os passos abaixo para corrigir problemas com o comando “nvidia-smi”.

Se essa saída mostrar uma placa NVIDIA e uma linha como Kernel driver in use: nouveau, instale o pacote de driver Ubuntu recomendado em vez de instalar apenas o nvidia-utils.

Instale o pacote ubuntu-drivers-common (necessário para a gestão de drivers) e os cabeçalhos do kernel para o seu kernel atualmente em execução.

Analise o seu sistema e liste os drivers proprietários disponíveis (por exemplo, drivers GPU NVIDIA) que podem ser instalados.

Em seguida, instale o pacote de driver recomendado. No nosso caso foi: nvidia-driver-595-open:

Após o reinício, execute novamente:

Instalar o Ollama e Confirmar que o Serviço Está Saudável

O caminho Ubuntu suportado é o instalador oficial do Ollama, não um fluxo de tarball personalizado nem um desvio pelo Docker. Isso importa porque este guia trata de obter um serviço local fiável com padrões previsíveis, integração systemd e comportamento de propriedade sensato no Linux.

Execute o instalador exatamente como documentado:

Num sistema saudável, o script instala o binário, cria o utilizador de serviço ollama, adiciona as associações de grupo corretas quando disponíveis, escreve a unidade systemd e inicia o serviço ligado a 127.0.0.1:11434.

Depois de o script terminar, valide o serviço em vez de assumir sucesso:

Está à procura de três coisas aqui: o ficheiro de unidade está presente, o serviço está ativado para arranque, e Active: active (running) confirma que o servidor está realmente em execução.

Primeiro, estabeleça a conta de utilizador de serviço Linux de forma concreta, e só depois pense em como e onde o armazenamento de modelos será gerido.

Essa única linha explica muito do comportamento futuro. Os modelos no Linux residem sob a propriedade do serviço, e se os mover posteriormente para outro disco sem corrigir as permissões para o utilizador ollama, cria os seus próprios problemas.

Mais uma verificação fecha o ciclo no bind padrão:

⚠️ Aviso: O Ollama não requer autenticação na API local por padrão. Isso é aceitável quando está ligado a 127.0.0.1, mas não é seguro expor a porta 11434 diretamente à internet como se fosse um serviço público reforçado.

Se o serviço não arrancar de forma limpa, vá primeiro aos registos em vez de reinstalar às cegas:

Essa é a forma mais rápida de detetar problemas de permissões, erros de arranque, problemas de deteção de driver ou problemas de bind. Depois de o serviço estar saudável no localhost, a próxima coisa a compreender é como o comportamento de colocação de GPU funciona em tempo de execução.

Como o Ollama Utiliza Realmente Uma ou Múltiplas GPUs

Mesmo que o servidor utilizado para este guia tenha uma GPU, o comportamento multi-GPU ainda vale a pena compreender porque muitos utilizadores podem estar em máquinas maiores ou expandir mais tarde. Muita confusão com duas GPUs começa com a expectativa errada: “Tenho duas placas, por isso ambas devem estar ativas o tempo todo.” Não é assim que o Ollama funciona. A regra prática é muito mais simples: se um modelo cabe numa GPU, o Ollama normalmente mantê-lo-á numa GPU. Só se distribui por múltiplas GPUs quando o modelo não cabe confortavelmente numa única placa.

Utilize estas duas verificações em conjunto sempre que quiser ver o desempenho da GPU:

ollama ps indica como o modelo carregado está a ser processado. 100% GPU significa que o modelo está totalmente residente na memória GPU. 100% CPU significa que a aceleração GPU não está a ser utilizada. Um estado misto indica que alguma parte da carga de trabalho ou residência saiu do caminho GPU. watch -n 1 nvidia-smi complementa isso mostrando o uso de VRAM em tempo real por placa enquanto o modelo está carregado.

A forma mais rápida de manter essas funções claras é esta:

📝 Nota: CUDA_VISIBLE_DEVICES é um controlo de visibilidade, não um interruptor “usar ambas as GPUs”. Se alguma vez restringir o acesso à GPU, prefira os UUIDs do nvidia-smi -L em vez de IDs numéricos porque a ordem das GPUs pode variar entre ambientes e reinícios.

Execute o Seu Primeiro Modelo Local e Verifique a Inferência GPU

Neste ponto, não precisa de um modelo gigante para provar que o servidor funciona. Precisa de um sucesso rápido e honesto. mistral é um bom primeiro pull porque é pequeno, rápido de descarregar e fácil de carregar, mesmo que llama3.1:8b seja a referência de base posterior para comparação de comportamento.

Comece por fazer pull do modelo:

Agora execute um prompt pequeno para que a máquina faça algo útil, não apenas administrativo. A resposta pode demorar alguns segundos.

Para provar que esta é inferência suportada por GPU em vez de um fallback para CPU, verifique o estado de execução:

E para ver o que já está no disco, liste o inventário local:

mistral é a prova inicial correta porque dá uma resposta rápida sem transformar a validação da configuração numa longa espera. Mais tarde, llama3.1:8b torna-se mais útil porque é uma referência de base alinhada mais forte para comparar o comportamento do modelo.

Por fim, verifique onde a instalação Linux está a armazenar modelos:

Esse caminho — /usr/share/ollama/.ollama/models — é o armazenamento padrão de modelos Linux documentado pelo Ollama.

Quando vir uma resposta bem-sucedida, 100% GPU no ollama ps, e o uso do disco a aumentar na localização esperada, tem a primeira prova significativa de que a pilha local funciona.

Prove que É um Servidor, Não Apenas um Wrapper CLI

Um prompt de linha de comandos é agradável, mas a razão para auto-alojar o Ollama não é apenas para conversar dentro de um terminal. É para executar um servidor de inferência local que outras ferramentas, scripts e aplicações podem chamar sem enviar prompts através da fronteira de API de outra pessoa. A prova mais rápida é um pedido HTTP limpo ao endpoint nativo do Ollama.

Envie um pedido de geração local com streaming desativado para que a primeira resposta seja fácil de inspecionar:

Uma resposta bem-sucedida deve voltar como JSON e ter um aspeto semelhante a este:

{
  "model": "mistral",
  "created_at": "2026-05-13T12:45:12.000000Z",
  "response": "Hello from a self-hosted Ollama server running locally on Ubuntu.",
  "done": true,
  "done_reason": "stop",
  "total_duration": 812345678,
  "load_duration": 12345678,
  "prompt_eval_count": 14,
  "eval_count": 12
}

A lista de verificação de sucesso é simples: o pedido HTTP funciona localmente, JSON válido é devolvido, done: true está presente, e a resposta do modelo está em response. Esse é o ponto em que o Ollama deixa de ser “um CLI que por acaso descarrega modelos” e se torna infraestrutura que pode realmente integrar em ferramentas locais e automação.

Se quiser compatibilidade com software que espera uma forma de pedido no estilo OpenAI, o Ollama também expõe endpoints /v1 localmente:

📝 Nota: Esse rótulo “compatível com OpenAI” é fácil de interpretar mal. Não significa que está a falar com a OpenAI, e não muda o facto de o servidor ainda ser local. Significa apenas que a forma do pedido é familiar o suficiente para ferramentas e SDKs construídos em torno do padrão da API OpenAI. O URL base permanece http://localhost:11434/v1/, e qualquer chave API de substituição que algumas bibliotecas cliente insistam pode ser ignorada para uso local do Ollama.

De Onde Vêm Realmente as Restrições do Modelo

Esta é a parte que normalmente é simplificada numa única ideia vaga de “censura”, mas tecnicamente existem três camadas diferentes envolvidas: a camada de serviço do fornecedor, o alinhamento e ajuste de instruções do modelo, e o comportamento de prompt/execução que controla você mesmo. O auto-alojamento altera algumas dessas camadas dramaticamente. Não as apaga todas.

Uma forma simples de visualizar é esta:

Cloud API request:
You -> Vendor API gateway -> Vendor moderation / policy layer -> Model -> Response

Self-hosted Ollama request:
You -> Local Ollama server on 127.0.0.1 -> Model -> Response

Resultados:
– A camada de serviço controlada pelo fornecedor desaparece do caminho local
– A fronteira de rede e registo local torna-se sua
– O próprio treino e alinhamento do modelo ainda acompanha o modelo

Depois de separar as camadas, os passos de configuração anteriores tornam-se muito mais significativos:

Pode pensar nisso como uma produção teatral. O auto-alojamento muda o palco, a iluminação, os microfones e as notas do realizador. Não retreina o ator. Se um modelo foi ajustado para responder com cautela, hesitar frequentemente ou recusar certos tipos de enquadramento, executá-lo localmente não desfará magicamente esse treino.

O que a sua configuração atual já provou é mais restrito, mas ainda importante: controla o processo do servidor, controla a fronteira da API, e já não está a encaminhar prompts locais através de uma camada de moderação de propriedade do fornecedor. Essa é uma mudança real em privacidade e controlo. O que não provou é que cada modelo local se comportará da mesma forma ou que cada recusa no futuro foi causada por um fornecedor cloud.

É aqui que entra a escolha do modelo. Se quiser o efeito prático de menos avisos, respostas mais diretas ou comportamento menos propenso a recusas, não chega lá dizendo “auto-alojado” mais alto. Chega lá escolhendo uma família de modelos ou fine-tune diferente — e compreendendo as trocas que vêm com isso.

Escolher um Modelo Local Menos Restrito

Se quiser um teste justo, compare modelos que ocupam aproximadamente a mesma classe de tamanho. É por isso que este guia utiliza llama3.1:8b como referência de base alinhada mainstream e dolphin3 como modelo de comparação menos restrito. Ambos têm cerca de 4.9GB, o que torna a diferença de comportamento mais fácil de interpretar sem também alterar drasticamente a pegada de hardware.

Faça pull dos modelos de comparação localmente:

Aqui está o enquadramento prático para os três nomes que mais provavelmente verá nesta parte do ecossistema Ollama:

⚠️ Aviso: Um fine-tune diferente não é “o mesmo modelo com censura removida.” Pode alterar a diretividade, a densidade de avisos e a disposição para seguir o enquadramento do utilizador, mas também pode alterar o tom, a factualidade, a consistência e a personalidade geral.

Desempenho GPU

Antes de executar os modelos desejados, é essencial compreender primeiro as possibilidades e limitações do hardware envolvido. Assim, há duas coisas a testar conceptualmente: primeiro, como é o comportamento limpo de GPU única no hardware real utilizado para este guia; segundo, o que muda se posteriormente executar a mesma pilha num host dual-GPU. Ambas importam, mas apenas a primeira é uma prova em tempo real desta máquina exata.

Neste servidor, o melhor teste de execução de topo de gama é gpt-oss:20b. É suficientemente grande para ser interessante enquanto ainda faz sentido numa placa de 16GB.

Depois de o modelo carregar, confirme o estado de execução:

Essa é a prova prática que pretende nesta máquina. Mostra que os modelos mais pequenos cabem facilmente e que um modelo local maior mas ainda realista pode empurrar uma placa de 16GB perto do seu envelope utilizável sem precisar de múltiplas GPUs.

Se posteriormente executar o Ollama num host de duas GPUs, um modelo como qwen3:30b torna-se o tipo de carga de trabalho que pode demonstrar a colocação multi-GPU. O fluxo de trabalho é o mesmo — observe o nvidia-smi, execute o modelo, inspecione o ollama ps — mas o objetivo não é fazer as duas placas acenderem por si só. O objetivo é confirmar que o Ollama só distribui um modelo por múltiplas GPUs quando o modelo já não cabe de forma limpa numa.

Considerações sobre Contorno de Censura

Para comparação de comportamento, mantenha as condições controladas para estar a testar o modelo mais do que a aleatoriedade. Utilize o mesmo endpoint, o mesmo prompt, stream: false, uma temperatura baixa e um seed fixo:

Em seguida, repita o mesmo pedido com “model”: “dolphin3”. O seed fixo não elimina toda a variância, mas reduz aleatoriedade suficiente para tornar as diferenças de tom e conformidade mais fáceis de ver.

1. Um primeiro prompt seguro é: “O auto-alojamento de um LLM significa que o utilizador controla totalmente o comportamento do modelo? Responda em 4 pontos. Seja direto e omita preâmbulos.” Uma resposta representativa do llama3.1:8b tende a soar assim:

   - Self-hosting gives you more control over deployment, privacy, and availability.
   - It does not automatically remove the model's built-in alignment behavior.
   - The model may still refuse or soften some responses depending on its training.
   - Full control comes from combining self-hosting with careful model selection and configuration.

   Uma resposta representativa do dolphin3 ao mesmo prompt soa frequentemente mais condensada:

   - You control the machine, the network boundary, and the serving layer.
   - You do not erase the model's training history just by running it locally.
   - Vendor-side policy can disappear, but model-side alignment can still remain.
   - Real control comes from choosing a model whose behavior matches your use case.

2. Um segundo prompt útil é: “Escreva um caso conciso em cinco frases sobre por que uma equipa sensível à privacidade pode rejeitar a IA gerida pelo fornecedor. Sem introdução nem conclusão.” O llama3.1:8b normalmente cumpre, mas num tom empresarial mais moderado. O dolphin3 segue mais prontamente a nitidez solicitada. Esse é o tipo de diferença que está a procurar aqui: não resultados dramáticos sem lei, mas mudanças em diretividade, enquadramento e densidade de avisos.
3. A terceira categoria de prompts para validação pode ser a seguinte: pedir cinco razões factuais pelas quais um escritor pode preferir um modelo local para trabalho criativo incomum, de nicho ou não mainstream. Na prática, ambos os modelos respondem, mas o dolphin3 tende a manter-se mais próximo do tom não moralizador solicitado e de respostas diretas.

O padrão parece este:

E assim, aqui estão as conclusões honestas:

1. A escolha de modelo local altera significativamente o comportamento de saída.
2. Diferentes modelos variam em diretividade e densidade de avisos.
3. O auto-alojamento remove uma camada de serviço controlada pelo fornecedor.

Agora Controla a Pilha, Não Apenas o Prompt

A frustração do início deste guia nunca foi apenas sobre um modelo recusar um pedido. Era sobre o facto de a camada de serviço, a camada de política e a fronteira de privacidade residirem noutro lugar. Após esta configuração, essa parte mudou. O seu servidor de inferência corre na sua máquina Ubuntu, a fronteira da API local é sua, o menu de modelos é seu, e os seus padrões de prompt/execução são seus para ajustar.

O que ainda requer julgamento é a parte que nenhum instalador pode resolver por si: escolher modelos que se adequem ao seu caso de uso, orientá-los com padrões sensatos, e expor o acesso de forma segura se avançar para além do localhost. Essa é a forma real do controlo de auto-alojamento. Não liberdade mágica de toda e qualquer restrição, mas propriedade da pilha que decide como, onde e com que modelo a inferência acontece. Se quiser o melhor próximo passo, comece por criar um Modelfile personalizado — ou colocar acesso remoto seguro à frente da API local quando estiver pronto.

O Que Fazer Após a Configuração Base

Neste ponto, a promessa central está cumprida. O servidor funciona, a API funciona, o caminho GPU é real, e as diferenças de comportamento do modelo já não são abstratas. O próximo passo não é “instalar mais coisas às cegas.” É ajustar as partes da pilha que agora lhe pertencem.

Personalizar o Comportamento do Modelo com um Modelfile

Um Modelfile é a forma mais limpa de alterar os padrões de prompt local sem tocar nos pesos do modelo. Comece por inspecionar a definição atual do modelo para perceber o que está a estender:

Em seguida, crie uma variação local simples:

FROM dolphin3

SYSTEM You are a direct, factual assistant for a self-hosted Ubuntu LLM server. 
Prefer short, practical answers and avoid padded disclaimers.

PARAMETER temperature 0.2
PARAMETER num_ctx 8192

Construa-a como um novo nome de modelo e teste-a:

❗ Importante: Um Modelfile altera o comportamento de prompt e execução, não o histórico de treino do modelo. Pode orientar o tom e os padrões, mas não retreina o modelo subjacente.

Proteger a Configuração

O bind ao localhost é um bom padrão, mas não é o fim da história de segurança. Verifique novamente o endereço de escuta atual:

Se o objetivo é manter o Ollama apenas local, fixe esse comportamento explicitamente com uma substituição systemd:

Adicione o seguinte:

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_NO_CLOUD=1"

Em seguida, recarregue e reinicie o serviço:

Se precisar de acesso remoto mais tarde, não publique o 11434 diretamente. Em vez disso, coloque um proxy inverso com TLS e autenticação à frente:

server {
    listen 443 ssl http2;
    server_name llm.example.com;

    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host localhost:11434;
    }
}

⚠️ Aviso: Trate a exposição pública como um projeto de reforço separado. O Ollama por si só é um servidor de inferência local, não um gateway de API público pronto para produção com autenticação integrada, limitação de taxa e padrões voltados para a internet.

Modelos Recomendados para Este Hardware

Depois de a instalação base funcionar, a melhoria de maior valor é escolher modelos que se adequem bem a esta máquina em vez de perseguir o maior destaque. Para o servidor single-4070 Ti SUPER utilizado aqui, o menu prático parece este:

Arranque Automático e Manutenção

Depois da parte divertida vem a parte que mantém um servidor LLM local utilizável um mês depois. Confirme o comportamento no arranque, mantenha o serviço atualizado, observe os registos e saiba como descarregar modelos grandes quando precisar da VRAM de volta.

Para operações diárias de modelos, estes são os comandos que utilizará com mais frequência:

E se o armazenamento de modelos tiver de ser movido para um disco maior, prepare o diretório para o utilizador de serviço antes de redirecionar o Ollama:

Em seguida, defina OLLAMA_MODELS através do systemctl edit ollama. Esse detalhe de propriedade é o que impede que uma migração de armazenamento se torne num problema de permissões.

Referência de Resolução de Problemas

Quando algo se avaria, o caminho mais rápido é normalmente fazer corresponder o sintoma à camada certa em vez de tentar ciclos aleatórios de reinstalação. Utilize esta tabela como primeira abordagem:

Se apenas se lembrar de uma regra operacional desta secção, que seja esta: trate o Ollama como um serviço real, não como uma utilidade CLI descartável. Registos, propriedade, endereços de bind e caminhos de armazenamento importam tanto quanto a janela de prompt.