Skip to main content
Use um serviço Compute quando precisar de GPUs para uma carga de trabalho persistente, como servir modelos. Um serviço é a mesma execução de contêiner genérica que um job, além de portas nomeadas, uma sonda de prontidão opcional e um endpoint público — o Compute não tem esquema de implantação ou modelo, portanto este guia utiliza o vLLM puramente como carga de trabalho. Um serviço é executado até que você o encerre, e você é responsável pelo ciclo de vida de ponta a ponta: o Compute nunca reinicia, redimensiona ou troca revisões sem sua intervenção, portanto 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 encerra, mesmo com código 0, encerra o serviço como failed — e substitua um serviço com falha ou desatualizado criando um novo.

​
Antes de começar

Você precisa de: Os serviços passam por requested → allocating → provisioning → ready e permanecem nesse estado até que algo encerre a execução:
  • Uma falha em qualquer fase, incluindo a carga de trabalho sendo encerrada após ready, desmonta o serviço passando por terminating até failed.
  • O encerramento explícito, um limite de vinculação ou um orçamento da organização esgotado encerram em terminated.
Com uma sonda de prontidão, ready significa que a sonda foi aprovada. Sem uma, significa apenas que a carga de trabalho foi iniciada; não faz nenhuma afirmação de integridade no nível da aplicação, portanto declare uma sonda sempre que a imagem oferecer uma rota de integridade.
A cobrança começa na alocação, não na prontidão.Os gastos são acumulados desde a alocação até o serviço alcançar um estado terminal, incluindo todo o tempo de provisionamento e carregamento do modelo. Um serviço nunca é concluído por conta própria — encerre-o quando terminar e defina limits como proteção adicional.

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

Passe a chave de API da carga de trabalho por secret_env, não embutida no comando, para que ela nunca apareça nas especificações de pods do provedor.
Os valores dos segredos são somente para gravação. Guarde o id sec_... retornado para o corpo de criação e o próprio valor da chave para seus clientes.

​
Etapa 2 - Crie o serviço

Crie o serviço com um cabeçalho Idempotency-Key obrigatório, exatamente como para jobs. Este exemplo serve Qwen2.5-0.5B-Instruct com o servidor compatível com OpenAI do vLLM, correspondente ao teste de fumaça da plataforma:
Observações sobre os campos: Assim como com jobs, 201 significa que a solicitação foi aceita; problemas de capacidade e provisionamento surgem depois por meio de state, reason, logs e eventos.

​
Etapa 3 - Aguarde a prontidão

O download e o carregamento do modelo ocorrem dentro da carga de trabalho, portanto espere minutos de provisioning antes que a sonda de prontidão seja aprovada. Um serviço pronto contém seus endpoints públicos:
Se o serviço entrar em failed, leia reason e então execute GET .../logs?source=user para a saída do próprio servidor e source=system para problemas de alocação e inicialização — os mesmos logs e eventos são exibidos para jobs.

​
Etapa 4 - Chame seu endpoint

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

​
Etapa 5 - Registre no gateway de LLM

Opcionalmente, registre o endpoint como um modelo traga-o-seu no gateway de LLM da MKA1, para que ele possa ser chamado pela API /responses da plataforma com chaves normais da plataforma. Adicione o endpoint ao seu catálogo de modelos:
Bash
Em seguida, registre o id de modelo retornado:
Bash
Modelos no formato completions são aceitos em /responses; o gateway gerencia o upstream de conclusões de chat para você. É por isso que o corpo de criação na Etapa 2 passou as flags de escolha de ferramenta ao vLLM.

​
Etapa 6 - Encerre

Um serviço é executado e é cobrado até que você o interrompa.
O encerramento é idempotente, desaloca o recurso do provedor e interrompe os gastos; o registro permanece legível para auditoria e uso.

​
Sirva um modelo de mka1-repos

Para servir pesos de mka1-repos — como a saída mesclada de um job de fine-tune, ou pesos que você enviou por git — altere apenas o identificador do modelo e as credenciais. Defina HF_ENDPOINT no serviço, apontando para o endpoint de artefatos do seu cluster, e o vLLM resolverá os identificadores de modelo nele — o mesmo acesso Hugging Face descrito em Gerenciar repositórios, portanto servir um repositório requer apenas um identificador de modelo e duas variáveis de ambiente. O console preenche HF_ENDPOINT automaticamente quando você cria uma carga de trabalho; defina-o manualmente ao chamar a API diretamente. O mka1-repos autentica com sua chave de API MKA1, injetada como HF_TOKEN por meio de secret_env:
O serviço baixa os pesos do repositório da sua organização na inicialização e os serve com o mesmo identificador, completando o ciclo: faça fine-tune como um job, publique em mka1-repos e sirva como um serviço.

​
Acompanhe os gastos

Os gastos do serviço são acumulados por minuto inteiro a partir da alocação e aparecem ao lado dos jobs no endpoint de uso:
Os gastos do Compute consomem os mesmos orçamentos da organização que todos os outros serviços 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 os esquemas completos de solicitação e resposta, abra os grupos Compute na Referência da API.

​
Veja também