ito-training

Treinamento Itô

ito-training é o skill canônico da ECC para treinamento em computação Itô. A ECC nunca executa um treinador, escalonador ou pipeline de dados próprio; ela nunca reserva, aloca ou gasta recursos. Este skill encadeia-se a partir de uma reserva concluída do ito-compute.

Limite de produção atual

O treinamento gerenciado não está disponível hoje. A ponte ECC expõe apenas login, logout, auth, find, status e evals explicitamente controlados. Ela não possui um verbo train, e o verbo run da CLI canônica e o backend training-run da mesa permancem como esboços. A garantia localmente aplicável é que a ECC rejeita train antes de resolver ou gerar o cliente canônico portador de credenciais.

Portanto, pare antes da autenticação ou de qualquer invocação de comando. Reporte a capacidade ausente e retorne ao agente de origem. Nunca substitua por um treinador local, auxiliar SSH, fluxo de navegador ou endpoint de compra.

Direito exigido

Quando o treinamento for implementado, sua primeira barreira é uma reserva concluída verificada pelo servidor. A memória do arnês, um RFQ, uma cotação, IPs de nós ou acesso SSH não são prova de direito. O backend deve retornar elegibilidade de treinamento recente vinculada à conta autenticada, à reserva, à topologia de GPU, à região, à malha e ao prazo. Reservas expiradas, revogadas, incompatíveis, incompletas ou já liberadas falham fechado antes da confirmação.

Contrato futuro de CLI e API

O nome de comando pretendido é train. A transferência futura deve ser equivalente a:

ecc ito train \
  --booking <id-da-reserva-verificada-pelo-servidor> \
  --manifest <caminho-absoluto-do-arquivo-json-revisado> \
  --confirmation-ref <referência-opaca-não-autorizadora> \
  --idempotency-key <chave-estável-de-reativação> \
  --json

O manifesto revisado deve identificar o tamanho e a revisão do modelo, referências de dados com proveniência de descontaminação, alvo de treinamento, receita pós-treinamento, teto de orçamento em USD, política de checkpoint e custo incremental máximo. Nenhuma chave de API bruta, chave SSH, senha de nó, token de portador ou credencial de conjunto de dados pertence a argumentos, manifestos, logs, resultados MCP ou chat.

O cliente deve canonizar o caminho do manifesto, rejeitar links simbólicos, abrir um arquivo regular sem seguir links, exigir propriedade apropriada e permissões restritivas, impor um tamanho limitado e fazer o hash dos bytes a partir do descritor aberto. Esse resumo deve ser exatamente igual ao resumo vinculado à confirmação antes de qualquer mutação da carga de trabalho. Uma troca de caminho, divergência de resumo, arquivo muito grande ou arquivo mutável inseguro falha fechado.

A API canônica—não a ECC—deve possuir a criação da carga de trabalho e retornar JSON estruturado com ok, live_api_contacted, notice e data ou error. Os dados de treinamento devem incluir IDs estáveis de reserva, execução, manifesto e idempotência, além de um enum de estado. Os erros devem incluir um código estável e uma mensagem segura, sem segredos.

Barreiras de confirmação e execução

Antes da criação da carga de trabalho, exija todos os seguintes:

1. Direito recente e elegibilidade de treinamento do backend canônico.
2. Um manifesto imutável revisável e resumo determinístico.
3. Uma confirmação separada de uso único vinculada à conta, ação, manifesto e custo, com expiração curta e proteção contra repetição. Os argumentos da CLI carregam apenas uma referência de confirmação opaca e não autorizadora; o servidor resolve e consome a capacidade de portador fora da banda.
4. Uma chave de idempotência fornecida pelo chamador, reservada atomicamente com a execução.
5. Validação de malha, capacidade, política de dados, armazenamento de checkpoint e custo no lado do servidor, incluindo o teto de orçamento do manifesto.

Autenticação é identidade, não autoridade de carga de trabalho. Um login, chave de API, cotação ou reserva concluída nunca substitui a confirmação de treinamento. Inspeção e geração de planos não devem criar uma carga de trabalho. Cancelamento e limpeza são mutações separadas com seus próprios limites de confirmação e idempotência.

Ciclo de vida e recuperação

A superfície de produção está incompleta até que o mesmo cliente canônico exponha status, logs, métricas, listagem de checkpoint, cancelamento e limpeza com escopo de locatário. Cada operação precisa de tempo limite de conexão e geral limitados, erros cientes de revogação e saída estruturada. Após uma falha de transporte ambígua, consulte o status pela chave de idempotência antes de tentar novamente; nunca crie uma segunda execução apenas porque a primeira resposta foi perdida. Uma credencial revogada interrompe a sondagem e retorna o controle ao agente de origem sem iniciar o login automaticamente.

Reporte honestamente as barreiras de estágio; nunca substitua uma barreira de avaliação com falha. A limpeza deve ser observável e não deve liberar ou modificar a reserva subjacente, a menos que essa ação econômica separada tenha sido explicitamente autorizada.

Estágios propostos de backend

Estes estágios descrevem o backend futuro (Camada 0.3), não o código que existe na ECC:

1. Preparação de dados — manifesto, dedup, descontaminação contra o conjunto de avaliação; trabalho de decisão em escada de 150M como verificação barata para dados personalizados.
2. Paralelismo e precisão — selecionados a partir do tamanho do modelo, número de nós, malha; combinações desperdiçadoras recusadas.
3. Checkpoint e tolerância a falhas — DCP assíncrono, torchft; detectar < 10 min, retomar < 15 min. Reinicialização por pico de perda é uma ação proposta, com controle humano.
4. Grade curricular e barreiras de avaliação — pré-treinamento / treinamento intermediário / contexto longo / pós-treinamento em estágios, cada um com uma bateria de avaliação fixa; uma barreira com falha interrompe a execução.
5. Pós-treinamento — SFT → DPO → RLVR (GRPO com correções de estabilidade DAPO), separação treinador/rolagem com obsolescência limitada.

O backend emite telemetria da mesa (goodput, taxa de interrupção, largura de banda de checkpoint) para que a mesa precifique blocos de treinamento honestamente.

Até que cada barreira e operação de ciclo de vida acima exista no runtime canônico, este skill permanece como uma verificação de disponibilidade de falha fechada e entrega de documentação.