Install iwant and launch a model on GCP

Install iwant locally, connect your cloud account, and preview a model’s GPU request before provisioning. GCP is the currently supported cloud. The steps below use gpt-oss-20b on one L4; choose a model deployment guide for the hardware and serving details of another checkpoint.

You need the gcloud CLI, a GCP project with billing enabled, and quota and available capacity for the model’s GPUs. A working login alone does not establish those prerequisites.

Install the CLI

The upstream installer  installs iwant in ~/.iwant and puts the command in ~/.local/bin:

curl -fsSL https://raw.githubusercontent.com/narevai/iwant/main/install.sh | bash
iwant --help

If the shell cannot find iwant, add ~/.local/bin to your PATH and retry. The installer sends an anonymous install event. To opt out, use this installation command instead:

curl -fsSL https://raw.githubusercontent.com/narevai/iwant/main/install.sh -o /tmp/iwant-install.sh
IWANT_NO_TELEMETRY=1 bash /tmp/iwant-install.sh

For a source installation with Python 3.10 or later:

git clone https://github.com/narevai/iwant.git
cd iwant
pip install -e .

Connect your cloud account

GCP setup

Install the Google Cloud CLI , replace YOUR_PROJECT_ID, then run:

gcloud config set project YOUR_PROJECT_ID
gcloud auth login
gcloud auth application-default login
iwant auth

iwant checks cloud access through SkyPilot. Confirm it reports GCP as enabled. Check GPU quota in the selected project and GPU locations  for the accelerator you need. Capacity can still be unavailable despite sufficient quota.

Cloud account setup belongs here; the model guides describe the serving configuration. Only GCP is documented as supported today. SkyPilot’s wider provider coverage does not by itself establish iwant support for another cloud.

Preview, then launch once

This preview does not rent a GPU:

iwant up gpt-oss-20b --infra gcp --dry-run --yes

Inspect the planned machine, region, storage, and setup. Check current cloud pricing for that plan; this guide does not quote an hourly rate. Launch when those resources match your budget:

iwant up gpt-oss-20b --infra gcp --yes

--yes skips the CLI’s interactive pickers. With these flags, the launch uses on-demand capacity. To select a region, replace --infra gcp with --infra gcp/YOUR_REGION. To request reclaimable spot capacity, add --spot to your chosen launch command. Treat these as alternative launch settings, not commands to run consecutively on new VMs.

Omitting the model with iwant up opens an interactive picker. For scripts, provide the slug and --yes. See upstream launch options  and iwant up --help for the full interface.

Authenticate model downloads

When authentication is needed, set a Hugging Face token in the same shell before launching. This keeps the value out of the command you type:

read -rsp 'Hugging Face token: ' HF_TOKEN
printf '\n'
export HF_TOKEN

The bash example prompts without echoing the token. Granted access to a gated repository is still required. iwant reads HF_TOKEN and passes it to the instance and forwards it into the serving container when needed. Remove the local variable with unset HF_TOKEN after submitting the launch if you no longer need it.

Connect to the model API

Wait for the server-ready message. Launch output prints a Server URL ending in /v1 and an API key. Copy those values into your shell; the CLI does not export environment variables for you:

export OPENAI_BASE_URL="http://YOUR_SERVER_IP:8000/v1"
export OPENAI_API_KEY="YOUR_LAUNCH_API_KEY"
 
curl -fsS "$OPENAI_BASE_URL/models" \
  -H "Authorization: Bearer $OPENAI_API_KEY"

Expect a JSON data array with served model IDs. For the gpt-oss-20b launch, send:

curl -fsS "$OPENAI_BASE_URL/chat/completions" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"openai/gpt-oss-20b","messages":[{"role":"user","content":"What is 2 + 2? Answer briefly."}],"max_tokens":256}'

Check choices[0].message and token usage in the response. If generation ends with finish_reason: "length", it hit the output cap and may have spent it on reasoning before completing an answer. For another model, follow its deployment guide and use the ID returned by /models; Step uses an alias rather than its Hugging Face path.

Use the same base URL, key, and model ID in an OpenAI-compatible app. A healthy models endpoint is the CLI’s readiness check, not a test of chat quality, tool calling, or throughput.

Troubleshoot a launch

Authentication succeeds but provisioning fails

Check the project selected by gcloud, its billing status, GPU quota, and regional accelerator availability. Use the provider error to distinguish missing permissions or quota from unavailable capacity. Preview another suitable region before launching there. See the GCP setup steps.

The server is still loading or its job failed

Provisioning, checkpoint download, and engine startup are separate stages. Keep the streamed logs visible on a first launch. If the CLI reports a failed job, use the sky logs CLUSTER JOB_ID command it prints. If startup is still progressing, inspect the current cluster rather than launching a second copy:

iwant list
iwant ssh EXACT_CLUSTER_NAME

Replace the placeholder with the cluster from a successful status lookup. Check the model guide for storage capacity and runtime requirements.

The models request returns an authentication or path error

Copy the API key from the same launch as the URL and send it as a bearer token. Use the Server URL including /v1 exactly once: the request appends /models, not /v1/models. If the server responds but cannot find a chat model, use its returned data[].id rather than guessing a checkpoint alias.

You interrupted the CLI or a launch failed

Ctrl+C stops local waiting or log streaming; the remote work can continue. Run iwant list and inspect the existing cluster before retrying. A stopped or failed server does not prove its VM was removed. If the status lookup itself fails, restore access and check the cloud console rather than interpreting the error as an empty resource list.

Billing and teardown

Remove the cluster explicitly when finished:

iwant list
iwant down EXACT_CLUSTER_NAME
iwant list

Replace EXACT_CLUSTER_NAME with the name returned by iwant list. In an interactive terminal, iwant down without a name opens a picker. Confirm removal in a successful final status response; if removal or status fails, check the cloud resources directly.

The upstream lifecycle documentation  explains that the default 30-minute idle timer tracks cluster jobs, not incoming API requests. A running server can keep the cluster active even when nobody sends a prompt. --idle-minutes N changes that timer and --no-autostop disables it; neither replaces cleanup after an experiment.