No. Miles targets enterprise-grade, large-scale LLM/VLM post-training, while your workload does not need its distributed rollout-and-training loop.

• The About section positions the project as “enterprise-ready” for “large-scale model post-training,” centered on SGLang rollout and Megatron-LM training.
• Although Miles provides PyTorch FSDP2, SFT, and a path to train Hugging Face implementations as-is, FSDP2 is still a backend within a large training framework rather than a lightweight single-GPU SFT tool.
• Agentic rollout, P2P RDMA, asynchronous scheduling, and fault tolerance address multi-worker, cluster-communication, and long-running RL problems; they offer little corresponding value for ordinary single-GPU SFT.
• The README explicitly says that the largest models, main recipes, and parallelism live on Megatron-LM.

Adopting Miles would therefore likely add installation, dependency, and debugging overhead instead of shortening your SFT workflow.

Yes. The README directly lists multi-turn agentic rollout, environment connectors, and task sandboxes as supported capabilities.

• What Miles runs says coding and computer-use agents can be trained through Harbor, HUD, NeMo Gym, OpenEnv, and Verifiers connectors.
• The same section lists AgentENV, Daytona, E2B, and Modal as task sandboxes, indicating an integration path between environment execution and rollout.
• Performance says the router behind SGLang distributes requests, preserves per-request metadata, and health-checks the engine fleet, with tuning for multi-turn agentic workloads.
• Correctness and resilience states that TITO is supported for “every model and every black-box harness,” reducing detokenize/retokenize issues between rollout and training.

Miles provides the training-loop and environment-integration infrastructure, not the quality of your reward function, tools, or task definitions. The README does not describe the maturity or feature differences of each connector.

Yes. Miles’ TITO and R3 directly target token consistency and MoE routing consistency, respectively.

• The Correctness and resilience section says TITO preserves token-level data between rollout and training, avoiding the detokenize/retokenize round trip, and claims support for every model and every black-box harness.
• The same section says R3 records expert routing during rollout and replays it in the trainer’s forward pass to remove MoE routing mismatch.
• The README also says R3 overlaps computation and communication to reduce the added cost of consistency handling.
• These capabilities are aligned with the Megatron-LM training path and large-scale MoE RL correctness requirements.

However, “supported” does not guarantee seamless behavior with a custom tokenizer, special stop conditions, or a custom harness. The README does not list covered MoE architectures or provide a TITO validation example for your multi-turn message format.

Yes. Miles is specifically designed for large-scale, disaggregated RL post-training.

• The About section pairs SGLang for high-throughput rollout with Megatron-LM for scalable training and states that rollout and training workers can be decoupled.
• The Performance section says new weights can reach inference engines in-loop and identifies P2P RDMA as the fast path for disaggregated deployments. It also cites Kimi-K2.6 as a trillion-parameter example.
• Fully async RL provides configurable on-policy and off-policy scheduling, which can reduce pipeline bubbles caused by rollout and training waiting on each other.

Whether it reaches the desired throughput still depends on GPU topology, RDMA networking, containers, drivers, and parallelism settings. The README does not provide end-to-end measurements for your exact cluster size.

Yes, at least for the SGLang engine-failure scenario described in the README, Miles provides in-place recovery instead of restarting the entire run.

• The Correctness and resilience section explicitly says that when an SGLang engine dies, Miles recovers it and resumes the run in place, with “no restart, no pause.”
• The Performance section says rollout requests pass through a router that health-checks the engine fleet, providing architectural support for detecting unhealthy instances.
• NVIDIA H200 is listed as supported hardware, and Fully async RL decouples rollout, training, and evaluation workers for long-running distributed pipelines.
• This capability targets inference-engine failures; it does not imply automatic recovery from training-worker, RDMA-network, GPU, or sandbox failures.

Miles is therefore closely aligned with your failure constraint. The README does not specify recovery time, recoverable failure classes, state persistence, or behavior when multiple engines fail simultaneously.

It depends. Miles offers an FSDP2 path, but the README explicitly places its largest models, main recipes, and parallelism capabilities on the Megatron-LM path.

• The About section says FSDP2 is available for runs that want to “train the HuggingFace implementation as-is,” reducing the need to rewrite the model.
• The same section states that the recipes, parallelism, and largest models live on Megatron-LM; FSDP2 should not be treated as a fully equivalent backend.
• What Miles runs lists GRPO, GSPO, PPO, REINFORCE++, SFT, and on-policy distillation, but does not map each capability to FSDP2 support.

FSDP2 is reasonable if the model size is moderate and the target recipes are covered by that path. For the largest models or Megatron-specific parallelism, it is not the safe default. The README lacks a detailed recipe-by-backend compatibility matrix.

It depends. The README explicitly demonstrates AMD MI355X and DeepSeek-V4 support, but it does not establish equal stability for every low-precision combination on AMD.

• The News section records “DeepSeek-V4 Flash RL training” on AMD Instinct MI355X with Miles, which is directly relevant evidence for the hardware and model.
• What Miles runs lists AMD MI300X, MI325, MI350, and MI355X through ROCm.
• Performance lists MXFP8, NVFP4, FP8, INT4 QAT, BF16, and FP16. However, NVFP4 is presented in a broader Blackwell/NVIDIA context elsewhere, so full MI355X support cannot be inferred.
• The project has only one formal release, v0.1.0, so stability across specific hardware, ROCm, kernels, and precision combinations remains uncertain.

There is clear evidence for AMD MI355X plus DeepSeek-V4. If MXFP8 or NVFP4 is mandatory, the README is insufficient for a procurement or production decision.