Configurando LLMs localmente para uso pessoal

Tudo começa com uma aplicação que seja capaz de executar LLMs localmente. Existem várias aplicações e serviços que fazem isso. Resolvi utilizar Ollama por pura conveniência, mas fui agraciado com um bom suporte a ele também.

A configuração do Ollama no Arch Linux é extremamente simples, basta utilizar um script de instalação que eles mesmos fornecem.

Você pode ver o script aqui. Estou evitando escrevê-lo diretamente para evitar ataques ou qualquer coisa que o valha, através de substituição de texto.

Usar as LLMs através do terminal é bem possível, mas queremos um pouco de comodidade.

Acho que a maioria das pessoas na área da tecnologia e da programação iria querer utilizar essas LLMs com editores de texto e ferramentas que as deixam mais confortáveis como o VSCode, mas no meu caso, sou um heavy user de Emacs, e preciso que essas ferramentas funcionem com ele.

Surpreendentemente, parece que as extensões para Emacs são inclusive muito flexíveis e extensíveis, talvez mais do que muitas por aí. Escolhi utilizar o Ellama, que fornece muita integração, inclusive com Org Mode.

Outra coisa legal de se ter, também, é uma interface gráfica para interagir com os modelos. Eu acabei optando por usar o Open WebUI, que aparentemente é extensível a ponto de tolerar mais ferramentas caso você queira partir para coisas como geração de imagens, por exemplo. Mas como não é meu objetivo, realizei um deploy mais simples.

Isso talvez soe um pouco invasivo, mas o Open WebUI é melhor executado através de Docker⁴. Isso é um pouco chato pensando do ponto de vista de que estou servindo uma aplicação no meu próprio computador só para ter uma interface gráfica, mas depois de resmungar um pouco, eu só aceitei, mesmo.

O único ponto de atenção aqui é que o Open WebUI deve conseguir acessar… advinhe só… o seu Ollama. Existe inclusive uma versão do contêiner já com o Ollama embutido, caso você queira algo mais unificado, e não vá depender do Ollama para outros serviços (o que não é meu caso, já que estou acessando também via Emacs).

Esse ponto não é um grande problema caso você esteja usando Docker Desktop no Windows⁵, porque ele já exporta um host customizado para que o contêiner tenha acesso às portas do seu computador.

No caso do Linux, você precisa adicionar esse host manualmente⁶.

Uma das formas de rodar o contêiner é através da linha de comando, usando o Docker "puro". O comando a seguir vai executar o Open WebUI com uma configuração para sempre reiniciar o contêiner caso ele seja encerrado (inclusive se você reiniciar o computador), a não ser que você destrua o contêiner:

docker run -d \
       -p 3111:8080 \
       --add-host=host.docker.internal:host-gateway \
       -v open-webui:/app/backend/data \
       --name open-webui \
       --restart always \
       ghcr.io/open-webui/open-webui:main

O comando acima "quebra um galho", mas eu achei particularmente ruim para substituir o contêiner em caso de atualização, porque eu precisaria dar docker pull na imagem novamente, e precisaria ficar copiando e colando o comando acima. Então acabei montando um docker-compose.yml para me ajudar com isso:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: always
    environment:
      PORT: "3111"
    extra_hosts:
      - "host.docker.internal:host-gateway"
    volumes:
      - open-webui:/app/backend/data
    network_mode: host

volumes:
  open-webui:
    external: true

Veja que eu marquei o volume open-webui com external: true unicamente porque eu já havia executado a ferramenta com Docker "puro", e queria manter meu volume que já estava com várias configurações. Caso você esteja executando diretamente no Docker Compose, pode remover isso sem problemas.

Veja também que eu estou rodando o contêiner em network_mode: host. Isso significa que ele basicamente não passa pelo processo de mapeamento da porta padrão da aplicação para o computador, e caso eu tivesse mais contêineres, eles não estariam em uma única malha capaz de fazer com que eles comuniquem entre si.

Em vez disso, eu estou configurando a aplicação diretamente (através da variável de ambiente PORT) para rodar na porta 3111. Esse detalhe do modo de networking do contêiner pode ser importante, caso você precise alterar esse arquivo do Docker Compose.

Depois de toda essa configuração, eu tenho o Open WebUI rodando no meu computador na porta 3111, e tudo o que preciso fazer é ir até o diretório da configuração e executar um docker compose up -d. Se eu precisar atualizar… docker compose down, docker pull na imagem, docker image prune para remover o lixo (ou deletar direto via lazydocker⁷), e subir o serviço de novo. Já está com o restart: always, então se eu reiniciar o computador, nem preciso me preocupar.

Tudo funcionou muito bem, mas agora estamos em um ponto crítico: Tudo isso só funciona no meu computador. E se você for como eu, muito provavelmente você tem um firewall bem-configurado no seu computador que não esteja permitindo, no momento, acesso externo a nenhuma porta sua. Espera… Não?! Então vamos instalar o ufw primeiro.

O Uncomplicated Firewall (UFW) é uma camada em cima do iptables que garante certa simplicidade ao configurar regras de firewall. Por padrão, ele não permite nenhuma entrada, em nenhuma porta.

Depois de instalar o ufw na sua distribuição Linux, ative-o através do systemd, caso você também use esse sistema de inicialização.

sudo systemctl enable ufw
sudo systemctl start ufw

Para o meu caso de uso, eu me concentrei em dois acessos externos no meu computador. O primeiro seria o acesso ao Open WebUI pelo menos no meu celular, mas desejavelmente no meu laptop de trabalho também; o segundo seria o acesso ao Ollama (via Emacs e Ellama também), diretamente através do meu laptop de trabalho, um sistema com Ubuntu, que eu potencialmente levaria para fora da minha casa.

Esse é o caso para alguma aplicação que permita o tunelamento entre vários dispositivos. Por sorte, existe uma solução muito legal pra isso: o Tailscale⁸, que eu já uso desde que surgiu, inclusive para experimentos envolvendo Kubernetes, e que agora eu posso usar para garantir a comunicação segura entre os três dispositivos.

A princípio, bastou seguir os passos de instalação para Android e para os dois Linux, como orientado no site oficial, e fazer login na minha rede privada e pessoal.

Uma vez na rede, do ponto de vista do meu computador, pude executar o seguinte comando e obter saídas como essas (navi é o meu laptop executando o Ollama e o Open WebUI):

➜  ~ tailscale status
100.65.xx.xx    navi              luksamuk@  linux    -
100.117.xx.xx   <pc-de-trabalho>  luksamuk@  linux    offline, last seen 6h ago
100.82.xx.xx    <celular>         luksamuk@  android  idle, tx 5374104 rx 948116

Para garantir uma boa segurança, criei as seguintes regras no UFW:

1. Meu computador de trabalho deve ser capaz de se conectar às portas 11434 e 3111, porque quero acessar tanto o Open WebUI, quanto acessar diretamente o Ollama através do Emacs⁹.
2. Meu celular deve ser capaz de se conectar apenas à porta 3111, porque ele será capaz de acessar apenas a Open WebUI.

Só precisamos traduzir essas duas ideias em três simples comandos de configuração do UFW. No caso, especifico os IPs dos dispositivos para garantir que eles só consigam acessar meu computador através da rede Tailscale (essa configuração não é exaustiva porque eu poderia usar a interface de rede da aplicação, mas é suficiente).

sudo ufw allow from 100.117.xx.xx to any port 11434 proto tcp
sudo ufw allow from 100.82.xx.xx to any port 3111 proto tcp
sudo ufw allow from 100.117.xx.xx to any port 3111 proto tcp

Para checar se deu tudo certo¹⁰:

➜  ~ sudo ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 11434/tcp                  ALLOW IN    100.117.xx.xx
[ 2] 3111/tcp                   ALLOW IN    100.82.xx.xx
[ 3] 3111/tcp                   ALLOW IN    100.117.xx.xx