Deploy a model

Bring a Hugging Face checkpoint or LoRA adapter, at any size. Boardwalk serves exactly the weights at the commit you pin, as a private API that scales from zero. Deploying is free.

1. Choose your weights

In the console, open Models → Deploy a model. Enter a repository ID and, optionally, a branch, tag, or commit. You need an owner or admin role.

Public repositories work without a connection. Connect Hugging Face to read private or gated repositories your account can access. Accept any required model license on Hugging Face first.

For repository requirements and a complete walkthrough, see Deploy a checkpoint.

2. Review the plan

Boardwalk pins the ref to an exact commit, reads the repository, and fits the model on GPU cards before anything is copied. Give the model a name, review the serving settings, and click Deploy. Each setting has a default.

Setting	What it controls
Engine	vLLM or SGLang, and its release. Default: vLLM.
Cards	The card class (H100, H200, B300, or a slice of one) and a replica of 1, 2, 4, or 8 cards. Default: the least expensive shape that fits.
Max context	Prompt and output tokens per request, up to the model’s own window. Default: the whole window. Boardwalk never narrows it to fit: a window that does not fit is refused with the longest one that does.
YaRN	A factor that extends the window past the one the model shipped with, as its publisher documents it. Default: off.
KV cache	The checkpoint’s own precision, or FP8, which fits more context on a card.
Speculative decoding	A method and, for a draft model, the Hugging Face repository it comes from. Default: off.
Hold	How long a card stays with the model after its last request: 1 to 300 seconds, billed as GPU time. Default: 5.
Engine settings	Any of the engine’s flags, one `name=value` a line. Default: the engine’s defaults, with a 2,048-token prefill chunk.

Engine settings

How the engine computes is yours. Set any flag of vLLM 0.27.1 or SGLang 0.5.19, one name=value a line, without its dashes.

max-num-seqs=64
max-num-batched-tokens=8192
enable-prefix-caching=true
attention-backend=FLASHINFER
speculative-config={"method": "ngram", "num_speculative_tokens": 4}

That covers the scheduler, prefix caching, the KV cache, attention and MoE kernels, CUDA graphs and compilation, expert and context parallelism, prefill and decode on separate cards, speculative decoding, and the reasoning and tool-call parsers (none turns one off).

The engine judges the values: a deploy whose settings it refuses fails with the engine’s own error. Boardwalk refuses, with the reason, only a flag that runs code other than the engine’s, sizes GPU or host memory, names the weights, reaches past your engine, or belongs to the API or to logs. No flag is accepted and ignored. Compare two configurations by calling each revision as name@revision.

What deploys

Base models and full fine-tunes, dense or MoE, from 1B to 1T parameters.
Any standard format, served as published: bf16, FP8, INT4, NVFP4, MXFP4, AWQ, GPTQ, and compressed-tensors. To serve a quantized model, deploy a quantized checkpoint.
LoRA adapters, on your own copy of their base (see adapters).

A deploy Boardwalk cannot serve is refused with the reason and what to change:

Custom tokenizer code that no standard tokenizer reproduces exactly. Deploy a checkpoint whose tokenizer.json stands on its own.
An architecture the engine does not implement. Repository code never runs on a GPU host.
Weights that do not fit with one max-context request on eight cards of the largest class: choose a smaller context, FP8 KV cache, or a quantized checkpoint.

LoRA adapters

Point at a repository with adapter_config.json. Boardwalk reads the base it names, stores your own copy of that base once, and serves each adapter as its own model with its own name, hold, and receipts. Adapters on one base share its copy in host memory, so each adds only its own bytes.

adapter_config.json
adapter_model.safetensors

3. Let Boardwalk check it

The deployment page tracks each stage. You can leave the page and return to the same run.

Stage	What happens
`screening`	Reads the repository at the pinned commit and fits it on cards: license, engine support, and the weights plus one max-context request. A repository that ships its own tokenizer code has it run once in an isolated sandbox with no network, exported to a standard `tokenizer.json`, and checked to give identical token ids and text over a fixed corpus.
`ingesting`	Copies the checkpoint’s files into Boardwalk’s store and records each file’s SHA-256.
`probing`	Boots the engine once on free cards to measure its memory layout. Only a configuration no earlier deploy has measured needs this step.
`staging`	Pins the copy in a host’s memory, ready to swap onto a card.
`checking`	Sends one request through the engine. It must generate, and the engine must count the prompt exactly as the checkpoint’s tokenizer does.
`activating`	Points the model name at the checked revision, once it is warm.

Deploying is free, including the check request. Boardwalk does not benchmark or evaluate your model; its quality is yours, and the check proves only that it serves exactly. A failed deploy stops with the reason in the run log, and nothing it tested goes live. Large weights take longer to copy and stage.

4. Call your model

Copy the Call as value from its model page. For a private deployment, this is the name you chose, such as support-agent.

curl https://api.boardwalk.cloud/v1/chat/completions \
  -H "Authorization: Bearer $BOARDWALK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"support-agent","messages":[{"role":"user","content":"Hello"}],"max_tokens":1024}'

Update a deployment

Redeploy from the model page to make a new revision of the same name. Give a branch, tag, or commit, or Boardwalk reads the repository’s main branch again. Serving settings carry over unless you change them. A deployment never follows later pushes to its Hugging Face repository on its own.

Action	What happens
Redeploy	The new revision warms where the live one serves, then the name moves to it. Requests in flight finish on the old revision. No caller sees a cold start.
Redeploy with Move callers once it is warm off	The revision stops after its check. Call it as `name@revision`, then promote it when you are ready.
Promote	Moves the name to another checked revision, after it warms.
Roll back	Moves the name to an earlier revision at once.

curl https://api.boardwalk.cloud/v1/chat/completions \
  -H "Authorization: Bearer $BOARDWALK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"support-agent@0123456789abcdef0123456789abcdef01234567","messages":[{"role":"user","content":"Hello"}]}'

Your deployment is private to your organization, even when its source is public. Use revision pins when you need a specific served weight commit.

A deployment bills the GPU time its cards are held, not tokens; see pricing for credits and billing, and how serving works for where your model runs.

Link to a deploy from your model card

https://app.boardwalk.cloud/deploy?repo=owner/name opens the deploy form with that repository filled in, after sign-in if needed. Add &ref= to pin a branch, tag or commit. Put it on your Hugging Face model card so anyone can serve your weights:

[![Serve on Boardwalk](https://www.boardwalk.cloud/badge/serve-on-boardwalk.svg)](https://app.boardwalk.cloud/deploy?repo=owner/name)