Substrate AI Inference Platform

Definías un programa como nodos con dependencias, no como una secuencia de llamadas HTTP. Substrate leía primero el grafo completo y luego lanzaba las ramas independientes al mismo tiempo. En un trabajo con tres generaciones de texto en paralelo y un paso de unión, ese paso esperaba a la rama más lenta en lugar de ejecutarlo todo en fila. De eso hablaba el término inferencia múltiple: una petición, muchas llamadas a modelos, un resultado.

La plataforma traía nodos preparados para no tener que alojar un modelo antes de empezar. Generación de texto, extracción de JSON con campos tipados, generación de imagen, transcripción de voz y embeddings se llamaban con el mismo cliente. Un patrón habitual consistía en redactar con un nodo de texto, forzar la salida a un esquema JSON y guardar el resultado, todo en una ejecución y sin mover datos entre proveedores.

Dos nodos, uno para Python y otro para JavaScript, dejaban ejecutar código corriente al lado de las llamadas a modelos. Eso cubría lo que los modelos hacen mal: analizar un CSV, llamar a un endpoint interno, reordenar un payload. Como el nodo de código corría en el mismo clúster que los nodos de modelo, podías pasar objetos intermedios grandes entre ellos sin serializarlos por tu propio servidor.

Substrate prometía que cada nodo de un programa se ejecutaba en el mismo clúster. Para el usuario, el efecto práctico era menos viajes de ida y vuelta y ninguna factura de salida al pasar una transcripción del nodo de voz al nodo de texto. También volvía la latencia más predecible en cadenas largas, porque cada salto era una llamada local y no una petición a internet.

El SDK de Python y el de TypeScript eran la interfaz principal. Con ambos construías nodos como objetos, los encadenabas pasando uno como entrada de otro y revisabas la ejecución después. Ben Guo pasó ocho años diseñando APIs y SDK en Stripe, y se nota en la ergonomía: entradas tipadas, nombres de método cortos y un objeto de ejecución que guarda cada valor intermedio para repetir el proceso.

Las llamadas a modelos, el código propio y el almacenamiento de resultados salían de una única factura por uso. Para un equipo pequeño eso era la diferencia entre una factura que cuadrar y cuatro, y evitaba comprar créditos por separado a cada proveedor de modelos. El consumo se medía por nodo, así que se veía qué paso del grafo se comía el presupuesto.