Ollama e runners locais

01 · Conceito

Conceito

Duas pessoas rodam o mesmo GGUF Q4_K_M fixado de 17,1 GB do Qwen3.8-27B no mesmo laptop, fazem a mesma pergunta e recebem respostas com temperamentos visivelmente diferentes — uma seca e literal, a outra prolixa e propensa a inventar detalhe. Nenhuma das duas editou um arquivo de config. A diferença é que uma delas está rodando o engine da lição 8.7 diretamente, com flags explícitas, e a outra está rodando o mesmo engine através de uma camada de conveniência que forneceu parâmetros de sampling em seu nome. Esta lição é sobre essa camada: o que ela genuinamente dá a você e o único hábito de configuração que a impede de mudar o seu modelo em silêncio.

Um runner local como o Ollama não é um engine de inferência. É uma camada de distribuição, configuração e ciclo de vida embrulhada em torno de um — neste caso o stack llama.cpp e ggml. Ele contribui com três coisas que o engine deliberadamente não tem. Primeiro, um registry: modelos são endereçados por nome e tag em vez de por uma URL para um arquivo específico, então puxar um modelo é um comando e o runner resolve qual variante de quantization buscar para o seu hardware. Segundo, um Modelfile, uma pequena receita declarativa que amarra um GGUF a um chat template, um system prompt, sequências de parada e parâmetros de sampling, e que pode ser construída num novo modelo nomeado que herda de outro. Terceiro, um servidor local: um processo de vida longa na interface de loopback expondo uma API de chat, incluindo rotas compatíveis com OpenAI, que carrega um modelo na primeira requisição, mantém-no residente por um intervalo de keep-alive e o despeja para abrir espaço para outro. Essa última peça é o que faz um runner parecer diferente do engine — você para de pensar em processos e passa a pensar em nomes de modelo.

O custo dessa conveniência é que agora existem padrões onde antes só havia as suas flags, e os padrões que você não escolheu são os que mordem. O Qwen3.8-27B publica dois presets de sampling no seu model card. Thinking mode, o comportamento padrão, espera temperature 1.0, top_p 0.95, top_k 20. Instruct mode — o caminho sem thinking — espera temperature 0.7, top_p 0.80, top_k 20. Não são sugestões estilísticas; são as configurações sob as quais o comportamento reportado pelo fornecedor foi produzido. Uma entrada de registry traz o que quer que o seu empacotador tenha posto no Modelfile, e não existe mecanismo que garanta que isso casa com o card. Se você implanta um assistente sobre padrões não examinados, você está avaliando uma configuração que ninguém documentou.

Então fixe. Escreva um Modelfile que herda da tag baixada e declara cada parâmetro com que você se importa, depois construa um modelo local nomeado e use só esse nome a partir da sua aplicação.

FROM qwen3.8:27b
PARAMETER temperature 0.7
PARAMETER top_p 0.80
PARAMETER top_k 20
PARAMETER min_p 0
PARAMETER repeat_penalty 1.0
PARAMETER presence_penalty 1.5
PARAMETER num_ctx 16384

Construa com ollama create qwen3.8-27b-instruct -f Modelfile e aponte o seu cliente para qwen3.8-27b-instruct. A configuração de sampling agora é um artefato versionado no seu repositório em vez de uma propriedade da máquina que por acaso está servindo.

Percorra o que cada linha compra. Além de temperature, top_p e top_k, o Ollama expõe min_p, repeat_penalty e presence_penalty. Fixe as seis opções de sampling como no exemplo e verifique a requisição efetiva e o backend, para que a configuração siga o preset instruct do card — e se você quiser thinking mode, constrói um segundo modelo nomeado com 1.0 e 0.95, em vez de alternar valores na mão e esquecer. A linha num_ctx é a que as pessoas omitem, e é a mais consequente. O Ollama hoje assume 4K abaixo de 24 GiB de VRAM, 32K entre 24 e 48 GiB e 256K a partir de 48 GiB, contra o contexto nativo de 262.144 tokens deste modelo. Esse padrão não é preguiça: a janela é uma promessa de memória, porque comprimento de contexto vezes os 64 KiB por token da lição 7.2 é KV cache que o runner precisa reservar. Em 16.384 tokens o cache é 1 GiB. Na máquina classe 24 GiB da lição, isso é um cap deliberado abaixo do padrão atual de 32K, escolhido para deixar folga ao lado do artefato Q4_K_M fixado de 17,1 GB. Em 262.144 tokens são 16 GiB, o que não é. Escolha a janela que a sua carga de fato usa e pague exatamente por ela.

Duas armadilhas menores decorrem do empilhamento. Opções por requisição enviadas pela API sobrescrevem parâmetros do Modelfile naquela requisição, o que é útil e também significa que um padrão perdido do lado do cliente pode desfazer a sua fixação cuidadosa — audite o que o seu SDK manda quando você não passa nada. E este modelo traz um thinking mode cujo comportamento é controlado pelo chat template e por um toggle por requisição, não pelo sampling sozinho; a chave do próprio model card é enable_thinking, e o runner expõe a sua flag equivalente, então confira a documentação atual pelo nome em vez de supor que abaixar a temperatura desligou o raciocínio. Não desligou. Só deixou o raciocínio menos variado.

O hábito durável é pequeno: trate o runner como empacotamento, nunca como política. Ele decide onde o arquivo mora e como o servidor se comporta; você decide o preset de sampling, a janela de contexto e o system prompt, e escreve essas decisões num Modelfile que viaja junto com o seu código. A lição 8.12 põe este stack ao lado dos de classe servidor e pergunta quando a conveniência vale o seu teto.