RadixArk Miles alcanza la v0.1, pero el RL a escala de producción aún necesita pruebas

RadixArk Miles alcanzó la versión 0.1 el 18 de agosto de 2026, nueve meses después de su primer lanzamiento público. Este hito transforma un repositorio joven en un sistema más amplio para el aprendizaje por refuerzo, el entrenamiento de agentes y el postentrenamiento distribuido de modelos.

La distinción importa porque iniciar un experimento de RL es más fácil que mantenerlo correcto en muchas máquinas. Los motores de rollout generan experiencia, los entrenadores actualizan el modelo y los nuevos pesos deben volver a los trabajadores de inferencia sin corromper el proceso.

El proyecto apareció recientemente en el puesto 14 de una instantánea de una lista de tendencias de GitHub. Sin embargo, ese agregador no proporcionó una hora de publicación verificada, por lo que la clasificación no constituye el evento subyacente. La noticia confirmada es el lanzamiento de la v0.1 de RadixArk y sus detalladas afirmaciones sobre producción.

Miles entra en un campo concurrido de sistemas de entrenamiento abiertos, incluido el framework slime del que evolucionó. Por tanto, su verdadera competencia no es un repositorio contra otro. Es infraestructura abierta e inspeccionable frente a las pilas internas personalizadas que los equipos avanzados de IA todavía construyen para sí mismos.

RadixArk Miles v0.1 es el evento confirmado

El cambio importante no es una posición temporal en tendencias. RadixArk ha vinculado a Miles un lanzamiento numerado y una narrativa de producción.

RadixArk y sus socios del ecosistema publicaron el lanzamiento de Miles v0.1 el 18 de agosto de 2026. Lo describieron como un sistema integral para el postentrenamiento de modelos de frontera. Esa descripción sigue siendo una afirmación del proyecto, no una certificación independiente.

La fecha resuelve la incertidumbre del feed de tendencias. El repositorio no apareció repentinamente en septiembre. Miles fue anunciado inicialmente el 19 de noviembre de 2025 y luego se desarrolló públicamente antes de alcanzar el hito de la v0.1.

El lanzamiento original de Miles posicionó el proyecto como una extensión de slime orientada a empresas. Slime había enfatizado una arquitectura pequeña y modificable. Miles conservó esa base al tiempo que añadió infraestructura para modelos más grandes de mezcla de expertos y cargas de trabajo de producción.

Un modelo de mezcla de expertos, o MoE, activa componentes expertos seleccionados para cada token en vez de utilizar todos los parámetros. Ese diseño puede mejorar la eficiencia computacional, pero complica el enrutamiento, la consistencia del entrenamiento y la ejecución distribuida.

La versión 0.1 intenta cubrir el ciclo completo de postentrenamiento. SGLang genera trayectorias, NVIDIA Megatron-LM o PyTorch FSDP entrenan la política, y una capa de sincronización devuelve los pesos actualizados a los trabajadores de rollout.

Ese alcance es más significativo que la implementación de un nuevo algoritmo. Las organizaciones ya pueden encontrar código para PPO, GRPO, el ajuste fino supervisado y métodos relacionados. El trabajo difícil comienza cuando esos métodos se enfrentan a largas sesiones de agentes, políticas cambiantes, fallos de hardware y cargas de trabajo desiguales.

RadixArk afirma que Miles admite aprendizaje por refuerzo síncrono y completamente asíncrono. En la ruta asíncrona, los trabajadores de inferencia siguen generando muestras mientras el entrenador consume grupos completados y actualiza el modelo.

El proyecto también incluye integraciones para entornos de agentes y proveedores de sandbox. Esas conexiones permiten que un trabajo de entrenamiento ejecute tareas de programación o uso de ordenador, registre las trayectorias resultantes y devuelva las puntuaciones de los verificadores como recompensas.

El repositorio público de Miles proporciona el código, las recetas, las pruebas, la documentación, las incidencias y el historial de desarrollo que respaldan esas afirmaciones. Su licencia Apache 2.0 ofrece a los equipos amplios derechos para inspeccionar y adaptar la implementación.

Esta apertura hace posible el examen técnico. No garantiza que otra organización pueda reproducir las mayores ejecuciones de RadixArk sin hardware, redes y experiencia operativa comparables.

Por tanto, la versión 0.1 debe leerse como un indicador de madurez. RadixArk ha consolidado su arquitectura, documentado cargas de trabajo de referencia y declarado un objetivo de producción. La evidencia de despliegues más amplios sigue siendo la próxima prueba.

Por qué el RL agéntico crea un problema de sistemas

El entrenamiento de agentes convierte el postentrenamiento ordinario de modelos en un problema de coordinación que abarca inferencia, herramientas, sandboxes, recompensas y pesos en constante cambio.

Un rollout simple de un modelo de lenguaje puede generar una respuesta a partir de un prompt. Un rollout agéntico puede abrir una terminal, inspeccionar archivos, llamar a herramientas, recuperarse de errores y continuar durante muchos turnos.

Esas trayectorias rara vez terminan al mismo tiempo. Una tarea de programación puede fallar rápidamente, mientras que otra puede pasar minutos ejecutando comandos. Un entrenador síncrono espera a los miembros más lentos antes de avanzar, dejando inactivo hardware costoso.

Miles aborda ese desequilibrio con programación a nivel de muestra. Cuando una trayectoria termina, otra puede ocupar inmediatamente la ranura disponible. Los grupos de trayectorias completados entran en un búfer limitado para el entrenador.

Este diseño separa la cadencia de los rollouts de la cadencia del optimizador. También plantea una pregunta difícil: ¿cuánto puede envejecer una muestra de experiencia antes de que la política actualizada la vuelva inadecuada para el entrenamiento?

En el aprendizaje por refuerzo asíncrono, el retraso de política mide cuánto se rezaga el modelo que genera una muestra respecto de la política de entrenamiento actual. Una mayor concurrencia puede elevar el uso del hardware, pero un retraso excesivo puede debilitar los supuestos on-policy en los que se basa un algoritmo.

Miles ofrece controles para aceptar, reintentar, descartar o rechazar muestras obsoletas. Esa flexibilidad ayuda a los investigadores a definir su propio límite, pero transfiere al operador una importante decisión de corrección.

El entrenamiento agéntico introduce otro desajuste. Las llamadas a herramientas y las plantillas de chat pueden modificar cómo los mensajes se convierten en tokens entre turnos. El entrenador podría entonces recibir una secuencia ligeramente distinta de la que se utilizó durante la inferencia.

Miles denomina a su respuesta Token-In-Token-Out, o TITO. El servidor de sesiones conserva los identificadores de token generados mientras añade únicamente los mensajes recién incorporados. Las máscaras de pérdida excluyen los tokens que el modelo no generó.

Este mecanismo apunta a un modo de fallo sutil. Si el rollout y el entrenamiento no coinciden en tokens, probabilidades o enrutamiento de expertos, el optimizador aprende de una interacción reconstruida y no de la experiencia real.

La hoja de ruta pública de TITO del repositorio también revela los límites del soporte actual. Las familias de modelos especificadas requieren una configuración explícita y el sistema no detecta automáticamente todas las plantillas.

Ese detalle es una señal saludable de un proyecto de ingeniería activo. Muestra que la fidelidad de los tokens depende de contratos, pruebas e integraciones específicos de cada modelo. La función no es un interruptor universal que haga correcto cualquier arnés externo de agentes.

Miles también admite entornos aislados para episodios de programación y uso de ordenador. Cada tarea puede recibir un sandbox nuevo que contiene sus propios archivos, procesos y verificador.

El aislamiento importa porque un episodio fallido no debería contaminar otro. También incrementa el trabajo de orquestación, especialmente cuando miles de entornos deben iniciarse, ejecutarse, informar recompensas y finalizar de forma predecible.

Estos problemas explican por qué el lanzamiento de la v0.1 llega ahora. El desarrollo de IA está pasando del ajuste de respuestas individuales a agentes que actúan durante periodos más largos. La infraestructura de entrenamiento debe capturar esas acciones sin perder el contexto exacto que las produjo.

Los desarrolladores que evalúen el proyecto deberían centrarse en esta capa de sistemas. El soporte de algoritmos es necesario, pero las trayectorias reproducibles, el comportamiento de programación y la recuperación ante fallos determinarán si una ejecución larga produce evidencia útil.

Los equipos que documenten sus propios experimentos también necesitan registros consultables de configuraciones, fallos y resultados de evaluación. Una base de conocimientos de ingeniería estructurada puede conservar ese contexto operativo fuera del framework de entrenamiento.

El mecanismo central conecta rollout, entrenamiento y actualizaciones de pesos

RadixArk Miles apuesta a que un único ciclo coordinado puede reducir los desajustes creados por pilas separadas de inferencia y entrenamiento.

El ciclo comienza con SGLang, un motor de inferencia abierto diseñado para el servicio de modelos de alto rendimiento. Miles lo utiliza para generar trayectorias largas de varios turnos y reutilizar prefijos almacenados en caché entre sesiones de agentes.

La caché de prefijos almacena el estado de atención reutilizable del texto que el modelo ya procesó. Mantener los turnos posteriores en el mismo trabajador adecuado puede evitar calcular repetidamente el historial compartido de la conversación.

Miles enruta las nuevas sesiones hacia trabajadores con menor carga mientras intenta preservar esa localidad de caché. Este enfoque apunta al problema de la cola larga, donde unas pocas tareas extensas consumen una capacidad desproporcionada.

El entrenador procesa luego los grupos completados con Megatron-LM o FSDP. Megatron-LM admite varias formas de paralelismo de modelos, mientras que FSDP fragmenta el estado del modelo entre trabajadores de paralelismo de datos.

Ofrecer ambas rutas amplía la audiencia potencial. Los equipos con despliegues consolidados de Megatron pueden utilizar sus controles distribuidos. Los equipos más cercanos a las implementaciones de modelos de Hugging Face pueden usar FSDP sin pasar por el mismo proceso de conversión.

La abstracción no elimina las diferencias entre backends. Las recetas de Megatron pueden dividir el trabajo entre dimensiones de tensor, pipeline, contexto y expertos. La ruta FSDP utiliza un modelo de distribución diferente y puede requerir adaptaciones de arquitectura.

Tras el entrenamiento, Miles debe trasladar los pesos modificados de vuelta a la flota de rollout. Ese paso puede dominar el tiempo de iteración cuando los modelos abarcan muchos aceleradores y la inferencia utiliza un diseño de fragmentación distinto.

Para clústeres conectados directamente, el proyecto ofrece transferencias peer-to-peer mediante RDMA. El acceso directo remoto a memoria permite que las máquinas escriban datos en memoria remota con una participación limitada de la CPU.

RadixArk informa que esta ruta redujo una actualización de pesos de Kimi-K2 de un billón de parámetros de 53,3 segundos a 7,2 segundos. El resultado procede de la propia carga de trabajo de referencia del proyecto y necesita reproducirse con otros diseños de red.

Miles también proporciona actualizaciones de delta en disco cuando no hay conectividad directa mediante NCCL o RDMA. El sistema publica las partes modificadas de la política en lugar de enviar un checkpoint completo después de cada paso.

En una ejecución reportada de GLM-4.7-Flash, RadixArk afirma que esto redujo cada carga útil de 62,4 GB a entre 0,69 GB y 0,83 GB. La pausa asociada a la generación se mantuvo entre tres y cinco segundos.

Estas cifras describen distintas rutas de despliegue, no una promesa de rendimiento universal. La transferencia peer-to-peer depende de redes rápidas y una topología compatible. Los deltas en disco dependen de cuántos bytes cambian entre versiones de la política.

La computación de baja precisión añade otra capa. Miles incluye recetas que usan entrenamiento consciente de cuantización FP8, MXFP8, NVFP4 e INT4 en modelos compatibles.

La cuantización representa valores con menos bits para reducir el uso de memoria y aumentar el rendimiento. Sin embargo, las partes de inferencia y entrenamiento deben aplicar reglas compatibles, o sus diferencias numéricas pueden alterar el comportamiento de la política.

Ese problema se acentúa en los modelos MoE. Cambios numéricos minúsculos pueden seleccionar un experto diferente para un token, modificando tanto el cálculo hacia adelante como los parámetros que reciben gradientes.

Miles aborda esto con Rollout Routing Replay, denominado R3. Registra las decisiones de enrutamiento de expertos durante la inferencia y las reproduce durante el paso hacia adelante del entrenador.

Esta es la expresión más clara del mecanismo central del proyecto. El framework no se limita a conectar herramientas independientes. Intenta preservar las decisiones tomadas a lo largo de todo el ciclo de RL.

El mismo principio respalda la destilación on-policy y la alineación zero-KL. La destilación on-policy entrena a un estudiante a partir de señales del profesor recopiladas bajo el comportamiento actual del estudiante. La alineación zero-KL busca una concordancia numérica entre el rollout y el entrenamiento.

Cada función aborda una forma de divergencia. En conjunto, hacen que Miles sea más que una colección de scripts de entrenamiento. También crean una superficie mayor que debe mantenerse correcta entre familias de modelos y generaciones de hardware.

La infraestructura abierta desafía las pilas privadas de entrenamiento

Miles presiona a las organizaciones que todavía consideran la infraestructura de aprendizaje por refuerzo una ventaja interna que todo equipo serio de modelos debe reconstruir.

La postura de RadixArk es sencilla. La inferencia abierta mejoró gracias a sistemas compartidos como SGLang, y la infraestructura de postentrenamiento debería seguir un camino similar.

La empresa se lanzó públicamente el 5 de mayo de 2026, con 100 millones de dólares en financiación semilla y una valoración post-money declarada de 400 millones de dólares. Accel lideró la ronda, con Spark Capital como co-líder.

Su estrategia de infraestructura abierta identifica a SGLang y Miles como dos pilares. SGLang gestiona la inferencia, mientras que Miles cubre el aprendizaje por refuerzo y el postentrenamiento de modelos.

Esa financiación cambia el contexto del repositorio. Miles no es solo un experimento voluntario. Es un activo estratégico para una empresa financiada que pretende desarrollar productos gestionados en torno a infraestructura abierta.

Por tanto, el principal adversario es la pila privada de RL. Los laboratorios de frontera suelen ensamblar combinaciones internas de servicios de rollout, entrenadores, búferes de datos, evaluadores y sistemas de checkpoints.

Esas plataformas internas pueden reflejar años de aprendizaje operativo. Pueden incluir planificadores propietarios, kernels optimizados, observabilidad especializada y procedimientos de recuperación no disponibles en repositorios públicos.

Miles intenta reducir esa brecha al poner a disposición pública una base integrada. Una startup podría comenzar con recetas mantenidas y puntos de extensión, en lugar de conectar cada subsistema desde cero.

Esto no elimina el trabajo de integración. Un equipo aún debe preparar entornos, recompensas, conjuntos de datos, checkpoints de modelos, redes, almacenamiento y criterios de evaluación.

La diferencia está en el punto de partida de la ingeniería. Sin un framework integrado, el equipo primero construye el bucle básico. Con Miles, puede empezar comprobando si el bucle proporcionado se ajusta a su carga de trabajo.

El proyecto también compite indirectamente con frameworks de investigación más simples. Slime sigue siendo una referencia importante porque Miles se originó en su diseño y afirma que muchos cambios vuelven al proyecto upstream.

Esa relación complica cualquier narrativa de ganador contra perdedor. Un framework pequeño puede seguir siendo preferible para investigaciones que valoran la transparencia y la modificación rápida. Un sistema más amplio puede servir a equipos que necesitan más controles operativos integrados.

Miles debe preservar ambas cualidades para justificar su posición. Demasiada infraestructura puede dificultar la depuración, incluso cuando el framework se describe a sí mismo como modular.

La empresa destaca interfaces tipadas y componentes reemplazables para rollout, recompensas, pérdidas, filtros y fuentes de datos. Esos puntos de extensión solo importan si los usuarios pueden comprender los fallos que se producen entre sus límites.

Los incentivos comerciales también merecen atención. RadixArk se beneficia cuando los proyectos abiertos logran una adopción amplia, ya que la infraestructura gestionada y el soporte pueden crecer alrededor de esa adopción.

Ese modelo es común en la infraestructura de código abierto. Puede financiar el mantenimiento y la validación de hardware. También puede generar tensiones sobre qué capacidades siguen siendo fáciles de operar de forma independiente.

La licencia Apache 2.0 reduce algunas preocupaciones de dependencia, porque los equipos pueden bifurcar y modificar el código. La dependencia operativa aún puede surgir a través de servicios de despliegue, herramientas propietarias o conocimientos especializados.

Para los compradores, la pregunta relevante no es si Miles es abierto. La pregunta es si otra organización puede operarlo de manera fiable sin volverse dependiente del conocimiento privado de RadixArk.

Para los desarrolladores, el repositorio ofrece valor inmediato como un mapa legible del problema de los sistemas de RL. Su arquitectura muestra dónde interactúan la fidelidad del rollout, la planificación, la precisión y la sincronización.

Para los equipos de producto de IA, esa infraestructura puede afectar la velocidad de experimentación. Los bucles más rápidos permiten probar más entornos de agentes, diseños de recompensas y estrategias de datos con el mismo presupuesto de hardware.

Lo que las ejecuciones de referencia no demuestran

RadixArk ha publicado afirmaciones de sistema inusualmente concretas, pero la mayor parte de la evidencia de rendimiento sigue procediendo del equipo que construye el framework.

El ejemplo insignia de v0.1 entrenó un modelo GLM-5.2 744B-A40B en tareas de uso de terminal mediante 64 GPU NVIDIA GB300. RadixArk asignó 32 GPU al rollout y 32 al entrenamiento.

La configuración de referencia utilizó una longitud máxima de secuencia de 65.000 tokens y un tamaño de lote de 64. La empresa informó de 100 pasos de rollout estables, con pasos de entrenamiento de aproximadamente 4,5 minutos.

También informó de un retraso medio de política de 1,7 pasos y una tasa de aciertos de caché de prefijos del 96 %. Según se informa, las optimizaciones de memoria ahorraron más de 30 GB de HBM por GPU en esa carga de trabajo.

Estas cifras son valiosas porque ofrecen objetivos concretos a los evaluadores. Siguen siendo mediciones de un modelo, un clúster, una versión de software, una distribución de tareas y una configuración de ajuste.

Una ejecución de 100 pasos demuestra que el sistema puede operar con esa configuración. No establece una fiabilidad de larga duración a través de miles de actualizaciones, fallos intermitentes o cargas cambiantes del entorno.

El perfil de rendimiento también puede diferir en clústeres más pequeños. Las funciones optimizadas para decenas de aceleradores recientes pueden añadir complejidad sin aportar el mismo beneficio en ocho GPU o en hardware mixto.

El diseño asíncrono del proyecto introduce una disyuntiva inevitable. Mantener ocupados el rollout y el entrenamiento aumenta la utilización, pero las trayectorias más antiguas pueden alejarse más de la política actual.

RadixArk expone controles de obsolescencia e informa del retraso en su ejemplo. Los usuarios independientes deben determinar si esos controles preservan la calidad del aprendizaje para sus algoritmos y distribuciones de recompensas.

Las afirmaciones sobre baja precisión merecen un escrutinio similar. RadixArk afirma que sus curvas de recompensa siguen de cerca las líneas base BF16 mientras reducen el tiempo de rollout. Ese resultado no puede trasladarse automáticamente a todos los modelos, optimizadores o tareas.

El entrenamiento cuantizado puede ser sensible a las distribuciones de activación y a capas concretas. Miles permite que componentes seleccionados permanezcan en BF16, pero elegir esas excepciones exige validación específica para cada modelo.

El soporte de modelos es otro objetivo móvil. El repositorio enumera muchas recetas densas, MoE, multimodales y agénticas. Que una receta figure en la lista no significa que cada combinación de backend y precisión reciba el mismo nivel de pruebas.

El rastreador público de incidencias hace visible esa incertidumbre. Los informes abiertos abarcan el comportamiento de sincronización, la semántica de configuración, los detalles de LoRA, alternativas de enrutamiento y soporte para modalidades adicionales.

Esa actividad no prueba que Miles sea inusualmente defectuoso. Los proyectos de entrenamiento distribuido normalmente exponen modos de fallo complejos. Sí muestra por qué la expresión "listo para producción" debe evaluarse frente a los requisitos de cada comprador.

La tolerancia a fallos sigue siendo especialmente importante. Una ejecución a escala de clúster puede perder horas cuando falla un trabajador, se bloquea una transferencia o un checkpoint se vuelve inconsistente.

La hoja de ruta original de 2025 identificó explícitamente una mejor elasticidad frente a fallos de GPU como trabajo futuro. La versión 0.1 incluye más maquinaria operativa, pero los usuarios deberían probar la recuperación en lugar de inferirla a partir de ejecuciones exitosas.

La seguridad también va más allá del entrenador. Los entornos agénticos ejecutan acciones generadas por modelos, a veces incluidos comandos de shell y solicitudes de red.

Los entornos aislados nuevos reducen la contaminación entre episodios, pero los operadores deben revisar la procedencia de las imágenes, las credenciales, los límites de red, los registros y los artefactos conservados. Un framework de entrenamiento no puede definir el modelo de amenazas de cada organización.

La conclusión correcta es mesurada. Miles ha superado una demostración mínima, y sus ejecuciones de referencia son técnicamente significativas. La madurez general para producción todavía requiere reproducción independiente e historiales operativos más largos.

Tres señales decidirán si RadixArk Miles perdura

La siguiente etapa depende de la reproducibilidad, la recuperación ante fallos y la adopción más allá de los equipos ya vinculados con RadixArk o SGLang.

La primera señal es la reproducción independiente de las grandes cargas de trabajo de referencia. Los investigadores no necesitan un clúster idéntico de 64 GPU, pero deberían publicar resultados comparables de utilización, retraso de política y convergencia.

Una reproducción exitosa reforzaría la afirmación de RadixArk de que sus mecanismos de coordinación se generalizan. Grandes diferencias sin explicación sugerirían que el ajuste privado o una topología inusual explican una mayor parte del rendimiento publicado.

La segunda señal es la evidencia de recuperación ante fallos en ejecuciones prolongadas. Los usuarios deberían buscar pruebas documentadas que involucren trabajadores interrumpidos, motores de inferencia bloqueados, entornos dañados y restauración de checkpoints.

Una recuperación fiable respaldaría la etiqueta de producción con más fuerza que otro gráfico de rendimiento máximo. Los fallos repetidos de sincronización o reanudación debilitarían el argumento para usar Miles en ejecuciones costosas sin supervisión.

La tercera señal es la adopción por equipos que no ayudaron a construir ni anunciar el framework. Los estudios de caso independientes deberían explicar el tamaño del modelo, el hardware, el tipo de tarea, las modificaciones y los problemas operativos encontrados.

Los logotipos y testimonios ofrecen pistas útiles, pero los informes detallados tienen más peso. La evidencia más sólida mostraría qué sustituyó Miles, qué trabajo de ingeniería permaneció y cuánto tiempo ahorró el equipo.

La actividad del repositorio también aportará contexto a las tres señales. Los mantenedores deben resolver problemas de corrección mientras dan soporte a nuevos modelos, precisiones, hardware y entornos agénticos.

Esa carga de trabajo puede crear una tensión conocida en el código abierto. El soporte rápido atrae usuarios, mientras que una expansión excesiva aumenta el riesgo de regresiones entre combinaciones difíciles de probar.

La versión más duradera de Miles definiría un núcleo probado y comunicaría claramente los límites experimentales. Así, los usuarios pueden distinguir las rutas de producción compatibles de las extensiones prometedoras.

RadixArk también debe demostrar que las contribuciones de la comunidad influyen en la hoja de ruta. Un repositorio estrechamente ligado a las prioridades de una empresa puede seguir siendo abierto y, al mismo tiempo, resultar difícil de orientar para externos.

Para los equipos pequeños, la decisión inmediata no exige aceptar todas las afirmaciones de escala. Pueden probar un modelo compatible, un entorno y un backend frente a un flujo de trabajo existente.

Esa evaluación debería medir más que los tokens por segundo. Los equipos deberían registrar episodios fallidos, tasas de muestras obsoletas, reproducibilidad de recompensas, recuperación de checkpoints y el esfuerzo necesario para diagnosticar problemas.

El veredicto actual es que RadixArk Miles se ha convertido en un intento abierto serio de entrenamiento de agentes a escala de producción. Su lanzamiento v0.1 de agosto, y no un puesto de tendencia sin fecha, es el acontecimiento que merece seguimiento.

La próxima prueba vendrá de los usuarios. ¿Pueden los equipos independientes reproducir el comportamiento informado, recuperar ejecuciones fallidas y ampliar el sistema sin conocimientos operativos ocultos?

Los equipos que estén considerando RadixArk Miles deberían empezar con una carga de trabajo acotada y publicar lo que encuentren. Comparen ejecuciones síncronas y asíncronas, revisen la fidelidad de los tokens y prueben la recuperación antes de escalar. Registren cada cambio de configuración y cada suposición fallida. Esa evidencia importará más que el impulso del repositorio por sí solo. Si esos resultados convergen entre distintos modelos y clústeres, Miles puede convertirse en una base compartida para el postentrenamiento abierto. Si siguen siendo difíciles de reproducir, el proyecto seguirá siendo una referencia útil de sistemas, pero todavía no un reemplazo de la infraestructura privada.