Hardware Discovery.

A node profiles its own compute hardware so the network can route work to it and so it can join a cluster as the right kind of member. The profile is enumerated through the runtime's ggml backend-device list and stamped with the runtime build commit; from it the node derives the memory it can serve, the backend it serves on, and a capability key for per-quant kernel checks.

STATUS: Testnet
CRATE: tenzro-model::cluster
RPC: tenzro_nodeProfile

The self-profile

detect_node_profile() walks every device the ggml runtime reports — discrete and integrated GPUs, accelerators, CPU — sorts them best (most free memory) first, and records the CPU architecture, operating system, and the linked runtime build commit:

NodeProfile {
  llama_commit: "<build commit>",   // members must share this exactly
  cpu_arch:     "aarch64",
  os:           "macos",
  devices: [
    LocalDevice {
      backend: Metal, dev_type: IntegratedGpu,
      cap_key: "Apple M-series", description: "...",
      mem_free: ..., mem_total: ...,
    },
    // ...
  ],
}

Derived serving values

Three accessors turn the raw device list into the values the router and the cluster planner use:

serving_vram_gb()  → total memory across GPU-class devices,
                     falling back to the largest CPU device
serving_backend()  → the first GPU-class device's backend, else Cpu
serving_cap_key()  → the serving device's capability key,
                     else the CPU arch

Capability keys start as the ggml device description and are refined by a vendor enrichment step (CUDA compute capability like sm_89, AMD gfx target like gfx1100, Apple chip family) so per-quant kernel checks upstream are precise.

Reading the profile

tenzro_nodeProfile returns the full device list plus the three derived values:

tenzro_nodeProfile {}  →

{
  llama_commit: "<build commit>",
  cpu_arch: "aarch64",
  os: "macos",
  devices: [ { backend, dev_type, cap_key, mem_free, mem_total }, ... ],
  serving_vram_gb: 36.0,
  serving_backend: "Metal",
  serving_cap_key: "Apple M-series",
}

From profile to cluster member

NodeProfile::to_member projects the node into a ClusterMember for orchestration — its address, the derived VRAM / backend / capability key, the build commit, its LAN endpoint, and its measured data-plane reachability. That member is what the cluster planner gates and bin-packs layers across.

profile.to_member(address, local_endpoint, reachability)
  → ClusterMember { address, vram_gb, backend, cap_key,
                    llama_commit, local_endpoint, reachability }

← All docs