Substrate AI Inference Platform

Vous définissiez un programme comme des nœuds liés par des dépendances, pas comme une suite d'appels HTTP. Substrate lisait d'abord le graphe entier, puis lançait les branches indépendantes en même temps. Sur une tâche avec trois générations de texte en parallèle et une étape de jonction, cette jonction attendait la branche la plus lente au lieu de tout exécuter en file. C'est ce que recouvrait le terme inférence multiple : une requête, plusieurs appels de modèles, un résultat.

La plateforme fournissait des nœuds prêts à l'emploi, sans avoir à héberger un modèle pour démarrer. Génération de texte, extraction JSON à champs typés, génération d'image, transcription audio et embeddings s'appelaient avec le même client. Un schéma courant consistait à rédiger avec un nœud texte, forcer la sortie dans un schéma JSON et stocker le résultat, le tout en une exécution et sans déplacer de données d'un fournisseur à l'autre.

Deux nœuds, l'un pour Python et l'autre pour JavaScript, permettaient d'exécuter du code ordinaire à côté des appels de modèles. Cela couvrait ce que les modèles font mal : lire un CSV, appeler un endpoint interne, remodeler un payload. Le nœud de code tournant dans le même cluster que les nœuds de modèle, vous pouviez leur passer de gros objets intermédiaires sans les sérialiser via votre propre serveur.

Substrate promettait que chaque nœud d'un programme s'exécutait dans le même cluster. Pour l'utilisateur, l'effet concret était moins d'allers-retours et aucune facture de sortie pour transmettre une transcription du nœud audio au nœud texte. La latence devenait aussi plus prévisible sur les longues chaînes, chaque saut étant un appel local et non une requête sur l'internet public.

Le SDK Python et le SDK TypeScript servaient d'interface principale. Les deux permettaient de construire des nœuds comme des objets, de les enchaîner en passant l'un en entrée du suivant et d'inspecter l'exécution ensuite. Ben Guo a passé huit ans à concevoir des API et des SDK chez Stripe, et cela se sent dans l'ergonomie : entrées typées, noms de méthodes courts et un objet d'exécution qui conserve chaque valeur intermédiaire pour rejouer le processus.

Appels de modèles, code maison et stockage des résultats sortaient d'une facture d'usage unique. Pour une petite équipe, c'était la différence entre une facture à rapprocher et quatre, et cela évitait d'acheter des crédits séparément chez chaque fournisseur de modèles. La consommation était mesurée par nœud, ce qui montrait quelle étape du graphe mangeait le budget.