Substrate AI Inference Platform

Você definia um programa como nós com dependências, não como uma sequência de chamadas HTTP. O Substrate lia o grafo inteiro primeiro e depois disparava os ramos independentes ao mesmo tempo. Num trabalho com três gerações de texto em paralelo e um passo de junção, a junção esperava o ramo mais lento em vez de rodar tudo em fila. Era disso que falava o termo inferência múltipla: um pedido, muitas chamadas de modelo, um resultado.

A plataforma trazia nós prontos para você não precisar hospedar modelo algum antes de começar. Geração de texto, extração de JSON com campos tipados, geração de imagem, transcrição de áudio e embeddings eram chamados com o mesmo cliente. Um padrão comum era escrever com um nó de texto, forçar a saída para um esquema JSON e guardar o resultado, tudo numa execução e sem levar dados de um fornecedor para outro.

Dois nós, um de Python e outro de JavaScript, deixavam rodar código comum ao lado das chamadas de modelo. Isso cobria o que modelo faz mal: ler um CSV, chamar um endpoint interno, reorganizar um payload. Como o nó de código rodava no mesmo cluster dos nós de modelo, dava para passar objetos intermediários grandes entre eles sem serializar tudo pelo seu próprio servidor.

O Substrate prometia que cada nó de um programa executava no mesmo cluster. Para quem usava, o efeito prático era menos idas e voltas e nenhuma cobrança de saída ao levar uma transcrição do nó de áudio para o nó de texto. Também deixava a latência mais previsível em cadeias longas, porque cada salto era uma chamada local e não um pedido pela internet.

O SDK de Python e o de TypeScript eram a interface principal. Com os dois você montava nós como objetos, encadeava um como entrada do outro e revisava a execução depois. Ben Guo passou oito anos desenhando APIs e SDKs no Stripe, e isso aparece na ergonomia: entradas tipadas, nomes de método curtos e um objeto de execução que guarda cada valor intermediário para repetir o processo.

Chamadas de modelo, código próprio e armazenamento de resultados saíam de uma única fatura por uso. Para um time pequeno, essa era a diferença entre uma fatura para conferir e quatro, e dispensava comprar créditos separados em cada fornecedor de modelo. O consumo era medido por nó, então dava para ver qual etapa do grafo comia o orçamento.