Nota de programação

Inferência distribuída vinculada a recibos verificáveis

Atualizado 1 de setembro de 2026 Traduzido ChattyPatty Alteração verificada 2969ff6

Nota técnica de .

O ChattyPatty separa a atribuição de leases aos fornecedores, a execução, a medição de consumo, o compromisso do recibo, a contestação e a liquidação, para que a inferência distribuída continue verificável após a conclusão.

Nesta página

O que mudou

Um gateway compatível com OpenAI valida envelopes canónicos de pedidos, aplica limites de tokens e concorrência, transmite a saída do fornecedor em contínuo e calcula compromissos determinísticos da resposta.

Um escalonador seleciona fornecedores elegíveis, atribui leases exclusivos por predefinição, verifica recibos assinados, persiste o estado do encaminhamento e reconcilia o estado das tarefas com o plano de confiança Sonic.

As interfaces dos contratos exigem o compromisso de um recibo antes da conclusão da tarefa e conservam contestações limitadas, hashes de evidência e resolução, reembolsos, taxas e penalizações dos fornecedores.

Três autoridades, não um único serviço

O gateway é a autoridade para a normalização de pedidos e a contagem de tokens. O escalonador é a autoridade para a elegibilidade dos fornecedores, os leases e a progressão das tarefas. O contrato na cadeia é a autoridade para os fundos em garantia, o compromisso dos recibos, os prazos de contestação e a liquidação.

Separar estas funções limita o que cada componente pode afirmar. Um fornecedor não pode escolher a sua própria contagem faturável de tokens, e um escalonador não pode declarar uma tarefa liquidada sem que os fundos em garantia tenham seguido a sequência exigida de recibo e contestação.

Os recibos ligam a execução ao pagamento

O envelope do recibo vincula o hash do pedido, o compromisso da resposta, a impressão digital do modelo, o hash do ambiente de execução, a identidade do tokenizer e os dados de consumo. A serialização canónica impede que conteúdos aparentemente equivalentes produzam compromissos diferentes entre serviços.

A conclusão exige um compromisso prévio de recibo correspondente. A liquidação aguarda o fim do prazo de contestação da classe de carga, e os fundos em garantia não utilizados podem ser devolvidos. A interface pode transmitir um resultado imediatamente, mas o pagamento não dispensa a verificação para ganhar velocidade.

Capacidade e funcionamento degradado

Os fornecedores começam com uma única vaga exclusiva. A capacidade adicional depende do hardware atestado, da atualidade dos benchmarks, da latência, da taxa de erro e da ausência de falhas por falta de memória, não de um número de vagas autodeclarado.

As chamadas falhadas libertam o respetivo lease. Atestados desatualizados retiram os nós da lista de elegíveis, os períodos de nova tentativa são limitados e os instantâneos do escalonador preservam o encaminhamento e os leases após um reinício. Estes percursos impedem que uma falha parcial se transforme numa reserva dupla ou numa liquidação ambígua.

Nota de engenharia

A inferência distribuída é mais fácil de verificar quando execução, medição, disputa e pagamento são transições de estado distintas. A transmissão pode continuar rápida enquanto a liquidação permanece prudente.

Proveniência

Esta nota baseia-se no código verificado do projeto no commit 2969ff6. Documenta uma alteração de software, não uma atualização pessoal.