Skip to main content
A deployment is a running model you can call over an OpenAI-compatible API. You can deploy a model you fine-tuned on Valkyrie, or any Hugging Face model directly, no fine-tuning required. Deployments appear on the Endpoints screen, each with a Base model or Fine-tuned pill.

​
Deploy a base model

A base model is served as it is, with no fine-tune.
1

Open Deploy a base model

In the dashboard, go to Endpoints and click Deploy a base model. You can also get there from Home (“No fine-tune needed? Deploy a base model as it is”) or from the Models list.
2

Pick the model

Choose a preset (for example, a Qwen chat model) or enter any Hugging Face model path in owner/name form. See Model names.
3

Pick the hardware

Under Hardware, pick Small, Medium, or Large instead of a specific GPU. Valkyrie rents the cheapest card in that size that holds the model. Choose a specific card opens the full card list and the Number of cards. See Hardware sizes.
4

Check the configuration

The form shows an estimate for the machine Valkyrie would pick: the hourly cost (GPU plus storage), how long it should take to get ready, and what the disk costs per day while paused. Under the advanced settings you can pick the serving engine, the disk size, and, where it’s offered, interruptible capacity.
5

Choose when it runs

Office hours, Pay as you go (stops after 30 minutes to 24 hours without requests), Until stopped, or Keep always on. See Always-on and idle stop.
6

Launch and wait for Running

Valkyrie takes the deployment through a series of stages and it’s only ready to use once it reaches Running:
Preparing means the machine is up and the runtime and model files are being set up.
If a deployment is still starting after 25 minutes, the dashboard shows Taking longer than usual. If its machine never becomes reachable, Valkyrie stops it automatically about 20 minutes after it comes up, with an error that explains why, so you are not billed for a machine you cannot use.

​
Deploy a fine-tuned version

1

Open the version

On Models, select your model and click a completed version.
2

Click Deploy

This opens the version’s deploy page.
3

Pick the serving settings

Under Hardware, pick Small, Medium, or Large, see Hardware sizes. A fine-tuned version always needs at least 24 GB of memory per card. Choose a specific card opens the full card list with the price per hour of each card. Choose the Engine: vLLM (recommended) or Ollama. Advanced lets you set the context length, memory use, and an optional cluster name. The disk is sized from your trained weights, see Disk size.
4

Choose when it runs

Office hours, Pay as you go (stops after 30 minutes to 24 hours without requests), Until stopped, or Keep always on. See Always-on and idle stop.
5

Check the cost and deploy

The Summary shows the model, the chosen card, the engine, and Cost while running per hour, billed from your wallet while the endpoint runs. Click Deploy endpoint. You land on the new endpoint’s page, where you can follow it to Running.
Valkyrie loads your trained weights or adapters onto the serving engine the same way as a base model. Once deployed, the version’s page on Models links to its running endpoint.

​
Hardware sizes

Both deploy pages ask for a size, not a GPU. Each size is a range of GPU memory per card:
  • Each size shows the price range per hour of its cards that can hold the model.
  • A size rents the cheapest card in its range that holds the model. The line under the sizes names it, for example Rents L4, the cheapest card in this size that fits the model.
  • A size whose cards can’t hold the model reads Too small for this model. and can’t be picked. One with no cards on offer reads No cards available right now.
  • Choose a specific card opens the full card list, with the price per hour of each card, for when you want a particular GPU. On the base model form it also shows Number of cards, and the sizes then count the model’s memory split across that many cards.
  • On the deploy page for a fine-tuned version, the model always needs at least 24 GB per card, and the page opens on the smallest size that holds it.

​
Model names

A model to deploy or fine-tune is named by its Hugging Face repository id, in owner/name form, for example Qwen/Qwen2.5-7B-Instruct:
  • Each part is 1 to 96 characters: letters, digits, -, _, and ..
  • A part can’t start or end with - or ., and can’t contain -- or ...
  • The name can’t end in .git.
Anything else, such as a full URL or a name without an owner, is refused before a GPU is rented, with the message model name must be a Hugging Face repo id ‘owner/name’. Ollama models, which don’t come from Hugging Face, are the exception.

​
Serving engines

The engine runs your model on the GPU and serves the OpenAI-compatible API.
  • vLLM (recommended) and Ollama serve both base models and fine-tuned versions.
  • A few more engines are offered for base models only, for example for quantized model formats.
The Serving engine list under the deploy form’s advanced settings always shows the engines Valkyrie currently supports. The deploy page for a fine-tuned version offers vLLM and Ollama. Agents and scripts can read the same list from GET /api/runtimes.

​
Disk size

The machine’s disk has to hold the model weights plus the serving engine.
  • Fine-tuned versions: Valkyrie sizes the disk from the weights your fine-tune produced: about 1.2 times their size plus room for the serving engine, and at least 60 GB. Ollama keeps two copies of the model, so its disk is sized for twice the weights. Versions trained before Valkyrie recorded weight sizes get 256 GB.
  • Base models: the deploy form has a Disk Size (GB) field. From the API or MCP, leave disk_size out and Valkyrie sizes the disk from the model the same way, or uses 256 GB if it can’t read the model’s size.
A disk smaller than the model’s weights is refused before a GPU is rented, with the size to use instead.

​
Before a GPU is rented

Before renting anything, Valkyrie checks the deployment: the model name, the configuration, and that the Hugging Face repository has weight files the engine can load. A deployment that fails these checks is refused with Runtime preflight failed and costs nothing. Agents can run the same checks on their own with dry_run on the MCP deploy_base_model tool. Valkyrie then picks a machine. By default it weighs each machine’s hourly price against how long it’s likely to take to download your model and get ready, so a slightly dearer machine that is ready in minutes can win over a cheap, slow one. It skips machines with a poor reliability record and machines that recently failed to start a model. If no machine passes for the GPU you picked, the deployment fails with a message saying why; try again later or pick another GPU type. See Deployment status and failures.

​
Call your deployment

Once ready, the deployment exposes an OpenAI-compatible endpoint at its default, non-guessable URL (a random public id, so it’s never a guessable sequential number):
If you’d like a friendlier, memorable URL, add an alias (optional at deploy time, or any time after):
See Run inference for full request examples, and Aliases to add or re-point one. To try a deployment before you write any code, chat with it in the Playground.
A fine-tuned deployment serves its model as fine-tuned-<job id>. You do not need to match that name exactly: requests sent to the deployment’s URL reach your fine-tuned model whatever model name the client sends.

​
Managing a deployment

Open a deployment from Endpoints to operate it over its whole lifecycle. The actions are in the endpoint’s menu:
Idle deployments keep a GPU running and cost money. A deployment that serves no requests for 2 hours is stopped automatically unless it’s always on. Use stop, pause, or a schedule so you only pay while the model is in use. See Wallet & billing.
If something goes wrong, the deployment’s page shows what failed and the next step. See Deployment status and failures.

​
Access and API keys

A deployment is called with an API key. Deployment API keys are prefixed vk_dep_ and belong to the workspace they were created in. You can share a deployment with members and teams of your workspace and manage who holds keys against it from the Access tab on its page. See Share a model.