Skip to content

Planning a run

Before a training run starts or a model loads, the leader plans where it goes: which PC runs which layers, on which cards, and what each card then holds. The placement planner shows that plan card by card, lets you try changes, and makes sure that what starts is what you saw.

It opens in two places:

  • Training: in the New training run dialog, under Show the plan.
  • Inference: the Plan button next to Load.

The page never plans on its own. Every change asks the leader's planner again, the same code that places the run, so the view and the result cannot disagree.

What it shows

One bar per card, grouped by PC in pipeline order. A bar is the card's whole memory:

Segment What it is
Other programs (striped) memory already in use on the card, by SilentSwarm or anything else
Weights the layers the card runs
Embeddings, head, buffers the input embeddings on the first card, the output head on the last, and a 4-bit model's dequantization buffer
KV cache serving: the cache for the context window, at the token budget of its stage
Activations, Optimizer, LoRA training: what a step keeps on the card
Workspace room kept free for attention and the CUDA context
Free what is left
Does not fit (red) how far the plan runs past the card's end

Above the bars:

  • The line that limits the plan, e.g. Context 65,536 tokens; the cards hold 89,088, limited by fxserver's GTX 1050 Ti #0. Screen readers hear the same sentence as the chart's label.
  • The layer strip: each stage's layers and the PC that runs them.

Below them, the same rows as a table, with each card's layers, what the plan puts on it, and the reason a card is left out:

  • 23.4 GB held by /app/llama-server (not SilentSwarm): another program uses the card;
  • 1.0 GB free, below the 4.0 GB floor: too little room for anything;
  • fellow not connected, fellow training, less than the 6.5 GB a stage needs free;
  • left out by you;
  • not needed: the plan fits without it.

Trying changes

  • Use (in the table): untick a card to plan without it, tick it to bring it back.
  • Serving: the context window, the number of stages, and how the KV cache is stored (see Context window).
  • Training: sequence length, steps and every other field of the dialog.
  • Maximize context (serving): the leader searches for the largest window the cards hold, and plans it.
  • Fastest that fits (serving): the placement measured card speed favours, instead of the cut the model was trained with.
  • Maximize sequence length (training): the longest sequence length that places and fits now; the dialog takes it over.

What starts is what was shown

Every plan has a plan_id. Load this plan and Start training send it along:

  • Loads go exactly where the plan said. If the cluster changed in between, for example a card filled up or a fellow went away, the load is refused with what changed (409 plan-changed), and the planner shows the new plan.
  • Training jobs keep their placement. A job submitted with a plan that no longer holds is refused at once. A job that waits for its fellows and then finds the placement changed stays pending with the reason, the cluster changed since the plan was shown: ..., instead of starting somewhere else. Cancel it and plan again, or submit without the plan to let the leader place it.

Change a field after the plan was shown and the dialog submits without the pin: the leader then plans the run itself, as before.

From the CLI and over MCP

swarm model-load MODEL --plan                      # the summary and its plan_id
swarm model-load MODEL --plan --maximize context   # the largest window, planned
swarm model-load MODEL --plan-id 3f9c2a1b0d4e5f67  # load exactly that plan
swarm train --config job.json --plan --maximize-seq-len
swarm train --config job.json --plan-id <id>

Over MCP, models_plan and jobs_plan answer with the same data: cards (every card, used or left out with the reason), layout.limit, a summary paragraph for the agent to show, and plan_id. models_plan takes maximize (context, speed) and exclude_cards ("fellow_id:gpu_index"); models_load takes plan_id. For training, exclude_cards, maximize: "seq_len" and plan_id go in the job config.

The plan's numbers are the leader's estimates from what the fellows report: free memory per card, measured speed where a card was benchmarked. The stages check them again when they load and refuse what does not fit.