ito-inference

Itô Inference

ito-inference é a única skill canônica da ECC para inferência em computação Itô. Requisições que mencionam ito-serve são roteadas aqui; não crie ou instale uma segunda skill ito-serve. A ECC nunca usa SSH em nós, baixa pesos, inicia um motor ou expõe um endpoint; ela nunca reserva, agenda ou gasta.

Limite de produção atual

Inferência gerenciada não está disponível hoje. A ponte ECC expõe apenas login, auth, find, status e evals explicitamente autorizados. Não há um verbo serve. O runtime canônico documenta inference apenas como uma sonda de compatibilidade não suportada; a ECC não a invoca nem depende dela. A superfície MCP expõe apenas auth, find e status. A garantia localmente exigível é que a ECC rejeita serve antes de resolver ou gerar o cliente canônico que contém as credenciais.

Portanto, pare antes da autenticação ou de qualquer invocação de comando. Relate a capacidade faltante e retorne ao agente originador. Nunca substitua por um executor local, helper SSH, fluxo de navegador, endpoint de compra ou qualquer rascunho ito-serve local não rastreado.

Direito de uso exigido

Quando a inferência estiver implementada, sua primeira barreira é uma reserva completa verificada pelo servidor. Memória da rédea, RFQ, orçamento, IPs dos nós ou acesso SSH não são prova de direito de uso. O backend deve retornar elegibilidade de inferência fresca vinculada à conta autenticada, reserva, topologia GPU, região, tecido, termo e política de modelo. Reservas expiradas, revogadas, incompatíveis, incompletas ou já liberadas falham fechadas antes da confirmação.

Futuro contrato CLI e API

O nome de comando pretendido é serve; inference pode permanecer apenas como um alias de compatibilidade explicitamente depreciado após o contrato de produção ser implementado. O handoff futuro deve ser equivalente a:

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

O manifesto revisado deve identificar a revisão do modelo, motor e versão, quantização, topologia tensor/pipeline, política de exposição de endpoint, checksums dos artefatos, teto de armazenamento, limites de runtime, objetivos TTFT/TPOT opcionais e custo incremental máximo. Nenhuma chave de API crua, chave SSH, senha de nó ou token bearer deve estar em argumentos, manifestos, logs, resultados MCP ou chat.

O cliente deve canonicalizar o caminho do manifesto, rejeitar symlinks, abrir um arquivo regular sem seguir links, exigir propriedade apropriada e permissões restritivas, impor um tamanho limitado e fazer hash dos bytes a partir do descritor aberto. Esse digest deve exatamente igualar o digest vinculado à confirmação antes de qualquer mutação de workload. Uma troca de caminho, divergência de digest, arquivo muito grande ou arquivo mutável inseguro falha fechado.

A API canônica — não a ECC — deve possuir a criação de workload e retornar JSON estruturado com ok, live_api_contacted, notice e data ou error. Os dados de inferência devem incluir IDs estáveis de reserva, workload, manifesto e idempotência, além de um enum de estado; não devem reivindicar que um endpoint está ativo até que testes de saúde e modelo passem. Erros devem incluir um código estável e mensagem segura sem segredos.

Portões de confirmação e execução

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

1. Elegibilidade de direito de uso e inferência fresca 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 expiração curta e proteção contra replay. Argumentos CLI carregam apenas uma referência de confirmação opaca e não autorizadora; o servidor resolve e consome a capacidade bearer fora de banda.
4. Uma chave de idempotência fornecida pelo chamador e reservada atomicamente com o workload.
5. Validação de tecido, capacidade, política de modelo, armazenamento e custo do lado do servidor.

Autenticação é identidade, não autoridade de workload. Um login, chave de API, orçamento ou reserva completa nunca substitui a confirmação de inferência. Inspeção e geração de plano não devem criar um workload. 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 operações de status, logs, métricas, cancelamento e limpeza escopo-tenant. Cada operação precisa de timeouts 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 um segundo workload apenas porque a primeira resposta foi perdida. Uma credencial revogada para de sondar e retorna o controle ao agente originador sem iniciar login automaticamente.

Relate ready apenas após saúde do endpoint, identidade do modelo e inferência canário passarem todos. Relate honestamente estados de falha intermediários e terminais. 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 de backend propostos

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

1. Verificar barreiras de direito de uso, topologia, tecido e custo.
2. Baixar pesos presos a checksums no armazenamento gerenciado pelo backend.
3. Emitir e validar um plano de topologia/motor revisável.
4. Iniciar pelo plano de controle do provedor, nunca SSH direto root da ECC.
5. Aquecer, testar saúde e identidade do modelo, rodar canário SLO, depois registrar o endpoint e configuração editada.

Até que todos os portões e operações de ciclo de vida acima existam no runtime canônico, esta skill permanece uma verificação de disponibilidade e handoff de documentação com falha fechada.