Itô Inference
ito-inference é a única skill canônica do ECC para inferência em computação Itô.
Requisições nomeando ito-serve são roteadas aqui; não crie ou instale uma segunda skill ito-serve. O ECC nunca faz SSH em nós, baixa pesos, inicia um motor ou expõe um endpoint; ele nunca reserva, aloca ou gasta.
Limite de produção atual
Não há inferência gerenciada disponível hoje. A ponte ECC expõe apenas login,
auth, find, status e evals explicitamente restritos. Ela não tem um verbo serve.
O runtime canônico documenta inference apenas como uma sonda de compatibilidade não suportada; o ECC não o invoca nem depende dele. A superfície MCP expõe apenas autenticação, pesquisa e status. A garantia localmente aplicável é que o ECC rejeita serve 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. Relate a capacidade ausente e retorne ao agente originador. Nunca substitua por um executor local, helper SSH, fluxo de navegador, endpoint de compra ou qualquer rascunho local de ito-serve não rastreado.
Direito exigido
Quando a inferência estiver implementada, seu primeiro gate é uma reserva concluída verificada pelo servidor. Memória do harness, RFQ, orçamento, IPs de nós ou acesso SSH não são prova de direito. O backend deve retornar elegibilidade de inferência recente vinculada à conta autenticada, reserva, topologia GPU, região, malha, termo e política de modelo. Reservas expiradas, revogadas, incompatíveis, incompletas ou já liberadas falham fechado 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 obsoleto após o contrato de produção entrar em vigor. A futura entrega deve ser equivalente a:
ecc ito serve \
--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 a revisão do modelo, motor e versão, quantização, topologia tensor/pipeline, política de exposição de endpoint, checksums de artefatos, limite de armazenamento, limites de runtime, objetivos opcionais de TTFT/TPOT e custo incremental máximo. Nenhuma chave de API bruta, chave SSH, senha de nó ou token de portador 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 ser exatamente igual ao digest vinculado à confirmação antes de qualquer mutação de carga de trabalho. Uma troca de caminho, digest incorreto, arquivo muito grande ou arquivo mutável inseguro falha fechado.
A API canônica—não o 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 inferência devem incluir IDs estáveis de reserva, carga de trabalho, manifesto e idempotência, além de um enum de estado; não deve afirmar que um endpoint está ativo até que verificações de saúde e de modelo passem. Erros devem incluir um código estável e uma mensagem segura, sem segredos.
Gates de confirmação e execução
Antes da criação da carga de trabalho, exija todos os seguintes:
- Direito recente e elegibilidade de inferência do backend canônico.
- Um manifesto imutável revisável e digest determinístico.
- Uma confirmação separada de uso único vinculada à conta, ação, manifesto e custo, com validade curta e proteção contra repetição. Argumentos CLI carregam apenas uma referência de confirmação opaca e não autorizante; o servidor resolve e consome a capacidade de portador fora da banda.
- Uma chave de idempotência fornecida pelo chamador, reservada atomicamente com a carga de trabalho.
- Validação de malha, capacidade, política de modelo, armazenamento e custo no lado do servidor.
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 inferência. 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 operações de status, logs, métricas, cancelamento e limpeza no escopo do locatário. Cada operação precisa de timeouts de conexão e gerais 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 carga de trabalho apenas porque a primeira resposta foi perdida. Uma credencial revogada para de sondar e retorna o controle ao agente originador sem iniciar login automaticamente.
Reporte ready somente após a saúde do endpoint, a identidade do modelo e a inferência canary passarem. Reporte estados de falha intermediários e terminais de forma honesta. 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 do backend
Estes estágios descrevem o futuro backend, não código que existe no ECC:
- Verificar direito, topologia, malha e gates de custo.
- Buscar pesos com checksum fixo no armazenamento gerenciado pelo backend.
- Emitir e validar um plano de topologia/motor revisável.
- Iniciar através do painel de controle do provedor, nunca via SSH root direto do ECC.
- Aquecer, testar saúde e identidade do modelo, executar um canary SLO, depois registrar o endpoint e a configuração redigida.
Até que todos os gates e operações de ciclo de vida acima existam no runtime canônico, esta skill permanece uma verificação de disponibilidade que falha fechado e uma entrega de documentação.