10. Running your own GPUs

A blueprint is a proven recipe: engine, flags, install script, readiness probe. An instance is one blueprint running on one rented GPU.

curl "$BASE/v1/blueprints" -H "Authorization: Bearer $KEY"
curl "$BASE/v1/gpu-offerings" -H "Authorization: Bearer $KEY"
curl "$BASE/v1/launch-estimate?blueprint=qwen38_sglang_bf16&provider=runpod&gpu_sku=NVIDIA%20H200" \
     -H "Authorization: Bearer $KEY"

launch-estimate returns the hourly cost and the measured cold start, not a guess. provider is required.

curl -X POST "$BASE/v1/instances" \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "blueprint": "qwen38_sglang_bf16",
    "provider": "runpod",
    "gpu_sku": "NVIDIA H200",
    "policy": {"idle_shutdown_min": 30, "cost_cap_cents": 500}
  }'

Returns 202 with an instance_id. Poll GET /v1/instances/{id} until state is ready; the model then appears in /v1/models and is callable by name — the Blueprint's model path (Qwen/Qwen3.8-27B) unless you set public_model_name on the launch, which is then the name your code sends.

Where the pod lands

Every launch is placed by the platform placement policy: a vetted-tier host, an ordered datacenter chain (EU first, then North America; never Iceland or Asia-Pacific), and bandwidth floors of 1,000 Mbps down / 100 Mbps up. The floors are not cosmetic — a 51 GB checkpoint on a 1 MB/s host can never finish inside the readiness budget, and the provider's own host filter is the only thing that rules such a host out before it bills.

Plans with the placement_override feature (enterprise, or any tenant granted it) may steer placement per launch:

  -d '{
    "blueprint": "qwen38_sglang_bf16",
    "provider": "runpod",
    "gpu_sku": "NVIDIA H200",
    "placement": {
      "data_center_ids": ["EU-FR-1", "EU-NL-1", "US-TX-3"],
      "country_codes": ["FR", "NL", "US"],
      "gpu_type_ids": ["NVIDIA H200", "NVIDIA H200 NVL"],
      "cloud": "secure",
      "min_download_mbps": 2000,
      "min_upload_mbps": 200,
      "min_disk_bandwidth_mbps": 500
    },
    "policy": {"cost_cap_cents": 500}
  }'

Every field is optional and an unset field inherits the policy. Datacenter ids are validated against the provider's accepted set at request time — a bad one is a 400 naming the accepted ids, not a failed instance ten seconds later. cloud: community is refused unless the operator has enabled it platform-wide. Without the feature, a non-empty placement is refused with 403 auth.forbidden; region (a single datacenter id, the older shorthand for placement.data_center_ids) is always accepted.

tags is attribution metadata only. It never steers the pod.

Lifecycle: requested → provisioning → installing → warming → ready, then draining → stopped.

Always set cost_cap_cents. Idle shutdown works (a pod that serves nothing for idle_shutdown_min drains itself), but it cannot fire before the pod is ready, and a launch that stalls is billing the whole time. The cost cap is the backstop that covers every phase.

Sample GPU pricing (RunPod, scraped hourly):

Concurrent instances are capped by your plan. Exceeding it returns 429 with {"kind":"max_concurrent_instances","current":N,"ceiling":M}.