Hardware discovery

You should not need to tell the network what your machine can do. A Tenzro node profiles its own hardware when it starts: every GPU and accelerator, the CPU, memory, storage and any confidential-computing support. From that profile it decides which models fit, which backend to serve on, whether it can join a cluster, and what to advertise to the network. It works the same on a laptop, a home PC with a gaming GPU, a workstation or a data-centre server.

What the node detects

Devices are sorted best first, by free memory. The capability key starts from the device description and is refined per vendor (for example a CUDA compute capability, an AMD GPU target or an Apple chip family), so per-quantisation kernel support can be checked precisely.

Supported backends

The inference runtime has a backend for every major accelerator family. A node is built with one backend, detects the matching devices at runtime and falls back to CPU if none is present.

Choose the backend at build time with the matching tenzro-node feature, for example:

cargo build --release -p tenzro-node -p tenzro-cli --features tenzro-node/cuda
cargo build --release -p tenzro-node -p tenzro-cli --features tenzro-node/rocm
cargo build --release -p tenzro-node -p tenzro-cli --features tenzro-node/vulkan

Container builds are provided for CUDA, ROCm and Vulkan. Non-language modalities (vision, speech, embeddings and others) run on ONNX Runtime and use TensorRT, CUDA or CoreML where available.

Seeing your profile

tenzro hardware
tenzro hardware --format json

Over JSON-RPC, both calls are open reads:

• tenzro_getHardwareProfile returns the machine summary: CPU, RAM, unified memory, GPUs and accelerators, storage, and TEE availability and type.
• tenzro_nodeProfile returns the inference view: the device list with backend, device type, capability key and free and total memory, plus three derived values.

tenzro_nodeProfile  ->
{
  cpu_arch: "aarch64",
  os: "macos",
  devices: [
    { backend: "Metal", dev_type: "IntegratedGpu", cap_key: "Apple M-series",
      mem_free: <bytes>, mem_total: <bytes> }
  ],
  serving_vram_gb: <gb>,
  serving_backend: "Metal",
  serving_cap_key: "Apple M-series"
}

The derived values are what the router and the cluster planner use:

• serving_vram_gb: total memory across GPU-class devices, or the largest CPU device when there is no GPU.
• serving_backend: the backend of the first GPU-class device, otherwise CPU.
• serving_cap_key: the serving device's capability key, otherwise the CPU architecture.

What the profile drives

Model choice. tenzro join --provider reads the profile and serves the largest catalog model that fits the machine. Every catalog entry declares the memory it needs, so a node knows what it can hold before downloading anything. See Model serving.

Clustering. A node willing to join LAN clusters advertises its backend, capability key and runtime build. The cluster planner uses the profile, plus measured network reachability, to decide which machines can share a model and how many layers each should hold. See LAN clustering.

Compute rental. Compute providers bond under an accelerator class (integrated, consumer, workstation or data centre) that matches what the profile reports. See Compute rental.

Confidential work. A machine with Intel TDX, AMD SEV-SNP, AWS Nitro or NVIDIA confidential GPU support can serve as a security (TEE) provider and serve confidential inference. Check with tenzro tee detect. See TEE.

Validation. Any machine with a TPM 2.0 can run a validator, with its keys rooted in that hardware. See Hardware-rooted keys.

Privacy

The profile describes capability, not identity or location. The network sees what your machine can serve and at what price; it does not need to know where the machine sits unless you choose to declare a jurisdiction in your operator policy.