Miles starts where an 8-GPU training job becomes an operations problem
Miles coordinates the two halves of reinforcement-learning post-training. SGLang generates candidate answers, a reward function scores them, and either Megatron-LM or PyTorch FSDP2 updates the model. The supplied recipes cover GRPO, GSPO, PPO, REINFORCE++, supervised fine-tuning, and on-policy distillation. This is infrastructure for teams changing model weights, not an API wrapper for people who only want to call a model.
The codebase matches that scope. Our checkout contained 2,043 files and about 275,700 lines of source in 23.4 MB. Miles also routes requests across generation engines, moves updated weights back into them, saves distributed checkpoints, and can recover a failed SGLang engine during a run. Those pieces are valuable when the alternative is maintaining several internal services, but they give a new operator many failure boundaries to understand.
The official first run needs 8 GPUs and 500 GB free disk
The quick start assumes one node with 8 H100, H200, or B-series GPUs, Docker GPU access, and at least 500 GB of free disk. It downloads a Qwen model plus training and evaluation data, converts Hugging Face weights into Megatron's sharded format, then starts a local Ray cluster. Keeping the original model directory is required because SGLang still reads its tokenizer and configuration.
That workflow is far removed from the 35-package environment that occupied 37 MB in our basic install. The recommended NVIDIA container uses host networking, 32 GB of shared memory, exposed GPUs, and raised memory-lock and stack limits. Its AMD counterpart mounts GPU devices, adds the video group, relaxes seccomp, and runs privileged. Security teams should review those flags before the image reaches a shared cluster.
The project warns that source installations often go wrong when SGLang or Megatron-LM is installed at the wrong patched commit. Docker is the documented answer. Multi-node training then adds a fast interconnect such as InfiniBand, RoCEv2, or Slingshot. This is reasonable for its intended scale, yet it means that a successful Python installation says almost nothing about whether a real job is ready.
What happened when we ran it
Our sandbox installed Miles in 33 seconds, added 35 packages, and used 37 MB on disk. The build succeeded in 18 seconds. Pip-audit reported 0 known vulnerabilities in that installed set. These are encouraging repository checks, though they did not exercise a GPU, pull a model, start Ray, or run a reinforcement-learning workload.
The test command failed with exit code 4 after 9 seconds. Pytest stopped while loading tests/conftest.py: the import chain reached miles/rollout/data_source.py, which imports torch, and Python raised ModuleNotFoundError: No module named 'torch'. The log establishes the missing module and nothing more, so we cannot say whether the intended test procedure needed another dependency group or a different image.
The repository has a tests directory and 20 CI workflow files, despite our local suite never reaching collection. It has no Dockerfile at the repository root, although the current tree contains Docker material under docker/ and the project publishes recommended images. The practical release gate is straightforward: run the full test command inside the exact GPU image and patched dependency set intended for training.
Megatron carries the scale while FSDP keeps Hugging Face models familiar
Megatron is the default and the only backend that splits a model with tensor, pipeline, context, expert, and expert-tensor parallelism. It also supports LoRA and disk-backed optimizer handling. The price is an offline conversion from Hugging Face weights into torch_dist checkpoints plus architecture flags and model-specific recipes. Teams spanning racks will probably accept that bill because those controls are why they are considering Miles.
FSDP2 trains the Hugging Face implementation directly and avoids the conversion step, but the documented limits matter. There is no LoRA, tensor parallelism, pipeline parallelism, context parallelism, or expert parallelism. The 23.4 MB checkout therefore contains two paths with different checkpoint formats and capabilities, not interchangeable switches for the same run. Choose the backend before building automation around checkpoints or model adaptation.
Colocation adds another meaningful choice. It lets training and rollout share the same GPUs by moving each side out of memory while the other works. Fully asynchronous rollout cannot use that layout because generation and training need separate GPUs at the same time. Disaggregated runs also need a weight-transfer method, with network broadcast, point-to-point RDMA, and disk deltas documented for different cluster designs.
A first tagged release is moving fast enough to demand pinning
GitHub recorded a push on September 4, 2026, and the first versioned release, v0.1.0, arrived on August 18. The repository had 2,481 stars and 953 combined issues and pull requests when fetched. A separate search found 125 open issues, including current design discussions and a detailed report about the OPD top-k reward path. That is active maintenance, not a quiet queue.
Rapid work is visible in the 20 CI workflows and the long stream of refactoring pull requests. It also raises upgrade risk for clusters built around patched SGLang, Megatron-LM, CUDA kernels, and model recipes. Pin the Miles commit, container digest, model files, dataset revision, and backend configuration for any run that must be reproduced. A moving latest image is a poor record of an expensive experiment.
Miles makes sense when distributed model training is already your day job. Its documentation is unusually candid about hardware, checkpoint conversion, parallelism limits, memory movement, and networking. The failed source-suite startup keeps us from granting the light install much weight, while the 8-GPU quick start rules out casual evaluation. Treat it as cluster software, test the chosen image end to end, and use a smaller trainer when the model fits on ordinary hardware.