Tenzro
AI

Model serving.

Run a provider. Register, serve, and earn TNZO per inference.
STATUS
Testnet
CRATE
tenzro-model
STABILITY
Stable
TYPE
Guide
01

Register

tenzro stake deposit 1000 --provider-type model-provider
tenzro provider register --models qwen3-0.6b,gemma3-12b
02

Serve

tenzro model serve qwen3-0.6b --device cpu
tenzro model serve gemma3-12b --device gpu --concurrency 4
03

LAN clustering

When a model is too large for one host, the node clusters automatically. It reads the GGUF header for layer count and hidden dimension, discovers LAN members from gossiped cluster announcements, splits the layers VRAM-weighted across them, and runs a layer-wise pipeline. No extra arguments are required — the node decides single-host vs. cluster from the model shape and the reachable members.

# Auto: single host if it fits, cluster if it doesn't
tenzro model serve gemma3-27b

# Force a split even when it fits one box (trades decode speed for memory)
tenzro model serve gemma3-27b --cluster

# Never cluster; pin single-host
tenzro model serve gemma3-27b --force-single

Preview the proposed layer split before serving with tenzro cluster preview <id> — it surfaces discovered members, the VRAM-weighted split, and any rejected members (commit mismatch, unreachable data plane, insufficient VRAM).

04

Visibility

By default a served model is announced to the network so any peer can route inference to it. Serve privately to register it locally without gossiping — no announcement, no heartbeats, no presence in provider discovery. Reachable only over a direct or LAN connection.

tenzro model serve qwen3-0.6b --private
05

Sealed distribution

Private weights move between nodes as encrypted shards — the artifact never travels in cleartext. Sealing splits it into 256 MiB shards, encrypts each under a single AES-256-GCM content key, publishes the ciphertext to the content-addressed blob store, and wraps the content key once per named recipient with X25519 envelope encryption (x25519-hkdf-sha256-envelope-aes-256-gcm). A recipient is a DID plus an X25519 public key, optionally pinned to an enclave measurement. The signed manifest binds shards, recipients, and the plaintext hash together; it carries no usable key material, so it can be delivered over any channel.

# Recipient: publish the node's X25519 recipient key
tenzro model recipient-key

# Owner: seal + export the manifest (admin-gated)
tenzro model seal my-finetune --path /models/my-finetune.gguf \
  --owner-did did:tenzro:machine:... \
  --recipient "did:tenzro:machine:...=<64-hex-pubkey>" \
  --admin-token $TENZRO_ADMIN_TOKEN
# ...or pin the recipient to an enclave measurement:
#   --recipient "did:tenzro:machine:...=<64-hex-pubkey>=<measurement-hex>"
tenzro model sealed-get my-finetune --out my-finetune.manifest.json

# Recipient: install + serve privately (admin-gated)
tenzro model install-sealed --manifest-file my-finetune.manifest.json \
  --recipient-did did:tenzro:machine:... --admin-token $TENZRO_ADMIN_TOKEN
tenzro model serve my-finetune --private

Install verifies the manifest signature, every ciphertext hash, and the plaintext artifact hash before anything reaches model storage. When a recipient pins an enclave measurement, the installing node proves its own enclave first — a fresh report committing to its DID and X25519 public key, verified against a pinned vendor root, whose measurement must equal the pinned one. Simulated reports are refused, and a node with no TEE provider is refused rather than allowed through. Sealing and installing are operator actions behind the node admin token (tenzro_sealModel / tenzro_installSealedModel); discovery — tenzro_listSealedModels, tenzro_getSealedModel, tenzro_modelRecipientKey — is open.

06

Health

Background health monitoring polls every endpoint. Reputation moves +1 on success, -5 on failure (saturating, ceiling 1000, floor 0). Reputation is persisted in CF_PROVIDERS.

07

Discovery

Every served model is listed at GET /v1/models with per-token pricing in TNZO wei, context length, max output tokens, feature flags (streaming, usage-in-stream, MTP, provenance signing), and the provider's declared datacenter geography and ISO 3166-1 alpha-2 jurisdiction country code — derived from registry and gossip-announcement state. An operator who declares a TNZO listing rate also gets USD per-token prices on every entry, for marketplaces that list in fiat. The response carries a data_policy object declaring retention behavior: prompt and completion bodies are never written to disk.

08

Schedule

tenzro schedule set --start 09:00 --end 21:00 --tz UTC
tenzro schedule show
Related
← All docs