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.
The CLI examples assume an authenticated MKA1 CLI.

​
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 four-step LoRA fine-tune of Qwen2.5-0.5B-Instruct, merges the adapter, and publishes the weights before the job exits. Create the output repository and artifact secret using Prepare output storage first. Save this complete workload as train-and-publish.sh beside the SDK or CLI example. The Bash and CLI tabs also require jq. The CLI runs this same script through container.command.
train-and-publish.sh
Replace YOUR_ORG/qwen-fine-tune and sec_REPLACE_WITH_ARTIFACT_SECRET with your repository and returned secret ID. The SDK tabs encode the local script. For Bash, encode it once and use jq to build the request body as shown below. This is a short workflow check, not a quality benchmark.
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.

​
Prepare output storage

Create a repository named qwen-fine-tune with Manage repositories. Use the returned organization slug in the job’s OUTPUT_MODEL_REPO. Store an API key with access to that repository as a Compute secret:
Use the returned secret ID in container.secret_env.ARTIFACT_TOKEN. The script uses a separate artifact client so public base-model and dataset downloads continue to use the public Hub. An artifact upload error fails the job.

​
Use mka1-repos for datasets and weights

Compute’s durable logs do not preserve the job’s ephemeral filesystem. The script above publishes merged weights to MKA1 repositories before returning success. Use the Hugging Face artifact tools to download them, or serve the repository. For private training inputs, download them with an explicit HfApi or snapshot_download client configured for your MKA1 artifact endpoint and token, then pass the local paths to your trainer. When ms-swift cannot infer a mirrored model’s family, set its model type and template explicitly for the model you use. This short script publishes at completion. If it is terminated earlier, its local checkpoint is lost. For longer runs, add periodic checkpoint publishing; the reinforcement learning example includes a working checkpoint callback.

​
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