> For the complete documentation index, see [llms.txt](https://docs.kinesis.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kinesis.network/getting-started/running-llms-with-kinesis-network/understanding-compute-sources.md).

# Compute options

Choose between serverless capacity and compute managed through grids.

Choose compute for the organization’s workloads. Admins manage servers and grids; Developers deploy to accessible grids or use serverless capacity when enabled. Viewers inspect resources.

| Option                      | How it works                                                                 | Good starting point for                                           |
| --------------------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------- |
| **Serverless CPU**          | Kinesis places CPU workloads on managed capacity matching their requirements | Getting started without managing servers                          |
| **Dedicated cloud servers** | Provision machines and compose them into grids                               | Workloads needing selected machine types and capacity you control |
| **Your infrastructure**     | Connect machines and use them through grids                                  | Bringing existing compute into the same deployment workflow       |

## Serverless capacity

Serverless GPUs are currently paused. Serverless placement is CPU-only; configure RAM, storage and region requirements. GPU apps must target a grid. The runtime selects eligible CPU capacity. Tight filters reduce the machines that can run the app; a valid configuration does not guarantee capacity is immediately available.

Serverless usage is metered at resource level. CPU activity, memory, storage and network usage can contribute separately to cost. An idle CPU does not imply every other resource is free. Organization admins use Cost and the current [pricing calculator](https://portal.kinesis.network/pricing-calculator) for your workload.

Admins can turn off serverless capacity for Developers under **Organization → Settings → Compute**. Existing running apps keep running, but Developers must target a grid for new starts, rebuilds and changes that need new serverless machines. Admins retain serverless access.

## Dedicated servers and grids

A server is a machine. A grid is the logical group your app targets. A grid can hold several servers, and an app can target more than one grid.

As an organization admin, open **Servers** in the portal to provision or connect machines, then compose them into grids. Developers select an accessible grid in the app’s Resources step. Organization URLs include the slug, for example `/dashboard/acme/my-servers`; the sidebar label is **Servers**.

Dedicated compute is billed through the servers. Hibernation stops compute billing while retaining the disk and its storage cost. A stopped app does not, by itself, confirm that its server is hibernated; inspect the server state and the grid's configured lifecycle behavior.

GPU configurations need at least one grid ID. In the API, `hardware.gpuCount > 0` with no `grids.ids` returns `serverless_gpu_unavailable`. Move an older serverless GPU app to a grid, or remove its GPU requirement, before saving changes.

## Placement and scale

Hardware and location filters combine to restrict eligible machines. More instance capacity requires enough matching resources. Check placement errors and grid capacity when an app has a running target state but no running container.

Grid policies can also cap GPUs, apps and running containers per person, counted against the app’s creator, reclaim idle capacity or queue work fairly under contention. See [Grids and shared capacity](/getting-started/running-llms-with-kinesis-network/understanding-grids.md).

## Marketplace capacity

The API and MCP catalog can browse spot capacity by hardware and location. Renting marketplace capacity is not exposed by the public operations documented here. Contributing hardware follows the separate [provider guide](/getting-started/kinetization-of-idle-compute.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.kinesis.network/getting-started/running-llms-with-kinesis-network/understanding-compute-sources.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.