Conteúdo detalhado
📏 Janela de contexto na prática
A janela de contexto é quanta coisa o modelo "lê de uma vez" antes de responder — sua pergunta, o histórico do chat e qualquer texto que você cole. Se a janela for pequena, o modelo "esquece" o começo da conversa. Se for grande demais, ela come memória sem necessidade.
🆕 Novo aqui?
"Janela de contexto" = o limite de tokens que entram de uma vez (ex.: 8192 = ~6 mil palavras). No Ollama isso é o parâmetro num_ctx. "Token" = um pedaço de palavra; ~4 caracteres em média. "KV cache" = a memória de trabalho que o modelo monta para cada token do contexto — ela cresce junto com num_ctx e é o que faz contexto longo pesar na VRAM.
Decidir o tamanho da janela é um equilíbrio em três passos:
Comece pelo padrão
Muitos modelos vêm com num_ctx de 2048 ou 4096. Para chat e perguntas curtas, isso já basta — não mexa só por mexer.
Aumente quando a tarefa pede
Vai colar um documento longo, código grande ou um histórico extenso? Suba para 8192, 16384 ou mais — desde que o modelo suporte aquele limite.
Pague o preço em memória
Dobrar a janela ≈ dobrar o KV cache. Se a VRAM estourar, o modelo desce camadas para a CPU e fica lento — ou simplesmente dá out of memory.
💡 Dica prática
Não ligue 128k de contexto "por garantia". Se você normalmente faz perguntas curtas, uma janela de 4k–8k responde mais rápido e libera VRAM para as camadas do modelo — que é o que mais importa para a qualidade.
🌡️ Temperatura, top_p e top_k
A cada token, o modelo tem várias palavras candidatas. Temperatura, top_p e top_k decidem o quanto ele se arrisca na hora de escolher. Esses três botões controlam o eixo preciso ⟷ criativo.
🆕 Novo aqui?
- Temperatura — quão "criativo/aleatório" o modelo é. Baixa (0–0.3) = determinístico e repetível; alta (0.8–1.2) = diverso e surpreendente.
- top_p (nucleus) — corta a cauda: só considera as palavras que somam, por exemplo, 90% da probabilidade (top_p 0.9).
- top_k — limita a escolha às k palavras mais prováveis (top_k 40). Mexa em temperatura primeiro; top_p/top_k são ajuste fino.
📋 Receitas por tarefa
| Tarefa | temperatura | top_p | Por quê |
|---|---|---|---|
| Código / SQL | 0.1–0.2 | 0.9 | precisão e respostas reproduzíveis |
| Extração / JSON | 0.0–0.2 | 0.8 | formato rígido, sem inventar campos |
| Chat / explicação | 0.5–0.7 | 0.9 | natural, mas ainda focado |
| Brainstorm / criativo | 0.9–1.2 | 0.95 | diversidade, ideias inesperadas |
✓ Temperatura baixa serve para
- ✓Gerar código que precisa compilar
- ✓Extrair dados em formato fixo
- ✓Respostas que devem ser sempre iguais
- ✓Classificação e roteamento
✓ Temperatura alta serve para
- ✓Gerar muitas variações de uma ideia
- ✓Textos de marketing e títulos
- ✓Quebrar repetição e respostas "engessadas"
- ✓Ficção e roteiros
🎭 System prompt: dirigindo o modelo
Antes de qualquer pergunta, o system prompt diz ao modelo quem ele é e como deve responder. É a alavanca de qualidade mais barata que existe: bem escrito, ele corrige verborragia, formato e tom sem você trocar de modelo.
🆕 Novo aqui?
"System prompt" é uma instrução fixa, separada da sua mensagem, que vale para a conversa toda. Pense nele como o "cargo e regras do funcionário": define papel (o que ele é), formato (como entrega) e restrições (o que não pode fazer).
🧱 Os três blocos de um bom system prompt
- •Papel: "Você é um assistente técnico conciso para desenvolvedores."
- •Formato: "Responda em no máximo 5 linhas. Use bullets quando listar passos."
- •Restrições: "Se não souber, diga que não sabe. Não invente comandos."
⌨️ Exemplo prático: um "assistente técnico conciso"
Objetivo: um system prompt reutilizável que você cola em qualquer modelo (Ollama, Open WebUI, API) para respostas curtas e diretas. Salve como system.txt ou use no Modelfile.
Como usar no Ollama (Modelfile):
Como verificar: faça a mesma pergunta no modelo base e no tecnico. O segundo deve responder bem mais curto e direto, sem o "Claro! Aqui está...".
🧩 Offload GPU/CPU e camadas
Um modelo é uma pilha de camadas. O ideal é que todas caibam na GPU, onde rodam rápido. Quando não cabem, o runtime transborda as que sobram para a CPU — e essas ficam bem mais lentas. O parâmetro que controla isso é o num_gpu.
🆕 Novo aqui?
"Offload" = empurrar parte do trabalho da GPU para a CPU. "num_gpu" (no Ollama) = quantas camadas do modelo são colocadas na GPU; o resto vai para a CPU/RAM. Mais camadas na GPU = mais rápido, desde que caibam na VRAM. Se você forçar camadas demais e a VRAM estourar, vira out of memory.
Leia da esquerda para a direita: as 7 primeiras camadas (roxo) couberam na GPU e voam; as 3 que sobraram (ciano) transbordaram para a CPU e arrastam a velocidade. Subir num_gpu move a fronteira para a direita — até a VRAM encher.
✓ Offload equilibrado
- ✓Caem todas (ou quase) as camadas na GPU
- ✓Sobra VRAM para o KV cache do contexto
- ✓Escolheu um quant (Q4_K_M) que cabe folgado
- ✓tokens/s estável e previsível
✗ Offload mal ajustado
- ✗Metade das camadas foi parar na CPU
- ✗num_gpu forçado alto → out of memory
- ✗Modelo grande demais para a VRAM disponível
- ✗Velocidade despenca a cada token
💡 Dica prática
O Ollama tenta detectar o offload sozinho — na maioria dos casos, deixe automático. Só ajuste num_gpu manualmente se você quiser caber um modelo um pouco maior (descendo algumas camadas de propósito) ou se rodar duas coisas na mesma GPU.
⚡ KV cache, batch e desempenho
Velocidade não é só "GPU boa". Três coisas mexem no tokens/s: quanta memória o KV cache come, o tamanho do batch e onde as camadas estão. Aqui você junta os parâmetros num lugar só — via API.
📊 O que acelera × o que desacelera
- ✓Modelo cabendo inteiro na GPU
- ✓Janela de contexto só do tamanho que precisa
- ✓Quantização de KV cache (q8/q4) para liberar VRAM
- ✓Manter o modelo "quente" (carregado) entre chamadas
- ✗Camadas transbordando para a CPU
- ✗num_ctx gigante "por garantia"
- ✗Swapping em disco quando a RAM enche
- ✗Recarregar o modelo a cada requisição
🆕 Novo aqui?
"Batch" = quantos tokens o modelo processa de uma vez na fase de leitura do prompt; batch maior acelera prompts longos, mas usa mais memória. "Quantização de KV cache" = guardar a memória de trabalho em precisão menor (ex.: q8_0) para caber contexto maior na mesma VRAM — com perda mínima.
⌨️ Exemplo prático: parâmetros via API do Ollama
Objetivo: rodar uma geração controlada, passando temperatura e janela de contexto juntas no campo options. Cole no terminal (o Ollama precisa estar rodando).
Como verificar: rode o mesmo comando duas vezes. Com temperature:0.2 as respostas saem quase idênticas (determinístico). Troque para 1.0 e repita: agora elas variam bem mais. O campo eval_count / eval_duration na resposta JSON te dá os tokens/s.
🩺 Diagnóstico: por que está lento ou ruim?
Quando a saída decepciona, o problema quase sempre é um dos quatro suspeitos: modelo grande demais, quantização agressiva demais, contexto enorme ou swap em disco. Este checklist separa "está lento" de "está ruim".
✗ Sintoma: está LENTO
- ✗Modelo grande demais → camadas na CPU
- ✗num_ctx enorme → KV cache estourou a VRAM
- ✗RAM cheia → swapping em disco
- ✗Modelo recarregando a cada chamada
✓ Como resolver o LENTO
- ✓Desça um tamanho (14B → 7B) ou um quant
- ✓Reduza num_ctx para o que a tarefa exige
- ✓Feche apps que comem RAM; cheque com ollama ps
- ✓Mantenha o modelo carregado (keep-alive)
✗ Sintoma: está RUIM
- ✗Quant agressivo (Q2/Q3) → respostas frágeis
- ✗Temperatura alta numa tarefa que pede precisão
- ✗Sem system prompt → modelo "viaja"
- ✗Contexto curto → ele esquece o início
✓ Como resolver o RUIM
- ✓Suba para Q4_K_M/Q5_K_M (o ponto doce)
- ✓Baixe a temperatura para 0.1–0.2
- ✓Adicione um system prompt claro (tópico 3)
- ✓Aumente num_ctx o suficiente para a conversa
Auto-checagem (opcional): você precisa gerar SQL que seja sempre igual e correto. Qual ajuste faz mais sentido?
📌 Resumo do módulo
Próximo módulo:
3.5 — Servindo via API local