Node Matching

How Meshive picks the host machine that runs your pod, and how a GPU host serves both GPU and CPU pods without starving either.

When you create a pod, Meshive does not just pick “any available host.” A scoring engine ranks every eligible machine and matches the best one to your request. This page explains how that score is built — and how a single GPU host can serve both GPU and CPU pod requests without one starving the other.

What “eligible” means

A host is eligible for your pod when it has:

The GPU model and count you requested (for GPU pods) — and, if you selected one, the GPU memory (VRAM): cards of the same model can carry different memory at different prices, and a pod that requests a capacity is only placed on a card with exactly that memory.
For CPU pods, the CPU option you picked — its CPU vendor, product line and generation, and its memory (DDR) generation. Each option has its own rates, so a CPU pod is only placed on a host that matches it. In the SDK and CLI this is the CPU line (cpu_line, --cpu-line); without one, the cheapest line that fits is used.
Enough free CPU, RAM, and storage for your spec.
A healthy state — recent heartbeat, no maintenance window in progress, ports reachable.
Passed the onboarding stress test, so its performance has been verified by the platform.

Among eligible hosts, a single combined score picks the winner.

How the score is built

Every eligible host gets one score that blends the factors below. They are weighted, not applied one after another — a small edge in one factor can be outweighed by a bigger difference in another. The weights are tuned and may change.

Binpack — highest weight. The scheduler prefers a host whose remaining capacity exactly fits your request. The simplest example: a 1-GPU pod request goes to a 1-GPU server before it goes to a 2-GPU server. This keeps larger machines free for the jobs that actually need them, and it minimizes wasted resource holes across the fleet.
Uptime rate Hosts with a higher lifetime uptime rate are preferred. This naturally biases pods toward more reliable machines and is reinforced by the Uptime & Fees tier system.
Network speed The score uses the host’s measured upload and download bandwidth — not latency or ping. Higher sustained throughput wins. The host measures it when the machine starts, once a week, and whenever its network card renegotiates a different link speed. It first downloads from and uploads to Meshive’s speed test endpoint at the nearest Cloudflare edge, so a host anywhere in the world is measured against a server close to it. If that doesn’t come close to the network card’s link speed, it also downloads a large public image layer from Docker Hub — where pod images come from — and a test file from Meshive storage, and uploads test data to Meshive storage. It keeps the fastest result in each direction, and each test runs over several connections at once.
Current GPU driver When the platform rolls out a new GPU driver version, hosts already running it are preferred, so machines on older drivers free up naturally for their upgrade.
Disk speed — smallest weight, a tie-breaker. The score uses the measured speed of the host’s local disk — where local volumes, the container image and the pod’s system disk live — as the average of sequential read and write. Network volumes don’t count; they live on separate storage machines. If a host spreads this storage over several disks, the slowest one counts. It is the Disk speed shown for your pod in the console. Its weight is small, so it mostly settles the order between hosts that are otherwise close. A host whose disk hasn’t been measured yet scores lowest on this factor.
Memory (DDR) generation — a tie-breaker, same small weight as disk speed. DDR5 hosts score higher than DDR4 hosts. A host whose memory generation hasn’t been read sits in between.
CPU generation — a tie-breaker, same small weight. Each CPU is scored by how many generations it trails the newest one released in its own family (EPYC, Xeon, Ryzen, Threadripper, Core), so a current-generation CPU of any family scores the same, and falling one generation behind costs the same in every family. A CPU whose generation couldn’t be read sits in the middle.

Disk speed, memory generation and CPU generation each carry a small weight, so together they mostly settle the order between hosts that are otherwise close. A CPU pod still runs only on the CPU type and memory generation it was created with — that is a requirement, not a preference, and it is also what you pay for.

Region is not a factor: pods are placed without one, whether you create them in the console or through the SDK, CLI or MCP server. The SDK’s region= argument and the CLI’s --region flag are still accepted but ignored (SDK reference).

GPU hosts: how CPU and GPU pods coexist

A GPU host machine is sold both as GPU pods and as CPU pods (using its CPU and RAM only). To make sure neither category starves the other, Meshive reserves resources GPU-first:

The scheduler pre-reserves the CPU and RAM needed to rent out every GPU on the host at its maximum per-pod ratio (2× the per-GPU vCPU minimum and 2 GiB RAM per GB of VRAM — see Hardware & Network → Recommended companion specs).
Only what is left over is exposed to the CPU pod pool.

As a host, you can therefore offer your GPU machine as a CPU-pod provider too without worrying that an early CPU pod will block a later GPU customer — the GPU side always has its allocation reserved first.