Inferência Itô

ito-inference é a única habilidade ECC canônica para inferência servida na computação Itô. Requisições nomeando ito-serve são roteadas aqui; não crie ou instale uma segunda habilidade ito-serve. ECC nunca faz SSH para nós, baixa pesos, inicia um motor, ou expõe um endpoint; nunca reserva, aloca ou gasta.

Limite de produção atual

Serviço gerenciado está indisponível hoje. A ponte ECC expõe apenas login, auth, find, status e evals explicitamente controlados. Não possui o verbo serve. A documentação do runtime canônico descreve inference apenas como uma sonda de compatibilidade não suportada; ECC não a invoca nem depende dela. A superfície MCP expõe apenas autenticação, busca e status. A garantia aplicável localmente é que ECC rejeita serve antes de resolver ou iniciar 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 um executor local, um auxiliar de SSH, um fluxo de trabalho de navegador, um endpoint de compra ou qualquer rascunho ito-serve local não rastreado.

Direito de acesso exigido

Quando o serviço for implementado, seu primeiro portão será uma reserva completa verificada pelo servidor. Memória do harness, um RFQ, uma cotação, IPs de nós ou acesso SSH não são prova de direito de acesso. O backend deve retornar elegibilidade de serviço recente vinculada à conta autenticada, reserva, topologia de GPU, região, fabric, termo e política de modelo. Reservas expiradas, revogadas, incompatíveis, incompletas ou já liberadas falham antes da confirmação.

Contrato futuro de 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 lançado. A entrega futura 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 de 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 do 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 calcular o hash dos bytes do descritor aberto. Esse digest deve ser exatamente igual ao digest vinculado na confirmação antes de qualquer mutação de carga de trabalho. Uma troca de caminho, incompatibilidade de digest, arquivo grande demais ou arquivo inseguro mutável falha fechando.

A API canônica — não ECC — deve ser responsável pela criação da carga de trabalho e retornar JSON estruturado com ok, live_api_contacted, notice e data ou error. Os dados de serviço 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 as verificações de saúde e modelo passem. Erros devem incluir um código estável e uma mensagem segura sem segredos.

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

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

1. Elegibilidade de serviço e direito de acesso recentes do backend canônico.
2. Um manifesto imutável revisável e digest 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. 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 carga de trabalho.
5. Validação de fabric, 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, cotação ou reserva concluída nunca substitui a confirmação de serviço. 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 escopados.

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 com escopo de tenant. Cada operação necessita de tempos limite 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 por

…