Skip to content
AI Primer
release

Modal releases open-source Spindle with reported 20–80% lower training costs

Modal released Spindle, which runs unchanged Tinker scripts in a Modal workspace with GPU-time billing. Modal reports 20–80% lower per-token costs when training runs share GPUs.

5 min read
Modal releases open-source Spindle with reported 20–80% lower training costs
Modal releases open-source Spindle with reported 20–80% lower training costs

TL;DR

  • Spindle runs existing Tinker-compatible scripts in a Modal workspace with GPU-time billing, according to Modal's announcement.
  • Shared training runs cost 20–80% less per million output tokens in Modal's comparisons across math, search-agent, and 256K-context coding workloads.
  • Multi-LoRA fills gaps between long rollouts by interleaving clients' training requests, as Modal explains.
  • Modal also shipped a higher-level training library, Dojo, with recipes and observability, described in its separate announcement.

The setup guide warns that first requests can incur GPU cold starts and model compilation. Underneath the API, the repository exposes familiar forward_backward and optim_step calls, then publishes updated weights to autoscaling sampling replicas.

Tinker compatibility

Existing Tinker-compatible scripts move with a refreshingly small change: a new base URL and API key, according to Modal's setup guide. The training loop, including its losses, rewards, and environments, stays with the client; Spindle handles distributed execution.

After installation and creation of the API-key and proxy-token secrets, deployment uses:

Clients connect through TINKER_BASE_URL and TINKER_API_KEY. The server runs inside the team's Modal workspace and remains in beta, according to the launch post.

The repository distinguishes two training paths:

  • Multi-tenant LoRA: adapters share a base model while keeping separate gradients and optimizer state; existing Tinker SDK clients work directly.
  • Single-tenant full-parameter training: each run receives dedicated training containers, with Spindle helpers extending the Tinker interface.

Cost per million output tokens

Modal's benchmark table compares the same scripts on Spindle and Tinker. These are normalized experiment costs per million output tokens; Spindle's billing unit is GPU time.

| Workload | Tinker | Spindle | Shared clients | Spindle trainer / inference GPUs | Reported saving |
| --- | ---: | ---: | ---: | --- | ---: |
| DAPO-math, Qwen3.8-27B | $9.77 | $1.99 | 8 | 8 H200 / 8 H200 | 80% |
| Search agent, gpt-oss-20b, up to 40 turns | $5.06 | $4.06 | 4 | 8 H200 / 16 H200 | 20% |
| Same search-agent workload | $5.06 | $3.80 | 8 | 8 H200 / 16 H200 | 25% |
| SWE-Gym, Qwen3.8-27B, 256K context | $15.04 | $5.82 | 8 | 8 B200 / 12 B200 | 61% |

The configurations differ across workloads, and the headline savings come from multiple clients sharing compute. Modal also reports a four-client SWE-Gym configuration at $6.17 per million output tokens, using eight B200s each for training and inference, a 59% reduction.

Multi-LoRA scheduling

Long-horizon agentic RL leaves trainers waiting while models generate responses and tools execute. Spindle interleaves another client's training step during those gaps.

In the utilization experiment, Modal ran a 27B-model GRPO job on DAPO-math with four H200s for training and twelve B200s for inference:

  • One client: the trainer was busy less than half the time, a pattern Modal says it observed even with asynchronous RL.
  • Four clients: interleaving kept the trainer approximately 88% busy.
  • Beyond four clients: trainer thrashing significantly degraded per-client throughput in this configuration.

Sharing reduced each run's cost while making individual runs finish somewhat more slowly. The eight-client results in the cost table use other hardware configurations, so the four-client saturation point belongs to this particular experiment.

Trainer and inference pools

Spindle separates training engines from inference pools, allowing them to use different accelerators and precisions. The architecture description breaks the backend into several concrete components:

  • Control plane: request and session management, plus container autoscaling through Modal Functions.
  • Training clusters: dynamically available, RDMA-connected nodes through Modal Clusters, without a cluster reservation.
  • Checkpoint storage: durable checkpoints on Modal Volumes, with asynchronous checkpointing.
  • Inference layer: Modal Servers, delta weight synchronization, and a custom router aware of LoRA adapters and KV-cache state.

The separate pools also let a fixed trainer serve more inference compute for one run, more concurrent runs within a fixed inference budget, or a combination of both.

Search-agent reproduction

Modal tested compatibility by reproducing Jasper Lu's GRPO recipe for gpt-oss-20b, which learns to select SEC filings that answer a query. The agent has three tool types:

  • Keyword matching
  • grep
  • Document reading

The reproduction changed only BASE_URL and API_KEY in the original code. Modal compared two Spindle seeds against its own Tinker rerun and Lu's published results, reporting training reward within 0.01 across all updates.

It also evaluated checkpoints at updates 16, 20, and 24 against the same 32 held-out queries and reported similar parity.

256K-context runs

For a separate long-horizon software-task experiment, Modal extended a Qwen3.5-9B configuration from 16K to 256K context with two configuration changes:

That run lasted approximately three days on preemptible GPUs and automatically resumed from checkpoints when machines were reclaimed. Eight clients shared the GPUs through multi-LoRA.

This extensibility reaches below context length: the server is a Modal App, and its configuration exposes trainer allocation, backend parameters, inference replica counts, and SGLang settings.

Dojo recipes and observability

Spindle followed Modal Dojo, released October 21. Dojo supplies the training loop and recipes on top of open-source frameworks including Miles and Slime.

Its workflow has three inputs:

  1. Model: a supported model or a custom model.
  2. Dataset: Hugging Face data, a Harbor environment, or tasks derived from production harness traces.
  3. Recipe: hardware, parallelism, rollout size, environment, and reward-function settings.

The dashboard exposes loss and reward curves, individual rollout trajectories, substep profiling, framework metrics, and container logs. Its CLI makes run status, metadata, logs, and agent traces accessible to coding agents.

Modal described two customer workloads:

  • Axiom Bio: molecule identification from mass-spectrometry data, including 64K-context DeepSeek V4.1 Flash runs on 64 B300s, according to Modal's customer example.
  • AfterQuery: autoresearch on existing expert-curated datasets with Kimi and DeepSeek at 256K context, as described in Modal's follow-up.

Further reading

Discussion across the web

Where this story is being discussed, in original context.

On X· 3 threads
Trainer and inference pools1 post
256K-context runs1 post
Dojo recipes and observability3 posts
Share on X