Vor ein paar Tagen habe ich ein Skript geschrieben, das komplexe, parallele Anfragen simuliert, und habe eine Menge Anfragen an @OpenGradient im Testnetz geschickt, die Bildverarbeitung, finanzielle Textzusammenfassungen und einfache logische Entscheidungsfindungen beinhalteten. Ich hatte ursprünglich vor, die spezifischen Modelle im Model Hub hart zu codieren und manuell für verschiedene Aufgaben festzulegen.
Aber als ich die Dokumentation des zugrundeliegenden Routing-Protokolls durchblätterte, stellte ich fest, dass ich komplett mit der Denkweise von Web2, ‚statische API-Adressen‘, an das Netzwerk herangegangen bin. In dieser Protokollebene ist das harte Codieren von Zielmodellen tatsächlich eine extrem ineffiziente Vorgehensweise.
OpenGradient hat in seiner Architektur einen dynamischen Routing-Engine eingeführt, die als ‚intent-zentriert‘ bekannt ist. Entwickler müssen sich nicht mehr mit der Frage plagen, welches Modell sie verwenden sollen; sie müssen nur eine ‚Intention mit Einschränkungen‘ ins Netzwerk werfen – zum Beispiel: ‚Ich brauche eine Ethereum-Volatilitätsprognose mit einer Abweichungsrate von weniger als 2% und bin bereit, maximal X an Gasgebühren zu zahlen.‘ $ARX
Nachdem diese Intention eingegangen ist, scannt der Routing-Knoten der Protokollebene sofort das gesamte verfügbare Modellportfolio und den aktuellen Zustand der Rechenleistungsknoten. Es bewertet die Verzögerungskosten der TEE-Ausführung und die Rechenaufwände zur Generierung von zkML-Beweisen und weist diese Anfrage automatisch dem Knoten zu, der das beste Preis-Leistungs-Verhältnis aufweist und die kryptographischen Verifikationsschwellen erfüllen kann. Das ist nicht nur die Planung der Rechenleistung, sondern auch die ultimative Ausschöpfung wirtschaftlicher Effizienz. In diesem Prozess ist $OPG das Bietmaterial für die Zuteilung dieser Ressourcen. Das Netzwerk bringt durch die Reibung der Token automatisch Angebot und Nachfrage auf die optimalste Lösung für Recheneffizienz. #OPG