Skip to main content

Sparkrun Clusters

A Sparkrun cluster is one or more NVIDIA DGX Spark devices that Cordatus can place a multi-node inference workload on. LLM Launcher → Sparkrun Clusters is where you define them, run the preflight checks, and see what each one is currently carrying.

Building the cluster, then launching on it: the recipe, the nodes, the logs, and chatting with the endpoint

 


The cluster list

ColumnMeaning
NameThe cluster name, with its description underneath.
NodesOne badge per member. The head badge is node_0 — it serves the API and holds the cluster definition; the rest are worker nodes, and their order is the node order.
Readinesssingle node, or SSH / CX7 with a pending state when they are not configured yet.
Head stateWhether the head device is reachable.
Workloads{n} live / {n} total. Click to expand.
CreatedWhen the cluster was defined.

Expanding a row lists Workloads on this cluster: recipe name, TP=, status, model, endpoint, serving node and launch time, with Open taking you to that workload's parameters on the Containers page.

An endpoint marked (assumed) means the port fell back to the engine default and was never actually reported by the device.

Row actions:

  • Preflight — re-run the SSH mesh, CX7 interconnect and runtime checks.
  • Edit — rename or re-describe. Membership is deliberately not editable here: the member order is the node ordering, so changing it belongs in the wizard where the head is picked and the preflight is re-run.
  • Delete — removes the cluster from Cordatus and from sparkrun on the head device.
note

Renaming in Cordatus does not rename sparkrun's own cluster — sparkrun keeps its own under the old name.


Creating a cluster

New Cluster opens the wizard. It has three steps; from this page it stops after two, because no recipe is being launched.

Step 1 — Cluster

Your DGX Spark devices are listed. Drag them onto two slots:

  • Head node — exactly one. It serves the API and holds the cluster definition.
  • Workers — any number, and their order is the node order.

A head on its own is a valid single-node cluster.

Also on this step: Cluster Name (which names the YAML file written on the head node and the workload row) and an optional Description.

Things the step will not let you past:

  • "Drag at least one device onto the Head slot."
  • "{n} selected device(s) are offline. They must connect before continuing."
note

A single-node cluster has no SSH mesh to build and no CX7 interconnect to configure. Only the runtime check applies, and only single-node recipes are offered in step 3.

Step 2 — Preflight

Three checks, each with its own card:

CheckWhat it is
SSH meshPasswordless SSH between every node. Cordatus reads each node's SSH account, then configures the mesh. Passwords are used for this setup only and are never saved.
CX7 networkingThe high-speed interconnect used for tensor parallelism. Required for multi-node recipes.
sparkrun runtimeThe sparkrun CLI and its container images on the head node. Install now installs them.

What a failed check means is spelled out on the page:

  • SSH down → the launch is blocked entirely, and the failing pair is named on the SSH card.
  • CX7 down → multi-node recipes are unavailable while the link is down. Single-node recipes still launch normally.

Checks that already passed stay done — nothing is repeated needlessly. Re-check and Reconfigure are available per card.

If the nodes do not share a login account, Cordatus passes each host to sparkrun with its own account rather than guessing.

Step 3 — Recipe & nodes

Only when you are launching, not when you are only defining a cluster. See below.


Launching a workload

Start from an engine application's Start Sparkrun button (see the Launch Guide). The wizard then adds its third step.

  • Choose what to run — the recipe catalogue read from the head node, filterable by model, runtime or name, with Only what fits on by default so you are not offered recipes this cluster cannot hold. Show all anyway overrides it.
  • Update catalog pulls the recipe registries on the head node again.
  • Paste YAML takes a sparkrun recipe you already have. It is validated against recipe_version 2 before anything is written to the head node.
  • Nodes for this run — which of the cluster's nodes this workload occupies. A recipe that needs fewer nodes than the cluster has says so: "{n} node(s) of this cluster will sit idle for this workload." A recipe that does not declare how many nodes it needs leaves the choice to you.
  • Launch options — a Hugging Face token (from your vault or pasted, or No token — pull anonymously) and a Recipe name, which names the YAML file on the head node and the workload row.

Launch on Sparkrun starts it. The wizard then shows live progress with a Full log, the endpoint the API will answer on, and Copy endpoint / Open API once it is up.

If it fails, the workload row is kept so it stays listed under Sparkrun Workloads whether you retry from here or not.


Managing workloads

Running workloads live on the Sparkrun Workloads tab of the Containers page, and under their cluster on this page. From there you can start, stop, cancel a launch, delete (typing DELETE), and open the details panel with Overview, Logs (one reader per node, each line tagged with the node it came from), Ports, Access URLs, Engine Arguments, Environment Variables (values masked) and the Recipe YAML.


Permissions

Reading and writing clusters are separate permissions. Without write access the New Cluster, Edit and Delete actions are hidden; without read access the page reports that rather than showing an empty list.