Inferencia Itô
ito-inference es la única skill canónica de ECC para servir inferencia en cómputo Itô.
Las solicitudes que nombran ito-serve se enrutan aquí; no cree ni instale una segunda skill ito-serve. ECC nunca se conecta por SSH a los nodos, descarga pesos, inicia un motor ni expone un endpoint; nunca reserva, aparta ni gasta.
Límite de producción actual
El servicio gestionado no está disponible hoy. El puente ECC expone solo login,
auth, find, status y evals explícitamente controlados. No tiene un verbo serve.
El runtime canónico documenta inference solo como una sonda de compatibilidad no soportada;
ECC no la invoca ni depende de ella. La superficie MCP expone solo autenticación, búsqueda y estado.
La garantía localmente aplicable es que ECC rechaza serve antes de resolver o generar el cliente canónico portador de credenciales.
Por lo tanto, deténgase antes de la autenticación o cualquier invocación de comando. Reporte
la capacidad faltante y regrese al agente originador. Nunca sustituya un ejecutor local,
ayudante SSH, flujo de trabajo en navegador, endpoint de compra o cualquier borrador local
ito-serve no rastreado.
Derecho requerido
Cuando el servicio esté implementado, su primera compuerta será una reserva completada verificada por servidor. La memoria del arnés, una RFQ, un presupuesto, IPs de nodos o acceso SSH no son prueba del derecho. El backend debe devolver elegibilidad de servicio fresca vinculada a la cuenta autenticada, reserva, topología de GPU, región, tejido, término y política de modelo. Las reservas expiradas, revocadas, no coincidentes, incompletas o ya liberadas fallan cerradas antes de la confirmación.
Futuro contrato CLI y API
El nombre de comando previsto es serve; inference puede permanecer solo como un
alias de compatibilidad explícitamente obsoleto después de que el contrato de producción llegue.
La futura entrega debe ser equivalente a:
ecc ito serve \
--booking <id-de-reserva-verificado-por-servidor> \
--manifest <archivo-json-absoluto-revisado> \
--confirmation-ref <referencia-no-autorizante-opaca> \
--idempotency-key <clave-de-reintento-estable> \
--json
El manifiesto revisado debe identificar la revisión del modelo, el motor y versión, cuantización, topología tensor/pipe, política de exposición del endpoint, sumas de verificación de artefactos, límite de almacenamiento, límites de ejecución, objetivos opcionales de TTFT/TPOT y costo incremental máximo. Ninguna clave API en bruto, clave SSH, contraseña de nodo o token de portador pertenece a argumentos, manifiestos, registros, resultados MCP o chat.
El cliente debe canonizar la ruta del manifiesto, rechazar enlaces simbólicos, abrir un archivo regular sin seguir enlaces, requerir propiedad adecuada y permisos restrictivos, forzar un tamaño acotado y aplicar hash a los bytes desde el descriptor abierto. Ese resumen debe coincidir exactamente con el resumen vinculado en la confirmación antes de cualquier mutación de carga de trabajo. Un intercambio de ruta, desajuste de resumen, archivo sobredimensionado o archivo mutable inseguro falla cerrado.
La API canónica—no ECC—debe ser dueña de la creación de la carga de trabajo y devolver JSON estructurado
con ok, live_api_contacted, notice y ya sea data o error. Los datos
del servicio deben incluir reserva estable, carga de trabajo, manifiesto e IDs de idempotencia más un enumerado de estado;
no debe afirmar que un endpoint está vivo hasta que pasen las comprobaciones de salud y modelo.
Los errores deben incluir un código estable y un mensaje seguro sin secretos.
Compuertas de confirmación y ejecución
Antes de la creación de la carga de trabajo, requiera todo lo siguiente:
- Elegibilidad fresca de derecho y servicio desde el backend canónico.
- Un manifiesto inmutable revisable y un resumen determinista.
- Una confirmación separada de un solo uso vinculada a cuenta, acción, manifiesto y costo, con caducidad corta y protección de repetición. Los argumentos CLI llevan solo una referencia de confirmación opaca y no autorizante; el servidor resuelve y consume la capacidad de portador fuera de banda.
- Una clave de idempotencia proporcionada por el llamante reservada atómicamente con la carga de trabajo.
- Validación de tejido, capacidad, política de modelo, almacenamiento y costo del lado del servidor.
La autenticación es identidad, no autoridad de carga de trabajo. Un inicio de sesión, clave API, presupuesto o reserva completada nunca sustituye la confirmación de servicio. La inspección y generación de planes no deben crear una carga de trabajo. Cancelar y limpiar son mutaciones separadas con sus propios límites de confirmación e idempotencia.
Ciclo de vida y recuperación
La superficie de producción está incompleta hasta que el mismo cliente canónico exponga operaciones de estado, registros, métricas, cancelación y limpieza con alcance de inquilino. Cada operación necesita tiempos de espera de conexión y total acotados, errores conscientes de revocación y salida estructurada. Después de una falla de transporte ambigua, consulte el estado mediante la clave de idempotencia antes de reintentar; nunca cree una segunda carga de trabajo solo porque la primera respuesta se perdió. Una credencial revocada detiene el sondeo y devuelve el control al agente originador sin iniciar inicio de sesión automáticamente.
Solo reporte ready después de que la salud del endpoint, la identidad del modelo y la inferencia de prueba
pasen. Reporte estados de falla intermedios y terminales honestamente. La limpieza debe
ser observable y no debe liberar ni modificar la reserva subyacente a menos que esa
economía separada haya sido explícitamente autorizada.
Etapas de backend propuestas
Estas etapas describen el backend futuro, no código que existe en ECC:
- Verificar compuertas de derecho, topología, tejido y costo.
- Obtener pesos con suma de verificación fija en almacenamiento gestionado por el backend.
- Emitir y validar un plan de topología/motor revisable.
- Iniciar a través del plano de control del proveedor, nunca SSH raíz directo desde ECC.
- Calentar, probar salud e identidad del modelo, ejecutar una prueba canaria de SLO, luego registrar el endpoint y configuración censurada.
Hasta que cada compuerta y operación de ciclo de vida anterior exista en el runtime canónico, esta skill sigue siendo una verificación de disponibilidad con cierre en fallo y una entrega de documentación.