Skip to main content
Use um trabalho Compute quando precisar de GPUs para uma carga de trabalho finita, como ajuste fino. Você fornece uma imagem de contêiner comum e um comando; o Compute aloca capacidade de GPU, executa a carga de trabalho até a conclusão, transmite logs duráveis e desaloca o hardware automaticamente. O Compute não possui um esquema de ajuste fino. Um trabalho é uma execução genérica de contêiner, portanto este guia faz o ajuste fino com ms-swift puramente como carga útil de trabalho — qualquer stack de treinamento funciona da mesma forma.
Este guia aluga GPUs e executa seu próprio contêiner de treinamento. Para a API gerenciada de ajuste fino que treina modelos da plataforma a partir de arquivos JSONL enviados, consulte Ajustar um modelo.

Antes de começar

Você precisa de: Os trabalhos passam por requestedallocatingprovisioningrunningfinalizing e, em seguida, chegam a um estado terminal:
  • Uma carga de trabalho que sai com 0 termina como succeeded; uma falha em qualquer fase termina como failed.
  • A terminação explícita, um limite vinculante ou um orçamento da organização esgotado move o trabalho por terminating até terminated.
A cobrança começa na alocação, não quando estiver pronto.Os custos acumulam a partir do momento em que o hardware é alocado; portanto, o tempo de provisionamento e inicializações com falha custam dinheiro. Defina limits.max_runtime_hours e limits.max_cost_usd em todos os trabalhos; um trabalho que atinge um limite vinculante é terminado e desalocado imediatamente.

Etapa 1 - Escolha um acelerador

Liste o catálogo selecionado de aceleradores e escolha um pelo seu name estável.
Cada entrada descreve o hardware, as contagens de GPU que você pode solicitar e as interconexões compatíveis:

Etapa 2 - Verifique preço e disponibilidade

Opcionalmente, solicite uma cotação antes de criar qualquer coisa. Uma cotação é uma observação ao vivo do mercado: ela retorna se a configuração está disponível no momento e a faixa de preço por hora, mas não reserva nada.
Uma configuração indisponível ainda é uma resposta 200, com available: false e limites de preço nulos.

Etapa 3 - Crie o trabalho

Crie o trabalho com um cabeçalho Idempotency-Key obrigatório. Repetir a solicitação com a mesma chave e o mesmo corpo retorna o mesmo trabalho com 200, em vez de criar um duplicado; a mesma chave com um corpo diferente retorna 409 idempotency_conflict. Este exemplo executa um pequeno ajuste fino LoRA de Qwen2.5-0.5B-Instruct e mescla o adaptador, correspondendo ao teste de fumaça da plataforma:
Notas sobre os campos: A resposta é 201 com o trabalho durável no estado requested:
Uma criação bem-sucedida significa que a solicitação foi aceita, não que existe capacidade disponível. Esgotamento de capacidade, erros do provedor e falhas de bootstrap surgem posteriormente por meio de state, reason, logs e eventos — nunca como um erro HTTP em uma criação que já retornou 201.

Etapa 4 - Consulte até terminar

Durante a execução, o trabalho informa o hardware que realmente obteve, o preço por hora registrado na alocação, o custo acumulado até o momento e um comando SSH pronto para uso, caso você tenha fornecido uma chave:
Quando a carga de trabalho sai com 0, o trabalho passa por finalizing até succeeded, exit_code é registrado, o recurso do provedor é desalocado automaticamente e o custo deixa de acumular. Uma saída diferente de zero termina em failed com uma reason explicando o motivo. Trabalhos terminais permanecem legíveis para auditoria e uso.

Etapa 5 - Leia logs e eventos

Os logs são duráveis e paginados por cursor, e distinguem a saída da sua carga de trabalho da saída do sistema.
Use source=system para saída de alocação e bootstrap, e order=asc (o padrão) para paginar do mais antigo para o mais recente. Transições de ciclo de vida, como provider_allocated, workload_started e workload_exited, também estão disponíveis como eventos estruturados:

Etapa 6 - Interrompa um trabalho antecipadamente

A terminação é explícita, idempotente e retorna o recurso atual.
Não há DELETE: o registro é mantido para auditoria, uso e reconciliação. Um trabalho que atinge limits.max_runtime_hours, limits.max_cost_usd ou um orçamento da organização é terminado da mesma forma, sem período de tolerância e sem garantia de resultado parcial; portanto, publique artefatos de dentro da carga de trabalho antes que ela termine.

Use mka1-repos para conjuntos de dados e pesos

O Compute não armazena artefatos de carga de trabalho. O caminho recomendado é mka1-repos, o serviço de repositório compatível com Hugging Face da plataforma para modelos e conjuntos de dados: seu trabalho obtém o conjunto de dados dele e publica os pesos mesclados de volta nele, tudo de dentro da carga de trabalho. Este é o mesmo acesso ao Hugging Face que você usa da sua própria máquina — consulte Gerenciar repositórios. O ms-swift com USE_HF=1 usa esse protocolo, portanto --model e --dataset aceitam referências <org>/<name> diretamente e não são necessárias alterações no código. Três valores de ambiente fazem isso funcionar. O Compute os trata como variáveis de ambiente comuns — são as ferramentas do Hugging Face dentro do seu contêiner que os leem, por estes nomes exatos:
  1. HF_ENDPOINT aponta para o endpoint de artefatos do seu cluster. Ferramentas compatíveis com Hugging Face — huggingface_hub, ms-swift com USE_HF=1, vLLM — resolvem identificadores <org>/<name> em relação a ele, para que as cargas de trabalho alcancem mka1-repos sem nenhuma alteração de código. O console o preenche automaticamente quando você cria uma carga de trabalho; defina-o você mesmo ao chamar a API diretamente ou aponte-o para outro local para obter dados de outro hub.
  2. mka1-repos autentica com sua chave de API MKA1. Armazene a chave como um segredo do Compute e injete-a como HF_TOKEN por meio de secret_env, para que ela nunca apareça embutida na especificação do trabalho.
  3. Defina HF_HUB_DISABLE_XET=1 ao enviar pesos. Versões atuais do huggingface_hub podem selecionar automaticamente o caminho de transferência Xet, enquanto o mka1-repos oferece suporte ao caminho padrão de envio Hub/LFS. Desabilitar o Xet mantém HfApi.upload_folder e hf upload no caminho compatível.
Crie o segredo uma vez:
Os valores dos segredos são somente para gravação; a resposta retorna apenas o id e os nomes das chaves:
Em seguida, escreva a carga de trabalho como um script que treina a partir do seu repositório de conjunto de dados e publica os pesos mesclados. Este exemplo continua o treinamento de meetkai/functionary e publica de volta nele, para que cada execução se baseie na anterior.
HF_ENDPOINT redireciona toda consulta ao Hugging Face na carga de trabalho, portanto identificadores do hub público deixam de ser resolvidos enquanto ele está definido. Para fazer ajuste fino a partir de um modelo base público, primeiro espelhe-o em um repositório próprio ou deixe HF_ENDPOINT não definido e obtenha-o do hub público.
--model_type e --template são obrigatórios sempre que o modelo base vier de um repositório, em vez do hub público. O ms-swift compara ambos pelo nome do modelo upstream, e os pesos obtidos do seu próprio repositório chegam como um diretório local que não carrega tal nome, portanto ele não consegue inferir nenhum dos dois e para com Failed to automatically match. As duas falhas ocorrem uma após a outra — model_type primeiro, depois template — e ambas acontecem após o download da imagem e a execução do treinamento, portanto uma flag ausente custa uma execução completa faturável a cada vez. Ambos os valores devem corresponder ao seu modelo base; a lista de modelos compatíveis do ms-swift fornece o par para cada família, e a mensagem de erro nomeia os candidatos entre os quais ele não conseguiu escolher.
train-and-publish.sh
Codifique-o com base64 < train-and-publish.sh e faça referência ao segredo no corpo de criação:
Quando o trabalho for concluído com sucesso, os pesos mesclados poderão ser baixados de meetkai/functionary por qualquer pessoa na sua organização, e um serviço Compute poderá servi-los diretamente — consulte Implantar um servidor de modelos.
Uma terminação no meio da execução destrói qualquer trabalho que ainda não tenha sido publicado. Publicar de dentro da carga de trabalho, como acima, é o mecanismo de checkpoint compatível nesta versão.

Acompanhe os custos

Toda resposta de trabalho contém accrued_usd, e o endpoint de uso agrega os custos entre recursos para uma janela de tempo:
A cobrança é medida em minutos inteiros por recurso, e os custos do Compute são descontados dos mesmos orçamentos da organização que todos os outros serviços MKA1.

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