RadixArk Miles atteint la v0.1, mais le RL à l’échelle de la production doit encore faire ses preuves

RadixArk Miles a atteint la version 0.1 le 18 août 2026, neuf mois après sa première publication publique. Cette étape transforme un jeune dépôt en un système plus large dédié à l’apprentissage par renforcement, à l’entraînement d’agents et au post-entraînement distribué de modèles.

Cette distinction compte, car lancer une expérience de RL est plus facile que de la maintenir correcte sur de nombreuses machines. Les moteurs de rollout génèrent de l’expérience, les entraîneurs mettent à jour le modèle et les nouveaux poids doivent revenir aux workers d’inférence sans corrompre le processus.

Le projet est récemment apparu à la 14e place d’un instantané de liste populaire GitHub Trending. Cependant, cet agrégateur ne fournissait aucune heure de publication vérifiée, de sorte que ce classement ne constitue pas l’événement sous-jacent. L’information confirmée est la sortie de la v0.1 de RadixArk et ses affirmations détaillées concernant la production.

Miles arrive dans un domaine encombré de systèmes d’entraînement ouverts, dont le framework slime dont il est issu. Son véritable affrontement n’oppose donc pas un dépôt à un autre. Il oppose une infrastructure ouverte et inspectable aux stacks internes sur mesure que les équipes d’IA avancées construisent encore pour elles-mêmes.

RadixArk Miles v0.1 est l’événement confirmé

Le changement important n’est pas une position temporaire dans les tendances. RadixArk a associé à Miles une sortie numérotée et une vision de la production.

RadixArk et ses partenaires de l’écosystème ont publié la sortie Miles v0.1 le 18 août 2026. Ils l’ont décrite comme un système full-stack pour le post-entraînement de modèles de pointe. Cette description reste une affirmation du projet, et non une certification indépendante.

La date lève l’incertitude du flux de tendances. Le dépôt n’est pas apparu soudainement en septembre. Miles a d’abord été annoncé le 19 novembre 2025, puis développé publiquement avant d’atteindre l’étape de la v0.1.

La sortie originale de Miles présentait le projet comme une extension de slime orientée entreprise. Slime mettait l’accent sur une architecture légère et modifiable. Miles a conservé cette base tout en ajoutant une infrastructure destinée aux modèles mixture-of-experts de plus grande taille et aux charges de travail de production.

Un modèle mixture-of-experts, ou MoE, active des composants experts sélectionnés pour chaque token au lieu d’utiliser tous les paramètres. Cette conception peut améliorer l’efficacité de calcul, mais elle complique le routage, la cohérence de l’entraînement et l’exécution distribuée.

La version 0.1 cherche à couvrir toute la boucle de post-entraînement. SGLang génère les trajectoires, NVIDIA Megatron-LM ou PyTorch FSDP entraîne la politique, et une couche de synchronisation renvoie les poids mis à jour aux workers de rollout.

Cette portée est plus importante qu’une nouvelle implémentation d’algorithme. Les organisations peuvent déjà trouver du code pour PPO, GRPO, le fine-tuning supervisé et des méthodes connexes. Le travail difficile commence lorsque ces méthodes rencontrent de longues sessions d’agents, des politiques changeantes, des pannes matérielles et des charges de travail inégales.

RadixArk indique que Miles prend en charge l’apprentissage par renforcement synchrone et entièrement asynchrone. Dans le parcours asynchrone, les workers d’inférence continuent à générer des échantillons pendant que l’entraîneur consomme les groupes terminés et met à jour le modèle.

Le projet comprend également des intégrations pour les environnements d’agents et les fournisseurs de sandbox. Ces connexions permettent à une tâche d’entraînement d’exécuter des tâches de programmation ou d’utilisation d’ordinateur, d’enregistrer les trajectoires obtenues et de transmettre les scores de vérification comme récompenses.

Le dépôt Miles public fournit le code, les recettes, les tests, la documentation, les issues et l’historique de développement qui étayent ces affirmations. Sa licence Apache 2.0 donne aux équipes de larges droits pour inspecter et adapter l’implémentation.

Cette ouverture rend l’examen technique possible. Elle ne garantit pas qu’une autre organisation puisse reproduire les plus grands runs de RadixArk sans matériel, réseau et expertise opérationnelle comparables.

La version 0.1 doit donc être lue comme un marqueur de maturité. RadixArk a consolidé son architecture, documenté des charges de travail de référence et déclaré un objectif de production. Des preuves de déploiement plus larges constituent encore le prochain test.

Pourquoi le RL agentique crée un problème de systèmes

L’entraînement d’agents transforme le post-entraînement ordinaire de modèles en un problème de coordination couvrant l’inférence, les outils, les sandboxes, les récompenses et des poids qui évoluent continuellement.

Un rollout simple de modèle de langage peut générer une réponse à partir d’un prompt. Un rollout agentique peut ouvrir un terminal, inspecter des fichiers, appeler des outils, se remettre d’erreurs et poursuivre sur de nombreux tours.

Ces trajectoires se terminent rarement au même moment. Une tâche de programmation peut échouer rapidement, tandis qu’une autre peut passer plusieurs minutes à exécuter des commandes. Un entraîneur synchrone attend les membres les plus lents avant d’avancer, laissant du matériel coûteux inactif.

Miles répond à ce déséquilibre par une planification au niveau des échantillons. Lorsqu’une trajectoire se termine, une autre peut occuper immédiatement le slot disponible. Les groupes de trajectoires terminés entrent dans un buffer borné pour l’entraîneur.

Cette conception sépare la cadence des rollouts de celle de l’optimiseur. Elle soulève également une question difficile : jusqu’à quel point un échantillon d’expérience peut-il vieillir avant que la politique mise à jour ne le rende inadapté à l’entraînement ?

Dans l’apprentissage par renforcement asynchrone, le décalage de politique mesure l’écart entre le modèle qui génère un échantillon et la politique d’entraînement actuelle. Davantage de concurrence peut accroître l’utilisation du matériel, mais un décalage excessif peut affaiblir les hypothèses on-policy sur lesquelles repose un algorithme.

Miles expose des contrôles permettant d’accepter, de réessayer, d’écarter ou de rejeter les échantillons obsolètes. Cette flexibilité aide les chercheurs à définir leur propre limite, mais elle transfère à l’opérateur une décision importante de correction.

L’entraînement agentique introduit un autre décalage. Les appels d’outils et les templates de chat peuvent modifier la façon dont les messages deviennent des tokens entre les tours. L’entraîneur peut alors recevoir une séquence légèrement différente de celle utilisée lors de l’inférence.

Miles appelle sa réponse Token-In-Token-Out, ou TITO. Le serveur de session préserve les identifiants de tokens générés tout en ajoutant uniquement les messages nouvellement ajoutés. Les masques de perte excluent les tokens que le modèle n’a pas générés.

Ce mécanisme cible un mode d’échec subtil. Si le rollout et l’entraînement ne sont pas d’accord sur les tokens, les probabilités ou le routage des experts, l’optimiseur apprend à partir d’une interaction reconstruite plutôt que de l’expérience réelle.

La roadmap TITO publique du dépôt révèle également les limites du support actuel. Les familles de modèles nommées nécessitent une configuration explicite, et le système ne détecte pas automatiquement chaque template.

Ce détail constitue une preuve saine d’un projet d’ingénierie actif. Il montre que la fidélité des tokens dépend de contrats, de tests et d’intégrations spécifiques aux modèles. La fonctionnalité n’est pas un interrupteur universel qui rend correct chaque harnais d’agent externe.

Miles prend également en charge des environnements isolés pour les épisodes de programmation et d’utilisation d’ordinateur. Chaque tâche peut recevoir une sandbox neuve contenant ses propres fichiers, processus et vérificateur.

L’isolation est importante, car un épisode échoué ne doit pas contaminer un autre. Elle accroît aussi le travail d’orchestration, en particulier lorsque des milliers d’environnements doivent démarrer, s’exécuter, rapporter des récompenses et s’arrêter de manière prévisible.

Ces problèmes expliquent pourquoi la sortie de la v0.1 arrive maintenant. Le développement de l’IA passe de l’ajustement de réponses uniques à des agents qui agissent sur des périodes plus longues. L’infrastructure d’entraînement doit capturer ces actions sans perdre le contexte exact qui les a produites.

Les développeurs qui évaluent le projet devraient se concentrer sur cette couche de systèmes. Le support des algorithmes est nécessaire, mais la reproductibilité des trajectoires, le comportement de planification et la récupération après panne détermineront si un long run produit des preuves utiles.

Les équipes qui documentent leurs propres expériences ont également besoin d’archives consultables de configurations, d’échecs et de résultats d’évaluation. Une base de connaissances d’ingénierie structurée peut préserver ce contexte opérationnel en dehors du framework d’entraînement.

Le mécanisme central relie rollout, entraînement et mises à jour de poids

RadixArk Miles parie qu’une boucle coordonnée peut réduire les décalages créés par des stacks distinctes d’inférence et d’entraînement.

La boucle commence avec SGLang, un moteur d’inférence ouvert conçu pour le service de modèles à haut débit. Miles l’utilise pour générer de longues trajectoires multi-tours et réutiliser les préfixes mis en cache entre les sessions d’agents.

Le cache de préfixes stocke un état d’attention réutilisable pour le texte déjà traité par le modèle. Conserver les tours ultérieurs sur le même worker adapté peut éviter de recalculer à plusieurs reprises l’historique de conversation partagé.

Miles oriente les nouvelles sessions vers les workers les moins chargés tout en cherchant à préserver cette localité de cache. Cette approche vise le problème de la longue traîne, où quelques tâches longues consomment une capacité disproportionnée.

L’entraîneur traite ensuite les groupes terminés avec Megatron-LM ou FSDP. Megatron-LM prend en charge plusieurs formes de parallélisme de modèle, tandis que FSDP répartit l’état du modèle entre les workers parallèles aux données.

Proposer les deux parcours élargit l’audience potentielle. Les équipes disposant de déploiements Megatron établis peuvent utiliser ses contrôles distribués. Les équipes plus proches des implémentations de modèles Hugging Face peuvent utiliser FSDP sans passer par le même processus de conversion.

L’abstraction n’efface pas les différences entre backends. Les recettes Megatron peuvent répartir le travail entre les dimensions tensorielle, pipeline, contextuelle et experte. Le parcours FSDP utilise un modèle de distribution différent et peut nécessiter des adaptations d’architecture.

Après l’entraînement, Miles doit renvoyer les poids modifiés vers la flotte de rollout. Cette étape peut dominer le temps d’itération lorsque les modèles s’étendent sur de nombreux accélérateurs et que l’inférence utilise une disposition de sharding différente.

Pour les clusters directement connectés, le projet propose des transferts pair à pair via RDMA. L’accès direct à la mémoire distante permet aux machines d’écrire des données dans une mémoire distante avec une implication limitée du CPU.

RadixArk indique que ce parcours a réduit une mise à jour de poids Kimi-K2 d’un trillion de paramètres de 53,3 secondes à 7,2 secondes. Ce résultat provient de la charge de travail de référence du projet et doit être reproduit sous d’autres configurations réseau.

Miles propose également des mises à jour par delta disque lorsque la connectivité directe NCCL ou RDMA n’est pas disponible. Le système publie les portions modifiées de la politique au lieu d’envoyer un checkpoint complet après chaque étape.

Lors d’un run GLM-4.7-Flash rapporté, RadixArk indique que cela a réduit chaque charge utile de 62,4 Go à entre 0,69 Go et 0,83 Go. La pause de génération associée est restée entre trois et cinq secondes.

Ces chiffres décrivent des parcours de déploiement différents, et non une promesse de performance universelle. Le transfert pair à pair dépend d’un réseau rapide et d’une topologie compatible. Les deltas disque dépendent du nombre d’octets modifiés entre les versions de politique.

Le calcul basse précision ajoute une autre couche. Miles comprend des recettes utilisant l’entraînement tenant compte de la quantification FP8, MXFP8, NVFP4 et INT4 sur les modèles pris en charge.

La quantification représente les valeurs avec moins de bits afin de réduire l’utilisation mémoire et d’augmenter le débit. Toutefois, les côtés inférence et entraînement doivent appliquer des règles compatibles, sans quoi leurs différences numériques peuvent modifier le comportement de la politique.

Cette question devient plus sensible pour les modèles MoE. De faibles changements numériques peuvent sélectionner un expert différent pour un token, modifiant à la fois le calcul avant et les paramètres qui reçoivent des gradients.

Miles répond à ce problème avec Rollout Routing Replay, appelé R3. Il enregistre les choix de routage des experts durant l’inférence et les rejoue lors du passage avant de l’entraîneur.

C’est l’expression la plus claire du mécanisme central du projet. Le framework ne se contente pas de connecter des outils indépendants. Il cherche à préserver les décisions prises tout au long de la boucle RL.

Le même principe soutient la distillation on-policy et l’alignement zéro-KL. La distillation on-policy entraîne un élève à partir de signaux de l’enseignant collectés selon le comportement actuel de l’élève. L’alignement zéro-KL vise une concordance numérique entre le rollout et l’entraînement.

Chaque fonctionnalité s’attaque à une forme de divergence. Ensemble, elles font de Miles bien plus qu’un ensemble de scripts d’entraînement. Elles créent aussi une surface plus vaste qui doit rester correcte à travers les familles de modèles et les générations de matériel.

L’infrastructure ouverte défie les piles d’entraînement privées

Miles met sous pression les organisations qui considèrent encore l’infrastructure d’apprentissage par renforcement comme un avantage interne que toute équipe de modèles sérieuse doit reconstruire.

La position de RadixArk est simple. L’inférence ouverte s’est améliorée grâce à des systèmes partagés tels que SGLang, et l’infrastructure de post-entraînement devrait suivre une voie similaire.

L’entreprise a été lancée publiquement le 5 mai 2026, avec un financement d’amorçage de 100 millions de dollars et une valorisation post-money annoncée de 400 millions de dollars. Accel a dirigé le tour, avec Spark Capital en co-chef de file.

Sa stratégie d’infrastructure ouverte présente SGLang et Miles comme deux fondations. SGLang gère l’inférence, tandis que Miles couvre l’apprentissage par renforcement et le post-entraînement des modèles.

Ce financement change le contexte autour du dépôt. Miles n’est pas seulement une expérimentation menée par des bénévoles. C’est un actif stratégique pour une entreprise financée qui entend bâtir des produits managés autour d’infrastructures ouvertes.

L’adversaire principal est donc la pile RL privée. Les laboratoires de pointe assemblent souvent en interne des combinaisons de services de rollout, d’entraîneurs, de buffers de données, d’évaluateurs et de systèmes de checkpoints.

Ces plateformes internes peuvent refléter des années d’apprentissage opérationnel. Elles peuvent inclure des ordonnanceurs propriétaires, des kernels optimisés, une observabilité spécialisée et des procédures de récupération indisponibles dans les dépôts publics.

Miles cherche à réduire cet écart en publiant une base intégrée. Une startup peut commencer avec des recettes maintenues et des points d’extension, au lieu de connecter chaque sous-système depuis zéro.

Cela n’élimine pas le travail d’intégration. Une équipe doit toujours préparer les environnements, les récompenses, les jeux de données, les checkpoints de modèles, le réseau, le stockage et les critères d’évaluation.

La différence réside dans le point de départ de l’ingénierie. Sans framework intégré, l’équipe commence par construire la boucle de base. Avec Miles, elle peut commencer par vérifier si la boucle fournie correspond à sa charge de travail.

Le projet concurrence également, de manière indirecte, des frameworks de recherche plus simples. Slime reste une référence importante, car Miles est issu de sa conception et affirme que de nombreux changements remontent vers l’amont.

Cette relation complique tout récit opposant gagnants et perdants. Un petit framework peut rester préférable pour des recherches qui valorisent la transparence et les modifications rapides. Un système plus vaste peut servir les équipes ayant besoin de davantage de contrôles opérationnels intégrés.

Miles doit préserver ces deux qualités pour justifier sa position. Trop d’infrastructure peut compliquer le débogage, même lorsque le framework se présente comme modulaire.

L’entreprise met en avant des interfaces typées et des composants remplaçables pour le rollout, les récompenses, les pertes, les filtres et les sources de données. Ces points d’extension ne comptent que si les utilisateurs peuvent comprendre les défaillances qui surviennent à leurs frontières.

Les incitations commerciales méritent également l’attention. RadixArk bénéficie d’une large adoption des projets ouverts, puisque l’infrastructure managée et le support peuvent se développer autour de cette adoption.

Ce modèle est courant dans l’infrastructure open source. Il peut financer la maintenance et la validation matérielle. Il peut aussi créer des tensions quant aux capacités qui restent faciles à exploiter de manière indépendante.

La licence Apache 2.0 réduit certaines préoccupations liées au verrouillage, car les équipes peuvent forker et modifier le code. Une dépendance opérationnelle peut néanmoins apparaître à travers des services de déploiement, des outils propriétaires ou une expertise spécialisée.

Pour les acheteurs, la question pertinente n’est pas de savoir si Miles est ouvert. Elle est de savoir si une autre organisation peut l’exploiter de manière fiable sans devenir dépendante du savoir privé de RadixArk.

Pour les développeurs, le dépôt offre une valeur immédiate comme carte lisible du problème des systèmes RL. Son architecture montre où interagissent la fidélité des rollouts, l’ordonnancement, la précision et la synchronisation.

Pour les équipes produit en IA, cette infrastructure peut influencer la vitesse d’expérimentation. Des boucles plus rapides permettent de tester davantage d’environnements d’agents, de conceptions de récompenses et de stratégies de données avec le même budget matériel.

Ce que les exécutions de référence ne prouvent pas

RadixArk a publié des affirmations système inhabituellement concrètes, mais la plupart des preuves de performance proviennent toujours de l’équipe qui construit le framework.

L’exemple phare de la v0.1 a entraîné un modèle GLM-5.2 744B-A40B sur des tâches d’utilisation du terminal, réparties sur 64 GPU NVIDIA GB300. RadixArk a attribué 32 GPU au rollout et 32 à l’entraînement.

La configuration de référence utilisait une longueur de séquence maximale de 65 000 tokens et une taille de batch de 64. L’entreprise a rapporté 100 étapes de rollout stables, avec des étapes d’entraînement d’environ 4,5 minutes.

Elle a également indiqué un retard moyen de politique de 1,7 étape et un taux de réussite du cache de préfixes de 96 %. Les optimisations mémoire auraient économisé plus de 30 Go de HBM par GPU pour cette charge de travail.

Ces chiffres sont précieux, car ils donnent aux évaluateurs des cibles précises. Ils restent toutefois des mesures issues d’un seul modèle, cluster, version logicielle, distribution de tâches et configuration de réglage.

Une exécution de 100 étapes prouve que le système peut fonctionner dans cette configuration. Elle n’établit pas sa fiabilité sur de longues durées, à travers des milliers de mises à jour, des pannes intermittentes ou des charges d’environnement changeantes.

Le profil de performance peut également différer sur des clusters plus petits. Des fonctionnalités optimisées pour des dizaines d’accélérateurs récents peuvent ajouter de la complexité sans produire le même bénéfice sur huit GPU ou un matériel hétérogène.

La conception asynchrone du projet introduit un compromis inévitable. Maintenir le rollout et l’entraînement occupés augmente l’utilisation, mais des trajectoires plus anciennes peuvent davantage s’écarter de la politique actuelle.

RadixArk expose des contrôles de fraîcheur et rapporte le retard dans son exemple. Les utilisateurs indépendants doivent déterminer si ces contrôles préservent la qualité de l’apprentissage pour leurs algorithmes et leurs distributions de récompenses.

Les affirmations sur la basse précision méritent un examen similaire. RadixArk affirme que ses courbes de récompense suivent étroitement les références BF16 tout en réduisant le temps de rollout. Ce résultat ne peut pas être automatiquement transposé à chaque modèle, optimiseur ou tâche.

L’entraînement quantifié peut être sensible aux distributions d’activation et à certaines couches. Miles permet à des composants sélectionnés de rester en BF16, mais le choix de ces exceptions exige une validation propre à chaque modèle.

Le support des modèles est une autre cible mouvante. Le dépôt répertorie de nombreuses recettes denses, MoE, multimodales et agentiques. Une recette listée ne signifie pas que chaque combinaison de backend et de précision bénéficie du même niveau de tests.

Le suivi public des problèmes rend cette incertitude visible. Les signalements ouverts couvrent le comportement de synchronisation, la sémantique de configuration, les détails de LoRA, les alternatives de routage et le support de modalités supplémentaires.

Cette activité ne prouve pas que Miles est inhabituellement défectueux. Les projets d’entraînement distribué exposent normalement des modes de défaillance complexes. Elle montre toutefois pourquoi l’expression « prêt pour la production » doit être vérifiée au regard des exigences de chaque acheteur.

La tolérance aux pannes reste particulièrement importante. Une exécution à l’échelle d’un cluster peut perdre des heures lorsqu’un worker échoue, qu’un transfert bloque ou qu’un checkpoint devient incohérent.

La feuille de route initiale de 2025 identifiait explicitement une meilleure élasticité face aux défaillances des GPU comme un travail futur. La version 0.1 comprend davantage de mécanismes opérationnels, mais les utilisateurs devraient tout de même tester la récupération plutôt que de l’inférer à partir d’exécutions réussies.

La sécurité va également au-delà de l’entraîneur. Les environnements agentiques exécutent des actions générées par les modèles, y compris parfois des commandes shell et des requêtes réseau.

Des sandboxes fraîches réduisent la contamination entre épisodes, mais les opérateurs doivent examiner la provenance des images, les identifiants, les frontières réseau, les journaux et les artefacts conservés. Un framework d’entraînement ne peut pas définir le modèle de menace de chaque organisation.

La conclusion appropriée est mesurée. Miles a dépassé le stade de la démonstration minimale, et ses exécutions de référence sont techniquement significatives. Une maturité de production étendue exige encore des reproductions indépendantes et des historiques opérationnels plus longs.

Trois signaux détermineront si RadixArk Miles perdure

La prochaine étape dépend de la reproductibilité, de la récupération après panne et de l’adoption au-delà des équipes déjà liées à RadixArk ou SGLang.

Le premier signal est la reproduction indépendante des grandes charges de travail de référence. Les chercheurs n’ont pas besoin d’un cluster identique de 64 GPU, mais ils devraient publier des résultats comparables sur l’utilisation, le retard de politique et la convergence.

Une reproduction réussie renforcerait l’affirmation de RadixArk selon laquelle ses mécanismes de coordination se généralisent. De grands écarts inexpliqués suggéreraient qu’un réglage privé ou une topologie inhabituelle explique une part plus importante des performances publiées.

Le deuxième signal est la présence de preuves de récupération après panne lors d’exécutions longues. Les utilisateurs devraient surveiller des tests documentés impliquant des workers interrompus, des moteurs d’inférence bloqués, des environnements endommagés et la restauration de checkpoints.

Une récupération fiable soutiendrait davantage l’étiquette de production qu’un nouveau graphique de débit maximal. Des échecs répétés de synchronisation ou de reprise affaibliraient l’argument en faveur de l’utilisation de Miles pour des exécutions coûteuses sans supervision.

Le troisième signal est l’adoption par des équipes qui n’ont pas contribué à construire ou à annoncer le framework. Des études de cas indépendantes devraient préciser la taille du modèle, le matériel, le type de tâche, les modifications et les problèmes opérationnels rencontrés.

Les logos et témoignages fournissent des pistes utiles, mais les rapports détaillés ont davantage de poids. La preuve la plus convaincante montrerait ce que Miles a remplacé, le travail d’ingénierie qui restait et le temps économisé par l’équipe.

L’activité du dépôt apportera également du contexte aux trois signaux. Les mainteneurs doivent résoudre les problèmes de correction tout en prenant en charge de nouveaux modèles, précisions, matériels et environnements d’agents.

Cette charge peut créer une tension familière dans l’open source. Un support rapide attire les utilisateurs, tandis qu’une expansion excessive augmente le risque de régressions sur des combinaisons difficiles à tester.

La version la plus durable de Miles définirait un cœur testé et communiquerait clairement les limites expérimentales. Les utilisateurs pourraient alors distinguer les voies de production prises en charge des extensions prometteuses.

RadixArk doit aussi montrer que les contributions de la communauté influencent la feuille de route. Un dépôt étroitement lié aux priorités d’une seule entreprise peut rester ouvert tout en devenant difficile à orienter pour les acteurs externes.

Pour les petites équipes, la décision immédiate ne nécessite pas d’accepter chaque affirmation d’échelle. Elles peuvent tester un modèle pris en charge, un environnement et un backend par rapport à un flux de travail existant.

Cette évaluation devrait mesurer davantage que les tokens par seconde. Les équipes devraient consigner les épisodes échoués, les taux d’échantillons obsolètes, la reproductibilité des récompenses, la récupération des checkpoints et l’effort nécessaire pour diagnostiquer les problèmes.

Le verdict actuel est que RadixArk Miles est devenu une tentative ouverte sérieuse d’entraînement d’agents à l’échelle de la production. Sa sortie v0.1 d’août, et non un classement tendance sans date, est l’événement à suivre.

La prochaine preuve viendra des utilisateurs. Des équipes indépendantes peuvent-elles reproduire le comportement rapporté, récupérer après des exécutions défaillantes et étendre le système sans connaissances opérationnelles cachées ?

Les équipes qui envisagent RadixArk Miles devraient commencer par une charge de travail limitée et publier leurs résultats. Comparez les exécutions synchrones et asynchrones, examinez la fidélité des tokens et testez la récupération avant de passer à l’échelle. Consignez chaque changement de configuration et chaque hypothèse infirmée. Ces éléments compteront davantage que la seule dynamique du dépôt. Si ces résultats convergent entre différents modèles et clusters, Miles pourra devenir une base commune pour le post-entraînement ouvert. S’ils restent difficiles à reproduire, le projet demeurera une référence utile en matière de systèmes, mais pas encore un remplacement des infrastructures privées.