Изучаем ONNX для применения в трейдинге - страница 4

[MetaQuotes]

ONNX Runtime v1.13 — обзор релиза

ONNX Runtime v1.13 — обзор релиза

Недавно была выпущена версия 1.13 среды выполнения ONNX с исправлениями безопасности, исправлениями ошибок и улучшениями производительности. Обновление направлено на оптимизацию моделей Transformer для квантования графического процессора и добавляет поддержку поставщиков прямого выполнения ML, которые не зависят от устройства и поддерживают более 150 операторов. Кроме того, в выпуск включены обновления мобильной инфраструктуры ORT для совместимости с новыми EPS, такими как пакет XNN. Также обсуждается использование квантования для повышения производительности моделей на основе Transformer с оптимизацией поставщика выполнения CUDA для запуска квантованной модели BERT и использованием обучения с учетом квантования для максимальной точности при оптимизации механизма выполнения ONNX.

• 00:00:00 В этом разделе спикер обсуждает недавно выпущенную версию 1.13 среды выполнения ONNX, которая включает исправления безопасности, исправления ошибок и улучшения производительности. Обновление было сосредоточено на оптимизации моделей Transformer для квантования графического процессора и добавило поддержку поставщиков прямого выполнения ML. Последний представляет собой API машинного обучения, который поддерживает более 150 различных операторов и не зависит от устройства. Спикер также упомянул нового поставщика исполняемых файлов Can EP, который был предоставлен Huawei для поддержки их аппаратного обеспечения Ascend 310. Кроме того, были внесены обновления в мобильную инфраструктуру ORT, что позволило обеспечить совместимость с новыми EPS, такими как пакет XNN.
  
  
• 00:05:00 В этом разделе докладчики обсуждают версию среды выполнения ONNX v1.13 и то, как она работает с любым графическим процессором, поддерживающим DirectX 12, что упрощает оптимизацию для компьютеров с Windows. Они также обсуждают новые операторы и обновления смещений ONNX в версии 1.12. Выступающие подчеркивают, как в новом выпуске расширена поддержка различных архитектур моделей, чтобы упростить использование поставщика исполнения в среде выполнения ONNX. Они также обсуждают новый поставщик выполнения, Excellent Impact, и то, как он заполняет пробелы в производительности на мобильных устройствах, где не доступны написанные от руки ядра. В настоящее время эта функция включена для Android, но команда планирует добавить поддержку iOS и сборок Xamarin или Maui в следующем выпуске. Наконец, они обсуждают новую функцию в выпуске, называемую оптимизацией для квантования модели BERT.
  
  
• 00:10:00 В этом разделе спикер обсуждает использование квантования для повышения производительности моделей на основе Transformer, таких как BERT. Они объясняют, как они оптимизировали поставщика выполнения CUDA для запуска квантованной модели BERT и использования квантованного обучения с учетом максимальной точности при оптимизации механизма выполнения ONNX. Докладчик приводит примеры того, как проводить обучение модели BERT с квантованием и экспортировать модель с помощью инструментов, доступных в среде выполнения ONNX, для дальнейшей оптимизации. Благодаря лучшей поддержке квантованного осознанного обучения среда выполнения ONNX может обеспечить дальнейшую оптимизацию производительности при сохранении максимальной точности. Они упоминают, что после того, как пользователь выполнит примеры для экспорта модели, автономные инструменты, доступные в новой версии среды выполнения ONNX, могут оптимизировать модель для повышения скорости.

[MetaQuotes]

Что такое ONNX Runtime (ORT)?

Что такое ONNX Runtime (ORT)?

ONNX Runtime (ORT) — это библиотека, которая оптимизирует и ускоряет вывод машинного обучения, позволяя пользователям обучать свои модели в любой поддерживаемой библиотеке машинного обучения, экспортировать в формат ONNX и выполнять вывод на предпочитаемом языке. Докладчик приводит пример выполнения логических выводов с использованием PyTorch с ONNX Runtime и указывает, что пользователи могут посетить ONNXRuntime.ai, чтобы изучить различные API и инструменты, необходимые для предпочтительной настройки.

[MetaQuotes]

Обсуждение дорожной карты ONNX на 2020 год №1 20200903

Обсуждение дорожной карты ONNX на 2020 год №1 20200903

Документ дорожной карты ONNX, который был открыт для общественности, является ключевой темой этого видео. Обсуждение охватывает расширение ONNX на конвейере машинного обучения, включая развитие данных, предварительную обработку и расширение ONNX на горизонтальные конвейеры, такие как QFLO. Предложения участников включают поддержку фреймов данных и внедрение новых операторов для предварительной обработки. Выступающие также обсудили принятие стандарта API данных Python для расширения поддержки ONNX и гарантии взаимодействия с другими библиотеками. Кроме того, спикеры обсуждают интеграцию ONNX в Kubernetes и Kubeflow, чтобы упростить разработку машинного обучения для пользователей. Группа планирует продолжить оценку влияния предложения и приветствует отзывы через дорожную карту или руководящий комитет.

• 00:00:00 В этом разделе спикер обсуждает документ дорожной карты ONNX, который был открыт для предложений общественности, и подчеркивает важность этих вкладов для реализации изменений. Спикер упоминает, что еженедельно будет проходить шесть обсуждений дорожной карты, а собрание сообщества запланировано на 14 октября. Обсуждение разделено на три основные части, а вторая часть посвящена расширению ONNX в конвейере машинного обучения. В частности, обсуждение охватывает развитие данных и их предварительную обработку, а также расширение ONNX на горизонтальные конвейеры, такие как QFLO. Докладчик также резюмирует некоторые предложения участников, такие как поддержка фреймов данных и внедрение новых операторов для предварительной обработки.
  
  
• 00:05:00 В этом разделе обсуждение сосредоточено на дорожной карте ONNX и различных предложениях, таких как поддержка обработки аудиоспектрограмм и расширение поддержки макета данных. Обсуждение также касается предлагаемого расширения влияния ONNX на конвейер машинного обучения и потенциальных преимуществ поддержки фреймов данных в ONNX. Участники высказывают свое мнение, а один из них поделился своим мнением об усилиях Консорциума API данных Python по созданию стандарта API данных для взаимодействия массивов и фреймов данных. Группа, похоже, согласна с тем, что расширение возможностей ONNX в этих областях — это хорошо и согласуется с более широкими отраслевыми инициативами.
  
  
• 00:10:00 В этом разделе спикеры обсуждают принятие стандарта API данных Python как способ расширить поддержку ONNX и гарантировать совместимость со всеми другими библиотеками того же стандарта. Спикер говорит, что принятие стандарта облегчит обмен моделями, а согласование графика с более крупным консорциумом позволит пользователям использовать ONNX. Они также обсуждают разницу между ONNX и традиционной структурой данных, такой как фрейм данных, и необходимость принятия того же стандарта другими библиотеками.
  
  
• 00:15:00 может интегрировать ONNX в конвейер Kuflow, чтобы упростить разработку машинного обучения для конечных пользователей. Чен упоминает концепцию конвейера, в котором все компоненты работают вместе, чтобы организовать сквозную разработку машинного обучения. Kuflow сочетает в себе модели и содержимое данных с инфраструктурой, чтобы обеспечить бесперебойную работу для конечных пользователей. Чен изучает, как можно интегрировать ONNX в этот конвейер, чтобы расширить его использование и упростить работу разработчиков машинного обучения.
  
  
• 00:20:00 В этом разделе докладчики обсуждают идею упрощения использования ONNX для своей инфраструктуры и сред пользователям, использующим Kubernetes и Kubeflow. Цель состоит в том, чтобы разработать простой в использовании API для извлечения моделей из зоопарка моделей и создания сквозного конвейера с использованием ONNX. Выступающие демонстрируют пример, в котором они используют ONNX для описания части логического вывода процесса машинного обучения в Kubeflow, и излагают идеи для разработки компонентов ONNX, чтобы охватить больше шагов, включая обработку данных и распределенное обучение. Идея состоит в том, чтобы использовать возможности Kubernetes, а также охватить больше шагов в процессе машинного обучения.
  
  
• 00:25:00 В этом разделе докладчики обсуждают расширение QFlow, чтобы иметь задание ONNX для обеспечения распределенного обучения, а также добавление обработки и преобразования данных для перехода к части обучения модели. Сама среда выполнения ONNX уже сегодня поддерживает обучающие модели преобразователей из PyTorch, но еще предстоит добиться прогресса в обучении моделей ONNX. Выступающие предлагают начать с моделей в зоопарке моделей, чтобы увидеть, как данные должны быть предварительно обработаны и преобразованы для моделей, но обратите внимание, что это не относится исключительно к основному проекту ONNX и требует структуры более высокого уровня для определения компонентов. как CoolFlow.
  
  
• 00:30:00 В этом разделе участники обсуждают предложение, сделанное для дорожной карты ONNX, и предлагают связать слайды с документом. Группа планирует продолжить оценку воздействия предложения на последующих встречах и надеется получить больше информации о реализации. Они также приветствуют отзывы и поощряют пользователей отправлять их через дорожную карту или руководящий комитет. Обсуждение завершается прощанием и приглашением на будущие встречи.

[MetaQuotes]

Обсуждение дорожной карты ONNX на 2020 год № 2 20200909

/p>

Обсуждение дорожной карты ONNX на 2020 год № 2 20200909

В видео «Обсуждение дорожной карты ONNX» докладчики обсуждают различные темы, связанные с дорожной картой ONNX, включая определение формы, определения операторов, эталонные реализации и спецификацию ONNX. Выступающие предлагают создать общую инфраструктуру вывода формы для улучшения оптимизации вывода формы, сокращения количества примитивных операторов, добавления эталонных реализаций для каждого оператора и более определенных тестовых случаев для обеспечения правильной реализации и тестирования ONNX. Группа планирует продолжить обсуждения в SIG оператора и на доске обсуждений GitHub для добавления нового оператора.

• 00:00:00 В этом разделе спикеры обсуждают дорожную карту ONNX и затрагивают несколько предложенных тем, в частности вывод формы, вне определения и IR, все из которых ранее упоминались в документе дорожной карты, с комментариями от разных людей. Выступающие спрашивают, готовы ли Чанминг или Бьюкен объяснить свои предложения. Бьюкен обсуждает свои отзывы о вмешательстве формы и о том, как у него были проблемы с этим в прошлом. Он предлагает создать общую инфраструктуру влияния формы, которая перекомпилирует форму всякий раз, когда происходит изменение IR, чтобы гарантировать, что оптимизация вывода формы идет рука об руку и одновременно улучшает оптимизацию. Выступающие пришли к выводу, что это больше относится к оптимизации, чем непосредственно к выводу о форме.
  
  
• 00:05:00 понять текущие возможности ONNX с точки зрения вывода формы и проходов оптимизации. Существующая инфраструктура уже поддерживает вывод формы на основе известных входных значений и может использоваться для вывода выходных форм. Обновление средства проверки модели может быть легким, но другие изменения могут потребовать дополнительного обсуждения. Группа обсуждает, относятся ли эти изменения к ONNX или к другому месту. Они также рассматривают идею вызова методов вывода формы для каждого оператора в последовательных циклах для достижения желаемых результатов. В конечном счете, существующая инфраструктура уже позволяет проводить оптимизацию и делать выводы о форме, но изменения и улучшения могут расширить эти возможности.
  
  
• 00:10:00 В этом разделе докладчики обсуждают определения операторов и предлагают сократить количество примитивных операторов, поскольку другие операторы можно сделать составными с операторами более низкого уровня. Они также обсуждают тему эталонной реализации и необходимость инфраструктуры для оценки последовательности операторов. Текущая эталонная реализация существует в виде реализации Python в генераторе тестовых случаев, но она не организована таким образом, чтобы упростить оценку последовательности операторов. Выступающие предлагают добавить в ЭК некоторую среду выполнения, например среду выполнения ONNX, для проверки подграфов функций, которые можно использовать для проверки.
  
  
• 00:15:00 В этом разделе спикеры обсуждают необходимость эталонных реализаций для каждого оператора, чтобы время выполнения не отличалось от ожиданий автора. Они предлагают использовать эталонную реализацию в качестве модульного теста для проверки четности со средой выполнения, а также в качестве режима интерпретатора для проверки совместимости и проверки. Выступающие отмечают, что использование среды выполнения ONNX для проверки функции возможно при условии, что функция состоит из примитивных операций, существующих в ONNX. Однако использование среды выполнения ONNX для новых операторов в подграфе, включающем новые примитивные операции, невозможно, поскольку ни одна другая среда выполнения не имеет такой реализации. Они признают, что создание эталонной реализации требует много работы, но обязательно для каждой операции. Они также подчеркивают необходимость соответствия ONNX, чтобы гарантировать, что время выполнения не отклоняется от ожиданий автора.
  
  
• 00:20:00 В этом разделе докладчики обсуждают использование эталонных реализаций в спецификации ONNX и важность четкого и лаконичного языка в спецификации. В то время как некоторые выступают за использование эталонных реализаций для устранения двусмысленности в английском тексте спецификации, другие утверждают, что спецификация должна быть достаточно ясной, чтобы эталонные реализации не были нужны. Выступающие также обсудили важность тщательного тестирования на соответствие, чтобы убедиться, что проверены все возможные крайние случаи. В конечном счете, консенсус, похоже, заключается в том, что, хотя эталонные реализации могут быть полезны, они не должны требоваться в спецификации ONNX.
  
  
• 00:25:00 В этом разделе обсуждаются требования к реализации оператора в ONNX, в частности, необходимость эталонной реализации и процедур тестирования. В то время как некоторые утверждают, что эталонная реализация оператора должна быть обязательной для создания тестовых данных, другие не согласны, заявляя, что достаточно предоставить либо функцию Python для генерации тестовых данных, либо фиксированный набор данных. Однако следует отметить, что эталонная реализация имеет решающее значение для того, кто реализует оператор в среде выполнения, чтобы должным образом протестировать свою реализацию, особенно для сложных операторов с множеством различных атрибутов. В обсуждении также поясняется, что, хотя эталонная среда выполнения для ONNX не требуется, требуется эталонная реализация для каждого оператора.
  
  
• 00:30:00 В этом разделе видео спикеры обсудили важность наличия эталонной реализации и более четко определенных тестовых случаев для обеспечения правильной реализации и тестирования ONNX. Они отметили, что полагаться на сгенерированные тестовые данные может быть недостаточно и что наличие простого кода решает проблему для всех. Разговор также затронул необходимость полной спецификации и свободу среды выполнения определять, что делать в случаях неопределенного поведения. Некоторые ораторы выразили озабоченность по поводу добавления бремени для тех, кто предлагает операторов, путем добавления эталонной реализации. Они предложили свести к минимуму инженерные усилия и пересмотреть текущие требования по добавлению операций в систему.
  
  
• 00:35:00 В этом разделе видео спикеры обсуждают важность наличия полной и однозначной спецификации для ONNX и способы ее обеспечения. Они согласны с тем, что эталонная реализация на Python была бы полезна, чтобы гарантировать, что люди, реализующие операторы в средах выполнения, смогут проверить все тестовые примеры. Тем не менее, они также признают, что реализовать спецификацию непросто, и есть еще проблемы, которые необходимо решить. Они обсуждают способы прояснить, как можно использовать спецификацию, и предлагают, чтобы практика и обратная связь определяли предложения новых операторов, а не предлагали оператор, а затем реализовывали его в среде выполнения. Они также отмечают, что одним из требований для добавления новой операции является то, что она должна быть реализована в хорошо известной среде.
  
  
• 00:40:00 В этом разделе обсуждения дорожной карты ONNX группа обсуждает процесс добавления новых операторов в спецификацию ONNX. Предлагается изменить политику добавления нового оператора, который уже требует эталонной реализации на Python. Их обсуждение сосредоточено на эталонных реализациях и тестах на соответствие, и они планируют продолжить разговор в SIG оператора и на доске обсуждений GitHub. Группа планирует продолжить обсуждение на следующей встрече, запланированной на следующую неделю.

[MetaQuotes]

Обсуждение дорожной карты ONNX на 2020 год № 3 20200916

Обсуждение дорожной карты ONNX на 2020 год № 3 20200916

В этом видео обсуждаются различные темы, связанные с ONNX, включая улучшение обработки ошибок, добавление предопределенного поля схемы метаданных для обозначения создания модели, необходимость физической оптимизации квантования и возможность обновления моделей ONNX из Model Zoo в самые последние версии. Команда планирует расставить приоритеты по этим темам в зависимости от их влияния и стоимости и работать над ними после выпуска 1.8. Кроме того, группа рассматривает идею создания различных языковых привязок для набора инструментов ONNX с особым интересом к Java для поддержки различных платформ, таких как Spark. Спикеры также обсудили возможность создания Java-оболочки вокруг ONNX Runtime.

• 00:00:00 В этом разделе спикер предлагает обсудить с сообществом три темы: обработка ошибок, расширение модельного зоопарка и реализация дополнительных операций или операторов для квантования. Они планируют использовать следующие три сессии, чтобы обсудить стоимость и влияние этих тем, а также определить приоритеты на основе элементов с наибольшим влиянием и низкой стоимостью. Они также отвечают на вопрос о влиянии этих тем на версию 1.8 и поясняют, что большинство этих изменений будут внесены после версии 1.8. Один член сообщества предлагает улучшить обработку ошибок, чтобы, если среда выполнения встречала некорректно сформированные protobuf, она не завершалась, а вместо этого возвращала код ошибки или выдавала исключение, чтобы обеспечить лучшее взаимодействие с пользователем.
  
  
• 00:05:00 В этом разделе обсуждение сосредоточено на улучшении обработки ошибок кода загрузки в ONNX, чтобы предотвратить сбои и улучшить функциональность. Команда провела фаззинг кода и обнаружила, что ненадежные модели могут нарушить весь процесс, что делает его первоочередной задачей. Процесс проверки среды выполнения ONNX отличается от процесса проверки ONNX, и пока неясно, могут ли они использовать одну и ту же программу проверки. Кроме того, поднимается вопрос об улучшении обработки ошибок во время аудитов, и команда планирует реализовать это предложение.
  
  
• 00:10:00 В этом разделе спикер обсуждает свою библиотеку под названием Trivial, которая взаимодействует с экосистемой ONNX и обслуживает модели ONNX. Они предлагают добавить предопределенное поле схемы метаданных в ONNX для обозначения временной метки, когда модель была создана, алгоритма обучения, используемого для модели, и исходной библиотеки, которая использовалась для ее создания. Они предлагают определить стандартные имена ключей для поля метаданных и также ввести их. Докладчик считает, что наличие схемы для поля метаданных было бы полезно для библиотек и других пользователей, обслуживающих модели ONNX. Затем разговор переходит к необходимости расширить тестирование моделей, чтобы охватить все модели в Model Zoo и предоставить хорошие примеры высокого качества.
  
  
• 00:15:00 В этом разделе обсуждение сосредоточено вокруг необходимости физической оптимизации квантования, а также расширения модельного зоопарка ONNX для включения квантованных моделей. Было несколько запросов на включение квантованных моделей в модельный зоопарк, и команда надеется найти участников. Они упоминают блог, в котором хорошо зарекомендовала себя квантованная модель ONNX от Hugging Face, но им потребуется разрешение от Hugging Face, чтобы опубликовать ее. Также было высказано предположение, что топ-модель библиотеки трансформаторов может быть примером для квантования, и над ней работают Microsoft и Space. Кроме того, обсуждалась оптимизация, и некоторые согласились с тем, что оптимизацию лучше оставить на время выполнения, поскольку она выходит за рамки спецификации ONNX.
  
  
• 00:20:00 В этой секции участники обсуждают возможность обновления моделей ONNX из Model Zoo до самых последних версий с помощью инструмента Version Converter. Однако они отмечают, что конвертер версий не полностью обновлен, и есть некоторая неопределенность в отношении необходимости преобразования, поскольку ONNX поддерживает все предыдущие версии. Группа также рассматривает идею различных языковых привязок для набора инструментов ONNX с особым интересом к Java для поддержки различных платформ, таких как Spark. Добавление Java API или привязок облегчило бы загрузку и проверку файлов модели и создание конвертера из других библиотек в формат ONNX.
  
  
• 00:25:00 В этом разделе докладчики обсуждают возможность создания Java-оболочки вокруг среды выполнения ONNX, которая упростит работу с проектами машинного обучения на основе JVM, такими как Spark. Хотя это нетривиальная задача, использование предустановок Java CPP для автоматического создания заглушек может стать хорошей отправной точкой. Обратная совместимость имеет решающее значение для таких крупных проектов, как Spark, а переход на Java 8 потребует значительной работы. Однако, если у сообщества есть достаточный интерес и желание внести свой вклад, это может быть полезно изучить.

[MetaQuotes]

Обсуждение дорожной карты ONNX на 2020 год № 4 20200923

Обсуждение дорожной карты ONNX на 2020 год № 4 20200923

Четвертая часть обсуждения дорожной карты ONNX охватывает темы поддержки фреймов данных, предварительной обработки, стандартизации, сквозного конвейера машинного обучения и рекомендаций по инструментам. Поддержка фреймов данных оценивается как полезная для классических моделей машинного обучения и может устранить необходимость в предварительной обработке. Подчеркнута необходимость включения предварительной обработки в модель ONNX для повышения производительности с упором на стандартизацию высокоуровневых категорий, таких как обработка изображений. Сквозной конвейер оценивается как низкоприоритетный, но предлагается постепенное добавление компонентов в конвейер. Обсуждение завершается рекомендацией использовать инструмент для дальнейшего обсуждения и анализа пунктов повестки дня.

• 00:00:00 В этом разделе спикеры обсуждают дорожную карту ONNX и функции, предложенные сообществом. На данный момент они рассмотрели три раздела, включая конвейер машинного обучения и обработку данных, определение операций или IRS и базовую робототехнику. Документ дорожной карты включает в себя таблицу предлагаемых функций с высоким, средним и низким приоритетом. Однако некоторые темы носят слишком общий характер, что затрудняет оценку их важности. Спикеры планируют провести следующие 30 минут, обсуждая, почему некоторые из этих функций получили высокие оценки, и собирая отзывы сообщества о том, какие функции наиболее важны.
  
  
• 00:05:00 мне было интересно, как расставляется приоритеты в дорожной карте ONNX, в этом разделе видео обсуждается важность функции поддержки фреймов данных и то, как она потенциально может решить другие проблемы на платформе. Спикер объясняет, что эта функция будет полезна для специалистов по данным и потенциально может свести на нет необходимость в функции предварительной обработки. Они также упоминают о необходимости получить смету инженерных затрат для каждого элемента дорожной карты, чтобы эффективно расставлять приоритеты задач. Предложения приветствуются, так как дорожная карта впервые представляется таким образом.
  
  
• 00:10:00 В этом разделе обсуждения дорожной карты ONNX обсуждается важность поддержки фреймов данных для моделей машинного обучения. Считается, что поддержка фреймов данных предназначена в основном для классических моделей машинного обучения, а не для DNN или других моделей. Фрейм данных отличается от последовательности тем, что представляет собой разнородный набор тензоров или реляционную таблицу со столбцами, которые могут иметь разные типы. Важность каждой функции оценивается на основе влияния, которое она будет иметь, и будут учитываться затраты на проектирование. Предлагается предоставить комментарий к каждому блоку, чтобы указать, почему функция является высокой или низкой по важности.
  
  
• 00:15:00 В этом разделе обсуждается важность предварительной обработки в модели ONNX. В ходе обсуждения подчеркивается необходимость учета всех необходимых шагов в модели ONNX, а не использования внешних библиотек, особенно в контексте обучения, когда предварительная обработка может оказать значительное влияние на производительность. Кроме того, предварительная обработка может быть полезна для логического вывода, особенно если не в среде на основе Python. Обсуждение также затрагивает проблемы стандартизации предварительной обработки из-за неоднородного характера типов данных. Хотя предварительная обработка — обширная и сложная тема, в ходе обсуждения делается вывод о том, что необходимо учитывать отсутствующие операторы и типы в ONNX для стандартизации предварительной обработки.
  
  
• 00:20:00 В этом разделе докладчики обсуждают широкий спектр предварительной обработки и то, как она может включать не только обработку, связанную со зрением, но и аудиоданные. Хотя важно учитывать предварительную обработку, докладчики отмечают, что может не быть необходимости поддерживать все типы данных, и вместо этого стандартизация высокоуровневых категорий, таких как обработка изображений, может быть более выгодной для разработчиков. Тем не менее, выступающие предупреждают, что даже, казалось бы, простые задачи предварительной обработки, такие как изменение размера изображения, могут иметь небольшие различия в крайних случаях между библиотеками, что делает стандартизацию сложной инженерной задачей. Тем не менее, стандартизация задач предварительной обработки может быть полезной, и докладчики предлагают собрать общие шаги предварительной обработки для дальнейшего рассмотрения.
  
  
• 00:25:00 В этом разделе докладчики обсуждают приоритет включения сквозного конвейера машинного обучения в ONNX, при этом некоторые заявляют, что это низкий приоритет, учитывая другие вопросы, которые необходимо решить. Тем не менее, они признают полезность наличия сквозного примера и иллюстрации того, как можно применять ONNX, особенно когда в микс включена среда выполнения ONNX. Предлагается идея постепенного добавления компонентов в конвейер с упором на обучающую часть, тонкую настройку ONNX и, в конечном итоге, добавление в смесь предварительной обработки. Обсуждение заканчивается рекомендацией использовать инструмент для облегчения дальнейшего обсуждения и анализа влияния пунктов повестки дня.
  
  
• 00:30:00 В этом разделе спикер благодарит всех за участие и сообщает аудитории, что они постараются опубликовать обсуждение в социальных сетях и на сайте ONNX.

[MetaQuotes]

Обсуждение дорожной карты ONNX на 2020 год № 5 20201001

Обсуждение дорожной карты ONNX на 2020 год № 5 20201001

Во время обсуждения дорожной карты ONNX команда ONNX обсудила различные функции, которые были предложены членами сообщества и оценены разными людьми, включая руководящий комитет. В то время как некоторые функции были согласованы единогласно, другие разделили сообщество. Команда обсудила возможность замены ONNX IR на несколько IR и централизованные библиотеки оптимизации IR. Они также обсудили идею централизации библиотек оптимизации внутри ONNX и требование к операторам реализовать стандартный интерфейс и стиль кодирования. Команда также обсудила возможность использования простой среды выполнения для моделей ONNX и использования пользовательских операций Python для случаев, когда среда выполнения ONNX недоступна. Кроме того, команда исследовала взаимосвязь между операциями предварительной обработки и использованием фреймов данных, планируя превратить свои идеи в действенные предложения для будущей работы.

• 00:00:00 В этом разделе команда ONNX обсуждает электронную таблицу анализа воздействия, которая была создана для сбора мыслей разных людей о том, что важно для проекта. Они перечислили все различные функции, которые были предложены, и получили оценки от разных людей, включая руководящий комитет и других членов сообщества. Они заметили, что есть некоторые функции, по которым все, кажется, согласны с тем, что они либо действительно важны, либо вообще не важны, а другие — по которым сообщество разделилось. Они обсудили те, которые были разделены, и следующие шаги для тех, которые, по их мнению, были важны. Они также говорили о настройке критериев для того, что считается высокоприоритетным, и о том, как это зависит от того, кто готов посвятить время реализации функции.
  
  
• 00:05:00 В этом разделе обсуждения дорожной карты ONNX участники обсуждают идею замены ONNX IR на несколько IR и централизованные библиотеки оптимизации IR. Ведутся споры о том, следует ли объединять эти две идеи, поскольку оптимизация и IR — это разные вопросы. Целью наличия нескольких IR является упрощение и объединение более простых операций, в то время как библиотеки оптимизации улучшат ядро ONNX. Продолжается обсуждение того, что подразумевается под ONNX IR, и необходимы разъяснения. Участники также обсуждают, как эти потенциальные изменения могут повлиять на их текущие оценки в дорожной карте ONNX.
  
  
• 00:10:00 В этом разделе команда обсуждает возможность централизации библиотек оптимизации в ONNX, но в конечном итоге соглашается с тем, что оптимизация должна быть частью среды выполнения и что она имеет более низкий приоритет по сравнению с другими вопросами. Они также обсуждают требования к реализации операций определенным образом, со стандартным интерфейсом и стилем кодирования, что уже является требованием, но может потребовать доработки. Они предполагают, что если кто-то предлагает определенный стиль, его можно принять, если он кажется приемлемым.
  
  
• 00:15:00 В этом разделе докладчики обсуждают идею простой среды выполнения для моделей ONNX, что вызывает опасения по поводу сложности необходимости выполнения потока и внутреннего IR для обработки модели. Тем не менее, возможность запускать и оценивать модели ONNX для тестирования и установления правильности имеет смысл, особенно при выявлении любых пробелов в модульных тестах для операторов. Хотя можно спорить о том, сколько усилий и затрат потребуется для реализации простой среды выполнения, среда выполнения ONNX имеет возможность подключать операции Python, которые можно использовать для этой цели.
  
  
• 00:20:00 В этом разделе участники обсуждения дорожной карты ONNX рассказали о возможности использования кастомной оп Python для конкретных случаев, когда среда выполнения ONNX недоступна . Они обсудили ограничения операции Python и необходимость стандартного интерфейса для обеспечения выполнимости. Кроме того, группа обсудила потребность в дополнительных возможностях предварительной обработки внутри графа ONNX, чтобы сделать модели более автономными и переносимыми, особенно для предварительной обработки на основе изображений, такой как масштабирование и обработка ограничивающих прямоугольников. Группа отметила, что предварительная обработка текста, в частности токенизация, является более сложной и всеобъемлющей проблемой, но они могут абстрагироваться от некоторых распространенных сценариев предварительной обработки.
  
  
• 00:25:00 В этом разделе участники обсуждают взаимосвязь между операциями предварительной обработки и использованием фреймов данных. Хотя они согласны с тем, что предварительная обработка и фреймы данных связаны, они рассматривают их как отдельные объекты, требующие разных типов работы. Предварительная обработка рассматривается как оператор, который работает по строкам в столбце фрейма данных, в то время как само извлечение фрейма данных отображает оператор предварительной обработки в строках столбца. Группа считает, что они тесно связаны, и планирует превратить свои идеи в действенные предложения для будущей работы.

[MetaQuotes]

Обсуждение дорожной карты ONNX на 2021 год №1 20210908

Обсуждение дорожной карты ONNX на 2021 год №1 20210908

Во время обсуждения дорожной карты ONNX компания IBM Research представила свое предложение по новой платформе конвейера машинного обучения, которая преобразует типичные шаблоны предварительной обработки данных в Pandas Dataframe в формат ONNX. Платформа под названием Data Frame Pipeline имеет открытый исходный код на GitHub и может быть определена с помощью предоставленного API, который запускается на Python на этапе обучения. Выступавшие также обсудили необходимость сделать ONNX видимым на языках, отличных от Python, таких как Java, C# и C++, а также экспортировать модели ONNX и создавать их из других языков. Кроме того, они обсудили текущие функции преобразователей ONNX Python и C++, а также необходимость функций определения области, именования и исправления при написании моделей ONNX.

• 00:00:00 В этом разделе Такуя из IBM Research представляет свое предложение по новой платформе конвейера машинного обучения с новыми операторами ONNX. Мотивация для предложения была связана с неспособностью существующих структур конвейера представить типичный шаблон предварительной обработки данных. Они создали прототип новой конвейерной инфраструктуры под названием Data Frame Pipeline на Python, которая преобразует типичные шаблоны предварительной обработки данных в Pandas Dataframe в формат ONNX. Они защитили три новых оператора ONNX, в том числе оператор даты и два простых оператора, конкатенаторы строк и разделители строк. Платформа конвейера имеет открытый исходный код на GitHub и может быть определена с помощью предоставленного API, который запускается на Python на этапе обучения. Модель обучается с использованием данных, выводимых из конвейера фреймов данных, и их инфраструктура может использовать уже преобразованные модели машинного обучения ONNX.
  
  
• 00:05:00 В этом разделе спикер обсуждает формат ONNX и то, как его можно использовать со средой выполнения ONNX, предоставленной Microsoft. Они упоминают, что в своем прототипе они реализовали 11 преобразователей фреймов данных в Python и сопоставили их с операторами ONNX, причем большинство из них были простыми сопоставлениями, но некоторые требовали анализа и преобразования, например, функциональный преобразователь. Они также обсуждают свой подход к созданию операторов ONNX со свойствами заряженного тела, а не к выполнению операторов агрегации в ONNX. Спикер делится предварительными экспериментальными результатами, которые показывают значительное ускорение при обучении предварительной обработке на ONNX, с 300-кратным улучшением производительности для категориального кодирования. Они также сравнивают точность предсказания и упоминают свое предложение, открывая слово для вопросов и комментариев по представленным операторам.
  
  
• 00:10:00 В этом разделе Адам Погба из Oracle Labs предлагает сделать ONNX видимым на языках, отличных от Python, поскольку вся текущая функциональность реализована в Python, и неясно, является ли C++ допустимой целью для привязки. Погба объясняет, что средство проверки модели должно быть видно на других языках, чтобы пользователи могли взаимодействовать с ним, не нуждаясь в действительной среде Python. Кроме того, Погба упоминает, что среда выполнения ONNX иногда дает сбои при использовании моделей из-за проблем с синтаксическим анализом, и средство проверки моделей можно использовать для проверки и легкого устранения этой проблемы.
  
  
• 00:15:00 В этом разделе спикер обсуждает основные функции проверки моделей и то, как было бы полезно представить их на других языках. Хотя они хотели бы иметь его на Java, они понимают, что не каждый будет писать Java API, поэтому C API является лучшим вариантом для большинства языков, к которому можно легко привязаться. Однако должна быть стабильная и подходящая цель для привязки людей, и не сразу ясно, считается ли C++ API любого из этих инструментов подходящей целью для привязки. Спикер готов участвовать в этих усилиях, но не стоит пытаться стимулировать большие усилия, если сообщество не заинтересовано.
  
  
• 00:20:00 В этом разделе докладчик обсуждает экспорт моделей ONNX и их передачу из других языков, помимо Python, таких как C# и Java, уделяя особое внимание ML.NET и Trivial Library. Спикер настаивает на необходимости общего API, который все проекты могли бы использовать для создания моделей ONNX, особенно с учетом существующих в настоящее время трех различных реализаций без общего кода, которые подвержены ошибкам. Общий API обеспечит только одно место для обновления и проверки узлов и графиков, предоставляя возможность поделиться своими возможностями и упростив другим библиотекам машинного обучения создание моделей ONNX. Спикер признает, что, хотя это может быть много работы, совместные усилия могут расширить экосистему ONNX за пределы Python.
  
  
• 00:25:00 В этом разделе спикеры обсуждают преобразователи ONNX Python и C++ и их текущие функции. Они отмечают, что документация ONNX недостаточно конкретна, что затрудняет понимание некоторых функций. Однако они утверждают, что многие функции, необходимые для экспорта ONNX, уже существуют в этих конвертерах, но их необходимо правильно представить другим проектам. Кроме того, они обсуждают необходимость в функциях области видимости, именования и исправления при написании моделей ONNX. Наконец, они предполагают, что конвертеры могут выиграть от привязки к архитектурной инфраструктуре, чтобы их могли легко использовать разные люди.

[MetaQuotes]

Обсуждение дорожной карты ONNX на 2021 год № 2 20210917

Обсуждение дорожной карты ONNX на 2021 год № 2 20210917

В обсуждении дорожной карты ONNX № 2 20210917 различные докладчики обсудили несколько ключевых областей, в которых ONNX нуждается в улучшении, включая удобство квантования и слияния, оптимизацию ядер для конкретных аппаратных платформ и добавление локальных функций модели в ONNX. Другие темы включали отзывы о сквозной поддержке конвейера, проблемы, с которыми сталкиваются клиенты на разных платформах, и проблемы с преобразованием графов GRU и LSTM. Некоторые предлагаемые решения включали предоставление серверной части дополнительной информации для выполнения предварительно квантованных графов, улучшение функциональной совместимости различных платформ и включение пространства имен, связанного с исходным графом, чтобы обеспечить как общее, так и оптимизированное решение. Кроме того, докладчики обсудили необходимость более эффективного развертывания пакетов для более широкого внедрения и возможность разработки дополнительных преобразователей для поддержки мультимодальных моделей.

• 00:00:00 В этом разделе Мартин из Green Waves Technologies обсуждает две области, в которых ONNX нуждается в улучшении, квантование и удобство слияния. Что касается квантования, Мартин предлагает предоставить больше информации для серверных частей для выполнения предварительно квантованных графов, поскольку ONNX не может следовать всем различным способам, которыми клиенты хотят реализовать специализированные вещи. Чтобы помочь в этом, Мартин предлагает добавить информацию о минимальном максимуме, стандартном отклонении и среднем значении к тензорам с дополнительной информацией, такой как статистика выбросов, информация о канале для каждого канала и информация о распределении в качестве возможных надстроек. Для удобства слияния Мартин предлагает улучшить совместимость различных платформ, предоставив улучшенные функции импорта/экспорта, что упростит для ONNX определение правильных конвертеров для использования при импорте/экспорте различных графиков.
  
  
• 00:05:00 В этом разделе спикер обсуждает текущее использование функций для составных операторов и сложность оптимизации ядер под конкретные аппаратные платформы, когда операторы разбиты. Предлагается идея сгруппировать экспортированные функции в контейнер более высокого уровня, возможно, функцию, и сопоставить этот контейнер с оптимизированным ядром на конкретном бэкэнде. Спиер также предлагает включить пространство имен, связанное с исходным графом, что позволяет использовать как общее, так и оптимизированное решение. Также упоминается добавление возможности импортировать локальные функции модели в последней версии ONNX.
  
  
• 00:10:00 В этом разделе докладчики обсуждают добавление локальных функций модели в ONNX, что позволяет операторам преобразователя включать тело функции в прототип модуля в качестве заполнителя для операторов, не определенных в стандарте ONNX. Тем не менее, докладчики также отмечают, что конвертерам лучше всего маркировать и комментировать то, что они экспортируют, в машиночитаемом виде. Они также касаются того, как оптимизация может повлиять на соглашения об именах, и предлагают продолжить обсуждение темы либо в канале Slack, либо на дополнительной встрече. Представлена следующая презентация, посвященная профилированию ONNX.
  
  
• 00:15:00 В этом разделе обсуждается отзыв о сквозной поддержке конвейера, при этом ONNX рассматривается как отличный вариант для упрощенного развертывания в различных операционных системах, не предъявляющих высоких требований к экосистеме. Выступающие выражают надежду на то, что операторы ONNX как в ONNX, так и в ONNX ML смогут выполнять не только модели, но и этапы подготовки данных, в том числе охватывать другие типы операций по производству данных. Они утверждают, что упрощенный или распространенный артефакт или модель развертывания могут повысить ценность, а также возможность сэкономить усилия и обеспечить согласованность за счет сосредоточения внимания на простых плодах по сравнению со стандартными преобразованиями.
  
  
• 00:20:00 В этом разделе спикер обсуждает некоторые проблемы, с которыми сталкиваются клиенты на разных платформах, и отмечает потенциальную ценность продолжения разработки и расширения платформы ONNX. Они касаются проблемы разрозненности и необходимости упростить развертывание пакетов для лучшего внедрения. В беседе также есть комментарии участника, который подтверждает, что сталкивается с похожими проблемами, и предлагает варианты объединения Linux-сервера ONNX или поиска более эффективных способов помочь пользователям преобразовать пользовательский код в ONNX. Также спикер затрагивает тему поддержки мультимодальности и необходимости представления ансамбля моделей в виде единого ONNX-графа. Они обсуждают потенциальную потребность в большем количестве преобразователей и предлагают общее движение в правильном направлении.
  
  
• 00:25:00 В этом разделе обсуждения дорожной карты ONNX команда обсуждает примеры прокси-моделей для прокси-моделей, чтобы продемонстрировать типы вещей, которые клиенты используют в корпоративных средах для сценариев использования, не связанных с образами. Один из членов команды упоминает пример прокси для модели обнаружения мошенничества, которая использует некоторые открытые данные и представляет собой относительно простую двухуровневую модель LSTM. Команда продолжает расследование этого вопроса и пытается получить больше примеров прокси-моделей. Они также обсуждают проблемы с некорректным преобразованием GRU и LSTM и упоминают, что хотели бы добавить поддержку для всех случаев.
  
  
• 00:30:00 В этом разделе спикеры обсуждают проблемы преобразования графов GRU (gated recurent unit) в формат, который может быть прочитан конвертером серверной части. Они упоминают, что в некоторых случаях сбой уже происходит в TensorFlow, но вернуть его обратно в GRU сложно. Они предлагают использовать флаг `--custom ops` и создать работающее для него ядро, прежде чем переходить к идее сделать его функцией или сохранить его с точки зрения семантики. Они отмечают, что лучший вариант — явно указать, хочет ли пользователь его разбить или нет, и что использование пользовательских операций может быть единственным способом сделать это надежно.
  
  
• 00:35:00 В этой секции спикеры обсуждают, лучше ли иметь полнофункциональное тело как в ONNX, так и на высоком уровне или просто иметь базу ТФ. Для них базы TF было бы достаточно, поскольку ONNX можно было бы использовать в качестве доказательства результата по цепочке. Однако они предостерегают от создания ONNX, ориентированного на TensorFlow, поскольку ONNX должен иметь возможность поступать из разных мест. Они также коснулись привлекательности наличия именованного подграфа с семантическим значением, рассматривая его почти как оператор, который должен быть определен и сгенерирован различными внешними интерфейсами. Наконец, они договорились о более глубоких презентациях, чтобы продолжить обсуждение с более знающими людьми.

[MetaQuotes]

Обсуждение дорожной карты ONNX на 2021 год № 3 20210922

Обсуждение дорожной карты ONNX на 2021 год № 3 20210922

Во время обсуждения дорожной карты ONNX докладчики говорили о необходимости исправить проблемы с инструментом преобразования смещения ONNX, чтобы улучшить внедрение ONNX с последним оптимизированным стеком для определенных случаев использования. Выступавшие предложили улучшить охват моделей для тестирования преобразования смещения и разрешения промежуточных шагов, которые в настоящее время отсутствуют в тестах операторов или слоев. Они также обсудили важность метаданных и инфраструктуры федеративного обучения, в том числе необходимость включения метаданных в спецификацию ONNX для передачи аннотаций обучения и концепцию федеративного обучения для обеспечения конфиденциальности, эффективности и использования вычислительных ресурсов. Выступавшие призвали сообщество к сотрудничеству и запросили отзывы для дальнейшего обсуждения и реализации этих идей. Следующее заседание запланировано на 1 октября.

• 00:00:00 В этом разделе Манодж из Intel устраняет пробелы в преобразованиях смещения для моделей ONNX, которые вызывают проблемы у многих клиентов. Основная проблема заключается в преобразовании смещения, поскольку многие клиенты не идут и не обновляют смещение после развертывания модели в производстве. Клиенты сталкиваются с многочисленными проблемами при преобразовании смещения, например, при переходе от 7 к 10 и 13 для квантования или невозможности преобразовать старые смещения в новые, чтобы воспользоваться преимуществами производительности и хорошей точности. Кроме того, модульное тестирование или все тесты, относящиеся к каждому оператору или уровню, не доходят до точки, в которой независимые поставщики программного обеспечения довольны, и, следовательно, большинство клиентов по-прежнему используют смещение 10 или 9.
  
  
• 00:05:00 В этом разделе докладчики обсуждают необходимость решения проблем с инструментом преобразования смещения ONNX, поскольку он препятствует принятию ONNX с последним оптимизированным стеком для определенных случаев использования. Разработчики, которые интегрируют ИИ и поставляют его в свои приложения, сообщают о необходимости исправления инструментов преобразования и обеспечения их бесперебойной работы. Они делятся примерами проблем, с которыми они столкнулись, таких как отсутствие промежуточных шагов и реализация адаптера, которые препятствуют переходу на квантованные модели производительности. Выступающие подчеркивают необходимость лучшего охвата и большего количества протестированных моделей, чтобы обеспечить лучшее внедрение ONNX.
  
  
• 00:10:00 В этом разделе видео спикеры обсуждают необходимость утверждения как минимум одной неудачной модели от ведущей компании-создателя для дальнейших улучшений в ONNX. Обсуждение переходит к улучшению преобразования fp16, которое было одним из пробелов между различными экосистемами, такими как мобильные устройства и Windows, и к тому, как это было исправлено в последнее время с помощью инструментов преобразования Microsoft. Ответственность за преобразование неясна, но обсуждение переходит к следующей презентации, касающейся модельного зоопарка, где включение фонетических операторов для обучения поможет охватить все модели по категориям. Они предлагают начать с обучающих образцов трансформатора или НЛП и перейти к другим моделям, чтобы продемонстрировать распределенную инфраструктуру обучения и методы, применимые к ONNX.
  
  
• 00:15:00 В этом разделе докладчики обсуждают участие моделей ONNX в обучении, в том числе важность обучения с учетом квантования и использования смешанной точности. Они запрашивают исходную модель fp32, чтобы лучше сравнивать точность и демонстрировать использование смешанной точности для обучения с моделями ONNX. Они уделяют первоочередное внимание участию в образцах трансформаторов, но просят помощи у сообщества в создании других популярных категорий. Они также обсуждают будущие предложения по лучшему отражению использования смешанной точности в модели как части метаданных. Наконец, Гейб Стивенс представляет конфигурацию развертывания, которую Intel начинает рассматривать.
  
  
• 00:20:00 В этом разделе спикер обсуждает концепцию распределенного и федеративного обучения и его преимущества с точки зрения конфиденциальности, задержки, эффективности и использования вычислительных ресурсов. Идея состоит в том, чтобы развернуть модели на множестве устройств, где у некоторых устройств есть обучающая группа, которая обогащает модель, используя данные, которые они видят. Предлагаемые модификации ONNX позволят упростить федеративное обучение, что повысит вероятность того, что разработчики будут использовать ONNX. Минимальный набор дополнений к API включает способ запроса части, чтобы получить параметры локальной модели, обновить эти параметры и уведомить сервер об изменении модели для объединения в новую модель, которая включает результаты из устройства.
  
  
• 00:25:00 В этом разделе видео спикер обсуждает идею включения метаданных в спецификацию ONNX, чтобы можно было передавать обучающие аннотации и упростить обучение меньшего набора данных с помощью модели, обученной на большем наборе данных. Однако реализация такой системы включает в себя несколько проектных решений, которые должны быть оставлены на усмотрение разработчиков. Докладчик предлагает три элемента, которые могли бы упростить базовую инфраструктуру такой системы, не ограничивая гибкость, необходимую для разработчиков приложений. Они также упоминают о необходимости согласованности в развертывании версий модели на множестве устройств и важности необязательного участия только моделей ONNX в федеративной системе обучения. Докладчик запрашивает отзывы о том, заинтересованы ли разработчики спецификаций в том, чтобы обратить внимание на такую конфигурацию обучения, и готовы ли они к дальнейшему обсуждению. Другой докладчик предлагает попробовать сделать это с помощью среды выполнения ONNX, так как она поддерживает обучение, а для федеративного обучения с ее использованием были созданы некоторые доказательства концепций.
  
  
• 00:30:00 В этом разделе спикер выражает свою признательность за огромные усилия, приложенные к презентации, и благодарит сообщество за вопросы. Цель презентации — представить идеи соответствующей SIG для дальнейшего обсуждения и возможной реализации. Последняя сессия состоится 1 октября, и спикер надеется на дальнейшее участие в этих идеях.