Auto-hospedar Ollama em um servidor LLM e Assumir Controle sobre Censura de IA

Palavras-chave

Antes de começar a configuração, aqui estão os termos mais propensos a confundir os leitores neste guia. Este glossário rápido mantém o Linux, GPU e vocabulário de modelo local claros desde o início.

Por que Vale a Pena Auto-Hospedar um LLM

Se você já fez a parte difícil — alugou o servidor GPU, instalou Ubuntu, aprendeu a se mover pelo SSH, e manteve seus próprios serviços funcionando — fica frustrante rapidamente quando uma IA hospedada ainda controla o último quilômetro. Pode recusar um pedido perfeitamente ordinário, enterrar a resposta sob avisos de isenção de responsabilidade, mudar o estilo de resposta sem aviso prévio, e manter cada prompt fluindo através de limites de outra pessoa. Para muitos usuários técnicos, essa é a frustração real: não apenas o que o modelo diz, mas quem está no controle da camada de serviço quando ele diz.

Este guia é sobre corrigir isso com modelos abertos e locais, não sobre truques de bypass para APIs proprietárias. Você irá auto-hospedar Ollama em um servidor GPU Ubuntu, executar inferência localmente, verificar que o caminho GPU é real, e ver o que muda quando você escolhe uma família de modelo diferente. Um equívoco para esclarecer cedo: auto-hospedado não significa automaticamente irrestrito. Significa que você controla muito mais da pilha — e você para de depender de um caminho de serviço controlado por fornecedor — mas o modelo que você executa ainda pode carregar seu próprio comportamento de alinhamento.

📝 Nota: Os comandos neste guia são validados contra a documentação atual do Ollama, mas as saídas de terminal mostradas abaixo são exemplos representativos em vez de capturas de benchmark ao vivo. Use-os como um padrão de sucesso, não como uma afirmação de desempenho.

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

O Servidor GPU Ubuntu Exato Usado para Este Guia

Este passo a passo é ancorado numa máquina Ubuntu real com uma única GPU, porque conselhos vagos do tipo “deve funcionar na maioria dos servidores” é como os guias de auto-hospedagem se tornam enganosos. A caixa de referência aqui é a classe real de host usada 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 passar direto para um rack de aceleradores empresariais. Ainda discutirá comportamento multi-GPU mais tarde, porque o Ollama muda uma vez que um modelo ultrapassa um cartão, 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 de classe 8B do dia a dia e ainda uma útil para trabalho local maior até ao ponto em que 16GB de VRAM se torna a verdadeira restrição. Um modelo como llama3.1:8b com aproximadamente 4.9GB cabe facilmente neste cartão. Um modelo como gpt-oss:20b com aproximadamente 14GB é o tipo de teste de GPU única de extremidade superior que ainda faz sentido aqui. Um modelo como qwen3:30b com aproximadamente 19GB é melhor tratado como um ponto de referência para o que muda num host maior ou dual-GPU do que como um ajuste limpo para esta máquina exata.

Essa distinção importa porque o ponto deste artigo não é espremer o maior número possível numa manchete. É mostrar como um servidor LLM auto-hospedado sensato se parece quando 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-hospedada se torna realista, não teórica.

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

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

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

Execute a verificação de GPU primeiro:

nvidia-smi

❗Se Ubuntu disser que nvidia-smi está ausente, não assuma que o servidor não tem GPU. Um modo de falha comum em caixas Ubuntu alugadas é que o cartão está presente mas ainda vinculado ao nouveau em vez do driver NVIDIA. Verifique primeiro a seção “Corrigir Problema do Driver Nvidia no Ubuntu“.

Um resultado saudável nesta classe de servidor deve parecer aproximadamente assim:

Assim que nvidia-smi funcionar e a GPU estiver visível, continue com as verificações abaixo.

O que você quer confirmar é simples: a GPU instalada está visível, ela relata aproximadamente 16GB de VRAM neste host, e o driver está carregado corretamente. Se você estiver em um servidor multi-GPU, o mesmo comando deve listar cada cartão.

nvidia-smi -L

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

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

lsb_release -a

Finalmente, verifique o espaço em disco livre antes de começar a baixar modelos. A instalação em si é pequena; os modelos não são. Assim que você passar além de testes pequenos, uma biblioteca de 20B-30B pode consumir dezenas de gigabytes rapidamente, então 100GB+ livres é a mentalidade correta antes de trabalho sério com modelos locais.

df -h /

Se estas verificações passarem, você limpou as principais incógnitas de infraestrutura: as GPUs estão presentes, a linha de base do driver é saudável, Ubuntu é confirmado, e o disco tem espaço para pulls de modelos reais. Esse é o ponto em que instalar Ollama se torna um próximo passo limpo em vez de um palpite.

Corrigir Problema do Driver Nvidia no Ubuntu

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

lspci -nnk | grep -A3 -Ei 'VGA|3D|NVIDIA'

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

Instale o pacote ubuntu-drivers-common (necessário para gerenciamento de driver) e os headers do kernel para seu kernel em execução.

apt update
apt install -y ubuntu-drivers-common linux-headers-$(uname -r)

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

ubuntu-drivers devices

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

apt install -y nvidia-driver-595-open
reboot

Após a reinicialização, execute novamente:

nvidia-smi
nvidia-smi -L

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

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

Execute o instalador exatamente como documentado:

curl -fsSL https://ollama.com/install.sh | sh

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

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

sudo systemctl status ollama --no-pager

Você está procurando três coisas aqui: o arquivo de unidade está presente, o serviço está habilitado para inicialização e Active: active (running) confirma que o servidor está realmente ativo.

Primeiro, estabeleça a conta de usuário do serviço Linux de forma concreta e apenas depois pense em como e onde o armazenamento do modelo será tratado.

getent passwd ollama

Essa única linha explica muito do comportamento futuro. Os modelos no Linux vivem sob a propriedade do serviço, e se você os mover para outro disco posteriormente sem corrigir as permissões para o usuário ollama, você cria sua própria falha.

Uma verificação a mais fecha o loop na vinculação padrão:

ss -tlnp | grep 11434

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

Se o serviço não iniciar corretamente, vá aos logs primeiro em vez de reinstalar cegamente:

journalctl -u ollama -n 100 --no-pager

Essa é a forma mais rápida de detectar problemas de permissão, erros de inicialização, problemas de detecção de driver ou problemas de vinculação. Depois que o serviço estiver saudável no localhost, a próxima coisa a entender é como o posicionamento de GPU se comporta em tempo de execução.

Como o Ollama Realmente Usa Uma ou Múltiplas GPUs

Mesmo que o servidor usado para este guia tenha uma GPU, o comportamento multi-GPU ainda vale a pena entender porque muitos usuários podem estar em máquinas maiores ou podem expandir mais tarde. Muita confusão com duas GPUs começa com a expectativa errada: “Tenho dois cartões, então ambos devem estar ativos o tempo todo.” Não é assim que o Ollama funciona. A regra prática é muito mais simples: se um modelo cabe em uma GPU, o Ollama geralmente o mantém em uma GPU. Ele só se espalha por múltiplas GPUs quando o modelo não cabe confortavelmente em um único cartão.

Use estas duas verificações juntas sempre que quiser ver o desempenho da GPU:

ollama ps

watch -n 1 nvidia-smi

ollama ps informa como o modelo carregado está sendo 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á sendo usada. Um estado misto informa que parte da carga de trabalho ou residência vazou para fora do caminho GPU. watch -n 1 nvidia-smi complementa isso mostrando o uso de VRAM em tempo real por cartão enquanto o modelo está carregado.

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

📝 Nota: CUDA_VISIBLE_DEVICES é um controle de visibilidade, não um interruptor “use ambas as GPUs”. Se você alguma vez restringir o acesso à GPU, prefira os UUIDs de nvidia-smi -L em vez de IDs numéricos porque a ordem das GPUs pode variar entre ambientes e reinicializações.

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

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

Comece puxando o modelo:

ollama pull mistral

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

ollama run mistral "In one sentence, explain why people self-host LLMs."

Para provar que esta é inferência com suporte GPU em vez de um fallback de CPU, verifique o estado de tempo de execução:

ollama ps

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

ollama list

mistral é a prova correta em primeiro lugar porque oferece uma resposta rápida sem transformar a validação de configuração em uma longa espera. Mais tarde, llama3.1:8b torna-se mais útil porque é uma linha de base alinhada mais forte para comparar o comportamento do modelo.

Finalmente, verifique onde a instalação Linux está armazenando modelos:

sudo du -sh /usr/share/ollama/.ollama/models

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

Depois que você vir uma resposta bem-sucedida, 100% GPU em ollama ps e uso de disco aumentando no local esperado, você terá 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 comando é útil, mas a razão para auto-hospedar Ollama não é apenas conversar dentro de um terminal. É executar um servidor de inferência local que outras ferramentas, scripts e aplicações podem chamar sem enviar prompts através da API de outra pessoa. A prova mais rápida é um HTTP request limpo para o endpoint nativo do Ollama.

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

curl http://localhost:11434/api/generate -d '{
"model": "mistral",
"prompt": "Say hello from a self-hosted Ollama server in one sentence.",
"stream": false
}'

Uma resposta bem-sucedida deve voltar como JSON e parecer aproximadamente assim:

{
  "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 HTTP request funciona localmente, JSON válido volta, done: true está presente, e a resposta do modelo está em response. Esse é o ponto em que Ollama deixa de ser “um CLI que acontece de baixar modelos” e se torna infraestrutura que você pode realmente integrar em ferramentas locais e automação.

Se você quer compatibilidade com software que espera um formato de request estilo OpenAI, Ollama também expõe endpoints /v1 localmente:

curl -X POST http://localhost:11434/v1/chat/completions
-H "Content-Type: application/json"
-d '{
"model": "mistral",
"messages": [
{"role": "user", "content": "Say this is a test."}
]
}'

📝 Nota: Esse rótulo “compatível com OpenAI” é fácil de ser mal interpretado. Isso não significa que você está falando com OpenAI, e não muda o fato de que o servidor ainda é local. Significa apenas que o formato do request é familiar o suficiente para ferramentas e SDKs construídos em torno do padrão de API OpenAI. A URL base permanece http://localhost:11434/v1/, e qualquer chave API de placeholder que algumas bibliotecas de cliente insistem pode ser ignorada para uso local do Ollama.

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

Esta é a parte que geralmente é achatada em uma única ideia vaga de “censura”, mas tecnicamente existem três camadas diferentes envolvidas: a camada de serviço do fornecedor, o alinhamento do modelo e o ajuste de instruções, e o comportamento de prompt/runtime que você controla. Self-hosting muda algumas dessas camadas dramaticamente. Não apaga todas elas.

Uma maneira simples de visualizar é assim:

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
– O limite de rede local e logging passa a ser seu
– O próprio treinamento e alinhamento do modelo ainda vêm com o modelo

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

Você pode pensar nisso como uma produção teatral. Self-hosting muda o palco, a iluminação, os microfones e as notas do diretor. 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 treinamento.

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

É aí que entra a escolha do modelo. Se você quer o efeito prático de menos avisos, respostas mais diretas ou comportamento menos pesado em recusas, você não chega lá dizendo “self-hosted” mais alto. Você chega lá escolhendo uma família de modelo ou fine-tune diferente — e compreendendo os tradeoffs que vêm com isso.

Escolha um Modelo Local Menos Restrito

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

Puxe os modelos de comparação localmente:

ollama pull llama3.1:8b

ollama pull dolphin3

# Optional older reference model
ollama pull dolphin-mistral

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

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

Desempenho de GPU

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

Neste servidor, o melhor teste de runtime de gama alta é gpt-oss:20b. É grande o suficiente para ser interessante enquanto ainda faz sentido numa placa de 16GB.

ollama pull gpt-oss:20b

ollama stop mistral

ollama run gpt-oss:20b "Explain in one paragraph why a 14GB model is a realistic upper-end single-GPU test on a 16GB card."

Após o modelo carregar, confirme o estado de runtime:

ollama ps

Essa é a prova prática que você quer nesta máquina. Mostra que modelos menores cabem facilmente e que um modelo local maior, mas ainda realista, pode levar uma placa de 16GB perto do seu envelope utilizável sem precisar de múltiplas GPUs.

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

Considerações sobre Contorno de Censura

Para comparação de comportamento, mantenha as condições controladas para que você esteja testando o modelo mais do que a aleatoriedade. Use o mesmo endpoint, o mesmo prompt, stream: false, uma temperatura baixa e uma seed fixa:

curl http://localhost:11434/api/generate -d '{
"model": "llama3.1:8b",
"prompt": "<comparison prompt>",
"stream": false,
"options": {
"temperature": 0.2,
"seed": 42
}
}'

Em seguida, repita o mesmo pedido com “model”: “dolphin3”. A seed fixa 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-hospedagem de um LLM significa que o usuário controla totalmente o comportamento do modelo? Responda em 4 pontos. Seja direto e pule preâmbulos.” Uma resposta representativa de 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 de dolphin3 para o mesmo prompt frequentemente soa mais simplificada:

   - 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 argumento afiado de cinco frases sobre por que uma equipe sensível à privacidade pode rejeitar IA gerenciada por fornecedor. Sem introdução e sem conclusão.” llama3.1:8b geralmente cumpre, mas em um tom corporativo mais medido. dolphin3 segue mais prontamente a nitidez solicitada. Esse é o tipo de diferença que você está procurando aqui: não uma saída dramaticamente sem lei, mas mudanças em diretividade, enquadramento e densidade de isenção de responsabilidade.
3. A terceira categoria de prompt para validação pode ser a seguinte: peça cinco razões factuais pelas quais um escritor pode preferir um modelo local para trabalho criativo incomum, de nicho ou não-convencional. Na prática, ambos os modelos respondem, mas dolphin3 tende a ficar mais próximo do tom não-moralizante solicitado e respostas diretas.

O padrão se parece com isto:

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

1. A escolha do modelo local muda significativamente o comportamento da saída.
2. Diferentes modelos variam em diretividade e densidade de isenção de responsabilidade.
3. O auto-hospedagem remove uma camada de serviço controlada por fornecedor.

Agora Você Controla a Stack, Não Apenas o Prompt

A frustração desde o início deste guia nunca foi apenas sobre um modelo recusando um pedido. Era sobre o fato de que a camada de serviço, camada de política e limite de privacidade viviam em outro lugar. Após esta configuração, essa parte mudou. Seu servidor de inferência é executado na sua máquina Ubuntu, o limite de API local é seu, o menu de modelos é seu, e seus padrões de prompt/runtime são seus para ajustar.

O que ainda requer julgamento é a parte que nenhum instalador pode resolver para você: escolher modelos que correspondam ao seu caso de uso, orientá-los com padrões sensatos e expor o acesso com segurança se você ir além do localhost. Essa é a forma real do controle de auto-hospedagem. Não é liberdade mágica de todas as restrições, mas propriedade da stack que decide como, onde e com qual modelo a inferência acontece. Se você quer o melhor próximo passo, comece criando um Modelfile personalizado — ou colocando acesso remoto seguro na 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 da GPU é real, e as diferenças de comportamento do modelo não são mais abstratas. O próximo passo não é “instalar mais coisas às cegas.” É ajustar as partes da pilha que agora pertencem a você.

Personalizando o Comportamento do Modelo com um Modelfile

Um Modelfile é a forma mais limpa de alterar os padrões de prompting local sem tocar nos pesos do modelo. Comece inspecionando a definição atual do modelo para entender o que você está estendendo:

ollama show --modelfile dolphin3

Depois 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:

ollama create dolphin3-local -f ./Modelfile
ollama run dolphin3-local "Summarize what changed in this custom model in 3 bullets."

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

Protegendo a Configuração

A vinculação 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:

ss -tlnp | grep 11434

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

sudo systemctl edit ollama

Adicione o seguinte:

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

Depois recarregue e reinicie o serviço:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Se você precisar de acesso remoto mais tarde, não publique 11434 diretamente. Coloque um proxy reverso com TLS e autenticação na frente dele:

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 endurecimento separado. Ollama por si só é um servidor de inferência local, não um gateway de API 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 que a instalação base funciona, a melhoria de maior valor é escolher modelos que realmente se ajustem bem a esta máquina em vez de perseguir o maior destaque. Para o servidor single-4070 Ti SUPER usado aqui, o menu prático se parece com isto:

Inicialização Automática e Manutenção

Depois da parte divertida vem a parte que mantém um servidor LLM local utilizável um mês a partir de agora. Confirme o comportamento no tempo de inicialização, mantenha o serviço atualizado, observe os logs e saiba como descarregar modelos grandes quando você precisar do VRAM de volta.

sudo systemctl is-enabled ollama

sudo systemctl enable --now ollama

curl -fsSL https://ollama.com/install.sh | sh

journalctl -u ollama -n 100 --no-pager

Para operações de modelo do dia a dia, estes são os comandos que você usará com mais frequência:

ollama list
ollama ps
ollama stop gpt-oss:20b
sudo du -sh /usr/share/ollama/.ollama/models

E se o armazenamento de modelo tiver que se mover para um disco maior, prepare o diretório para o usuário do serviço antes de reapontar o Ollama:

sudo mkdir -p /mnt/ai/ollama-models
sudo chown -R ollama:ollama /mnt/ai/ollama-models

Depois defina OLLAMA_MODELS através de systemctl edit ollama. Esse detalhe de propriedade é o que impede que uma migração de armazenamento se transforme em um problema de permissões.

Referência de Resolução de Problemas

Quando algo quebra, o caminho mais rápido é geralmente corresponder o sintoma à camada correta em vez de tentar loops de reinstalação aleatória. Use esta tabela como a primeira passagem:

Se você só se lembrar de uma regra operacional desta seção, deixe ser esta: trate o Ollama como um serviço real, não como um utilitário CLI descartável. Logs, propriedade, endereços de vinculação e caminhos de armazenamento importam tanto quanto a janela de prompt.