ito-training

Itô Training

ito-training é a skill canônica do ECC para treinamento em computação Itô. O ECC nunca executa um treinador, agendador ou pipeline de dados próprio; ele nunca faz reservas, reservas ou gastos. Esta skill se encadeia a uma reserva concluída do ito-compute.

Limite atual de produção

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 o ECC rejeita train antes de resolver ou gerar o cliente canônico portador de credenciais.

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

Direito de uso exigido

Quando o treinamento for implementado, sua primeira barreira é uma reserva concluída verificada pelo servidor. Memória de arnês, um RFQ, um orçamento, IPs de nós ou acesso SSH não são prova de direito de uso. O backend deve retornar elegibilidade de treinamento fresca vinculada à conta autenticada, reserva, topologia de GPU, região, tecido e prazo. Reservas expiradas, revogadas, incompatíveis, incompletas ou já liberadas falham de forma fechada 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 <server-verified-booking-id> \
  --manifest <absolute-reviewed-json-file> \
  --confirmation-ref <opaque-non-authorizing-reference> \
  --idempotency-key <stable-retry-key> \
  --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 de 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, aplicar um tamanho limitado e fazer hash dos bytes a partir do descritor aberto. Esse digest deve ser exatamente igual ao digest vinculado à confirmação antes de qualquer mutação de carga de trabalho. Uma troca de caminho, incompatibilidade de digest, arquivo superdimensionado ou arquivo inseguro mutável falha de forma fechada.

A API canônica—não o ECC—deve ser a dona da 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. Erros devem incluir um código estável e mensagem segura, sem segredos.

Barreiras de confirmação e execução

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

1. Elegibilidade e direito de treinamento frescos do backend canônico.
2. Um manifesto imutável revisável e digest determinístico.
3. Uma confirmação separada de uso único vinculada a conta, ação, manifesto e custo, com curto prazo de expiração e proteção contra repetição. Argumentos de CLI carregam apenas uma referência de confirmação opaca e não autorizadora; o servidor resolve e consome a capacidade do portador fora de banda.
4. Uma chave de idempotência fornecida pelo chamador, reservada atomicamente com a execução.
5. Validação de tecido, capacidade, política de dados, armazenamento de checkpoint e custo do 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, orçamento ou reserva concluída nunca substitui a confirmação de treinamento. Inspeção e geração de plano 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 checkpoints, cancelamento e limpeza com escopo de inquilino. Cada operação precisa de timeouts limitados de conexão e gerais, erros conscientes 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 para de consultar e retorna o controle ao agente original sem iniciar o login automaticamente.

Reporte as barreiras de estágio honestamente; 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

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

1. Preparação de dados — manifesto, dedup, descontaminação contra o conjunto de avaliação; job de decisão de escada de 150M como verificação barata para dados personalizados.
2. Paralelismo e precisão — selecionados a partir do tamanho do modelo, contagem de nós, tecido; 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 intervenção humana.
4. Currículo e barreiras de avaliação — pré-treinamento / treinamento intermediário / contexto longo / pós-treinamento em etapas, cada uma com uma bateria fixa de avaliação; 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/rollout com defasagem 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, essa skill permanece como uma verificação de disponibilidade que falha de forma fechada e entrega de documentação.