compute monetization platform

You own the hardware.
HZ brings the demand.

Not another marketplace. HZ AI routes qualified buyer workloads onto your available GPU capacity, then meters and bills it - built around demand, not listings. You provide the compute; we bring the workload.

The problem

Idle GPUs are stranded revenue.

Capacity that sits unsold earns nothing. A listing board makes you wait to be discovered.

listing boardillustrative
gpu-0listed, idle
gpu-1listed, idle
gpu-2listed, idle
gpu-3listed, idle

$ waiting to be discovered

How it works

Connect. Match. Monetize.

agent · mTLS

01 Connect

Bring your infrastructure. HZ monitors its health and available capacity.

gateway · sandbox

02 Match

HZ routes qualified buyer workloads onto your available capacity, isolated on your host.

metered · billed · paid

03 Monetize

Usage is metered and billed. You get paid for what runs on your hardware.

> No waiting for someone to discover a listing.

Buying instead? Deploy a workload onto available capacity, or own the hardware outright.

The model

Listing boards aggregate supply. HZ routes demand.

The difference is not GPU count. It is who is responsible for bringing the workload to the hardware.

model · comparison

How buyers arrive

Traditional listing marketplace

You wait to be found

HZ AI demand network

HZ routes workloads to you

Utilization

Traditional listing marketplace

Your problem

HZ AI demand network

The platform's job

What you manage

Traditional listing marketplace

Listing, price, support

HZ AI demand network

Connect once. HZ handles match, deploy, meter, pay

Isolation

Traditional listing marketplace

Varies by host

HZ AI demand network

gVisor sandbox + mTLS. Your host is never exposed to buyers
Demand network

Workloads in. Revenue back.

Compute buyers submit workloads to HZ. HZ matches, routes and deploys them onto connected GPU infrastructure, meters the usage and bills the buyer. The infrastructure owner is paid from that usage.

workload flow
HZ AI demand networkCompute buyers submit workloads to HZ AI. HZ matches, routes and deploys each workload onto connected GPU infrastructure, meters the usage and bills the buyer. Revenue is paid to the infrastructure owner.▍ COMPUTE BUYERSssh / dedicatedbatch / traininginference endpoint▍ GPU INFRASTRUCTUREyour GPUsagent · mTLSgVisor sandbox▍ HZ AI DEMAND NETWORK01matchqualify and place02routegateway auth over mTLS03deploygVisor sandbox04meterper-second usage counts05billprepaid creditsworkloadbilldeployusagepayoutREVENUEto the infrastructure owner

Workloads are routed in. Usage is metered per second. Revenue follows what runs.

For infrastructure owners

Have GPUs? You don't need another listing board.

HZ routes buyer workloads onto your capacity and meters the usage. You keep control of the hardware and HZ handles monitor, match, deploy, meter, pay.

  • /One-command install on Ubuntu / Debian
  • /Set your own price per GPU-hour
  • /Specs auto-detected and matched to qualified workloads
  • /Sandboxed with gVisor behind mTLS - your host IP is never shown to buyers
  • /Receive payouts in fiat
infrastructure · setupbash
$ curl -fsSL 'https://github.com/hz-ai-io/hzai-agent/releases/latest/download/install.sh' | sudo env HZAI_VERSION='v0.1.12' HZAI_BOOTSTRAP_TOKEN='hzai_bs_…' HZAI_API_URL='https://api.hz-ai.io' HZAI_MTLS_API_URL='https://api.hz-ai.io:8443' HZAI_PUBLIC_IP='203.0.113.10' bash
✓ agent v0.1.12 installed
✓ detected 2× NVIDIA A100 80GB
✓ enrolled over mTLS · capacity available

$ hzai-agent --price 1.89
waiting for jobs…
Isolation

One request path. Tenants never touch.

Every inference request follows the same isolated path from the public edge down to a sandboxed workload on the infrastructure owner's host.

Request pathedge → host

Buyer

HTTPS

Caddy edge

auto-TLS

Gateway

auth · meter

tlsproxy

mTLS

Workload

sandboxed

Prompts and outputs stay on the infrastructure owner's host. Only metering counts cross to the control plane.

Host IP never exposed

On the inference path, buyers hit a per-deployment gateway. The infrastructure owner's host address stays behind mTLS. It isn't in any buyer-facing API response.

Hardened, enrolled agent

Connected infrastructure runs a memory-safe Rust agent enrolled over mTLS. Private (RFC1918) networks and cloud metadata are denied by default and workloads run under gVisor.

Keys you can trust

Per-deployment API keys, compared in constant time and revocable instantly. Rate limits and request caps are enforced at the gateway, not bolted on.

FAQ

Your questions answered.

Per second. You prepay with credits and a running job is metered per second at the infrastructure owner's GPU-hour rate, minus our platform fee. Unused credits stay in your account.

Yes, on-demand instances and dedicated reservations give full SSH access with your own public key. You can also run batch jobs or deploy inference endpoints instead.

Each job runs in its own container with dropped capabilities and a read-only root filesystem, and gVisor syscall-sandboxing where the runtime is configured. On the inference path the host IP is never exposed to buyers, traffic goes through a per-deployment gateway over mTLS.

Whatever connected infrastructure currently has available. That spans consumer cards (RTX 4090/3090) and datacenter GPUs (A100, H100). Availability tracks real capacity, so it changes through the day.

Run the one-command installer on an Ubuntu/Debian box, set your price, and your node becomes available capacity once the agent enrolls. Payouts are made via Stripe.

We don't claim an uptime SLA, multi-region HA, or SOC 2 certification today. We don't guarantee utilization or revenue for connected infrastructure: HZ routes qualified workloads onto available capacity, but how much runs depends on buyer demand. Capacity depends on the infrastructure connected at the time, and a few things (private registries, confidential-compute GPUs) are on the roadmap.

Put idle GPUs to work.

Connect your infrastructure and HZ routes buyer workloads onto it, or deploy a workload onto available capacity.

Buy compute