Akash Network

Akash is a marketplace for deploying a containerized application on a chosen independent provider. Its core unit is a continuously running resource lease, funded from escrow, rather than a one-off GPU job that returns a completed file.

A deployment declares the application and its resource shape

A tenant defines services in an SDL, including a container image, CPU, memory, storage, ports, price ceiling and, where relevant, GPU-model requirements. CPU is requested in threads, memory and storage in Mi or Gi, and GPU capacity in units with specified model requirements.

That declaration is also an operational constraint. CPU, memory and storage cannot be resized in place after deployment, so changing them means creating a new deployment rather than adjusting a live server. Console, CLI and SDK are alternative control surfaces for the same deployment-and-lease lifecycle.

Provider bids become a specific lease

Providers advertise capacity and bid on an order created from the deployment. The tenant selects a bid and creates a lease that binds the provider, quoted resources and lease price; location, offered attributes, hardware, availability and price are part of choosing that concrete provider.

After the lease starts, the provider pulls the image and runs the service. A lease shows that the resources were contracted; it does not establish that the image, configuration, endpoint security, data handling or application behaviour is correct. Health checks, observability, secret management, backups, failover and acceptance testing remain the tenant’s work.

Escrow sustains the running workload

Current documentation describes ACT, a USD-pegged compute credit, as the normal funding asset. The selected provider is paid automatically from the tenant’s escrow per block while the lease continues, making the payment model time- and resource-lease-based rather than contingent on approval of a finished task.

Escrow must remain funded. A bid applies to the selected provider and the requested resource shape, not to every provider, future redeployment or larger workload; price and capacity should therefore be checked again when the deployment changes.

Persistence is provider-local, so migration needs a plan

Container writable-layer storage is ephemeral by default. Persistent storage has to be requested explicitly and is backed by the selected provider; it can survive container and provider restarts and updates on that provider, but it is not portable network storage.

Provider-local persistent data does not survive lease termination, a move to another provider or a provider storage failure. Storage cannot be resized in place and volumes are not automatically shared among services, so critical applications need external backup or replication before a provider change.

Render Network is for a different GPU-workflow boundary

Render Network is the closer alternative where the requirement is a bounded GPU render or supported AI job with output review and a completion-linked reward flow. Akash instead is for a tenant-configured container workload with exposed service ports and an ongoing provider lease.

The decision is not simply GPU versus non-GPU capacity: it is whether an application needs a selected environment that it continues to operate, or a job system that assigns work, returns output and has the creator accept or reject the result.