Inférence Itô
ito-inference est la seule compétence ECC canonique pour le service d'inférence sur les nœuds de calcul Itô. Les requêtes nommant ito-serve sont redirigées ici ; ne créez pas et n'installez pas une seconde compétence ito-serve. ECC ne se connecte jamais en SSH aux nœuds, ne télécharge pas de poids, ne lance pas de moteur, et n'expose pas d'endpoint ; ECC ne réserve, ne réserve à l'avance, ni ne dépense.
Limite de production actuelle
Le service managé n'est pas disponible aujourd'hui. Le pont ECC expose uniquement login, auth, find, status, et evals explicitement verrouillés. Il n'a pas de verbe serve. L'exécution canonique ne documente inference que comme une sonde de compatibilité non prise en charge ; ECC ne l'invoque pas et ne dépend pas d'elle. La surface MCP n'expose que auth, find et status. La garantie localement applicable est qu'ECC rejette serve avant de résoudre ou de générer le client canonique porteur des identifiants.
Par conséquent, arrêtez-vous avant toute authentification ou invocation de commande. Signalez la capacité manquante et revenez à l'agent d'origine. Ne remplacez jamais par un exécuteur local, un helper SSH, un workflow navigateur, un point de terminaison d'achat ou tout brouillon local non suivi ito-serve.
Droit requis
Lorsque le service sera implémenté, sa première porte sera une réservation complétée vérifiée par le serveur. La mémoire du harnais, un RFQ, un devis, les IP des nœuds ou l'accès SSH ne sont pas une preuve de droit. Le backend doit retourner une éligibilité de service fraîche liée au compte authentifié, à la réservation, à la topologie GPU, à la région, au tissu, à la durée et à la politique de modèle. Les réservations expirées, révoquées, non conformes, incomplètes ou déjà libérées échouent avant confirmation.
Contrat CLI et API futur
Le nom de commande prévu est serve ; inference ne peut rester qu'un alias de compatibilité explicitement déprécié après la mise en production du contrat. Le futur transfert doit être équivalent à :
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
Le manifeste examiné doit identifier la révision du modèle, le moteur et sa version, la quantification, la topologie tenseur/pipeline, la politique d'exposition de l'endpoint, les sommes de contrôle des artefacts, le plafond de stockage, les limites d'exécution, les objectifs optionnels TTFT/TPOT, et le coût incrémental maximum. Aucune clé API brute, clé SSH, mot de passe de nœud ou jeton bearer ne doit figurer dans les arguments, manifestes, journaux, résultats MCP ou discussion.
Le client doit canoniser le chemin du manifeste, rejeter les liens symboliques, ouvrir un fichier régulier sans suivre les liens, exiger une propriété appropriée et des permissions restrictives, appliquer une taille maximale, et hacher les octets depuis le descripteur ouvert. Ce digest doit être exactement égal au digest lié dans la confirmation avant toute mutation de la charge de travail. Un échange de chemin, une discordance de digest, un fichier trop volumineux ou un fichier mutable non sécurisé échouent.
L'API canonique — pas ECC — doit posséder la création de la charge de travail et retourner un JSON structuré avec ok, live_api_contacted, notice, et soit data soit error. Les données de service doivent inclure la réservation stable, la charge de travail, le manifeste, et les identifiants d'idempotence ainsi qu'une énumération d'état ; elles ne doivent pas prétendre qu'un endpoint est actif tant que les vérifications de santé et de modèle ne sont pas réussies. Les erreurs doivent inclure un code stable et un message sécurisé sans secrets.
Portes de confirmation et d'exécution
Avant la création de la charge de travail, exigez impérativement :
- Un droit frais et une éligibilité au service depuis le backend canonique.
- Un manifeste immutable et un digest déterministe pouvant être examinés.
- Une confirmation distincte à usage unique liée au compte, à l'action, au manifeste et au coût, avec une courte durée de validité et une protection contre la relecture. Les arguments CLI ne portent qu'une référence de confirmation opaque et non autorisante ; le serveur résout et consomme la capacité bearer hors bande.
- Une clé d'idempotence fournie par l'appelant, réservée atomiquement avec la charge de travail.
- Une validation côté serveur du tissu, de la capacité, de la politique de modèle, du stockage et du coût.
L'authentification est une identité, pas une autorité de charge de travail. Une connexion, une clé API, un devis ou une réservation complétée ne se substituent jamais à la confirmation de service. L'inspection et la génération de plan ne doivent pas créer de charge de travail. L'annulation et le nettoyage sont des mutations séparées avec leurs propres limites de confirmation et d'idempotence.
Cycle de vie et récupération
La surface de production est incomplète tant que le même client canonique n'expose pas les opérations de statut, journaux, métriques, annulation et nettoyage propres au locataire. Chaque opération nécessite des délais d'attente de connexion et globaux limités, des erreurs tenant compte de la révocation, et une sortie structurée. Après un échec de transport ambigu, interrogez le statut via la clé d'idempotence avant de réessayer ; ne créez jamais une seconde charge de travail simplement parce que la première réponse a été perdue. Un identifiant révoqué arrête l'interrogation et rend le contrôle à l'agent d'origine sans démarrer automatiquement la connexion.
Ne signalez ready qu'après que la santé de l'endpoint, l'identité du modèle et l'inférence canari ont tous réussi. Signalez honnêtement les états d'échec intermédiaires et terminaux. Le nettoyage doit être observable et ne doit pas libérer ni modifier la réservation sous-jacente, sauf si cette action économique distincte a été explicitement autorisée.
Étapes proposées du backend
Ces étapes décrivent le futur backend, pas du code existant dans ECC :
- Vérifier les portes de droit, de topologie, de tissu et de coût.
- Récupérer les poids à somme de contrôle figée dans le stockage géré par le backend.
- Émettre et valider un plan de topologie/moteur examinable.
- Lancer via le plan de contrôle du fournisseur, jamais un SSH root direct depuis ECC.
- Chauffer, tester la santé et l'identité du modèle, exécuter un canari SLO, puis enregistrer l'endpoint et la configuration expurgée.
Jusqu'à ce que chaque porte et opération du cycle de vie ci-dessus existe dans l'exécution canonique, cette compétence reste une vérification de disponibilité et un transfert de documentation qui échouent.