Lernen mit ONNX für den Handel - Seite 4

 

2020 ONNX-Roadmap-Diskussion Nr. 2 20200909



2020 ONNX-Roadmap-Diskussion Nr. 2 20200909

Im Video „ONNX Roadmap Discussion“ diskutieren die Referenten verschiedene Themen im Zusammenhang mit der Roadmap von ONNX, darunter Shape-Inferenz, Operatordefinitionen, Referenzimplementierungen und die ONNX-Spezifikation. Die Referenten schlagen vor, eine generische Shape-Inferenz-Infrastruktur aufzubauen, um die Form-Inferenz-Optimierung zu verbessern, die Anzahl primitiver Operatoren zu reduzieren, Referenzimplementierungen für jeden Operator hinzuzufügen und besser definierte Testfälle, um eine ordnungsgemäße Implementierung und Prüfung von ONNX sicherzustellen. Die Gruppe plant, die Diskussionen innerhalb des Betreibers SIG und im GitHub-Diskussionsforum fortzusetzen, um einen neuen Betreiber hinzuzufügen.

  • 00:00:00 In diesem Abschnitt diskutieren die Redner die ONNX-Roadmap und behandeln einige vorgeschlagene Themen, insbesondere Formschlussfolgerung, Off-Definition und IR, die alle zuvor im Roadmap-Dokument erwähnt wurden, mit Kommentaren von verschiedenen Personen. Die Redner fragen, ob Changming oder Buchan zur Verfügung stehen, um ihre Vorschläge zu erläutern. Buchan bespricht sein Feedback zu Forminterferenzen und wie er in der Vergangenheit Probleme damit hatte. Er schlägt den Aufbau einer generischen Formeinflussinfrastruktur vor, die die Form bei jeder Änderung des IR neu kompiliert, um sicherzustellen, dass die Forminferenzoptimierung Hand in Hand geht und gleichzeitig die Optimierung verbessert. Die Referenten kommen zu dem Schluss, dass dies eher für die Optimierung gilt als direkt für die Formschlussfolgerung.

  • 00:05:00 Verstehen Sie die aktuellen Möglichkeiten von ONNX in Bezug auf Forminferenz und Optimierungsdurchläufe. Die vorhandene Infrastruktur unterstützt bereits die Forminferenz basierend auf bekannten Eingabewerten und kann verwendet werden, um Ausgabeformen abzuleiten. Bei der Aktualisierung des Modellprüfers kann es zu tief hängenden Früchten kommen, aber andere Änderungen erfordern möglicherweise mehr Diskussion. Die Gruppe diskutiert, ob diese Änderungen in ONNX oder an einen anderen Ort gehören. Sie erwägen auch die Idee, Formschlussverfahren für jeden Operator in aufeinanderfolgenden Schleifen aufzurufen, um die gewünschten Ergebnisse zu erzielen. Letztendlich ermöglicht die vorhandene Infrastruktur bereits Optimierungsdurchläufe und Formschlussfolgerungen, aber Änderungen und Verbesserungen könnten diese Fähigkeiten erweitern.

  • 00:10:00 In diesem Abschnitt erörtern die Referenten die Operatordefinitionen und schlagen vor, die Anzahl primitiver Operatoren zu reduzieren, da andere Operatoren mit untergeordneten Operatoren zusammengesetzt werden können. Sie diskutieren auch das Thema der Referenzimplementierung und die Notwendigkeit der Infrastruktur, um eine Reihe von Operatoren zu evaluieren. Die aktuelle Referenzimplementierung liegt in Form einer Python-Implementierung im Testfallgenerator vor, ist aber nicht so organisiert, dass es einfach ist, eine Folge von Operatoren auszuwerten. Die Referenten schlagen vor, den CIs eine Laufzeit wie die ONNX-Laufzeit hinzuzufügen, um Funktionsunterdiagramme zu verifizieren, die zur Validierung verwendet werden können.

  • 00:15:00 In diesem Abschnitt diskutieren die Referenten die Notwendigkeit von Referenzimplementierungen für jeden Betreiber, um sicherzustellen, dass die Laufzeiten nicht von den Erwartungen des Autors abweichen. Sie schlagen vor, die Referenzimplementierung als Komponententest zu verwenden, um die Parität mit der Laufzeit zu validieren, und auch als Interpretermodus, um die Interoperabilität und Validierung zu überprüfen. Die Referenten weisen darauf hin, dass die Verwendung der ONNX-Laufzeit zur Validierung der Funktion unter der Annahme möglich ist, dass die Funktion aus primitiven Operationen besteht, die in ONNX vorhanden sind. Die Verwendung der ONNX-Laufzeit für neue Operatoren in einem Unterdiagramm, das neue primitive Operationen enthält, ist jedoch nicht möglich, da keine andere Laufzeit diese Implementierung hätte. Sie erkennen an, dass das Erstellen einer Referenzimplementierung viel Arbeit erfordert, aber für jede Operation obligatorisch ist. Sie betonen auch die Notwendigkeit der ONNX-Konformität, um sicherzustellen, dass die Laufzeit nicht von den Erwartungen des Autors abweicht.

  • 00:20:00 In diesem Abschnitt erörtern die Referenten die Verwendung von Referenzimplementierungen in der ONNX-Spezifikation und die Bedeutung einer klaren und prägnanten Sprache in der Spezifikation. Während einige für die Verwendung von Referenzimplementierungen plädieren, um Mehrdeutigkeiten im englischen Text der Spezifikation zu beseitigen, argumentieren andere, dass die Spezifikation klar genug sein sollte, sodass Referenzimplementierungen unnötig sind. Die Referenten diskutieren auch die Bedeutung strenger Konformitätstests, um sicherzustellen, dass alle möglichen Eckfälle getestet werden. Letztendlich scheint der Konsens zu sein, dass Referenzimplementierungen zwar nützlich sein können, aber in der ONNX-Spezifikation nicht erforderlich sein sollten.

  • 00:25:00 In diesem Abschnitt werden die Anforderungen für die Implementierung eines Operators in ONNX erörtert, insbesondere in Bezug auf die Notwendigkeit einer Referenzimplementierung und Testverfahren. Während einige argumentieren, dass eine Referenzimplementierung für den Betreiber zur Generierung von Testdaten obligatorisch sein sollte, sind andere anderer Meinung und sagen, dass es ausreicht, entweder eine Python-Funktion zum Generieren von Testdaten oder einen festen Datensatz bereitzustellen. Es wird jedoch darauf hingewiesen, dass das Vorhandensein einer Referenzimplementierung für jemanden, der den Operator in einer Laufzeitumgebung implementiert, entscheidend ist, um seine Implementierung ordnungsgemäß zu testen, insbesondere für komplizierte Operatoren mit vielen verschiedenen Attributen. Die Diskussion verdeutlicht auch, dass eine Referenzlaufzeit für ONNX zwar nicht erforderlich ist, aber eine Referenzimplementierung für jeden Betreiber erforderlich ist.

  • 00:30:00 In diesem Abschnitt des Videos erörterten die Redner die Bedeutung einer Referenzimplementierung und besser definierter Testfälle, um eine ordnungsgemäße Implementierung und Prüfung von ONNX sicherzustellen. Sie stellten fest, dass es unzureichend sein kann, sich auf generierte Testdaten zu verlassen, und dass die Verfügbarkeit eines einfachen Codes das Problem für alle löst. Das Gespräch berührte auch die Notwendigkeit einer vollständigen Spezifikation und die Freiheit der Laufzeit, zu bestimmen, was in undefinierten Verhaltensfällen zu tun ist. Einige Redner äußerten ihre Besorgnis über die zusätzliche Belastung für diejenigen, die Betreiber vorschlagen, indem sie eine Referenzimplementierung hinzufügen. Sie schlugen vor, den Engineering-Aufwand zu minimieren und die aktuellen Anforderungen für das Hinzufügen von Operationen zum System zu überdenken.

  • 00:35:00 In diesem Abschnitt des Videos diskutieren die Redner, wie wichtig es ist, eine vollständige und eindeutige Spezifikation für ONNX zu haben, und wie sie durchgesetzt werden kann. Sie sind sich einig, dass eine Referenzimplementierung in Python hilfreich wäre, um sicherzustellen, dass Personen, die Operatoren in den Laufzeitumgebungen implementieren, alle Testfälle überprüfen können. Sie erkennen jedoch auch an, dass die Implementierung einer Spezifikation nicht einfach ist und es noch Probleme zu lösen gibt. Sie diskutieren Möglichkeiten zur Klärung, wie die Spezifikation verwendet werden kann, und schlagen vor, dass Praxis und Feedback den Vorschlag neuer Operatoren leiten sollten, anstatt einen Operator vorzuschlagen und ihn dann in einer Laufzeit zu implementieren. Sie weisen auch darauf hin, dass eine Voraussetzung für das Hinzufügen einer neuen Operation darin besteht, dass sie in einem bekannten Framework implementiert werden sollte.

  • 00:40:00 In diesem Abschnitt der ONNX-Roadmap-Diskussion diskutiert die Gruppe den Prozess zum Hinzufügen neuer Betreiber zur ONNX-Spezifikation. Der Vorschlag besteht darin, die Richtlinie zum Hinzufügen eines neuen Operators zu ändern, was bereits eine Referenzimplementierung in Python erfordert. Ihre Diskussion dreht sich um Referenzimplementierungen und Konformitätstests, und sie planen, das Gespräch innerhalb der Betreiber-SIG und im GitHub-Diskussionsforum fortzusetzen. Die Gruppe plant, die Diskussionen bei ihrem nächsten Treffen, das für die folgende Woche geplant ist, fortzusetzen.
 

2020 ONNX-Roadmap-Diskussion Nr. 3 20200916



2020 ONNX-Roadmap-Diskussion Nr. 3 20200916

Die Diskussion in diesem Video konzentriert sich auf verschiedene Themen im Zusammenhang mit ONNX, darunter die Verbesserung der Fehlerbehandlung, das Hinzufügen eines vordefinierten Metadaten-Schemafelds zur Angabe der Erstellung des Modells, die Notwendigkeit der physischen Quantisierungsoptimierung und die Möglichkeit, ONNX-Modelle von Model Zoo auf zu aktualisieren die neuesten Versionen. Das Team plant, diese Themen basierend auf ihren Auswirkungen und Kosten zu priorisieren und nach der Veröffentlichung von 1.8 daran zu arbeiten. Darüber hinaus erwägt die Gruppe die Idee, verschiedene Sprachbindungen für das ONNX-Toolset zu erstellen, mit besonderem Interesse an Java, um verschiedene Plattformen wie Spark zu unterstützen. Die Referenten diskutieren auch die Möglichkeit, einen Java-Wrapper um die ONNX Runtime zu erstellen.

  • 00:00:00 In diesem Abschnitt schlägt der Sprecher vor, drei Themen mit der Community zu diskutieren: Fehlerbehandlung, Verbesserung des Modellzoos und Implementierung weiterer Operationen oder Operatoren für die Quantisierung. Sie planen, die nächsten drei Sitzungen zu nutzen, um über die Kosten und Auswirkungen dieser Themen zu sprechen und eine Priorisierung basierend auf den Elementen mit der größten Auswirkung und den niedrigsten Kosten zu ermitteln. Sie sprechen auch eine Frage zu den Auswirkungen dieser Themen auf Release 1.8 an und erklären, dass die meisten dieser Änderungen nach 1.8 vorgenommen werden. Ein Community-Mitglied schlägt vor, die Fehlerbehandlung zu verbessern, sodass die Laufzeitumgebung nicht beendet wird, wenn sie auf fehlerhafte Protobufs stößt, und stattdessen einen Fehlercode zurückgibt oder eine Ausnahme auslöst, um eine bessere Benutzererfahrung zu gewährleisten.

  • 00:05:00 In diesem Abschnitt konzentriert sich die Diskussion auf die Verbesserung der Fehlerbehandlung des Ladecodes in ONNX, um Abstürze zu verhindern und die Funktionalität zu verbessern. Das Team hat Fuzzing des Codes durchgeführt und festgestellt, dass nicht vertrauenswürdige Modelle das Potenzial haben, den gesamten Prozess zum Erliegen zu bringen, was es zu einer Top-Priorität macht, ihn zu beheben. Die ONNX-Laufzeit hat einen anderen Prüfprozess als der ONNX-Checker, und es ist noch nicht klar, ob sie denselben Checker verwenden können. Darüber hinaus wird das Thema einer besseren Fehlerbehandlung bei Audits angesprochen, und das Team plant, diesem Vorschlag nachzugehen.

  • 00:10:00 In diesem Abschnitt erörtert der Redner seine Bibliothek namens Trivial, die mit dem ONNX-Ökosystem interagiert und ONNX-Modelle bedient. Sie schlagen vor, in ONNX ein vordefiniertes Metadaten-Schemafeld hinzuzufügen, um den Zeitstempel der Erstellung des Modells, den für das Modell verwendeten Trainingsalgorithmus und die zu seiner Generierung verwendete Quellbibliothek anzugeben. Sie schlagen vor, Standardschlüsselnamen für das Metadatenfeld zu definieren und diese ebenfalls einzugeben. Der Sprecher glaubt, dass ein Schema für das Metadatenfeld für Bibliotheken und andere Benutzer, die ONNX-Modelle bedienen, nützlich wäre. Das Gespräch verlagert sich dann auf die Notwendigkeit, Modelltests auszudehnen, um alle Modelle in Model Zoo abzudecken und gute Beispiele mit hoher Qualität bereitzustellen.

  • 00:15:00 In diesem Abschnitt dreht sich die Diskussion um die Notwendigkeit einer physikalischen Quantisierungsoptimierung sowie um die Erweiterung des ONNX-Modellzoos um quantisierte Modelle. Es gab mehrere Anfragen, quantisierte Modelle in den Modellzoo aufzunehmen, und das Team hofft, Mitwirkende zu finden. Sie erwähnen einen Blog, in dem das quantisierte ONNX-Modell von Hugging Face gut abgeschnitten hat, aber sie würden die Erlaubnis von Hugging Face benötigen, um es zu veröffentlichen. Es wurde auch vorgeschlagen, dass das Topmodell der Transformer-Bibliothek ein Beispiel für Quantisierung sein könnte, und Microsoft und Space arbeiten beide daran. Darüber hinaus gab es Diskussionen über die Optimierung, und einige waren sich einig, dass es besser ist, die Optimierung der Laufzeit zu überlassen, da dies über den Rahmen der ONNX-Spezifikation hinausgeht.

  • 00:20:00 In diesem Abschnitt diskutieren die Teilnehmer die Möglichkeit, die ONNX-Modelle von Model Zoo mithilfe des Version Converter-Tools auf die neuesten Versionen zu aktualisieren. Sie stellen jedoch fest, dass der Versionskonverter nicht vollständig auf dem neuesten Stand ist und einige Unsicherheiten darüber bestehen, ob die Konvertierung erforderlich ist, da ONNX alle früheren Versionen unterstützt. Die Gruppe erwägt auch die Idee verschiedener Sprachbindungen für das ONNX-Toolset mit besonderem Interesse an Java, um verschiedene Plattformen wie Spark zu unterstützen. Das Hinzufügen einer Java-API oder von Bindungen würde das Laden und Validieren von Modelldateien und das Erstellen eines Konverters aus anderen Bibliotheken in das ONNX-Format erleichtern.

  • 00:25:00 In diesem Abschnitt erörtern die Referenten die Möglichkeit, einen Java-Wrapper um die ONNX-Laufzeit zu erstellen, der die Dinge für JVM-basierte Machine-Learning-Projekte wie Spark erleichtern würde. Obwohl dies kein triviales Unterfangen ist, könnte die Verwendung der Java-CPP-Voreinstellungen zum automatischen Generieren von Stubs ein guter Ausgangspunkt sein. Abwärtskompatibilität ist für große Projekte wie Spark von entscheidender Bedeutung, und die Ausrichtung auf Java 8 würde erhebliche Arbeit erfordern. Wenn es jedoch genügend Interesse und Bereitschaft der Community gibt, einen Beitrag zu leisten, könnte es eine gute Sache sein, dies zu untersuchen.
 

2020 ONNX-Roadmap-Diskussion Nr. 4 20200923



2020 ONNX-Roadmap-Diskussion Nr. 4 20200923

Der vierte Teil der ONNX-Roadmap-Diskussion behandelt die Themen Datenrahmenunterstützung, Vorverarbeitung, Standardisierung, End-to-End-Machine-Learning-Pipeline und Tool-Empfehlungen. Die Unterstützung von Datenrahmen wird für klassische maschinelle Lernmodelle als wertvoll bewertet und könnte die Notwendigkeit einer Vorverarbeitung beseitigen. Die Notwendigkeit der Erfassung der Vorverarbeitung innerhalb des ONNX-Modells wird hervorgehoben, um die Leistung zu verbessern, wobei der Schwerpunkt auf der Standardisierung von übergeordneten Kategorien wie der Bildverarbeitung liegt. Die End-to-End-Pipeline wird mit niedriger Priorität bewertet, es wird jedoch empfohlen, der Pipeline schrittweise Komponenten hinzuzufügen. Die Diskussion endet mit einer Empfehlung, ein Tool zur Unterstützung der weiteren Diskussion und Analyse der Tagesordnungspunkte zu verwenden.

  • 00:00:00 In diesem Abschnitt erörtern die Redner die ONNX-Roadmap und die von der Community vorgeschlagenen Funktionen. Sie haben bisher drei Abschnitte abgedeckt, darunter die ML-Pipeline und Datenverarbeitung, Op-Definition oder IRS und Kernrobotik. Das Roadmap-Dokument enthält eine Tabelle mit den vorgeschlagenen Funktionen, die mit hoher, mittlerer und niedriger Priorität bewertet werden. Einige der Themen sind jedoch zu allgemein gehalten, was es schwierig macht, ihre Bedeutung einzuschätzen. Die Redner planen, die nächsten 30 Minuten damit zu verbringen, zu diskutieren, warum einige dieser Funktionen hoch bewertet wurden, und Feedback von der Community zu sammeln, welche Funktionen am wichtigsten sind.

  • 00:05:00 fragte, wie die ONNX-Roadmap priorisiert wird, erörtert dieser Abschnitt des Videos die Bedeutung einer Datenrahmen-Unterstützungsfunktion und wie sie möglicherweise andere Probleme innerhalb der Plattform lösen könnte. Der Referent erklärt, dass diese Funktion für Datenwissenschaftler wertvoll wäre und möglicherweise die Notwendigkeit einer Vorverarbeitungsfunktion zunichte machen könnte. Sie erwähnen auch die Notwendigkeit, eine technische Kostenschätzung für jeden Punkt auf der Roadmap zu erhalten, um Aufgaben effektiv zu priorisieren. Vorschläge sind willkommen, da die Roadmap zum ersten Mal auf diese Weise präsentiert wird.

  • 00:10:00 In diesem Abschnitt der ONNX-Roadmap-Diskussion wird die Bedeutung der Unterstützung von Datenrahmen für Modelle des maschinellen Lernens erörtert. Es wird angenommen, dass die Unterstützung von Datenrahmen hauptsächlich für klassische maschinelle Lernmodelle und nicht für DNNs oder andere Modelle gilt. Der Datenrahmen unterscheidet sich von der Sequenz dadurch, dass es sich um eine heterogene Sammlung von Tensoren oder eine relationale Tabelle mit Spalten handelt, die unterschiedliche Typen haben können. Die Wichtigkeit jeder Funktion wird basierend auf ihren Auswirkungen bewertet, und die Engineering-Kosten werden berücksichtigt. Es wird empfohlen, pro Feld einen Kommentar abzugeben, um hervorzuheben, warum eine Funktion von hoher oder niedriger Bedeutung ist.

  • 00:15:00 In diesem Abschnitt wird die Bedeutung der Vorverarbeitung innerhalb eines ONNX-Modells erörtert. Das Gespräch unterstreicht die Notwendigkeit, alle notwendigen Schritte innerhalb des ONNX-Modells zu erfassen, anstatt sich auf externe Bibliotheken zu verlassen, insbesondere im Zusammenhang mit Schulungen, bei denen die Vorverarbeitung einen erheblichen Einfluss auf die Leistung haben kann. Darüber hinaus kann die Vorverarbeitung auf der Inferenzseite nützlich sein, insbesondere wenn es sich nicht um eine Python-basierte Umgebung handelt. Die Diskussion berührt auch die Herausforderungen der Standardisierung der Vorverarbeitung aufgrund der Heterogenität von Datentypen. Obwohl die Vorverarbeitung ein breites und komplexes Thema ist, kommt das Gespräch zu dem Schluss, dass es notwendig ist, fehlende Operatoren und Typen innerhalb von ONNX zu berücksichtigen, um die Vorverarbeitung zu standardisieren.

  • 00:20:00 In diesem Abschnitt erörtern die Referenten das breite Spektrum der Vorverarbeitung und wie sie nicht nur die bildbezogene Verarbeitung, sondern auch Audiodaten umfassen könnte. Während die Vorverarbeitung wichtig zu berücksichtigen ist, weisen die Redner darauf hin, dass es möglicherweise nicht notwendig ist, jeden Datentyp zu unterstützen, und stattdessen eine Standardisierung auf übergeordnete Kategorien wie die Bildverarbeitung für Entwickler vorteilhafter sein könnte. Die Referenten weisen jedoch darauf hin, dass selbst scheinbar einfache Vorverarbeitungsaufgaben wie die Größenänderung von Bildern subtile Randunterschiede zwischen Bibliotheken aufweisen können, was die Standardisierung zu einer technischen Herausforderung macht. Nichtsdestotrotz kann die Standardisierung von Vorverarbeitungsaufgaben hilfreich sein, und die Referenten schlagen vor, gemeinsame Vorverarbeitungsschritte für zukünftige Überlegungen zu sammeln.

  • 00:25:00 In diesem Abschnitt erörtern die Redner die Priorität der Einbeziehung der End-to-End-Pipeline für maschinelles Lernen in ONNX, wobei einige angeben, dass dies angesichts der anderen Punkte, die angegangen werden müssen, eine geringe Priorität hat. Sie erkennen jedoch den Nutzen eines End-to-End-Beispiels und einer Illustration, wie ONNX angewendet werden kann, insbesondere wenn ONNX Runtime in den Mix eingebracht wird. Es wird die Idee vorgeschlagen, der Pipeline nach und nach Komponenten hinzuzufügen, wobei der Schwerpunkt auf dem Trainingsteil, der Feinabstimmung von ONNX und schließlich dem Hinzufügen der Vorverarbeitung in der Mischung liegt. Die Diskussion endet mit der Empfehlung, ein Tool zu verwenden, um die weitere Diskussion und Wirkungsanalyse der Tagesordnungspunkte zu erleichtern.

  • 00:30:00 In diesem Abschnitt dankt der Redner allen für die Teilnahme und informiert das Publikum, dass sie versuchen werden, die Diskussion in den sozialen Medien und auf der ONNX-Website zu veröffentlichen.
 

2020 ONNX-Roadmap-Diskussion Nr. 5 20201001



2020 ONNX-Roadmap-Diskussion Nr. 5 20201001

Während der ONNX-Roadmap-Diskussion diskutierte das ONNX-Team verschiedene Funktionen, die von Community-Mitgliedern vorgeschlagen und von verschiedenen Personen, einschließlich des Lenkungsausschusses, bewertet wurden. Während einige Features einstimmig beschlossen wurden, spalteten andere die Community. Das Team diskutierte die Möglichkeit, ONNX IR auf mehrere IRs und zentralisierte IR-Optimierungsbibliotheken umzustellen. Sie diskutierten auch die Idee, Optimierungsbibliotheken innerhalb von ONNX zu zentralisieren, und die Anforderung, dass Ops eine Standardschnittstelle und einen Codierungsstil implementieren müssen. Das Team erörterte auch die Möglichkeit einer einfachen Laufzeit für ONNX-Modelle und die Verwendung benutzerdefinierter Python-Operationen für Fälle, in denen die ONNX-Laufzeit nicht verfügbar ist. Darüber hinaus untersuchte das Team die Beziehung zwischen Vorverarbeitungsvorgängen und der Verwendung von Datenrahmen und plante, ihre Ideen in umsetzbare Vorschläge für zukünftige Arbeiten umzusetzen.

  • 00:00:00 In diesem Abschnitt erörtert das ONNX-Team die Wirkungsanalysetabelle, die erstellt wurde, um die Gedanken verschiedener Personen darüber zu erfassen, was für das Projekt wichtig ist. Sie listeten alle verschiedenen Funktionen auf, die vorgeschlagen wurden, und hatten Bewertungen von verschiedenen Personen, einschließlich des Lenkungsausschusses und anderer Community-Mitglieder. Sie bemerkten, dass es einige Features gab, bei denen sich alle einig zu sein scheinen, dass es entweder wirklich wichtig oder überhaupt nicht wichtig ist, und andere, bei denen die Community gespalten war. Sie besprachen diejenigen, die gespalten waren, und die nächsten Schritte für diejenigen, denen sie zustimmten, seien wichtig. Sie sprachen auch darüber, Kriterien dafür festzulegen, was als hohe Priorität angesehen wird, und wie dies davon abhängt, wer bereit ist, die Zeit für die Implementierung eines Features zu investieren.

  • 00:05:00 In diesem Abschnitt der ONNX-Roadmap-Diskussion diskutieren die Teilnehmer die Idee, ONNX IR auf mehrere IRs und zentralisierte IR-Optimierungsbibliotheken umzustellen. Es gibt einige Diskussionen darüber, ob diese beiden Ideen zusammen gruppiert werden sollten, da Optimierung und IR getrennte Themen sind. Das Ziel mehrerer IRs besteht darin, einfachere Operationen zu vereinfachen und zu verketten, während Optimierungsbibliotheken das Kern-ONNX verbessern würden. Es gibt weitere Diskussionen darüber, was mit ONNX IR gemeint ist, und es besteht Klärungsbedarf. Die Teilnehmer diskutieren auch, wie sich diese potenziellen Änderungen auf ihre aktuellen Bewertungen auf der ONNX-Roadmap auswirken könnten.

  • 00:10:00 In diesem Abschnitt diskutiert das Team die Möglichkeit, Optimierungsbibliotheken in ONNX zu zentralisieren, stimmt aber letztlich darin überein, dass die Optimierung Teil der Laufzeit sein sollte und im Vergleich zu anderen Themen eine geringere Priorität hat. Sie diskutieren auch die Anforderung, dass Operationen auf eine bestimmte Weise implementiert werden müssen, mit einer Standardschnittstelle und einem Standardcodierungsstil, was bereits eine Anforderung ist, aber möglicherweise angepasst werden muss. Sie schlagen vor, dass, wenn jemand einen bestimmten Stil vorschlägt, dieser akzeptiert werden kann, wenn er akzeptabel erscheint.

  • 00:15:00 In diesem Abschnitt erörtern die Referenten die Idee einer einfachen Laufzeit für ONNX-Modelle, was Bedenken hinsichtlich der Komplexität aufwirft, die erforderlich ist, um einen Ausführungsablauf und eine interne IR zur Verarbeitung des Modells zu benötigen. Es ist jedoch von Vorteil, ONNX-Modelle zum Testen und Feststellen der Korrektheit ausführen und bewerten zu können, insbesondere beim Aufdecken etwaiger Lücken in Einheitentests für Betreiber. Während es fraglich sein mag, wie viel Aufwand und Kosten die Implementierung einer einfachen Laufzeit erfordern würde, hat die ONNX-Laufzeit die Fähigkeit, Python-Operationen einzufügen, die für diesen Zweck verwendet werden könnten.

  • 00:20:00 In diesem Abschnitt sprachen die Teilnehmer der ONNX-Roadmap-Diskussion über die Möglichkeit, eine benutzerdefinierte Python-Operation für bestimmte Fälle zu verwenden, in denen die ONNX-Laufzeit nicht verfügbar ist . Sie diskutierten die Einschränkungen der Python-Operation und die Notwendigkeit einer Standardschnittstelle, um die Machbarkeit zu gewährleisten. Darüber hinaus diskutierte die Gruppe den Bedarf an mehr Vorverarbeitungsfunktionen innerhalb des ONNX-Graphen, um Modelle eigenständiger und portabler zu machen, insbesondere für die bildbasierte Vorverarbeitung wie Skalierung und Handhabung von Begrenzungsrahmen. Die Gruppe stellte fest, dass die Textvorverarbeitung, insbesondere die Tokenisierung, ein komplizierteres und umfassenderes Thema ist, aber sie können möglicherweise einige gängige Vorverarbeitungsszenarien abstrahieren.

  • 00:25:00 In diesem Abschnitt diskutieren die Teilnehmer die Beziehung zwischen Vorverarbeitungsvorgängen und der Verwendung von Datenrahmen. Sie stimmen zwar darin überein, dass Vorverarbeitung und Datenrahmen miteinander verknüpft sind, sehen sie jedoch als separate Einheiten, die unterschiedliche Arten von Arbeit erfordern. Die Vorverarbeitung wird als ein Operator angesehen, der zeilenweise über eine Spalte eines Datenrahmens hinweg arbeitet, während die Datenrahmenextraktion selbst den Vorverarbeitungsoperator über die Zeilen einer Spalte abbildet. Die Gruppe sieht die beiden als eng miteinander verbunden und plant, ihre Ideen in umsetzbare Vorschläge für die zukünftige Arbeit umzusetzen.
 

2021 ONNX-Roadmap-Diskussion Nr. 1 20210908


2021 ONNX-Roadmap-Diskussion Nr. 1 20210908

Während der ONNX-Roadmap-Diskussion stellte IBM Research seinen Vorschlag für ein neues Pipeline-Framework für maschinelles Lernen vor, das typische Datenvorverarbeitungsmuster auf Pandas Dataframe in das ONNX-Format umwandelt. Das Framework namens Data Frame Pipeline ist Open Source auf GitHub und kann mithilfe der bereitgestellten API definiert werden, die während der Trainingsphase auf Python ausgeführt wird. Die Referenten diskutierten auch die Notwendigkeit, ONNX in anderen Sprachen als Python sichtbar zu machen, wie Java, C# und C++, sowie den Export von ONNX-Modellen und deren Ausgabe aus anderen Sprachen. Darüber hinaus diskutierten sie die aktuellen Funktionalitäten der ONNX-Python- und C++-Konverter und die Notwendigkeit von Scoping-, Benennungs- und Patch-Funktionalitäten beim Schreiben von ONNX-Modellen.

  • 00:00:00 In diesem Abschnitt stellt Takuya von IBM Research seinen Vorschlag für ein neues Pipeline-Framework für maschinelles Lernen mit neuen ONNX-Operatoren vor. Die Motivation für den Vorschlag lag in der Unfähigkeit bestehender Pipeline-Frameworks, ein typisches Muster der Datenvorverarbeitung darzustellen. Sie erstellten den Prototyp eines neuen Pipeline-Frameworks namens Data Frame Pipeline on Python, das typische Datenvorverarbeitungsmuster auf Pandas Dataframe in das ONNX-Format konvertiert. Sie schützten drei neue ONNX-Operatoren, darunter einen Datumsoperator und zwei einfache Operatoren, String-Verknüpfer und String-Splitter. Das Pipeline-Framework ist Open-Source auf GitHub und kann mithilfe der bereitgestellten API definiert werden, die während der Trainingsphase auf Python ausgeführt wird. Das Modell wird mit den Daten trainiert, die von der Datenrahmenpipeline ausgegeben werden, und ihr Framework kann bereits konvertierte ONNX-Modelle für maschinelles Lernen verwenden.

  • 00:05:00 In diesem Abschnitt erörtert der Referent das ONNX-Format und wie es mit der von Microsoft bereitgestellten ONNX-Laufzeit verwendet werden kann. Sie erwähnen, dass sie in ihrem Prototyp 11 Datenrahmentransformatoren in Python implementiert und sie ONNX-Operatoren zugeordnet haben, wobei die meisten einfache Zuordnungen sind, einige jedoch eine Analyse und Konvertierung erfordern, wie z. B. der Funktionstransformator. Sie diskutieren auch ihren Ansatz zur Generierung von ONNX-Operatoren mit Eigenschaften geladener Körper, anstatt Aggregationsoperatoren auf ONNX auszuführen. Der Referent teilt vorläufige experimentelle Ergebnisse, die eine signifikante Beschleunigung beim Erlernen der Vorverarbeitung auf ONNX mit einer 300-fachen Leistungsverbesserung für die kategoriale Codierung zeigen. Sie vergleichen auch die Vorhersagegenauigkeit und erwähnen ihren Vorschlag, wodurch sie das Wort für Fragen und Kommentare zu den vorgestellten Operatoren freigeben.

  • 00:10:00 In diesem Abschnitt schlägt Adam Pogba von Oracle Labs vor, dass ONNX in anderen Sprachen als Python sichtbar gemacht werden sollte, da die aktuelle Funktionalität vollständig in Python verpackt ist und es nicht klar ist, ob C++ ein gültiges Ziel für die Bindung ist. Pogba erklärt, dass der Modellprüfer in anderen Sprachen sichtbar sein sollte, damit Benutzer damit interagieren können, ohne eine gültige Python-Umgebung zu benötigen. Darüber hinaus erwähnt Pogba, dass die ONNX-Laufzeit beim Verbrauch von Modellen aufgrund von Parsing-Problemen gelegentlich Segfaults aufweist, und dass der Modellprüfer verwendet werden könnte, um dieses Problem zu validieren und einfach zu beheben.

  • 00:15:00 In diesem Abschnitt erörtert der Referent die Kernfunktionalität der Modellprüfung und wie es nützlich wäre, sie in anderen Sprachen verfügbar zu machen. Obwohl sie es gerne in Java hätten, verstehen sie, dass nicht jeder eine Java-API schreiben würde, daher ist eine C-API eine bessere Option für die meisten Sprachen, an die sie sich leicht binden lassen. Es muss jedoch ein stabiles und geeignetes Ziel für die Bindung vorhanden sein, und es ist nicht sofort klar, ob die C++-API eines dieser Tools als geeignetes Bindungsziel angesehen wird. Der Redner ist bereit, sich an diesen Bemühungen zu beteiligen, aber es lohnt sich nicht, große Anstrengungen zu unternehmen, es sei denn, es besteht Interesse aus der Community.

  • 00:20:00 In diesem Abschnitt erörtert der Referent den Export von ONNX-Modellen und deren Ausgabe aus anderen Sprachen als Python, wie C# und Java, mit besonderem Schwerpunkt auf ML.NET und Trivial Library. Der Referent fordert die Notwendigkeit einer gemeinsamen API, die alle Projekte zur Generierung von ONNX-Modellen verwenden könnten, insbesondere angesichts der derzeit drei verschiedenen Implementierungen ohne gemeinsamen Code, die anfällig für Fehler sind. Die gemeinsame API würde sicherstellen, dass nur ein Ort zum Aktualisieren und Validieren der Knoten und Diagramme vorhanden ist, was eine Möglichkeit bietet, Stärken zu teilen und es anderen Bibliotheken für maschinelles Lernen einfacher macht, ONNX-Modelle auszugeben. Der Redner räumt ein, dass dies zwar eine Menge Arbeit sein könnte, aber die gemeinsame Anstrengung das ONNX-Ökosystem über Python hinaus erweitern könnte.

  • 00:25:00 In diesem Abschnitt diskutieren die Referenten die ONNX-Python- und C++-Konverter und ihre aktuellen Funktionalitäten. Sie stellen fest, dass die ONNX-Dokumentation nicht spezifisch genug ist, was das Verständnis bestimmter Funktionen erschwert. Sie behaupten jedoch, dass viele der für den ONNX-Export erforderlichen Funktionalitäten bereits in diesen Konvertern vorhanden sind, aber für andere Projekte auf die richtige Weise verfügbar gemacht werden müssen. Darüber hinaus erörtern sie die Notwendigkeit von Scoping-, Benennungs- und Patchfunktionen beim Schreiben von ONNX-Modellen. Schließlich schlagen sie vor, dass die Konverter davon profitieren könnten, mit der Architektur-Infrastruktur-Sig verknüpft zu werden, damit sie von verschiedenen Personen problemlos verwendet werden können.
ONNX Roadmap Discussion #1 20210908
ONNX Roadmap Discussion #1 20210908
  • 2021.09.08
  • www.youtube.com
1. Takuya Nakaike (IBM) – New operators for data processing to cover ML pipeline (eg: StringConcatenator, StringSplitter, Date)2. Adam Pocock (Oracle Labs) –...
 

2021 ONNX-Roadmap-Diskussion Nr. 2 20210917



2021 ONNX-Roadmap-Diskussion Nr. 2 20210917

In der ONNX-Roadmap-Diskussion Nr. 2 20210917 diskutierten verschiedene Redner mehrere Schlüsselbereiche, in denen ONNX verbessert werden muss, darunter die Quantisierungs- und Fusionsfreundlichkeit, die Optimierung von Kerneln für bestimmte Hardwareplattformen und das Hinzufügen von modelllokalen Funktionen zu ONNX. Weitere Themen waren Feedback zur End-to-End-Pipeline-Unterstützung, Herausforderungen, mit denen Kunden auf verschiedenen Plattformen konfrontiert sind, und Probleme bei der Konvertierung von GRU- und LSTM-Diagrammen. Einige vorgeschlagene Lösungen umfassten die Bereitstellung von mehr Informationen für Backends zur Ausführung vorquantisierter Graphen, die Verbesserung der Interoperabilität verschiedener Frameworks und die Aufnahme eines Namensraums, der sich auf den ursprünglichen Graphen bezieht, um sowohl eine allgemeine als auch eine optimierte Lösung zu ermöglichen. Darüber hinaus erörterten die Referenten die Notwendigkeit einer besseren Bereitstellung von Paketen für eine breitere Akzeptanz und das Potenzial für die Entwicklung weiterer Konverter zur Unterstützung multimodaler Modelle.

  • 00:00:00 In diesem Abschnitt erörtert Martin von Green Waves Technologies die beiden Bereiche, in denen ONNX verbessert werden muss: Quantisierung und Fusionsfreundlichkeit. Für die Quantisierung schlägt Martin vor, mehr Informationen für Backends bereitzustellen, um vorquantisierte Graphen auszuführen, da es für ONNX unmöglich ist, all den verschiedenen Wegen zu folgen, auf die Kunden spezielle Dinge implementieren möchten. Um dies zu unterstützen, schlägt Martin vor, den Tensoren Min-Max-, Standardabweichungs- und Mittelwertinformationen hinzuzufügen, mit zusätzlichen Informationen wie Ausreißerstatistiken, Kanal-für-Kanal-Informationen und Verteilungsinformationen als mögliche Add-Ons. Für die Fusionsfreundlichkeit schlägt Martin vor, die Interoperabilität verschiedener Frameworks zu verbessern, indem bessere Import-/Exportfunktionen bereitgestellt werden, die es ONNX erleichtern würden, die richtigen Konverter für den Import/Export verschiedener Diagramme zu identifizieren.

  • 00:05:00 In diesem Abschnitt erörtert der Sprecher die derzeitige Verwendung von Funktionen für zusammengesetzte Operatoren und die Schwierigkeit, Kernel für bestimmte Hardwareplattformen zu optimieren, wenn Operatoren aufgelöst werden. Die Idee, exportierte Funktionen unter einem übergeordneten Container, möglicherweise einer Funktion, zu gruppieren und diesen Container einem optimierten Kernel auf einem bestimmten Backend zuzuordnen, wird vorgeschlagen. Der Sprecher schlägt auch vor, einen Namensraum einzubeziehen, der sich auf den ursprünglichen Graphen bezieht, was sowohl eine allgemeine als auch eine optimierte Lösung ermöglicht. Erwähnt wird auch die Möglichkeit, modelllokale Funktionen in der neuesten ONNX-Version zu importieren.

  • 00:10:00 In diesem Abschnitt erörtern die Referenten das Hinzufügen von modelllokalen Funktionen zu ONNX, wodurch Konverterbetreiber einen Funktionskörper als Platzhalter für Operatoren, die nicht im ONNX-Standard definiert sind, in das Modul proto aufnehmen können. Die Redner weisen jedoch auch darauf hin, dass es für Konverter eine bewährte Methode sein sollte, das, was sie exportieren, maschinenlesbar zu kennzeichnen und zu kommentieren. Sie gehen auch darauf ein, wie sich die Optimierung auf Namenskonventionen auswirken kann, und schlagen vor, die Diskussion zu dem Thema entweder im Slack-Kanal oder in einem zusätzlichen Meeting fortzusetzen. Die nächste Präsentation, in der es um die ONNX-Profilerstellung geht, wird vorgestellt.

  • 00:15:00 In diesem Abschnitt wird ein Feedback zur End-to-End-Pipeline-Unterstützung diskutiert, wobei ONNX als hervorragend geeignet für leichtgewichtige Bereitstellungen auf verschiedenen Betriebssystemen angesehen wird, die keine hohen Anforderungen an das Ökosystem stellen. Die Redner äußern die Hoffnung, dass es ONNX-Betreibern sowohl in ONNX als auch in ONNX ML ermöglicht wird, nicht nur Modelle, sondern auch Datenvorbereitungsphasen auszuführen, einschließlich anderer Arten von Datenproduktionsvorgängen. Sie behaupten, dass ein vereinfachtes oder gemeinsames Bereitstellungsartefakt oder -modell einen Mehrwert schaffen könnte, zusammen mit der Möglichkeit, Aufwand und Konsistenz zu sparen, indem man sich auf niedrig hängende Früchte rund um Standardkonvertierungen konzentriert.

  • 00:20:00 In diesem Abschnitt erörtert der Redner einige der Herausforderungen, mit denen Kunden auf verschiedenen Plattformen konfrontiert sind, und weist auf den potenziellen Wert der Weiterentwicklung und Erweiterung der ONNX-Plattform hin. Sie sprechen das Thema Siloing und die Notwendigkeit an, die Bereitstellung von Paketen für eine bessere Akzeptanz zu vereinfachen. Das Gespräch enthält auch Kommentare eines Teilnehmers, der bestätigt, dass er mit ähnlichen Problemen konfrontiert ist, und Optionen vorschlägt, um den Linux-Server ONNX zusammenzuführen oder bessere Wege zu finden, um Benutzern zu helfen, benutzerdefinierten Code in ONNX zu konvertieren. Der Referent geht auch auf das Thema multimodale Unterstützung und die Notwendigkeit ein, ein Ensemble von Modellen als einen einzigen ONNX-Graphen darzustellen. Sie diskutieren den potenziellen Bedarf an mehr Konvertern und schlagen eine allgemeine Bewegung in die richtige Richtung vor.

  • 00:25:00 In diesem Abschnitt der ONNX-Roadmap-Diskussion erörtert das Team Beispiele für Proxys für Proxy-Modelle, um die Arten von Dingen zu demonstrieren, die Kunden in Unternehmensumgebungen für Nicht-Bild-Anwendungsfälle verwenden. Ein Teammitglied erwähnt ein Beispiel für einen Proxy für ein Betrugserkennungsmodell, das einige offene Daten verwendet und ein relativ einfaches zweischichtiges LSTM-Modell ist. Das Team untersucht die Angelegenheit weiter und versucht, weitere Beispiele für Proxy-Modelle vorzubringen. Sie diskutieren auch Probleme mit GRU und LSTM, die nicht korrekt konvertiert werden, und erwähnen, dass sie gerne Unterstützung für alle Fälle hinzufügen würden.

  • 00:30:00 In diesem Abschnitt erörtern die Referenten die Herausforderungen bei der Konvertierung von GRU-Graphen (Gated Recurrent Unit) in ein Format, das vom Konverter eines Backends gelesen werden kann. Sie erwähnen, dass es bestimmte Fälle gibt, in denen der Ausfall bereits in TensorFlow auftritt, es jedoch schwierig ist, ihn wieder in GRU umzuwandeln. Sie schlagen vor, das `--custom ops`-Flag zu verwenden und einen Kernel zu erstellen, der dafür funktioniert, bevor sie zu der Idee übergehen, es zu einer Funktion zu machen oder es in Bezug auf die Semantik beizubehalten. Sie weisen darauf hin, dass die beste Option darin besteht, explizit anzugeben, ob der Benutzer eine Aufschlüsselung wünscht oder nicht, und dass die Verwendung von benutzerdefinierten Operationen möglicherweise die einzige Möglichkeit ist, dies robust zu tun.

  • 00:35:00 In diesem Abschnitt diskutieren die Redner, ob es besser ist, den vollen Funktionskörper sowohl in ONNX als auch auf hohem Niveau zu haben oder nur eine TF-Basis zu haben. Für sie wäre die TF-Basis ausreichend, da der ONNX als Ergebnisnachweis entlang der Kette verwendet werden könnte. Sie warnen jedoch davor, ONNX TensorFlow-zentrisch zu machen, da ONNX in der Lage sein sollte, von verschiedenen Orten zu kommen. Sie sprachen auch die Attraktivität eines benannten Untergraphen mit einer semantischen Bedeutung an und betrachteten ihn fast als einen Operator, der von verschiedenen Front-Ends definiert und generiert werden muss. Schließlich einigten sie sich auf tiefere Präsentationen, um die Diskussion mit sachkundigeren Personen fortzusetzen.
ONNX Roadmap Discussion #2 20210917
ONNX Roadmap Discussion #2 20210917
  • 2021.09.17
  • www.youtube.com
1. Martin Croome (Greenwaves) – Add meta information in tensors2. Andrew Sica (IBM) – E2E pipeline with ONNX operators (include Keras, TF, Scikit-learn/Spark...
 

2021 ONNX-Roadmap-Diskussion Nr. 3 20210922



2021 ONNX-Roadmap-Diskussion Nr. 3 20210922

Während der ONNX-Roadmap-Diskussion sprachen die Referenten die Notwendigkeit an, Probleme mit dem Offset-Konvertierungstool von ONNX zu beheben, um die Akzeptanz von ONNX mit dem neuesten optimierten Stack für bestimmte Anwendungsfälle zu verbessern. Die Referenten schlugen eine bessere Abdeckung von Modellen zum Testen von Offset-Konvertierung und Auflösung von Zwischenschritten vor, die derzeit bei Operator- oder Layer-Tests fehlen. Sie erörterten auch die Bedeutung von Metadaten und der föderierten Lerninfrastruktur, einschließlich der Notwendigkeit, Metadaten in die ONNX-Spezifikation für Anmerkungen zum Transferlernen aufzunehmen, und das Konzept des föderierten Lernens, um Datenschutz, Effizienz und Nutzung von Rechenressourcen zu ermöglichen. Die Redner ermutigten die Community zur Zusammenarbeit und baten um Feedback, um diese Ideen weiter zu diskutieren und umzusetzen. Die nächste Sitzung ist für den 1. Oktober geplant.

  • 00:00:00 In diesem Abschnitt befasst sich Manoj von Intel mit Lücken bei Offset-Konvertierungen für ONNX-Modelle, die bei vielen Kunden Probleme verursacht haben. Das grundlegende Problem liegt in der Offset-Konvertierung, da viele Kunden den Offset nicht ständig aktualisieren, sobald sie ein Modell in der Produktion einsetzen. Kunden stehen bei der Offset-Konvertierung vor mehreren Problemen, z. B. wenn sie zur Quantisierung von 7 auf 10 auf 13 umsteigen oder ältere Offsets nicht in neuere konvertieren können, um die Leistung und gute Genauigkeit zu nutzen. Darüber hinaus sind der Unit-Test oder alle Tests, die sich auf jeden Operator oder Layer beziehen, nicht auf dem Stand, an dem ISVs zufrieden sind, und daher sind die meisten Kunden immer noch auf 10 oder 9 Offset.

  • 00:05:00 In diesem Abschnitt erörtern die Redner die Notwendigkeit, Probleme mit dem Offset-Konvertierungstool von ONNX zu lösen, da es die Einführung von ONNX mit dem neuesten optimierten Stack für bestimmte Anwendungsfälle behindert. Entwickler, die KI integrieren und in ihre Anwendungen ausliefern, geben Feedback zur Notwendigkeit, Konvertierungstools zu reparieren und sicherzustellen, dass sie nahtlos funktionieren. Sie teilen Beispiele für Probleme, mit denen sie konfrontiert waren, wie fehlende Zwischenschritte und fehlende Adapterimplementierungen, die den Übergang zu quantisierten Leistungsmodellen verhindern. Die Redner betonen die Notwendigkeit einer besseren Abdeckung und mehr zu testender Modelle, um eine bessere Akzeptanz von ONNX zu gewährleisten.

  • 00:10:00 In diesem Abschnitt des Videos erörtern die Redner die Notwendigkeit der Genehmigung mindestens eines fehlerhaften Modells von einem führenden Entwicklerunternehmen für weitere Verbesserungen in ONNX. Die Diskussion geht weiter zur Verbesserung der FP16-Konvertierung, die eine der Lücken zwischen verschiedenen Ökosystemen wie Mobilgeräten und Windows war, und wie sie in letzter Zeit mit Microsoft-Konvertertools behoben wurde. Die Verantwortung für die Konvertierung ist unklar, aber die Diskussion geht zur nächsten Präsentation über den Modellzoo über, wo die Einbeziehung von Phonikoperatoren für die Schulung dazu beitragen wird, alle Modelle in allen Kategorien abzudecken. Sie schlagen vor, mit Transformer- oder NLP-Trainingsbeispielen zu beginnen und zu weiteren Modellen überzugehen, um verteilte Trainingsinfrastruktur und Techniken zu präsentieren, die auf ONNX anwendbar sind.

  • 00:15:00 In diesem Abschnitt erörtern die Referenten die Einbeziehung von ONNX-Modellen in das Training, einschließlich der Bedeutung von quantisierungsbewusstem Training und gemischter Präzisionsnutzung. Sie fordern das ursprüngliche fp32-Modell an, um die Genauigkeit besser zu vergleichen und die gemischte Präzisionsnutzung für das Training mit ONNX-Modellen zu demonstrieren. Sie priorisieren den Beitrag zu Transformer-Mustern, bitten aber die Community um Hilfe, um andere beliebte Kategorien beizusteuern. Sie diskutieren auch zukünftige Vorschläge, um die gemischte Präzisionsnutzung innerhalb eines Modells als Teil von Metadaten besser widerzuspiegeln. Abschließend stellt Gabe Stevens eine Bereitstellungskonfiguration vor, die sich Intel derzeit ansieht.

  • 00:20:00 In diesem Abschnitt erörtert der Referent das Konzept des verteilten und föderierten Lernens und seine Vorteile in Bezug auf Datenschutz, Latenz, Effizienz und Nutzung von Rechenressourcen. Die Idee ist, Modelle auf einer Flotte von Geräten bereitzustellen, wobei einige der Geräte eine Trainingsgruppe haben, die das Modell mit den Daten, die sie sehen, anreichert. Die vorgeschlagenen Änderungen an ONNX würden es ermöglichen, das föderierte Lernen zu erleichtern, wodurch es für Entwickler wahrscheinlicher wird, ONNX zu verwenden. Der minimale Satz von Ergänzungen zur API umfasst eine Möglichkeit, das Teil abzufragen, um die Parameter des lokalen Modells abzurufen, diese Parameter zu aktualisieren und den Server darüber zu benachrichtigen, wie sich das Modell geändert hat, um es in ein neues Modell zu konsolidieren, das die Ergebnisse aus der enthält Geräte.

  • 00:25:00 In diesem Abschnitt des Videos erörtert der Sprecher die Idee, Metadaten in die ONNX-Spezifikation aufzunehmen, um die Übertragung von Lernanmerkungen zu ermöglichen und es einfacher zu machen, einen kleineren Datensatz mit einem Modell zu trainieren, das auf einem größeren Datensatz trainiert wurde. Die Implementierung eines solchen Systems erfordert jedoch mehrere Entwurfsentscheidungen, die den Implementierern überlassen werden müssen. Der Redner schlägt drei Elemente vor, die die grundlegende Infrastruktur eines solchen Systems erleichtern könnten, ohne die für Anwendungsentwickler erforderliche Flexibilität einzuschränken. Sie erwähnen auch die Notwendigkeit der Konsistenz bei der Bereitstellung von Modellversionen über eine Flotte von Geräten hinweg und die Wichtigkeit, nicht vorzuschreiben, dass nur ONNX-Modelle an einem föderierten Lernsystem teilnehmen dürfen. Der Referent bittet um Rückmeldung, ob die Spezifikationsdesigner daran interessiert sind, auf diese Art der Lernkonfiguration zu achten, und ob sie für weitere Diskussionen offen wären. Ein anderer Redner schlägt vor, dies mit der ONNX-Laufzeit zu versuchen, da sie das Training unterstützt und einige Proof-of-Concepts für die Durchführung von föderiertem Lernen erstellt wurden.

  • 00:30:00 In diesem Abschnitt drückt der Sprecher seine Wertschätzung für die enorme Mühe aus, die in die Präsentation gesteckt wurde, und dankt der Community für ihre Fragen. Ziel der Präsentation ist es, der zuständigen SIG Ideen zur weiteren Diskussion und eventuellen Umsetzung vorzustellen. Die letzte Sitzung findet am 1. Oktober statt, und der Referent freut sich auf die weitere Beschäftigung mit diesen Ideen.
ONNX Roadmap Discussion #3 20210922
ONNX Roadmap Discussion #3 20210922
  • 2021.09.27
  • www.youtube.com
1. Rajeev Nalawadi & Manuj Sabharwal (Intel) – Address gaps with Opset conversions across broad set of models2. Rajeev Nalawadi (Intel) – ONNX model zoo exam...
 

Virtuelles Meetup der ONNX-Community – März 2021



000 ONNX 20211021 ONNX SC Willkommen Fortschritts-Roadmap-Veröffentlichung

Der ONNX-Workshop begann mit einer Einführung, in der die Organisatoren die Bedeutung der Beteiligung der Community am Wachstum des ONNX-Ökosystems betonten. Sie gaben auch einen Überblick über die Tagesordnung, die Aktualisierungen zu ONNX-Statistiken, Community-Präsentationen und die Roadmap-Diskussionen des ONNX-Lenkungsausschusses umfasste. Die Roadmap-Vorschläge zielen darauf ab, die Unterstützung, Robustheit und Benutzerfreundlichkeit des ONNX-Frameworks zu verbessern und umfassen Vorverarbeitungsoperatoren, C-APIs, föderiertes Lernen und eine bessere Integration von Datenverarbeitung und Inferenz. Die jüngste Veröffentlichung von Version 1.10 der ONNX-Spezifikationen wurde ebenfalls diskutiert, und die Teilnehmer wurden ermutigt, Fragen zu stellen und am ONNX-Slack-Kanal teilzunehmen, um das Gespräch fortzusetzen.

  • 00:00:00 In diesem Abschnitt des Workshops geben die Organisatoren einen Überblick und begrüßen alle Teilnehmer. Sie erwähnen die große Auswahl an Produkten, die für KI verfügbar sind, und fordern die Teilnehmer auf, sich diese anzusehen. Das übergeordnete Ziel des Workshops besteht darin, die neuesten Updates zu ONNX, seinen Prozessen, seiner Roadmap und seinen Releases zu erhalten sowie von Community-Teilnehmern zu erfahren, wie ONNX verwendet wird. Sie ermutigen die Teilnehmer, ihr Feedback zu teilen und sich stärker im ONNX-Lenkungsausschuss, den SIGs und Arbeitsgruppen zu engagieren. Sie geben einen Überblick über die Agenda, die die Logistik der ONNX-Arbeitsgruppe, die State of the State-Präsentation von Wenming Yi, gefolgt von Alex, und Community-Präsentationen umfasst. Schließlich präsentieren sie aufregende Updates zu den Statistiken von ONNX, darunter eine fast 400-prozentige Steigerung der monatlichen Downloads auf 1,6 Millionen pro Monat, was ein gesundes Wachstum des Ökosystems zeigt.

  • 00:05:00 In diesem Abschnitt erörtert der Redner den Fortschritt und das Wachstum des ONNX-Ökosystems und betont die Bedeutung von Beiträgen von Unternehmen in der Community. Der Redner erwähnt das Deep-Java-Bibliotheksprojekt von Amazon, das gute Erfahrungen für die Java-Community gemacht hat und stark gewachsen ist. Mehrere kommerzielle Unternehmen wie IBM, AMD und Sony unterstützen das Ökosystem und helfen ONNX dabei, zum Industriestandard zu werden. Der Redner spricht auch über die Governance der Community und die neuen Mitglieder des Lenkungsausschusses und lädt zur Teilnahme an den Roadmap-Diskussionen, dem Slack-Kanal, Q&A auf GitHub und Beiträgen zur Dokumentation und zu den Blogs ein. Der nächste Redner folgt mit der Roadmap, die entscheidend ist, um in die richtige Richtung zu gehen und ONNX-Modelle auf Batterien für CPU und Beschleuniger zu reduzieren.

  • 00:10:00 In diesem Abschnitt erörtert der Redner die Roadmap-Diskussionen des ONNX-Lenkungsausschusses, die im Sommer stattfanden. Die von verschiedenen Mitgliedern eingegangenen Vorschläge werden in vier Gruppen mit jeweils drei Vorschlägen aufgeteilt, und jede Gruppe wird den jeweiligen Sigs zur Genehmigung und Umsetzung vorgelegt. Die Vorschläge reichen von Vorverarbeitungsoperatoren, C-APIs, Modellprüfung, Unterstützung für die Ausgabe von Modellen in anderen Sprachen, Hinzufügen von Metadateninformationen in Tensoren, bessere Integration von Datenverarbeitung und Inferenz, Definition von Konzepten für föderiertes Lernen, Definition von Metadatenverarbeitungseigenschaften zur Verbesserung der Integrität von Daten, Modellen und mehr. Ziel ist es, eine bessere Unterstützung, Robustheit und Benutzerfreundlichkeit des ONNX-Frameworks für alle Benutzer zu ermöglichen.

  • 00:15:00 In diesem Abschnitt erörtert der Redner die kürzliche Veröffentlichung von Version 1.10 der ONNX-Spezifikationen und dankt den Mitwirkenden für ihre harte Arbeit. Es wird weitere Diskussionen und Details zu dieser letzten Änderung auf der next.ai-Website geben. Der Redner lädt das Publikum ein, Fragen im Chat oder im allgemeinen Slack-Kanal von ONNX zu posten, um das Gespräch fortzusetzen.
000 ONNX 20211021 ONNX SC Welcome Progress Roadmap Release
000 ONNX 20211021 ONNX SC Welcome Progress Roadmap Release
  • 2021.11.06
  • www.youtube.com
Event: LF AI & Data Day - ONNX Community Meeting, October 21, 2021Talk Title: ONNX Steering Committee (SC) Update - Host Welcome, Progress, Governance, Roadm...
 

ONNX-Community-Tag! Livestream am 24. Juni 2022

Diese Veranstaltung findet am Freitag, den 24. Juni, persönlich auf dem brandneuen Microsoft Silicon Valley Campus statt.

Die Veranstaltung umfasst Updates der ONNX-Community, Partner- und Benutzergeschichten sowie zahlreiche Community-Netzwerke.



ONNX-Community-Tag!

Kurze Zusammenfassung:

  • 00:00:00 - 01:00:00 Das YouTube-Video "ONNX Community Day!" erörtert Aktualisierungen und Verbesserungen der Arbeit der ONNX-Community zur Interoperabilität und Flexibilität für Entwickler, die mit Modellen für maschinelles Lernen arbeiten. Die ONNX-Community arbeitet unter Open Governance, und die drei Kategorien von Tools, Erstellung, Betrieb und Visualisierung, unterstützen das Engagement und die Nutzung von ONNX durch die Community. Das Video bietet Fortschrittsberichte zu verschiedenen Aspekten, wie z. B. Aktualisierungen der ONNX-Spezifikationen, neue Operatoren und Verbesserungen bei Konvertern. Der Redner hebt auch die Vorteile von ONNX hervor, darunter das breitere Kundenspektrum für Hardwareanbieter und den Zugriff auf mehrere Frameworks und Hardwarebeschleuniger für Benutzer. Die Zukunft von ONNX umfasst die Vorstellung von ONNX-Funktionen zur Bereitstellung einer ausführbaren Spezifikation.

  • 01:00:00 - 02:00:00 Die ONNX Community Day-Veranstaltung diskutiert mehrere Themen im Zusammenhang mit ONNX, einschließlich ONNX Model Zoo und ONNX Tutorials, die vortrainierte Modelle für maschinelles Lernen und Demos zur Verwendung mit ONNX-Modellen bereitstellen. Das Video hebt die Arbeit der ONNX Preprocessing Working Group hervor, die darauf abzielt, Datenvorverarbeitungsvorgänge zu standardisieren, um die Modellbereitstellung zu verbessern. Die Referenten diskutieren auch die Grundlagen der Quantisierung neuronaler Netze und wie TensorRT quantisierte Netze durch verschiedene Fusionen unterstützt, einschließlich Quantisierung nach dem Training und quantisierungsbewusstes Training. Sie vertiefen sich auch in die Grenzen von ONNX bei der Darstellung von Quantisierung mit geringer Genauigkeit und schlagen eine Strategie vor, um seine Darstellungskraft durch Clipping zu erweitern, um Präzision zwischen den quantisierten und dequantisierten Knoten zu induzieren. Schließlich befasst sich das Video mit einer Fallstudie zur Genauigkeit eines quantisierten und feinabgestimmten gespeicherten TensorFlow-Modells.

  • 02:00:00 - 03:00:00 Der ONNX Community Day präsentierte zahlreiche Redner, die die Bedeutung von Metadaten in Modellen für maschinelles Lernen und die Unterstützung von Java Virtual Machine (JVM) in ONNX diskutierten. Die Redner betonten die Verwendung hardwarebasierter Technologien zum Schutz von Daten und hoben die Kompatibilität von ONNX mit verschiedenen Bibliotheken für maschinelles Lernen hervor, darunter DeepJ und Deep Java Library. Sie demonstrierten die Verwendung von Bytepuffern für eine bessere Effizienz und diskutierten die Bedeutung der Standardisierung von Metadaten für eine verantwortungsbewusste und erklärbare KI. Die Präsentationen enthielten auch Erfolgsgeschichten, darunter die verbesserte Laufzeit einer chinesischen Bank mit ONNX und ONNX Runtime. Die ONNX-Community arbeitet an der Erstellung, Abfrage und Filterung von Metadaten aus Hubs-Workflows mit Unterstützung für maschinenlesbare Metadaten in ONNX. Insgesamt hoben die Präsentationen die Stärken der ONNX-Plattform und das Engagement der Community für ihre Entwicklung hervor.

  • 03:00:00 - 04:00:00 Der "ONNX Community Day!" Das Video behandelt verschiedene Updates und Funktionen im Zusammenhang mit dem ONNX-Ökosystem. Dazu gehören Diskussionen über die Simulation der Quantisierung, um den Genauigkeitsabfall zwischen quantisierten und vortrainierten Modellen zu reduzieren, die Bereitstellung von TensorFlow-Modellen, die mit NVIDIAs Toolkit trainiert wurden, auf einem ONNX-Graphen mit TensorRT und Verbesserungen an ONNX Runtime, wie z. B. optimierte Tensorform, Ausführungsanbieter und Unterstützung für mobile Plattformen. Darüber hinaus wurden Updates für ONNX selbst besprochen, darunter die Unterstützung der XNNpack-Bibliothek und die Erstellung von ONNX-Laufzeiterweiterungen für Vor-/Nachverarbeitungsaufgaben. Das Video stellt auch die Bibliothek Optimum vor, die sich auf die Beschleunigung von Transformatormodellen vom Training bis zur Inferenz konzentriert.

  • 04:00:00 - 05:00:00 Der ONNX Community Day beinhaltete Diskussionen zu verschiedenen Themen rund um die ONNX-Laufzeit und ihre Anwendungsfälle. Die Referenten beschrieben die Funktionen des ONNX-Laufzeitpakets, des PiTorch-ONNX-Konverters und benutzerdefinierter Ops in PyTorch. Sie diskutierten auch Anwendungsfälle wie Prozessüberwachung und Digitalisierung des Handels sowie Herausforderungen im Zusammenhang mit Modellbereitstellung und Kompatibilitätstests. Während der gesamten Veranstaltung wurde betont, dass die ONNX-Laufzeitumgebung dazu beitragen kann, die Leistung zu verbessern und die Bereitstellungsgröße zu reduzieren, aber Kompatibilität und Auswahl sind unerlässlich, um konsistente Qualität und Geschwindigkeit sicherzustellen.

  • 05:00:00 - 06:00:00 Am ONNX Community Day diskutierten mehrere Redner verschiedene Tools und Techniken, die zur Optimierung und Bereitstellung von Modellen für maschinelles Lernen mit dem ONNX-Framework verwendet werden. NVIDIA erläuterte seinen Ansatz zur Verbesserung der Bildqualität und Modellkompatibilität mithilfe von Blockaufteilung für Inferenz sowie seine ONNX-spezifischen Tools zum Debuggen und Modifizieren von Modellen. Qualcomm erklärte, wie sie KI-Beschleuniger mithilfe von ONNX als Austauschformat in ihre Designs integriert haben, und stellte ihren Software-Stack vor, der die ONNX-Laufzeit und verschiedene Tools zur Optimierung und Bereitstellung umfasst. Darüber hinaus erörterten mehrere Referenten die Optimierung von ONNX-Modellen mithilfe von Techniken wie Moduloptimierung, Checkpointing und Shape-Inferenz. Die Veranstaltung hob die Vielseitigkeit und Skalierbarkeit von ONNX für verschiedene Geräteanwendungsfälle hervor und ermutigte zu Beiträgen zum weiteren Ausbau des ONNX-Projekts. Der letzte Teil konzentriert sich auf die Vereinfachung des Prozesses der Bereitstellung von Modellen für maschinelles Lernen in Spark mithilfe des SPIP-Vorschlags, der darauf abzielt, die Komplexität der Umwandlung der Registerkartenverarbeitung und der Modellinitialisierung für Entwickler zu verbergen. Das Ascend-KI-Ökosystem und seine Prozessoren wurden vorgestellt, einschließlich der Softwareschicht „Kung“, die APIs zum Erstellen von KI-Anwendungen und -Diensten bereitstellt. Der Khan-Software-Stack wurde besprochen und die Roadmap für das Hinzufügen als neuer Ausführungsanbieter für die ONNX-Laufzeit vorgestellt. Die Veranstaltung endete mit Roundtable-Diskussionen zu Themen wie ONNX für Mobile und Edge, Modellbereitstellung, Schulung und Betrieb, Konvertierungen und Betreiber, gefolgt von einer Happy Hour und Umfrage-Feedback.

Die detaillierte Timeline-Zusammenfassung:
  • 00:15:00 Erstellen Sie den Modus im Framework, den Sie bevorzugen, und exportieren Sie dann Ihr Modell in ein gemeinsames Format, das von anderen Frameworks und Tools verwendet werden kann. Dies ermöglicht eine größere Interoperabilität und Flexibilität für Entwickler, die mit maschinellen Lernmodellen arbeiten. Darüber hinaus ist ONNX für Hardwareanbieter von Vorteil, die optimierte Laufzeiten für maschinelle Lernmodelle erstellen möchten, da sie sich jetzt auf die Unterstützung der von ONNX definierten gemeinsamen Gruppe von Operatoren konzentrieren können, anstatt mehrere verschiedene Frameworks unterstützen zu müssen.

  • 00:20:00 In diesem Abschnitt erörtert der Referent die Vorteile der Verwendung von ONNX, das den Zugriff auf mehrere Frameworks und Hardwarebeschleuniger für Benutzer sowie einen breiteren Kundenkreis für Hardwareanbieter ermöglicht. Die ONNX-Entwicklung wird von der Community unter Open Governance durchgeführt, was bedeutet, dass es kein einzelnes Unternehmen gibt, das sie kontrolliert. Der Redner hebt auch die Arbeitsgruppen hervor, zu denen Architektur und Infrastruktur, Operatoren, Konverter, die Modellzone, Tutorials und eine neue Vorverarbeitungs-Arbeitsgruppe gehören. Der Referent umreißt anschließend die drei Kategorien von Tools, Erstellung, Ausführung und Visualisierung von ONNX-Modellen, und liefert einige Statistiken der letzten sechs Monate, wie z. B. eine Zunahme der Anzahl von PRs, Mitwirkenden, Sternen und monatlichen Downloads. Stärkung des Engagements und der Nutzung von ONNX durch die Community.

  • 00:25:00 In diesem Abschnitt erörtert der Sprecher die Veröffentlichungen und Aktualisierungen, die seit dem letzten Community-Update in der ONNX-Community stattgefunden haben. Anfang dieses Jahres wurde ONNX 1.11 veröffentlicht, das neue Operatoren einführte und einige Operatoren aktualisierte, einschließlich des ONNX-Modellhubs, der es Benutzern ermöglicht, vortrainierte Modelle aus verschiedenen Modellzoos abzurufen. Darüber hinaus wurden Dienstprogramme wie das Compose-Dienstprogramm und der Funktionsersteller sowie Fehlerkorrekturen und Infrastrukturverbesserungen eingeführt. ONNX 1.12 wurde kürzlich mit weiteren neuen Operatoren, Form- und Inferenzverbesserungen und Unterstützung für Python 3.10 eingeführt. Der Referent erörtert auch den ONNX-Roadmap-Prozess und 12 Roadmap-Anfragen, die für den weiteren Fortschritt ausgewählt und den Arbeitsgruppen zugewiesen wurden. Diese Anfragen umfassen die Implementierung neuer Operatoren für die Datenvorverarbeitung, eine C-API für ONNX und mehr.

  • 00:30:00 In diesem Abschnitt des Videos erörtert der Sprecher die Fortschritte, die bei der Bewältigung des Bedarfs an strukturierteren quantisierten Informationen erzielt wurden, die durch das Modell und die Tensoren fließen. Der Vorschlag für die End-to-End-Pipeline mit ONNX-Betreibern wird weiter verfeinert, da er als langfristiger Abschnitt identifiziert wird. Bei den Konvertern wurden bisher einige Fortschritte erzielt, wobei höher funktionierende Operationen Unterstützung erhalten. Der Redner geht auch auf verschiedene Bereiche ein, wie z. B. den Bedarf an mehr Freiwilligen, da es sich um ein Gemeinschaftsprojekt handelt, und eine Bitte an Unternehmen, sich mehr Menschen anzuschließen. Der Referent listet verschiedene Ressourcen wie die Website, GitHub, Slack-Kanäle und den ONNX-Kalender auf.

  • 00:35:00 In diesem Abschnitt erörtert der Referent die jüngsten Aktualisierungen und Verbesserungen von ONNX. Es gab zwei kürzlich veröffentlichte Versionen mit verschiedenen Updates, wie z. B. verbesserter Chip-Einfluss für Bediener und stabilerer Umgang mit falschen und optionalen Eingaben. Darüber hinaus hebt der Referent die Hinzufügung von zwei wichtigen Releases hervor: dem Model Composer und dem Function Builder. Auch der Model Converter ist stabiler geworden, und das Team plant, in Zukunft gemischte Releases besser zu unterstützen. Insgesamt ist es unmöglich, alle Verbesserungen aufzulisten, die von Mitwirkenden vorgenommen wurden, aber sie arbeiten weiterhin an der Verbesserung von ONNX.

  • 00:40:00 Rama von Operator SIG gab eine Zusammenfassung der jüngsten Änderungen und Aktualisierungen der ONNX-Spezifikation. Der Schwerpunkt von Operator SIG liegt auf der Weiterentwicklung der Gruppe von Operatoren, aus denen die ONNX-Spezifikation besteht, dem Hinzufügen neuer Operatoren und der Präzisierung ihrer Spezifikationen. In den letzten beiden Releases wurden neue Operatoren wie Grid-Sample und Layer-Normalisierung eingeführt. Vorhandene Operatoren wie scatter op wurden aktualisiert, um doppelte Indizes zu unterstützen, während einige ops erweitert wurden, um Typen wie b float 16 und optionale Typen zu unterstützen. Rama erwähnte auch Pläne, einige der neuen Operatoren bald zu Funktionen zu machen.

  • 00:45:00 In diesem Abschnitt erörtert der Redner die Pläne für die Zukunft von ONNX und den Kompromiss zwischen einer kompakten Spezifikation und der Unterstützung neuer Arten von Modellen, die mehr Operationen in der Spezifikation erfordern. Die Lösung für diese Herausforderung ist das Konzept der ONNX-Funktionen, die eine ausführbare Spezifikation für eine Operation bereitstellen und ein Gleichgewicht zwischen widersprüchlichen Anforderungen ermöglichen. Der Redner erwähnt Pläne, die Menge primitiver Operatoren zu reduzieren, indem man sie in Funktionen umwandelt und das Authoring in Python mit einer Teilmenge namens ONNX-Crypt ermöglicht. Beispiele für Funktionen wie die Jello-Aktivierungsfunktion und die Dropout-Operation werden gegeben, um zu veranschaulichen, wie die Verwendung von Kontrollfluss es einfacher macht, ihre Semantik auf natürliche und kompakte Weise zu spezifizieren.

  • 00:50:00 In diesem Abschnitt gibt Kevin Chen ein Update zur Konverter-Sig und der Arbeit, die seit dem letzten Treffen geleistet wurde. Er bespricht die Front-End-Konverter-Updates, einschließlich der PyTorch-, TensorFlow- und sk-learn-zu-ONNX-Konverter. Für den PyTorch-Konverter unterstützt die neueste Version ONNX-Exporte bis zu ONNX-Offset 16, und es wurden neue Funktionen hinzugefügt, z. B. die Möglichkeit, neuronale Netzwerkmodule speziell als lokale ONNX-Funktionen zu exportieren. Chen geht auch auf die Back-End-Konverter-Updates ein, wie z. B. die ONNX-Zentralität und den ONNX-TensorFlow-Konverter. Schließlich stellt Chen die Roadmap für die Konverter-Sig vor und ermutigt die Leute, sich zu engagieren.

  • 00:55:00 In diesem Abschnitt erörtert der Referent Aktualisierungen und Verbesserungen für den Konverter SK Learn to ONNX, den Konverter ONNX Detector Key und den Konverter ONNX TensorFlow. Benutzern wird empfohlen, auf die neuesten Versionen zu aktualisieren, um die Benutzererfahrung beim Konvertieren von Modellen zu verbessern. Die Roadmap für den Converter-Stick umfasst Ziele wie die Verbesserung von Community-gesteuerten Werkzeugen, die Standardisierung von Hilfsfunktionen und die Verbesserung der Bediener- und Offset-Unterstützung. Benutzer werden ermutigt, dem ONNX Converters-Kanal auf Slack beizutreten oder die ONNX Converter SIG-Mailingliste zu abonnieren, um sich in der Community zu engagieren und Feedback zu geben.

  • 01:00:00 Jackie von Microsoft stellt ONNX Model Zoo und ONNX Tutorials vor. ONNX Model Zoo ist eine Sammlung von vortrainierten, hochmodernen Modellen für maschinelles Lernen, die größtenteils von der ONNX-Community beigesteuert werden. Derzeit befinden sich 168 Modelle im Zoo, darunter 40 ONNX-Modelle und 35 visionsbasierte ONNX-Modelle zur Bildklassifizierung und Objekterkennung. ONNX-Tutorials bieten Dokumente und Notebooks, die ONNX in der Praxis für verschiedene Szenarien und Plattformen demonstrieren. Der Model Zoo hat seit dem letzten Workshop mehrere Verbesserungen erfahren, darunter neue quantisierte Modelle von Intel und eine erhöhte Testabdeckung mit routinemäßigen CI-Tests, der Behebung fehlerhafter Testdatensätze und der Zusammenarbeit mit dem Team Hugging Face, um eine Webschnittstelle für die Demonstration von Modellen zu erstellen.

  • 01:05:00 Die Referenten diskutieren die Verfügbarkeit von Tutorials und Demos zur Verwendung von ONNX, einschließlich einer Website, die eine einfache Verarbeitung von Bildern und ONNX-Modellen ermöglicht, indem nur wenige Zeilen Python-Code geschrieben werden. Sie diskutieren auch die zukünftige Roadmap für den ONNX Model Zoo mit Plänen, mehr Modelle von ORT ausführen zu lassen und mehr Beiträge zu integrieren, einschließlich quantisierter Modelle und Trainingsbeispielmodelle. Darüber hinaus heben sie die Arbeit der ONNX Preprocessing Working Group hervor, die sich darauf konzentriert, die Vorverarbeitung von Daten für die Verwendung mit ONNX-Modellen zu vereinfachen.

  • 01:10:00 In diesem Abschnitt des Videos erörtert der Redner den Mangel an Standardisierung in Datenvorverarbeitungs-Pipelines und hebt Unterschiede zwischen beliebten Bibliotheken wie Pillow und OpenCV in der Bildvorverarbeitung hervor. Diese Unterschiede können zu Genauigkeitsproblemen führen, wenn Modelle auf verschiedenen Plattformen bereitgestellt werden. Der Referent stellt das Ziel der ONNX-Gruppe vor, Datenvorverarbeitungsvorgänge zu standardisieren, um Mehrdeutigkeiten zu vermeiden und die Modellbereitstellung zu verbessern. Die Gruppe hat an der Entwicklung einer Infrastruktur gearbeitet, um die Datenvorverarbeitung in Modelle einzubeziehen, wie z. B. die Entwicklung von Kompositionsdienstprogrammen und des Sequence-Map-Operators für die Batch-Verarbeitung. Die ONNX-Gruppe untersucht auch Möglichkeiten, den Vorverarbeitungsteil eines Modells zur Identifizierung durch Back-Ends zu markieren. Darüber hinaus schlägt die Gruppe Erweiterungen für den Resize-Operator vor, darunter einen optionalen Anti-Aliasing-Filter und eine Richtlinie zum Beibehalten des Seitenverhältnisses.

  • 01:15:00 Die Referenten diskutieren die Implementierung einer vorgeschlagenen Center-Crop- oder Path-Operation, die ein höheres Abstraktionsniveau bietet und auf bestehenden Pad- und Slice-Operatoren beruht. Sie ermutigen die Zuschauer, ihrem Slack-Kanal und ihren monatlichen Treffen beizutreten, um Ideen auszutauschen. Die folgende Präsentation wird von Joaquin Anton gehalten, der das Ziel der ONNX-Vorverarbeitungsarbeitsgruppe zusammenfasst und ihre jüngsten Arbeiten teilt. Auch Marvin aus Italien stellt sich und seine Arbeit als Entwickler und Data Scientist im Bereich Natural Language Processing vor.

  • 01:20:00 Der Referent erläutert, wie wichtig es ist, die ONNX-Dokumentation zu prüfen, bevor mit der Arbeit an einem Projekt begonnen wird. Sie erklären, dass nicht alle Modelle einfach für ONNX konvertiert oder optimiert werden können und dass es wichtig ist sicherzustellen, dass die für das Projekt erforderlichen Betriebsfunktionen in dem verwendeten Framework implementiert werden. Darüber hinaus rät der Referent von der Annahme ab, dass die besten Leistungsoptionen immer ein Modell optimieren, da diese Optionen manchmal die Genauigkeit verringern können. Insgesamt ist es wichtig, die Architektur des Projekts sorgfältig zu prüfen und die ONNX-Dokumentation und Tools wie den ONNX-Optimierer zu prüfen, um Fehler zu vermeiden und eine erfolgreiche Bereitstellung in der Cloud oder auf Geräten sicherzustellen.

  • 01:25:00 In diesem Abschnitt erörtert Jiraj Perry von Nvidia die Grundlagen der Quantisierung neuronaler Netzwerke und wie TensorRT quantisierte Netzwerke durch verschiedene Fusionen unterstützt. Er erklärt, dass Quantisierung der Prozess der Umwandlung kontinuierlicher Werte in einen diskreten Satz von Werten ist, wobei lineare oder nichtlineare Skalierungstechniken verwendet werden, die eine schnellere Inferenz und einen geringeren Speicherbedarf bieten können. Es kann jedoch zu Kompromissen bei der Genauigkeit kommen. Jiraj erwähnt auch die verschiedenen Quantisierungsschemata und die Bedeutung von Quantisierungsparametern oder q params. Anschließend stellt er die Quantisierung nach dem Training (PTQ) und das quantisierungsbewusste Training (QAT) vor und erklärt, wie sie q-Parameter bestimmen können.

  • 01:30:00 In diesem Abschnitt behandelt das Video die Post-Training-Quantisierung (PTQ) und das quantisierungsbewusste Training (QAT). PTQ beinhaltet das Ausführen eines vortrainierten Modells auf einem Kalibrierungsdatensatz und das Sammeln schichtweiser Statistiken, um den dynamischen Bereich für jede Schicht zum Berechnen von Quantisierungsparametern zu bestimmen. QAT führt qdq-Knoten auf gewünschten Ebenen ein und passt den Graphen für eine kleine Anzahl von Epochen an, um Modell- oder Quantisierungsparameter zu lernen. PTQ ist im Allgemeinen schneller und hat weniger Kontrolle über die endgültige Genauigkeit, während QAT langsamer ist, aber mehr Genauigkeitskontrolle bietet. Das Video zeigt auch Unterschiede in den Ansätzen zwischen dem TF Mod-Toolkit von Google und dem TF2-Quantisierungs-Toolkit von NVIDIA, das auf TF Mod aufsetzt.

  • 01:35:00 In diesem Abschnitt erörtert der Sprecher die Unterschiede zwischen dem Quantisierungs-Toolkit von Nvidia und tf mod hinsichtlich der Platzierung von qdq-Knoten. Das Toolkit von Nvidia platziert qdq-Knoten an den Eingängen und Gewichten einer Schicht im Netzwerk, während tf mod empfiehlt, sie an den Gewichten und Ausgängen einer Schicht zu platzieren. Der Referent beschreibt auch, wie TensorRT Modelle durch Schichtfusionen optimiert, wie z. B. punktweise Fusionsfaltung und Pooling-Fusion, zusammen mit dedizierten Fusionen für qdq-Knoten. Darüber hinaus führt der Graphoptimierer von TensorRT eine qdq-Propagation durch, um q- und dq-Knoten zu verschieben, um sicherzustellen, dass der maximale Teil des Graphen in der Aufnahme läuft. Die vorgestellten Fusionsbeispiele umfassen eine durchschnittliche Poolquantisierung und eine elementweise Additionsfusion. Schließlich untersucht der Sprecher die Quantisierungsfusion in einem Restblock.

  • 01:40:00 In diesem Abschnitt erklärt der Referent, wie wichtig es ist, qdq-Knoten am Identitätszweig hinzuzufügen, um beim Neuladen von Vorgängen die beste Leistung von Tensor RT zu erzielen. Die resultierenden Fusionen sehen aus wie dq-Knoten der Gewichtungen und Eingaben, die über die Anzeige hinaus weitergegeben und mit q-Knoten nach der Hinzufügeschicht verschmolzen werden. Der Sprecher betont die Notwendigkeit von qdq-Knoten im ursprünglichen Diagramm, um die beste Leistung für Ihr Modell zu erzielen, und warnt davor, dass eine nicht ordnungsgemäße Verwendung zu einer schlechten Leistung des Modells führen kann. Der Referent lädt abschließend zu einer Diskussion darüber ein, wie man qdq-Knoten in das TensorFlow-Toolkit einfügt.

  • 01:45:00 In diesem Abschnitt erkennt der Sprecher ein technisches Problem beim Navigieren durch die Folien an und versichert dem Publikum, dass es in Kürze behoben wird. Anschließend diskutieren sie eine Fallstudie zur Genauigkeit, nachdem sie ein quantisiertes und feinabgestimmtes gespeichertes TensorFlow-Modell erhalten haben. Das Publikum ist eingeladen, vor einer kurzen Pause Fragen zu stellen.

  • 01:50:00 In diesem Abschnitt erörtert der Referent das Konzept der Quantisierung und wie es verwendet werden kann, um eine geringe Genauigkeit bei der Quantisierung neuronaler Netze darzustellen. Die Quantisierung ist eine Kombination aus zwei Funktionen: der quantisierten Funktion, die Gleitkommawerte auf ganzzahlige Werte abbildet, und der quantisierten Funktion, die ganzzahlige Werte zurück auf eine Gleitkommadarstellung abbildet. Die Kombination dieser beiden Funktionen wird als Scheinquantisierung bezeichnet. Dieser Prozess ermöglicht die Abbildung von Darstellungen auf eine Nur-Ganzzahl-Darstellung. Die Verwendung einer einheitlichen Quantisierung, insbesondere mit reduzierter Präzision, ermöglichte 1,7 Milliarden Samples pro Sekunde mit weniger als drei Mikrosekunden Latenz auf der HF-Fußballplattform.

  • 01:55:00 In diesem Abschnitt erörtert der Redner die Einschränkungen von ONNX bei der Darstellung von Quantisierung mit niedriger Genauigkeit, insbesondere unter acht Bit, und schlägt eine Strategie vor, um die Darstellungskraft von ONNX zu erweitern, indem Clipping genutzt wird, um Präzision zwischen den quantisierten und dequantisierten Knoten zu induzieren . Diese Strategie fügt eine zusätzliche Clipping-Funktion hinzu, die über ganzzahlige Grenzen hinweg unterstützt wird und die Retrokompatibilität mit bestehenden Bibliotheken und Tools nicht beeinträchtigt. Diese Strategie erstreckt sich jedoch nur so weit, wie es die quantisierte Linearität als Operator zulässt, und weist einige Einschränkungen hinsichtlich verschiedener Arten von Rundungen auf. Der Redner erwähnt auch ihre Bemühungen mit der Quantisierung im Exponentiationsdialekt (tuonex), die eine gefälschte Quantisierung in nur einem Knoten darstellt, sich aber auf eine breitere Palette von Szenarien mit Eingangssendungen, binären Quantisierungsoptionen und mehr erstreckt. Dieses Format wird im Rahmen ihrer Bereitstellungsbemühungen auf fpgas genutzt, und ihre Tools wie q ONNX und nqcdq lassen sich in vorhandene Quantisierungsbibliotheken integrieren und haben in der fpga-Community Akzeptanz gefunden.

  • 02:00:00 In diesem Abschnitt erläutert Daniel von Mithril, wie sie eine Lösung namens „Blind AI“ entwickelt haben, die den Einsatz von ONNX-Modellen in sicheren Enklaven ermöglicht, die Hardware zum Schutz von Daten nutzen. Durch die Verwendung hardwarebasierter Technologien bietet diese Lösung eine Isolierung und Verschlüsselung des Speicherinhalts der Enklave, wodurch jeder Dumping-Versuch von außen verhindert wird. Die Daten werden innerhalb der Enklave entschlüsselt, und böswillige Insider können nicht auf die Daten zugreifen, was für den Dateneigentümer ein großer Vorteil in Bezug auf Datenschutz und Sicherheit ist. Blind AI ist eine Open-Source-Lösung, die einfach zu integrieren ist, und es ist für den KI-Anbieter mühelos, diese Lösung zu warten und zu verkaufen.

  • 02:05:00 In diesem Abschnitt erörtert der Referent die Möglichkeit, KI-Modelle mit Fortschrittsgarantien bereitzustellen, indem das Python SDK verwendet wird, um die Modelle sicher hochzuladen und Daten zur Analyse zu senden, ohne Dritten Zugriff auf die Daten zu gewähren. Hervorgehoben wird auch die Expressivität von ONNX, die es ermöglicht, verschiedene Anwendungsfälle abzudecken, darunter Gepäckkontrolle, Analyse medizinischer Dokumente und Gesichtserkennung. Der Sprecher stellt auch verschiedene in der Praxis verwendete Modelle und ihre Geschwindigkeit innerhalb und außerhalb der Enklave vor, mit angemessener zusätzlicher Latenz aufgrund des gebotenen Schutzes. Darüber hinaus erfordert ONNX eine minimale Codebasis, was es aus Sicherheitsgründen besser macht und in der Lage ist, jeden Betreiber zu stärken und eine sichere Nutzung der Enklave zu gewährleisten. Die Präsentation endet mit Informationen zu ihrem GitHub und wie sie verschiedene Szenarien abdecken können, sowie der Möglichkeit, sich mit den technischen Sicherheitsdetails zu befassen.

  • 02:10:00 In diesem Abschnitt erörtert der Referent den Vorschlag zur Aktivierung maschinenlesbarer KI-Metadaten in ONNX, bei dem die Herkunft und andere relevante Merkmale eines Modells nachverfolgt werden, um zu ermitteln, wie es sich im Laufe der Zeit bewegt und sich in einem bestimmten Anwendungsfall entwickelt. Der Vorschlag wurde ursprünglich im Oktober 2020 dem ONNX-Lenkungsausschuss vorgelegt, und jetzt möchte das Team den Vorschlag weiter ausdehnen, um die Erstellung, Abfrage und Visualisierung von Metadaten als Teil eines End-to-End-Designs für Modell-Hubs einzuschließen und Zoos. Der Referent betont die Bedeutung von Metadaten als Schlüsselfaktor für eine verantwortungsbewusste und erklärbare KI und hebt ihre Nützlichkeit bei der Eingrenzung von Fehlermodi und der Identifizierung von Schmerzpunkten für KI-Systeme hervor.

  • 02:15:00 In diesem Abschnitt der ONNX Community Day-Präsentation erörtern die Redner die Bedeutung von Metadaten in Modellen und das Potenzial für die Verwendung von RDF für einen besser maschinenlesbaren und standardisierten Ansatz zur Darstellung von Metadaten. Sie erklären, wie dieser Ansatz dazu beitragen kann, Beziehungen zwischen Entitäten herzustellen, Transparenz zu wahren und die Herkunft zu verfolgen, und beantworten Fragen dazu, was dazu geführt hat, dass ein Modell eine geringere Genauigkeit als erwartet aufweist. Die Referenten diskutieren auch die Leistungsfähigkeit der Abfrage von Metadaten mit SPARQL und erklären, wie Modelle mit RDF-formatierten Metadaten Informationen liefern können, die über das hinausgehen, was eine einfache Modellkarte bieten kann.

  • 02:20:00 In diesem Abschnitt erörtert der Referent das Vokabular der Ofensteuerung, eine Reihe von Leitprinzipien, um Daten und digitale Assets zugänglich, interoperabel und wiederverwendbar zu machen. Die Prinzipien von Furnace wurden von der Semantic-Web-Community identifiziert und umfassen Fairness, Vertrauenswürdigkeit und Nachhaltigkeit. RDF-codierte Metadaten können mit der Furnace-Ontologie abgefragt werden, um Modelle zu entdecken, die für NLP-Aufgaben geeignet sind, die Ersteller und die Größe von Modellen zu identifizieren und den CO2-Fußabdruck von Modellen zu verfolgen, um sie zu klassifizieren und zu sortieren. Die Erweiterbarkeit von RDF und seiner Abfragesprache Sparkle ermöglichen eine unendliche Erweiterbarkeit über das von Prüfungsbehörden ausgewählte Vokabular hinaus. Dies kann die Verfolgung von verantwortlichem KI- und gemischtem Präzisionsstrom ermöglichen.

  • 02:25:00 In diesem Abschnitt erörtern die Referenten die Abfrage- und Filterfunktionen des ONNX Community Day. Sie zeigen, wie der Autor von Metadaten Modelle identifizieren kann, die mit Datensätzen trainiert wurden, die private oder persönliche Informationen enthalten, indem er Metadaten-Tags verwendet. Die Referenten demonstrieren auch, wie erweiterte Filterfunktionen es Benutzern ermöglichen, Modelle mit gemischter Genauigkeit abzufragen. Sie beleuchten die Visualisierung von Modellprofilen und erklärbare KI-Techniken zur effizienten Anzeige von Metadaten. Die Referenten rufen zum Handeln auf, um ein konkretes Design rund um die Modellerstellung und -nutzung in Betracht zu ziehen, das die gesamte Metadatenerstellung, Abfrage und Filterung aus dem Hubs-Workflow mit Unterstützung für maschinenlesbare Metadaten in ONNX abdeckt. Sie bereiten derzeit eine Strohmann-Implementierung vor und untersuchen Technologien für die Erstellung von Metadaten.

  • 02:30:00 In diesem Abschnitt erläutert Adam Pocock von Oracle Labs die Bedeutung der Unterstützung der Java Virtual Machine (JVM) mit ONNX. Während die meisten ML-Anwendungen in anderen Sprachen als Python geschrieben sind, wie z. B. Java, ist es entscheidend, maschinelles Lernen in diese Sprachen zu bringen. Die ONNX-Laufzeit-Java-API wurde von Oracle Labs entwickelt, um maschinelles Lernen in Java und andere Sprachen zu integrieren, mit Funktionen wie minimaler Auswirkung auf die Leistung und einfacher Bereitstellung. Adam stellt auch ein Codebeispiel bereit, um die Ähnlichkeiten zwischen der Java-API und anderen APIs zu demonstrieren.

  • 02:35:00 In diesem Abschnitt erläutert der Referent, wie Daten zugeführt und ein Modell mithilfe von ONNX-Tensor, einer Byte-Pufferdarstellung für einen Strom von Bytes, ausgeführt wird. Obwohl es möglich ist, reguläre Arrays in Java zu verwenden, empfiehlt der Referent die Verwendung von Bytepuffern aufgrund ihres Zero-Copy-Pfads, was eine effizientere Handhabung von Daten ermöglicht. Der Referent weist auch darauf hin, dass die mehrdimensionalen Arrays von Java nicht optimal für maschinelles Lernen sind, da sie nicht flach sind und viel Zeigerverfolgung erfordern. Der Redner erörtert ferner Pläne für ein Upgrade auf eine neuere Version von Java, das Hinzufügen neuer Funktionen und den Ausbau, um dem ONNX-Laufzeitbaum zu entsprechen. Darüber hinaus stellt der Referent eine Open-Source-Bibliothek vor, die ONNX-Modelle aus Java schreibt, die überall auf der JVM verfügbar ist.

  • 02:40:00 In diesem Abschnitt erörtern die Referenten die Kompatibilität des ONNX-Toolsets mit neuen Bibliotheken für maschinelles Lernen wie DeepJ und wie es sich in die ONNX-Laufzeit integriert, um erstklassige Leistung zu bieten. DeepJ erstellt eine Abstraktionsschicht über verschiedenen Deep-Learning-Bibliotheken, abstrahiert alle erforderlichen Bibliotheken und stellt mehrere Operator-Backends für die Maschinenlern-Engines bereit, die verwendet werden können, wie Apache MixTape, Tensorflow, PyTorch, ONNX, Pedal und mehr. Sie untersuchen auch Möglichkeiten, die Metadaten in diesem Toolset zu standardisieren, um Standard-Metadatenformate auszugeben, während sie die Operatoraufzählung weiter erweitern.

  • 02:45:00 In diesem Abschnitt erörtert der Referent die Vorteile der Deep Java Library, die eine Reihe vortrainierter Modelle enthält, die Aufgaben wie Bildklassifizierung, Objekterkennung, Stimmungsanalyse und Aktionserkennung abdecken. Die Bibliothek ist einsatzbereit und wurde strengen Tests unterzogen, um mit der bestmöglichen Geschwindigkeit und Speicherkontrolle zu arbeiten, wie der erfolgreiche Einsatz bei DHL seit über einem halben Jahr ohne Fehler zeigt. Darüber hinaus teilt der Redner mehrere Anwendungsfälle, in denen ONNX und die ONNX-Laufzeit verwendet wurden, um erhebliche Leistungssteigerungen zu erzielen und die Latenz zu reduzieren. Eine Erfolgsgeschichte zeigt eine chinesische Bank, die die Laufzeit ihrer OCR-Modelle von einer Sekunde auf weniger als 400 Millisekunden für ein einzelnes Bild reduzieren konnte. Darüber hinaus stellt der Referent das Hybrid-Engine-Konzept vor, das es ermöglicht, zwei Motoren gleichzeitig zu laden und für einen reibungslosen Übergang zwischen ihnen zu sorgen.

  • 02:50:00 In diesem Abschnitt erläutert der Referent eine Methode, die den direkten Puffer verwendet, um Zeiger von Python direkt an die ONNX-Laufzeit zu senden, was das Kopieren von Daten vermeidet und eine Leistungssteigerung bietet. Sie führen auch ND Manager ein, eine baumartige Architektur, die in der DeepDraw-Bibliothek implementiert ist, um kostengünstigere Speichersammlungen bereitzustellen. Der Referent erläutert, wie Kunden von der Verwendung von PyTorch zur ONNX-Laufzeit wechseln können, ohne eine einzige Codezeile zu ändern. Später spricht der Redner von Hype Factors über ihr Media-Intelligence-Unternehmen und wie sie sich entschieden haben, ihre Infrastruktur auf der Grundlage der JVM aufzubauen, wegen ihrer Entwicklererfahrung, ihres Ökosystems aus wiederverwendbaren Komponenten und ihrer hohen Skalierbarkeit.

  • 02:55:00 In diesem Abschnitt erörtert der Referent die technischen Aspekte seiner Medienanalyse-Website, einschließlich der Verwendung der JVM zur Bereitstellung der meisten Funktionen der Website und der Migration zu einem System, das grundsätzlich alle eingehenden Daten anreichert. Mit einigen Milliarden GPU-Inferenzen pro Tag hängen die Funktionen des Produkts stark vom maschinellen Lernen und der Modellverwaltung ab, die zu einem wesentlichen Bestandteil der Aufrechterhaltung des Betriebs geworden sind, was zur Kritikalität des Prozesses führt. Die Daten umfassen alle Arten von Formaten, einschließlich HTML und PDFs, und sie verfolgen ihre Laufzeit, um Daten im Handumdrehen anzureichern, einschließlich der Erkennung benannter Entitäten, Hervorhebung, Stimmung und mehr. Auf dem Weg dorthin gab es viele Herausforderungen, darunter Konvertierungsfehler und ein seltenes Speicherleck in DTL, dessen Lösung eine Weile dauerte.
ONNX Community Day!
ONNX Community Day!
  • 2022.06.24
  • www.youtube.com
This event is being hosted in-person at the brand-new Microsoft Silicon Valley Campus on Friday, June 24th. The event will cover ONNX Community updates, part...
 

ONNX-Community-Tag! Livestream am 24. Juni 2022

Diese Veranstaltung findet am Freitag, den 24. Juni, persönlich auf dem brandneuen Microsoft Silicon Valley Campus statt.

Die Veranstaltung umfasst Updates der ONNX-Community, Partner- und Benutzergeschichten sowie zahlreiche Community-Netzwerke.



ONNX-Community-Tag!

Kurze Zusammenfassung:

  • 00:00:00 - 01:00:00 Das YouTube-Video "ONNX Community Day!" erörtert Aktualisierungen und Verbesserungen der Arbeit der ONNX-Community zur Interoperabilität und Flexibilität für Entwickler, die mit Modellen für maschinelles Lernen arbeiten. Die ONNX-Community arbeitet unter Open Governance, und die drei Kategorien von Tools, Erstellung, Betrieb und Visualisierung, unterstützen das Engagement und die Nutzung von ONNX durch die Community. Das Video bietet Fortschrittsberichte zu verschiedenen Aspekten, wie z. B. Aktualisierungen der ONNX-Spezifikationen, neue Operatoren und Verbesserungen bei Konvertern. Der Redner hebt auch die Vorteile von ONNX hervor, darunter das breitere Kundenspektrum für Hardwareanbieter und den Zugriff auf mehrere Frameworks und Hardwarebeschleuniger für Benutzer. Die Zukunft von ONNX umfasst die Vorstellung von ONNX-Funktionen zur Bereitstellung einer ausführbaren Spezifikation.

  • 01:00:00 - 02:00:00 Die ONNX Community Day-Veranstaltung diskutiert mehrere Themen im Zusammenhang mit ONNX, einschließlich ONNX Model Zoo und ONNX Tutorials, die vortrainierte Modelle für maschinelles Lernen und Demos zur Verwendung mit ONNX-Modellen bereitstellen. Das Video hebt die Arbeit der ONNX Preprocessing Working Group hervor, die darauf abzielt, Datenvorverarbeitungsvorgänge zu standardisieren, um die Modellbereitstellung zu verbessern. Die Referenten diskutieren auch die Grundlagen der Quantisierung neuronaler Netze und wie TensorRT quantisierte Netze durch verschiedene Fusionen unterstützt, einschließlich Quantisierung nach dem Training und quantisierungsbewusstes Training. Sie vertiefen sich auch in die Grenzen von ONNX bei der Darstellung von Quantisierung mit geringer Genauigkeit und schlagen eine Strategie vor, um seine Darstellungskraft durch Clipping zu erweitern, um Präzision zwischen den quantisierten und dequantisierten Knoten zu induzieren. Schließlich befasst sich das Video mit einer Fallstudie zur Genauigkeit eines quantisierten und feinabgestimmten gespeicherten TensorFlow-Modells.

  • 02:00:00 - 03:00:00 Der ONNX Community Day präsentierte zahlreiche Redner, die die Bedeutung von Metadaten in Modellen für maschinelles Lernen und die Unterstützung von Java Virtual Machine (JVM) in ONNX diskutierten. Die Redner betonten die Verwendung hardwarebasierter Technologien zum Schutz von Daten und hoben die Kompatibilität von ONNX mit verschiedenen Bibliotheken für maschinelles Lernen hervor, darunter DeepJ und Deep Java Library. Sie demonstrierten die Verwendung von Bytepuffern für eine bessere Effizienz und diskutierten die Bedeutung der Standardisierung von Metadaten für eine verantwortungsbewusste und erklärbare KI. Die Präsentationen enthielten auch Erfolgsgeschichten, darunter die verbesserte Laufzeit einer chinesischen Bank mit ONNX und ONNX Runtime. Die ONNX-Community arbeitet an der Erstellung, Abfrage und Filterung von Metadaten aus Hubs-Workflows mit Unterstützung für maschinenlesbare Metadaten in ONNX. Insgesamt hoben die Präsentationen die Stärken der ONNX-Plattform und das Engagement der Community für ihre Entwicklung hervor.

  • 03:00:00 - 04:00:00 Der "ONNX Community Day!" Das Video behandelt verschiedene Updates und Funktionen im Zusammenhang mit dem ONNX-Ökosystem. Dazu gehören Diskussionen über die Simulation der Quantisierung, um den Genauigkeitsabfall zwischen quantisierten und vortrainierten Modellen zu reduzieren, die Bereitstellung von TensorFlow-Modellen, die mit NVIDIAs Toolkit trainiert wurden, auf einem ONNX-Graphen mit TensorRT und Verbesserungen an ONNX Runtime, wie z. B. optimierte Tensorform, Ausführungsanbieter und Unterstützung für mobile Plattformen. Darüber hinaus wurden Updates für ONNX selbst besprochen, darunter die Unterstützung der XNNpack-Bibliothek und die Erstellung von ONNX-Laufzeiterweiterungen für Vor-/Nachverarbeitungsaufgaben. Das Video stellt auch die Bibliothek Optimum vor, die sich auf die Beschleunigung von Transformatormodellen vom Training bis zur Inferenz konzentriert.

  • 04:00:00 - 05:00:00 Der ONNX Community Day beinhaltete Diskussionen zu verschiedenen Themen rund um die ONNX-Laufzeit und ihre Anwendungsfälle. Die Referenten beschrieben die Funktionen des ONNX-Laufzeitpakets, des PiTorch-ONNX-Konverters und benutzerdefinierter Ops in PyTorch. Sie diskutierten auch Anwendungsfälle wie Prozessüberwachung und Digitalisierung des Handels sowie Herausforderungen im Zusammenhang mit Modellbereitstellung und Kompatibilitätstests. Während der gesamten Veranstaltung wurde betont, dass die ONNX-Laufzeitumgebung dazu beitragen kann, die Leistung zu verbessern und die Bereitstellungsgröße zu reduzieren, aber Kompatibilität und Auswahl sind unerlässlich, um konsistente Qualität und Geschwindigkeit sicherzustellen.

  • 05:00:00 - 06:00:00 Am ONNX Community Day diskutierten mehrere Redner verschiedene Tools und Techniken, die zur Optimierung und Bereitstellung von Modellen für maschinelles Lernen mit dem ONNX-Framework verwendet werden. NVIDIA erläuterte seinen Ansatz zur Verbesserung der Bildqualität und Modellkompatibilität mithilfe von Blockaufteilung für Inferenz sowie seine ONNX-spezifischen Tools zum Debuggen und Modifizieren von Modellen. Qualcomm erklärte, wie sie KI-Beschleuniger mithilfe von ONNX als Austauschformat in ihre Designs integriert haben, und stellte ihren Software-Stack vor, der die ONNX-Laufzeit und verschiedene Tools zur Optimierung und Bereitstellung umfasst. Darüber hinaus erörterten mehrere Referenten die Optimierung von ONNX-Modellen mithilfe von Techniken wie Moduloptimierung, Checkpointing und Shape-Inferenz. Die Veranstaltung hob die Vielseitigkeit und Skalierbarkeit von ONNX für verschiedene Geräteanwendungsfälle hervor und ermutigte zu Beiträgen zum weiteren Ausbau des ONNX-Projekts. Der letzte Teil konzentriert sich auf die Vereinfachung des Prozesses der Bereitstellung von Modellen für maschinelles Lernen in Spark mithilfe des SPIP-Vorschlags, der darauf abzielt, die Komplexität der Umwandlung der Registerkartenverarbeitung und der Modellinitialisierung für Entwickler zu verbergen. Das Ascend-KI-Ökosystem und seine Prozessoren wurden vorgestellt, einschließlich der Softwareschicht „Kung“, die APIs zum Erstellen von KI-Anwendungen und -Diensten bereitstellt. Der Khan-Software-Stack wurde besprochen und die Roadmap für das Hinzufügen als neuer Ausführungsanbieter für die ONNX-Laufzeit vorgestellt. Die Veranstaltung endete mit Roundtable-Diskussionen zu Themen wie ONNX für Mobile und Edge, Modellbereitstellung, Schulung und Betrieb, Konvertierungen und Betreiber, gefolgt von einer Happy Hour und Umfrage-Feedback.


Die detaillierte Timeline-Zusammenfassung:

  • 03:00:00 In diesem Abschnitt diskutiert ein Redner seine Erfahrungen mit dem ONNX-Ökosystem und die Herausforderungen, denen er bei seiner Nutzung gegenüberstand. Sie sprechen über die Notwendigkeit, Treiber abzugleichen und eine Überwachung einzurichten, um sicherzustellen, dass das System reibungslos läuft. Sie erwähnen auch ihre zukünftigen Pläne, die GPU-Effizienz zu steigern, weitere Modelle hinzuzufügen und die allgemeine Robustheit des Systems durch GPU-beschleunigte Tests zu verbessern. Der Referent lädt zu Fragen und Diskussionen zu diesem Anwendungsfall ein und nutzt die Gelegenheit, um sich bei allen zu bedanken. Das Video wird nach dem Mittagessen mit einer Wiederholung des NVIDIA-Gesprächs fortgesetzt.

  • 03:25:00 Es tut mir leid, aber dieser Transkriptauszug hat nichts mit dem „ONNX Community Day“ zu tun! Video. Können Sie mir einen weiteren Ausschnitt aus dem Video zur Zusammenfassung zur Verfügung stellen?

  • 03:30:00 In diesem Abschnitt des Videos erörtern die Referenten, wie die Quantisierung simuliert und die endgültigen q-Parameter gespeichert werden, um den Genauigkeitsabfall zwischen dem quantisierten Modell und dem vorab trainierten Modell zu verringern. Eine Möglichkeit, ein quantisierungsbewusstes Training durchzuführen, ist die Verwendung des TensorFlow-Modelloptimierungs-Toolkits oder des von Nvidia erstellten Toolkits, das Funktionen wie das Quantisieren von Ebenen mithilfe von Ebenennamen und Klassenattributen und musterbasierte Quantisierung bietet. Die Referenten weisen darauf hin, dass Nvidias Toolkit eine symmetrische Quantisierungsvariante verwendet, die mit einer Erweiterung die beste Leistung für ein QAT-Modell auf einer GPU bietet.

  • 03:35:00 In diesem Abschnitt lernen wir den Prozess der Bereitstellung eines Modells, das mit NVIDIAs TF2 Quantization Toolkit trainiert wurde, auf einem ONNX-Diagramm mit TensorRT kennen. Der Arbeitsablauf umfasst die Quantisierung eines vortrainierten TensorFlow 2.0-Modells mit dem Toolkit von NVIDIA, die Feinabstimmung für eine kleine Anzahl von Epochen und die Konvertierung in ein ONNX-Diagramm mit dem TF2ONNX-Konverter. Dann werden die APIs von TensorRT verwendet, um TensorRT Engine aus dem ONNX-Diagramm zu generieren. Wir sehen, dass quantisierungsbewusstes Training eine Alternative zum Einsatz tiefer neuronaler Netze mit geringerer Genauigkeit bietet, und dass qrt-Modelle im Vergleich zu ptq-Modellen aufgrund fein abgestimmter Modellparameter möglicherweise weniger anfällig für Genauigkeitsverluste während der Inferenz sind. Schließlich zeigen die Experimente mit ResNet-Modellen, dass die INT8-Genauigkeit der FP32-Grundliniengenauigkeit ebenbürtig ist und die Latenz im Vergleich zu ihren FP32-Gegenstücken mehr als 10-mal schneller ist.

  • 03:40:00 In diesem Abschnitt spricht Ryan Hill, ein Softwareentwickler, der seit seiner Erstellung an der ONNX-Laufzeitumgebung arbeitet, über die Funktionen und die Verwendung der ONNX-Laufzeitumgebung. ONNX Runtime ist eine Laufzeit für ONNX-Modelle, vollständig plattformübergreifend und mit Sprachbindungen für viele Programmiersprachen. Microsoft verwendet es in allen wichtigen Produktgruppen wie Windows, Office und Azure, während über 160 Modelle mit ONNX-Laufzeit in Produktion sind. Hill geht in den letzten Versionen auf bemerkenswerte neue Funktionen ein, darunter die Möglichkeit, operative Kernel als mathematische Bibliothek zu verwenden, und die Möglichkeit, externe Initialisierer vollständig im Speicher zu füttern. Zu den Leistungsverbesserungen gehören das Hinzufügen eines Transpositionsoptimierers, das Optimieren von Heap-Zuweisungen und das Reduzieren der Notwendigkeit von Layout-Transformationen.

  • 03:45:00 In diesem Abschnitt erörtern die Referenten die Verbesserungen, die an ONNX Runtime vorgenommen wurden, einschließlich optimierter Tensorform und Inline-Vektorklassen, was zu einer Reduzierung der Heap-Zuweisungen und einer verbesserten Leistung führt. Sie erläutern auch die Vorteile von Ausführungsanbietern, die es ONNX Runtime ermöglichen, auf verschiedenen Hardwaremöglichkeiten optimal zu funktionieren, einschließlich einer vollständigen CPU-Implementierung als Fallback-Option. Darüber hinaus heben sie Aktualisierungen hervor, die zur Unterstützung mobiler Plattformen und verbesserter Benutzerfreundlichkeit für mobile Entwickler vorgenommen wurden, einschließlich der Verwendung der NHWC-Konvertierung zur Laufzeit und der Hinzufügung von Android- und iOS-Paketen mit den vollständigen ONNX Runtime-Builds. Schließlich stellen sie ONNX Runtime Web vor, das von der gleichen Kerncodebasis wie ONNX Runtime und mit einer kleineren Binärdatei unterstützt wird, und diskutieren die Einführung einer JavaScript-Bibliothek namens ONNX Runtime Common.

  • 03:50:00 In diesem Abschnitt besprechen die Redner die Aktualisierungen von ONNX, einschließlich der Unterstützung für die XNNpack-Bibliothek und der bevorstehenden OpenGL-Unterstützung in der Version 1.12. Sie gehen auch die Herausforderungen bei der Vor- und Nachverarbeitung von Daten und der Erstellung der ONNX-Laufzeiterweiterungen an, die eine Bibliothek gemeinsam nutzbarer benutzerdefinierter Operationen bereitstellen, die sich auf die Vor- und Nachverarbeitung von Modellen konzentrieren. Diese Erweiterungen umfassen potenzielle Funktionen wie das Konvertieren von Text in Groß- oder Kleinbuchstaben und das Trennen positiver und negativer Werte in separate Tensoren. Die aktuelle Bibliothek konzentriert sich hauptsächlich auf die Verarbeitung natürlicher Sprache sowie auf Bild- und Textdomänen, aber es wird erwartet, dass sich dies weiterentwickeln wird, wenn neue Anforderungen erkannt werden. Sie stellen auch Jeff von Hugging Face vor, der die Integration von ONNX mit der Optimum-Bibliothek zur Beschleunigung von Transformers-Modellen erläutert.

  • 03:55:00 In diesem Abschnitt erörtert der Redner die Leistungsfähigkeit von Transformatormodellen und wie sie von großen Unternehmen wie Tesla, Gmail, Facebook und Bing verwendet werden, um täglich Milliarden von Vorhersagen zu treffen. Sie erklären, dass das Ziel von Hugging Face darin besteht, diese Modelle jedem Unternehmen auf der Welt durch leicht zugängliche vortrainierte Modelle und Tools zugänglich zu machen, um sie zu nutzen. Sie besprechen auch ihren Fokus auf den Aufbau einer Community, die das Mögliche teilt und verbessert, mit über 1300 Open-Source-Mitwirkenden an ihren Bibliotheken und Zugang zu über 50.000 fein abgestimmten Modellen für jede maschinelle Lernaufgabe und Sprache. Der Redner stellt dann seine Bibliothek Optimum vor, die sich auf die Beschleunigung von Transformer-Modellen vom Training bis zur Inferenz konzentriert und die Herausforderungen von Rechen-, Speicher- und Bandbreitenressourcen angeht, die mit steigenden Modellparametern einhergehen.


  • 04:00:00 In diesem Abschnitt erörtert der Referent das ONNX-Laufzeitpaket im Optimum-Toolkit und seine Fähigkeit, das Training und die Inferenz von Transformatormodellen zu beschleunigen. Sie stellen die neue Trainerklasse namens ORT Trainer vor, die es Benutzern ermöglicht, eine native Integration von Deep Speed zu erhalten und eine Beschleunigung des Trainingsdurchsatzes von bis zu 40 % zu erreichen. Für die Schlussfolgerung gibt es drei Hauptklassen: ORT Optimizer, RT Quantizer und RT Model for Task. Mit diesen Klassen können Benutzer den Graphen ihres Modells vereinfachen, Gewichtungen optimieren und von der gesamten Hardwarebeschleunigung profitieren, die die ONNX-Laufzeit bietet. Der Redner erwähnt auch Kooperationsbemühungen zur Ermöglichung der Optimierung von Sequenz-zu-Sequenz-Modellen durch diese optimalen beschleunigten Inferenz-Pipeline-Klassen.

  • 04:05:00 In diesem Abschnitt diskutieren zwei Moderatoren über die ONNX-Community und konzentrieren sich auf den Optimierungs- und Konvertierungsprozess für ONNX-Modelle. Der erste Moderator stellt die optimale Bibliothek vor, die es Benutzern ermöglicht, ihre Modelle zu optimieren und zu quantisieren, den Durchsatz zu erhöhen und die Latenz zu verringern, während die Genauigkeit ihrer Modelle erhalten bleibt. Der zweite Referent erörtert die Architektur und den Ablauf des PiTorch-ONNX-Konverters und erläutert die Schritte zum Konvertieren von PiTorch-Modellen in die Fackel-Zwischendarstellung, Verwenden von Grafikoptimierungen und Konvertieren in ONNX IR. Sie heben auch einige interessante Funktionen hervor, wie die Unterstützung für den Export eines quantisierten Modells im QTQ-Format und die Erfassung von Python-Steuerungsflussschleifen und ifs in ONNX-Modellen als ONNX-Schleife und ONNX-if-Knoten.

  • 04:10:00 In diesem Abschnitt erörtert der Referent verschiedene Möglichkeiten zum Exportieren benutzerdefinierter Ops in PyTorch, einschließlich des Schreibens einer benutzerdefinierten Torch-Autogrammfunktion und des Definierens der Vorwärts- und Rückwärtsmethoden. Der Referent erklärt, wie die API verwendet wird, um eine benutzerdefinierte symbolische Funktion zu registrieren, um dem Exporteur mitzuteilen, wie er sie entweder als standardmäßige ONNX-Operationen oder als benutzerdefinierte Operationen in einer benutzerdefinierten Domäne exportieren kann. Anschließend führen sie die ONNX Local Function-Funktion ein, mit der Benutzer eine bestimmte Torch-Modulklasse oder einen bestimmten Knotentyp als Funktion für das Back-End angeben können, um das Modell weiterhin ohne einen bestimmten Kernel ausführen zu können. Abschließend erwähnt der Redner, dass sich das Team weiterhin auf die Unterstützung weiterer Modelle und die Verbesserung der Erfahrung bei der Diagnose von Fehlern konzentrieren wird.

  • 04:15:00 In diesem Abschnitt wird ein Anwendungsfall diskutiert, bei dem ein vorhandenes Kamerasystem wiederverwendet wird, um Mitarbeiter zu erkennen, die gefährliche Bereiche in der Nähe von sich bewegenden Maschinen betreten. Unter Verwendung eines Open-Source-ONNX-Modells zur Erkennung von Personen und des Sasebo Stream Processing-Tools von SAS zur Echtzeitanalyse und Ereignisverarbeitung wurde eine Lösung entwickelt, die Millionen von Ereignissen pro Sekunde verarbeiten und auf größere Systeme skaliert werden kann. Die Lösung wurde Datenwissenschaftlern auch über ein Grafikstudio und ein Jupyter-Notebook zur Verfügung gestellt, um Modelle zu entwickeln, und die ONNX-Laufzeit wurde in Sasebo Stream Processing integriert. Um die Ausfallsicherheit zu gewährleisten, wurde eine modulare Lösung vorgeschlagen, die die Bildverarbeitung in mehrere Schritte mit Kafka als Pufferwarteschlange aufteilt.

  • 04:20:00 In diesem Abschnitt beschreibt der Referent ein Computer-Vision-Verarbeitungsmodell, das am Rand mithilfe von Kubernetes als Bereitstellungsmechanismus bereitgestellt wurde. Das Modell umfasst einen Aufnahmeprozess mit einem Pod für jede Kamera, einen Kafka-Bus für Videodaten und einen Verarbeitungs-Pod, der ein Computer-Vision-Modell verwendet, um Ergebnisse zu erzeugen. Die Ergebnisse werden dann an einen dritten Pod gesendet, der zusätzliche Sensordaten des Kunden verarbeitet, um zu verstehen, ob das aufgezeichnete Gerät aktiv ist oder nicht. Darüber hinaus erklärt der Referent, dass diese Architektur derzeit bei einem ihrer Kunden in Produktion ist und dass die ONNX-Laufzeitintegration dank öffentlich verfügbarer vortrainierter Modelle und der Wiederverwendung von Kundenanlagen eine optimale Time-to-Value gewährleistet. Die Ausfallsicherheit der Architektur ist ein weiterer wichtiger Vorteil und wird dank Kubernetes und Kafka sichergestellt.

  • 04:25:00 In diesem Abschnitt diskutiert Matthew von Bazaar Voice die Digitalisierung des Handels und wie sich Marken und Einzelhändler auf die unendlichen Regalflächen im Internet verlagert haben. Angesichts des Umfangs der Daten, über die E-Commerce-Unternehmen verfügen, kann die Erstellung wirkungsvoller Erkenntnisse mithilfe von KI ein Wendepunkt sein. Matthew veranschaulicht dies am Beispiel von Bazaar Voice, das monatlich Daten für über eine Milliarde Käufer verwaltet und verarbeitet und insgesamt über 8 Milliarden Bewertungen für Marken und Einzelhändler bereitstellt. Durch die Konzentration auf den Austausch von Produktbewertungen über Kataloge hinweg spielt das Konzept des Produktabgleichs eine zentrale Rolle. Matthew erklärt, wie ein maschinelles Lernmodell erstellt wird, um den Produktabgleich durch Vergleichen eindeutiger Produktkennungen durchzuführen, aber alle Reste werden manuell erledigt. Um eine Lösung zu implementieren, die einen echten Geschäftswert generiert, ist der ideale Ansatz eine leichtgewichtige, kosteneffiziente Lösung, die die Leistung aufrechterhält.

  • 04:30:00 In diesem Abschnitt erörtert der Referent verschiedene Optionen für die Bereitstellung von Modellen für maschinelles Lernen, darunter virtuelle Server, Cloud-ML-Plattformen und serverlose Funktionen wie Azure Cloud Functions oder AWS Lambdas. Nach Bewertung der Vor- und Nachteile jeder Option beschlossen der Referent und sein Team, ein in das ONNX-Format exportiertes Scikit-Learn-Modell zu entwickeln, es mit Python zu erstellen, es für eine serverlose Funktion bereitzustellen und eine Knotenumgebung zu verwenden, um Inferenzen auf ONNX auszuführen Laufzeit. Der Redner erwähnt auch, dass ONNX hilft, die Bereitstellungsgröße von Modellen zu reduzieren, hebt jedoch die Herausforderungen hervor, die sich ergeben, wenn innerhalb der Zeitüberschreitungs- und Bereitstellungsgrößenbeschränkungen von serverlosen Funktionen gearbeitet wird, sowie die Kosten- und Größenbeschränkungen von Python-Paketen.

  • 04:35:00 In diesem Abschnitt erläutert Nikhil Calro, Senior Software Engineer bei Adobe, die einzigartigen Herausforderungen, die mit leistungsstarkem maschinellem Lernen für Video- und Audio-Workflows verbunden sind. Zu diesen Herausforderungen gehören Ressourcenbeschränkungen, Datenintensität und rechenintensive Anforderungen. Um diese Probleme zu lösen, verwendet Adobe eine Kombination aus Technologien und Pipelines zur Beschleunigung von Arbeitsabläufen, einschließlich der ONNX-Laufzeitumgebung zur Unterstützung von Arbeitsabläufen für maschinelles Lernen in Windows und des Direct ML-Ausführungsanbieters für die GPU-Beschleunigung auf Windows-Plattformen. Calro weist auch darauf hin, dass die Machine-Learning-Workflows von Adobe darauf abzielen, Entwicklern zu ermöglichen, mehr Zeit für den kreativen Prozess und weniger Zeit für redundante und sich wiederholende Aufgaben aufzuwenden.

  • 04:40:00 In diesem Abschnitt spricht der Redner darüber, wie die Creative Cloud-Apps von Adobe auf das gesamte Windows-Ökosystem als eine einzige Plattform abzielen und für alle wichtigen IHVs, die Windows unterstützen, wie Nvidia, Intel und AMD, gleiche Merkmale und Funktionen bieten müssen. Sie entschieden sich für den DirectML-Ausführungsanbieter, um die Verwendung herstellerspezifischer Hardware wie Tensor-Cores auf Nvidia-GPUs zu ermöglichen, da Hardware für andere asynchrone Rechenworkflows frei bleibt. Sie nahmen auch zusätzliche Leistungsoptimierungen vor, indem sie ein Framework auf der ONNX-Laufzeit aufbauten und versuchten, die Inferenzanforderungen in Batch-Workflows zusammenzufassen, um Ressourcenkonflikte mit der GPU zu reduzieren und den Treiberaufwand zu minimieren. Sie geben ein Beispiel für den Scene Edit Detection-Workflow, der ein extrem ressourcenintensiver Workflow ist, aber sie sind in der Lage, die gesamte Pipeline End-to-End von der Dekodierung bis zur Inferenz in etwa 10 Sekunden oder sechsmal Echtzeit auszuführen.

  • 04:45:00 In diesem Abschnitt erläutert der Referent, wie die von ORT und dem Direct ML-Ausführungsanbieter bereitgestellten Leistungsverbesserungen es ermöglicht haben, moderne High-End-GPUs zu verwenden, um auf maschinellem Lernen basierende Workflows während des GPU-Renderings zu ermöglichen. Sie planen, ihre Pipeline so umzustellen, dass sie eher wie die Pipeline auf der rechten Seite aussieht, Übertragungen an die CPU minimiert und so viel Zeug wie möglich auf der GPU oder GPU-adressierbarer Hardware belässt. Dies wird noch einfacher, wenn mehr ihrer GPU-Rechenleistung auf DX12 umgestellt wird, wodurch der mit OpenCL und CUDA verbundene Overhead in ihrem OP auf DX12 entfällt.

  • 04:50:00 In diesem Abschnitt erläutert Alexander Zang, Softwareentwickler bei Topaz Labs, die Herausforderungen bei der Bereitstellung von Bildmodellen auf Desktops und Laptops. Er erklärt, dass der entscheidende Teil dieser Bereitstellung darin besteht, sich in einen bestehenden Workflow einzufügen, die erwartete Leistung ohne manuelle Konfiguration zu erzielen und qualitativ hochwertige Bildmodelle bereitzustellen. Alexander erklärt, dass der Desktop-Bereitstellung im Gegensatz zur Server-Bereitstellung die Kontrolle über das System fehlt, insbesondere bei unterschiedlichen GPUs von verschiedenen Anbietern mit unterschiedlichen Arbeitsspeicher- und Reaktionsbeschränkungen. Seine Lösung hierfür besteht darin, sich auf unterschiedliche Inferenzbibliotheken für jeden Hardwareanbieter zu verlassen, die ONNX bereitstellt. Dieser Ansatz ermöglicht es Topaz Labs, eine Modellarchitektur zu erstellen, die von verschiedenen Inferenzbibliotheken verwendet werden kann, während manuelle Arbeit eingespart wird.

  • 04:55:00 In diesem Abschnitt erörtert der Referent die Herausforderungen im Zusammenhang mit der Modellkonvertierung und die Notwendigkeit, Kompatibilitätsprobleme zu testen, bevor ein Modell trainiert wird. Das Problem der Mehrdeutigkeit in Modellspezifikationen wird ebenso hervorgehoben wie die Notwendigkeit, verschiedene Bibliotheken auf Leistung und Konsistenz zu testen. Der Referent erläutert auch die Gründe für die Durchführung mehrerer Konvertierungen und erklärt, dass die Verwendung einer allgemeineren Schnittstelle zu zusätzlichen Ladeschritten und Konvertierungskosten führen kann, die sich auf die Leistung ihrer Apps auswirken können. Abschließend wird der Prozess der Auswahl der geeigneten Konfiguration und der Handhabung der Laufzeit-Inferenzpipeline erläutert, wobei die Notwendigkeit der Kompatibilität und Auswahl hervorgehoben wird, während gleichzeitig eine konsistente Qualität und Geschwindigkeit von Desktops sichergestellt wird.



  • 05:00:00 In diesem Abschnitt spricht ein Redner von NVIDIA über seinen Ansatz zur Handhabung der ONNX-Modellkompatibilität und zur Verbesserung der Bildqualität auf Desktop-Systemen, indem Bilder in Blöcke aufgeteilt und durch Inferenz ausgeführt werden, der Durchsatz maximiert und möglicherweise auf mehreren Geräten und Bibliotheken ausgeführt wird parallel zu. Der Redner geht auch auf die Schwierigkeit ein, sicherzustellen, dass neue Modellarchitekturen hinzugefügt werden können und sich in allen Bibliotheken gut verhalten, was viel Arbeit und Zeit in Anspruch nehmen kann. Anschließend diskutieren sie zwei Tools, ONNX Craft Surgeon, eine Python-Bibliothek, mit der Sie ONNX-Modelle erstellen und ändern können, und Polygraphy, ein Toolkit zum Debuggen von Deep-Learning-Modellen. Der Referent erklärt, wie diese Werkzeuge funktionieren und wie sie verwendet werden können, um Modelle zu konstruieren, die so einfach sind wie das Konstruieren von tf-Graphen.

  • 05:05:00 In diesem Abschnitt stellt der Referent das ONNX-Tooling vor, das eine Python-API und verschiedene Befehlszeilentools enthält, die viele Funktionen zum Manipulieren von ONNX-Modellen bieten. Der Referent konzentriert sich auf ONNX-spezifische Tools, wie z. B. das Inspektionsmodell, das eine Textdarstellung eines ONNX-Modells zeigt, und das vom Chirurgen bereinigte Subtool, das Konstanten im Modell vereinfacht und faltet. Der Chirurgenextrakt ermöglicht es Benutzern, Teilgraphen aus einem Modell zu extrahieren, um es zu debuggen, und der Modellbisektor-Debug reduziert Arbeiten wie git bisect, jedoch für ONNX-Modelle, sodass man das kleinste fehlerhafte Modell finden kann, um Fehler im System zu diagnostizieren.

  • 05:10:00 In diesem Abschnitt erläutert der Moderator die Verwendung des Calligraphy-Debug-Reduzierungs-Tools zum Debuggen von Modellen, die möglicherweise Laufzeitprobleme aufweisen. Durch Reduzieren der Modellgröße und Testen jedes Zwischenmodells können Entwickler problematische Bereiche im Code identifizieren und den Debugging-Prozess vereinfachen. Der Moderator erklärt auch, wie Qualcomm mit der Community zusammenarbeitet, indem ONNX als Austauschformat verwendet wird, das auf einer Vielzahl von Geräten verwendet werden kann, von Ohrhörern über Laptops bis hin zu Automobilsystemen. Durch das Targeting von Modellen mit ONNX können Entwickler Modelle erstellen, die mit allen von Qualcomm unterstützten Geräten kompatibel sind.

  • 05:15:00 In diesem Abschnitt spricht der Referent über die Herausforderungen beim Umgang mit verschiedenen Architekturen von Geräten, die unterschiedliche Modelle, Implementierungen und Timing-Anforderungen erfordern. Er gibt ein Beispiel dafür, wie derselbe Algorithmus und dieselbe Technologie, die für Tiefensensoren und Kameras in Mobiltelefonen entwickelt wurden, jetzt für sichere intelligente Türklingeln und Innen- und Außenüberwachungskameras in Autos verwendet werden. Anschließend betont er die Bedeutung der Skalierbarkeit und vergleicht die Unterschiede zwischen Verarbeitungsmaschinenalgorithmen auf CPUs, GPUs und KI-Beschleunigern am Beispiel der Ausführung des Inception V3-Modells, bei dem die Ausführung auf den KI-Beschleunigern bis zu tausend Inferenzen pro Sekunde liefern kann. Freigeben der CPU für andere nützliche Aufgaben.

  • 05:20:00 In diesem Abschnitt erklärt ein Vertreter von Qualcomm, wie sie Beschleuniger für künstliche Intelligenz (KI) in ihre Hardware integriert haben, um Leistung und Skalierbarkeit zu verbessern. Durch die Verwendung eines speziell entwickelten KI-Beschleunigers können sie KI-Arbeitslasten ohne den zusätzlichen Energieverbrauch oder langsamere Geschwindigkeiten bewältigen, die häufig aus der Verwendung einer CPU oder GPU resultieren. Darüber hinaus ermöglicht ihnen ihr ONNX-Austauschformat das Kompilieren und Ausführen von Modellen für maschinelles Lernen über verschiedene Geräte und Branchen hinweg, was dem Unternehmen Zeit spart und mehr Portabilität ermöglicht. Sie haben auch einen einheitlichen Software-Stack und eine Bibliothek erstellt, die eine Vielzahl von Betriebssystemen unterstützen und Hardware-Details verbergen, um Kunden die Verwendung ihrer Hardware zu erleichtern.

  • 05:25:00 In diesem Abschnitt stellt der Referent den Software-Stack vor, den Qualcomm rund um ONNX entwickelt hat. Sie haben eine Komplettlösung entwickelt, die die ONNX-Laufzeit sowie ein Delegationssystem umfasst, das sich um das Routing von Modellen an die CPU oder GPU kümmert, je nach Anwendungsfall des Geräts. Der Referent bespricht die vielen Werkzeuge, die sie entwickelt haben, darunter Compiler, Profiler, Analysatoren und die Aktivierung von Suchwerkzeugen für Netzwerkarchitekturen. Der Redner betont die Skalierbarkeit und Vielseitigkeit von ONNX und wie es für verschiedene Anwendungsfälle von Geräten verwendet werden kann, darunter Kameraalgorithmen, intelligente Lautsprecher und XR-Geräte.

  • 05:30:00 In diesem Abschnitt erläutert der Referent den Entwicklungsprozess des ANITA-Compilers, der verwendet wird, um einen Referenzdialekt in Mair für eine einfache Optimierung über verschiedene Architekturen bereitzustellen und die Modelle in verschiedenen Umgebungen bereitzustellen. Der Redner hebt auch das Framework hervor, das sie eingeführt haben, um benutzerdefinierte Beschleuniger zu unterstützen, mit dem sie auswählen können, welche Operatoren hochgeladen werden sollen, und den Beschleuniger einfach ein- und ausschalten können. Der Referent gibt auch einen Überblick darüber, wie die Optimierung in ONNX Mlir eingesetzt wird, wo das ONNX-Modell schrittweise in eine Zwischendarstellung abgesenkt wird.

  • 05:35:00 In diesem Abschnitt spricht der Sprecher über den ONNX-Compiler und wie mehrere Dialekte für die CPU- und Beschleunigeroptimierung verwendet werden. Die Optimierung auf hoher Ebene umfasst die Optimierung auf Graphebene, und auf niedrigeren Ebenen wird die Optimierung auf CPU- und Beschleunigeroperationen angewendet. Der Referent präsentiert ein Beispiel dafür, wie ein Beschleuniger-Framework im Compiler funktioniert, bei dem die Verwendung des Beschleunigers 11-mal schneller ist als die Ausführung auf einer CPU. Sie erwähnen auch, wie sie sich auf die Optimierung von Deep-Learning-Operatoren konzentrieren und Online-Machine-Learning-Operatoren sowie andere Beschleuniger wie die CPU unterstützen werden. Abschließend bedanken sie sich bei den Mitwirkenden und laden zu weiteren Beiträgen ein, um das ONNX-Projekt weiter auszubauen. Der nächste Redner von Preferred Networks stellt PFVM vor, ihren Compiler für neuronale Netzwerke, der die Zwischendarstellung von ONNX verwendet.

  • 05:40:00 In diesem Abschnitt erörtert ein Mitglied des Compile-Teams einen Anwendungsfall für ONNX in der Moduloptimierung, insbesondere im Hinblick auf seine stabile und gut dokumentierte Zwischendarstellung. Das Team verwendet ONNX, um Modelle mit einer Vielzahl von Optimierungspfaden zu optimieren, indem es ONNX mit Kundenbetreibern erweitert, z. B. das Hinzufügen von Geräteinformationen, um Geräteänderungen und Speicher zu optimieren. Der Referent diskutiert auch die Bedeutung der Forminferenz bei der Moduloptimierung und stellt drei Optimierungsfälle vor. Der erste Fall beinhaltet das Reduzieren des Kernelbereichs-Overheads in Berechnungsgraphen, die auf CUDA ausgeführt werden, indem mehrere elementweise Operatoren zu einem einzigen Fusionsgruppenoperator fusioniert werden.

  • 05:45:00 pass würde viele unnötige Operatoren enthalten, wenn das Modell von einem Programm wie der neuronalen Architektursuche generiert würde. Hier sind Optimierungen wie Shape-Inferenz und Graph-Vereinfachung hilfreich. Die Formableitung ist entscheidend, um zu bestimmen, ob benachbarte elementweise Operatoren miteinander verschmolzen werden können, während die Graphenvereinfachung unnötige Operatoren aus dem Rückwärtsdurchgang entfernen kann. Diese beiden Optimierungen können die Anzahl der erforderlichen Berechnungen erheblich reduzieren und die Gesamteffizienz des Modells verbessern.

  • 05:50:00 In diesem Abschnitt erläutert der Referent die Checkpointing-Technik, die den Speicherverbrauch beim Ausführen eines Moduls reduziert. Durch Modifizieren des Berechnungsgraphen kann die Speichernutzung noch weiter reduziert werden, jedoch auf Kosten einer erhöhten Latenz. Der Referent betont, wie wichtig es ist, die Tensorgrößen zu kennen, um die Speichernutzung abzuschätzen, und gibt die Grenzen des automatischen Checkpointings beim Umgang mit unbekannten Dimensionen an. Darüber hinaus erörtert der Referent die Auswirkungen unbekannter Dimensionen auf Optimierungsmöglichkeiten und skizziert die Verbesserungen, die an der ONNX-Shape-Inferenz vorgenommen wurden. Insbesondere die Einführung der symbolischen Inferenz in ONNX 1.10 hat die Shape-Inferenz durch Datenausbreitung erheblich verbessert.

  • 05:55:00 In diesem Abschnitt erörtert der Redner die Forminferenz in ONNX und erklärt, dass Forminformationen für statische Fälle global von oben weitergegeben werden können, für dynamische Fälle jedoch mehr Unterstützung erforderlich ist. Der Referent zeigt ein Beispiel eines ONNX-Diagramms, bei dem die Form einer Umformung geschätzt werden muss, aber derzeit unbekannt ist. Sie schlagen vor, mehr Formschlussfunktionen für dynamische Fälle zu implementieren, und fragen, ob Unterstützung für Fälle wie die Verkettung von zwei Tensoren unterschiedlicher Größe erforderlich ist. Der Referent erwähnt auch kurz Optimierungen für den md4-Supercomputer, der nur Modelle mit statischer Form und ohne dynamische Verzweigung akzeptiert und statische Informationen für Scheduling und Optimierungen verwendet. Als Nächstes hält ein Vertreter von Huawei einen vorab aufgezeichneten Vortrag darüber, wie man Spark die Leistung von ONNX zur Schlussfolgerung bringen kann.

  • 06:00:00 In diesem Abschnitt liegt der Schwerpunkt auf dem SPARK-Verbesserungsvorschlag, allgemein bekannt als SPIP, der darauf abzielt, den Prozess der Bereitstellung von Modellen für maschinelles Lernen in Spark zu vereinfachen und ihn in DL-Frameworks von Drittanbietern zu integrieren. Dieser Vorschlag richtet sich an Data Engineers oder Entwickler, die DL-Modelle auf Spark bereitstellen müssen. Das Endziel besteht darin, die Komplexität der Umwandlung der Registerkartenverarbeitung und der Modellinitialisierung innerhalb einer modalen UDF zu verbergen, sodass Benutzer die ONNX-Inferenz auf Big Data problemlos durchführen können. Huaweis eigener KI-Prozessor namens Ascend wird eingeführt, und es wird erklärt, dass man zur Vervollständigung der SPARK- und ONNX-Pipeline auf der Ascend-Plattform zuerst die Ascend-Unterstützung in der ONNX-Laufzeit einführen sollte.

  • 06:05:00 In diesem Abschnitt erörtert der Referent das Ascend-KI-Ökosystem und die verschiedenen Prozessoren, die es unterstützt. Das Ascend 310 unterstützt nur KI-Inferenz, während das Ascend 710 und 910 sowohl Training als auch Inferenz unterstützen. Darüber hinaus bietet das Ökosystem eine Softwareschicht namens „Kung“, die APIs für Entwickler bereitstellt, um KI-Anwendungen und -Dienste einfach zu erstellen. Der Referent konzentriert sich dann auf Khan, den aktuellen Software-Stack im Ascend-Ökosystem, und die neueste Version, Khan 5.0. Sie erklären die verschiedenen Schichten von Khan und wie es Operatorbibliotheken, Optimierungs-Engines und einen Framework-Adapter für Entwickler bereitstellt. Der Redner erörtert dann die Roadmap für das Hinzufügen von Khan als neuen Ausführungsanbieter für die ONNX-Laufzeitumgebung, sodass Benutzer ONNX-Modelle direkt auf Ascend-Hardware ausführen können.

  • 06:10:00 In diesem Abschnitt des Videos endet der ONNX Community Day mit den Roundtable-Diskussionen für die persönlichen Teilnehmer. Die Roundtables bestanden aus sechs verschiedenen Themen, mit großen Notizblöcken, die den Teilnehmern zum Schreiben zur Verfügung standen. Die Themen wurden basierend auf den Beiträgen der Teilnehmer ausgewählt und umfassen ONNX für Mobile und Edge, Modellbereitstellung und Quantisierung des maschinellen Lernens, Schulung und Betrieb, Konvertierungen und Betreiber. Das ONNX Runtime-Team stand ebenfalls zur Verfügung, um sich an den Gesprächen zu beteiligen. Nach den Gesprächsrunden genossen die Teilnehmer eine Happy Hour mit Speisen und Getränken und wurden ermutigt, die Umfrage auszufüllen, um Feedback zu geben.
ONNX Community Day!
ONNX Community Day!
  • 2022.06.24
  • www.youtube.com
This event is being hosted in-person at the brand-new Microsoft Silicon Valley Campus on Friday, June 24th. The event will cover ONNX Community updates, part...