Deploying a model

Point Boardwalk at a Hugging Face repository and we serve it: same API, same metering, same receipts as the first-party catalog. Deploying is free — you pay nothing until someone actually runs tokens through the model.

Two ways to deploy

We detect which one you have from the repository's files; there is nothing to choose.

  • A full checkpoint gets its own serving endpoint. It scales to zero when idle, so the first request after a quiet spell pays a cold start.
  • A LoRA adapter is served from a shared pool of its base model alongside other adapters. Nothing new is provisioned, and a busy pool is much more likely to be warm when your request arrives — if your fine-tune is a LoRA, deploy the LoRA.

Before you deploy

  • You need an organization role of owner or admin; members can view models but not deploy them.
  • A public source repository needs no Hugging Face account link. For a private repository, connect your Hugging Face account in console settings first so we can read it.
  • Start from Models → Deploy a modelin the console. Paste the repository id, and the preview shows exactly what we found and what we will serve — or, if we can't serve it, the specific reason and a remedy. A refusal costs nothing.

Checkpoints

What we can serve, stated up front rather than discovered at boot:

  • Architectures: qwen2, qwen3, llama, mistral, gemma2, gemma3, phi3, and smollm3 families.
  • Weights must be safetensors. Repositories that require custom modelling code (auto_map) are refused.
  • The model must fit a single GPU with room for at least 4,096 tokens of KV cache. The preview shows the context-length options that fit; you pick one at deploy time.
  • Private repositories work: we copy the serving files (up to 12 GiB) into our storage, and the worker boots from that copy — your Hugging Face token never reaches a worker. Gated repositories are refused; deploy a LoRA of the gated base instead.

Longer context is a real trade: it leaves less room for concurrent requests, so the benchmark measures lower throughput and the derived price comes out higher. The wizard shows this choice before you commit.

LoRA adapters

An adapter deploys in seconds of setup and serves from its base model's shared pool. These bases have a pool standing ready, pinned at the exact commits we serve:

BasePinned commit
Qwen/Qwen3-0.6Bc1899de289a04d12100db370d81485cdf75e47ca
Qwen/Qwen3-1.7B70d244cc86ccca08cf5af4e1e306ecf908b1ad5e
Qwen/Qwen3-4B1cfa9a7208912126459214e8b04321603b3df60c

An adapter of any other supported base also works: we stand up a pool for that base as part of your deploy, which takes as long as a checkpoint deploy the first time. The base must be publicly readable — pool workers hold no tokens.

The adapter itself must be:

  • PEFT type LORA, in safetensors, with rank ≤ 64, targeting attention and MLP projection modules only, and no modules_to_save.
  • Trained against the exact base commit we serve. We read it from adapter_config.jsonwhen your training run recorded it; otherwise state it in the wizard's base-revision field.
  • Tokenizer-identical to its base. An adapter that ships a diverged tokenizer is refused rather than served subtly wrong.

Qualification

Every deploy is qualified before it can serve: we boot it, stream a completion and check the usage frame arrives, verify /v1/tokenizeagrees with the metered prompt count, and benchmark it under concurrent load. You watch each step live on the model page, and a failure names the step that failed. Qualification is free and typically takes a few minutes; the model serves nothing until it passes, and the result is published on the model's page as its verification record.

How your model is priced

Prices are measured, not chosen. From the benchmark's throughput and the GPU's hourly cost we derive the output price (floored at $0.02 per million tokens); input is half the output price, cache reads a tenth of input, cache writes $0. The four prices are published on /v1/modelslike every catalog model's, and every request gets a receipt against them.

Visibility & limits

  • A model is public (listed on /v1/models for the whole world, callable by anyone with credits) or private(invisible and callable only by your org; anyone else gets the same 404 as a model that doesn't exist).
  • A private source repository forces the model private. Each org can have up to 5 private models; public deploys are uncapped.
  • A model with billed usage can be disabled but not deleted — its receipts are money records and they stay resolvable.

Updates from Hugging Face

While your Hugging Face account stays connected, we watch the source repository. A commit that changes weight files cuts a new revision at the new sha and qualifies it from scratch; the old revision keeps serving until the new one passes. Documentation-only commits change nothing. Every revision change is visible on the model page — never a silent swap.

Calling your model

Your model's id is <org-slug>/<name>. The name is fixed at deploy time; pin an exact revision with @<hf_revision> like any catalog model.

shell
curl https://api.boardwalk.cloud/v1/chat/completions \
  -H "Authorization: Bearer $BOARDWALK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "your-org/your-model",
    "messages": [{"role": "user", "content": "Say hello in five words."}]
  }'