Spindle Brings Tinker-Compatible LLM Training to Modal GPUs

Spindle gives teams a way to keep Tinker’s Python-based training workflow while controlling the training server and paying for GPU time. Modal released the open-source, Tinker-compatible service for teams whose experiments are growing costly under per-token pricing or whose work depends on models and features a closed API doesn’t support.

Deployment starts with one command:

spindle deploy

Teams then point their training script at the deployed server. Spindle runs the distributed work underneath, while the team supplies its own training loop, losses, rewards and environments. It supports full-parameter training and multi-LoRA across a range of open models.

Choosing a level of control

Modal presents Spindle as one option in a broader post-training stack. Teams that want a prepared training workflow can use Modal Dojo, which takes a model and dataset and handles the rest. Those who want to manage infrastructure directly can use on-demand multi-node clusters and sandboxes for RL rollouts. Spindle occupies the middle ground: teams write the experiment logic, while the service manages distributed training.

For teams running many experiments, Modal says Spindle can support hundreds of concurrent runs with similar performance and lower costs than closed-source APIs. That claim depends on keeping shared GPUs productive; the reported workload results later in the article show how concurrency affects both cost and per-run speed.

How the service is built

A distributed control plane manages requests and sessions, while containers scale through Modal Functions. Spindle separates trainer engines from inference pools, so the two can run on different accelerators and at different numerical precisions. Modal describes mixed-precision, mixed-accelerator setups as a way to improve accelerator availability and reduce cost, while pointing to its discussion of keeping RL stable across these configurations.

The infrastructure also uses Modal Clusters to schedule large-model requests on dynamically available, RDMA-connected nodes without a cluster reservation; Modal Volumes for durable checkpointing; and Modal Servers for inference. While developing multi-LoRA training, the team contributed improvements to Miles and SGLang.

Multi-tenant training required work on batch scheduling across clients, asynchronous checkpointing, delta weight synchronization and an inference router that accounts for both LoRA adapters and KV state. The design document describes these components. An architecture video is included below.

Reproducing a search-agent run

Modal reports testing Spindle on reinforcement-learning workloads spanning math reasoning, agentic coding and search. One example reproduces Jasper Lu’s Training Search Agents with GRPO, which trains gpt-oss-20b to search a corpus of SEC filings over multiple turns. The agent uses keyword matching, grep and read tools to gather documents that answer a query.

The team took Lu’s open-source code, changed the BASE_URL and API_KEY to target Spindle, then ran it. Across 24 updates, two Spindle seeds tracked a Modal rerun on Tinker and Lu’s published results to within 0.01 reward at every update. Evaluations at updates 16, 20 and 24 also showed similar results on 32 held-out queries.

Customizing context length

Because teams control the server configuration, they can adjust settings for workloads that a hosted service may not cover. For a Qwen3.5-9B run on long-horizon software tasks, the available default supported a 16K context. Modal says two configuration changes raised the limit to 256K and increased context parallelism from one to four:

class Config(Qwen35_9B_16k):
    ...
    max_context_length = "256k"     # was "16k"
    context_parallel_size = 4       # was 1

The run lasted about three days on preemptible GPUs and resumed automatically from checkpoints when machines were reclaimed. Eight clients shared the GPUs through multi-LoRA, allowing eight long-context ablations to run for the cost and time of one, according to Modal.

Shared GPUs trade speed for cost

Agentic RL can leave trainer GPUs idle while a client waits for long, multi-turn rollouts. Modal says a trainer serving one client may be busy for less than half the time, depending on the workload. Multi-LoRA lets several clients share that trainer: while one waits for inference, another can use the training capacity. The tradeoff is that each run may take longer as clients compete for the shared resources.

In a GRPO test using a 27B model on DAPO-math, Modal compared one to eight clients sharing training and inference GPUs. The setup used four H200s for training and 12 B200s for inference. Trainer utilization rose from 37.0% with one client to 70.0% with two and 87.7% with four. Beyond four clients in this setup, the team observed thrashing that significantly reduced per-client throughput.

Across three workloads, Modal reports these costs per million output tokens:

These figures are workload-specific, and the utilization results show why they shouldn’t be treated as fixed savings: costs improve when shared GPUs stay busy, while excessive concurrency can slow each run. Spindle is open source and remains in beta. Teams can follow the setup instructions, report bugs or request support for models and features through GitHub issues, and contribute configuration or performance changes. Modal says it plans further work on performance, autoscaling, features and training recipes.