Providing inference
A provider runs the Katara node on a machine with a supported GPU, serves one or more approved bundles, and is paid in USDC for every reply it completes. There is no stake and no minimum commitment.
What you need
Section titled “What you need”- Apple Silicon: any M1 to M5 chip. Each model states the unified memory it needs, from 8 GB for the smallest.
- NVIDIA on Linux or Windows: a GPU with compute capability 6.1 or better and enough video memory for the model, from 3 GB for the smallest. On Linux, Docker and the NVIDIA container toolkit, since the runtime ships as a container; on Windows, the native app needs no Docker.
- A wallet on Katara (created in the portal) to register with and be paid to.
- An outbound internet connection. The node connects out to Katara, so no public address, port or certificate is needed; see Networking.
Hardware compatibility has the full tables: every supported chip and card, and which bundles each one can serve.
How it works
Section titled “How it works”- The node detects your hardware and shows which approved bundles it can run.
- You pick a bundle. The node fetches the pinned weights and checks every hash.
- You register once in the portal: your payout address and the node’s signing key.
- The node publishes signed price offers. The router sends you jobs when your offer wins.
- Each completed job returns a signed receipt. Katara settles it on chain and pays your address, less Katara’s fee: 2%, plus a fixed 0.012 USDC (0.018 with
upto) on a reply paid per request with x402.
A node serves one of the two networks: Live, paid in USDC on Avalanche C-Chain, or Test, paid in test USDC on Avalanche Fuji. Registration and settlement happen on the network it serves. Running a node has the commands.
Validation
Section titled “Validation”Validators send known prompts through the normal job path at intervals and score your answers. A provider that fails or stalls stops being picked for a few minutes, then gets tried again. Scores are kept per bundle and profile, so trouble with one does not follow you to another, and a tuple nobody has scored yet is not held against you.
Nothing beyond that happens on its own. You can pause and resume your registration from the portal. Registration is withdrawn by hand, for serving something other than the pinned bundle or for forged receipts, not for a machine that turns out to be slow.
Your wallet key never touches the node. The node signs offers and receipts with a separate service key that you register alongside your wallet; rotate it from the portal at any time.
What The Node Reports
Section titled “What The Node Reports”The node describes the machine it runs on. It sends that description when it connects and every minute after, signed with the same service key that signs your offers. The gateway will not accept offers from a node that has not sent one, so this is part of running a provider rather than an option in a config file.
What goes in it:
- The chip or graphics card, memory, compute capability, and core counts.
- The bundle and profile being served, and whether the machine met the profile.
- What the startup benchmark measured: first-token latency and tokens per second.
- The node version, the operating system and its version, and the CPU model.
- How the runtime is doing: its health checks, restarts and memory, how many jobs it has in flight and has finished, and the input and output tokens it has served.
- Identifiers that distinguish one machine from another, such as board and GPU serial numbers and UUIDs, so that a single machine cannot quietly register as several providers.
What never goes in it: prompts, replies, or anything about who is asking. The node does not keep those and does not send them.
A machine that fails its own checks reports that too, and then exits without serving. Those results are the most useful ones we get: they are how the hardware requirements in Hardware compatibility are set, and they are the reason a chip that works can be added to a bundle’s list.
Read Running a node next.