LLM local para programar sem internet: configuração offline completa (2026)

Fatos rápidos

• Stack: Qwen3-Coder 30B (ou 7B) + Continue.dev ou Aider + Devdocs (ou Zeal) + Verdaccio (npm) e devpi (pip) + ripgrep e rga.
• Disco total: ~50–80 GB conforme a cobertura de linguagens e se você faz cache do dump do Stack Overflow.
• Hardware ideal: Apple M5 MacBook Pro 64 GB. A memória unificada permite que o modelo 30B, o editor e o Docker compartilhem um mesmo pool.
• Qualidade offline vs. online: idêntica para o modelo em si — o autocompletar, as refatorações e a revisão de código têm a mesma sensação. O atrito está ao redor do modelo, não nele.
• Latência offline: ~280 ms de autocompletar no M5 (mais rápido que a ida e volta aos servidores do Copilot quando você tem sinal).
• Tudo de código aberto: Ollama (MIT), Continue.dev (Apache), Aider (Apache), Qwen3-Coder (pesos abertos), Devdocs (MPL), Zeal (GPL).
• Atualizações: o setup é "snapshot e execução" — uma vez que tudo está em cache, permanece atualizado até você escolher atualizá-lo. Atualize online e depois volte a ficar offline.

A stack offline

O teste do voo de 14 horas: o que realmente aconteceu

• Hora 1 — Tirei o notebook e abri um projeto Next.js que eu havia clonado na noite anterior. O Continue.dev já apontava para o Ollama em localhost:11434. Apertei Cmd+I sobre uma função que eu queria refatorar. O diff apareceu em 2 segundos. Aceito. O modelo era o Qwen3-Coder 30B Q4_K_M carregado na memória; estava assim desde que fiz a mala.
• **Hora 3 — Precisei adicionar uma nova dependência: @tanstack/react-query.** Executei npm install. O Verdaccio a serviu a partir do cache local (eu havia executado npm install uma vez em casa como teste de fumaça). Tempo total: 4 segundos. Nenhuma chamada de rede foi observada no tcpdump (sim, eu verifiquei — era esse tipo de voo).
• Hora 5 — Esqueci a assinatura exata de um método do Zod. Abri o Devdocs em uma aba do navegador. O docset do Zod estava incluído. Encontrei a resposta em 8 segundos. Sem spinner de "carregando…".
• **Hora 6 — Tentei instalar um pacote que não estava em cache: vitest-html-reporter.** O npm install falhou com um 404 do Verdaccio. Esta foi a primeira parede. A reserva: clonei o repo localmente, copiei o código-fonte manualmente para node_modules e apliquei um patch no package.json para apontar para um caminho local. Levou 12 minutos. A solução é preventiva: pré-aqueça o cache para tudo o que você possa precisar antes de perder o sinal.
• Hora 8 — Perguntei ao modelo sobre uma biblioteca lançada em fevereiro de 2026. Ele alucinou a API com confiança. A data de corte de treinamento do Qwen3-Coder foi outubro de 2025; as APIs de fevereiro de 2026 não estavam nos dados de treinamento. A solução: eu havia indexado localmente o repo da biblioteca com rga antes do voo. Busquei no código-fonte real. Encontrei a assinatura correta. A lição: o modelo sabe o que estava nos seus dados de treinamento; para qualquer coisa mais nova, a documentação e o código-fonte são a sua autoridade.
• Hora 11 — Executei a suíte completa de testes. 423 testes, 4,7 segundos. Sem regressões. O test runner não se importa com a rede.
• Hora 13 — Não fiz push de nada. Os commits do Git se acumularam localmente. Quando o avião pousou, executei git push uma vez na sala VIP do aeroporto. 17 commits em um único push. O modelo git-first local é o que torna isso possível — o único passo que depende da rede é o push final.
• Resultado líquido: uma funcionalidade foi entregue, dois bugs foram corrigidos, 11 testes novos foram escritos, três commits dos quais ainda me orgulho. Horas produtivas: aproximadamente 11 de 14 (o resto foi comer, dormir e lidar com a dependência problemática na hora 6). O setup se pagou nesse voo.

Checklist pré-voo: passos numerados

1. 1
   Baixe o LLM local. ollama pull qwen3-coder:30b (ou :7b se a sua máquina tiver 16 GB). Verifique com ollama run qwen3-coder:30b "say hi" — ele deve responder em segundos.
2. 2
   Instale e configure o Continue.dev (ou Aider). Abra o VS Code, instale a extensão do Continue.dev, edite ~/.continue/config.json para apontar para http://localhost:11434 (a porta padrão do Ollama). Teste abrindo um arquivo e apertando Cmd+I.
3. 3
   Aqueça o cache de pacotes do seu projeto. Entre no diretório do projeto com cd e execute npm install (ou pip install -r requirements.txt, ou cargo build, ou go mod download). Verdaccio, devpi ou Cargo farão cache de tudo em disco na primeira execução.
4. 4
   Execute uma instalação de exemplo de quaisquer dependências opcionais de que você possa precisar. Se for possível que você adicione @tanstack/react-query ou zod durante o voo, execute agora um npm install descartável em um diretório de teste. Os pacotes ficarão no cache.
5. 5
   Pré-clone os repos que você possa precisar consultar. git clone --mirror é o mais seguro — você obtém o histórico completo e todas as branches sem precisar de rede mais tarde.
6. 6
   Sincronize o Devdocs (ou baixe os docsets do Zeal de que você precisa). No Devdocs, selecione Configurações → Desativar atualização automática → Baixar tudo. Os docsets de que você precisa (TypeScript, Node, React, Python, Rust) ficarão disponíveis localmente.
7. 7
   Baixe previamente qualquer imagem Docker que você possa usar. docker pull node:20-alpine, docker pull postgres:16, etc. Elas serão servidas a partir do armazenamento local quando você executar docker compose up mais tarde.
8. 8
   Execute a suíte de testes uma vez no projeto. Detecta artefatos de compilação faltantes (TypeScript compilado, cliente Prisma gerado) antes de você estar a 10.000 metros de qualquer rede.
9. 9
   Desconecte-se por 30 minutos e teste novamente. Desative o Wi-Fi, desative o celular e tente trabalhar cinco minutos em algo real. O que falhar — corrija agora, não no portão de embarque.
10. 10
    Carregue tudo. A bateria é o segundo modo de falha offline depois de um cache incompleto. Duas horas de uso do LLM em um M5 MacBook Pro consomem aproximadamente 30–40% da bateria — planeje de acordo e leve um power bank USB-C compatível com notebooks.

Hardware: por que um M5 MacBook Pro com 64 GB de memória unificada vence

• A memória unificada significa que o modelo não está "na VRAM" nem "na RAM do sistema" — está na memória. Quando você carrega o Qwen3-Coder 30B Q4_K_M (~18 GB), ele permanece residente; mudar para uma stack do Docker Compose não o expulsa. Em um notebook com GPU discreta de 16 GB de VRAM e 32 GB de RAM do sistema, trocar o modelo custa 5–10 segundos a cada troca.
• O modelo 30B cabe confortavelmente em 24 GB; 64 GB deixam margem para tudo o mais. Com 64 GB você pode ter o modelo carregado, três contêineres Docker (banco de dados, redis, sandbox), VS Code, uma aba do Chromium com Devdocs e um multiplexador de terminal, tudo sem lentidão.
• Duração da bateria sob carga: 6–8 horas. Cobre a maioria dos voos com um power bank USB-C. O M5 é o chip mais eficiente energeticamente para inferência LLM sustentada já lançado no mercado — o consumo de energia por token é aproximadamente 3× melhor que os notebooks com GPU discreta no mesmo desempenho.
• Sem ruído de ventilador em um avião silencioso. O chassi M5 executa o modelo 30B de forma passiva por períodos sustentados. Os notebooks com GPU discreta acionam os ventiladores de forma audível sob carga de inferência — não é problema em casa, mas é um problema social na fileira 27.
• As alternativas com GPU discreta são competitivas em desempenho bruto mas com mais compromissos. Um Razer Blade 16 com RTX 4090 mobile (16 GB VRAM) executa o modelo 30B a mais tokens/seg que um M5, mas a duração da bateria sob inferência é ~2 horas, o ruído do ventilador é importante e o limite de 16 GB VRAM impede também manter configurações de contexto de 32K ou um contêiner Docker com banco de dados junto ao modelo.
• Para uma comparação de hardware mais profunda, consulte Os melhores notebooks para LLMs locais em 2026 — esse artigo classifica todas as opções viáveis (Macs da série M, ROG Strix, Razer Blade, Framework 16) por tokens/seg, bateria e memória total do sistema.

Escolher o modelo local certo para trabalhar offline

• Qwen3-Coder 30B Q4_K_M (~18 GB) — a opção recomendada por padrão. O melhor da sua classe em autocompletar de TypeScript, Python, Rust e Go; chamadas de ferramentas confiáveis; gerencia contextos de 32K tokens. Precisa de 24 GB de memória disponível (RAM do sistema no Apple Silicon, VRAM em GPUs discretas).
• Qwen3-Coder 7B Q4_K_M (~5 GB) — a reserva leve. Funciona com 8 GB de RAM unificada ou 8 GB de VRAM. Aproximadamente 80–85% da qualidade do 30B no trabalho cotidiano; a diferença aparece em refatorações de múltiplos passos e raciocínio de contexto longo. A escolha certa se o seu notebook tem menos de 24 GB de memória ou se você quer que o modelo conviva com cargas de trabalho pesadas de Docker.
• DeepSeek Coder V3 — escolha este se você precisa de contextos muito longos. O V3 da DeepSeek suporta 128K tokens; útil quando você depura através de muitos arquivos em um único prompt. Maior em disco (~25 GB com Q4_K_M); qualidade bruta aproximadamente equivalente ao Qwen3-Coder 30B.
• Codestral 22B — a opção de velocidade. Autocompletar mais rápido que o Qwen3-Coder 30B; mais fraco em chamadas de ferramentas e planos de múltiplos passos. Boa escolha se o seu fluxo de trabalho offline é dominado pelo autocompletar e você não usa agentes.
• Evite: modelos de propósito geral abaixo de 13B sem fine-tuning de código (Llama 3.2 7B, Mistral Small) e qualquer quantização mais agressiva que Q4_K_M. Ambos falham de forma óbvia em trabalho de programação real.
• Para a comparação completa de modelos de código incluindo pontuações HumanEval+ por linguagem, consulte Os melhores modelos locais de código em 2026: Qwen3-Coder vs DeepSeek vs Codestral.

Fazer cache de dependências: npm, pip, cargo, go

• npm (Node.js): instale o Verdaccio (npm install -g verdaccio), aponte o npm para ele (npm config set registry http://localhost:4873/), execute npm install uma vez em cada projeto. O Verdaccio faz cache de cada pacote localmente; as instalações posteriores funcionam offline. O cache fica em ~/.local/share/verdaccio/storage.
• pip (Python): o padrão mais simples é pip download -r requirements.txt -d ~/wheelhouse, depois instalar com pip install --no-index --find-links ~/wheelhouse -r requirements.txt. Para uso em múltiplos projetos, o devpi é a opção mais poderosa — mesma forma que o Verdaccio mas para Python.
• cargo (Rust): o cargo vendor escreve cada dependência em um diretório vendor/ do projeto, mais um trecho .cargo/config.toml que diz ao cargo para usá-lo. Uma vez confirmado, o projeto compila offline para sempre. O Cargo também faz cache do registro global em ~/.cargo/registry/cache — pré-aquecê-lo com cargo fetch cobre a maioria dos casos.
• go (Go): o padrão mais simples é go mod vendor por projeto (o Go escreve um diretório vendor/ como o Cargo). Para cache global, execute um proxy Athens local e defina GOPROXY=http://localhost:3000.
• pnpm e yarn (sabor npm): aponte-os para o Verdaccio do mesmo jeito que você aponta o npm. O armazenamento do pnpm com endereçamento por conteúdo é offline-friendly por padrão; uma vez que um pacote está no armazenamento, todos os projetos o compartilham.
• Brew, apt, dnf (pacotes do sistema): menos crítico para viagens curtas mas vale a pena conhecer. O brew bundle dump produz um Brewfile que você pode reexecutar mais tarde; apt/dnf têm modos offline via apt-get download e arquivos .deb/.rpm baixados.

Documentação offline: Devdocs, Zeal e o dump do Stack Overflow

• Devdocs (app web, ~3 GB). Um Progressive Web App autocontido que espelha a documentação oficial de ~150 linguagens e frameworks. Abra devdocs.io, vá em Configurações, ative a documentação que você usa, aperte "Tornar disponível offline". O navegador faz cache de tudo; funciona em modo avião para sempre.
• Zeal (app de desktop, ~5 GB). Um navegador de documentação nativo de desktop que usa os docsets do Dash — o mesmo formato do app Dash do macOS, mas gratuito e multiplataforma. Melhor navegação com teclado que o Devdocs; busca mais fraca. Escolha um; ter os dois é exagero.
• Dump de dados do Stack Overflow (~8 GB comprimido). O Internet Archive hospeda o dump oficial de dados do Stack Exchange como torrent. Ferramentas como o Kiwix o apresentam como um site navegável, ou você pode indexá-lo com Elasticsearch / SQLite-FTS para busca local rápida. A cobertura é cortada na data do dump — normalmente a poucos meses — mas para perguntas gerais de programação é mais que suficiente.
• Documentação específica do projeto. Para as bibliotecas que você usa com frequência, clone o repo e o código-fonte do site de documentação. A maioria dos sites de documentação são estáticos e vivem em diretórios docs/; mkdocs build ou npm run docs:build produz um site local que você pode servir com python -m http.server.
• O próprio modelo conta como documentação para o que está nos seus dados de treinamento. O Qwen3-Coder 30B conhece bem a biblioteca padrão e os principais frameworks — TypeScript, React, Python stdlib, NumPy, os SDKs da AWS. Perguntar ao modelo costuma ser mais rápido que buscar no Devdocs para isso. A divisão é "modelo para o conhecido, documentação para o novo, código-fonte para o desconhecido".

Busca local sem Google

• **ripgrep (rg) — busca de texto rápida para código.** Substitui o grep -r e o supera em 10–50× em repositórios grandes. Lê o .gitignore automaticamente. Ferramenta padrão para "onde esta função é usada?" e "encontre todos os chamadores desta API".
• **rga (ripgrep-all) — ripgrep para PDFs, arquivos comprimidos e outros formatos binários.** Busca dentro de PDFs, arquivos zip, logs comprimidos com gzip, bancos de dados SQLite e documentos Office de forma transparente. rga "consulta" . busca em cada formato de arquivo que o ripgrep não consegue, com reserva no ripgrep para texto puro.
• Caso de uso 1 — "Preciso de um exemplo de como usar esta API". Pré-clone alguns repositórios que a usem; rg "nome_funcao_api" ~/code/examples retorna cada local de chamada real em uma fração de segundo. Melhor que a documentação para padrões de uso.
• Caso de uso 2 — "Onde diz X nesta especificação PDF?" rga "frase específica" ~/specs/. PDFs que levavam 2 minutos para revisar viram buscas de 200 ms.
• Caso de uso 3 — "Stack Overflow sem Stack Overflow". Se você indexou o dump do Stack Overflow com Kiwix ou Elasticsearch, as consultas no estilo rg contra o dump substituem as buscas no Google de "stackoverflow" para tópicos legados.
• Para perguntas de código rápidas, o modelo é mais rápido que a busca. Cmd+L no Continue.dev abre um chat com a base de código como contexto; "onde gerenciamos o fluxo de autenticação?" retorna o arquivo correto em 1–2 segundos sem que você precise digitar a consulta em uma ferramenta de busca.

Qual IDE funciona completamente offline

• VS Code — funciona completamente offline; as funções de IA dependem das extensões que você usa. O Continue.dev roda inteiramente contra um endpoint local de Ollama e é a combinação recomendada. O autocompletar Tab integrado do Cursor faz chamadas de rede e se degrada silenciosamente. O GitHub Copilot para de funcionar imediatamente.
• IDEs da JetBrains (IntelliJ, PyCharm, GoLand, WebStorm) — funcionam completamente offline uma vez que a licença está em cache. O servidor de licenças faz ping periodicamente (a cada 30 dias para licenças individuais) mas tolera janelas offline estendidas. O Continue.dev tem uma versão para JetBrains com paridade de funções.
• Vim e Neovim — completamente offline por design. Sem verificações de licença, sem telemetria. Combine-os com o Aider em um painel de terminal lateral; ou use o nvim com o plugin llm.nvim apontando para o Ollama local.
• Emacs — completamente offline por design. Combine-o com o Aider através do aidermacs ou chame diretamente a API HTTP do Ollama local via gptel.
• Cursor — parcialmente offline. O IDE em si funciona sem internet, mas as funções principais (autocompletar Tab, agente Cmd+K) exigem o roteamento na nuvem do Cursor. Instalar o Continue.dev como extensão do VS Code dentro do Cursor contorna a limitação; você obtém um editor de IA local funcional em um IDE compatível com o modo offline.
• Para uma comparação mais profunda da camada de harness especificamente, consulte Continue.dev vs Cline vs Aider: o melhor agente de código local em 2026.

O que realmente falha sem conexão (lista honesta)

• Instalar pacotes de terceiros completamente novos. Sem acerto de cache, sem reserva além de vendorizar o código-fonte manualmente. A solução é preventiva — faça o pré-cache de tudo o que você possa querer, incluindo as opções que são apenas possibilidades.
• O conhecimento do modelo sobre APIs lançadas após a sua data de corte. A data de corte de treinamento do Qwen3-Coder foi outubro de 2025 (lançamento em maio de 2026); as APIs lançadas depois são, no melhor caso, estimativas. A solução: pré-clone o código-fonte e use rg para encontrar a assinatura real quando tiver dúvidas. Nunca confie no modelo para bibliotecas mais novas que os seus dados de treinamento.
• Qualquer coisa que exija idas e voltas de autenticação OAuth ou API. Fazer login em um provedor de nuvem, trocar tokens OAuth, acessar o portal SSO do seu time — nada disso funciona offline. A solução: faça toda a autenticação antes da decolagem e confie nos tokens em cache (que normalmente expiram após 12–24 horas).
• Testes de serviços remotos baseados em navegador. Se os seus testes chamam uma API real ou um ambiente de staging, eles vão falhar sem conexão. A solução: use um mock local (msw, nock, vcr) e grave fixtures previamente.
• Geração de imagens e assets que chama serviços externos. Os geradores de imagens na nuvem, os serviços de fontes e os assets baixados por CDN falham todos. A solução: inclua os assets fixos no repo ou use um modelo de imagens completamente local (que é uma stack separada).
• A solução para o problema "como se chamava aquela biblioteca?" é o próprio modelo. Quando você não pode buscar no Google, pergunte ao modelo "qual é o nome do pacote para a funcionalidade X?" — para coisas nos seus dados de treinamento ele responde corretamente 80–90% das vezes. Verifique no cache de pacotes antes de instalar.

Atualizar modelos e caches mais tarde

• **Os modelos se atualizam via ollama pull.** Quando sai uma nova versão do Qwen3-Coder, execute ollama pull qwen3-coder:30b enquanto estiver online. Os novos pesos substituem os anteriores; a versão prévia desaparece a menos que você a tenha marcado com tag (ollama tag qwen3-coder:30b qwen3-coder:30b-2026-05 antes de baixar).
• **Os caches de pacotes se atualizam no próximo npm install / pip install / cargo update online.** Sem fluxo de trabalho especial — o seu gerenciador de pacotes normal continua funcionando quando você está online e congela quando você está offline.
• O Devdocs se atualiza automaticamente por padrão. Desative a atualização automática antes dos voos para evitar downloads inesperados quando você tem sinal no aeroporto (Configurações → Desativar atualização automática).
• Os dumps do Stack Overflow são atualizados trimestralmente. O Internet Archive publica novos dumps a cada três meses; baixe novamente quando quiser cobertura mais recente.
• Cadência a planejar: modelo e Devdocs a cada 2–3 meses, caches de pacotes por projeto ao começar trabalho novo, dump do Stack Overflow a cada 6–12 meses. Nenhum é urgente a menos que você comece a trabalhar em algo genuinamente novo.

Compartilhar o cache offline com o time

• O Verdaccio também funciona como servidor de time. Aponte um pequeno servidor de escritório para o Verdaccio, defina npm config set registry http://team-cache.local:4873/ para todos. Os novos desenvolvedores obtêm o cache automaticamente; as viagens offline significam apenas pré-sincronizar o que você precisa no seu notebook.
• Os modelos podem ser hospedados em um servidor Ollama do time. ollama serve em uma máquina de escritório potente, aponte a configuração do Continue.dev de cada desenvolvedor para o servidor do time quando estão no escritório, mude para localhost:11434 (com modelos baixados localmente) para as viagens.
• O Devdocs não tem modo de time nativo mas é trivialmente compartilhável como pasta estática. Compile-o uma vez, hospede-o em http://docs.team.local, que todos o marquem como favorito. Para as viagens, os desenvolvedores individuais executam instâncias em localhost.
• O Git já é compartilhável em time. Um Gitea local ou um GitLab auto-hospedado dentro da rede do escritório dá a cada desenvolvedor acesso offline aos repos; combine-o com git clone --mirror nos notebooks individuais para as viagens.
• Imagens de contêiner via um registro privado. Um pequeno Harbor ou o registro integrado do Gitea faz cache das imagens uma vez; os viajantes fazem docker pull para local antes de sair.
• O caso econômico: para um time de 5 desenvolvedores que viajam com frequência, compartilhar caches economiza aproximadamente 250 GB de download de internet por mês e reduz o checklist pré-voo de 60 minutos para 5.

Erros comuns ao configurar uma stack de programação offline

• Erro 1: esquecer de testar o setup offline antes da viagem. A falha mais comum é descobrir as lacunas no aeroporto. Faça um ensaio "sem luz" de 30 minutos em casa — desative o Wi-Fi, desconecte o celular, trabalhe em algo real — pelo menos 24 horas antes de precisar dele.
• Erro 2: fazer cache apenas dos pacotes que você usa atualmente, não dos que você poderia precisar. Se houver alguma possibilidade de que você adicione uma dependência durante a viagem, instale-a uma vez em casa como teste de fumaça. O cache vai conservá-la.
• Erro 3: deixar o autocompletar Tab do Cursor ativado e supor que funciona offline. Não funciona. O IDE volta silenciosamente a não oferecer nada; você não recebe nenhum autocompletar. Instale o Continue.dev como extensão do VS Code dentro do Cursor, ou use o VS Code diretamente.
• Erro 4: usar um modelo abaixo de 7B para trabalho de programação a sério. Os modelos de código sub-7B falham o suficiente para que você passe mais tempo corrigindo a saída deles do que escrevendo código. Desça no mínimo para o Qwen3-Coder 7B; se o seu hardware não dá conta disso, o setup de programação offline não é viável nesse notebook.
• Erro 5: confiar no modelo para bibliotecas mais novas que a sua data de corte de treinamento. Ele vai alucinar com confiança. Para qualquer coisa lançada nos últimos 6 meses, trate a saída do modelo como uma estimativa e verifique contra o código-fonte.
• **Erro 6: pular o cache de pacotes e supor que o npm install é rápido o suficiente na sala VIP do aeroporto.** O Wi-Fi da sala é pouco confiável, os downloads travam e você embarca com uma árvore de dependências instalada pela metade. Faça cache no dia anterior.
• Erro 7: esquecer as imagens Docker. Se o seu fluxo de trabalho de desenvolvimento usa docker compose up para um banco de dados, as imagens precisam estar baixadas previamente. Um primeiro docker compose up em voo sem imagens é uma parede intransponível.

Fontes

• Documentação do Ollama — Biblioteca oficial de modelos, incluindo as variantes do Qwen3-Coder e os níveis de quantização referenciados para os orçamentos VRAM/RAM offline.
• Documentação do Continue.dev — Guia de configuração, configuração de modelo local e os fluxos de trabalho de autocompletar e chat compatíveis com o modo offline.
• Documentação do Aider — Referência de CLI de terminal, configuração de modelo local e padrões de fluxo de trabalho offline nativos com git.
• Código-fonte do Devdocs — O app web que espelha a documentação oficial para uso offline; instruções de download e cache PWA.
• Dump de dados do Stack Exchange (Internet Archive) — Dump trimestral do conteúdo do Stack Overflow usado como substituto offline para as buscas.

FAQ

Leitura relacionada

• Substitua o GitHub Copilot por um LLM local: setup + comparação de custos 2026 — objetivo adjacente: mesma stack, abordagem diferente (custo vs. offline). Leia isto se você quiser primeiro os números de custo.
• Continue.dev vs Cline vs Aider: o melhor agente de código local em 2026 — quais harnesses funcionam completamente offline, com cobertura profunda das diferenças entre Continue.dev, Aider e Cline.
• Os melhores modelos locais de código em 2026: Qwen3-Coder vs DeepSeek vs Codestral — o lado do modelo da equação, com benchmarks HumanEval+ por linguagem.
• Execute IA em um tablet: apps de LLM local para iPad e Android — para viajantes que preferem um dispositivo offline mais leve que um notebook.
• Os melhores notebooks para LLMs locais em 2026 — referência de hardware; classifica todos os notebooks viáveis em tokens/seg, bateria e memória total do sistema.
• Escreva código melhor com IA — técnicas de prompting que melhoram a qualidade de geração de código em qualquer modelo, online ou offline.
• Hub de Power Local LLM — biblioteca completa de guias sobre código, RAG, agentes e trabalho criativo.