DOCSEARCHbyAlgolia
Submit Docs

Akash Network Extended Reference

website·Indexed 36 days ago

https://akash.network/docs

A decentralized compute marketplace connecting tenants with independent compute providers. Documentation covers deployment paths via Console, Console Air, and the akt CLI; SDL (Stack Definition Language) configuration; GPU workloads and managed inference with AkashML; funding via ACT compute credits; and provider operations using Kubernetes infrastructure.

Tokens
8.3K
Snippets
23
Records
56
Agent score
73%

What's inside Akash Network

  1. Overview of supplying compute as an Akash Provider

    Providers on the Akash Network operate Kubernetes infrastructure to advertise resource capabilities, submit bids, and schedule tenant workloads. They are responsible for maintaining gateways and storage/network services. Specialized capabilities such as GPUs, persistent storage, dedicated IPs, confidential compute, and interconnects require specific hardware and provider-side configuration. Provider attributes and audits are used by tenants to select infrastructure, though they do not guarantee all application-specific compliance or availability requirements.

  2. Understand Akash SDL structure and components

    SDL is a YAML-based configuration language with Akash-specific semantics (not Docker Compose or Kubernetes). It consists of five primary sections that define how a deployment is structured:

    • services: Defines images, commands, environment variables, ports, credentials, and runtime parameters.
    • profiles.compute: Specifies CPU (fractional cores), RAM, storage, and optional GPU resources per service instance.
    • profiles.placement: Defines provider requirements, auditor constraints, and maximum price bids.
    • deployment: Maps specific services to placements and compute profiles, including the number of instances (replicas).
    • endpoints: Optional dedicated IP endpoints for specific exposure rules.
    version: "2.0"

services:
  web:
    image: nginx:1.28.0
    expose:
      - port: 80
        as: 80
        to:
          - global: true

profiles:
  compute:
    web:
      resources:
        cpu:
          units: 0.5
        memory:
          size: 512Mi
        storage:
          - size: 1Gi
  placement:
    dcloud:
      pricing:
        web:
          denom: uact
          amount: 100

deployment:
  web:
    dcloud:
      profile: web
      count: 1

  3. Understand the difference between Akash full nodes and validators

    In the Akash Network, a full node tracks the blockchain and provides RPC/API access. A validator performs all full node functions but additionally participates in network consensus using a signing identity and stake. Validator operators are responsible for managing signing keys, maintaining uptime, performing backups, handling network upgrades, and avoiding slashing conditions. Note that provider operations and validator operations are separate responsibilities.

  4. Deploy AI and Distributed Compute frameworks on Akash

    Akash supports various GPU-intensive workloads provided the application image is compatible with the requested GPUs and software stack. Supported use cases include:

    • Inference: vLLM, Ollama
    • Image Generation: ComfyUI
    • Distributed Compute: Ray
    • Other: Fine-tuning tools and notebooks.

    Best practice: Store checkpoints and outputs outside of the disposable lease to prevent data loss, and close batch deployments immediately after retrieving results.

  5. Understand Akash Network compute credits (ACT vs AKT)

    Akash uses two primary denominations for network operations:

    • ACT: A USD-pegged compute credit used for canonical SDL pricing and escrow. It is not a standard transferable payment token.
    • AKT: The native token used for transaction gas.

    Denominations:

    • 1 ACT = 1,000,000 uact
    • 1 AKT = 1,000,000 uakt

    BME (Burn-Mint Equilibrium): This protocol mechanism allows users to convert AKT into ACT by burning AKT. Conversion rates and circuit-breaker behaviors are determined by the live protocol state.

  6. Understand the Akash Network compute marketplace model

    Akash is a decentralized compute marketplace that connects tenants (users needing compute) with independent providers (infrastructure suppliers).

    Key operational flow:

    1. Request: A tenant defines container images and resource requirements using Stack Definition Language (SDL).
    2. Bidding: Providers bid on these requests based on their available capacity.
    3. Lease: Accepting a bid creates a lease, and the provider runs the containers on their physical infrastructure.
    4. Settlement: The blockchain is used to record marketplace agreements and settle payments from escrow.

    Crucially, application computation occurs on provider machines, not on the blockchain itself.

  7. Decide between AkashML and GPU deployments

    When deploying AI workloads on Akash, choose based on the level of control required:

    • AkashML: Use this when the task is simply calling a supported hosted model via API.
    • GPU Deployment: Use a full GPU deployment when you require control over model weights, serving software, specific dependencies, or training processes.

  8. Choose an Akash Network deployment path based on your needs

    Depending on your requirements for custody, interface, and automation, choose the appropriate Akash Network product or interface:

    • Managed Web Deployment: Use Akash Console for a hosted browser app experience using USD credits and a managed wallet.
    • Self-Custody Web Deployment: Use Console Air (self-hosted/local app) with a compatible wallet, ACT escrow, and AKT gas.
    • Terminal Deployment (Local Signing): Use akt keyring context for local signing accounts with on-chain escrow and transaction fees.
    • Terminal Management of Console Deployments: Use akt console-api context with a Console API key and managed wallet.
    • Deployment Service Integration: Use the Console API with an x-api-key header and a funded Console account to avoid managing chain keys.
    • Direct Blockchain/Provider Integration: Use the Go or TypeScript chain-sdk for application-managed signing and provider authentication.
    • AI Assistant Integration: Use the Akash skill bundle, akt-cli skill, and akt MCP to provide AI assistants with Akash knowledge and tools.
    • Hosted Model Inference: Use AkashML with a separate inference API key and credits if you only need to call a model without operating a full deployment.
    • Hardware Provisioning: Use Provider Playbook, Kubespray setup, or Provider Console to offer hardware to tenants as a provider.

  9. Manage images and secrets in deployments

    Best practices for images and security:

    • Image Pinning: Always pin images to an explicit version or digest to avoid breaking changes from tags.
    • Private Registries: Use the credentials section in the SDL to provide pull-scoped tokens for private images.
    • Secret Security: Environment variables and registry credentials in the SDL are not automatically encrypted against the provider. Do not store sensitive secrets in public SDL files or source control; use an external secret manager where possible.

  10. Use managed inference with AkashML

    AkashML provides managed hosting for supported models with a billing system based on credits. It offers two primary API bases: an OpenAI-compatible base and an Anthropic-compatible base. Authentication is handled via a Bearer token using an AkashML API key, which is distinct from Console deployment credentials.

    Key API endpoints:

    • OpenAI-compatible: https://api.akashml.com/v1
    • Anthropic-compatible: https://api.akashml.com/anthropic

    Recommended workflow:

    1. Call GET /v1/models to identify available model IDs, pricing, modalities, and context lengths.
    2. Use POST /v1/chat/completions for chat generation (supports streaming via stream: true).

    Developers should implement error handling for insufficient credits, rate limits, and unavailable backends. If a required model or runtime is not available in the managed catalog, a self-managed deployment should be used instead.

    # Example header for API requests
Authorization: Bearer <AkashML key>

  11. Deploy workloads and GPU applications on Akash

    The Akash marketplace supports both CPU and GPU workloads. Common deployment use cases include:

    • Web & Backend: Frontends, APIs, background workers, and databases.
    • AI/ML: Model inference, fine-tuning, training, notebooks, and AI agents.
    • Gaming/Web3: Game servers and blockchain nodes.

    Note: While Akash provides the rented infrastructure, the tenant remains responsible for application-level configuration, authentication, monitoring, and backups. Hardware availability depends on the specific provider selected.

  12. Implement high availability for Akash workloads

    To achieve production-grade availability on Akash, implement the following strategies:

    • Avoid Single-Provider Reliance: Multiple replicas within a single provider do not protect against that provider's failure.
    • Multi-Provider Strategy: Deploy separate leases across different providers and implement your own traffic routing and data replication strategy.
    • Operational Requirements: Ensure you have application health monitoring, a consistent funding plan, recovery procedures, and external backups.