Docs
How the kvrun console works.
Six guides covering the whole path: pick a model, get a private endpoint on a dedicated GPU, fine-tune on your own data, and read the evidence the platform produces as it runs.
Start here
The path from an empty console to a live, locked-down endpoint.
Build
Train on your own data, and wire the result into your code.
Fine-tune a model with LoRA or QLoRA ↗
Train an adapter on your own data: pick a base model and method, point at a dataset, review the runtime and cost, then deploy the result as its own endpoint.
Call your endpoint from code ↗
Your deployment is an OpenAI-compatible endpoint: swap the base URL and key, stream responses, isolate cache per end user, and wire it into a coding agent.
Operate
Governance, access and where the hardware actually sits.
The governed KV cache and its audit log ↗
What kvrun does with the attention state behind your deployment: encrypted tiers, per-tenant isolation, a hash-chained audit log, and how to read the evidence.
Workspace, roles, keys and storage ↗
How the console is organised: one workspace per team, four roles, two kinds of API key, a storage tree for datasets and adapters, and where billing lands.
Where your workloads run ↗
Four placements: our managed fleet, your own cloud account, your own server, or fully self-hosted. Who pays, who controls the data, and what changes.
Beyond the console