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: 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. Two platform conventions make this work:
  1. Compute always injects HF_ENDPOINT into every workload, pointing at the artifact endpoint configured 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. You cannot override HF_ENDPOINT yourself.
  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.
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:
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 acme/qwen2.5-0.5b-support 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