Inférence Itô
ito-inference est la compétence ECC unique et canonique pour le service d'inférence sur les
ressources de calcul Itô. Les requêtes nommant ito-serve sont redirigées ici ; ne créez pas ni n'installez 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
un moteur ni n'expose de point de terminaison ; elle ne réserve, ne facture ni ne dépense rien.
Limite actuelle de production
Le service managé n'est pas disponible aujourd'hui. Le pont ECC expose uniquement login,
auth, find, status et des evals explicitement restreintes. Il n'y a pas de verbe serve.
L'exécutable canonique ne documente inference que comme une sonde de compatibilité non
prise en charge ; ECC ne l'invoque ni n'en dépend. La surface MCP n'expose que l'authentification, la recherche
et le statut. La garantie localement applicable est qu'ECC rejette serve
avant de résoudre ou de générer le client canonique porteur d'identifiants.
Par conséquent, arrêtez-vous avant l'authentification ou toute invocation de commande. Signalez
la fonctionnalité manquante et retournez à l'agent d'origine. Ne remplacez jamais par un
exécuteur local, un assistant SSH, un workflow de navigateur, un point de terminaison d'achat ou tout
brouillon local non suivi d'ito-serve.
Droit requis
Lorsque le service sera implémenté, sa première barrière sera une réservation terminée vérifiée par le serveur. La mémoire de la bride, une demande de devis (RFQ), un devis, les adresses IP des nœuds ou l'accès SSH ne constituent pas une preuve de droit. Le backend doit renvoyer une éligibilité de service fraîche liée au compte authentifié, à la réservation, à la topologie GPU, à la région, au réseau, à la durée et à la politique modèle. Les réservations expirées, révoquées, non correspondantes, incomplètes ou déjà libérées échouent en mode fermé avant la confirmation.
Futur contrat CLI et API
Le nom de commande prévu est serve ; inference ne peut subsister que comme 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 <id-de-réservation-vérifié-par-serveur> \
--manifest <fichier-json-absolu-révisé> \
--confirmation-ref <référence-opaque-non-autorisante> \
--idempotency-key <clé-de-reprise-stable> \
--json
Le manifeste révisé doit identifier la révision du modèle, le moteur et sa version, la quantification, la topologie tenseur/pipeline, la politique d'exposition du point de terminaison, 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 maximal. Aucune clé API brute, clé SSH, mot de passe de nœud ou jeton ne doit figurer dans les arguments, les manifestes, les journaux, les résultats MCP ou le chat.
Le client doit canoniser le chemin du manifeste, rejeter les liens symboliques, ouvrir un fichier régulier sans suivre les liens, exiger la propriété appropriée et des permissions restrictives, appliquer une taille limitée et hacher les octets du descripteur ouvert. Ce condensé doit correspondre exactement au condensé lié dans la confirmation avant toute mutation de charge de travail. Un changement de chemin, une non-correspondance du condensé, un fichier trop volumineux ou un fichier instable non sécurisé échoue en mode fermé.
L'API canonique—pas ECC—doit posséder la création de la charge de travail et renvoyer du JSON structuré
avec ok, live_api_contacted, notice, et soit data soit error. Les données
de service doivent inclure les identifiants stables de réservation, de charge de travail, de manifeste et d'idempotence ainsi qu'une
énumération d'état ; elle ne doit pas prétendre qu'un point de terminaison est actif tant que les contrôles de santé et de modèle
ne sont pas réussis. Les erreurs doivent inclure un code stable et un message sûr sans secrets.
Confirmation et barrières d'exécution
Avant la création de la charge de travail, exigez l'ensemble des éléments suivants :
- Un droit frais et une éligibilité de service du backend canonique.
- Un manifeste immuable révisable et un condensé déterministe.
- 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 le droit porté 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 réseau, de la capacité, de la politique modèle, du stockage et du coût.
L'authentification est une identité, pas une autorité de charge de travail. Un identifiant, une clé API, un devis ou une réservation terminée ne remplace 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 distinctes avec leurs propres limites de confirmation et d'idempotence.
Cycle de vie et reprise
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 spécifiques 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 lancer automatiquement la connexion.
Ne signalez ready qu'après que la santé du point de terminaison, l'identité du modèle et l'inférence de test
soient toutes réussies. 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 backend proposées
Ces étapes décrivent le futur backend, pas du code qui existe dans ECC :
- Vérifier les barrières de droit, topologie, réseau et coût.
- Récupérer les poids à somme de contrôle fixe dans le stockage géré par le backend.
- Émettre et valider un plan de topologie/moteur révisable.
- 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 test de qualité de service (SLO canary), puis enregistrer le point de terminaison et la configuration expurgée.
Jusqu'à ce que chaque barrière et opération de cycle de vie ci-dessus existe dans l'exécutable canonique, cette compétence reste une vérification de disponibilité en mode fermé et un transfert de documentation.