Skip to main content
Use a Compute service when you need GPUs for a persistent workload such as model serving. A service is the same generic container run as a job, plus named ports, an optional readiness probe, and a public endpoint — Compute has no deployment or model schema, so this guide serves with vLLM purely as workload payload. GPU services run on external GPU providers, and CPU services run in the MKA1 cluster. This guide’s example requests a GPU, so it runs on an external GPU provider. The two placements protect endpoints differently; see Endpoint access. This example creates a single persistent model server. Keep its process in the foreground and terminate the service when finished. Some placements also support the public service.scaling and volume fields; support depends on the selected backend. Do not assume every external GPU provider supports shared storage or dynamic replicas. The CLI examples assume an authenticated MKA1 CLI.

Before you start

You need: Services move through requested → allocating → provisioning → ready, and stay there until something ends the run:
  • A failure in any phase, including the workload exiting after ready, tears down through terminating into failed.
  • Explicit termination, a binding limit, or an exhausted organization budget ends in terminated instead.
With a readiness probe, ready means the probe passed. Without one, it only means the workload launched; it makes no application-level health claim, so declare a probe whenever the image offers a health route.
Billing starts at allocation, not readiness.Spend accrues from allocation until the service reaches a terminal state, including all provisioning and model-loading time. A service never completes on its own — terminate it when you are done, and set limits as a backstop.

Endpoint access

A service’s placement decides who authenticates requests to its endpoints. MKA1 cluster endpoints are always authenticated by the MKA1 API gateway. Send an MKA1 API key of the organization that owns the service, holding the admin-only read:compute scope. A request without a valid key gets 401. A key that lacks read:compute, or that belongs to another organization, gets 403. The API gateway strips the Authorization header and cookies before forwarding a request, so your container never receives a caller’s credential. Do not configure the serving runtime to require a key of its own. External GPU provider endpoints are reachable at the provider’s URL, with no MKA1 authentication in front of them. Protect them with the serving runtime’s own key, as this guide does with VLLM_API_KEY.

Step 1 - Store the endpoint key as a secret

Pass the workload API key through secret_env, not inline in the command, so it never appears in provider pod specs. Skip this step for a CPU service: the MKA1 API gateway authenticates its endpoint.
Secret values are write-only. Keep the returned sec_... id for the create body, and the key value itself for your clients.

Step 2 - Create the service

Create the service with a required Idempotency-Key header, exactly as for jobs. This example serves Qwen2.5-0.5B-Instruct with vLLM’s OpenAI-compatible server, matching the platform smoke test:
Field notes: As with jobs, 201 means the request was accepted; capacity and provisioning problems surface afterwards through state, reason, logs, and events.

Step 3 - Wait for ready

Model download and load happen inside the workload, so expect minutes of provisioning before the readiness probe passes. A ready service carries its public endpoints:
If the service lands in failed instead, read reason, then GET .../logs?source=user for the server’s own output and source=system for allocation and bootstrap problems — the same logs and events surface as jobs.

Step 4 - Call your endpoint

The endpoint is plain vLLM: an OpenAI-compatible API. The calls below use the official OpenAI-compatible client libraries directly against your vLLM endpoint, rather than the MKA1 control-plane SDK. Install openai@5.0.0 for TypeScript, OpenAI 2.4.0 for C#, or openai==1.109.1 for Python. Replace https://<model-server-host> with the endpoint’s url, and <model-server-api-key> with the credential its placement accepts: the endpoint key from Step 1 on an external GPU provider, or an MKA1 API key holding read:compute in the MKA1 cluster. Use an HTTPS endpoint for these credentialed requests.
For the external GPU endpoint illustrated here, vLLM authenticates inference requests using the endpoint key. Readiness uses its health route, which does not require that key.
Check the endpoint’s url scheme before sending anything sensitive. MKA1 cluster endpoints always use https, but an external GPU provider may serve an endpoint over plain http, in which case bearer tokens and payloads cross the internet unencrypted.

Step 5 - Register with the LLM gateway

Optionally register the endpoint as a bring-your-own model in the MKA1 LLM gateway, so it is callable through the platform’s /responses API with normal platform keys. Add the endpoint to your model catalog using an organization admin or owner key. The catalog id names your MKA1 model; modelId must match the upstream model name served by vLLM. auth.value is the credential the LLM gateway sends to your endpoint, so it depends on the placement:
  • External GPU provider: the serving runtime’s key. The example below registers this guide’s endpoint with the endpoint key from Step 1.
  • MKA1 cluster: an MKA1 API key of the organization that owns the service, holding read:compute. Prefer a dedicated key with only that scope. The MKA1 API gateway rejects a runtime key with 401.
Then activate the catalog model using its returned model_id (the id you supplied above):
completions-format models are accepted at /responses; the gateway drives the chat-completions upstream for you. This is why the create body in Step 2 passed the tool-choice flags to vLLM.

Step 6 - Terminate

A service runs, and bills, until you stop it.
Termination is idempotent, deallocates the provider resource, and stops spend; the record stays readable for audit and usage. Terminating does not remove a catalog entry you added in Step 5. The model stays active, and requests to it return 404; remove it in Step 7.

Step 7 - Remove the model from the LLM gateway

If you registered the endpoint in Step 5, deactivate the model and delete its catalog entry, using the same organization admin or owner key:
Deactivating releases the model name, so requests to qwen-compute-demo stop resolving; deleting withdraws its catalog definition.

Serve a model from mka1-repos

To serve weights from mka1-repos — such as the merged output of a fine-tune job, or weights you pushed over git — change only the model identifier and the credentials. Set HF_ENDPOINT on the service, pointing at the artifact endpoint for your cluster, and vLLM resolves model identifiers against it — the same Hugging Face access described in Manage repositories, so serving a repository is just a model identifier and two environment variables. The console pre-fills HF_ENDPOINT when you create a workload; set it yourself when you call the API directly. mka1-repos authenticates with your MKA1 API key, injected as HF_TOKEN through secret_env:
The service downloads the weights from your organization’s repository at startup and serves them under the same identifier, completing the loop: fine-tune as a job, publish to mka1-repos, serve as a service.

Track spend

Service spend accrues per whole minute from allocation and appears alongside jobs in the usage endpoint:
Compute spend draws from the same organization budgets as every other MKA1 service, and a service that hits an organization budget or its own limits is terminated with no grace period.

API reference

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

See also