Während ich die PIPE-Dokumentation von OpenGradient durchgelesen habe, ist mir etwas aufgefallen, das ich nicht mehr aus dem Kopf bekomme. Wenn ein Smart Contract ein Modell aufruft, zieht der Sequencer die Inferenzanfrage heraus, bevor das Blockbuilding überhaupt beginnt – er führt sie in einem parallelen Mempool aus, verteilt den Job auf GPU-Operatoren und fügt das Ergebnis dann wieder ein. Der Block wartet nie auf das Modell. Beim ersten Lesen klingt das elegant. Aber ich habe immer wieder mit einer Frage gekämpft: Was passiert tatsächlich, wenn zwei konkurrierende GPU-Knoten unterschiedliche Ausgaben für dasselbe Prompt zurückgeben?
Die Dokumentation besagt, dass das erste gültige Bundle gewinnt und Duplikate verworfen werden. Das ist in Ordnung für deterministische Modelle, aber LLMs sind nicht deterministisch. Temperatur, Sampling-Varianz, selbst Unterschiede bei Gleitpunktzahlen über Hardware hinweg können legitimerweise unterschiedliche Ausgaben aus demselben Input erzeugen. Also ist die "Renn"-Mechanik nicht wirklich ein Wettlauf um die Richtigkeit, sondern eher ein Wettlauf um die erste Einreichung. Ich bin mir nicht ganz sicher, ob das aktuelle Design dafür eine klare Antwort hat oder ob es stillschweigend annimmt, dass die Varianz nicht bedeutend genug ist, um zu streiten.
Das bringt mich dazu, über die Bedeutung von "gültig" in der Praxis nachzudenken. Wenn Gültigkeit nur der Nachweis der Ausführung ist und nicht der Nachweis einer spezifischen Ausgabe, dann toleriert das System Nondeterminismus von Natur aus. Das könnte absichtlich sein. Aber für jede On-Chain-Anwendung, bei der die Modell-Ausgabe in eine finanzielle Entscheidung oder eine Governance-Aktion einfließt, fühlt sich die Toleranz für Ausgabevariationen wie eine echte Lücke und nicht wie ein akzeptabler Kompromiss an.
Die Frage, die mir in den Sinn kommt, ist, wie sich das verhält, wenn Entwickler beginnen, hochriskante Modellaufrufe direkt in Smart Contracts im großen Maßstab einzubetten und nicht nur im Testnetz zu experimentieren – naja, die Zeit wird es zeigen👍
#opg $OPG
Die Dokumentation besagt, dass das erste gültige Bundle gewinnt und Duplikate verworfen werden. Das ist in Ordnung für deterministische Modelle, aber LLMs sind nicht deterministisch. Temperatur, Sampling-Varianz, selbst Unterschiede bei Gleitpunktzahlen über Hardware hinweg können legitimerweise unterschiedliche Ausgaben aus demselben Input erzeugen. Also ist die "Renn"-Mechanik nicht wirklich ein Wettlauf um die Richtigkeit, sondern eher ein Wettlauf um die erste Einreichung. Ich bin mir nicht ganz sicher, ob das aktuelle Design dafür eine klare Antwort hat oder ob es stillschweigend annimmt, dass die Varianz nicht bedeutend genug ist, um zu streiten.
Das bringt mich dazu, über die Bedeutung von "gültig" in der Praxis nachzudenken. Wenn Gültigkeit nur der Nachweis der Ausführung ist und nicht der Nachweis einer spezifischen Ausgabe, dann toleriert das System Nondeterminismus von Natur aus. Das könnte absichtlich sein. Aber für jede On-Chain-Anwendung, bei der die Modell-Ausgabe in eine finanzielle Entscheidung oder eine Governance-Aktion einfließt, fühlt sich die Toleranz für Ausgabevariationen wie eine echte Lücke und nicht wie ein akzeptabler Kompromiss an.
Die Frage, die mir in den Sinn kommt, ist, wie sich das verhält, wenn Entwickler beginnen, hochriskante Modellaufrufe direkt in Smart Contracts im großen Maßstab einzubetten und nicht nur im Testnetz zu experimentieren – naja, die Zeit wird es zeigen👍
#opg $OPG