Nota do autor: este post vai ser técnico, vai ser opinativo, e vai incomodar quem acha que só os grandes labs conseguem fazer modelos que raciocinam a sério. Se és desses, senta-te e lê na mesma — o pior que pode acontecer é aprenderes alguma coisa.
Quando a Anthropic anunciou o Claude Mythos Preview a 7 de abril, já aqui escrevi sobre o que isso significava para a segurança e para os modelos locais. Mas havia uma pergunta que ficou no ar, pendurada como um fio solto que ninguém quis puxar nos primeiros dias: e se alguém reconstruísse a arquitectura do Mythos em open source? E se, em vez de ficarmos todos a olhar para o slide deck da Anthropic com cara de quem viu o futuro, alguém se sentasse e dissesse “ok, vamos ver se isto se constrói com o que já existe na literatura publicada pela Anthropic na internet”?
O Kye Gomez fez exactamente isso. E o resultado chama-se OpenMythos.
Mas esta semana apareceu mais uma peça do puzzle — e esta vem de uma direcção completamente diferente, que reforça ainda mais a tese de que tamanho não é diploma. Como um certo assassino vitoriano do seculo XIX diria, vamos por partes.
O que é o OpenMythos — sem o marketing
Vamos ao que interessa. O OpenMythos é uma implementação open source, teórica, da arquitectura que se suspeita estar por trás do Claude Mythos pela documentação que tem vindo a ser publicada sobre ele. Não é um clone. Não é uma cópia. É uma reconstrução de engenharia inversa baseada em papers publicados, especulação informada, e um trabalho de síntese que, sejamos honestos, é impressionante independentemente de estar certo ou errado sobre o que a Anthropic realmente fez.
O repositório está no GitHub com licença MIT, tem mais de 10 mil stars à data em que escrevo, e implementa aquilo que o Gomez e a comunidade acreditam ser o coração do Mythos: um Recurrent-Depth Transformer.
E aqui é onde a coisa fica interessante para quem, como eu, gosta de perceber o que está debaixo do capô.
Recurrent-Depth Transformer: o que raio é isto e porque importa
A maioria dos transformers que usamos — o GPT, o Llama, o Mistral, o que quiseres — funciona de uma forma relativamente simples em termos de profundidade: tens N camadas, o input passa por todas elas uma vez, da primeira à última, e sai o output. Mais camadas, mais parâmetros, mais inteligência. Pelo menos em teoria.
O que o OpenMythos implementa é fundamentalmente diferente. Em vez de empilhar centenas de camadas únicas, divide a arquitectura em três blocos: um Prelude (camadas normais de transformer que correm uma vez), um Recurrent Block (um conjunto de camadas que é reciclado e corre múltiplas vezes — os mesmos pesos, repetidos em loop), e um Coda (camadas finais, também de passagem única).
Imagina isto como a diferença entre ler um parágrafo uma vez e ler o mesmo parágrafo cinco vezes, cada vez com mais contexto do que entendeste na passagem anterior. Os mesmos pesos. Mais loops. Raciocínio mais profundo.
Cada iteração do loop não é uma repetição cega. A cada passagem, o hidden state é actualizado com uma regra que combina o estado anterior, o input original (injectado de volta para não se perder o sinal), e o resultado do transformer nessa iteração. É, na prática, chain-of-thought a acontecer em espaço latente contínuo — sem gerar tokens intermédios, sem o overhead de escrever passos de raciocínio visíveis. O modelo “pensa” internamente, em silêncio, tantas vezes quantas lhe mandares.
E aqui está a parte que me fez parar a ler o README e ir buscar café: isto foi formalmente provado. Cada iteração do loop é funcionalmente equivalente a um passo de chain-of-thought. Um modelo com T loops simula implicitamente T passos de raciocínio. Mas ao contrário do CoT discreto em tokens, o raciocínio latente pode codificar múltiplos caminhos alternativos simultaneamente — algo mais parecido com breadth-first search do que com o raciocínio linear passo-a-passo que vemos quando o modelo “pensa em voz alta.”
A peça que faltava: estabilidade
Quem já tentou treinar modelos recorrentes sabe que há um problema clássico: instabilidade. O hidden state cresce descontroladamente ao longo dos loops — o que se chama residual explosion — e o treino diverge. É por isso que, durante anos, os transformers recorrentes foram considerados uma ideia bonita mas impraticável a escala.
O OpenMythos resolve isto da forma que a literatura recente sugere, nomeadamente o paper Parcae: trata o loop como um sistema dinâmico linear discreto, parametriza a matriz de transição A de forma a que o seu raio espectral seja estritamente menor que 1, e assim garante convergência por construção. Não é um truque de regularização que esperas que funcione — é uma restrição matemática que impede fisicamente a divergência.
No código do OpenMythos, isto traduz-se numa parametrização diagonal negativa da matriz A, discretizada com ZOH ou Euler, e com o constraint reforçado via exponencial. O resultado é que o modelo treina de forma limpa mesmo com learning rates agressivos, e o loop pode correr mais vezes durante inferência do que durante treino — o que eles chamam de depth extrapolation. Treinas com 4 loops, fazes inferência com 8 ou 16, e o modelo continua estável.
Isto é, para mim, a contribuição técnica mais significativa de toda esta linha de investigação. Não é a ideia de reciclar camadas — isso já existia desde o Universal Transformer de 2018. É tornar isso treinável e estável a escala. E o OpenMythos implementa-o.
Mixture of Experts: profundidade E largura
O loop explica a profundidade do raciocínio. Mas o Mythos — e o OpenMythos — também precisa de lidar com largura: domínios completamente diferentes como código, matemática, linguagem natural, ciência, direito. Para isto, o OpenMythos usa Mixture of Experts no feed-forward de cada camada do Recurrent Block.
Em vez de um único FFN monolítico, tens dezenas ou centenas de “experts” pequenos, um router que selecciona os top-K por token, e um conjunto de shared experts que estão sempre activos para absorver conhecimento transversal. O resultado é um modelo que pode ter centenas de milhares de milhões de parâmetros totais mas que só activa uma fracção — estimada em cerca de 5% — por token. O número de parâmetros total é um número de armazenamento, não de computação.
E aqui está a parte bonita: como o hidden state evolui ao longo dos loops, o router pode seleccionar experts diferentes em cada iteração. O loop 1 pode activar experts de parsing sintático. O loop 3 pode activar experts de raciocínio lógico. O loop 5 pode activar experts de validação. Tudo isto com os mesmos pesos base, diferenciado apenas pelo estado do hidden state naquele ponto da recorrência.
Segunda prova: “Second Thoughts” e os Bidirectional Refinement Loops
E agora vem a parte nova. Enquanto o OpenMythos ataca o problema da profundidade de raciocínio reciclando camadas em loop, apareceu um trabalho experimental do Michael E. Johnson — o homem da Big Attic House, que anda a construir baterias de ferro para comunidades sem electricidade quando não anda a mexer em LLMs — que ataca o mesmo problema por um ângulo completamente diferente. E os resultados são, no mínimo, provocadores.
O Johnson partiu de uma observação simples: um LLM é sempre forward-only. Tudo flui numa direcção, da primeira camada à última, e o que sai no fim é o que é. As tags <think> ajudam — forçam o modelo a gastar mais tokens a reflectir antes de responder — mas são um hack inelegante. Queimam tokens, podem entrar em loops infinitos, e muitos utilizadores desligam-nas.
A proposta dele chama-se Bidirectional Refinement Loop, ou BRL. A ideia é inspirada — de forma assumidamente poética — na série Tiffany Aching do Terry Pratchett, onde se fala de “Second Thoughts”: os pensamentos que pensas sobre a forma como pensas.
Na prática, o que o BRL faz é o seguinte: pegas numa representação perto do fim do modelo (uma camada a cerca de 75-85% de profundidade), passas essa representação por um mini-LLM independente (um transformer pequeno, treinado do zero, com 3 a 8 camadas), e reinjectas o resultado dessa passagem num ponto perto do início do modelo (a cerca de 25-40% de profundidade). Depois, o modelo faz uma segunda forward pass com essa correcção incorporada.
Primeira passagem: o modelo pensa normalmente. Segunda passagem: o modelo pensa com o benefício de já “quase ter respondido” e ter tido feedback de uma consciência externa sobre o que ia dizer.
A direcção do mini-LLM é conceptualmente inversa — ele recebe informação de perto do output e envia-a de volta para perto do input — mas computacionalmente é uma forward pass normal. Não há nada exótico aqui em termos de implementação. É uma ideia engenhosa com componentes simples.
E o detalhe que me prendeu a atenção: o γ, um escalar aprendido que controla quanta correcção é injectada. Quando γ está a zero, o modelo ignora o “Second Thought” e funciona normalmente. Quando está a 1, a correcção é total. O modelo aprende quando precisa de se autocorrigir.
Os resultados — e porque é que devias prestar atenção
O Johnson testou o BRL num Qwen3-1.7B — um modelo minúsculo, francamente mau para escrever código — contra as primeiras 20 tarefas do HumanEval. O modelo base passou 1 em 20. Com o BRL, passou 4 em 20. Houve uma regressão (o BRL falhou uma que o modelo base acertava), mas o saldo líquido é claro: passou de 5% para 20% de pass rate.
Para contextualizar: estamos a falar de um modelo de 1.7 mil milhões de parâmetros. Um modelo que mal cabe na definição de “útil” para programação. E com um sidecar de umas poucas camadas a funcionar como consciência, quadruplicou a taxa de sucesso.
Mais interessante que os números é o que o BRL corrige qualitativamente. No teste intersperse do HumanEval, o modelo base gerava o código correcto mas depois perdia a disciplina — começava a repetir o prompt, a docstring, entrava num loop degenerativo. O BRL identificou esse risco no espaço latente, podou os tokens redundantes, e redirecionou o modelo para uma implementação mais limpa que terminava correctamente. Em vez de um for i in range(1, len(numbers)) manual, o BRL levou o modelo a usar um for num in numbers[1:] idiomático — menos propenso a erros off-by-one.
O que o BRL está a fazer aqui não é tornar o modelo mais inteligente no sentido convencional. Está a funcionar como um filtro latente — intercepta trajectórias degenerativas no espaço de activações e redireciona-as antes de se manifestarem no output. O Johnson compara-o ao Jiminy Cricket: uma consciência pequena que senta ao lado de um modelo maior e mais burro e lhe diz “espera, pensa melhor nisso.”
E isto liga directamente com uma descoberta interessante dos primeiros testes: quando o Johnson tentou que o mini-LLM avaliasse a “riskiness” de tudo, o modelo de 1.7B marcava literalmente cada token como arriscado e parava de produzir output. O que, pensando bem, é uma resposta honesta — o modelo sabe, a algum nível, que o seu conhecimento é fino. O truque é focar o Second Thought num objectivo específico e mensurável, como qualidade sintáctica do código, em vez de o deixar ser um pessimista existencial.
O que isto tem a ver com o OpenMythos
Tudo. São duas abordagens ao mesmo problema fundamental: como é que um modelo pequeno compensa as suas limitações sem simplesmente empilhar mais parâmetros?
O OpenMythos fá-lo reciclando as mesmas camadas em loop — mais profundidade de raciocínio sem mais pesos. O BRL fá-lo com um sidecar que cria um feedback loop entre camadas profundas e camadas iniciais — uma forma de auto-revisão interna que não requer mais tokens visíveis nem mais parâmetros no modelo principal.
São complementares. Um modelo com arquitectura RDT e um BRL por cima teria, teoricamente, profundidade de raciocínio via loops e capacidade de auto-correcção via feedback. E tudo isto com uma fracção dos parâmetros que os big labs atiram ao problema.
Tudo muito bonito, sócio. Mas como é que eu corro isto em casa?
Certo. Vamos ao que interessa para quem, como eu, tem um homelab e quer pôr as mãos na massa.
Primeiro, o disclaimer honesto: à data de hoje, o OpenMythos não tem pesos pré-treinados de qualidade “production-ready” prontos a descarregar e usar como usas um Llama ou um Mistral. O projecto está na fase de implementação da arquitectura e treino inicial. O script de treino para o modelo de 3B parâmetros existe e corre, usa o dataset FineWeb-Edu da HuggingFace, suporta multi-GPU com DDP via torchrun, e inclui precisão bfloat16 para hardware recente.
Mas a beleza disto não está em esperar que o Kye Gomez te entregue um modelo pronto. Está em perceber que tens nas mãos tudo o que precisas para o construir tu próprio. E se não quiseres treinar de raiz — o que é perfeitamente legítimo e provavelmente sensato para a maioria das pessoas — há uma abordagem híbrida que acho muito mais interessante e prática.
A receita: OpenMythos como arquitectura, LLM local como motor
Aqui está o que eu faria — e o que pretendo testar no meu homelab nas próximas semanas.
Passo 1: Hardware mínimo e setup base
Precisas de uma máquina com GPU NVIDIA com pelo menos 8GB de VRAM para experimentar com a variante 1B, ou 24GB+ para a variante 3B. Uma RTX entre a 3060 ou 4090 é o sweet spot para homelab. Se tens uma workstation com múltiplas GPUs, ainda melhor — o OpenMythos suporta multi-GPU nativamente.
O setup base é Linux (obviamente), com CUDA 12.x, PyTorch 2.1+, e Python 3.10+.
# Criar um ambiente limpo
python -m venv openmythos-env
source openmythos-env/bin/activate
# Instalar o OpenMythos
pip install open-mythos
# Se tens GPU com CUDA e queres Flash Attention 2 (recomendado)
pip install open-mythos[flash]
Passo 2: Testar que funciona
Antes de investires horas a treinar, testa que a arquitectura corre no teu hardware:
import torch
from open_mythos.main import OpenMythos, MythosConfig
cfg = MythosConfig(
vocab_size=32000,
dim=2048,
n_heads=16,
max_seq_len=2048,
max_loop_iters=8,
prelude_layers=2,
coda_layers=2,
n_experts=16,
n_shared_experts=2,
n_experts_per_tok=2,
expert_dim=512,
lora_rank=8,
attn_type="gqa",
n_kv_heads=4,
)
model = OpenMythos(cfg)
total = sum(p.numel() for p in model.parameters())
print(f"Parâmetros: {total:,}")
# Forward pass de teste
ids = torch.randint(0, cfg.vocab_size, (1, 64))
logits = model(ids, n_loops=4)
print(f"Logits shape: {logits.shape}")
# Verificar estabilidade — o raio espectral TEM de ser < 1
A = model.recurrent.injection.get_A()
rho = torch.linalg.eigvals(A).abs().max().item()
print(f"Raio espectral ρ(A) = {rho:.4f} — {'ESTÁVEL' if rho < 1 else 'INSTÁVEL'}")
Se o raio espectral for menor que 1, estás em negócio. Se não for, algo correu mal na instalação.
Passo 3: Treinar o modelo 3B no teu hardware
O OpenMythos inclui um script de treino para o modelo de 3B parâmetros usando o dataset FineWeb-Edu. Se tens uma ou mais GPUs, podes lançar o treino directamente:
# Single GPU
python training/3b_fine_web_edu.py
# Multi-GPU (detecta automaticamente quantas tens)
torchrun --nproc_per_node=$(python -c "import torch; print(torch.cuda.device_count())") \
training/3b_fine_web_edu.py
O treino usa AdamW, warmup linear de 2000 steps seguido de cosine decay, bfloat16 em hardware recente (H100/A100, ou RTX 40xx), e faz streaming do dataset para não precisares de o descarregar todo para disco.
Aviso realista: treinar um modelo de 3B de raiz requer tempo e compute significativos, mesmo para o subset sample-10BT do FineWeb-Edu. Numa RTX 4090 single, estamos a falar de dias, não horas. Mas o ponto não é treinar o modelo inteiro numa tarde — é ter a capacidade de o fazer, iterativamente, no teu hardware.
Passo 4: A abordagem híbrida — e a que recomendo
Se o que queres é experimentar a arquitectura de recurrent-depth sem treinar de raiz, há um caminho mais pragmático. Usa um modelo local existente — Llama 3, Qwen 2.5, Mistral — como base de inferência via Ollama ou vLLM, e usa o OpenMythos como laboratório de experimentação arquitectural.
A ideia é esta: instala o Ollama no teu homelab para teres um LLM local funcional e pronto a usar. Depois, usa o OpenMythos para entender e experimentar com a arquitectura de looped transformers. Se estiveres a sério, podes usar os insights do OpenMythos para treinar modelos pequenos customizados para tarefas específicas — o script de treino suporta configurações desde 1B até ao que o teu hardware aguentar.
# Instalar Ollama (se ainda não tens)
curl -fsSL https://ollama.ai/install.sh | sh
# Descarregar um modelo base
ollama pull llama3:8b
# Ou, se tens VRAM para isso
ollama pull qwen2.5:72b
E depois, como camada de orquestração, usa algo como o LiteLLM — que já cobri num post anterior — para distribuir carga entre o teu modelo local e APIs externas como fallback.
Passo 5: Orquestração e pipeline
Aqui é onde a coisa se torna útil a sério. O valor real do OpenMythos não é apenas a arquitectura — é o padrão que demonstra. A ideia de que podes ter raciocínio mais profundo sem mais parâmetros, apenas mais loops. E o BRL reforça isto com uma abordagem ortogonal: mais auto-correcção sem mais parâmetros, apenas um sidecar inteligente.
Configura o teu pipeline com:
- Ollama como runtime de inferência para modelos open-weight
- Open WebUI como interface de chat (docker compose e tens tudo a correr em 5 minutos)
- LiteLLM como proxy para balanceamento entre modelos locais e APIs externas
- OpenMythos como sandbox de experimentação arquitectural
# docker-compose.yml simplificado para o stack
services:
ollama:
image: ollama/ollama
ports:
- "11434:11434"
volumes:
- ollama_data:/root/.ollama
deploy:
resources:
reservations:
devices:
- capabilities: [gpu]
webui:
image: ghcr.io/open-webui/open-webui:main
ports:
- "3000:8080"
environment:
OLLAMA_BASE_URL: http://ollama:11434
depends_on:
- ollama
volumes:
ollama_data:
Isto dá-te um stack completo de inferência local em menos de 10 minutos. GPU passthrough para o Ollama, interface web para interacção, e tudo a correr na tua rede local sem um byte a sair para fora.
O que a issue #20 do repositório nos diz — e porque é pior para a narrativa dos big labs
Há uma issue no repositório do OpenMythos que merece ser lida com atenção. Alguém pegou no Gemma 4 26B — um modelo standard, sem arquitectura recorrente — fez fine-tuning com LoRA usando 551 pares comportamentais destilados do system card do Mythos e de outputs do Claude Opus, e conseguiu que o modelo generalizasse para perguntas out-of-distribution sem system prompt. Sete em sete perguntas de teste.
A conclusão do autor é cirúrgica: a superfície comportamental é separável do mecanismo arquitectural. Um transformer standard, com o sinal de treino correcto, reproduz respostas de nível Mythos em identidade, meta-cognição e consciência de avaliação — sem profundidade recorrente.
Lê aquilo outra vez. Sem. Profundidade. Recorrente.
Isto não contradiz a hipótese do RDT — a arquitectura explica a profundidade de raciocínio, não o comportamento superficial. Mas demonstra algo que muita gente nos grandes labs preferia que não fosse verdade: o comportamento está no sinal de treino, não na arquitectura proprietária.
Escala não é diploma: o caso está cada vez mais forte
Há uma narrativa que os grandes labs — Anthropic, OpenAI, Google — alimentam, implícita ou explicitamente, desde que os LLMs se tornaram mainstream: que a capacidade real requer escala que só eles têm. Que precisas de centenas de milhares de GPUs, de mil milhões de dólares em compute, de equipas de centenas de investigadores, para produzir modelos que raciocinam a sério.
O problema para essa narrativa é que as provas em contrário não param de aparecer. E agora temos três linhas independentes a convergir no mesmo ponto.
- Linha 1: O OpenMythos demonstra que a arquitectura do que possivelmente é o modelo mais avançado do mundo pode ser reconstruída por uma comunidade open source a partir de papers públicos. A implementação está no GitHub. Qualquer pessoa pode lê-la, corrê-la, modificá-la.
- Linha 2: A issue #20 prova que a superfície comportamental é separável da arquitectura. Com os dados certos e fine-tuning correcto, um transformer standard reproduz comportamento de nível Mythos.
- Linha 3: O BRL do Johnson mostra que mesmo sem mudar a arquitectura do modelo principal, um sidecar minúsculo — umas poucas camadas de transformer treinadas do zero — pode quadruplicar a taxa de sucesso em coding benchmarks. Um Qwen3-1.7B, que sozinho mal funciona, com um “Second Thought” a funcionar como consciência passa de 1/20 para 4/20 no HumanEval. Não é frontier performance, mas o delta é absurdo para o custo: umas poucas camadas extra e um segundo forward pass.
E o Johnson nem sequer testou isto num modelo decente ainda. O artigo promete resultados com o Qwen3.5-9B na continuação. Se o padrão escalar — e há razões para acreditar que sim, porque o mecanismo opera no espaço latente e não depende directamente da capacidade do modelo base — um modelo de 9B com BRL pode aproximar-se de resultados que hoje requerem modelos de 30B+.
Os scaling laws do Parcae reforçam ainda mais a tese: um modelo looped de 770M atinge a qualidade downstream de um transformer standard de 1.3B treinado nos mesmos dados. Metade dos parâmetros para a mesma qualidade. Isto inverte completamente a lógica de que mais parâmetros é sempre melhor. Não é. Mais loops é melhor. Mais auto-correcção é melhor. E ambos são compute de inferência, que qualquer pessoa com uma GPU pode escalar.
O ecossistema de ferramentas para correr modelos locais atingiu um nível de maturidade que seria impensável há dois anos. Ollama, vLLM, llama.cpp, Open WebUI, LiteLLM — tens uma stack completa de inferência e orquestração, gratuita, open source, que corre em hardware de consumo. Um modelo de 7B quantizado a 4 bits corre numa RTX 3060 com 12GB de VRAM. Um modelo de 70B quantizado cabe numa máquina com 48GB. E o OpenMythos sugere que com a arquitectura correcta, um modelo de 7B com loops suficientes pode raciocinar como um modelo de 70B sem loops. O BRL sugere que mesmo sem mudar a arquitectura, um sidecar barato pode eliminar uma fatia significativa dos erros.
O génio saiu da garrafa. Não porque os modelos locais sejam melhores do que o Mythos ou o GPT-5 ou o que quer que a Google lance na próxima semana. São claramente piores em capacidade bruta de raciocínio de fronteira. Mas porque são suficientemente bons para a esmagadora maioria dos casos de uso. E porque o delta entre “suficientemente bom” e “fronteira” está a encolher a cada mês que passa — e agora encolhe por duas frentes simultaneamente.
O que os modelos locais com estas arquitecturas significam a prazo
Se o OpenMythos e abordagens como o BRL cumprirem o que prometem — e é um “se” grande, não vou ser desonesto — as implicações para quem corre modelos em casa são significativas.
Modelos mais pequenos com raciocínio mais profundo. Em vez de precisares de um modelo de 70B para tarefas que requerem raciocínio multi-step, podes ter um modelo de 7B-13B com loops suficientes. E se lhe juntares um sidecar de auto-correcção, o modelo não só raciocina melhor como se corrige antes de dizer disparates. Isto traduz-se directamente em hardware mais acessível, inferência mais rápida, e custos de operação mais baixos.
Compute adaptativo por query. A arquitectura de Adaptive Computation Time permite que o modelo decida quantos loops precisa por input. Perguntas simples saem com 2-3 loops. Problemas complexos usam 16 ou mais. O BRL pode funcionar como um mecanismo complementar — se o sidecar detecta alta incerteza, o modelo pode fazer mais loops antes de responder. Isto é eficiência de inferência que nenhum transformer standard te dá.
Depth extrapolation gratuita. Treinas com 4 loops, fazes inferência com 16. Mais raciocínio, sem re-treinar. Isto é, na prática, inference-time scaling sem chain-of-thought visível — o modelo pensa mais sem gerar mais tokens. Para quem paga electricidade e VRAM por token gerado, isto é dinheiro no bolso.
Modelos que sabem dizer “não sei.” O trabalho do Johnson revelou algo subtilmente importante: quando tentou que o mini-LLM avaliasse tudo como arriscado, o modelo de 1.7B efectivamente concordou — marcou cada token como incerto e recusou-se a produzir output. Isto é, paradoxalmente, um resultado positivo. O modelo tem, a algum nível nas suas representações internas, noção das suas próprias limitações. Com o foco correcto — por exemplo, treinar o sidecar para detectar quando o modelo precisa de usar uma tool call em vez de inventar uma resposta — isto pode ser a base de modelos locais que sabem quando pedir ajuda em vez de alucinar.
O elefante (outro) na sala. Ao menos estão a sair aqui no blog da lista de animais em risco.
Precisamos de ser honestos sobre uma coisa: o OpenMythos é, à data de hoje, uma implementação teórica. Não tem pesos treinados de qualidade comparável aos modelos existentes. O treino de raiz requer compute significativo. E a hipótese de que o Mythos é de facto um Recurrent-Depth Transformer é exactamente isso — uma hipótese, baseada em evidência circunstancial e análise de papers.
O BRL do Johnson está numa fase ainda mais precoce. Os resultados com o Qwen3-1.7B são promissores mas limitados — 20 testes do HumanEval não são um benchmark definitivo. Houve uma regressão. O autor ainda não publicou o repositório completo. E a questão dos loops infinitos, que ele próprio reconhece, é real e precisa de ser resolvida antes de isto ser prático para produção.
Pode estar tudo errado. A Anthropic pode ter usado uma abordagem completamente diferente para o Mythos. O BRL pode não escalar para modelos maiores. Os números podem não se manter quando o HumanEval completo for avaliado.
Mas mesmo que tudo isto esteja parcialmente errado, o valor permanece. Porque demonstrou que a comunidade — desde projectos estruturados como o OpenMythos até experimentadores solitários como o Johnson a correr testes numa MI50 — é capaz de produzir inovação arquitectural real, implementá-la, documentá-la, e partilhá-la. Isto é o poder do open source em acção — não como ideologia, mas como método de engenharia.
E como mostrou a issue #20, mesmo que a arquitectura não seja o factor determinante, o sinal de treino é. E os dados para construir esse sinal estão cada vez mais acessíveis.
Conclusão: o que fazer com isto tudo
Se estás a ler este blog, provavelmente já tens um homelab, já corres modelos locais, e já percebes que a independência tecnológica não é paranoia — é prudência de engenharia.
O OpenMythos e trabalhos como o BRL dão-te mais ferramentas no arsenal. Não como substituição do teu Llama ou do teu Mistral — mas como um vislumbre do que a próxima geração de modelos locais vai parecer. Arquitecturas mais inteligentes, não apenas maiores. Raciocínio mais profundo, não apenas mais parâmetros. Sidecars que adicionam auto-correcção sem inflacionar o modelo principal. Eficiência por design, não por quantização forçada.
E na próxima vez que alguém te disser que os modelos locais são brinquedos comparados com os modelos comerciais, manda-lhes este post. Ou melhor: manda-lhes o repositório do OpenMythos, a issue #20, os resultados do BRL, os resultados da AISLE que cobri no post anterior, e pergunta-lhes: se escala fosse diploma, porque é que um modelo de 1.7B parâmetros com um sidecar de meia dúzia de camadas quadruplica a sua taxa de sucesso? Porque é que um modelo de 3.6B detecta as mesmas vulnerabilidades que o Mythos? Porque é que um Gemma 26B com 551 exemplos de fine-tuning se comporta como o Mythos em meta-cognição?
Escala não é diploma. Nunca foi. O diploma é a engenharia. E a engenharia está aberta.
Espero que tenham gostado do post. Como sempre, estejam à vontade para me contactar se tiverem perspectivas diferentes — especialmente se já andaram a experimentar com o OpenMythos, com BRLs, ou com arquitecturas recorrentes nos vossos homelabs. Estas conversas são sempre melhores quando saem do monólogo e vão para a experiência de campo.
Abraço! Nuno
Links úteis:
- OpenMythos no GitHub: https://github.com/kyegomez/OpenMythos
- Paper Parcae (scaling laws para looped transformers): https://arxiv.org/abs/2604.12946
- Issue #20 — Behavioral distillation: https://github.com/kyegomez/OpenMythos/issues/20
- “Second Thoughts” — Bidirectional Refinement Loops: https://bigattichouse.medium.com/second-thoughts-improving-small-llms-with-bidirectional-refinement-loops-part-1-fa5ab51af656
- “Repeat Yourself” — Layer duplication experiment: https://dnhkng.github.io/posts/rys/
- Ollama: https://ollama.ai
- Open WebUI: https://github.com/open-webui/open-webui
- O meu post anterior sobre Mythos vs modelos locais: https://blog.nuneshiggs.com/a-fronteira-irregular-porque-e-que-o-mythos-nao-mata-os-modelos-locais-mas-tambem-nao-devias-relaxar/