Aggiornamento di programmazione

Inferenza distribuita vincolata alle ricevute

Aggiornato 1 settembre 2026 Tradotto ChattyPatty Modifica verificata 2969ff6

Nota tecnica di .

ChattyPatty separa assegnazione temporanea dei fornitori, esecuzione, misurazione, impegno crittografico della ricevuta, contestazione e regolamento, così l’inferenza distribuita rimane verificabile dopo il completamento.

In questa pagina

Cosa è cambiato

Un gateway compatibile con OpenAI valida le buste canoniche delle richieste, applica limiti di token e concorrenza, trasmette in streaming l’output del fornitore e calcola impegni crittografici deterministici delle risposte.

Uno scheduler seleziona i fornitori idonei, assegna lease esclusivi per impostazione predefinita, verifica le ricevute firmate, conserva lo stato di instradamento e riconcilia lo stato dei job con il piano di fiducia Sonic.

Le interfacce dei contratti richiedono l’impegno crittografico di una ricevuta prima di completare un job e conservano record di contestazione limitati, hash delle prove e delle risoluzioni, rimborsi, commissioni e penalità per i fornitori.

Tre autorità, non un unico servizio

Il gateway è responsabile della normalizzazione delle richieste e della contabilità dei token. Lo scheduler decide idoneità dei fornitori, lease e avanzamento dei job. Il contratto on-chain governa deposito a garanzia, impegno della ricevuta, finestre di contestazione e regolamento.

Separare questi ruoli limita ciò che un singolo componente può dichiarare. Un fornitore non può scegliere il proprio conteggio fatturabile del tokenizer; uno scheduler non può segnare un job come regolato senza che lo stato del deposito segua la sequenza richiesta di ricevuta e contestazione.

Le ricevute legano l’esecuzione al pagamento

La busta della ricevuta lega hash della richiesta, impegno della risposta, impronta del modello, digest del runtime, identità del tokenizer e dati di misurazione. La serializzazione canonica impedisce che payload apparentemente equivalenti producano impegni diversi tra servizi.

Il completamento richiede un impegno precedente e corrispondente della ricevuta. Il regolamento attende la finestra di contestazione prevista per la classe di carico; la quota inutilizzata del deposito può essere restituita. L’interfaccia può mostrare subito il risultato in streaming, ma lo stato del pagamento non salta le verifiche per guadagnare velocità.

Capacità e funzionamento degradato

I fornitori iniziano con uno slot esclusivo. La capacità aggiuntiva dipende da hardware attestato, aggiornamento dei benchmark, latenza, tasso di errore e assenza di esaurimenti della memoria, non dal numero di slot dichiarato dal fornitore.

Le chiamate fallite ai fornitori rilasciano il lease. Le attestazioni obsolete rendono i nodi non idonei, le finestre di ritentativo sono limitate e gli snapshot dello scheduler conservano instradamento e lease attraverso i riavvii. Questi percorsi impediscono che un guasto parziale produca doppie assegnazioni o regolamenti ambigui.

Nota di ingegneria

È più semplice fidarsi dell’inferenza distribuita quando esecuzione, misurazione, contestazione e pagamento sono transizioni di stato distinte. Lo streaming può restare rapido mentre il regolamento mantiene verifiche prudenti.

Provenienza

Questa nota si basa sul codice verificato del progetto al commit 2969ff6. Documenta una modifica al software, non un aggiornamento personale.