Реинфорсмент-лернинг (RL) стал центральной частью post-training больших языковых моделей, но по мере роста моделей и перехода на архитектуру mixture-of-experts (MoE) задача RL post-training перестала быть просто training loop. Теперь это distributed systems problem, требующий координации rollout workers, trainers, weight synchronization и routing consistency.

Miles — open source фреймворк от RadixArk, который решает эту проблему через композицию лучших инструментов: SGLang для rollout, NVIDIA Megatron-LM для training, Ray для оркестрации и PyTorch как общий слой программирования и numerics. Фреймворк поддерживает frontier-модели (DeepSeek-V4, Kimi K2.5, GLM-5, Qwen3.5), low-precision рецепты (BF16, FP8, MXFP8, INT4-QAT) и асинхронное выполнение, что делает large-scale LLM RL training более воспроизводимым и масштабируемым.

Что такое RL post-training и почему это теперь системная задача

Классическое fine-tuning моделей — это сравнительно простой процесс: берёшь предобученную модель, прогоняешь через неё датасет, оптимизируешь loss. RL post-training сложнее, потому что модель не просто обучается на статичных данных, а взаимодействует со средой (environment), генерирует ответы (rollout), получает reward и обновляет политику на основе этих reward.

Для небольших моделей это работает нормально. Но когда речь идёт о моделях с сотнями миллиардов параметров, работающих на сотнях GPU, возникают системные проблемы. Rollout workers должны генерировать сэмплы с высокой throughput. Trainers должны потреблять эти сэмплы эффективно и вычислять стабильные policy updates. Rollout policy и training policy должны оставаться синхронизированными — иначе обучение разваливается. MoE-модели добавляют ещё один уровень сложности: routing behavior должен оставаться согласованным между rollout и training, иначе эксперты начинают работать по-разному в двух фазах.

Miles был построен именно для этого setting'а.

Архитектура Miles: small core, many edges

Философия Miles — маленькое ядро с множеством точек расширения. Основной training loop намеренно компактный, содержащий только essentials: forward pass, backward pass, optimizer step. Pieces, которые пользователи чаще всего хотят менять — rollout logic, reward computation, loss functions, sample filtering, metrics, training hooks — подключаются при запуске через user-supplied Python modules. Это позволяет командам адаптировать систему под новые алгоритмы без форка фреймворка.

Под капотом Miles композирует четыре системы.

SGLang отвечает за high-throughput rollout generation. SGLang — это движок для inference LLM, оптимизированный для batch generation с высокой утилизацией GPU memory. В контексте RL он генерирует сэмплы для training, используя radix tree prefix caching для ускорения повторяющихся prompt patterns. Для long context RL tasks это даёт 2–3× speedup по сравнению с naive batching.

Megatron-LM используется как production training backend. Miles не оборачивает Megatron как black box, а встраивается напрямую в его argument parser, model-construction pipeline, training loop, parallelism primitives и distributed checkpoint format. Это даёт доступ к infrastructure для frontier-scale dense и MoE training — tensor parallelism, pipeline parallelism, expert parallelism, activation checkpointing, fused kernels.

Ray обеспечивает cluster orchestration — actor lifecycle, scheduling, supervision. Каждый long-lived процесс в Miles представлен как Ray actor: trainer ranks, SGLang rollout servers, routing proxies, asynchronous rollout workers. Ray даёт GPU-aware scheduler, placement groups для actor placement и fault tolerance для week-long workloads. Когда GPU падает, Ray автоматически restarts actor на доступном node без остановки всей training run.

PyTorch остаётся общим programming model — model components это torch.nn.Modules, losses это стандартные autograd graphs, mixed precision, gradient checkpointing, distributed primitives и profiling работают через знакомые PyTorch workflows. Это критично для extensibility: команды могут добавлять новые modules, instrument performance, debug issues используя существующие PyTorch tools без изучения новой абстракции.

Такая композиция важна, потому что RL post-training требует, чтобы generation и training работали вместе, но эти фазы имеют очень разные performance profiles. Rollout memory-bandwidth-bound (KV-cache и parameter reads доминируют во время decoding). Training compute-bound и communication-heavy. Weight synchronization, sample transfer, checkpoint conversion, routing consistency и low-precision behavior должны обрабатываться аккуратно на границе между фазами.

Как Miles решает ключевые проблемы

Асинхронное выполнение. Благодаря тому, что Ray actors persistent, держат собственное состояние и планируются независимо, Miles может работать в fully asynchronous mode. Rollout actors непрерывно стримят сэмплы в очередь, которую trainer draining в собственном темпе. Это устраняет per-iteration blocking между фазами — rollout не ждёт training, training не ждёт rollout.

Быстрая синхронизация весов. После каждого training update свежие веса должны попасть к rollout workers. Miles использует dedicated NCCL/RDMA channels для bulk tensor transfer, а Ray обрабатывает только control path. Это значит, что огромные тензоры не проходят через Python data path, что критично для скорости.

MoE-aware alignment. Для MoE-моделей routing decisions должны сохраняться между rollout и training. Miles реализует Rollout Routing Replay — механизм, который сохраняет routing decisions через границу rollout/training, уменьшая routing mismatch, который иначе дестабилизировал бы MoE RL.

Low-precision pipeline. Miles строит low-precision pipeline на PyTorch dtype system — BF16, FP8, MXFP8, INT4-QAT recipes охватывают и training, и rollout, а не живут как изолированные backend-only features. Это consistency критична для RL, потому что policy, генерирующая сэмплы, и policy, вычисляющая training log probabilities, должны оставаться согласованными.

Parallelism-aware checkpointing. Miles использует Megatron distributed checkpoint format, что позволяет конвертировать модель из Hugging Face один раз и загружать её в разных tensor/pipeline/context/expert parallel конфигурациях без повторной конвертации весов. Для команд, оперирующих большими training jobs, это значит, что checkpoint conversion и parallelism changes не становятся отдельным инженерным проектом при каждой смене модели или cluster shape.

Model specs вместо long-lived forks. Frontier architectures меняются быстро — новые attention blocks, routing mechanisms, expert layouts приходят в разных model families. Miles обрабатывает это через plug-in model specs — небольшие spec files, которые вставляют custom PyTorch components (gated attention-output module, Gated-Delta-Net block, model-specific MoE router) прямо в Megatron model pipeline. Это позволяет поддерживать DeepSeek-V3/V4, GLM-4.7, Qwen3 MoE variants без поддержания long-lived Megatron fork.

Практическая ценность: что это даёт инженерам

Miles предоставляет готовые recipes для frontier и open-source моделей: DeepSeek-V4, Kimi K2.5/K2.6, GLM-5/5.1, Qwen3.5/3.6, с поддержкой NVIDIA Hopper и Blackwell GPUs. Фреймворк поддерживает LoRA в обоих путях — rollout и training — что позволяет parameter-efficient post-training для снижения стоимости и ускорения итераций на больших base models.

Для research teams это значит возможность быстро тестировать новые RL algorithms без написания distributed systems boilerplate. Extension points позволяют заменить reward function, добавить auxiliary loss, изменить sample filtering или instrument new diagnostics через Python modules — не переписывая trainer, не forking фреймворк, не learning новую абстракцию.

Для infrastructure teams Miles даёт production-ready системы features из коробки: fault tolerance для week-long runs, observability через Ray dashboard и PyTorch profiler, parallelism-aware checkpointing для изменения cluster topology без re-conversion, fast weight synchronization через NCCL/RDMA для минимизации overhead между фазами.

Для product teams, работающих с specific domains — code generation, agentic tasks, rule-based reward scenarios — plug-in architecture позволяет адаптировать систему под domain-specific constraints. Можно добавить custom rollout logic для multi-turn conversations, domain-specific reward functions для code correctness или task completion, specialized sample filters для quality control.

Fault tolerance и observability встроены с самого начала. Ray job и actor model предоставляют supervision, log aggregation, dashboard visibility, а rank-level fault tolerance позволяет week-long training runs продолжаться даже при сбоях. PyTorch profiler integration покрывает training-level view для performance debugging. Когда что-то идёт не так — rollout latency spike, training compute bottleneck, collective communication slowdown — profiler показывает где именно проблема, а Ray dashboard показывает какой actor или rank вызывает issue.

Почему это важно сейчас

LLM post-training движется быстро — больше модели, длиннее контексты, больше MoE, больше асинхронных и agentic RL pipelines. Miles построен для этой траектории: композируя SGLang, Ray, Megatron-LM и PyTorch за маленьким pluggable trainer, он даёт PyTorch-native путь от algorithm experimentation до large-scale RL runs.

Open source релиз Miles делает frontier-scale LLM RL post-training более воспроизводимым, расширяемым и оперируемым. Команды могут начинать с существующих recipes, заменять reward, добавлять auxiliary losses, менять sample filtering или instrument new diagnostics без переписывания trainer.

Miles не пытается изобрести все компоненты заново. Вместо этого он композирует лучшие существующие инструменты в единую систему с правильными абстракциями на границах. Это pragmatic approach, который позволяет командам фокусироваться на algorithm и product logic, а не на systems-level decisions — placement, weight sync, fault tolerance, low-precision recipes.

Часто задаваемые вопросы

Чем Miles отличается от других RL фреймворков для LLM?

Miles не reinvent wheel, а композирует лучшие существующие инструменты: SGLang для rollout, Megatron-LM для training, Ray для оркестрации, PyTorch как общий слой. Философия small core с extension points позволяет адаптировать систему под новые алгоритмы без форка, а не предлагает monolithic framework с ограниченной кастомизацией.

Поддерживает ли Miles асинхронное обучение?

Да, Miles поддерживает fully asynchronous mode, где rollout actors непрерывно стримят сэмплы в очередь, которую trainer draining в собственном темпе. Это устраняет per-iteration blocking между фазами rollout и training, что критично для high-throughput scenarios.

Как Miles работает с MoE-моделями?

Miles реализует MoE-aware rollout/training alignment через Rollout Routing Replay — механизм, который сохраняет routing decisions через границу rollout/training. Это уменьшает routing mismatch, который иначе дестабилизировал бы MoE RL, когда эксперты работают по-разному в rollout и training фазах.

Какие модели поддерживаются из коробки?

Miles поставляется с готовыми recipes для DeepSeek-V4, Kimi K2.5/K2.6, GLM-5/5.1, Qwen3.5/3.6, с поддержкой NVIDIA Hopper и Blackwell GPUs. Model specs механизм позволяет добавлять новые архитектуры через plug-in components без long-lived forks.

Итог

Miles от RadixArk решает реальную проблему: RL post-training LLM вырос из простой training loop в complex distributed systems challenge. Фреймворк композирует SGLang, Megatron-LM, Ray и PyTorch в единую систему с поддержкой асинхронности, fast weight sync, MoE alignment и low-precision recipes, делая frontier-scale LLM RL более воспроизводимым и масштабируемым.

Если вы работаете с large-scale RL post-training и устали от системных проблем — попробуйте Miles. Open source, PyTorch-native, с готовыми recipes для frontier моделей. Код доступен на GitHub, документация описывает architecture и extension points.