Connect & discover
Connect heterogeneous GPU nodes and energy devices. Record hardware capabilities, connectivity and available resources.
Bring node health, workload dispatch and household energy into a single management experience. Explore how SunStack’s control platform is being developed for distributed compute.
| Node / location | Hardware | Utilisation | Power | Status |
|---|---|---|---|---|
| Sydney · Node 01 | RTX 309024 GB VRAM | 78% | 225 W | Available |
| Newcastle · Node 02 | RTX 409024 GB VRAM | 64% | 270 W | Available |
| Wollongong · Node 03 | RTX 309024 GB VRAM | 42% | 180 W | Available |
| Dubbo · Node 04 | RTX 409024 GB VRAM | 0% | 0 W | Energy hold |
A management approach that connects telemetry to decisions, while keeping device limits and household priorities visible.
Connect heterogeneous GPU nodes and energy devices. Record hardware capabilities, connectivity and available resources.
Bring GPU utilisation, power, temperature, workload activity and dedicated energy metering into one operational view.
Consider PV availability, battery state of charge, household load, tariffs and grid constraints before scheduling.
Study how a job behaves on different GPU configurations and power limits to estimate runtime, energy and capacity needs.
Match jobs to appropriate nodes, apply supported power controls, and respond to changing energy conditions or node failures.
The control room uses illustrative data. Predictive scheduling, automated power control and recovery are development capabilities, subject to hardware support and trial validation.
The management approach connects observations from each property with workload planning and an operator’s view of the network.
PV, battery, household and GPU metering.
Device health, capabilities and supported local controls.
Job matching, energy windows and recovery decisions.
Fleet state, policies, workload status and measured outcomes.
The prediction module is intended to estimate the consequences of choosing a GPU configuration and power setting. More GPUs do not automatically mean a better result.
Explore the evaluation approachPredictions need calibration against measured workloads. Multi-GPU estimates must reflect interconnect, task parallelism and system overhead.
Intended operating responses are subject to hardware support, workload behaviour and validation in trials.
| Condition | Management intent | What needs to remain visible |
|---|---|---|
| Household demand increases | Reduce new job admission or supported GPU power within the agreed policy. | Household load, GPU allocation and the reason for a change. |
| Battery approaches its reserve | Restrict battery-supported work and preserve the household reserve. | State of charge, reserve setting and eligible energy sources. |
| Temperature approaches a limit | Apply supported throttling, pause work or take the node out of service. | Temperature, effective power limit and recovery state. |
| A node becomes unreachable | Stop assigning new work and assess restart or migration options. | Job state, retry cost, output integrity and node connectivity. |
| A job needs more resources | Reassess placement and feasibility against model memory and runtime needs. | GPU capability, resource requirements and an explanation of the match. |
Inventory GPUs, energy devices, metering, network boundaries and existing operating constraints.
Collect comparable telemetry and measure representative workloads before applying optimisation.
Introduce limited scheduling and supported controls, with clear fallbacks and reviewable results.
Use measured performance, household impact and operational outcomes to guide further deployment.