Conteúdo detalhado
📏 Medindo: tokens/s, latência e memória
Você não consegue melhorar o que não mede. Antes de comprar hardware ou culpar o modelo, capture três números: velocidade de geração (tokens/s), tempo até a primeira palavra (latência) e quanto da memória está sendo usada — e por quem (GPU ou CPU).
🆕 Novo aqui?
- tokens/s = quantos "pedaços de palavra" o modelo gera por segundo. Acima de ~15 tok/s a leitura flui como um chat; abaixo de ~5 já incomoda.
- latência = o tempo de espera antes da resposta começar a sair (carregar o modelo + processar seu prompt). Contexto longo aumenta a latência.
- OOM = out of memory: a memória (VRAM/RAM) acabou e o modelo não cabe. É o erro nº 1 do lab local — voltamos nele no tópico 5.
⌨️ Exemplo prático: meça o seu lab
Objetivo: ver o que está carregado, onde roda (GPU x CPU) e a velocidade real de geração. Cole no terminal.
Como verificar: no fim da geração, olhe eval rate — é o seu tokens/s. No ollama ps, a coluna PROCESSOR mostra o split: 100% GPU é o ideal; se aparecer CPU, parte do modelo "vazou" pra RAM e ficou lento.
📊 O que é "bom o suficiente"
- Chat interativo: > 15 tok/s e latência < 2 s parecem instantâneos para um humano lendo.
- Agente 24/7 / batch: velocidade quase não importa — ele trabalha sozinho. Aqui o que conta é caber na memória e não dar OOM.
- Voz / tempo real: exige bem mais — latência baixa vira o gargalo, não o tokens/s médio.
🔀 Multi-GPU e multi-máquina
Quando uma máquina não dá conta, você não precisa de uma máquina maior — precisa de mais máquinas conversando. A receita junta duas peças que você já montou no curso: a rede privada do Tailscale (2.4) e o orquestrador que roteia tarefas (4.1).
Multi-GPU na mesma máquina
Duas GPUs no mesmo PC: o Ollama divide as camadas do modelo entre elas automaticamente. Some a VRAM das duas para caber um modelo maior — ótimo para 70B em duas placas de 24 GB.
Roteamento por máquina
O modelo gigante mora no Mac de memória unificada (lento, mas cabe); o modelo rápido vive na GPU NVIDIA. O orquestrador manda cada tarefa para o endpoint certo — recap direto do 4.1.
A cola é o Tailscale
Cada máquina ganha um IP fixo 100.x na sua tailnet. Você chama o modelo de qualquer device como se estivesse na mesma LAN — sem abrir porta na internet (recap 2.4).
⌨️ Exemplo prático: rotear para outra máquina
Objetivo: expor o Ollama da máquina forte na tailnet e usá-lo de um laptop fraco.
Como verificar: a resposta sai no laptop, mas o ollama ps só mostra o modelo carregado na máquina A. O laptop virou só um terminal — quem trabalha é a GPU remota.
💡 Dica prática
0.0.0.0 expõe o Ollama para toda a rede da máquina. Só faça isso atrás do Tailscale — a tailnet é privada e criptografada. Nunca aponte essa porta para a internet pública: seria deixar seu modelo (e sua máquina) abertos para qualquer um.
⚖️ Quando local NÃO vale
Honestidade fecha o curso melhor do que hype. Local é poderoso, mas não é resposta para tudo. Saber quando usar a nuvem é parte de ser soberano — você escolhe por estratégia, não por dependência.
✓ Local brilha
- ✓Dados sensíveis que não podem sair da máquina
- ✓Uso intenso e contínuo (agentes 24/7, batch)
- ✓Tarefas que "bom o suficiente" já resolve
- ✓Você quer independência de preço e bloqueio
✗ Hora de pensar na nuvem
- ✗Você precisa do pico absoluto de inteligência de hoje
- ✗Uso raro e esporádico — não compensa o hardware
- ✗Você não quer manter uptime, drivers e segurança
- ✗Pico de demanda momentâneo que sua máquina não aguenta
🔀 O caminho maduro é o híbrido
Não é local ou nuvem — é local como base e nuvem quando faz sentido:
- •O dia a dia, o privado e o contínuo rodam local.
- •O caso raro que exige o topo de linha vai para a nuvem — sem dados sensíveis.
- •Como a API local é compatível com a da OpenAI (3.5), trocar de endpoint é mudar uma URL.
🔥 Custo de energia e térmico
"Ilimitado" não quer dizer "de graça": deixar uma GPU trabalhando 24/7 tem conta de luz e conta de calor. Vale muito a pena — mas com responsabilidade, senão você troca a fatura da nuvem por uma fatura de energia (e por um equipamento cozinhando).
🧮 A conta de luz, no guardanapo
Regra: potência (kW) × horas × tarifa (R$/kWh). Uma GPU forte puxa ~350 W quando está gerando (em idle, bem menos):
Na vida real, um agente 24/7 fica a maior parte do tempo ocioso entre tarefas — então o consumo costuma ser uma fração disso. Ainda assim, meça antes de assumir.
⚠️ Alerta: calor é o que mata hardware 24/7
- ▸Ventilação: máquina sempre-on precisa de ar fresco entrando e quente saindo — não a enfie num armário fechado.
- ▸Throttling térmico: GPU quente reduz a própria velocidade para se proteger — seu tokens/s despenca sem erro nenhum.
- ▸Poeira: em meses de uso contínuo, ela entope os fans. Limpe periodicamente.
- ▸Monitore: nvidia-smi mostra temperatura e watts em tempo real; acima de ~83 °C, melhore o resfriamento.
🛠️ Troubleshooting comum
Quase todo problema de lab local cai em cinco caixas. Em vez de decorar, use o fluxo abaixo: parta do sintoma, identifique o diagnóstico e aplique a ação. A tabela logo depois é o seu cartão de bolso.
Leia da esquerda para a direita: o sintoma (âmbar) abre quatro diagnósticos típicos (ciano), e cada um converge para uma ação de correção. A tabela abaixo dá o "causa → fix" de cada caso.
| Problema | Causa provável | Fix |
|---|---|---|
| OOM (out of memory) | Modelo + contexto não cabem na VRAM/RAM | Use quant menor (Q8→Q4), reduza num_ctx, ou rode modelo menor |
| Modelo lento | Parte do modelo vazou pra CPU (offload) ou throttle térmico | Cheque ollama ps (PROCESSOR); ajuste num_gpu; resfrie a GPU |
| Driver/CUDA quebrado | Atualização de kernel/driver dessincronizou o CUDA | nvidia-smi falha? Reinstale o driver e reinicie; reinstale o toolkit |
| Porta 11434 ocupada | Já há um Ollama (ou outro serviço) escutando nela | lsof -i :11434, mate o processo, ou mude OLLAMA_HOST |
| Tailscale offline | Sessão expirou, serviço caiu ou key venceu | tailscale status; rode sudo tailscale up de novo |
⌨️ Exemplo prático: os 5 comandos de diagnóstico
Objetivo: antes de pedir ajuda na internet, rode esta bateria — ela cobre os cinco problemas da tabela.
Como verificar: cada comando ou responde direito (verde) ou aponta o culpado. Com o sintoma + a linha da tabela, você resolve 90% dos casos sozinho — sem mandar nada para fora da sua máquina.
🚀 Seu lab daqui pra frente
Você chegou ao fim — e agora tem um lab que é seu. O que vem é evolução constante, não um destino. Veja o roadmap natural e os hábitos que mantêm tudo saudável.
Mantenha os modelos atualizados
Modelos abertos melhoram mês a mês. Refaça ollama pull das novas versões e teste-as na sua tarefa antes de adotar.
Coloque um agente a mais para trabalhar
Já tem o scanner (4.3), o vigia (4.4) e o buddy (4.5). Cada problema repetitivo da sua rotina é candidato a virar um worker 24/7.
Suba de hardware quando o gargalo aparecer
Não compre por antecipação. Meça (tópico 1), descubra o limite real e priorize memória — o recurso que manda.
✓ Hábitos que mantêm o lab vivo
- ✓Versionar configs (Modelfiles, scripts) num repo
- ✓Logar o que os agentes fazem e revisar
- ✓Medir antes de comprar hardware
- ✓Manter tudo na tailnet, nada na internet pública
✗ Armadilhas que travam
- ✗Rodar 24/7 sem ventilação nem monitorar temperatura
- ✗Expor a porta do Ollama direto na internet
- ✗Perseguir o "modelo perfeito" e nunca enviar nada
- ✗Esquecer o agente solto sem logs nem limites
💡 Dica prática
Aprende-se IA local fazendo e trocando ideia. Comunidades (incluindo a INEMA.CLUB), fóruns de modelos abertos e os cards do Hugging Face são onde você descobre o próximo modelo bom e foge das pegadinhas que outros já pagaram caro.
Auto-checagem (opcional): seu modelo trava com erro de OOM ao carregar. Qual é o primeiro ajuste mais direto?
🏁 Fim do curso — recap das 4 trilhas
Você saiu da teoria e chegou a um lab que trabalha por você. Olha o caminho que percorreu:
🤝 Continue com a gente
A virada da IA local não acaba aqui — ela acelera. Para não ficar para trás, troque ideia, mostre seu lab e descubra o próximo modelo bom junto de quem também está construindo soberania.
Entrar no INEMA.CLUB →