Skip to main content
Use um serviço do Compute quando precisar de GPUs para uma carga de trabalho persistente, como servir modelos. Um serviço é a mesma execução genérica de contêiner que um job, mais portas nomeadas, uma sonda de prontidão (readiness probe) opcional e um endpoint público — o Compute não tem esquema de implantação nem de modelo, então este guia serve com vLLM puramente como payload da carga de trabalho. Um serviço executa até você encerrá-lo, e você é dono do ciclo de vida de ponta a ponta: o Compute nunca reinicia, redimensiona nem troca revisões pelas suas costas, então o que você implantou é exatamente o que está em execução. Essa previsibilidade vem com duas regras: mantenha o processo do servidor em primeiro plano durante toda a vida do serviço — uma carga de trabalho que sai, mesmo com código 0, termina o serviço como failed — e substitua um serviço que falhou ou ficou desatualizado criando um novo.

​
Antes de começar

Você precisa de: Os serviços passam por requested → allocating → provisioning → ready e permanecem lá até algo encerrar a execução:
  • Uma falha em qualquer fase, incluindo a carga de trabalho sair depois de ready, desmonta o serviço por terminating até failed.
  • Encerramento explícito, um limite atingido ou um orçamento da organização esgotado termina em terminated.
Com uma sonda de prontidão, ready significa que a sonda passou. Sem uma, significa apenas que a carga de trabalho foi lançada; não faz nenhuma afirmação de saúde no nível da aplicação, então declare uma sonda sempre que a imagem oferecer uma rota de health check.
A cobrança começa na alocação, não na prontidão.Os gastos acumulam da alocação até o serviço alcançar um estado terminal, incluindo todo o tempo de provisionamento e de carregamento do modelo. Um serviço nunca termina por conta própria — encerre-o quando terminar e defina limits como salvaguarda.

​
Passo 1 - Armazene a chave do endpoint como um segredo

Passe a chave de API da carga de trabalho através de secret_env, não inline no comando, para que ela nunca apareça nas especificações de pod do provedor.
Os valores de segredos são somente escrita. Guarde o id sec_... retornado para o corpo de criação, e o valor da chave em si para seus clientes.

​
Passo 2 - Crie o serviço

Crie o serviço com um cabeçalho Idempotency-Key obrigatório, exatamente como para jobs. Este exemplo serve o Qwen2.5-0.5B-Instruct com o servidor compatível com OpenAI do vLLM, reproduzindo o smoke test da plataforma:
Notas sobre os campos: Como nos jobs, 201 significa que a requisição foi aceita; problemas de capacidade e provisionamento aparecem depois através de state, reason, logs e eventos.

​
Passo 3 - Aguarde ficar pronto

O download e o carregamento do modelo acontecem dentro da carga de trabalho, então espere minutos de provisioning antes de a sonda de prontidão passar. Um serviço pronto carrega seus endpoints públicos:
Se, em vez disso, o serviço cair em failed, leia o reason, depois GET .../logs?source=user para a saída do próprio servidor e source=system para problemas de alocação e bootstrap — a mesma superfície de logs e eventos dos jobs.

​
Passo 4 - Chame seu endpoint

O endpoint é vLLM puro: uma API compatível com OpenAI autenticada com a chave que você armazenou no Passo 1.
curl
Uma requisição sem a chave é rejeitada pelo próprio vLLM — o Compute não fica na frente do seu endpoint.
Verifique o esquema da url do endpoint antes de enviar qualquer coisa sensível. Dependendo de onde a capacidade foi alocada, um endpoint pode ser servido por http puro, caso em que tokens bearer e payloads cruzam a internet sem criptografia.

​
Passo 5 - Registre no gateway de LLM

Opcionalmente, registre o endpoint como um modelo bring-your-own no gateway de LLM da MKA1, para que ele possa ser chamado através da API /responses da plataforma com chaves normais da plataforma. Adicione o endpoint ao seu catálogo de modelos:
curl
Depois registre o id de modelo retornado:
curl
Modelos no formato completions são aceitos em /responses; o gateway conduz o upstream de chat-completions por você. É por isso que o corpo de criação no Passo 2 passou as flags de tool-choice ao vLLM.

​
Passo 6 - Encerre o serviço

Um serviço executa, e cobra, até você pará-lo.
O encerramento é idempotente, desaloca o recurso do provedor e interrompe os gastos; o registro permanece legível para auditoria e uso.

​
Sirva um modelo a partir do mka1-repos

Para servir pesos do mka1-repos — como a saída mesclada de um job de ajuste fino, ou pesos que você enviou via git — mude apenas o identificador do modelo e as credenciais. O Compute sempre injeta HF_ENDPOINT em toda carga de trabalho, apontando para o endpoint de artefatos configurado para o seu cluster, e o vLLM resolve identificadores de modelo contra ele. O mka1-repos autentica com sua chave de API MKA1, injetada como HF_TOKEN através de secret_env:
O serviço baixa os pesos do repositório da sua organização na inicialização e os serve sob o mesmo identificador, fechando o ciclo: fazer o ajuste fino como job, publicar no mka1-repos, servir como serviço.

​
Acompanhe os gastos

Os gastos de serviço acumulam por minuto inteiro a partir da alocação e aparecem junto com os jobs no endpoint de uso:
Os gastos do Compute saem dos mesmos orçamentos da organização que qualquer outro serviço MKA1, e um serviço que atinge um orçamento da organização ou seus próprios limits é encerrado sem período de carência.

​
Referência da API

Para o esquema completo de requisição e resposta, abra os grupos do Compute na Referência de API.

​
Veja também