Por que seu LLM local parece mais burro do que é
Muitos usuários acham que modelos de linguagem grandes executados em seu próprio hardware parecem mais fracos do que sistemas baseados na nuvem, não porque os modelos sejam inerentemente piores, mas devido a armadilhas de configuração como templates de chat errados, quantização agressiva, janelas de contexto minúsculas e configurações de sampling subótimas. Os participantes comparam ferramentas como llama.cpp, Ollama, vLLM e vários esquemas de quantização, observando que os padrões em executores populares podem degradar silenciosamente o raciocínio, o uso de ferramentas e o desempenho em contexto longo. O fio também pondera os trade-offs entre rodar modelos poderosos localmente — muitas vezes quentes, barulhentos e lentos em hardware de consumo — e descarregar o trabalho para GPUs na nuvem, com o tema recorrente de que configuração cuidadosa e benchmarking específico para a tarefa importam mais do que tamanhos de modelo chamativos.
Hardware, térmica e velocidade
- Muitos relatos de Qwen 3.8 27B e Gemma 4 rodando de forma impressionante em Macs e GPUs recentes, mas com muito calor, ventoinhas barulhentas e alto consumo de bateria.
- MacBook Pros (M1–M5, 32–128 GB de RAM) veem ~12–60 tok/s em modelos 27B; modelos densos são frequentemente “usáveis, mas lentos”, especialmente com contexto grande.
- Usuários mitigam o calor com modo de economia de energia, ferramentas de controle de ventoinha, bases de resfriamento para laptop ou descarregando para um servidor doméstico.
- Alguns preferem instâncias de GPU na nuvem (Vast.ai, DO, Linode) por cerca de ~$2/h para trabalho sério, usando scripts e túneis para subir sob demanda.
Por que LLMs locais parecem “burros”
- Um ponto recorrente: templates de chat ruins e padrões de sampling não fornecidos pelo fabricante podem degradar drasticamente a qualidade, mesmo que a quantização esteja correta.
- Alguns executores fazem fallback silencioso para templates genéricos (por exemplo, ChatML), fazendo os modelos parecerem menos capazes.
- O nível de quantização e a compressão do KV cache afetam fortemente o raciocínio, especialmente em contextos longos; quants de baixa qualidade (por exemplo, alguns W4A16/NVFP4) são criticados.
- Vários enfatizam manter quants de maior qualidade (Q8, bons esquemas GGUF) e evitar quantização do KV cache se a precisão importa.
Ollama vs llama.cpp vs vLLM/outros
- Críticas ao Ollama: recursos defasados em relação ao llama.cpp/vLLM/SGLang, padrões questionáveis (contexto pequeno, quantização opaca, desempenho mais lento), confusão no registry, poucos controles de ajuste.
- Outros dizem que o Ollama é bom pela facilidade de uso, mas esconde detalhes importantes, levando usuários a julgar mal a qualidade do modelo.
- O llama.cpp (e variantes) é elogiado por confiabilidade, desempenho e controle granular, embora a configuração possa ser não trivial sem boa orientação.
Casos de uso e valor versus modelos na nuvem
- Experiências positivas: modelos locais para revisão de código, checagem de tom, trabalho com ferramentas/agentes, desafios de CTF/reversing e fluxos privados.
- Experiências negativas: modelos locais muitas vezes lentos demais ou menos capazes do que modelos de ponta na nuvem (Claude, GPT, Gemini), especialmente para programação e raciocínio complexo.
- Alguns argumentam que modelos BF16 sem quantização, que cabem totalmente na VRAM, são os únicos realmente valiosos; outros ficam satisfeitos com quants de 4 bits bem escolhidos.
Meta: benchmarking e adaptação
- Forte ênfase em construir benchmarks e harnesses específicos para a tarefa em vez de confiar em pontuações de destaque.
- Surgem ideias sobre pós-treinamento ou fine-tuning no estilo RL com base no próprio código/tickets de uma empresa, embora o esforço versus o retorno seja debatido.