computing-provider-v2

README

Computing Provider v2

Turn your GPU into an AI inference endpoint and join the Swan Chain decentralized computing network.

Quick Start (5 minutes)

No wallet needed. No blockchain registration. No public IP required.

Install

Every release publishes a prebuilt binary, so building from source is optional:

# Linux x86-64 (also: computing-provider-linux-arm64, computing-provider-darwin-arm64)
curl -fL -o computing-provider \
  https://github.com/swanchain/computing-provider/releases/latest/download/computing-provider-linux-amd64
chmod +x computing-provider && sudo mv computing-provider /usr/local/bin/

computing-provider version

Already installed? Upgrade in place:

computing-provider update --check   # report only, change nothing
sudo computing-provider update      # download, verify and replace the binary

update replaces the binary but does not restart the provider — a running agent stays on the old build until you restart it, which is deliberate: an agent that restarts itself mid-request drops that request.

To build from source instead, follow the steps below.

Linux (NVIDIA GPU)

# 0. Install build tools (skip if already installed)
sudo apt-get update && sudo apt-get install -y git make
wget https://go.dev/dl/go1.22.0.linux-amd64.tar.gz
sudo rm -rf /usr/local/go && sudo tar -C /usr/local -xzf go1.22.0.linux-amd64.tar.gz
echo 'export PATH=$PATH:/usr/local/go/bin' >> ~/.bashrc && source ~/.bashrc

# 1. Clone and build
git clone https://github.com/swanchain/computing-provider.git
cd computing-provider
make clean && make mainnet && sudo make install

# 2. Download model weights from HuggingFace (e.g., Qwen 2.5 7B)
computing-provider models download Qwen/Qwen2.5-7B-Instruct

# 3. Start SGLang with the downloaded model
docker run -d --gpus all -p 30000:30000 --ipc=host --name sglang \
  -v ~/.swan/models/Qwen/Qwen2.5-7B-Instruct:/models \
  lmsysorg/sglang:latest \
  python3 -m sglang.launch_server --model-path /models \
    --host 0.0.0.0 --port 30000 \
    --served-model-name Qwen/Qwen2.5-7B-Instruct

# 4. Run the setup wizard (handles auth, config, and model discovery)
computing-provider setup

# 5. Run the provider
computing-provider run

# 7. Verify your provider is connected
computing-provider inference status

The models download command downloads model weights directly from HuggingFace. Large weight files (LFS) are verified with SHA256 hashes. The setup wizard will:

• Check prerequisites (Docker, GPU)
• Create/login to your Swan Inference account
• Auto-discover your running model servers
• Auto-match local models to Swan Inference model IDs
• Generate config.toml and models.json

macOS (Apple Silicon)

# 1. Install Ollama and pull a model
brew install ollama
ollama serve &
ollama pull qwen2.5:7b

# 2. Install Computing Provider
brew install go
git clone https://github.com/swanchain/computing-provider.git
cd computing-provider
make clean && make mainnet && sudo make install

# 3. Run the setup wizard
computing-provider setup

# 4. Run the provider
computing-provider run

# 5. Verify your provider is connected
computing-provider inference status

The setup wizard auto-discovers Ollama models and matches them to Swan Inference model IDs (e.g., qwen2.5:7b → qwen-2.5-7b).

Want to maximize earnings? The quickstart uses Qwen 2.5 7B as an example, but you are paid per token actually served. Serving other in-demand models means less competition and more requests routed to you. See the Switching Models section to get started.

---

What Happens After Setup

Once your provider is running, it goes through these stages automatically. Most providers are fully active within a day.

Connect ──▶ Benchmark ──▶ Approval ──▶ Collateral ──▶ Active
(instant)   (automatic)   (< 24 hrs)   (USD or crypto) (earning)

Stage	What happens	Time
Connect	Provider connects to the network and registers its models	Immediate
Benchmark	Automated benchmarks verify your GPU can serve the registered models	Minutes (automatic)
Approval	Admin reviews your provider	< 24 hours
Collateral	Deposit collateral to secure your position and unlock earnings (card, USDC on Ethereum or Base, or SWAN on Swan Chain)	Instant
Active	Start receiving inference requests and earning rewards	Ongoing

Grace period: New providers get a 7-day grace period after activation. During this period, benchmark failures and low uptime won't affect your routing priority, giving you time to stabilize your setup.

Check your current stage at any time:

computing-provider inference status

---

How It Works

Swan Inference (Cloud)
        │
        │ WebSocket (outbound connection - works behind NAT)
        ▼
┌───────────────────────┐
│  Computing Provider   │
│  ┌─────────────────┐  │
│  │ Your GPU Server │  │
│  │ (SGLang/Ollama) │  │
│  └─────────────────┘  │
└───────────────────────┘

1. Provider connects outbound to Swan Inference (no inbound ports needed)
2. Registers available models
3. Receives inference requests via WebSocket
4. Forwards to local model server, returns response
5. Get paid per token for completed requests (a beneficiary wallet is needed for payouts)

---

Reliability & Performance

The provider manages request flow and backend health automatically — no manual tuning is required to run:

• Health checking — each model endpoint is polled continuously; unhealthy backends are reported to Swan Inference so traffic routes away, and they recover automatically when they come back online.
• Rate limiting — GPU-aware token-bucket limits (global and per-model); over-limit requests are rejected with HTTP 429 instead of overloading your GPU.
• Concurrency control — global and per-model in-flight request slots protect the backend under burst load.
• Automatic retries — transient upstream failures (connection refused/reset, 502/503/504, timeouts) are retried with exponential backoff and jitter.
• Hot-reload — edits to models.json are picked up live via file watching; no restart needed to add, remove, or repoint a model.
• Observability — failed requests are logged with model, latency, and status code; live metrics are available via the web dashboard and a Prometheus endpoint.
• Graceful shutdown — SIGTERM/SIGINT drains cleanly, stopping the HTTP server before tearing down inference subsystems.

Rate limits and concurrency slots can be tuned at runtime via the REST API (see Useful Endpoints).

---

Prerequisites

Linux (NVIDIA GPU)

Category	Requirement
GPU	NVIDIA RTX 3090, 4090, A100, H100, or equivalent
VRAM	Minimum 16GB (24GB+ recommended)
RAM	Minimum 32GB system memory
Storage	500GB+ SSD for model weights
OS	Ubuntu 22.04+ or Debian 11+
NVIDIA Driver	535.x or newer
CUDA	12.1 or newer
Docker	24.0+ with NVIDIA Container Toolkit
Network	100 Mbps minimum (1 Gbps recommended), stable connection with low latency

macOS (Apple Silicon)

Category	Requirement
Chip	Apple Silicon M1, M2, M3, or M4
Memory	16GB+ unified memory (32GB+ recommended)
Storage	500GB+ SSD for model weights
OS	macOS 13 Ventura or newer
Software	Ollama (latest version)
Network	100 Mbps minimum, stable connection with low latency

Ports: Only outbound WebSocket connections are needed — no port forwarding or public IP required.

Install NVIDIA Container Toolkit (Linux only)

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# Verify
docker run --rm --gpus all nvidia/cuda:12.0-base-ubuntu22.04 nvidia-smi

---

Configuration

Model Configuration (models.json)

Map Swan Inference model IDs to your local inference endpoints:

{
  "qwen-2.5-7b": {
    "endpoint": "http://localhost:30000",
    "gpu_memory": 16000,
    "category": "text-generation"
  }
}

Field	Description
endpoint	URL of your local inference server
gpu_memory	GPU memory required (MB)
category	Model category (text-generation, image-generation, etc.)
local_model	(Optional) Actual model name for local server (e.g., Ollama model name)
context_length	(Optional) The real context window this backend accepts, in tokens. Set this for any backend other than vLLM or SGLang — see below

Note: The local_model field is used when your local server uses different model names than Swan Inference. For example, Ollama uses qwen2.5:7b while Swan Inference expects qwen-2.5-7b. The setup wizard handles this mapping automatically.

Context windows

The provider reports each model's real context window so the marketplace advertises what you actually serve. It is detected automatically from max_model_len in the backend's /v1/models — but that field is a vLLM and SGLang convention. Ollama, llama.cpp, LiteLLM and other OpenAI-compatible proxies expose nothing, so no window is reported and Swan Inference falls back to the catalog's theoretical value for that model. Clients then size prompts to a window your backend will reject.

Set it explicitly for those backends:

{
  "openai/gpt-5.5": {
    "endpoint": "http://localhost:8317",
    "local_model": "gpt-5.5",
    "context_length": 128000
  }
}

An explicit context_length always wins over detection. To see what each model currently reports:

computing-provider inference status

Reported context windows
----------------------------------------
  TheDrummer/Cydonia-24B-v4.3                 45056  (detected)
  openai/gpt-5.5                             128000  (override)
  Qwen/Qwen3.8-27B                                -  (not reported)

Anything showing not reported is being advertised at its catalog value, not yours. The provider also logs a warning once per model at startup.

Provider Configuration (config.toml)

Located at ~/.swan/computing/config.toml:

[API]
Port = 8085
NodeName = "my-provider"

[Inference]
Enable = true
WebSocketURL = "wss://inference-ws.swanchain.io"
ServiceURL = "https://api.swanchain.io"
ApiKey = "sk-prov-xxxxxxxxxxxxxxxxxxxx"  # Required - get from https://inference.swanchain.io
Models = ["qwen-2.5-7b"]

---

Monitoring

Self-check

The failures that cost a provider money are quiet: the daemon stays up and looks healthy while a model earns nothing. selfcheck audits for exactly that.

computing-provider selfcheck

  OK   models.json                     8 models mapped
  OK   config/models.json agreement    config.toml and models.json list the same models
  OK   Swan Inference connection       connected
  OK   registered with Swan Inference  all 8 models registered
  OK   model health                    all 8 models healthy
  OK   context window                  reported context matches every backend
 FAIL  inference probe                 openai/gpt-5.5: HTTP 401 authentication token has been invalidated
  OK   traffic                         every model has served requests
  OK   disk space                      /home/you/.swan/computing: 92.1 GB free of 438 GB (78% used)

It checks the things no error message reveals:

Check	Catches
config/models.json agreement	A model served but not advertised, or advertised but not served
registered with Swan Inference	A healthy model that was never sent upstream, so it receives no traffic
context window	A backend serving less context than you advertise — clients' long prompts get rejected
inference probe	A backend that answers health checks but cannot serve: dead engine, expired credentials
traffic	A model registered and healthy that has never been called
disk space	A volume filling before it takes the node down

The inference probe sends one max_tokens: 1 completion per model. It is the only check that exercises the engine — GET /v1/models is answered by most backends without touching it, so a dead engine or an expired API token looks healthy everywhere else.

Exits non-zero when a check fails, so it works as a cron or monitoring check. --json for machine-readable output, --no-inference to skip the completion probe.

The daemon runs the same audit every 10 minutes and acts on it: a model whose backend fails two consecutive inference probes is deregistered from Swan Inference, and re-registered automatically once it serves again. No traffic is better than traffic that fails, which is what a failing model costs your reliability score. Only backend-owned failures count — a client's over-long prompt or your own rate limit never pulls a model, and one you disabled by hand is never switched back on. Tune it under [SelfCheck]; see docs/configuration.md.

When [Alerts] is configured, a failing audit posts a webhook or email; passing runs are logged locally and not sent, so an "all clear" never trains you to ignore it.

Alerts

Set a webhook in config.toml and the provider tells you when something breaks:

[Alerts]
WebhookURL = "https://hooks.example.com/provider"

Or by email, with no receiver to run:

[Alerts.Email]
Host = "smtp.gmail.com"
Port = 587
Username = "you@example.com"
To = ["you@example.com"]

Keep the password out of config.toml — the provider reads $CP_PATH/.env at startup:

# Most providers (Gmail, Outlook, Yahoo) need an app password, not your login password
umask 077 && printf "SMTP_PASSWORD='your-app-password'\n" > $CP_PATH/.env
computing-provider alerts test             # verify before you need it

Either transport, or both. Alerts fire on a model going unhealthy, a model that passes health checks while failing most of its requests, a lost connection to Swan Inference, and a failed daily self-check — each with a matching recovery event. See docs/configuration.md for the payload and tuning.

Logging

Logs rotate under $CP_PATH/logs by default. Point them at another disk with:

[Log]
Dir = "/mnt/data/logs/cp"
MaxSizeMB = 100
MaxBackups = 5

Web Dashboard

computing-provider dashboard
# Open http://localhost:3060

The port and listen address are configurable, so you set them once rather than passing flags every time:

[Dashboard]
Host = "127.0.0.1"   # use 0.0.0.0 only on a network you trust
Port = 3060

To listen on every interface on a trusted network:

computing-provider dashboard --host 0.0.0.0

The dashboard is read-only until you choose **Unlock controls** and paste the
token from `$CP_PATH/dashboard.token`. That owner-only file is generated on
first run. Model configuration, request limits, alerts, self-check, and logging
can then be edited from **Settings**; stored secrets are never sent back to the
browser.

Features: real-time metrics, model pricing, per-transaction input/output token
usage, GPU status, model management, request controls, and validated settings.

### REST API

```bash
# View metrics
curl http://localhost:8085/api/v1/computing/inference/metrics

# List models
curl http://localhost:8085/api/v1/computing/inference/models

# Check health
curl http://localhost:8085/api/v1/computing/inference/health

Useful Endpoints

Endpoint	Description
GET /inference/metrics	Request counts, latency, GPU stats
GET /inference/metrics/prometheus	Prometheus format for Grafana
GET /inference/models	List all models with status
POST /inference/models/:id/enable	Enable a model
POST /inference/models/:id/disable	Disable a model
POST /inference/models/reload	Hot-reload models.json
GET /inference/status	Connection state, active models, and the models actually registered upstream

---

Available Models

Run computing-provider models catalog to see all supported models:

$ computing-provider models catalog
Available models in Swan Model Repository (6):

+--------------------------------------------------------+----------+-------+----------+----------------+
|                        MODEL ID                        | CATEGORY | FILES |   SIZE   |     STATUS     |
+--------------------------------------------------------+----------+-------+----------+----------------+
| Qwen/Qwen2.5-0.5B                                      |   llm    |     1 | 942.3 MB |   downloaded   |
| Qwen/Qwen3-8B                                          |   llm    |     5 |  15.3 GB | partial (3/5)  |
| Sinensis/L3.3-MS-Nevoria-70b-AWQ                       |   llm    |     8 |  13.7 GB | not downloaded |
| TheDrummer/Cydonia-24B-v4.1                            |   llm    |    19 |  43.9 GB | not downloaded |
| jeffcookio/Mistral-Small-3.2-24B-Instruct-2506-awq-sym |   llm    |     7 |   9.3 GB | not downloaded |
| meganovaai/MN-Violet-Lotus-12B-AWQ                     |   llm    |    12 |   7.8 GB | not downloaded |
+--------------------------------------------------------+----------+-------+----------+----------------+

Hardware Requirements

VRAM recommendation is roughly 2× the model file size on HuggingFace to account for KV cache and runtime overhead. Longer context lengths need more VRAM.

Model	HF Size	Recommended VRAM	Example GPU
Qwen/Qwen2.5-0.5B	1 GB	2 GB+	Any GPU
meganovaai/MN-Violet-Lotus-12B-AWQ	8.3 GB	16 GB+	RTX 4090, RTX 3090
jeffcookio/Mistral-Small-3.2-24B-Instruct-2506-awq-sym	15.1 GB	32 GB+	2× RTX 3090/4090 or A100
Qwen/Qwen3-8B	16.4 GB	32 GB+	2× RTX 3090/4090 or A100
Sinensis/L3.3-MS-Nevoria-70b-AWQ	39.8 GB	80 GB+	A100 80GB or 4× RTX 3090/4090
TheDrummer/Cydonia-24B-v4.1	47.2 GB	96 GB+	2× A100 or 4× RTX 3090/4090

---

Switching Models

You can add, remove, or swap models without restarting the provider.

1. Start the new model server

# Example: switch from Qwen 2.5 7B to Mistral Small 24B (AWQ)

# Stop the old server (optional — you can run multiple models)
docker stop sglang && docker rm sglang

# Download the new model weights
computing-provider models download jeffcookio/Mistral-Small-3.2-24B-Instruct-2506-awq-sym

# Start the new model server
docker run -d --gpus all -p 30000:30000 --ipc=host --name sglang \
  -v ~/.swan/models/jeffcookio/Mistral-Small-3.2-24B-Instruct-2506-awq-sym:/models \
  lmsysorg/sglang:latest \
  python3 -m sglang.launch_server --model-path /models \
    --host 0.0.0.0 --port 30000 \
    --served-model-name jeffcookio/Mistral-Small-3.2-24B-Instruct-2506-awq-sym

# Verify the server is healthy
curl http://localhost:30000/v1/models

2. Update models.json

Edit ~/.swan/computing/models.json to point to the new model:

{
  "jeffcookio/Mistral-Small-3.2-24B-Instruct-2506-awq-sym": {
    "endpoint": "http://localhost:30000",
    "gpu_memory": 16000,
    "category": "text-generation"
  }
}

The provider watches models.json and hot-reloads automatically — no restart needed. You can also trigger a manual reload:

curl -X POST http://localhost:8085/api/v1/computing/inference/models/reload

3. Verify

# Check the provider picked up the new model
curl http://localhost:8085/api/v1/computing/inference/models

# Check status on Swan Inference
computing-provider inference status

Tip: To run multiple models simultaneously, start each on a different port and add all of them to models.json. Use --gpus '"device=0"' and --gpus '"device=1"' to pin each model to a specific GPU.

---

Getting Paid

You are paid per token, for every request you serve. Each model in the catalog publishes a payout price per 1M input and output tokens; your earnings accrue at that rate and are shown in the Provider Dashboard and by computing-provider inference status. There is no UBI and no allocation for idle hardware — the Swan 1.0 UBI program has ended — so traffic is the only thing that earns.

Set the wallet that payouts go to:

computing-provider inference set-beneficiary 0xYourWalletAddress

Payouts are requested from the dashboard: minimum $10, flat $1 fee, one request per chain per hour. Earnings can also be converted into inference credit on the same account.

Collateral is required for activation, not optional. Deposit on-chain (USDC on Ethereum or Base, SWAN on Swan Chain) or by card; it is refundable with a 7-day waiting period.

# Get deposit instructions (chains, contracts, minimums) and check your status
computing-provider inference deposit
computing-provider inference deposit --check

Tip: computing-provider inference recommend-models ranks catalog models by current demand against your hardware — the fastest way to find traffic.

---

CLI Reference

Basic Commands

computing-provider version                   # Print the installed build
computing-provider update --check            # Is a newer release available?
sudo computing-provider update               # Install the newest release
computing-provider setup                     # Interactive setup wizard (recommended)
computing-provider run                       # Start provider
computing-provider inference status          # Check status on Swan Inference
computing-provider inference config          # Show inference config
computing-provider inference deposit         # Get collateral deposit instructions
computing-provider inference deposit --check # Check current collateral status
computing-provider inference set-beneficiary 0x...  # Set reward wallet
computing-provider dashboard                 # Web UI (port 3060)

Setup Wizard

The setup wizard is the recommended way to configure a new provider:

computing-provider setup                     # Full interactive setup
computing-provider setup --skip-discovery    # Skip model discovery
computing-provider setup --api-key=sk-prov-xxx  # Use existing API key

# Subcommands
computing-provider setup discover            # Just discover model servers
computing-provider setup login               # Login to existing account
computing-provider setup signup              # Create new account

Hardware Info

computing-provider research hardware         # All hardware info
computing-provider research gpu-info         # GPU details
computing-provider research gpu-benchmark    # Run benchmark

---

Keeping Up To Date

computing-provider version         # what you are running
computing-provider update --check  # what is available
sudo computing-provider update     # install it

update downloads the binary for your platform from the GitHub release, verifies its SHA-256 against the checksums published with the release when there are any, and replaces the executable atomically — a crash mid-update cannot leave a half-written binary where the agent used to be. sudo is needed only because the binary usually lives in /usr/local/bin.

It deliberately does not restart the provider. Restart when it suits you:

sudo systemctl restart computing-provider   # under systemd
# otherwise stop the process and run `computing-provider run` again

Releases publish a checksums.txt and a signature over it. update checks the SHA-256 automatically and refuses to install on a mismatch; to verify by hand:

sha256sum -c checksums.txt --ignore-missing

cosign verify-blob \
  --certificate checksums.txt.pem \
  --signature checksums.txt.sig \
  --certificate-identity-regexp 'https://github.com/swanchain/computing-provider/.github/workflows/release.yaml@.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  checksums.txt

The checksums prove the download arrived intact. The signature is what proves it came from the release workflow — anyone who could publish a release could rewrite the checksums to match a binary of their own, but not that signature.

Swan Inference may also mention a newer release in the message it returns when the agent registers, which computing-provider run logs verbatim at startup. That depends on the server sending it, so treat it as a convenience rather than something to rely on — update --check is what actually asks.

If a release has no binary for your platform, update says so and prints the source-build commands instead.

Troubleshooting

Error	Solution
go: command not found	Install Go 1.21+: see go.dev/dl
permission denied...docker.sock	Add user to docker group: sudo usermod -aG docker $USER
could not select device driver "nvidia"	Install NVIDIA Container Toolkit
authentication required	Set ApiKey in config.toml or INFERENCE_API_KEY env var
invalid provider API key	Verify key starts with sk-prov- and is not revoked
WebSocket connection failed	Check WebSocketURL and network connectivity
Provider not receiving requests	Check models.json matches your inference server
cuda>=12.x unsatisfied condition	Use an older SGLang tag: lmsysorg/sglang:v0.4.7.post1-cu124

Check Logs

# Provider logs
tail -f cp.log

# Inference server logs
docker logs sglang

---

FAQ

Setup & Installation

Q: make mainnet fails with go: command not found Install Go 1.22+. On Linux: download from go.dev/dl and add to PATH. On macOS: brew install go. Make sure to restart your shell or source ~/.bashrc after installing.

Q: SGLang container fails with cuda>=12.x unsatisfied condition Your NVIDIA driver is too old for the latest SGLang image. The error looks like:

nvidia-container-cli: requirement error: unsatisfied condition: cuda>=12.9, please update your driver to a newer version, or use an earlier cuda container

First, check what CUDA version your driver supports:

nvidia-smi   # Max CUDA version is shown in the top-right corner

Then either update your driver (sudo apt install nvidia-driver-550) or use an older SGLang tag that matches your CUDA version:

# For CUDA 12.4 compatible drivers
docker run -d --gpus all -p 30000:30000 --ipc=host --name sglang \
  -v ~/.swan/models/Qwen/Qwen2.5-7B-Instruct:/models \
  lmsysorg/sglang:v0.4.7.post1-cu124 \
  python3 -m sglang.launch_server --model-path /models \
    --host 0.0.0.0 --port 30000 \
    --served-model-name Qwen/Qwen2.5-7B-Instruct

Q: docker: Error response from daemon: could not select device driver "nvidia" The NVIDIA Container Toolkit is not installed. Follow the NVIDIA Container Toolkit section, then restart Docker.

Q: computing-provider setup doesn't detect my running model server The setup wizard scans common ports (30000, 8080, 11434). Make sure your model server is running before you start the wizard. You can verify manually:

curl http://localhost:30000/v1/models   # SGLang/vLLM
curl http://localhost:11434/api/tags    # Ollama

If your server uses a non-standard port, the wizard may not find it — you can manually edit ~/.swan/computing/models.json afterward.

Model Issues

Q: My provider is online but not receiving any inference requests The most common cause is a model name mismatch. The --served-model-name in your SGLang/vLLM command must exactly match the key in models.json, and that key must match a model ID registered on Swan Inference. Run computing-provider models catalog to see valid model IDs.

Q: SGLang container starts but immediately exits Check logs with docker logs sglang. Common causes:

• Out of VRAM: The model is too large for a single GPU. Use tensor parallelism to split it across multiple GPUs with --tp 2 (or --tp 4). For example, a 12B model in bf16 needs ~23 GB — too large for a single 24GB GPU once KV cache is included, but fits easily across 2 GPUs.
• Unbalanced GPU memory: If another model server (e.g., vLLM) is already using one of your GPUs, SGLang will fail with memory capacity is unbalanced. Pin SGLang to specific free GPUs instead of using --gpus all:

  # Check which GPUs are free
  nvidia-smi
  # Run on specific GPUs (e.g., GPUs 0 and 2)
  docker run -d --gpus '"device=0,2"' -p 30000:30000 --ipc=host \
    -v ~/.swan/models/YourModel:/models \
    lmsysorg/sglang:v0.4.7.post1-cu124 \
    python3 -m sglang.launch_server --model-path /models \
      --host 0.0.0.0 --port 30000 --tp 2 \
      --served-model-name YourModel
  

• Shared memory: Add --shm-size 4g to your docker run command.
• Port conflict: Port 30000 is already in use. Check with docker ps or lsof -i :30000.

Q: models download fails for Llama or other gated models Some HuggingFace models require accepting a license agreement. Visit the model page on huggingface.co, accept the terms, then set your HuggingFace token:

export HF_TOKEN=hf_xxxxxxxxxxxxxxxxxxxxx
computing-provider models download meta-llama/Llama-3.3-70B-Instruct

Connection & Authentication

Q: WebSocket connection failed or provider can't connect

• Verify the WebSocket URL in ~/.swan/computing/config.toml is wss://inference-ws.swanchain.io (not http:// or https://)
• Check that outbound port 443 isn't blocked by your firewall or cloud security group
• If behind a corporate proxy, WebSocket connections may be blocked — check with your network admin

Q: invalid provider API key or authentication required

• Your API key must start with sk-prov-. Consumer keys (sk-swan-*) won't work.
• Verify your key in ~/.swan/computing/config.toml under [Inference].ApiKey
• You can also set it via environment variable: export INFERENCE_API_KEY=sk-prov-xxx

Q: Provider is stuck in pending status Providers are auto-activated when all conditions are met: collateral deposited, GPU meets minimum hardware requirements, and registration benchmark passes. Check your status:

computing-provider inference status

If you're just testing, ask the Swan team on Discord about dev mode access which skips these requirements.

Earnings & Collateral

Q: How do I earn? Per token: input and output tokens of every request you serve, multiplied by that model's published payout price. There is no UBI or daily allocation any more — only served traffic earns. See Getting Paid.

computing-provider inference status   # Shows current stage and earnings summary

Request a payout from the dashboard once your withdrawable balance is at least $10 (flat $1 fee). Set a beneficiary wallet first:

computing-provider inference set-beneficiary 0xYourWalletAddress

Q: What are the collateral deposit options? Collateral is required before activation. Deposit via:

• Card: Stripe, through the Provider Dashboard
• On-chain: USDC on Ethereum or Base, or SWAN on Swan Chain

Run computing-provider inference deposit to see supported chains, contract addresses, and minimum amounts. Deposit via the Provider Dashboard or directly to the contract from your wallet.

Q: What happens if I fail benchmarks? The system runs periodic benchmarks (math, code, reasoning, latency) to verify provider quality. Passing resets your failure counter. Consecutive failures may result in collateral slashing (default: 10% after 2 consecutive failures).

Configuration

Q: I edited config.toml but nothing changed Make sure you're editing the right file. The provider reads config from ~/.swan/computing/config.toml (or wherever $CP_PATH points), not the config.toml in the git repo directory.

Q: How do I change models without restarting? Edit ~/.swan/computing/models.json — the provider watches this file and hot-reloads automatically. You can also reload via the API:

curl -X POST http://localhost:8085/api/v1/computing/inference/models/reload

Q: Port 8085 or 30000 is already in use Find and stop the conflicting process:

lsof -i :30000   # Find what's using the port
docker ps         # Check for leftover containers
docker rm -f sglang  # Remove old SGLang container

---

Getting Help

• Discord - Community support
• GitHub Issues - Bug reports
• Documentation - Full docs

License

Apache 2.0