Vacuum in one page

What runs where

Your request goes to the Vacuum router, which picks a node that has the model you asked for and a clean record of serving it. That node runs the model on its own GPU and streams the response back. None of that happens on a blockchain — running a language model on-chain is not realistic, and Vacuum does not claim to.

What does go on-chain is everything needed to prove and to punish: the registry entry pinning a model to its exact weights, the collateral the operator has posted, a cryptographic commitment to every execution, audit outcomes, disputes and penalties.

What you are trusting

This is not the same set of assumptions as a cloud API, so it is worth being precise.

• The model is the model. Each registry entry is identified by the hash of its weights, its quantization format and the inference engine version. An operator serving something smaller is committing fraud, and a sampled audit scores the response against the declared model to catch it.
• The token count is checkable. Receipts commit to the response, so the billed count can be recomputed. Overbilling is not a matter of taking the operator’s word for it.
• The operator can read your prompt. A real limitation, not a footnote. Inference on consumer hardware happens in plaintext on someone else’s machine. Do not send regulated or sensitive data through Vacuum at this stage.

The shape of a request

The API follows the request and response format you already use, so migrating is usually a base URL and a key. Streaming, system messages and the usual generation parameters behave the way you expect.

Where to go next

• Quickstart — a working request in about a minute.
• Chat completions — every parameter the main endpoint takes.
• Receipts and proofs — how to verify what you were served.
• Run a node — if you are here for the other side of the market.