Am Sonntag habe ich meine Lesezeichen durchgeschaut und eine Wettbewerbsübersicht zu AI-On-Chain-„Trajektorien“ gefunden, die ich vor etwa einem halben Jahr abgetippt hatte. Die Anzahl der von den einzelnen Projekten gehosteten Modelle reichte von zweistellig bis dreistellig. Nebenbei habe ich das On-Chain-Panel von @OpenGradient geöffnet: Der Model Hub hat bereits über 4500 Modelle gehostet – mehrere Male so viel wie alle Punkte zusammen in dieser damaligen Tabelle. Ich habe mich nicht gleich ausgiebig gewundert, sondern wollte sehen, ob dieses Volumen wirklich Last trägt oder ob nur viele leere Dateien im System herumliegen, die nie aufgerufen wurden.
Ich habe eine Arbeitswoche mit fünf Tagen gewählt und die am jeweiligen Tag tatsächlich aufgerufenen Modelle aus dem Model Hub anhand von vier Dimensionen herausgezogen: Gewichtshash, Verteilung der Hosting-Knoten, die Scheduling-Logs der Capability-Routing-Middleware sowie die Quittungen der Verification Layer. An jedem der fünf Tage habe ich zwölf Stichproben gezogen – insgesamt 60 Datensätze. Jedes Mal habe ich Upload-Zeitpunkt, Latenz beim ersten Aufruf und die Signatur der Quittung in einer Tabelle Zeile für Zeile gegengeprüft. Das Ergebnis war ziemlich sauber: Von den über 4500 Modellen hatten in der letzten Woche ein beträchtlicher Teil tatsächlich echten Traffic; selbst die Long-Tail-Modelle konnten durch Cold-Starts hochgezogen werden.
In der öffentlichen Diskussion geht es bei den gehosteten Modellzahlen fast ausschließlich um den Vergleich der Menge. Der Unterschied, den OpenGradient tatsächlich nachvollziehbar macht, ist jedoch eher nüchtern: Das Volumen wird nicht durch das Stapeln von Upload-Zählern erzeugt. Jede Gewichtung wird in Walrus in Scheiben geschnitten gespeichert, beim Aufruf von der Capability-Routing-Middleware nach Verfügbarkeit wieder zusammengesetzt und anschließend von der Verification Layer abgestempelt. Das „Hängen“ an das System erfordert die Bindung von Speicherkapazität; der Aufruf hinterlässt in der Quittung eine Spur. Der Aufwand für das „Refreshen von Daten“ ist sogar höher als das eigentliche „Arbeiten“. 4500 sind eine reale Menge an tragbarer Last – keine einzige Zeile in einer Tabelle.
Auch die Kennzahlen müssen anders sein. Ich schaue nicht darauf, wie viele Modelle OpenGradient kumulativ gehostet hat, sondern auf eine nicht-konsensfähige Kennzahl: der Anteil der Modelle, die mindestens einmal pro Woche zu einem echten, bezahlten Aufruf führen und dabei in der Verification Layer eine Quittung hinterlassen. Das Erste misst die Aufnahme in den Bestand; das Zweite misst, ob diese Hosting-Schicht wirklich von Entwicklerinnen und Entwicklern genutzt wird.
Wenn $OPG nur als Matching-Gebühr für einen einzelnen Modellaufruf dient, ist es eher eine Art Token zur Abrechnung von Aufrufen; aber falls die zukünftige Hosting-Kapazität darauf als Sicherheit basiert, Cold-Start-Anreize, das Ausstellen von Quittungen, Long-Tail-Profit-Sharing und sogar Strafzahlungen für „Zombie-Modelle“ um diese Einheit herum als geschlossener Kreis funktionieren, dann ist es nicht mehr nur Abrechnungs-Token, sondern ein Kapazitätskredit-Asset für dieses Modell-Hosting-Netzwerk.
Noch keine voreiligen Schlüsse. Der Vorteil durch das Volumen zählt erst, wenn er im Long-Tail wiederholt verifiziert wird. Ich möchte weiter die OpenGradient-Mainnet- und die darauf folgenden Stichproben ansehen, die die Modellanbieter bei der Integration übergeben.
#opg