Choose a useful cluster boundary
A cluster is more than a folder. It defines an accelerator family and a schedulable capacity boundary. Group machines that can be operated under the same availability, networking, driver, and maintenance policy. Separate experimental hosts from production capacity and keep NVIDIA and AMD systems in different clusters.
Cluster listings expose aggregate capacity and are used for Kubernetes namespace rentals. Node listings remain tied to individual machines and are used for SSH workspaces. A cluster can contain multiple nodes while each node’s inventory, benchmarks, uptime, and availability remain visible. The cluster page displays its maximum compute-node capacity; the default is 15 compute nodes. Reserved node profiles count toward that limit. When it is full, remove an unused profile or create another cluster rather than attempting to resize an active cluster.
GPU benchmarks are per device, measured at the same time. Every physical GPU runs the pinned llama-benchy profile against its own engine while all other GPUs do the same, so each result reflects the card under whole-node load — the run doubles as a stress test. The card model, VRAM and device identity are pinned, and identical cards keep separate results. There is no whole-node score: a shared engine across devices pools memory in a way that is not comparable, so only per-device results are published.
The benchmark details show the workload profile, measurement date, and individual generation and prompt-processing rates per GPU. Compare only matching profiles. Missing, unsupported, failed, partial and stale results do not imply a zero score or complete qualification. A partial report can retain useful individual results without a complete host result.
Rebenchmarking requires unoccupied capacity. Active and reserved rentals prevent it, including idle namespace reservations. During collection, the device and completed coverage appear in benchmark progress. Changed device identities, drivers or benchmark software require fresh coverage; reports expire after 30 days. A legacy node score cannot identify the performance of a particular GPU.
Read the Activity Monitor
| Milestone | Meaning |
|---|---|
| Cluster Provisioned | The managed controller completed its initial readiness path. |
| Node Added | A join was accepted and an inventory record exists; it does not yet mean rentable. |
| Nodes Synced | ComputeCubed reconciled controller nodes with the marketplace records. |
| Cluster Out Of Sync | Observed topology or controller reachability differs from the expected state. |
| Rental Starting / Active / Ended / Error | A rental on this capacity crossed a contract lifecycle boundary. |
Understand node readiness
Connected means the node is visible to the cluster. Inventory pending means hardware collection is not complete. Benchmark pending means performance evidence is still being produced. Ready means the current inventory and benchmark requirements are satisfied. Rented identifies allocated capacity, and disconnected means the node is no longer ready.
The collapsed node row shows operational health separately from the rental and listing. During a detected outage it shows Disconnected, Rental interrupted, and Billing paused. Listing enabled — unavailable means your listing settings are retained but the node cannot accept a new rental. Restore the node; do not remove it merely to clear an interruption.
The rental and its allocated resources remain reserved during an interruption. The renter and provider receive Console notifications when billing pauses and when service recovery is verified, with a record in the activity history. Billing does not resume just because the node reconnects: the rented service must pass recovery checks. Renters can use End rental during an outage.
Node uptime uses rolling windows of 1 hour, 1 day, 1 week, and 30 days. A window without a full tracking history shows Insufficient history. Since tracking began measures only the observed history, including detected downtime. A measured 0.000% means no recorded online time in that complete window. Node history is separate from a rental’s committed-period uptime guarantee.
Inspect live performance metrics
The cluster detail page shows recent CPU, memory, filesystem, network, GPU utilization, temperature, and power telemetry when the metric is supported by the node. Choose a time window from one hour to 30 days and, on multi-node clusters, filter the view to one node. Separate charts and units make sustained pressure and gaps easier to distinguish than a single combined graph.
Hover over any chart to inspect its values and local timestamp. All charts follow the same time so you can compare resources together. Focus a chart and use the arrow keys, Home, or End to inspect samples with the keyboard. A dash means there is no sample at that time. Each chart always shows the latest values and their timestamp; move away or press Escape to return to them. Click a series name below a chart to hide or show that series, for example to focus on one node’s values. Series keep the same color and order in every chart.
Marketplace listings also offer past rental reliability, with saved rental evidence and explicit coverage. Node reboot detection is separate from container restarts, and history for changed hardware is excluded from current listing summaries.
Metrics are operational evidence, not a billing meter or an uptime guarantee. A blank interval can mean that a node, exporter, controller, or network path was unavailable; it does not mean the measured value was zero. Hardware without a supported sensor reports no series for that panel.
Protect shared capacity with Availability Guard
If you also use a node for your own workloads or offer it through another service, install Availability Guard from the cluster detail page. The guard observes sustained GPU, CPU, and RAM pressure on each worker. A node with external activity is temporarily removed from new ComputeCubed marketplace capacity; compatible capacity on other available cluster nodes can remain rentable.
Availability Guard is a controlled platform feature. If it is disabled for your account, existing telemetry no longer changes marketplace or rental availability and the Console prevents new installations. You can still remove an already-installed monitor. Re-enabling the feature restores normal guard evaluation without changing active rental contracts.
The cluster page shows each node as available, externally busy, or awaiting telemetry. New rentals fail closed while telemetry is missing or stale. Short spikes are filtered before a node becomes busy, and a recovery period prevents listings from flickering. When a ComputeCubed rental is active on a node, the accepted rental allocation remains the source of truth and guard observations do not override it.
Installing the guard does not reserve a GPU from Kubernetes. Remove it from the same cluster page when you no longer want external activity to affect listing availability. Removing the guard also removes its current reports; your published listings and active contracts are not deleted.
Manage empty clusters
ComputeCubed allows one cluster without joined nodes per accelerator family in your account. This includes stopped clusters. If the Console blocks another cluster, follow its link to the existing empty cluster and either add capacity there or delete it.
An empty cluster is stopped after 24 hours to avoid reserving an unused managed controller. Removing the last joined node begins a fresh 24-hour period. A disconnected node is still attached, so a temporary outage does not make the cluster empty. While a cluster is stopping, stopped, or starting, new nodes cannot join. Use Start Cluster on the cluster detail page and wait for ready before adding a node.
If an automatically stopped cluster remains dormant, ComputeCubed sends a deletion warning after two days and schedules deletion no sooner than 24 hours after that warning is delivered. It sends another email after deletion. Starting the cluster before the displayed deletion time cancels that deletion cycle and starts a new empty period.
Hardware and topology changes
Do not add, remove, or re-identify GPUs, CPU capacity, RAM, or cluster nodes during active rentals. Cluster listings are tied to a recorded composition. If the live composition no longer matches, ComputeCubed can pause the listing so a renter does not accept stale aggregate capacity.
For planned changes: delist, wait until all active rentals end, stop the node, make and test the change, rejoin or synchronize as required, wait for fresh inventory and benchmarks, inspect the new marketplace evidence, and relist. New terms are recorded in a new listing version.
Remove nodes and clusters safely
Removal is destructive to future scheduling and may require control-plane cleanup. First delist every affected offer. Confirm there are no starting or active rentals. Export any provider records you need. Remove the node through the Console, then stop and uninstall the managed agent and WireGuard configuration on the host if it will no longer participate.
If cluster deletion fails, the cluster remains visible with an error. Review the Activity Monitor and retry deletion after the problem is resolved. Do not assume its resources have been removed until deletion completes.
Cluster details show queued, in-progress, completed or needs-attention requests with an operation reference. If a request fails, use Retry request when offered. Keep the reference when contacting support. A connection failure does not necessarily mean the cluster was not created; check your cluster list before creating another.