Оценка положения оси вращения с помощью центра масс усреднённого проекционного снимка была рассмотрена нами в работе. Эксперименты показали, что в ряде случаем она дает неверный ответ. Например, когда в область видимости детектора кроме самого образца попадает подставка для его крепления. На получаемых в таких условиях проекционных данных, помимо контуров объекта, оказываются отчетливо различимы контуры подставки. Центр масс таких проекций оказывается сильно смещенным от центра масс проекции исключительно самого объекта. Поиск сдвига оси вращения вокруг положения центра масс в совокупности столика и объекта приводит к неверным результатам.
Предложенная Вами оптимизация целевого функционала, без сомнения, возможна и также была нами апробирована. Но она также показала себя неустойчивой к нарушениям условий сканирования объекта. Такая оптимизация приводит к ошибочным результатам в случае выхода объекта из поля видимости детектора. Описанная в тексте статьи Хабра оптимизация оказывается более устойчива к выходу объекта из поля видимости детектора, присутствию в поле видимости детектора столика, а также сильной зашумленности проекций. Это подтверждено нашими экспериментами, помещенными в работе.
Мы спросили ChatGPT, как наиболее вежливо ответить на ваш комментарий. ИИ предложил следующее:
Спасибо за Ваше замечание. Мы действительно ценим мнение каждого и стремимся к конструктивному диалогу. Хотел бы пояснить, что наша деятельность направлена на проведение реальных научных исследований, которые нацелены на получение новых знаний и развитие технологий. Мы убеждены, что каждый вопрос и каждое обсуждение способствует продвижению науки и помогает достигать значимых результатов, которые могут принести пользу обществу. Будем рады продолжить сотрудничество и обмен мнениями.
Современные смартфоны давно достигли по мощности средненьких персональных компьютеров. При разумном подходе к оптимизации нейросетевых моделей, уже сейчас можно запускать локально обработку фото/видео, распознавание qr и банковских карт, распознавание документов и голоса. Сейчас работаем над тем, как запускать более серьезные локальные модели.
Для слоя нейронной сети ln и exp делаются для входного и выходного векторов данных соответственно, а это существенно меньшее число операций, чем число умножений внутри, например, сверточного слоя.
RFID не содержит открытых данных по соображениям элементарных норм безопасности. Чтобы его прочитать и дешифровать, нужно знать ключ, который собирается из персональных данных (MRZ).
"Нормальные машиночитаемые паспорта", несущие внутри себя чип, очень широко распространены (если Вы про это). Правда, ключом к этой информации является MRZ (две кодифицированные строки внизу документа). который все еще считывается с помощью "костылей оптического распознавания".
Да, в этом направлении мы тоже работаем. Однако несмотря на то, что графические ускорители есть практически везде, там тот еще зоопарк. Нужно поддерживать как минимум ветку для устройств Apple и OpenCL для всех остальных, но на практике оказывается, что не на всех мобильных GPU OpenCL работает одинаково хорошо.
Vulkan позволяет гораздо эффективнее общаться с видеокартой по сравнению с OpenGL, когда требуется отправлять большое количество команд или работать с несколькими видеокартами одновременно. Однако в нашем случае переход на Vulkan не принесет никаких преимуществ. Мы не сможем воспользоваться его возможностями, поскольку отправляем на видеокарту лишь небольшое количество несложных команд в процессе отрисовки. С другой стороны, OpenGL очень широко распространен, что для нас крайне важно.
Про воксельный редактор: такой редактор — отдельный непростой продукт, и пока в наши планы его создание не входит. Нам кажется, что распыляться и делать кое-как — это неправильно. Мы будем делать свое и прекрасно, а другое сделает прекрасно кто-нибудь еще.
Про ОКТ: это может быть интересным направлением развития. Спасибо за идею. Но пока мы еще не начали экспансию за пределы области рентгеновских методов.
Также сравнились с 4 битами, для которых есть быстрая ЦПУ имплементация (дальше только тернарные, тернарно-бинарные и бинарные сети, которые заметно хуже по качеству), и 4.6-битное квантование лучше по качеству и всего на 4% медленнее.
fp8/bf8 принципиально отличаются от нашей схемы квантования, так как это типы данных с плавающей точкой и для работы с ними нужны отдельные арифметико-логические устройства, которые есть не на всех центральных процессорах. Наш же тип использует линейную схему квантования и работает полностью в целых числах, скоро напишем подробную статью.
Для llama моделей схемы квантования qn_* устроены следующим образом: веса делятся на блоки и в каждом блоке квантуются независимо до n разрядов. То есть на каждый блок еще приходится несколько параметров схемы квантования (например, scale и bias, которые также могут иметь разную разрядность). В результате усреднения по сети получаются дробные значения bits per weight, которые можно, например, видеть в таблице. При этом на один вес приходится 2^n возможных значений.
Вычисление квантованных llama моделей, разумеется, использует AVX на CPU. Сначала квантованные веса загружаются в векторные регистры, чем сильнее квантована сеть, тем больше весов можно загрузить за один load. Далее эти веса распаковываются непосредственно на регистрах и вычисляется скалярное произведение с помощью AVX-инструкций. Проверили сейчас, непосредственно в llama.cpp для типов q4_0 и q8_0 выполняется распаковка в int8 для весов и fp16 для скейлов (сравните функции ggml_vec_dot_q4_0_q8_0 для типа q4_0 и ggml_vec_dot_q8_0_q8_0 для типа q8_0 тут) и скалярное произведение вычисляется умножением значений int8 c аккумулированием во float. То есть, разница в скорости для двух этих типов возникает за счет загрузки и распаковки весов, не самого вычисления скалярного прозведения.
В нашем случае диапазон значений веса не является степенью двойки и позволяет представить больше, чем 16 значений, однако позволяет нам имплементировать матричное умножение более эффективно, чем для 8-битных сетей.
В результате мы достигаем скорости практически как у 4-битных моделей, но 4.6-битные сети работают точнее.
В случае больших языковых моделей основным ограничивающим фактором является пропускная способность памяти. GGUF является форматом хранения, при котором коэффициенты квантуются, и модель начинает занимать меньше места, а уже в оперативной памяти по частям преобразуется в fp16 или bf16 для вычислений.
Мы же работаем с моделями существенно меньшего размера и квантуем не для эффективного сжатия в памяти в первую очередь, а для вычислений. В результате, у нас отличается и сама схема квантования, и подход к ее вычислению: мы квантуем веса, входные сигналы и вычисляем свертки полностью в целых числах, оптимизируя все методы для центральных процессоров.
Да, во время эксперимента ни один программист не пострадал!
Нет. На конференции сказали, что OCR still useful.
Скоро выпустим апдейт по итогам ICDAR-2024. Ждите!
Спасибо за комментарий!
Оценка положения оси вращения с помощью центра масс усреднённого проекционного снимка была рассмотрена нами в работе. Эксперименты показали, что в ряде случаем она дает неверный ответ. Например, когда в область видимости детектора кроме самого образца попадает подставка для его крепления. На получаемых в таких условиях проекционных данных, помимо контуров объекта, оказываются отчетливо различимы контуры подставки. Центр масс таких проекций оказывается сильно смещенным от центра масс проекции исключительно самого объекта. Поиск сдвига оси вращения вокруг положения центра масс в совокупности столика и объекта приводит к неверным результатам.
Предложенная Вами оптимизация целевого функционала, без сомнения, возможна и также была нами апробирована. Но она также показала себя неустойчивой к нарушениям условий сканирования объекта. Такая оптимизация приводит к ошибочным результатам в случае выхода объекта из поля видимости детектора. Описанная в тексте статьи Хабра оптимизация оказывается более устойчива к выходу объекта из поля видимости детектора, присутствию в поле видимости детектора столика, а также сильной зашумленности проекций. Это подтверждено нашими экспериментами, помещенными в работе.
Мы спросили ChatGPT, как наиболее вежливо ответить на ваш комментарий. ИИ предложил следующее:
Современные смартфоны давно достигли по мощности средненьких персональных компьютеров. При разумном подходе к оптимизации нейросетевых моделей, уже сейчас можно запускать локально обработку фото/видео, распознавание qr и банковских карт, распознавание документов и голоса. Сейчас работаем над тем, как запускать более серьезные локальные модели.
Для слоя нейронной сети ln и exp делаются для входного и выходного векторов данных соответственно, а это существенно меньшее число операций, чем число умножений внутри, например, сверточного слоя.
RFID не содержит открытых данных по соображениям элементарных норм безопасности. Чтобы его прочитать и дешифровать, нужно знать ключ, который собирается из персональных данных (MRZ).
"Нормальные машиночитаемые паспорта", несущие внутри себя чип, очень широко распространены (если Вы про это). Правда, ключом к этой информации является MRZ (две кодифицированные строки внизу документа). который все еще считывается с помощью "костылей оптического распознавания".
Для обхода законодательства обычно достаточно бумажек и сертификатов, технологии не требуются.
Можно и так, но это уже не к нам.
Мы занимаемся распознаванием и проверкой подлинности и решаем задачу в моменте.
Тоже выход, но что делать в таком случае с дефицитом кадров?
Приветствуем!
Да, в этом направлении мы тоже работаем. Однако несмотря на то, что графические ускорители есть практически везде, там тот еще зоопарк. Нужно поддерживать как минимум ветку для устройств Apple и OpenCL для всех остальных, но на практике оказывается, что не на всех мобильных GPU OpenCL работает одинаково хорошо.
Про реконструкцию поверхностей: пока нет, но есть в планах. Следите за нашими новостями)
Vulkan позволяет гораздо эффективнее общаться с видеокартой по сравнению с OpenGL, когда требуется отправлять большое количество команд или работать с несколькими видеокартами одновременно. Однако в нашем случае переход на Vulkan не принесет никаких преимуществ. Мы не сможем воспользоваться его возможностями, поскольку отправляем на видеокарту лишь небольшое количество несложных команд в процессе отрисовки. С другой стороны, OpenGL очень широко распространен, что для нас крайне важно.
Приветствуем! Благодарим за интерес к статье.
Про воксельный редактор: такой редактор — отдельный непростой продукт, и пока в наши планы его создание не входит. Нам кажется, что распыляться и делать кое-как — это неправильно. Мы будем делать свое и прекрасно, а другое сделает прекрасно кто-нибудь еще.
Про ОКТ: это может быть интересным направлением развития. Спасибо за идею. Но пока мы еще не начали экспансию за пределы области рентгеновских методов.
Также сравнились с 4 битами, для которых есть быстрая ЦПУ имплементация (дальше только тернарные, тернарно-бинарные и бинарные сети, которые заметно хуже по качеству), и 4.6-битное квантование лучше по качеству и всего на 4% медленнее.
fp8/bf8 принципиально отличаются от нашей схемы квантования, так как это типы данных с плавающей точкой и для работы с ними нужны отдельные арифметико-логические устройства, которые есть не на всех центральных процессорах. Наш же тип использует линейную схему квантования и работает полностью в целых числах, скоро напишем подробную статью.
Для llama моделей схемы квантования qn_* устроены следующим образом: веса делятся на блоки и в каждом блоке квантуются независимо до n разрядов. То есть на каждый блок еще приходится несколько параметров схемы квантования (например, scale и bias, которые также могут иметь разную разрядность). В результате усреднения по сети получаются дробные значения bits per weight, которые можно, например, видеть в таблице. При этом на один вес приходится 2^n возможных значений.
Вычисление квантованных llama моделей, разумеется, использует AVX на CPU. Сначала квантованные веса загружаются в векторные регистры, чем сильнее квантована сеть, тем больше весов можно загрузить за один load. Далее эти веса распаковываются непосредственно на регистрах и вычисляется скалярное произведение с помощью AVX-инструкций. Проверили сейчас, непосредственно в llama.cpp для типов q4_0 и q8_0 выполняется распаковка в int8 для весов и fp16 для скейлов (сравните функции ggml_vec_dot_q4_0_q8_0 для типа q4_0 и ggml_vec_dot_q8_0_q8_0 для типа q8_0 тут) и скалярное произведение вычисляется умножением значений int8 c аккумулированием во float. То есть, разница в скорости для двух этих типов возникает за счет загрузки и распаковки весов, не самого вычисления скалярного прозведения.
В нашем случае диапазон значений веса не является степенью двойки и позволяет представить больше, чем 16 значений, однако позволяет нам имплементировать матричное умножение более эффективно, чем для 8-битных сетей.
В результате мы достигаем скорости практически как у 4-битных моделей, но 4.6-битные сети работают точнее.
В случае больших языковых моделей основным ограничивающим фактором является пропускная способность памяти. GGUF является форматом хранения, при котором коэффициенты квантуются, и модель начинает занимать меньше места, а уже в оперативной памяти по частям преобразуется в fp16 или bf16 для вычислений.
Мы же работаем с моделями существенно меньшего размера и квантуем не для эффективного сжатия в памяти в первую очередь, а для вычислений. В результате, у нас отличается и сама схема квантования, и подход к ее вычислению: мы квантуем веса, входные сигналы и вычисляем свертки полностью в целых числах, оптимизируя все методы для центральных процессоров.