Interconnect and download speed on GET /executors

A multi-GPU job runs at the speed of the link between the GPUs and at the speed the node can pull your data. Before you rent 8 GPUs explains how to check both by hand once the pod is up. This page is the API side: the listing now carries the answer, and you can filter on it before you rent.

Two new fields on every node

Every node in GET /executors, and the executor object of a pod on GET /pods, has:

Field	Type	Meaning
nvlink	true, false or null	true when every GPU pair on the node is joined by NVLink. false when at least one pair is not. null when no validator has reported the topology yet, or the node has one GPU.
interconnect	object or null	How the GPUs are wired, from the validator's nvidia-smi topo run. null until a scrape has reported it.

interconnect has these keys, each null when the validator could not read it:

Key	Meaning
gpu_count, gpu_pairs	GPUs on the host and the number of GPU pairs judged.
nvlink	Same verdict as the top-level field: every pair on NVLink.
nvlink_links, nvlink_pairs, nvlink_active_links	NVLink links per GPU, the pairs joined by NVLink, and the links that are up. A board with NVLink bridges on some pairs only reports nvlink: false with nvlink_pairs below gpu_pairs.
pcie_class	The worst PCIe class among the pairs that are not on NVLink: SYS, NODE, PHB, PXB or PIX, from worst to best.
p2p, p2p_pairs, p2p_ok_pairs	p2p is true only when every pair passed nvidia-smi topo -p2p r. A false here is the host where NCCL does not start without NCCL_P2P_DISABLE=1.
matrix	The GPU x GPU cell table from nvidia-smi topo -m, so a client can print the topology.

The wiring of a host does not change between scrapes, so a scrape that fails to read the topology keeps the last known interconnect instead of turning the node back to null.

nvlink and interconnect.nvlink always carry the same value. Only a JSON boolean counts as a verdict when the API reads a stored row: a persisted string "true" reads as null in both places, and the nvlink=true filter leaves that node out. If one key of interconnect arrives in a shape the API cannot type, that key alone is null and the other keys stay. interconnect itself is null only when the host has no object at all.

A specs.network figure that is not a number is treated as missing, both by the min_download_mbps filter and by effective_download_speed_mbps. One such node does not fail the listing for everyone.

The public nodes feed carries the nvlink verdict too. The full interconnect object stays on GET /executors. The smaller listing, GET /executors?view=summary, carries nvlink and every interconnect key except matrix; read the full view or the pod's executor object for the cell table.

Two new filters

Query parameter	Effect
nvlink=true	Only nodes whose nvlink is true. A node with no topology verdict yet is left out on purpose: an unknown box is not NVLink for a renter who asked for it. false or omitted means no filter.
min_download_mbps=2000	Only nodes whose most trusted download figure, in Mbps, is at least the value. The figure is the VerifyX average first, then the speed-test average, then the raw samples; zero counts as missing. A node with no measurement is left out.

curl -s "https://lium.io/api/executors?nvlink=true&min_download_mbps=2000" \
  | jq '.[] | {id, nvlink, p2p: .interconnect.p2p, nvlink_active_links: .interconnect.nvlink_active_links}'

The response is the usual list of nodes; the two filters combine with the existing ones (machine_names, price_lte, gpu_count_gte and the rest). GET /pods takes the same two parameters and applies them to the node each pod runs on. In the lium SDK, Lium.rent(min_download_mbps=...) applies the download floor (lium 0.0.39 and later, through rent-by-spec). Lium.rent(interconnect="nvlink") is refused on lium.io, because rent-by-spec has no interconnect constraint: list with nvlink=true on this API and rent the node you picked with Lium.up(). lium ls shows the Link column and takes --nvlink since lium v0.4.0.