Why Flyte 2?
AI/ML has moved beyond traditional orchestration
Orchestrators were built for linear data pipelines: extract, transform, load, repeat.
AI workloads don't look like that. They branch based on model output, retry against infrastructure that fails in AI-specific ways (OOM kills, preempted spot nodes, GPUs that vanish mid-run), and mix long training loops with realtime serving.
Flyte 2 AI runtime is built for that.
Flyte SDK downloads to date:
Durable Execution
Recover from infrastructure failures, not just code failures
Most orchestrators retry your function when it throws an exception. Flyte 2 goes further: it's infrastructure-aware, and it automatically recovers when the infrastructure underneath your task disappears, an OOM kill, a preempted spot node, a GPU that vanishes mid-run, without you writing any recovery logic yourself.
Retries with backoff, a per-attempt runtime cap, and an absolute deadline, composable on a single task. Infrastructure-triggered `retries` (node loss, preemption) don't consume your retries budget at all, the platform handles those separately.
Fail fast on the unfixable
Not every failure should be retried. Raise `NonRecoverableError` for a bad input or malformed config so the action fails immediately instead of burning through your retry budget on something retrying will never fix.
Every execution is reproducible
Executions are logged and versioned automatically. Trace exactly what ran, with what inputs, and see precisely when and how a self-healing recovery happened, right in the UI.
Authoring
Inference
Batch inference with max GPU utilization
When running batch inference, the single biggest cost driver is idle GPU time: cycles where the GPU sits waiting with nothing to do. Flyte 2 uses `DynamicBatcher` to maximize GPU utilization.
Real-time inference and model serving
Flyte 2 adds support for real-time inference for single node models.
Sandboxes
Safely execute LLM-generated code
Flyte 2 ships with a built-in sandbox that lets LLMs generate Python orchestration code and execute it safely. Two complementary modes:
- Sandboxed orchestration, built on Monty, a Rust-based sandboxed Python interpreter. Starts in microseconds, runs pure Python control flow, and dispatches heavy work to full container tasks through the Flyte controller.
- Code sandboxing: a stateless sandbox that runs arbitrary Python scripts or shell commands inside an ephemeral, disposable container, for when you need full Python capabilities beyond pure control flow.
Programmatic tool calling for agents
Instead of a model making one tool call at a time, with every intermediate result passing back through its context window, the model writes a single block of code that calls multiple tools, transforms data, and applies logic, all inside the sandbox. Only the final result returns to the model.
For production workloads, wrap tools as `@env.task` so the sandbox dispatches them as durable Flyte tasks, the same retry and recovery behavior from above applies to every tool call.
Compute Management
Autoscale long-running apps
Model endpoints, agent services, and other long-running apps scale replicas up and down automatically to match load.
Spot instances, with automatic fallback
Schedule interruptible workloads on spot or preemptible instances to cut compute costs. When a spot instance is reclaimed, Flyte 2 falls back to on-demand on the final attempt, the same recovery mechanism covered in Durable by default handles the interruption automatically.

