<?xml version="1.0" encoding="UTF-8"?>
<rss  xmlns:atom="http://www.w3.org/2005/Atom" 
      xmlns:media="http://search.yahoo.com/mrss/" 
      xmlns:content="http://purl.org/rss/1.0/modules/content/" 
      xmlns:dc="http://purl.org/dc/elements/1.1/" 
      version="2.0">
<channel>
<title>João Marcelo Uchôa de Alencar</title>
<link>https://joao.marcelo.nom.br/blog/</link>
<atom:link href="https://joao.marcelo.nom.br/blog/index.xml" rel="self" type="application/rss+xml"/>
<description>Professor da UFC Quixadá. Computação paralela, nuvem e sistemas.</description>
<generator>quarto-1.10.19</generator>
<lastBuildDate>Sat, 10 Oct 2026 00:00:00 GMT</lastBuildDate>
<item>
  <title>Modelos Locais Estão Chegando</title>
  <dc:creator>João Marcelo Uchôa de Alencar</dc:creator>
  <link>https://joao.marcelo.nom.br/blog/posts/2026-10-20-modelos-locais-estao-chegando/</link>
  <description><![CDATA[ 





<p>Ontem, tinha um servidor executando um contêiner Docker que mesmo com o mapeamento de portas, não conseguia acessar o serviço pelo <em>localhost</em> da máquina. <code>docker ps</code> mostrava o contêiner em execução, com a porta mapeada. Disparei uma seção de Claude Code para averiguar. Rapidamente, em coisa menos de 2 minutos, o <em>Opus 5.5</em> fez o seguinte:</p>
<ol type="1">
<li>Repetiu o teste com <code>curl</code> no servidor, sem sucesso.</li>
<li>Entrou no contêiner e executou o mesmo teste, obtendo resposta.</li>
</ol>
<p>Daí concluiu que o problema não era o contêiner, por alguma razão o sistema Linux do servidor não enviava pacotes para o contêiner, ou não encaminhava os pacotes de resposta para o processo adequado. Fez uma verificação com <code>ip route</code> e descobriu que havia duas rotas para a mesma rede que o contêiner utilizava. Uma rota própria da rede virtual do Docker. Outra, para uma conexão VPN. Por coincidência, acabaram usando a mesma faixa. Este é um problema bem difícil de detectar, mas o Claude rapidamente descobriu a razão e forneceu sugestões para solucionar.</p>
<p>Pensei então, que tal um modelo local? Usei o Qwen3.8-27B com quantização de 4 <em>bits</em>. Executando no oMLX do meu Mac, ocupou ali uns 24 GB de memória. Passei o mesmo <em>prompt</em>, ativei o <em>thinking</em> e esperei. Esperei. E esperei. Fui vendo o <em>raciocínio</em> desenrolar na tela, passaram cerca de 20 a 30 minutos para chegar na mesma conclusão do Claude. Mas chegou, e forneceu a mesma solução. Então, neste caso específico, o modelo local teve a mesma qualidade, apesar de um desempenho de 15x pior. Essa velocidade torna impraticável para atividades complexas com uma base de código extensa, mas meio que mostra que os modelos abertos estão na direção de oferecer qualidade comparável. O problema é o <em>hardware</em> para executá-los.</p>



 ]]></description>
  <category>llm</category>
  <category>mac</category>
  <guid>https://joao.marcelo.nom.br/blog/posts/2026-10-20-modelos-locais-estao-chegando/</guid>
  <pubDate>Sat, 10 Oct 2026 00:00:00 GMT</pubDate>
</item>
</channel>
</rss>
