RadixArk Miles Chega à v0.1, mas o RL em Escala de Produção Ainda Precisa de Provas

O RadixArk Miles chegou à versão 0.1 em 18 de agosto de 2026, nove meses após seu primeiro lançamento público. O marco transforma um repositório jovem em um sistema mais amplo para aprendizado por reforço, treinamento de agentes e pós-treinamento distribuído de modelos.

Essa distinção importa porque iniciar um experimento de RL é mais fácil do que mantê-lo correto em muitas máquinas. Mecanismos de rollout geram experiência, treinadores atualizam o modelo, e novos pesos precisam retornar aos workers de inferência sem corromper o processo.

O projeto apareceu recentemente na posição 14 em um snapshot de uma lista de tendências do GitHub. No entanto, esse agregador não forneceu um horário de publicação verificado, portanto o ranking não é o evento central. A notícia confirmada é o lançamento da v0.1 do RadixArk e suas alegações detalhadas sobre produção.

Miles entra em um campo concorrido de sistemas abertos de treinamento, incluindo o framework slime, do qual evoluiu. Sua disputa real, portanto, não é entre um repositório e outro. Trata-se de infraestrutura aberta e inspecionável contra as pilhas internas personalizadas que equipes avançadas de IA ainda constroem para si.

RadixArk Miles v0.1 É o Evento Confirmado

A mudança importante não é uma posição temporária nas tendências. A RadixArk associou um lançamento numerado e uma narrativa de produção ao Miles.

A RadixArk e seus parceiros do ecossistema publicaram o lançamento do Miles v0.1 em 18 de agosto de 2026. Eles o descreveram como um sistema full-stack para o pós-treinamento de modelos de fronteira. Essa descrição continua sendo uma alegação do projeto, não uma certificação independente.

A data resolve a incerteza no feed de tendências. O repositório não surgiu subitamente em setembro. Miles foi anunciado inicialmente em 19 de novembro de 2025 e, em seguida, desenvolvido publicamente até alcançar o marco v0.1.

O lançamento original do Miles posicionou o projeto como uma extensão do slime voltada a empresas. O Slime enfatizava uma arquitetura pequena e modificável. O Miles manteve essa base, ao mesmo tempo que adicionou infraestrutura para modelos maiores de mixture-of-experts e cargas de trabalho de produção.

Um modelo mixture-of-experts, ou MoE, ativa componentes especialistas selecionados para cada token, em vez de usar todos os parâmetros. Esse design pode melhorar a eficiência computacional, mas complica o roteamento, a consistência do treinamento e a execução distribuída.

A versão 0.1 tenta abranger todo o ciclo de pós-treinamento. O SGLang gera trajetórias, o NVIDIA Megatron-LM ou o PyTorch FSDP treina a política, e uma camada de sincronização devolve os pesos atualizados aos workers de rollout.

Esse escopo é mais significativo do que a implementação de um novo algoritmo. As organizações já podem encontrar código para PPO, GRPO, ajuste fino supervisionado e métodos relacionados. O trabalho difícil começa quando esses métodos encontram sessões longas de agentes, políticas em mudança, falhas de hardware e cargas de trabalho desiguais.

A RadixArk afirma que o Miles oferece suporte a aprendizado por reforço síncrono e totalmente assíncrono. No caminho assíncrono, os workers de inferência continuam gerando amostras enquanto o treinador consome grupos concluídos e atualiza o modelo.

O projeto também inclui integrações para ambientes de agentes e provedores de sandbox. Essas conexões permitem que um trabalho de treinamento execute tarefas de programação ou uso de computador, registre as trajetórias resultantes e repasse as pontuações dos verificadores como recompensas.

O repositório público do Miles fornece o código, receitas, testes, documentação, issues e histórico de desenvolvimento por trás dessas alegações. Sua licença Apache 2.0 concede às equipes amplos direitos para inspecionar e adaptar a implementação.

Essa abertura torna possível o exame técnico. Ela não garante que outra organização possa reproduzir as maiores execuções da RadixArk sem hardware, rede e expertise operacional comparáveis.

A versão 0.1 deve, portanto, ser interpretada como um indicador de maturidade. A RadixArk consolidou sua arquitetura, documentou cargas de trabalho de referência e declarou uma meta de produção. Evidências de implantação mais ampla continuam sendo o próximo teste.

Por que o RL Agêntico Cria um Problema de Sistemas

O treinamento de agentes transforma o pós-treinamento comum de modelos em um problema de coordenação que abrange inferência, ferramentas, sandboxes, recompensas e pesos em constante mudança.

Um rollout simples de modelo de linguagem pode gerar uma resposta para um prompt. Um rollout agêntico pode abrir um terminal, inspecionar arquivos, chamar ferramentas, recuperar-se de erros e continuar ao longo de muitos turnos.

Essas trajetórias raramente terminam juntas. Uma tarefa de programação pode falhar rapidamente, enquanto outra pode passar minutos executando comandos. Um treinador síncrono espera pelos membros mais lentos antes de avançar, deixando hardware caro ocioso.

O Miles aborda esse desequilíbrio com agendamento em nível de amostra. Quando uma trajetória termina, outra pode ocupar imediatamente o slot disponível. Grupos de trajetórias concluídos entram em um buffer limitado para o treinador.

Esse design separa a cadência de rollout da cadência do otimizador. Ele também cria uma questão difícil: quanto uma amostra de experiência pode envelhecer antes que a política atualizada a torne inadequada para o treinamento?

No aprendizado por reforço assíncrono, o atraso de política mede o quanto o modelo que gera uma amostra está defasado em relação à política de treinamento atual. Mais concorrência pode elevar o uso de hardware, mas atraso excessivo pode enfraquecer as premissas on-policy por trás de um algoritmo.

O Miles expõe controles para aceitar, tentar novamente, descartar ou rejeitar amostras desatualizadas. Essa flexibilidade ajuda pesquisadores a definir seu próprio limite, mas transfere uma decisão importante de correção ao operador.

O treinamento agêntico introduz outro descompasso. Chamadas de ferramentas e templates de chat podem alterar como as mensagens se tornam tokens entre os turnos. O treinador pode então receber uma sequência ligeiramente diferente daquela usada durante a inferência.

O Miles chama sua abordagem de Token-In-Token-Out, ou TITO. O servidor de sessão preserva os identificadores de tokens gerados enquanto adiciona apenas mensagens recém-anexadas. Máscaras de perda excluem tokens que o modelo não gerou.

Esse mecanismo visa um modo sutil de falha. Se rollout e treinamento discordarem sobre tokens, probabilidades ou roteamento de especialistas, o otimizador aprende a partir de uma interação reconstruída, e não da experiência real.

O roadmap público do TITO do repositório também revela os limites do suporte atual. Famílias de modelos nomeadas exigem configuração explícita, e o sistema não detecta automaticamente todos os templates.

Esse detalhe é uma evidência saudável de um projeto de engenharia ativo. Ele mostra que a fidelidade de tokens depende de contratos, testes e integrações específicos de cada modelo. O recurso não é uma chave universal que torna correto todo harness externo de agentes.

O Miles também oferece suporte a ambientes isolados para episódios de programação e uso de computador. Cada tarefa pode receber um sandbox novo contendo seus próprios arquivos, processos e verificador.

O isolamento é importante porque um episódio com falha não deve contaminar outro. Ele também aumenta o trabalho de orquestração, especialmente quando milhares de ambientes precisam iniciar, executar, informar recompensas e encerrar de forma previsível.

Esses problemas explicam por que o lançamento da v0.1 chegou agora. O desenvolvimento de IA está migrando do ajuste de respostas únicas para agentes que atuam por períodos mais longos. A infraestrutura de treinamento precisa capturar essas ações sem perder o contexto exato que as produziu.

Desenvolvedores que avaliam o projeto devem se concentrar nessa camada de sistemas. O suporte a algoritmos é necessário, mas trajetórias reproduzíveis, comportamento de agendamento e recuperação de falhas determinarão se uma execução longa produz evidências úteis.

Equipes que documentam seus próprios experimentos também precisam de registros pesquisáveis de configurações, falhas e resultados de avaliação. Uma base de conhecimento de engenharia estruturada pode preservar esse contexto operacional fora do framework de treinamento.

O Mecanismo Central Conecta Rollout, Treinamento e Atualizações de Pesos

O RadixArk Miles aposta que um ciclo coordenado pode reduzir os descompassos criados por pilhas separadas de inferência e treinamento.

O ciclo começa com o SGLang, um mecanismo aberto de inferência projetado para servir modelos com alto throughput. O Miles o usa para gerar trajetórias longas e com múltiplos turnos, além de reutilizar prefixos em cache entre sessões de agentes.

O cache de prefixo armazena estados de atenção reutilizáveis para texto já processado pelo modelo. Manter turnos posteriores no mesmo worker adequado pode evitar o recálculo repetido do histórico compartilhado da conversa.

O Miles encaminha novas sessões para workers menos carregados enquanto tenta preservar essa localidade de cache. Essa abordagem visa o problema de cauda longa, em que algumas tarefas extensas consomem capacidade desproporcional.

Em seguida, o treinador processa grupos concluídos usando Megatron-LM ou FSDP. O Megatron-LM oferece suporte a diversas formas de paralelismo de modelo, enquanto o FSDP fragmenta o estado do modelo entre workers paralelos de dados.

Oferecer ambos os caminhos amplia o público potencial. Equipes com implantações estabelecidas de Megatron podem usar seus controles distribuídos. Equipes mais próximas de implementações de modelos do Hugging Face podem usar FSDP sem o mesmo processo de conversão.

A abstração não elimina as diferenças entre backends. As receitas do Megatron podem dividir o trabalho entre dimensões de tensor, pipeline, contexto e especialistas. O caminho FSDP usa um modelo de distribuição diferente e pode exigir adaptações de arquitetura.

Após o treinamento, o Miles precisa mover os pesos alterados de volta para a frota de rollout. Essa etapa pode dominar o tempo de iteração quando os modelos abrangem muitos aceleradores e a inferência usa um layout de fragmentação diferente.

Para clusters conectados diretamente, o projeto oferece transferências peer-to-peer por RDMA. O acesso direto remoto à memória permite que máquinas gravem dados na memória remota com envolvimento limitado da CPU.

A RadixArk relata que esse caminho reduziu uma atualização de pesos de 53,3 segundos para 7,2 segundos em um Kimi-K2 de um trilhão de parâmetros. O resultado vem da própria carga de trabalho de referência do projeto e precisa ser reproduzido em outros layouts de rede.

O Miles também oferece atualizações por delta em disco quando conectividade direta via NCCL ou RDMA não está disponível. O sistema publica partes alteradas da política em vez de enviar um checkpoint completo após cada etapa.

Em uma execução relatada do GLM-4.7-Flash, a RadixArk afirma que isso reduziu cada payload de 62,4 GB para entre 0,69 GB e 0,83 GB. A pausa associada à geração permaneceu entre três e cinco segundos.

Esses números descrevem caminhos de implantação diferentes, não uma promessa universal de desempenho. A transferência peer-to-peer depende de rede rápida e topologia compatível. Os deltas em disco dependem de quantos bytes mudam entre versões da política.

A computação de baixa precisão adiciona outra camada. O Miles inclui receitas que usam treinamento consciente de quantização FP8, MXFP8, NVFP4 e INT4 em modelos compatíveis.

A quantização representa valores com menos bits para reduzir o uso de memória e aumentar o throughput. No entanto, os lados de inferência e treinamento precisam aplicar regras compatíveis, ou suas diferenças numéricas podem alterar o comportamento da política.

Essa questão se torna mais acentuada em modelos MoE. Pequenas alterações numéricas podem selecionar um especialista diferente para um token, mudando tanto o cálculo direto quanto os parâmetros que recebem gradientes.

O Miles aborda isso com Rollout Routing Replay, chamado R3. Ele registra as escolhas de roteamento de especialistas durante a inferência e as reproduz durante a passagem direta do treinador.

Esta é a expressão mais clara do mecanismo central do projeto. O framework não apenas conecta ferramentas independentes. Ele tenta preservar as decisões tomadas ao longo de todo o ciclo de RL.

O mesmo princípio sustenta a destilação on-policy e o alinhamento zero-KL. A destilação on-policy treina um aluno a partir de sinais do professor coletados sob o comportamento atual do aluno. O alinhamento zero-KL busca concordância numérica entre rollout e treinamento.

Cada recurso combate uma forma de divergência. Em conjunto, eles fazem do Miles mais do que uma coleção de scripts de treinamento. Também criam uma superfície maior que precisa permanecer correta em diferentes famílias de modelos e gerações de hardware.

A Infraestrutura Aberta Está Desafiando Stacks Privadas de Treinamento

O Miles pressiona organizações que ainda tratam a infraestrutura de aprendizado por reforço como uma vantagem interna que toda equipe séria de modelos precisa reconstruir.

A posição da RadixArk é direta. A inferência aberta melhorou por meio de sistemas compartilhados como o SGLang, e a infraestrutura de pós-treinamento deveria seguir um caminho semelhante.

A empresa foi lançada publicamente em 5 de maio de 2026, com US$ 100 milhões em financiamento seed e uma avaliação pós-money declarada de US$ 400 milhões. A Accel liderou a rodada, com a Spark Capital como co-líder.

Sua estratégia de infraestrutura aberta nomeia SGLang e Miles como duas bases. O SGLang cuida da inferência, enquanto o Miles abrange aprendizado por reforço e pós-treinamento de modelos.

Esse financiamento muda o contexto em torno do repositório. O Miles não é apenas um experimento voluntário. É um ativo estratégico para uma empresa financiada que pretende desenvolver produtos gerenciados em torno de infraestrutura aberta.

O principal adversário, portanto, é a stack privada de RL. Laboratórios de ponta frequentemente montam combinações internas de serviços de rollout, treinadores, buffers de dados, avaliadores e sistemas de checkpoint.

Essas plataformas internas podem refletir anos de aprendizado operacional. Elas podem incluir agendadores proprietários, kernels otimizados, observabilidade especializada e procedimentos de recuperação indisponíveis em repositórios públicos.

O Miles tenta reduzir essa lacuna ao disponibilizar uma base integrada de forma aberta. Uma startup poderia começar com receitas mantidas e pontos de extensão, em vez de conectar cada subsistema do zero.

Isso não elimina o trabalho de integração. Uma equipe ainda precisa preparar ambientes, recompensas, conjuntos de dados, checkpoints de modelos, rede, armazenamento e critérios de avaliação.

A diferença está em onde a engenharia começa. Sem um framework integrado, a equipe primeiro constrói o loop básico. Com o Miles, ela pode começar testando se o loop fornecido corresponde à sua carga de trabalho.

O projeto também compete indiretamente com frameworks de pesquisa mais simples. O Slime continua sendo uma referência importante porque o Miles surgiu de seu design e afirma que muitas mudanças retornam ao projeto upstream.

Essa relação complica qualquer narrativa de vencedor contra perdedor. Um framework pequeno pode continuar preferível para pesquisas que valorizam transparência e modificações rápidas. Um sistema maior pode atender equipes que precisam de mais controles operacionais integrados.

O Miles precisa preservar ambas as qualidades para justificar sua posição. Infraestrutura em excesso pode tornar a depuração mais difícil, mesmo quando o framework se descreve como modular.

A empresa destaca interfaces tipadas e componentes substituíveis para rollout, recompensas, perdas, filtros e fontes de dados. Esses pontos de extensão só importam se os usuários conseguirem compreender falhas nas fronteiras entre eles.

Os incentivos comerciais também merecem atenção. A RadixArk se beneficia quando os projetos abertos se tornam amplamente adotados, pois infraestrutura gerenciada e suporte podem crescer em torno dessa adoção.

Esse modelo é comum em infraestrutura open source. Ele pode financiar manutenção e validação de hardware. Também pode criar tensão sobre quais capacidades permanecem fáceis de operar de forma independente.

A licença Apache 2.0 reduz algumas preocupações de lock-in, pois as equipes podem fazer fork e modificar o código. A dependência operacional ainda pode surgir por meio de serviços de implantação, ferramentas proprietárias ou conhecimento especializado.

Para compradores, a pergunta relevante não é se o Miles é aberto. A questão é se outra organização consegue operá-lo com confiabilidade sem se tornar dependente do conhecimento privado da RadixArk.

Para desenvolvedores, o repositório oferece valor imediato como um mapa legível do problema de sistemas de RL. Sua arquitetura expõe onde fidelidade de rollout, agendamento, precisão e sincronização interagem.

Para equipes de produtos de IA, essa infraestrutura pode afetar a velocidade de experimentação. Loops mais rápidos permitem testar mais ambientes de agentes, designs de recompensa e estratégias de dados dentro do mesmo orçamento de hardware.

O Que as Execuções de Referência Não Comprovam

A RadixArk publicou alegações de sistema incomumente concretas, mas a maior parte das evidências de desempenho ainda vem da equipe que desenvolve o framework.

O exemplo principal da v0.1 treinou um modelo GLM-5.2 744B-A40B em tarefas de uso de terminal usando 64 GPUs NVIDIA GB300. A RadixArk destinou 32 GPUs ao rollout e 32 ao treinamento.

A configuração de referência utilizou um comprimento máximo de sequência de 65.000 tokens e um tamanho de lote de 64. A empresa relatou 100 etapas estáveis de rollout, com etapas de treinamento durando cerca de 4,5 minutos.

Também relatou um atraso médio de política de 1,7 etapas e uma taxa de acerto de cache de prefixo de 96%. Segundo os relatos, otimizações de memória economizaram mais de 30 GB de HBM por GPU nessa carga de trabalho.

Esses números são valiosos porque fornecem metas específicas aos avaliadores. Ainda assim, permanecem medições de um único modelo, cluster, versão de software, distribuição de tarefas e configuração de ajuste.

Uma execução de 100 etapas é evidência de que o sistema pode operar nessa configuração. Ela não estabelece confiabilidade de longa duração ao longo de milhares de atualizações, falhas intermitentes ou mudanças nas cargas do ambiente.

O perfil de desempenho também pode ser diferente em clusters menores. Recursos otimizados para dezenas de aceleradores recentes podem adicionar complexidade sem gerar o mesmo benefício em oito GPUs ou em hardware misto.

O design assíncrono do projeto introduz uma troca inevitável. Manter rollout e treinamento ocupados aumenta a utilização, mas trajetórias mais antigas podem se afastar ainda mais da política atual.

A RadixArk expõe controles de desatualização e relata o atraso em seu exemplo. Usuários independentes precisam determinar se esses controles preservam a qualidade do aprendizado para seus algoritmos e distribuições de recompensa.

Alegações de baixa precisão merecem escrutínio semelhante. A RadixArk afirma que suas curvas de recompensa acompanham de perto as linhas de base BF16 enquanto reduzem o tempo de rollout. Esse resultado não pode ser transferido automaticamente para todos os modelos, otimizadores ou tarefas.

O treinamento quantizado pode ser sensível às distribuições de ativação e a camadas específicas. O Miles permite que componentes selecionados permaneçam em BF16, mas a escolha dessas exceções exige validação específica para cada modelo.

O suporte a modelos é outro alvo em movimento. O repositório lista muitas receitas densas, MoE, multimodais e agênticas. Uma receita listada não significa que toda combinação de backend e precisão receba o mesmo nível de teste.

O rastreador público de issues torna essa incerteza visível. Relatos abertos abordam comportamento de sincronização, semântica de configuração, detalhes de LoRA, alternativas de roteamento e suporte a modalidades adicionais.

Essa atividade não é evidência de que o Miles seja excepcionalmente defeituoso. Projetos de treinamento distribuído normalmente expõem modos de falha complexos. Ela mostra por que a expressão "pronto para produção" deve ser testada em relação aos requisitos de cada comprador.

A tolerância a falhas continua especialmente importante. Uma execução em escala de cluster pode perder horas quando um worker falha, uma transferência trava ou um checkpoint se torna inconsistente.

O roteiro original de 2025 identificava explicitamente uma melhor elasticidade diante de falhas de GPU como trabalho futuro. A versão 0.1 inclui mais mecanismos operacionais, mas os usuários ainda devem testar a recuperação em vez de inferi-la a partir de execuções bem-sucedidas.

A segurança também vai além do treinador. Ambientes agênticos executam ações geradas pelo modelo, às vezes incluindo comandos de shell e solicitações de rede.

Sandboxes novos reduzem a contaminação entre episódios, mas os operadores precisam revisar a procedência das imagens, credenciais, limites de rede, logs e artefatos retidos. Um framework de treinamento não pode definir o modelo de ameaças de todas as organizações.

A conclusão correta é ponderada. O Miles avançou além de uma demonstração mínima, e suas execuções de referência são tecnicamente significativas. A maturidade ampla para produção ainda exige reprodução independente e históricos operacionais mais longos.

Três Sinais Decidirão se o RadixArk Miles Vai Durar

A próxima etapa depende de reprodutibilidade, recuperação de falhas e adoção por equipes que já não estejam conectadas à RadixArk ou ao SGLang.

O primeiro sinal é a reprodução independente das grandes cargas de trabalho de referência. Pesquisadores não precisam de um cluster idêntico de 64 GPUs, mas devem publicar resultados comparáveis de utilização, atraso de política e convergência.

Uma reprodução bem-sucedida fortaleceria a alegação da RadixArk de que seus mecanismos de coordenação se generalizam. Grandes lacunas sem explicação sugeririam que ajuste privado ou uma topologia incomum explica uma parcela maior do desempenho publicado.

O segundo sinal é evidência de recuperação em falhas de longa duração. Os usuários devem observar testes documentados envolvendo workers interrompidos, mecanismos de inferência travados, ambientes danificados e restauração de checkpoints.

Uma recuperação confiável sustentaria o rótulo de produção com mais força do que outro gráfico de pico de throughput. Falhas repetidas de sincronização ou retomada enfraqueceriam o argumento para usar o Miles em execuções caras e sem supervisão.

O terceiro sinal é a adoção por equipes que não ajudaram a criar ou anunciar o framework. Estudos de caso independentes devem explicar o tamanho do modelo, hardware, tipo de tarefa, modificações e os problemas operacionais encontrados.

Logotipos e depoimentos oferecem pistas úteis, mas relatórios detalhados têm mais peso. A evidência mais forte mostraria o que o Miles substituiu, qual engenharia permaneceu necessária e quanto tempo a equipe economizou.

A atividade do repositório também fornecerá contexto para os três sinais. Os mantenedores precisam resolver questões de correção enquanto oferecem suporte a novos modelos, precisões, hardware e ambientes de agentes.

Essa carga de trabalho pode criar uma tensão familiar no open source. O suporte rápido atrai usuários, enquanto expansão excessiva aumenta o risco de regressões em combinações difíceis de testar.

A versão mais duradoura do Miles definiria um núcleo testado e comunicaria claramente os limites experimentais. Os usuários poderiam então distinguir caminhos de produção suportados de extensões promissoras.

A RadixArk também precisa mostrar que as contribuições da comunidade influenciam o roteiro. Um repositório estreitamente ligado às prioridades de uma empresa pode permanecer aberto, mas tornar-se difícil de direcionar por pessoas externas.

Para equipes menores, a decisão imediata não exige aceitar todas as alegações de escala. Elas podem testar um modelo suportado, um ambiente e um backend em relação a um fluxo de trabalho existente.

Essa avaliação deve medir mais do que tokens por segundo. As equipes devem registrar episódios com falha, taxas de amostras desatualizadas, reprodutibilidade de recompensas, recuperação de checkpoints e o esforço necessário para diagnosticar problemas.

O veredito atual é que o RadixArk Miles se tornou uma tentativa aberta séria de treinamento de agentes em escala de produção. Seu lançamento v0.1 em agosto, e não uma posição de tendência sem data, é o evento que vale acompanhar.

A próxima prova virá dos usuários. Equipes independentes conseguem reproduzir o comportamento relatado, recuperar execuções com falha e estender o sistema sem conhecimento operacional oculto?

As equipes que estiverem considerando o RadixArk Miles devem começar com uma carga de trabalho limitada e publicar o que encontrarem. Compare execuções síncronas e assíncronas, avalie a fidelidade dos tokens e teste a recuperação antes de escalar. Registre cada alteração de configuração e cada suposição que falhar. Essas evidências importarão mais do que o ritmo do repositório por si só. Se esses resultados convergirem entre diferentes modelos e clusters, Miles poderá se tornar uma base compartilhada para o pós-treinamento aberto. Se continuarem difíceis de reproduzir, o projeto ainda será uma referência útil de sistemas, mas ainda não substituirá a infraestrutura privada.