Skip to main content
Use a Compute job when you need GPUs for a finite workload such as fine-tuning. You bring an ordinary container image and a command; Compute allocates GPU capacity, runs the workload to completion, streams durable logs, and deallocates the hardware automatically. Compute has no fine-tuning schema. A job is a generic container run, so this guide fine-tunes with ms-swift purely as workload payload — any training stack works the same way.
This guide rents GPUs and runs your own training container. For the managed fine-tuning API that trains platform models from uploaded JSONL files, see Fine-tune a model.

​
Before you start

You need: Jobs move through requested → allocating → provisioning → running → finalizing, then land in a terminal state:
  • A workload that exits 0 ends as succeeded; a failure in any phase ends as failed.
  • Explicit termination, a binding limit, or an exhausted organization budget moves the job through terminating to terminated.
Billing starts at allocation, not readiness.Spend accrues from the moment hardware is allocated, so provisioning time and failed boots cost money. Set limits.max_runtime_hours and limits.max_cost_usd on every job; a job that hits a binding limit is terminated and deallocated immediately.

​
Step 1 - Pick an accelerator

List the curated accelerator catalog and choose one by its stable name.
Each entry describes the hardware, the GPU counts you can request, and the interconnects it supports:

​
Step 2 - Check price and availability

Optionally request a quote before creating anything. A quote is a live observation of the market: it returns whether the configuration is currently obtainable and the hourly price range, and it reserves nothing.
An unavailable configuration is still a 200 response, with available: false and null price bounds.

​
Step 3 - Create the job

Create the job with a required Idempotency-Key header. Retrying with the same key and the same body returns the same job with a 200 instead of creating a duplicate; the same key with a different body returns 409 idempotency_conflict. This example runs a small LoRA fine-tune of Qwen2.5-0.5B-Instruct and merges the adapter, matching the platform smoke test:
Field notes: Why capacity_optimized is the default: billing starts at allocation, so the cheapest offer is not the cheapest outcome when the machine is slow to start or never reaches the workload. Choose lowest_cost when the quoted rate matters more than time-to-start. The response is 201 with the durable job in state requested:
Creation succeeding means the request was accepted, not that capacity exists. Capacity exhaustion, provider errors, and bootstrap failures surface later through state, reason, logs, and events — never as an HTTP error on a create that already returned 201.

​
Step 4 - Poll until it finishes

While running, the job reports the hardware it actually obtained, the hourly price captured at allocation, spend so far, and a ready-to-use SSH command if you supplied a key:
When the workload exits 0, the job moves through finalizing to succeeded, exit_code is recorded, the provider resource is deallocated automatically, and spend stops accruing. A non-zero exit ends in failed with a reason explaining why. Terminal jobs stay readable for audit and usage.

​
Step 5 - Read logs and events

Logs are durable and cursor-paginated, and they distinguish your workload’s output from system output.
Use source=system for allocation and bootstrap output, and order=asc (the default) to page oldest-first. Lifecycle transitions such as provider_allocated, workload_started, and workload_exited are also available as structured events:

​
Step 6 - Stop a job early

Termination is explicit, idempotent, and returns the current resource.
There is no DELETE: the record is retained for audit, usage, and reconciliation. A job that hits limits.max_runtime_hours, limits.max_cost_usd, or an organization budget is terminated the same way, with no grace period and no partial-result guarantee, so publish artifacts from inside the workload before it exits.

​
Use mka1-repos for datasets and weights

Compute stores no workload artifacts. The golden path is mka1-repos, the platform’s Hugging Face-compatible repository service for models and datasets: your job pulls the dataset from it and publishes the merged weights back to it, all from inside the workload. This is the same Hugging Face access you use from your own machine — see Manage repositories. ms-swift with USE_HF=1 speaks that protocol, so --model and --dataset take <org>/<name> references directly and no code changes are needed. Three environment values make this work. Compute treats them as ordinary environment variables — it is the Hugging Face tooling inside your container that reads them, and by these exact names:
  1. HF_ENDPOINT points at the artifact endpoint for your cluster. Hugging Face-compatible tooling — huggingface_hub, ms-swift with USE_HF=1, vLLM — resolves <org>/<name> identifiers against it, so workloads reach mka1-repos without any code changes. The console pre-fills it when you create a workload; set it yourself when you call the API directly, or point it elsewhere to pull from a different hub.
  2. mka1-repos authenticates with your MKA1 API key. Store the key as a Compute secret and inject it as HF_TOKEN through secret_env, so it never appears inline in the job spec.
  3. Set HF_HUB_DISABLE_XET=1 when uploading weights. Current huggingface_hub releases can select the Xet transfer path automatically, while mka1-repos supports the standard Hub/LFS upload path. Disabling Xet keeps HfApi.upload_folder and hf upload on the supported path.
Create the secret once:
Secret values are write-only; the response returns only the id and key names:
Then write the workload as a script that trains from your dataset repository and publishes the merged weights. This example continues training meetkai/functionary and publishes back to it, so each run builds on the last.
HF_ENDPOINT redirects every Hugging Face lookup in the workload, so identifiers from the public hub no longer resolve while it is set. To fine-tune from a public base model, mirror it into a repository of your own first, or leave HF_ENDPOINT unset and pull from the public hub instead.
--model_type and --template are required whenever the base model comes from a repository rather than the public hub. ms-swift matches both by upstream model name, and weights pulled from your own repository arrive as a local directory that carries no such name, so it cannot infer either and stops with Failed to automatically match. The two failures arrive one after the other — model_type first, then template — and both land after the image pull and the training run, so a missing flag costs a full billable run each time. Both values must match your base model; ms-swift’s supported models list gives the pair for each family, and the error message names the candidates it could not choose between.
train-and-publish.sh
Encode it with base64 < train-and-publish.sh and reference the secret in the create body:
When the job succeeds, the merged weights are downloadable from meetkai/functionary by anyone in your organization, and a Compute service can serve them directly — see Deploy a model server.
A mid-run termination destroys any work not already published. Publishing from inside the workload, as above, is the supported checkpointing mechanism in this version.

​
Track spend

Every job response carries accrued_usd, and the usage endpoint aggregates spend across resources for a time window:
Billing is metered in whole minutes per resource, and Compute spend draws from the same organization budgets as every other MKA1 service.

​
API reference

For the full request and response schemas, open the Compute groups in the API Reference.

​
See also