Node Matching

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 that scoring order — 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).
• 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, the scoring order below picks the winner.

Scoring order

1. 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.

2. 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.

3. Network speed The score uses the host’s measured upload and download bandwidth from a periodic network speed test — not latency or ping. Higher sustained throughput wins.

4. CPU generation When everything else is equal, a newer-generation CPU host wins.

5. DDR generation DDR5 hosts are preferred over DDR4 hosts at the same other factors — newer memory is faster end-to-end for the same workload.

6. Disk speed Disk read/write speed (measured periodically) is the last tiebreaker — faster persistent storage means snappier checkpointing and dataset loading.

Geographic distance is not part of scoring today. In a future iteration clients will pick a region directly instead of having the scheduler infer it.

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:

1. 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 minimum — see Hardware & Network → Recommended companion specs).
2. 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.