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 throughterminatingintofailed. - Explicit termination, a binding limit, or an exhausted organization budget ends in
terminatedinstead.
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.
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-onlyread: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 throughsecret_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.
sec_... id for the create body, and the key value itself for your clients.
Step 2 - Create the service
Create the service with a requiredIdempotency-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:
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
provisioning before the readiness probe passes.
A ready service carries its public endpoints:
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. Installopenai@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.
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 with401.
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.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: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. SetHF_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:
Track spend
Service spend accrues per whole minute from allocation and appears alongside jobs in the usage endpoint: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
- Manage resources - inspect capacity, workloads, secrets, and volumes.
- Run a fine-tune job - produce the weights this service serves.
- Manage repositories - create and manage the repositories this service pulls weights from.
-
Generate a response - call your registered model through the platform
/responsesAPI.