Imparare ONNX per il trading - pagina 4

Nuovo commento
 

Discussione sulla roadmap ONNX 2020 n. 2 20200909



Discussione sulla roadmap ONNX 2020 n. 2 20200909

Nel video "ONNX Roadmap Discussion", i relatori discutono vari argomenti relativi alla roadmap di ONNX, tra cui l'inferenza della forma, le definizioni degli operatori, le implementazioni di riferimento e le specifiche ONNX. I relatori suggeriscono di costruire un'infrastruttura di inferenza di forma generica per migliorare l'ottimizzazione dell'inferenza di forma, riducendo il numero di operatori primitivi, aggiungendo implementazioni di riferimento per ogni operatore e casi di test meglio definiti per garantire la corretta implementazione e test di ONNX. Il gruppo prevede di continuare le discussioni all'interno dell'operatore SIG e nel forum di discussione di GitHub per l'aggiunta di un nuovo operatore.

  • 00:00:00 In questa sezione, i relatori discutono della roadmap ONNX e trattano alcuni argomenti suggeriti, in particolare shape inference, off definition e IR, tutti menzionati in precedenza nel documento della roadmap, con commenti di varie persone. I relatori chiedono se Changming o Buchan sono disponibili a spiegare le loro proposte. Buchan discute il suo feedback sull'interferenza della forma e su come ha avuto problemi con essa in passato. Suggerisce di costruire un'infrastruttura di influenza della forma generica che ricompili la forma ogni volta che si verifica un cambiamento nell'IR per garantire che l'ottimizzazione dell'inferenza della forma vada di pari passo e migliori l'ottimizzazione contemporaneamente. I relatori concludono che ciò si applica più all'ottimizzazione che direttamente all'inferenza della forma.

  • 00:05:00 comprendere le attuali capacità di ONNX in termini di deduzione della forma e passaggi di ottimizzazione. L'infrastruttura esistente supporta già l'inferenza delle forme basata su valori di input noti e può essere utilizzata per dedurre le forme di output. L'aggiornamento del controllo del modello potrebbe comportare frutti a basso impatto, ma altre modifiche potrebbero richiedere ulteriori discussioni. Il gruppo discute se queste modifiche appartengono a ONNX o in un luogo diverso. Considerano anche l'idea di chiamare metodi di inferenza di forma per ciascun operatore in cicli consecutivi per ottenere i risultati desiderati. In definitiva, l'infrastruttura esistente consente già i passaggi di ottimizzazione e l'inferenza della forma, ma modifiche e miglioramenti potrebbero potenziare queste capacità.

  • 00:10:00 In questa sezione, i relatori discutono le definizioni degli operatori e suggeriscono di ridurre il numero di operatori primitivi poiché altri operatori possono essere resi componibili con operatori di livello inferiore. Discutono anche il tema dell'implementazione di riferimento e la necessità per l'infrastruttura di valutare una sequenza di operatori. L'attuale implementazione di riferimento esiste sotto forma di un'implementazione Python nel generatore di casi di test, ma non è organizzata in modo da semplificare la valutazione di una sequenza di operatori. I relatori suggeriscono di aggiungere un runtime come il runtime ONNX ai CI per verificare i sottografi delle funzioni, che possono essere utilizzati per la convalida.

  • 00:15:00 In questa sezione, i relatori discutono della necessità di implementazioni di riferimento per ogni operatore per garantire che i tempi di esecuzione non si discostino dalle aspettative dell'autore. Suggeriscono di utilizzare l'implementazione di riferimento come unit test per convalidare la parità con il runtime e anche come modalità interprete per verificare l'interpretabilità e la convalida. I relatori notano che l'utilizzo del runtime ONNX per convalidare la funzione è possibile supponendo che la funzione sia composta da operazioni primitive che esistono in ONNX. Tuttavia, l'utilizzo del runtime ONNX per i nuovi operatori in un sottografo che include nuove operazioni primitive non è possibile poiché nessun altro runtime avrebbe tale implementazione. Riconoscono che la creazione di un'implementazione di riferimento richiede molto lavoro, ma è obbligatoria per ogni operazione. Sottolineano inoltre la necessità della conformità ONNX per garantire che il tempo di esecuzione non si discosti dalle aspettative dell'autore.

  • 00:20:00 In questa sezione, i relatori discutono dell'uso di implementazioni di riferimento nelle specifiche ONNX e dell'importanza di un linguaggio chiaro e conciso nelle specifiche. Mentre alcuni sostengono l'uso di implementazioni di riferimento per rimuovere l'ambiguità nel testo inglese della specifica, altri sostengono che la specifica dovrebbe essere sufficientemente chiara in modo che le implementazioni di riferimento non siano necessarie. I relatori discutono anche dell'importanza di rigorosi test di conformità per garantire che tutti i possibili casi limite siano testati. In definitiva, il consenso sembra essere che mentre le implementazioni di riferimento possono essere utili, non dovrebbero essere richieste nelle specifiche ONNX.

  • 00:25:00 In questa sezione, c'è una discussione sui requisiti per l'implementazione di un operatore in ONNX, in particolare per quanto riguarda la necessità di un'implementazione di riferimento e procedure di test. Mentre alcuni sostengono che un'implementazione di riferimento per l'operatore dovrebbe essere obbligatoria per generare dati di test, altri non sono d'accordo, affermando che è sufficiente fornire una funzione Python per generare dati di test o un set di dati fisso. Tuttavia, si noti che avere un'implementazione di riferimento è fondamentale per qualcuno che implementa l'operatore in un runtime per testare correttamente la propria implementazione, in particolare per operatori complicati con molti attributi diversi. La discussione chiarisce inoltre che mentre non è necessario un runtime di riferimento per ONNX, è necessaria un'implementazione di riferimento per ciascun operatore.

  • 00:30:00 In questa sezione del video, i relatori hanno discusso dell'importanza di disporre di un'implementazione di riferimento e di casi di test meglio definiti per garantire la corretta implementazione e test di ONNX. Hanno notato che fare affidamento sui dati di test generati può essere insufficiente e che avere a disposizione un semplice codice risolve il problema per tutti. La conversazione ha anche toccato la necessità di una specifica completa e la libertà del runtime di determinare cosa fare in casi di comportamento indefinito. Alcuni oratori hanno espresso preoccupazione per l'aggiunta di un onere a coloro che propongono gli operatori aggiungendo un'implementazione di riferimento. Hanno suggerito di ridurre al minimo lo sforzo ingegneristico e di rivedere i requisiti attuali per l'aggiunta di operazioni al sistema.

  • 00:35:00 In questa sezione del video, i relatori discutono dell'importanza di disporre di specifiche complete e inequivocabili per ONNX e dei modi per applicarle. Concordano sul fatto che un'implementazione di riferimento in Python sarebbe utile per garantire che le persone che implementano gli operatori nei runtime possano verificare tutti i casi di test. Tuttavia, riconoscono anche che l'implementazione di una specifica non è semplice e che ci sono ancora problemi da affrontare. Discutono i modi per chiarire come la specifica può essere utilizzata e propongono che la pratica e il feedback dovrebbero guidare la proposta di nuovi operatori, piuttosto che proporre un operatore e poi implementarlo in un runtime. Notano inoltre che un requisito per l'aggiunta di una nuova operazione è che dovrebbe essere implementata in un framework ben noto.

  • 00:40:00 In questa sezione della discussione sulla roadmap di ONNX, il gruppo discute il processo per l'aggiunta di nuovi operatori alle specifiche di ONNX. La proposta è di modificare la politica per l'aggiunta di un nuovo operatore, che richiede già un'implementazione di riferimento in Python. La loro discussione è incentrata sulle implementazioni di riferimento e sui test di conformità e hanno in programma di continuare la conversazione all'interno dell'operatore SIG e nel forum di discussione di GitHub. Il gruppo prevede di continuare le discussioni nella prossima riunione prevista per la settimana successiva.
 

Discussione sulla roadmap ONNX 2020 n. 3 20200916



Discussione sulla roadmap ONNX 2020 n. 3 20200916

La discussione in questo video è incentrata su vari argomenti relativi a ONNX, tra cui il miglioramento della gestione degli errori, l'aggiunta di un campo dello schema di metadati predefinito per indicare la creazione del modello, la necessità di un'ottimizzazione fisica della quantizzazione e la possibilità di aggiornare i modelli ONNX da Model Zoo a le versioni più recenti. Il team prevede di dare la priorità a questi argomenti in base al loro impatto e al loro costo e di lavorare su di essi dopo la versione 1.8. Inoltre, il gruppo considera l'idea di creare collegamenti linguistici diversi per il set di strumenti ONNX, con un particolare interesse per Java, al fine di supportare diverse piattaforme come Spark. I relatori discutono anche della possibilità di creare un wrapper Java attorno al Runtime ONNX.

  • 00:00:00 In questa sezione, il relatore suggerisce di discutere tre argomenti con la comunità: gestione degli errori, miglioramento dello zoo modello e implementazione di più operazioni o operatori per la quantizzazione. Hanno in programma di utilizzare le prossime tre sessioni per parlare del costo e dell'impatto di questi argomenti e per stabilire le priorità in base agli elementi con il massimo impatto e il basso costo. Rispondono anche a una domanda sull'impatto di questi argomenti sulla versione 1.8 e spiegano che la maggior parte di queste modifiche verrà apportata dopo la 1.8. Un membro della comunità suggerisce di migliorare la gestione degli errori in modo che se il runtime rileva protobuf non corretti, non verrà terminato e restituirà invece un codice di errore o genererà un'eccezione per garantire una migliore esperienza utente.

  • 00:05:00 In questa sezione, la discussione è incentrata sul miglioramento della gestione degli errori del codice di caricamento in ONNX al fine di prevenire arresti anomali e migliorare la funzionalità. Il team ha condotto il fuzzing sul codice e ha scoperto che i modelli non attendibili hanno il potenziale per interrompere l'intero processo, rendendolo una priorità assoluta da affrontare. Il runtime ONNX ha un processo di controllo diverso dal controllo ONNX e non è ancora chiaro se possono condividere lo stesso controllo. Inoltre, viene sollevato l'argomento di una migliore gestione degli errori durante gli audit e il team prevede di dare seguito a questo suggerimento.

  • 00:10:00 In questa sezione, il relatore discute la loro libreria chiamata Trivial che interagisce con l'ecosistema ONNX e serve i modelli ONNX. Propongono di aggiungere un campo dello schema di metadati predefinito in ONNX per indicare il timestamp in cui è stato creato il modello, l'algoritmo di addestramento utilizzato per il modello e quale libreria di origine è stata utilizzata per generarlo. Suggeriscono di definire nomi di chiavi standard per il campo dei metadati e anche di digitarli. Il relatore ritiene che avere uno schema per il campo dei metadati sarebbe utile per le biblioteche e altri utenti che servono modelli ONNX. La conversazione si sposta quindi sulla necessità di estendere il test del modello per coprire tutti i modelli in Model Zoo e fornire buoni esempi di alta qualità.

  • 00:15:00 In questa sezione, la discussione è incentrata sulla necessità di un'ottimizzazione fisica della quantizzazione e sull'espansione dello zoo di modelli di ONNX per includere modelli quantizzati. Ci sono state diverse richieste per includere modelli quantizzati nello zoo modello e il team spera di trovare collaboratori. Citano un blog in cui il modello ONNX quantizzato di Hugging Face ha funzionato bene, ma avrebbero bisogno del permesso di Hugging Face per pubblicarlo. È stato anche suggerito che il modello di punta della libreria dei trasformatori potrebbe essere un esempio per la quantizzazione, e Microsoft e lo spazio ci lavorano entrambi. Inoltre, si è discusso sull'ottimizzazione e alcuni hanno convenuto che è meglio lasciare l'ottimizzazione al runtime in quanto va oltre l'ambito delle specifiche di ONNX.

  • 00:20:00 In questa sezione, i partecipanti discutono della possibilità di aggiornare i modelli ONNX da Model Zoo alle versioni più recenti utilizzando lo strumento Version Converter. Tuttavia, notano che il convertitore di versione non è completamente aggiornato e vi è qualche incertezza sulla necessità della conversione, poiché ONNX supporta tutte le versioni precedenti. Il gruppo considera anche l'idea di diverse associazioni linguistiche per il set di strumenti ONNX, con un particolare interesse per Java, al fine di supportare diverse piattaforme come Spark. L'aggiunta di un'API Java o di collegamenti faciliterebbe il caricamento e la convalida dei file modello e la creazione di un convertitore da altre librerie nel formato ONNX.

  • 00:25:00 In questa sezione, i relatori discutono della possibilità di creare un wrapper Java attorno al runtime ONNX, che semplificherebbe le cose per i progetti di machine learning basati su JVM come Spark. Sebbene sia un'impresa non banale, l'utilizzo dei preset Java CPP per generare automaticamente gli stub potrebbe essere un buon punto di partenza. La compatibilità con le versioni precedenti è fondamentale per progetti di grandi dimensioni come Spark e il targeting per Java 8 richiederebbe un lavoro significativo. Tuttavia, se c'è abbastanza interesse e disponibilità da parte della comunità a contribuire, potrebbe essere una buona cosa da esplorare.
 

Discussione sulla roadmap ONNX 2020 n. 4 20200923



Discussione sulla roadmap ONNX 2020 n. 4 20200923

La quarta parte della discussione sulla roadmap ONNX copre gli argomenti del supporto dei frame di dati, la pre-elaborazione, la standardizzazione, la pipeline di machine learning end-to-end e i consigli sugli strumenti. Il supporto dei frame di dati è valutato come prezioso per i classici modelli di machine learning e potrebbe eliminare la necessità di pre-elaborazione. Viene evidenziata la necessità di acquisire la pre-elaborazione all'interno del modello ONNX per migliorare le prestazioni, con particolare attenzione alla standardizzazione di categorie di alto livello come l'elaborazione delle immagini. La pipeline end-to-end è classificata come una priorità bassa, ma si consiglia di aggiungere gradualmente componenti alla pipeline. La discussione si conclude con la raccomandazione di utilizzare uno strumento per aiutare l'ulteriore discussione e analisi dei punti all'ordine del giorno.

  • 00:00:00 In questa sezione, i relatori discutono della roadmap ONNX e delle funzionalità suggerite dalla community. Finora hanno coperto tre sezioni, tra cui la pipeline ML e l'elaborazione dei dati, la definizione operativa o IRS e la robotica di base. Il documento della tabella di marcia include una tabella delle funzionalità suggerite, classificate come priorità alta, media e bassa. Tuttavia, alcuni argomenti sono troppo generici, rendendo difficile valutarne l'importanza. I relatori hanno in programma di trascorrere i prossimi 30 minuti discutendo del motivo per cui alcune di queste funzionalità sono state valutate in modo elevato e raccogliendo feedback dalla community su quali funzionalità sono più importanti.

  • 00:05:00 si chiedeva quale fosse la priorità della roadmap ONNX, questa sezione del video discute l'importanza di una funzione di supporto del frame di dati e come potrebbe potenzialmente risolvere altri problemi all'interno della piattaforma. Il relatore spiega che questa funzione sarebbe preziosa per i data scientist e potrebbe potenzialmente annullare la necessità di una funzione di pre-elaborazione. Menzionano anche la necessità di ottenere una stima dei costi di ingegneria per ogni elemento della tabella di marcia al fine di stabilire le priorità delle attività in modo efficace. Si accettano suggerimenti poiché è la prima volta che la tabella di marcia viene presentata in questo modo.

  • 00:10:00 In questa sezione della discussione sulla roadmap ONNX, viene discussa l'importanza del supporto dei frame di dati per i modelli di machine learning. Si ritiene che il supporto dei frame di dati sia principalmente per i classici modelli di apprendimento automatico, piuttosto che DNN o altri modelli. Il frame di dati è diverso dalla sequenza in quanto è una raccolta eterogenea di tensori o una tabella relazionale con colonne che possono avere tipi diversi. L'importanza di ciascuna caratteristica viene valutata in base all'impatto che avrà e verranno presi in considerazione i costi di progettazione. Si suggerisce di fornire un commento per casella per evidenziare perché una caratteristica è di importanza alta o bassa.

  • 00:15:00 In questa sezione viene discussa l'importanza della pre-elaborazione all'interno di un modello ONNX. La conversazione evidenzia la necessità di acquisire tutti i passaggi necessari all'interno del modello ONNX piuttosto che affidarsi a librerie esterne, soprattutto nel contesto della formazione, dove la pre-elaborazione può avere un impatto significativo sulle prestazioni. Inoltre, la pre-elaborazione può essere utile dal punto di vista dell'inferenza, in particolare se non in un ambiente basato su Python. La discussione tocca anche le sfide della standardizzazione della pre-elaborazione a causa della natura eterogenea dei tipi di dati. Sebbene la pre-elaborazione sia un argomento ampio e complesso, la conversazione conclude che è necessario considerare gli operatori e i tipi mancanti all'interno di ONNX per standardizzare la pre-elaborazione.

  • 00:20:00 In questa sezione, i relatori discutono dell'ampia portata della pre-elaborazione e di come potrebbe includere non solo l'elaborazione relativa alla visione, ma anche i dati audio. Sebbene la pre-elaborazione sia importante da considerare, i relatori notano che potrebbe non essere necessario supportare tutti i tipi di dati e, invece, la standardizzazione su categorie di alto livello come l'elaborazione delle immagini potrebbe essere più vantaggiosa per gli sviluppatori. Tuttavia, i relatori avvertono che anche attività di pre-elaborazione apparentemente semplici come il ridimensionamento delle immagini possono avere sottili differenze tra i casi limite tra le librerie, rendendo la standardizzazione una sfida ingegneristica. Tuttavia, la standardizzazione delle attività di pre-elaborazione può essere utile e i relatori suggeriscono di raccogliere passaggi di pre-elaborazione comuni per considerazioni future.

  • 00:25:00 In questa sezione, i relatori discutono della priorità di includere la pipeline di machine learning end-to-end in ONNX, con alcuni che affermano che si tratta di una priorità bassa visti gli altri elementi che devono essere affrontati. Tuttavia, riconoscono l'utilità di disporre di un esempio end-to-end e di un'illustrazione di come ONNX può essere applicato, in particolare quando ONNX Runtime viene inserito nel mix. Viene suggerita l'idea di aggiungere gradualmente componenti alla pipeline, con particolare attenzione alla parte di formazione, alla messa a punto di ONNX e infine all'aggiunta di pre-elaborazione nel mix. La discussione si conclude con la raccomandazione di utilizzare uno strumento per facilitare ulteriori discussioni e analisi di impatto dei punti all'ordine del giorno.

  • 00:30:00 In questa sezione, il relatore ringrazia tutti per essersi uniti e informa il pubblico che cercherà di pubblicare la discussione sui social media e sul sito web di ONNX.
 

Discussione sulla roadmap ONNX 2020 n. 5 20201001



Discussione sulla roadmap ONNX 2020 n. 5 20201001

Durante la discussione sulla roadmap ONNX, il team ONNX ha discusso di varie funzionalità suggerite dai membri della comunità e valutate da diverse persone, incluso il comitato direttivo. Mentre alcune caratteristiche sono state concordate all'unanimità, altre hanno diviso la comunità. Il team ha discusso la possibilità di modificare ONNX IR in più IR e librerie di ottimizzazione IR centralizzate. Hanno anche discusso l'idea di centralizzare le librerie di ottimizzazione all'interno di ONNX e il requisito per le operazioni di implementare un'interfaccia standard e uno stile di codifica. Il team ha anche discusso la possibilità di avere un semplice runtime per i modelli ONNX e l'uso di operazioni Python personalizzate per i casi in cui il runtime ONNX non è disponibile. Inoltre, il team ha esplorato la relazione tra le operazioni di pre-elaborazione e l'uso di frame di dati, pianificando di trasformare le proprie idee in proposte attuabili per il lavoro futuro.

  • 00:00:00 In questa sezione, il team ONNX discute il foglio di calcolo dell'analisi dell'impatto che è stato creato per catturare i pensieri di diverse persone su ciò che è importante per il progetto. Hanno elencato tutte le diverse funzionalità suggerite e hanno ottenuto punteggi da persone diverse, incluso il comitato direttivo e altri membri della comunità. Hanno notato che c'erano alcune funzionalità in cui tutti sembrano concordare sul fatto che sia davvero importante o per niente importante, e altre in cui la comunità era divisa. Hanno discusso di quelli che erano stati divisi e i passaggi successivi per quelli che hanno concordato sono stati importanti. Hanno anche parlato della creazione di criteri per ciò che è considerato ad alta priorità e di come ciò dipenda da chi è disposto a impegnare il tempo per implementare una funzionalità.

  • 00:05:00 In questa sezione della discussione sulla roadmap ONNX, i partecipanti discutono l'idea di cambiare ONNX IR in più IR e librerie di ottimizzazione IR centralizzate. Si discute se queste due idee debbano essere raggruppate insieme poiché l'ottimizzazione e l'IR sono questioni separate. L'obiettivo di avere più IR è semplificare e concatenare operazioni più semplici mentre le librerie di ottimizzazione migliorerebbero l'ONNX principale. C'è un'ulteriore discussione su cosa si intende per ONNX IR e sono necessari chiarimenti. I partecipanti discutono anche di come questi potenziali cambiamenti potrebbero influire sui loro punteggi attuali sulla roadmap ONNX.

  • 00:10:00 In questa sezione, il team discute la possibilità di centralizzare le librerie di ottimizzazione in ONNX, ma alla fine concorda sul fatto che l'ottimizzazione dovrebbe far parte del runtime e che ha una priorità inferiore rispetto ad altri problemi. Discutono anche del requisito per l'implementazione delle operazioni in un modo specifico, con un'interfaccia standard e uno stile di codifica, che è già un requisito ma potrebbe richiedere modifiche. Suggeriscono che se qualcuno propone uno stile specifico, può essere accettato se sembra accettabile.

  • 00:15:00 In questa sezione, i relatori discutono l'idea di avere un runtime semplice per i modelli ONNX, che solleva preoccupazioni circa la complessità della richiesta di un flusso di esecuzione e IR interno per elaborare il modello. Tuttavia, è utile poter eseguire e valutare i modelli ONNX per testare e stabilire la correttezza, soprattutto nel rivelare eventuali lacune nei test unitari per gli operatori. Sebbene possa essere discutibile quanto impegno e quanto costo sarebbero necessari per implementare un semplice runtime, il runtime ONNX ha la capacità di collegare le operazioni Python, che potrebbero essere utilizzate per questo scopo.

  • 00:20:00 In questa sezione, i partecipanti alla ONNX Roadmap Discussion hanno parlato della possibilità di utilizzare un'operazione Python personalizzata per casi specifici in cui il runtime ONNX non è disponibile . Hanno discusso i limiti dell'operazione Python e la necessità di un'interfaccia standard per garantire la fattibilità. Inoltre, il gruppo ha discusso della necessità di maggiori capacità di pre-elaborazione all'interno del grafico ONNX per rendere i modelli più autonomi e portatili, in particolare per la pre-elaborazione basata su immagini come il ridimensionamento e la gestione dei riquadri di delimitazione. Il gruppo ha notato che la pre-elaborazione del testo, in particolare la tokenizzazione, è un problema più complicato e completo, ma potrebbe essere in grado di astrarre alcuni scenari comuni di pre-elaborazione.

  • 00:25:00 In questa sezione, i partecipanti discutono la relazione tra le operazioni di pre-elaborazione e l'uso di frame di dati. Sebbene concordino sul fatto che la pre-elaborazione e i frame di dati siano collegati, li vedono come entità separate che richiedono diversi tipi di lavoro. La pre-elaborazione è vista come un operatore che lavora per riga su una colonna di un frame di dati, mentre l'estrazione stessa del frame di dati mappa l'operatore di pre-elaborazione attraverso le righe di una colonna. Il gruppo vede i due come strettamente legati e prevede di trasformare le loro idee in proposte attuabili per il lavoro futuro.
 

Discussione sulla roadmap ONNX 2021 n. 1 20210908


Discussione sulla roadmap ONNX 2021 n. 1 20210908

Durante l'ONNX Roadmap Discussion, IBM Research ha presentato la sua proposta per un nuovo framework di pipeline di machine learning che converte i tipici modelli di pre-elaborazione dei dati su Pandas Dataframe in formato ONNX. Il framework, chiamato Data Frame Pipeline, è open source su GitHub e può essere definito utilizzando l'API fornita, che viene eseguita su Python durante la fase di addestramento. I relatori hanno anche discusso della necessità di rendere ONNX visibile in linguaggi diversi da Python, come Java, C# e C++, e dell'esportazione di modelli ONNX e della loro emissione da altri linguaggi. Inoltre, hanno discusso le attuali funzionalità dei convertitori ONNX Python e C++ e la necessità di funzionalità di scoping, denominazione e patch durante la scrittura di modelli ONNX.

  • 00:00:00 In questa sezione, Takuya di IBM Research presenta la sua proposta per un nuovo framework di pipeline di machine learning con nuovi operatori ONNX. La motivazione della proposta era dovuta all'incapacità dei framework di pipeline esistenti di rappresentare un modello tipico di pre-elaborazione dei dati. Hanno prototipato un nuovo framework di pipeline chiamato Data Frame Pipeline su Python, che converte i tipici modelli di preelaborazione dei dati su Pandas Dataframe in formato ONNX. Hanno protetto tre nuovi operatori ONNX, tra cui un operatore di data e due operatori semplici, concatenatori di stringhe e separatori di stringhe. Il framework della pipeline è open source su GitHub e può essere definito utilizzando l'API fornita, che viene eseguita su Python durante la fase di training. Il modello viene addestrato utilizzando i dati emessi dalla pipeline del frame di dati e il relativo framework può utilizzare modelli di machine learning ONNX già convertiti.

  • 00:05:00 In questa sezione, il relatore discute il formato ONNX e come può essere utilizzato con il runtime ONNX, fornito da Microsoft. Menzionano che nel loro prototipo hanno implementato 11 trasformatori di frame di dati in Python e li hanno mappati agli operatori ONNX, con la maggior parte dei semplici mapping ma alcuni che richiedono analisi e conversione, come il trasformatore di funzioni. Discutono anche del loro approccio alla generazione di operatori ONNX con proprietà del corpo cariche, piuttosto che eseguire operatori di aggregazione su ONNX. Il relatore condivide i risultati sperimentali preliminari che mostrano una significativa accelerazione durante l'apprendimento della pre-elaborazione su ONNX, con un miglioramento delle prestazioni di 300 volte per la codifica categorica. Confrontano anche l'accuratezza della previsione e menzionano la loro proposta, aprendo la parola a domande e commenti sugli operatori presentati.

  • 00:10:00 In questa sezione, Adam Pogba di Oracle Labs suggerisce che ONNX dovrebbe essere reso visibile in linguaggi diversi da Python, poiché l'attuale funzionalità è tutta racchiusa in Python e non è chiaro se C++ sia un obiettivo valido per l'associazione. Pogba spiega che il model checker dovrebbe essere visibile in altri linguaggi in modo che gli utenti possano interagire con esso senza bisogno di un ambiente Python valido. Inoltre, Pogba afferma che ONNX Runtime occasionalmente genera segfault durante l'utilizzo di modelli a causa di problemi di analisi e il controllo del modello potrebbe essere utilizzato per convalidare e risolvere facilmente questo problema.

  • 00:15:00 In questa sezione, il relatore discute le funzionalità principali del controllo del modello e come sarebbe utile essere esposto in altri linguaggi. Sebbene vorrebbero averlo in Java, capiscono che non tutti scriverebbero un'API Java, quindi un'API C è un'opzione migliore per la maggior parte dei linguaggi a cui collegarsi facilmente. Tuttavia, deve esserci un obiettivo stabile e appropriato a cui le persone possono associarsi e non è immediatamente chiaro se l'API C++ di uno di questi strumenti sia considerata un obiettivo appropriato per l'associazione. L'oratore è disposto a partecipare a questo sforzo, ma non vale la pena cercare di galvanizzare un grande sforzo a meno che non ci sia interesse da parte della comunità.

  • 00:20:00 In questa sezione, il relatore discute l'esportazione di modelli ONNX e la loro emissione da altri linguaggi oltre a Python, come C# e Java, con particolare attenzione a ML.NET e Trivial Library. Il relatore sottolinea la necessità di un'API comune che tutti i progetti possano utilizzare per generare modelli ONNX, soprattutto considerando le tre diverse implementazioni attualmente presenti senza codice condiviso che sono soggette a bug. L'API comune garantirebbe un solo posto per aggiornare e convalidare i nodi e i grafici, offrendo l'opportunità di condividere la forza e rendere più facile per altre librerie di machine learning l'emissione di modelli ONNX. Il relatore riconosce che, sebbene questo possa richiedere molto lavoro, lo sforzo condiviso potrebbe far crescere l'ecosistema ONNX oltre Python.

  • 00:25:00 In questa sezione, i relatori discutono dei convertitori ONNX Python e C++ e delle loro attuali funzionalità. Notano che la documentazione ONNX non è sufficientemente specifica, il che rende difficile comprendere determinate funzionalità. Tuttavia, affermano che molte delle funzionalità necessarie per l'esportazione ONNX esistono già in questi convertitori, ma devono essere esposte nel modo giusto ad altri progetti. Inoltre, discutono della necessità di funzionalità di definizione dell'ambito, denominazione e patch durante la scrittura di modelli ONNX. Infine, suggeriscono che i convertitori potrebbero trarre vantaggio dall'essere collegati al sig dell'infrastruttura dell'architettura in modo che possano essere utilizzati facilmente da persone diverse.
 

Discussione sulla roadmap ONNX 2021 n. 2 20210917



Discussione sulla roadmap ONNX 2021 n. 2 20210917

Nella ONNX Roadmap Discussion #2 20210917, vari relatori hanno discusso diverse aree chiave in cui ONNX necessita di miglioramenti, tra cui quantizzazione e facilità di fusione, ottimizzazione dei kernel per piattaforme hardware specifiche e aggiunta di funzioni locali del modello a ONNX. Altri argomenti includevano feedback sul supporto della pipeline end-to-end, sfide affrontate dai clienti su piattaforme diverse e problemi con la conversione di grafici GRU e LSTM. Alcune soluzioni suggerite includevano la fornitura di maggiori informazioni per i backend per l'esecuzione di grafici pre-quantizzati, il miglioramento dell'interoperabilità di diversi framework e l'inclusione di uno spazio dei nomi relativo al grafico originale per consentire sia una soluzione generale che ottimizzata. Inoltre, i relatori hanno discusso della necessità di una migliore implementazione dei pacchetti per un'adozione più ampia e del potenziale per lo sviluppo di più convertitori per supportare i modelli multimodali.

  • 00:00:00 In questa sezione, Martin di Green Waves Technologies discute le due aree in cui ONNX necessita di miglioramenti, quantizzazione e facilità di fusione. Per la quantizzazione, Martin suggerisce di fornire maggiori informazioni ai back-end per eseguire grafici pre-quantizzati, poiché è impossibile per ONNX seguire tutti i diversi modi in cui i clienti desiderano implementare cose specializzate. Per aiutare in questo, Martin suggerisce di aggiungere ai tensori informazioni su min max, deviazione standard e media, con informazioni aggiuntive come statistiche anomale, informazioni canale per canale e informazioni sulla distribuzione come possibili componenti aggiuntivi. Per facilitare la fusione, Martin suggerisce di migliorare l'interoperabilità di diversi framework fornendo migliori funzionalità di importazione/esportazione, che renderebbero più facile per ONNX identificare i giusti convertitori da utilizzare durante l'importazione/esportazione di diversi grafici.

  • 00:05:00 In questa sezione, il relatore discute l'uso corrente delle funzioni per gli operatori composti e la difficoltà nell'ottimizzare i kernel per specifiche piattaforme hardware quando gli operatori vengono scomposti. Viene suggerita l'idea di raggruppare le funzioni esportate in un contenitore di livello superiore, possibilmente una funzione, e mappare quel contenitore su un kernel ottimizzato su un backend specifico. L'oratore suggerisce inoltre di includere uno spazio dei nomi relativo al grafico originale, consentendo sia una soluzione generale che una soluzione ottimizzata. Viene menzionata anche l'aggiunta della possibilità di importare le funzioni locali del modello nell'ultima versione di ONNX.

  • 00:10:00 In questa sezione, i relatori discutono dell'aggiunta di funzioni locali modello a ONNX, che consente agli operatori del convertitore di includere un corpo di funzione nel modulo proto come segnaposto per gli operatori che non sono definiti nello standard ONNX. Tuttavia, i relatori osservano anche che dovrebbe essere una buona pratica per i trasformatori etichettare e commentare ciò che stanno esportando in un modo che sia leggibile dalla macchina. Toccano anche come l'ottimizzazione può influenzare le convenzioni di denominazione e suggeriscono di continuare la discussione sull'argomento nel canale Slack o in una riunione extra. Viene introdotta la presentazione successiva, che riguarda la profilazione ONNX.

  • 00:15:00 In questa sezione viene discusso un feedback sul supporto della pipeline end-to-end, con ONNX visto come un'ottima soluzione per distribuzioni leggere su diversi sistemi operativi che non richiedono requisiti di ecosistema pesanti. I relatori esprimono la speranza nella direzione di consentire agli operatori ONNX sia ONNX che ONNX ML di eseguire non solo modelli ma anche fasi di preparazione dei dati, inclusa la copertura di altri tipi di operazioni di produzione di dati. Affermano che un artefatto o un modello di distribuzione semplificato o comune potrebbe aggiungere valore, insieme alla capacità di risparmiare fatica e coerenza concentrandosi su frutti a bassa pendenza attorno alle conversioni standard.

  • 00:20:00 In questa sezione, il relatore discute alcune delle sfide affrontate dai clienti su diverse piattaforme e rileva il potenziale valore nel continuare a sviluppare e ampliare la piattaforma ONNX. Toccano la questione del siloing e la necessità di semplificare l'implementazione dei pacchetti per una migliore adozione. La conversazione include anche i commenti di un partecipante che conferma di aver affrontato problemi simili e propone opzioni per unire il server Linux ONNX o trovare modi migliori per aiutare gli utenti a convertire il codice personalizzato in ONNX. Il relatore tocca anche il tema del supporto multimodale e la necessità di rappresentare un insieme di modelli come un singolo grafico ONNX. Discutono della potenziale necessità di più convertitori e suggeriscono un movimento generale nella giusta direzione.

  • 00:25:00 In questa sezione della discussione sulla roadmap ONNX, il team discute esempi di proxy per modelli proxy per mostrare i tipi di cose che i clienti utilizzano negli ambienti aziendali per tipi di casi d'uso diversi dalle immagini. Un membro del team cita un esempio di proxy per un modello di rilevamento delle frodi che utilizza alcuni dati aperti ed è un modello LSTM a due livelli relativamente semplice. Il team sta indagando ulteriormente sulla questione e sta cercando di ottenere ulteriori esempi di modelli proxy da portare avanti. Discutono anche dei problemi con GRU e LSTM che non vengono convertiti correttamente e menzionano che vorrebbero aggiungere il supporto per tutti i casi.

  • 00:30:00 In questa sezione, i relatori discutono le sfide della conversione dei grafici GRU (gated recurrent unit) in un formato che può essere letto dal convertitore di un back-end. Dicono che ci sono alcuni casi in cui il guasto si verifica già in TensorFlow, ma è difficile riportarlo in GRU. Suggeriscono di utilizzare il flag `--custom ops` e di creare un kernel che funzioni per esso, prima di passare all'idea di renderlo una funzione o preservarlo in termini di semantica. Notano che l'opzione migliore è indicare esplicitamente se l'utente lo desidera scomporre o meno e che l'utilizzo di operazioni personalizzate potrebbe essere l'unico modo per farlo in modo affidabile.

  • 00:35:00 In questa sezione, i relatori discutono se sia meglio avere il corpo completo delle funzioni sia in ONNX che ad alto livello o avere solo una base TF. Per loro, la base TF sarebbe sufficiente in quanto l'ONNX potrebbe essere utilizzato come prova del risultato lungo la catena. Tuttavia, mettono in guardia dal rendere ONNX TensorFlow incentrato poiché ONNX dovrebbe essere in grado di provenire da luoghi diversi. Hanno anche toccato l'attrattiva di avere un sottografo denominato con un significato semantico, pensandolo quasi come un operatore, che deve essere definito e generato da diversi front-end. Infine, hanno concordato di tenere presentazioni più approfondite per continuare la discussione con persone più informate.
 

Discussione sulla roadmap ONNX 2021 n. 3 20210922



Discussione sulla roadmap ONNX 2021 n. 3 20210922

Durante la discussione sulla roadmap ONNX, i relatori hanno affrontato la necessità di risolvere i problemi con lo strumento di conversione offset di ONNX per migliorare l'adozione di ONNX con l'ultimo stack ottimizzato per determinati casi d'uso. I relatori hanno proposto una migliore copertura dei modelli per testare la conversione dell'offset e la risoluzione dei passaggi intermedi che attualmente mancano nei test dell'operatore o del livello. Hanno anche discusso dell'importanza dei metadati e dell'infrastruttura di apprendimento federato, inclusa la necessità di includere i metadati nelle specifiche ONNX per le annotazioni di apprendimento trasferite e il concetto di apprendimento federato per consentire la privacy, l'efficienza e l'uso delle risorse computazionali. I relatori hanno incoraggiato la collaborazione della comunità e hanno chiesto feedback per discutere ulteriormente e implementare queste idee. La prossima sessione è prevista per il 1 ottobre.

  • 00:00:00 In questa sezione, Manoj di Intel affronta le lacune nelle conversioni offset per i modelli ONNX che hanno causato problemi a molti clienti. Il problema di base risiede nella conversione dell'offset poiché molti clienti non continuano ad aggiornare l'offset una volta che distribuiscono un modello in produzione. I clienti devono affrontare diversi problemi con la conversione dell'offset, ad esempio il passaggio da 7 a 10 a 13 per la quantizzazione o l'impossibilità di convertire gli offset precedenti in quelli più recenti per sfruttare le prestazioni e la buona precisione. Inoltre, il test unitario o tutti i test relativi a ogni operatore o livello non sono all'altezza del punto in cui gli ISV sono soddisfatti e, quindi, la maggior parte dei clienti ha ancora un offset di 10 o 9.

  • 00:05:00 In questa sezione, i relatori discutono della necessità di risolvere i problemi con lo strumento di conversione offset di ONNX, in quanto ostacola l'adozione di ONNX con l'ultimo stack ottimizzato per determinati casi d'uso. Gli sviluppatori che stanno integrando l'intelligenza artificiale e la distribuiscono nelle loro applicazioni stanno fornendo feedback sulla necessità di correggere gli strumenti di conversione e assicurarsi che siano perfetti. Condividono esempi di problemi che hanno dovuto affrontare, come passaggi intermedi mancanti e implementazioni di adattatori mancanti, che impediscono la transizione a modelli di prestazioni quantizzati. I relatori sottolineano la necessità di una migliore copertura e di più modelli da testare per garantire una migliore adozione di ONNX.

  • 00:10:00 In questa sezione del video, i relatori discutono della necessità dell'approvazione di almeno un modello difettoso da parte di un'importante azienda di creatori per ulteriori miglioramenti in ONNX. La discussione si sposta sul miglioramento della conversione fp16, che era uno dei divari tra diversi ecosistemi come mobile e Windows, e su come è stato risolto ultimamente con gli strumenti di conversione Microsoft. La responsabilità della conversione non è chiara, ma la discussione passa alla prossima presentazione relativa allo zoo modello, in cui l'inclusione di operatori fonetici per la formazione contribuirà a coprire tutti i modelli in tutte le categorie. Propongono di iniziare con trasformatori o campioni di formazione NLP e passare a più modelli per mostrare l'infrastruttura di formazione distribuita e le tecniche applicabili a ONNX.

  • 00:15:00 In questa sezione, i relatori discutono del coinvolgimento dei modelli ONNX nell'addestramento, inclusa l'importanza dell'addestramento consapevole della quantizzazione e dell'utilizzo di precisione mista. Richiedono il modello fp32 originale per confrontare meglio l'accuratezza e mostrare l'utilizzo di precisione mista per l'addestramento con i modelli ONNX. Danno la priorità al contributo ai campioni di trasformatore, ma richiedono aiuto dalla comunità per contribuire ad altre categorie popolari. Discutono anche proposte future per riflettere meglio l'utilizzo della precisione mista all'interno di un modello come parte dei metadati. Infine, Gabe Stevens presenta una configurazione di distribuzione che Intel sta iniziando a esaminare.

  • 00:20:00 In questa sezione, il relatore discute il concetto di apprendimento distribuito e federato ei suoi vantaggi in termini di privacy, latenza, efficienza e utilizzo delle risorse computazionali. L'idea è di distribuire i modelli su una flotta di dispositivi, in cui alcuni dispositivi hanno un gruppo di addestramento che arricchisce il modello utilizzando i dati che vedono. Le modifiche proposte a ONNX consentirebbero di facilitare l'apprendimento federato, rendendo più probabile l'utilizzo di ONNX da parte degli sviluppatori. Il set minimo di aggiunte all'API include un modo per interrogare la parte per ottenere i parametri del modello locale, aggiornare tali parametri e notificare al server come il modello è cambiato per consolidarsi in un nuovo modello che include i risultati del dispositivi.

  • 00:25:00 In questa sezione del video, il relatore discute l'idea di includere i metadati nelle specifiche ONNX per consentire il trasferimento delle annotazioni di apprendimento e semplificare l'addestramento di un set di dati più piccolo con un modello addestrato su un set di dati più grande. Tuttavia, l'implementazione di un tale sistema comporta molteplici decisioni di progettazione che devono essere lasciate agli implementatori. Il relatore suggerisce tre elementi che potrebbero facilitare l'infrastruttura di base di un tale sistema senza limitare la flessibilità necessaria per gli sviluppatori di applicazioni. Menzionano anche la necessità di coerenza nella distribuzione della versione del modello su una flotta di dispositivi e l'importanza di non imporre che solo i modelli ONNX possano partecipare a un sistema di apprendimento federato. L'oratore sollecita un feedback sul fatto che i progettisti delle specifiche siano interessati a prestare attenzione a questo tipo di configurazione dell'apprendimento e se sarebbero aperti a ulteriori discussioni. Un altro relatore suggerisce di provare a farlo con il runtime ONNX, poiché supporta la formazione e sono state create alcune prove di concetti per eseguire l'apprendimento federato utilizzandolo.

  • 00:30:00 In questa sezione, il relatore esprime il proprio apprezzamento per l'enorme impegno profuso nella presentazione e ringrazia la comunità per le domande. L'obiettivo della presentazione è presentare idee al SIG competente per ulteriori discussioni ed eventuali implementazioni. L'ultima sessione si terrà il 1° ottobre e il relatore attende con impazienza di continuare a partecipare a queste idee.
 

Meetup virtuale della community ONNX – marzo 2021



000 ONNX 20211021 ONNX SC Benvenuto Progress Roadmap Release

Il workshop ONNX è iniziato con un'introduzione, in cui gli organizzatori hanno sottolineato l'importanza della partecipazione della comunità alla crescita dell'ecosistema ONNX. Hanno anche fornito una panoramica dell'ordine del giorno, che includeva aggiornamenti sulle statistiche ONNX, presentazioni della comunità e discussioni sulla tabella di marcia del comitato direttivo di ONNX. Le proposte di roadmap mirano a migliorare il supporto, la robustezza e l'usabilità del framework ONNX e includono operatori di pre-elaborazione, API C, apprendimento federato e una migliore integrazione dell'elaborazione e dell'inferenza dei dati. È stata discussa anche la recente versione della versione 1.10 delle specifiche ONNX e i partecipanti sono stati incoraggiati a porre domande e partecipare al canale ONNX Slack per continuare la conversazione.

  • 00:00:00 In questa sezione del workshop, gli organizzatori forniscono una panoramica e danno il benvenuto a tutti i partecipanti. Menzionano la vasta gamma di prodotti disponibili per l'intelligenza artificiale e invitano i partecipanti a verificarlo. Gli obiettivi generali del workshop sono ottenere gli ultimi aggiornamenti su ONNX, i suoi processi, la roadmap e le versioni, nonché imparare dai partecipanti della comunità su come viene utilizzato ONNX. Incoraggiano i partecipanti a condividere il loro feedback, a partecipare maggiormente al comitato direttivo ONNX, ai SIG e ai gruppi di lavoro. Forniscono una panoramica dell'agenda, che include la logistica del gruppo di lavoro ONNX, la presentazione sullo stato dello stato di Wenming Yi, seguita da Alex, e le presentazioni della comunità. Infine, presentano aggiornamenti entusiasmanti sulle statistiche di ONNX, incluso un aumento di quasi il 400% dei download mensili a 1,6 milioni al mese, che mostra una sana crescita nell'ecosistema.

  • 00:05:00 In questa sezione, il relatore discute i progressi e la crescita dell'ecosistema ONNX, sottolineando l'importanza dei contributi delle aziende nella comunità. L'oratore menziona il progetto di libreria deep java di Amazon, che ha creato una buona esperienza per la comunità Java e ha visto una grande crescita. Diverse aziende commerciali come IBM, AMD e Sony stanno fornendo supporto per l'ecosistema e aiutando ONNX a diventare lo standard del settore. Il relatore parla anche della governance della comunità e dei nuovi membri del comitato direttivo e invita a partecipare alle discussioni sulla roadmap, al canale Slack, alle domande e risposte su GitHub e al contributo alla documentazione e ai blog. Il prossimo relatore prosegue con la tabella di marcia, che è fondamentale per muoversi nella giusta direzione e ridurre i modelli ONNX a batterie per CPU e acceleratori.

  • 00:10:00 In questa sezione, il relatore discute le discussioni sulla tabella di marcia del comitato direttivo di ONNX, che si sono svolte durante l'estate. Le proposte ricevute dai diversi membri sono suddivise in quattro gruppi di tre proposte ciascuno, e ciascun gruppo viene presentato ai rispettivi Sig per l'approvazione e l'attuazione. Le proposte spaziano da operatori di pre-elaborazione, API C, verifica del modello, supporto per l'emissione di modelli in altri linguaggi, aggiunta di informazioni sui metadati nei tensori, migliore integrazione dell'elaborazione e dell'inferenza dei dati, definizione dei concetti per l'apprendimento federato, definizione delle proprietà di elaborazione dei metadati per migliorare l'integrità di dati, modelli e altro ancora. L'obiettivo è consentire un migliore supporto, robustezza e usabilità del framework ONNX per tutti gli utenti.

  • 00:15:00 In questa sezione, il relatore discute il recente rilascio della versione 1.10 delle specifiche ONNX e ringrazia i contributori per il loro duro lavoro. Ci saranno ulteriori discussioni e dettagli su quest'ultima modifica sul sito next.ai. Il relatore invita il pubblico a pubblicare eventuali domande nella chat o nel canale Slack generale di ONNX per continuare la conversazione.
 

Giornata della comunità ONNX! Trasmesso in diretta il 24 giugno 2022

Questo evento sarà ospitato di persona presso il nuovissimo Microsoft Silicon Valley Campus venerdì 24 giugno.

L'evento riguarderà gli aggiornamenti della community ONNX, le storie di partner e utenti e un ampio networking della community.



Giornata della comunità ONNX!

Breve riassunto:

  • 00:00:00 - 01:00:00 Il video di YouTube "ONNX Community Day!" discute gli aggiornamenti e i miglioramenti al lavoro della comunità ONNX sull'interoperabilità e la flessibilità per gli sviluppatori che lavorano con i modelli di machine learning. La comunità ONNX lavora sotto una governance aperta e le tre categorie di strumenti, creazione, esecuzione e visualizzazione, supportano l'impegno e l'utilizzo di ONNX da parte della comunità. Il video fornisce rapporti sullo stato di avanzamento su diversi aspetti, come aggiornamenti delle specifiche ONNX, nuovi operatori e miglioramenti nei convertitori. Il relatore evidenzia inoltre i vantaggi di ONNX, tra cui la più ampia gamma di clienti per i fornitori di hardware e l'accesso a più framework e acceleratori hardware per gli utenti. Il futuro di ONNX include la nozione di funzioni ONNX per fornire una specifica eseguibile.

  • 01:00:00 - 02:00:00 L'evento ONNX Community Day discute diversi argomenti relativi a ONNX, tra cui ONNX Model Zoo e ONNX Tutorial, che forniscono modelli e demo di machine learning preaddestrati da utilizzare con i modelli ONNX. Il video evidenzia il lavoro dell'ONNX Preprocessing Working Group, che mira a standardizzare le operazioni di preelaborazione dei dati per migliorare la distribuzione del modello. I relatori discutono anche delle basi della quantizzazione delle reti neurali e di come TensorRT supporti le reti quantizzate attraverso varie fusioni, tra cui la quantizzazione post-addestramento e l'addestramento consapevole della quantizzazione. Inoltre approfondiscono i limiti di ONNX nella rappresentazione della quantizzazione a bassa precisione e suggeriscono una strategia per estendere il suo potere rappresentativo utilizzando il ritaglio per indurre precisione tra i nodi quantizzati e dequantizzati. Infine, il video approfondisce un caso di studio sull'accuratezza di un modello salvato TensorFlow quantizzato e messo a punto.

  • 02:00:00 - 03:00:00 L'ONNX Community Day ha ospitato numerosi relatori che hanno discusso dell'importanza dei metadati nei modelli di machine learning e del supporto di Java Virtual Machine (JVM) in ONNX. I relatori hanno sottolineato l'utilizzo di tecnologie basate su hardware per proteggere i dati e hanno evidenziato la compatibilità di ONNX con varie librerie di machine learning, tra cui DeepJ e Deep Java Library. Hanno dimostrato l'uso di buffer di byte per una migliore efficienza e hanno discusso l'importanza della standardizzazione dei metadati per un'intelligenza artificiale responsabile e spiegabile. Le presentazioni presentavano anche storie di successo, tra cui il runtime di una banca cinese migliorato utilizzando ONNX e il runtime ONNX. La community ONNX sta lavorando alla creazione, all'interrogazione e al filtraggio dei metadati dal flusso di lavoro degli hub con il supporto dei metadati leggibili dalla macchina in ONNX. Nel complesso, le presentazioni hanno evidenziato i punti di forza della piattaforma ONNX e l'impegno della comunità per il suo sviluppo.

  • 03:00:00 - 04:00:00 L'"ONNX Community Day!" il video copre vari aggiornamenti e funzionalità relative all'ecosistema ONNX. Ciò include la discussione sulla simulazione della quantizzazione per ridurre il calo di precisione tra modelli quantizzati e pre-addestrati, l'implementazione di modelli TensorFlow addestrati con il toolkit di NVIDIA su un grafico ONNX utilizzando TensorRT e i miglioramenti apportati a ONNX Runtime, come la forma del tensore ottimizzata, i fornitori di esecuzione e supporto per piattaforme mobili. Inoltre, sono stati discussi gli aggiornamenti allo stesso ONNX, incluso il supporto per la libreria XNNpack e la creazione di estensioni di runtime ONNX per le attività di pre/post-elaborazione. Il video introduce anche la libreria Optimum, che si concentra sull'accelerazione dei modelli di trasformatore dall'addestramento all'inferenza.

  • 04:00:00 - 05:00:00 L'ONNX Community Day ha incluso discussioni su vari argomenti relativi al runtime ONNX e ai suoi casi d'uso. I relatori hanno descritto le funzionalità del pacchetto runtime ONNX, il convertitore PiTorch ONNX e le operazioni personalizzate in PyTorch. Hanno anche discusso casi d'uso come il monitoraggio dei processi e la digitalizzazione del commercio, nonché le sfide associate all'implementazione del modello e ai test di compatibilità. Durante l'evento, è stato sottolineato che il runtime ONNX può aiutare a migliorare le prestazioni e ridurre le dimensioni dell'implementazione, ma la compatibilità e la selezione sono essenziali per garantire qualità e velocità costanti.

  • 05:00:00 - 06:00:00 L'ONNX Community Day ha visto diversi relatori discutere di vari strumenti e tecniche utilizzati per ottimizzare e distribuire modelli di machine learning utilizzando il framework ONNX. NVIDIA ha discusso il proprio approccio per migliorare la qualità dell'immagine e la compatibilità dei modelli utilizzando la suddivisione dei blocchi per l'inferenza, nonché i propri strumenti specifici ONNX per il debug e la modifica dei modelli. Qualcomm ha spiegato come ha integrato gli acceleratori AI nei propri progetti utilizzando ONNX come formato di interscambio e ha introdotto il proprio stack software che include il runtime ONNX e vari strumenti per l'ottimizzazione e l'implementazione. Inoltre, diversi relatori hanno discusso dell'ottimizzazione dei modelli ONNX utilizzando tecniche come l'ottimizzazione dei moduli, il checkpoint e l'inferenza della forma. L'evento ha evidenziato la versatilità e la scalabilità di ONNX per vari casi d'uso dei dispositivi e ha incoraggiato i contributi per continuare a far crescere il progetto ONNX. L'ultima parte è incentrata sulla semplificazione del processo di distribuzione dei modelli di machine learning su Spark utilizzando la proposta SPIP, che mira a nascondere le complessità della conversione dell'elaborazione delle schede e dell'inizializzazione del modello per gli sviluppatori. Sono stati introdotti l'ecosistema Ascend AI e i suoi processori, incluso il livello software "Kung" che fornisce API per la creazione di applicazioni e servizi AI. È stato discusso lo stack software Khan ed è stata presentata la roadmap per aggiungerlo come nuovo provider di esecuzione per il runtime ONNX. L'evento si è concluso con tavole rotonde su argomenti come ONNX per dispositivi mobili ed Edge, implementazione di modelli, formazione e operazioni, conversioni e operatori, seguite da un happy hour e feedback sul sondaggio.

Il riepilogo dettagliato della sequenza temporale:
  • 00:15:00 Crea la modalità nel framework che preferisci e quindi esporta il tuo modello in un formato comune che può essere utilizzato da altri framework e strumenti. Ciò consente una maggiore interoperabilità e flessibilità per gli sviluppatori che lavorano con modelli di machine learning. Inoltre, ONNX è vantaggioso per i fornitori di hardware che desiderano creare runtime ottimizzati per i modelli di machine learning poiché ora possono concentrarsi sul supporto del set comune di operatori definito da ONNX piuttosto che dover supportare più framework diversi.

  • 00:20:00 In questa sezione, il relatore discute i vantaggi dell'utilizzo di ONNX, che consente l'accesso a più framework e acceleratori hardware per gli utenti, nonché una più ampia gamma di clienti per i fornitori di hardware. Lo sviluppo di ONNX viene svolto dalla comunità sotto una governance aperta, il che significa che non c'è una singola azienda che lo controlla. Il relatore evidenzia anche i gruppi di lavoro che includono architettura e infra, convertitori di operatori, la zona modello, tutorial e un nuovo gruppo di lavoro di pre-elaborazione. Il relatore prosegue delineando le tre categorie di strumenti, creazione, esecuzione e visualizzazione dei modelli ONNX e fornisce alcune statistiche degli ultimi sei mesi, come un aumento del numero di PR, contributori, stelle e download mensili, rafforzare l'impegno e l'utilizzo di ONNX da parte della comunità.

  • 00:25:00 In questa sezione, il relatore discute i rilasci e gli aggiornamenti che sono avvenuti nella community ONNX dall'ultimo aggiornamento della community. ONNX 1.11 è stato rilasciato all'inizio di quest'anno, che ha introdotto nuovi operatori e aggiornato alcuni operatori, incluso l'hub del modello ONNX, che consente agli utenti di estrarre modelli pre-addestrati da diversi zoo modello. Inoltre, sono state introdotte utilità come l'utilità di composizione e il generatore di funzioni, insieme a correzioni di bug e miglioramenti dell'infrastruttura. ONNX 1.12 è stato recentemente introdotto con più nuovi operatori, miglioramenti di forma e inferenza e supporto per Python 3.10. Il relatore discute anche del processo di roadmap ONNX e di 12 richieste di roadmap che sono state selezionate per ulteriori progressi e assegnate ai gruppi di lavoro. Queste richieste includono l'implementazione di nuovi operatori per la pre-elaborazione dei dati, un'API C per ONNX e altro ancora.

  • 00:30:00 In questa sezione del video, il relatore discute i progressi compiuti nell'affrontare la necessità di informazioni quantizzate più strutturate per fluire attraverso il modello e i tensori. La proposta di pipeline end-to-end con operatori ONNX è in fase di ulteriore affinamento in quanto identificata come intercetta di lungo periodo. Finora sono stati compiuti alcuni progressi con i convertitori, con operazioni di funzionamento più elevate che ottengono supporto. Il relatore tocca anche diverse aree, come la necessità di più volontari in quanto si tratta di un progetto comunitario e una richiesta per le aziende di avere più persone che si uniscono allo sforzo. Il relatore elenca diverse risorse come il sito Web, GitHub, i canali Slack e il calendario ONNX.

  • 00:35:00 In questa sezione, il relatore discute i recenti aggiornamenti e miglioramenti a ONNX. Ci sono state due versioni recenti con vari aggiornamenti come una migliore influenza del chip per gli operatori e una gestione più stabile di input errati e facoltativi. Inoltre, il relatore sottolinea l'aggiunta di due importanti versioni: Model Composer e Function Builder. Anche il convertitore di modelli è diventato più stabile e il team prevede di fornire un supporto migliore per le versioni miste in futuro. Nel complesso, è impossibile elencare tutti i miglioramenti apportati dai contributori, ma continuano a lavorare per migliorare ONNX.

  • 00:40:00 Rama dell'operatore SIG ha fornito un riepilogo delle recenti modifiche e aggiornamenti alla specifica ONNX. L'obiettivo di Operator SIG è evolvere l'insieme di operatori che compongono la specifica ONNX, aggiungendo nuovi operatori e chiarendone le specifiche. Nelle ultime due versioni sono stati introdotti nuovi operatori come grid sample e layer normalization. Operatori esistenti come scatter op sono stati aggiornati per supportare indici duplicati, mentre alcuni op sono stati estesi per fornire supporto per tipi come b float 16 e tipi opzionali. Rama ha anche menzionato i piani per promuovere alcuni dei nuovi operatori per diventare presto funzioni.

  • 00:45:00 In questa sezione, il relatore discute i piani per il futuro di ONNX e il compromesso tra avere una specifica compatta e supportare nuovi tipi di modelli che richiedono più operazioni nelle specifiche. La soluzione a questa sfida è la nozione di funzioni ONNX, che forniscono una specifica eseguibile per un'operazione e consentono un equilibrio tra requisiti contrastanti. L'oratore menziona i piani per ridurre l'insieme di operatori primitivi promuovendoli in funzioni e abilitando l'authoring in Python usando un sottoinsieme chiamato ONNX-Crypt. Vengono forniti esempi di funzioni, come la funzione di attivazione Jello e l'op di dropout, per illustrare come l'uso del flusso di controllo renda più facile specificare in modo naturale e compatto la loro semantica.

  • 00:50:00 In questa sezione, Kevin Chen fornisce un aggiornamento sulla firma del convertitore e sul lavoro svolto dall'ultimo incontro. Discute gli aggiornamenti del convertitore front-end, inclusi i convertitori PyTorch, TensorFlow e sk-learn per ONNX. Per il convertitore PyTorch, l'ultima versione supporta le esportazioni ONNX fino all'offset ONNX 16 e sono state aggiunte nuove funzionalità, come la possibilità di esportare moduli di rete neurale specificamente come funzioni locali ONNX. Chen esamina anche gli aggiornamenti del convertitore back-end, come la centralità ONNX e il convertitore ONNX TensorFlow. Infine, Chen presenta la tabella di marcia per il convertitore sig e incoraggia le persone a mettersi in gioco.

  • 00:55:00 In questa sezione, il relatore discute gli aggiornamenti e i miglioramenti per il convertitore SK learn to ONNX, il convertitore chiave rivelatore ONNX e il convertitore ONNX TensorFlow. Si consiglia agli utenti di eseguire l'aggiornamento alle versioni più recenti per una migliore esperienza utente durante la conversione dei modelli. La roadmap per il converter stick include obiettivi come il miglioramento degli strumenti guidati dalla comunità, la standardizzazione delle funzioni di utilità e il miglioramento del supporto dell'operatore e dell'offset. Gli utenti sono incoraggiati a unirsi al canale dei convertitori ONNX su Slack o iscriversi alla mailing list ONNX Converter SIG per essere coinvolti con la community e fornire feedback.

  • 01:00:00 Jackie di Microsoft presenta ONNX Model Zoo e ONNX Tutorial. ONNX Model Zoo è una raccolta di modelli di machine learning preaddestrati e all'avanguardia, per lo più forniti dalla community ONNX. Attualmente ci sono 168 modelli nello zoo, inclusi 40 modelli ONNX e 35 modelli ONNX basati sulla visione per la classificazione delle immagini e il rilevamento degli oggetti. I tutorial ONNX forniscono documenti e taccuini che dimostrano ONNX nella pratica per diversi scenari e piattaforme. Il Model Zoo ha visto diversi miglioramenti dall'ultimo workshop, inclusi nuovi modelli quantizzati di Intel e una maggiore copertura dei test con test CI di routine, correzione di set di dati di test interrotti e collaborazione con il team Hugging Face per creare un'interfaccia web per la dimostrazione dei modelli.

  • 01:05:00 I relatori discutono della disponibilità di tutorial e demo per l'utilizzo di ONNX, incluso un sito Web che consente una facile elaborazione di immagini e modelli ONNX scrivendo solo poche righe di codice Python. Discutono anche della futura roadmap per ONNX Model Zoo, con piani per consentire a più modelli di essere eseguiti da ORT e per incorporare più contributi, inclusi modelli quantizzati e modelli di esempio di addestramento. Inoltre, evidenziano il lavoro dell'ONNX Preprocessing Working Group, che si concentra sulla semplificazione della preelaborazione dei dati da utilizzare con i modelli ONNX.

  • 01:10:00 In questa sezione del video, il relatore discute la mancanza di standardizzazione nelle pipeline di pre-elaborazione dei dati, evidenziando le differenze tra librerie popolari come Pillow e OpenCV nella pre-elaborazione delle immagini. Queste disparità possono portare a problemi di precisione durante la distribuzione di modelli su piattaforme diverse. Il relatore introduce l'obiettivo del gruppo ONNX di standardizzare le operazioni di pre-elaborazione dei dati per evitare ambiguità e migliorare l'implementazione del modello. Il gruppo ha lavorato per sviluppare l'infrastruttura per includere la pre-elaborazione dei dati nei modelli, come lo sviluppo di utilità di composizione e l'operatore della mappa di sequenza per l'elaborazione in batch. Il gruppo ONNX sta anche studiando modi per contrassegnare la parte di pre-elaborazione di un modello per l'identificazione da parte dei back-end. Inoltre, il gruppo propone estensioni all'operatore di ridimensionamento, tra cui un filtro anti-aliasing opzionale e una politica di mantenimento delle proporzioni.

  • 01:15:00 I relatori discutono dell'implementazione di una proposta di operazione center crop o path, che offre un livello più elevato di astrazione e si basa sugli operatori pad e slice esistenti. Incoraggiano gli spettatori a unirsi al loro canale Slack e alle riunioni mensili per condividere idee. La seguente presentazione è di Joaquin Anton, che riassume l'obiettivo del gruppo di lavoro sulla preelaborazione ONNX e condivide il recente lavoro svolto. Marvin dall'Italia presenta anche se stesso e il suo lavoro come sviluppatore e data scientist nel campo dell'elaborazione del linguaggio naturale.

  • 01:20:00 Il relatore discute l'importanza di controllare la documentazione ONNX prima di iniziare a lavorare su un progetto. Spiegano che non tutti i modelli possono essere facilmente convertiti o ottimizzati per ONNX ed è importante garantire che le funzioni operative richieste per il progetto siano implementate nel framework utilizzato. Inoltre, il relatore sconsiglia di presumere che le migliori opzioni di prestazioni ottimizzeranno sempre un modello, poiché a volte queste opzioni possono effettivamente ridurre la precisione. Nel complesso, è importante considerare attentamente l'architettura del progetto e controllare la documentazione e gli strumenti ONNX come l'ottimizzatore ONNX per evitare errori e garantire un'implementazione corretta sul cloud o sui dispositivi.

  • 01:25:00 In questa sezione, Jiraj Perry di Nvidia discute le basi della quantizzazione delle reti neurali e come TensorRT supporta le reti quantizzate attraverso varie fusioni. Spiega che la quantizzazione è il processo di conversione di valori continui in un insieme discreto di valori utilizzando tecniche di ridimensionamento lineare o non lineare, che possono offrire un'inferenza più rapida e un footprint di memoria inferiore. Tuttavia, potrebbero esserci dei compromessi con la precisione. Jiraj menziona anche i diversi schemi di quantizzazione e l'importanza dei parametri di quantizzazione o q params. Quindi introduce la quantizzazione post-addestramento (PTQ) e l'addestramento consapevole della quantizzazione (QAT) e come possono determinare q params.

  • 01:30:00 In questa sezione, il video discute la quantizzazione post training (PTQ) e il quantization aware training (QAT). PTQ prevede l'esecuzione di un modello pre-addestrato su un set di dati di calibrazione e la raccolta di statistiche a livello di livello per determinare l'intervallo dinamico per ogni livello per il calcolo dei parametri di quantizzazione. QAT introduce i nodi qdq nei livelli desiderati e mette a punto il grafico per un piccolo numero di epoche per apprendere i parametri del modello o di quantizzazione. PTQ è generalmente più veloce e ha meno controllo sulla precisione finale, mentre QAT è più lento ma fornisce un maggiore controllo della precisione. Il video evidenzia anche le differenze di approccio tra il toolkit TF Mod di Google e il toolkit di quantizzazione TF2 di NVIDIA basato su TF Mod.

  • 01:35:00 In questa sezione, l'oratore discute le differenze tra il toolkit di quantizzazione di Nvidia e tf mod in termini di dove sono posizionati i nodi qdq. Il toolkit di Nvidia posiziona i nodi qdq agli input e ai pesi di un livello nella rete, mentre tf mod consiglia di posizionarli ai pesi e alle uscite di un livello. Il relatore descrive anche come TensorRT ottimizzi i modelli attraverso fusioni di strati, come la convoluzione di fusione puntuale e la fusione di pooling, insieme a fusioni dedicate per i nodi qdq. Inoltre, l'ottimizzatore grafico di TensorRT esegue la propagazione qdq per spostare i nodi q e dq per garantire che la porzione massima del grafico venga eseguita in immissione. Gli esempi di fusione presentati includono la quantizzazione media del pool e la fusione per addizione basata sugli elementi. Infine, il relatore esamina la fusione di quantizzazione in un blocco residuo.

  • 01:40:00 In questa sezione, il relatore spiega l'importanza di aggiungere nodi qdq al ramo di identità per ottenere le migliori prestazioni da Tensor RT durante le operazioni di ricaricamento. Le fusioni risultanti sembrano nodi dq dei pesi e degli input che vengono propagati oltre l'annuncio e fusi con nodi q dopo il livello di aggiunta. Il relatore sottolinea la necessità di nodi qdq nel grafico originale per ottenere le migliori prestazioni per il tuo modello e avverte che non utilizzarli correttamente può portare a prestazioni scadenti nel modello. Il relatore conclude invitando una discussione su come inserire nodi qdq nel toolkit TensorFlow.

  • 01:45:00 In questa sezione, il relatore riconosce una difficoltà tecnica nella navigazione delle diapositive e assicura al pubblico che verrà risolto a breve. Passano quindi alla discussione di un caso di studio sull'accuratezza dopo aver ottenuto un modello salvato TensorFlow quantizzato e messo a punto. Il pubblico è invitato a porre qualsiasi domanda prima di fare una breve pausa.

  • 01:50:00 In questa sezione, il relatore discute il concetto di quantizzazione e come può essere utilizzato per rappresentare la bassa precisione nella quantizzazione delle reti neurali. La quantizzazione è una combinazione di due funzioni: la funzione quantizzata che mappa i valori in virgola mobile a valori interi e la funzione quantizzata che mappa i valori interi in una rappresentazione in virgola mobile. La combinazione di queste due funzioni viene definita falsa quantizzazione. Questo processo consente la mappatura delle rappresentazioni in una rappresentazione di soli interi. L'uso della quantizzazione uniforme, in particolare con una precisione ridotta, ha consentito 1,7 miliardi di campioni al secondo con meno di tre microsecondi di latenza sulla piattaforma rf soccer.

  • 01:55:00 In questa sezione, il relatore discute i limiti di ONNX nella rappresentazione della quantizzazione a bassa precisione, specialmente al di sotto degli otto bit, e suggerisce una strategia per estendere il potere rappresentativo di ONNX sfruttando il clipping per indurre la precisione tra i nodi quantizzati e dequantizzati . Questa strategia aggiunge una funzione di ritaglio aggiuntiva che è supportata su limiti interi e non influisce sulla retrocompatibilità con le librerie e gli strumenti esistenti. Tuttavia, questa strategia si estende solo fino a quanto lineare quantizzato consente di andare come operatore e presenta alcune limitazioni relative ai diversi tipi di arrotondamenti. L'oratore menziona anche i loro sforzi con la quantizzazione sul dialetto di esponenziazione (tuonex), che rappresenta la quantizzazione falsa in un solo nodo mentre si estende a un insieme più ampio di scenari con trasmissioni di input, opzioni di quantizzazione binaria e altro. Questo formato viene sfruttato come parte dei loro sforzi di implementazione su FPGA e i loro strumenti, come q ONNX e nqcdq, si integrano con le librerie di quantizzazione esistenti e hanno ottenuto l'adozione nella comunità FPGA.

  • 02:00:00 In questa sezione, Daniel di Mithril spiega come hanno sviluppato una soluzione chiamata "Blind AI" che consente l'implementazione di modelli ONNX all'interno di enclavi sicure che sfruttano l'hardware per proteggere i dati. Utilizzando tecnologie basate su hardware, questa soluzione fornisce l'isolamento e la crittografia del contenuto della memoria dell'enclave che impedisce qualsiasi tentativo di dumping dall'esterno. I dati vengono decrittografati all'interno dell'enclave e qualsiasi utente malintenzionato non può accedere ai dati, il che rappresenta un enorme vantaggio per il proprietario dei dati quando si tratta di privacy e sicurezza. Blind AI è una soluzione open source facile da integrare ed è facile per il fornitore di intelligenza artificiale mantenere e vendere questa soluzione.

  • 02:05:00 In questa sezione, il relatore discute la possibilità di implementare modelli di intelligenza artificiale con garanzie di progresso, utilizzando l'SDK Python per caricare in modo sicuro i modelli e inviare i dati per l'analisi senza consentire a terzi l'accesso ai dati. Viene inoltre evidenziata l'espressività di ONNX, che gli consente di coprire vari casi d'uso, tra cui lo screening dei bagagli, l'analisi di documenti medici e il riconoscimento facciale. L'altoparlante presenta anche diversi modelli utilizzati nella pratica e la loro velocità all'interno e all'esterno dell'enclave, con una ragionevole latenza aggiuntiva dovuta alla protezione che fornisce. Inoltre, ONNX richiede una base di codice minima, che lo rende migliore per motivi di sicurezza e in grado di rafforzare ogni operatore, garantendo un utilizzo sicuro dell'enclave. La presentazione si conclude con informazioni sul loro GitHub e su come possono coprire vari scenari e l'opportunità di approfondire i dettagli tecnici sulla sicurezza.

  • 02:10:00 In questa sezione, il relatore discute la proposta di abilitare i metadati AI leggibili dalla macchina in ONNX, che implica il monitoraggio della provenienza e altre caratteristiche rilevanti di un modello per identificare come si muove nel tempo e si evolve in un caso d'uso specifico. La proposta è stata inizialmente presentata al comitato direttivo ONNX nell'ottobre del 2020 e ora il team desidera estendere ulteriormente la proposta per includere la creazione, l'interrogazione e la visualizzazione dei metadati come parte di una progettazione end-to-end per hub di modelli e zoo. Il relatore sottolinea l'importanza dei metadati come fattore abilitante chiave dell'IA responsabile e spiegabile e sottolinea la sua utilità nel restringere le modalità di errore e nell'identificare i punti deboli per i sistemi di intelligenza artificiale.

  • 02:15:00 In questa sezione della presentazione dell'ONNX Community Day, i relatori discutono dell'importanza dei metadati nei modelli e del potenziale dell'utilizzo di RDF per un approccio più leggibile e standardizzato alla rappresentazione dei metadati. Spiegano come questo approccio può aiutare a stabilire relazioni tra le entità, mantenere la trasparenza e tenere traccia della provenienza, rispondendo alle domande su cosa ha causato un modello con una precisione inferiore al previsto. I relatori discutono anche della potenza dell'interrogazione dei metadati utilizzando SPARQL e spiegano come i modelli con metadati in formato RDF possono fornire informazioni oltre a ciò che può offrire una semplice scheda modello.

  • 02:20:00 In questa sezione, il relatore discute il vocabolario di Furnace control, un insieme di principi guida per rendere i dati e le risorse digitali accessibili, interoperabili e riutilizzabili. I principi di Furnace sono stati identificati dalla comunità del web semantico e includono equità, affidabilità e sostenibilità. I metadati codificati in RDF possono essere interrogati utilizzando l'ontologia di Furnace per scoprire modelli adatti alle attività di PNL, identificare i creatori e le dimensioni dei modelli e tenere traccia dell'impronta di carbonio dei modelli per classificarli e ordinarli. L'estensibilità di RDF e il suo linguaggio di query, Sparkle, consentono un'estensibilità infinita oltre il vocabolario selezionato dalle autorità d'esame. Ciò può consentire il tracciamento dell'IA responsabile e della corrente di precisione mista.

  • 02:25:00 In questa sezione, i relatori discutono delle funzionalità di interrogazione e filtraggio dell'ONNX Community Day. Mostrano come l'autore dei metadati può identificare i modelli addestrati con set di dati contenenti informazioni private o personali utilizzando i tag dei metadati. I relatori dimostrano inoltre come le funzionalità di filtraggio estese consentano agli utenti di interrogare i modelli con precisione mista. Evidenziano la visualizzazione dei profili dei modelli e tecniche di intelligenza artificiale spiegabili per visualizzare i metadati in modo efficiente. I relatori invitano all'azione per prendere in considerazione un progetto concreto sulla creazione e l'utilizzo del modello che copra l'intera creazione di metadati, l'interrogazione e il filtraggio dal flusso di lavoro degli hub con il supporto per i metadati leggibili dalla macchina in ONNX. Attualmente stanno preparando un'implementazione di strawman ed esplorando tecnologie per la creazione di metadati.

  • 02:30:00 In questa sezione, Adam Pocock di Oracle Labs discute l'importanza di supportare la Java Virtual Machine (JVM) con ONNX. Sebbene la maggior parte delle applicazioni ML sia scritta in linguaggi diversi da Python, come Java, portare l'apprendimento automatico in questi linguaggi è fondamentale. L'API Java di runtime di ONNX è stata sviluppata da Oracle Labs per incorporare l'apprendimento automatico in Java e altri linguaggi, con funzionalità come impatto minimo sulle prestazioni e facilità di implementazione. Adam fornisce anche un esempio di codice per dimostrare le somiglianze tra l'API Java e altre API.

  • 02:35:00 In questa sezione, il relatore discute come alimentare i dati ed eseguire un modello utilizzando il tensore ONNX, una rappresentazione del buffer di byte per un flusso di byte. Sebbene sia possibile utilizzare array regolari in Java, l'oratore consiglia di utilizzare buffer di byte a causa del loro percorso di copia zero, che consente una migliore efficienza nella gestione dei dati. L'oratore osserva inoltre che gli array multidimensionali di Java non sono ottimali per l'apprendimento automatico perché non sono piatti e comportano un sacco di inseguimento del puntatore. Il relatore discute ulteriormente i piani per l'aggiornamento a una versione più recente di Java, l'aggiunta di nuove funzionalità e la creazione per adattarsi all'albero di runtime ONNX. Inoltre, il relatore introduce una libreria open source che scrive modelli ONNX da Java, disponibile ovunque sulla JVM.

  • 02:40:00 In questa sezione, i relatori discutono della compatibilità del set di strumenti ONNX con le nuove librerie di machine learning come DeepJ e di come si integra con il runtime ONNX per fornire prestazioni di prim'ordine. DeepJ crea un livello di astrazione su varie librerie di deep learning, astraendo tutte le librerie necessarie e fornendo diversi back-end operatore per i motori di machine learning da utilizzare, come Apache MixTape, Tensorflow, PyTorch, ONNX, Pedal e altro. Stanno anche esplorando modi per standardizzare i metadati in questo set di strumenti per emettere formati di metadati standard continuando ad espandere l'enumerazione degli operatori.

  • 02:45:00 In questa sezione, il relatore discute i vantaggi della libreria Deep Java che include una serie di modelli pre-addestrati che coprono attività come la classificazione delle immagini, il rilevamento degli oggetti, l'analisi dei sentimenti e il riconoscimento delle azioni. La libreria è pronta per il servizio ed è stata sottoposta a test rigorosi per funzionare con la migliore velocità possibile e controllo della memoria, come dimostrato dal suo utilizzo con DHL per oltre sei mesi senza errori. Inoltre, il relatore condivide diversi casi d'uso in cui il runtime ONNX e ONNX è stato utilizzato per ottenere significativi miglioramenti delle prestazioni e ridurre la latenza. Una storia di successo riguarda una banca cinese che è stata in grado di ridurre il runtime dei suoi modelli OCR da un secondo a meno di 400 millisecondi su una singola immagine. Inoltre, l'altoparlante introduce il concetto di motore ibrido, che consente di caricare due motori contemporaneamente e fornisce una transizione graduale tra di loro.

  • 02:50:00 In questa sezione, il relatore spiega un metodo che utilizza il buffer diretto per inviare puntatori da Python direttamente al runtime ONNX, che evita la copia dei dati e fornisce un aumento delle prestazioni. Introducono anche ND Manager, un'architettura ad albero implementata nella libreria DeepDraw per fornire raccolte di memoria più convenienti. Il relatore discute di come i clienti possono passare dall'utilizzo di PyTorch al runtime ONNX senza modificare una sola riga di codice. Successivamente, il relatore di Hype Factors parla della loro società di media intelligence e di come hanno scelto di basare la loro infrastruttura sulla JVM per la sua esperienza di sviluppo, l'ecosistema di componenti riutilizzabili e l'elevata scalabilità.

  • 02:55:00 In questa sezione, il relatore discute gli aspetti tecnici del proprio sito Web di analisi dei media, incluso l'uso della JVM per potenziare la maggior parte delle funzionalità del sito Web e la migrazione a un sistema che arricchisce principalmente tutti i dati in entrata. Con qualche miliardo di inferenze GPU al giorno, le funzionalità del prodotto dipendono fortemente dall'apprendimento automatico e dalla gestione dei modelli, che è diventata una parte essenziale per mantenere tutto attivo e funzionante, portando alla criticità del processo. I dati comprendono tutti i tipi di formati, inclusi HTML e PDF, e tengono traccia del tempo di esecuzione per arricchire i dati al volo, incluso il riconoscimento di entità denominate, la salienza, il sentimento e altro ancora. Ci sono state molte sfide lungo il percorso, inclusi errori di conversione e una rara perdita di memoria in DTL, che ha richiesto un po' di tempo per essere risolta.
 

Giornata della comunità ONNX! Trasmesso in diretta il 24 giugno 2022

Questo evento sarà ospitato di persona presso il nuovissimo Microsoft Silicon Valley Campus venerdì 24 giugno.

L'evento riguarderà gli aggiornamenti della community ONNX, le storie di partner e utenti e un ampio networking della community.



Giornata della comunità ONNX!

Breve riassunto:

  • 00:00:00 - 01:00:00 Il video di YouTube "ONNX Community Day!" discute gli aggiornamenti e i miglioramenti al lavoro della comunità ONNX sull'interoperabilità e la flessibilità per gli sviluppatori che lavorano con i modelli di machine learning. La comunità ONNX lavora sotto una governance aperta e le tre categorie di strumenti, creazione, esecuzione e visualizzazione, supportano l'impegno e l'utilizzo di ONNX da parte della comunità. Il video fornisce rapporti sullo stato di avanzamento su diversi aspetti, come aggiornamenti delle specifiche ONNX, nuovi operatori e miglioramenti nei convertitori. Il relatore evidenzia inoltre i vantaggi di ONNX, tra cui la più ampia gamma di clienti per i fornitori di hardware e l'accesso a più framework e acceleratori hardware per gli utenti. Il futuro di ONNX include la nozione di funzioni ONNX per fornire una specifica eseguibile.

  • 01:00:00 - 02:00:00 L'evento ONNX Community Day discute diversi argomenti relativi a ONNX, tra cui ONNX Model Zoo e ONNX Tutorial, che forniscono modelli e demo di machine learning preaddestrati da utilizzare con i modelli ONNX. Il video evidenzia il lavoro dell'ONNX Preprocessing Working Group, che mira a standardizzare le operazioni di preelaborazione dei dati per migliorare la distribuzione del modello. I relatori discutono anche delle basi della quantizzazione delle reti neurali e di come TensorRT supporti le reti quantizzate attraverso varie fusioni, tra cui la quantizzazione post-addestramento e l'addestramento consapevole della quantizzazione. Inoltre approfondiscono i limiti di ONNX nella rappresentazione della quantizzazione a bassa precisione e suggeriscono una strategia per estendere il suo potere rappresentativo utilizzando il ritaglio per indurre precisione tra i nodi quantizzati e dequantizzati. Infine, il video approfondisce un caso di studio sull'accuratezza di un modello salvato TensorFlow quantizzato e messo a punto.

  • 02:00:00 - 03:00:00 L'ONNX Community Day ha ospitato numerosi relatori che hanno discusso dell'importanza dei metadati nei modelli di machine learning e del supporto di Java Virtual Machine (JVM) in ONNX. I relatori hanno sottolineato l'utilizzo di tecnologie basate su hardware per proteggere i dati e hanno evidenziato la compatibilità di ONNX con varie librerie di machine learning, tra cui DeepJ e Deep Java Library. Hanno dimostrato l'uso di buffer di byte per una migliore efficienza e hanno discusso l'importanza della standardizzazione dei metadati per un'intelligenza artificiale responsabile e spiegabile. Le presentazioni presentavano anche storie di successo, tra cui il runtime di una banca cinese migliorato utilizzando ONNX e il runtime ONNX. La community ONNX sta lavorando alla creazione, all'interrogazione e al filtraggio dei metadati dal flusso di lavoro degli hub con il supporto dei metadati leggibili dalla macchina in ONNX. Nel complesso, le presentazioni hanno evidenziato i punti di forza della piattaforma ONNX e l'impegno della comunità per il suo sviluppo.

  • 03:00:00 - 04:00:00 L'"ONNX Community Day!" il video copre vari aggiornamenti e funzionalità relative all'ecosistema ONNX. Ciò include la discussione sulla simulazione della quantizzazione per ridurre il calo di precisione tra modelli quantizzati e pre-addestrati, l'implementazione di modelli TensorFlow addestrati con il toolkit di NVIDIA su un grafico ONNX utilizzando TensorRT e i miglioramenti apportati a ONNX Runtime, come la forma del tensore ottimizzata, i fornitori di esecuzione e supporto per piattaforme mobili. Inoltre, sono stati discussi gli aggiornamenti allo stesso ONNX, incluso il supporto per la libreria XNNpack e la creazione di estensioni di runtime ONNX per le attività di pre/post-elaborazione. Il video introduce anche la libreria Optimum, che si concentra sull'accelerazione dei modelli di trasformatore dall'addestramento all'inferenza.

  • 04:00:00 - 05:00:00 L'ONNX Community Day ha incluso discussioni su vari argomenti relativi al runtime ONNX e ai suoi casi d'uso. I relatori hanno descritto le funzionalità del pacchetto runtime ONNX, il convertitore PiTorch ONNX e le operazioni personalizzate in PyTorch. Hanno anche discusso casi d'uso come il monitoraggio dei processi e la digitalizzazione del commercio, nonché le sfide associate all'implementazione del modello e ai test di compatibilità. Durante l'evento, è stato sottolineato che il runtime ONNX può aiutare a migliorare le prestazioni e ridurre le dimensioni dell'implementazione, ma la compatibilità e la selezione sono essenziali per garantire qualità e velocità costanti.

  • 05:00:00 - 06:00:00 L'ONNX Community Day ha visto diversi relatori discutere di vari strumenti e tecniche utilizzati per ottimizzare e distribuire modelli di machine learning utilizzando il framework ONNX. NVIDIA ha discusso il proprio approccio per migliorare la qualità dell'immagine e la compatibilità dei modelli utilizzando la suddivisione dei blocchi per l'inferenza, nonché i propri strumenti specifici ONNX per il debug e la modifica dei modelli. Qualcomm ha spiegato come ha integrato gli acceleratori AI nei propri progetti utilizzando ONNX come formato di interscambio e ha introdotto il proprio stack software che include il runtime ONNX e vari strumenti per l'ottimizzazione e l'implementazione. Inoltre, diversi relatori hanno discusso dell'ottimizzazione dei modelli ONNX utilizzando tecniche come l'ottimizzazione dei moduli, il checkpoint e l'inferenza della forma. L'evento ha evidenziato la versatilità e la scalabilità di ONNX per vari casi d'uso dei dispositivi e ha incoraggiato i contributi per continuare a far crescere il progetto ONNX. L'ultima parte è incentrata sulla semplificazione del processo di distribuzione dei modelli di machine learning su Spark utilizzando la proposta SPIP, che mira a nascondere le complessità della conversione dell'elaborazione delle schede e dell'inizializzazione del modello per gli sviluppatori. Sono stati introdotti l'ecosistema Ascend AI e i suoi processori, incluso il livello software "Kung" che fornisce API per la creazione di applicazioni e servizi AI. È stato discusso lo stack software Khan ed è stata presentata la roadmap per aggiungerlo come nuovo provider di esecuzione per il runtime ONNX. L'evento si è concluso con tavole rotonde su argomenti come ONNX per dispositivi mobili ed Edge, implementazione di modelli, formazione e operazioni, conversioni e operatori, seguite da un happy hour e feedback sul sondaggio.


Il riepilogo dettagliato della sequenza temporale:

  • 03:00:00 In questa sezione, un relatore discute la propria esperienza con l'ecosistema ONNX e le sfide che ha dovuto affrontare durante il suo utilizzo. Parlano della necessità di abbinare i driver e impostare il monitoraggio per garantire che il sistema continui a funzionare senza problemi. Menzionano anche i loro piani futuri per aumentare l'efficienza della GPU, aggiungere più modelli e migliorare la robustezza complessiva del sistema attraverso test accelerati dalla GPU. Il relatore invita a qualsiasi domanda e discussione su questo caso d'uso e coglie l'occasione per ringraziare tutti. Il video riprenderà dopo pranzo con un replay del talk NVIDIA.

  • 03:25:00 Mi dispiace, ma questo estratto della trascrizione non è correlato all'"ONNX Community Day!" video. Puoi fornire un altro estratto dal video per farmi riassumere?

  • 03:30:00 In questa sezione del video, i relatori discutono su come simulare la quantizzazione e memorizzare i parametri q finali per ridurre il calo di precisione tra il modello quantizzato e il modello pre-addestrato. Un modo per eseguire l'addestramento consapevole della quantizzazione consiste nell'utilizzare il toolkit di ottimizzazione del modello TensorFlow o il toolkit creato da Nvidia, che offre funzionalità come la quantizzazione dei layer utilizzando il nome del layer e gli attributi della classe e la quantizzazione basata su pattern. I relatori notano che il toolkit di Nvidia utilizza una variante di quantizzazione simmetrica che offre le migliori prestazioni per un modello QAT su una GPU utilizzando un'estensione.

  • 03:35:00 In questa sezione, apprendiamo il processo di distribuzione di un modello addestrato utilizzando TF2 Quantization Toolkit di NVIDIA su un grafico ONNX utilizzando TensorRT. Il flusso di lavoro prevede la quantizzazione di un modello TensorFlow 2.0 preaddestrato con il toolkit di NVIDIA, la messa a punto per un numero limitato di epoche e la conversione in un grafico ONNX utilizzando il convertitore TF2ONNX. Quindi le API di TensorRT vengono utilizzate per generare TensorRT Engine dal grafico ONNX. Vediamo che l'addestramento sensibile alla quantizzazione fornisce un'alternativa per distribuire reti neurali profonde con una precisione inferiore e che i modelli qrt potrebbero essere meno soggetti a un calo di precisione durante l'inferenza rispetto ai modelli ptq a causa della messa a punto dei parametri del modello. Infine, gli esperimenti con i modelli ResNet mostrano che l'accuratezza INT8 è alla pari con l'accuratezza della linea di base FP32 e la latenza è più di 10 volte più veloce rispetto alle loro controparti FP32.

  • 03:40:00 In questa sezione, Ryan Hill, un ingegnere del software che lavora sul runtime ONNX sin dalla sua creazione, parla delle funzionalità e dell'utilizzo del runtime ONNX. Il runtime ONNX è un runtime per modelli ONNX, completamente multipiattaforma e con collegamenti linguistici per molti linguaggi di programmazione. Microsoft lo utilizza in tutti i suoi principali gruppi di prodotti come Windows, Office e Azure, mentre ci sono oltre 160 modelli in produzione con runtime ONNX. Hill passa attraverso notevoli nuove funzionalità nelle versioni recenti, inclusa la possibilità di utilizzare kernel operativi come libreria matematica e la capacità di alimentare inizializzatori esterni interamente in memoria. I miglioramenti delle prestazioni includono l'aggiunta di un ottimizzatore di trasposizione, l'ottimizzazione delle allocazioni dell'heap e la riduzione della necessità di trasformazioni del layout.

  • 03:45:00 In questa sezione, i relatori discutono dei miglioramenti apportati a ONNX Runtime, tra cui la forma tensoriale ottimizzata e le classi vettoriali inline, che si traducono in una riduzione delle allocazioni di heap e in un miglioramento delle prestazioni. Spiegano inoltre i vantaggi dei provider di esecuzione, che consentono a ONNX Runtime di funzionare in modo ottimale su varie possibilità hardware, inclusa un'implementazione completa della CPU come opzione di fallback. Inoltre, evidenziano gli aggiornamenti apportati per supportare le piattaforme mobili e una migliore usabilità per gli sviluppatori mobili, incluso l'uso della conversione NHWC in fase di esecuzione e l'aggiunta di pacchetti Android e iOS con le build ONNX Runtime complete. Infine, introducono ONNX Runtime Web, supportato dalla stessa base di codice di base di ONNX Runtime e con un binario più piccolo, e discutono dell'introduzione di una libreria JavaScript chiamata ONNX Runtime Common.

  • 03:50:00 In questa sezione, i relatori discutono degli aggiornamenti a ONNX, incluso il supporto per la libreria XNNpack e l'imminente supporto OpenGL nella versione 1.12. Affrontano anche le sfide con la pre e post-elaborazione dei dati e la creazione delle estensioni del runtime ONNX, che forniscono una libreria di operazioni personalizzate condivisibili incentrate sul lavoro di pre-post-elaborazione del modello. Queste estensioni includono potenziali funzioni come la conversione del testo in maiuscolo o minuscolo e la separazione di valori positivi e negativi in tensori separati. L'attuale biblioteca si concentra principalmente sull'elaborazione del linguaggio naturale e sui domini della visione e del testo, ma si prevede che si evolverà man mano che verranno identificate nuove esigenze. Presentano anche Jeff di Hugging Face, che discute l'integrazione di ONNX con la libreria Optimum per l'accelerazione dei modelli Transformers.

  • 03:55:00 In questa sezione, il relatore discute la potenza dei modelli di trasformatore e come vengono utilizzati da grandi aziende come Tesla, Gmail, Facebook e Bing per fare miliardi di previsioni ogni giorno. Spiegano che l'obiettivo di Hugging Face è rendere questi modelli accessibili a tutte le aziende del mondo attraverso modelli e strumenti pre-addestrati facilmente accessibili per utilizzarli. Discutono anche della loro attenzione alla costruzione di una comunità che condivide e migliora ciò che è possibile, con oltre 1300 contributori open source alle loro librerie e accesso a oltre 50.000 modelli ottimizzati per ogni attività e linguaggio di machine learning. Il relatore introduce quindi la loro libreria Optimum, che si concentra sull'accelerazione dei modelli di trasformatori dall'addestramento all'inferenza, affrontando le sfide delle risorse di calcolo, memoria e larghezza di banda che derivano dall'aumento dei parametri del modello.


  • 04:00:00 In questa sezione, il relatore discute il pacchetto di runtime ONNX all'interno del toolkit Optimum e la sua capacità di accelerare l'addestramento e l'inferenza dei modelli di trasformatore. Introducono la nuova classe trainer chiamata ORT Trainer che consente agli utenti di ottenere l'integrazione nativa della velocità profonda e ottenere un'accelerazione fino al 40% nel throughput dell'allenamento. Per l'inferenza, ci sono tre classi principali: ORT Optimizer, RT Quantizer e RT Model for Task. Con queste classi, gli utenti possono semplificare il grafico dal proprio modello, ottimizzare i pesi e beneficiare di tutta l'accelerazione hardware offerta dal runtime ONNX. Il relatore menziona anche gli sforzi di collaborazione per consentire l'ottimizzazione del modello sequenza per sequenza attraverso queste classi ottimali di pipeline di inferenza accelerata.

  • 04:05:00 In questa sezione, due relatori discutono della community ONNX, concentrandosi sul processo di ottimizzazione e conversione per i modelli ONNX. Il primo relatore introduce la libreria ottimale, che consente agli utenti di ottimizzare e quantizzare i propri modelli, aumentando il throughput e diminuendo la latenza conservando l'accuratezza dei propri modelli. Il secondo relatore discute l'architettura e il flusso del convertitore PiTorch ONNX, spiegando le fasi di conversione dei modelli PiTorch nella rappresentazione intermedia della torcia, utilizzando le ottimizzazioni dei grafici e la conversione in ONNX IR. Evidenziano anche alcune caratteristiche interessanti, come il supporto per l'esportazione di un modello quantizzato in formato QTQ e l'acquisizione di loop e if di controllo del flusso di Python in modelli ONNX come loop ONNX e nodi if ONNX.

  • 04:10:00 In questa sezione, il relatore discute vari modi per esportare Ops personalizzati in PyTorch, inclusa la scrittura di una funzione autograf a Torch personalizzata e la definizione dei metodi avanti e indietro. Il relatore spiega come utilizzare l'API per registrare una funzione simbolica personalizzata per indicare all'esportatore come esportarla come operazioni ONNX standard o come operazioni personalizzate in un dominio personalizzato. Introducono quindi la funzione ONNX Local Function che consente agli utenti di specificare una determinata classe di modulo Torch o tipo di nodo come funzione per il back-end per essere ancora in grado di eseguire il modello senza avere un kernel specificato. Infine, il relatore afferma che il team continuerà a concentrarsi sul supporto per più modelli e sul miglioramento dell'esperienza di diagnosi dei guasti.

  • 04:15:00 In questa sezione viene discusso un caso d'uso in cui un sistema di telecamere esistente viene riutilizzato per rilevare i dipendenti che entrano in aree pericolose vicino a macchinari in movimento. Utilizzando un modello ONNX open source per il rilevamento delle persone e lo strumento Sasebo Stream Processing di SAS per l'analisi in tempo reale e l'elaborazione degli eventi, è stata sviluppata una soluzione in grado di elaborare milioni di eventi al secondo ed essere adattata a sistemi più grandi. La soluzione è stata inoltre resa disponibile tramite uno studio grafico e un notebook Jupyter per consentire ai data scientist di sviluppare modelli e il runtime ONNX è stato integrato in Sasebo Stream Processing. Per garantire la resilienza, è stata suggerita una soluzione modulare che suddivide l'elaborazione delle immagini in più passaggi con Kafka come coda buffer.

  • 04:20:00 In questa sezione, il relatore descrive un modello di elaborazione della visione artificiale che è stato implementato sull'edge utilizzando Kubernetes come meccanismo di implementazione. Il modello include un processo di acquisizione con un pod per ciascuna telecamera, un bus Kafka per i dati video e un pod di elaborazione che utilizza un modello di visione artificiale per creare i risultati. I risultati vengono poi inviati a un terzo pod che elabora ulteriori dati del sensore del cliente per capire se l'apparecchiatura in fase di registrazione è attiva o meno. Inoltre, il relatore spiega che questa architettura è attualmente in produzione presso una delle strutture del cliente e che l'integrazione del runtime ONNX garantisce un time-to-value ottimale grazie ai modelli pre-addestrati disponibili al pubblico e al riutilizzo delle risorse del cliente. La resilienza dell'architettura è un altro vantaggio chiave ed è assicurata grazie a Kubernetes e Kafka.

  • 04:25:00 In questa sezione, Matthew di Bazaar Voice parla della digitalizzazione del commercio e di come marchi e rivenditori si sono spostati verso l'infinito spazio sugli scaffali attraverso Internet. Con la portata dei dati in possesso delle società di e-commerce, la creazione di insight di grande impatto utilizzando l'intelligenza artificiale può cambiare le regole del gioco. Matthew lo illustra utilizzando Bazaar Voice come esempio, che gestisce ed elabora i dati per oltre un miliardo di acquirenti al mese e fornisce oltre 8 miliardi di recensioni totali per marchi e rivenditori. Concentrandosi sulla condivisione delle recensioni dei prodotti nei cataloghi, il concetto di corrispondenza dei prodotti gioca un ruolo fondamentale. Matthew spiega come viene creato un modello di machine learning per eseguire la corrispondenza dei prodotti confrontando gli identificatori di prodotto univoci, ma gli eventuali residui vengono eseguiti manualmente. Per implementare una soluzione che generi un reale valore aziendale, l'approccio ideale è una soluzione leggera ed economica che mantenga le prestazioni.

  • 04:30:00 In questa sezione, il relatore discute diverse opzioni per la distribuzione di modelli di machine learning, inclusi server virtuali, piattaforme cloud ML e funzioni serverless come Azure Cloud Functions o AWS Lambdas. Dopo aver valutato i pro e i contro di ogni opzione, il relatore e il suo team hanno deciso di sviluppare un modello scikit-learn esportato in formato ONNX, crearlo con Python, distribuirlo in una funzione serverless e utilizzare un ambiente nodo per eseguire l'inferenza su ONNX tempo di esecuzione. Il relatore afferma inoltre che ONNX aiuta a ridurre le dimensioni di distribuzione dei modelli, ma evidenzia le sfide di lavorare entro i limiti di timeout e dimensione di distribuzione delle funzioni serverless, nonché i costi e i limiti di dimensione dei pacchetti Python.

  • 04:35:00 In questa sezione, il Senior Software Engineer di Adobe Nikhil Calro discute le sfide uniche coinvolte nell'apprendimento automatico ad alte prestazioni per flussi di lavoro video e audio. Queste sfide includono i limiti delle risorse, l'intensità dei dati e i requisiti pesanti di calcolo. Per risolvere questi problemi, Adobe utilizza una combinazione di tecnologie e pipeline per accelerare i flussi di lavoro, tra cui il runtime ONNX per potenziare i flussi di lavoro di machine learning in Windows e il provider di esecuzione Direct ML per l'accelerazione GPU sulle piattaforme Windows. Calro osserva inoltre che i flussi di lavoro di apprendimento automatico di Adobe mirano a consentire ai creatori di dedicare più tempo al processo creativo e meno tempo ad attività ridondanti e ripetitive.

  • 04:40:00 In questa sezione, il relatore parla di come le app Creative Cloud di Adobe si rivolgono all'intero ecosistema Windows come un'unica piattaforma e devono fornire funzionalità e parità funzionale tra tutti i principali IHV che supportano Windows come Nvidia, Intel e AMD. Hanno scelto il provider di esecuzione DirectML per consentire l'uso di hardware specifico del fornitore come tensor core sulle GPU Nvidia in quanto lascia l'hardware libero per altri flussi di lavoro di calcolo asincroni. Hanno anche apportato ulteriori ottimizzazioni delle prestazioni costruendo un framework in cima al runtime ONNX e cercando di assemblare le richieste di inferenza in flussi di lavoro in batch per ridurre la contesa di risorse con la GPU e ridurre al minimo il sovraccarico del driver. Forniscono un esempio del flusso di lavoro Scene Edit Detection, che è un flusso di lavoro estremamente dispendioso in termini di risorse, ma sono in grado di eseguire l'intera pipeline end-to-end dalla decodifica all'inferenza in circa 10 secondi o sei volte in tempo reale.

  • 04:45:00 In questa sezione, il relatore discute in che modo le abilitazioni delle prestazioni fornite da ORT e dal provider di esecuzione Direct ML hanno reso possibile l'utilizzo di moderne GPU di fascia alta per abilitare flussi di lavoro basati sull'apprendimento automatico durante il rendering GPU. Hanno in programma di trasferire la loro pipeline in modo che assomigli di più alla pipeline sulla destra, riducendo al minimo i trasferimenti alla CPU e mantenendo quante più cose possibili sulla GPU o sull'hardware indirizzabile dalla GPU. Ciò diventerà ancora più semplice man mano che una parte maggiore del loro calcolo GPU passa a DX12, rimuovendo l'overhead associato a OpenCL e CUDA a DX12 nel loro OP.

  • 04:50:00 In questa sezione, Alexander Zang, uno sviluppatore di software presso Topaz Labs, discute le sfide della distribuzione di modelli di immagine su desktop e laptop. Spiega che la parte critica di questa implementazione è inserirsi in un flusso di lavoro esistente, ottenere le prestazioni previste senza configurazione manuale e fornire modelli di immagine di alta qualità. Alexander spiega che, a differenza della distribuzione del server, la distribuzione del desktop manca di controllo sul sistema, in particolare con GPU diverse di fornitori diversi con diversi livelli di memoria e vincoli di reattività. La sua soluzione a questo è affidarsi a diverse librerie di inferenza per ciascun fornitore di hardware, fornite da ONNX. Questo approccio consente a Topaz Labs di creare un'architettura modello che può essere utilizzata da diverse librerie di inferenza risparmiando sul lavoro manuale.

  • 04:55:00 In questa sezione, il relatore discute le sfide associate alla conversione del modello e la necessità di testare i problemi di compatibilità prima di addestrare un modello. Viene evidenziato il problema dell'ambiguità nelle specifiche del modello, nonché la necessità di testare diverse librerie per prestazioni e coerenza. Il relatore spiega anche i motivi per eseguire più conversioni, affermando che l'utilizzo di un'interfaccia più generica può comportare passaggi di caricamento aggiuntivi e costi di conversione che possono influire sulle prestazioni delle loro app. Infine, viene spiegato il processo di selezione della configurazione appropriata e di gestione della pipeline di inferenza di runtime, evidenziando la necessità di compatibilità e selezione garantendo qualità e velocità costanti dai desktop.



  • 05:00:00 In questa sezione, un relatore di NVIDIA parla del loro approccio alla gestione della compatibilità dei modelli ONNX e al miglioramento della qualità delle immagini nei sistemi desktop suddividendo le immagini in blocchi ed eseguendole tramite inferenza, massimizzando il throughput e potenzialmente eseguendo su più dispositivi e librerie in parallelo. Il relatore affronta anche la difficoltà di garantire che nuove architetture di modello possano essere aggiunte e si comportino bene in tutte le librerie, il che può richiedere molto lavoro e tempo. Passano quindi a discutere di due strumenti, ONNX Craft Surgeon, una libreria python che consente di creare e modificare modelli ONNX, e Polygraphy, un toolkit per il debug di modelli di deep learning. Il relatore spiega come funzionano questi strumenti e come possono essere utilizzati per costruire modelli semplici come costruire grafici tf.

  • 05:05:00 In questa sezione, il relatore introduce gli strumenti ONNX, che includono un'API Python e vari strumenti da riga di comando che offrono molte funzionalità per la manipolazione dei modelli ONNX. Il relatore si concentra sugli strumenti specifici di ONNX, come il modello di ispezione, che mostra una rappresentazione testuale di un modello ONNX, e il subtool sanitized del chirurgo, che semplifica e ripiega le costanti nel modello. L'estratto del chirurgo consente agli utenti di estrarre sottografi da un modello per eseguirne il debug e il modello bisector debug reduce funziona come git bisect ma per i modelli ONNX, consentendo di trovare il modello in errore più piccolo per diagnosticare gli errori nel sistema.

  • 05:10:00 In questa sezione, il relatore discute l'utilizzo dello strumento Calligraphy debug reduce per eseguire il debug di modelli che potrebbero avere problemi di runtime. Riducendo le dimensioni del modello e testando ogni modello intermedio, gli sviluppatori possono identificare le aree problematiche nel codice e semplificare il processo di debug. Il presentatore spiega anche come Qualcomm collabora con la comunità utilizzando ONNX come formato di interscambio che può essere utilizzato su una varietà di dispositivi, dagli auricolari ai laptop ai sistemi automobilistici. Prendendo di mira i modelli che utilizzano ONNX, gli sviluppatori possono creare modelli compatibili con tutti i dispositivi supportati da Qualcomm.

  • 05:15:00 In questa sezione, il relatore parla delle sfide legate alla gestione di varie architetture di dispositivi che richiedono modelli, implementazioni e requisiti temporali differenti. Fornisce un esempio di come lo stesso algoritmo e la stessa tecnologia creati per i sensori di profondità e le telecamere nei telefoni cellulari siano ora utilizzati per campanelli intelligenti sicuri e telecamere di sorveglianza interne ed esterne nelle automobili. Sottolinea quindi l'importanza della scalabilità e confronta le differenze tra gli algoritmi delle macchine di elaborazione su CPU, GPU e acceleratori di intelligenza artificiale utilizzando l'esempio dell'esecuzione del modello Inception V3, dove eseguirlo sugli acceleratori di intelligenza artificiale può fornire fino a mille inferenze al secondo, liberando la CPU per altre attività utili.

  • 05:20:00 In questa sezione, un rappresentante di Qualcomm spiega come hanno integrato gli acceleratori di intelligenza artificiale (AI) nel loro hardware per migliorare le prestazioni e la scalabilità. Utilizzando un acceleratore AI appositamente progettato, possono gestire i carichi di lavoro AI senza il consumo di energia aggiuntivo o velocità inferiori che spesso derivano dall'utilizzo di una CPU o GPU. Inoltre, il loro formato di interscambio ONNX consente loro di compilare ed eseguire modelli di apprendimento automatico su diversi dispositivi e verticali, risparmiando tempo per l'azienda e consentendo una maggiore portabilità. Hanno anche creato uno stack e una libreria software unificati che supportano una varietà di sistemi operativi e nascondono i dettagli dell'hardware per facilitare l'utilizzo dell'hardware da parte dei clienti.

  • 05:25:00 In questa sezione, il relatore introduce lo stack software che Qualcomm ha sviluppato intorno a ONNX. Hanno creato una soluzione completa che include il runtime ONNX, nonché un sistema di delega che si occupa di instradare i modelli alla CPU o alla GPU a seconda del caso d'uso del dispositivo. Il relatore discute i numerosi strumenti che hanno sviluppato, inclusi compilatori, profiler, analizzatori e abilitazione per gli strumenti di ricerca dell'architettura di rete. Il relatore sottolinea la scalabilità e la versatilità di ONNX e il modo in cui può essere utilizzato per vari casi d'uso del dispositivo, inclusi algoritmi per fotocamere, altoparlanti intelligenti e dispositivi XR.

  • 05:30:00 In questa sezione, il relatore spiega il processo di sviluppo del compilatore ANITA, utilizzato per fornire un dialetto di riferimento in Mair per una facile ottimizzazione su diverse architetture e distribuire i modelli su vari ambienti. Il relatore evidenzia anche il framework che hanno introdotto per supportare gli acceleratori personalizzati, che consente loro di scegliere quali operatori caricare e attivare/disattivare facilmente l'acceleratore. Il relatore fornisce anche una panoramica di come l'ottimizzazione viene implementata in ONNX Mlir, dove il modello ONNX viene gradualmente abbassato in una rappresentazione intermedia.

  • 05:35:00 In questa sezione, il relatore parla del compilatore ONNX e di come vengono utilizzati più dialetti per l'ottimizzazione della CPU e dell'acceleratore. L'ottimizzazione di alto livello include l'ottimizzazione a livello di grafico e, a livelli inferiori, l'ottimizzazione viene applicata alle operazioni della CPU e dell'acceleratore. Il relatore presenta un esempio di come funziona un framework di accelerazione nel compilatore, in cui l'utilizzo dell'acceleratore è 11 volte più veloce rispetto all'esecuzione su una CPU. Menzionano anche come si stanno concentrando sull'ottimizzazione degli operatori di deep learning e supporteranno gli operatori di machine learning online e altri acceleratori come la CPU. Infine, esprimono la loro gratitudine ai contributori e invitano altri contributi per continuare a far crescere il progetto ONNX. Il prossimo relatore, di Preferred Networks, introduce PFVM, il loro compilatore di reti neurali che utilizza la rappresentazione intermedia di ONNX.

  • 05:40:00 In questa sezione, un membro del team di Compile discute un caso d'uso per ONNX nell'ottimizzazione dei moduli, in particolare per quanto riguarda la sua rappresentazione intermedia stabile e ben documentata. Il team utilizza ONNX per ottimizzare i modelli con una varietà di percorsi di ottimizzazione estendendo ONNX con gli operatori dei clienti, come l'aggiunta di informazioni sul dispositivo per ottimizzare le modifiche e la memoria del dispositivo. Il relatore discute anche l'importanza dell'inferenza della forma nell'ottimizzazione dei moduli e introduce tre casi di ottimizzazione. Il primo caso comporta la riduzione dell'overhead dell'intervallo del kernel nei grafici computazionali eseguiti su CUDA mediante la fusione di più operatori element-wise in un singolo operatore di gruppo di fusione.

  • 05:45:00 pass conterrebbe molti operatori non necessari se il modello fosse generato da un programma come la ricerca dell'architettura neurale. È qui che tornano utili ottimizzazioni come l'inferenza della forma e la semplificazione del grafico. L'inferenza della forma è fondamentale per determinare se gli operatori adiacenti in base all'elemento possono essere fusi insieme, mentre la semplificazione del grafico può rimuovere gli operatori non necessari dal passaggio all'indietro. Entrambe queste ottimizzazioni possono ridurre significativamente il numero di calcoli necessari e migliorare l'efficienza complessiva del modello.

  • 05:50:00 In questa sezione, il relatore discute la tecnica del checkpoint, che riduce l'utilizzo della memoria durante l'esecuzione di un modulo. Modificando il grafico computazionale, l'utilizzo della memoria può essere ulteriormente ridotto, ma a scapito di una maggiore latenza. Il relatore sottolinea l'importanza di conoscere le dimensioni del tensore per stimare l'utilizzo della memoria e afferma i limiti del checkpoint automatico quando si ha a che fare con dimensioni sconosciute. Inoltre, il relatore discute l'impatto delle dimensioni sconosciute sulle opportunità di ottimizzazione e delinea i miglioramenti che sono stati apportati all'inferenza della forma ONNX. Nello specifico, l'introduzione dell'inferenza simbolica in ONNX 1.10 ha notevolmente migliorato l'inferenza della forma attraverso la propagazione dei dati.

  • 05:55:00 In questa sezione, il relatore discute l'inferenza della forma in ONNX, spiegando che le informazioni sulla forma possono essere propagate globalmente dall'alto per i casi statici, ma è necessario un maggiore supporto per i casi dinamici. Il relatore mostra un esempio di grafico ONNX in cui è necessario stimare la forma di una risagoma, ma al momento non è nota. Suggeriscono di implementare più funzioni di inferenza di forma per casi dinamici e chiedono se sia necessario il supporto per casi come la concatenazione di due tensori di dimensioni diverse. Il relatore menziona anche brevemente le ottimizzazioni per il supercomputer md4, che accetta solo modelli con forma statica e nessuna ramificazione dinamica, e utilizza informazioni statiche per la pianificazione e le ottimizzazioni. Successivamente, un rappresentante di Huawei condivide un discorso preregistrato su come portare la potenza di ONNX su Spark per l'inferenza.

  • 06:00:00 In questa sezione, il focus è sulla proposta di miglioramento SPARK, comunemente nota come SPIP, che mira a semplificare il processo di distribuzione del modello di machine learning a spark, integrandolo con framework DL di terze parti. Questa proposta è rivolta a data engineer o sviluppatori che devono distribuire modelli DL su Spark. L'obiettivo finale è nascondere le complessità della conversione dell'elaborazione delle schede e dell'inizializzazione del modello all'interno di una UDF modale, consentendo agli utenti di completare facilmente l'inferenza ONNX sui big data. Viene introdotto il processore AI di Huawei chiamato Ascend e viene spiegato che per completare la pipeline SPARK e ONNX sulla piattaforma Ascend, è necessario prima introdurre il supporto Ascend nel runtime ONNX.

  • 06:05:00 In questa sezione, il relatore discute l'ecosistema Ascend AI e i diversi processori che supporta. L'Ascend 310 supporta solo l'inferenza AI, mentre l'Ascend 710 e il 910 supportano sia l'addestramento che l'inferenza. Inoltre, l'ecosistema fornisce un livello software chiamato "Kung" che fornisce API agli sviluppatori per creare facilmente applicazioni e servizi di intelligenza artificiale. L'oratore si concentra quindi su Khan, l'attuale stack software nell'ecosistema Ascend e la versione più recente, Khan 5.0. Spiegano i diversi livelli di Khan e come fornisce librerie di operatori, motori di ottimizzazione e un adattatore framework per sviluppatori. Il relatore discute quindi la roadmap per l'aggiunta di Khan come nuovo provider di esecuzione per il runtime ONNX, consentendo agli utenti di eseguire direttamente i modelli ONNX sull'hardware Ascend.

  • 06:10:00 In questa sezione del video, l'ONNX Community Day si conclude con le tavole rotonde per i partecipanti di persona. Le tavole rotonde consistevano in sei diversi argomenti, con grandi taccuini a disposizione dei partecipanti su cui scrivere. Gli argomenti sono stati selezionati in base agli invii dei partecipanti e includono ONNX per dispositivi mobili ed Edge, distribuzione del modello e quantizzazione dell'apprendimento automatico, formazione e operazioni, conversioni e operatori. Anche il team ONNX Runtime era disponibile a partecipare alle conversazioni. Dopo le tavole rotonde, i partecipanti hanno goduto di un happy hour con cibi e bevande e sono stati incoraggiati a compilare il sondaggio per fornire un feedback.
1234567891011...15
Nuovo commento