Для 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 для вычислений.
Мы же работаем с моделями существенно меньшего размера и квантуем не для эффективного сжатия в памяти в первую очередь, а для вычислений. В результате, у нас отличается и сама схема квантования, и подход к ее вычислению: мы квантуем веса, входные сигналы и вычисляем свертки полностью в целых числах, оптимизируя все методы для центральных процессоров.
Здравствуйте! Спасибо за ваш отзыв, очень рады, что статья показалась вам интересной.
Разработка подобных инструментов визуализации относится к области компьютерной графики и требует знаний в программировании GPU, так и понимания алгоритмов трассировки лучей, методов объемного рендеринга.
Порог входа достаточно высокий, особенно если целью является создание высокопроизводительных интерактивных инструментов. Необходимо хорошо разбираться в низкоуровневом программировании не только GPU, но и хорошо знать способы оптимизации CPU, а также иметь хорошие знания в оптимизации алгоритмов и работе с большими объемами данных.
Если будут еще вопросы - обращайтесь, будем рады помочь!
Рентгеновская и механическая части производства российской компании ЭЛТЕХ-Мед, вся вычислительная часть (реконструкция, коррекция, сегментация и визуализация) - Smart Engines.
Основные параметры: Диапазон тока: 0.05-0.15 мкА Диапазон напряжений: 35-130 кВ Размер пикселя детектора: 140х140 мкм Предельное разрешение: ~30-35мкм
Характерные размеры загрузочной камеры на картинке.
Исследование драгоценных камней проводилось в рамках научной работы. Пока мы не планируем делать бизнес на проверках, наш бизнес – это софт. Чтобы делать такие исследования необходимы рентгеновская часть и софт, с вопросами по их покупке пишите нам через форму на сайте https://smartengines.ru/smart-tomo-engine/.
Когда речь идет о распознавании выполненных по стандарту QR в хороших условиях распознавания - тут вы правы. Более того, даже десятки бесплатных библиотек, написанных студентами старших курсов, справятся с такой задачей.
Но когда речь о живых кейсах, включающих отклонения от стандартов, плохие условия освещенности, существенные повреждения баркода, наличие глубокой проективности и т.д. - требуется полноценное промышленное решение, которое не зависит от платформы.
Дорогие друзья! 19 января заканчивается марафон новогодних праздников. Поэтому еще три дня очень ждем ваши комментарии, после чего выберем победителя и направим ему наш календарик!
Алгоритмы сами по себе не накладывают ограничений, все зависит от системы технического зрения, которую вы будете использовать. Параметры оптики и матрицы, расстояние от объекта — все это будет влиять, более того, для таких точностей будет влиять еще и стабильность их характеристик.
Будем рады быть полезными, за деталями — уже в 2024 году) С наступающими праздниками!
После публикации в открытом доступе CuneiForm и Tesseract OCR вопрос полнотекстового офлайн распознавания для бытовых нужд фактически стал закрытым. Эти движки встроены в десятки прикладных инструментов для ПК, позволяющих решить возникающие мелкие бытовые задачи, сведя на "нет" необходимость в коммерческом софте.
Другой вопрос - промышленное распознавание документов, где и постановка задачи отличается, и требования к ПО совершенно другие, и программные решения полноценно отечественные (читай - наши).
Да, действительно, подобные вопросы часто возникают в задачах подсчета статистик в скользящем окне. И, как вы верно отметили, абсолютные центральные моменты почти никогда не нужны, видимо поэтому мы не смогли найти где-то описанного ранее алгоритма :)
В случае обработки в скользящем окне упомянутый вами двухпроходный алгоритм, скорее всего, действительно более практичен: он будет и более стабилен вычислительно, да и трудоемкость отходит по важности на второе место (т.к. зависит она от размера окна а не от размера постоянно растущей выборки). В нашем же случае мы скорее ориентировались на случай с растущими выборками и нас больше всего интересовала трудоемкость обновления (больше, чем вычислительная стабильность).
Кстати, по поводу вычислительной стабильности, работа 2016-го года, на которую мы ссылаемся в тексте (https://link.springer.com/article/10.1007/s00180-015-0637-z) о быстром обновлении центральных моментов (не абсолютных) почти целиком посвящена проблемам накопления ошибки вычислений с плавающей точкой. Этот вопрос там хорошо и подробно рассмотрен, рекомендуем.
Разумеется, существует множество как платного, так и бесплатного ПО для 3D визуализации.
Для реконструкции и визуализации 3D изображений мы пользуемся собственным софтом STE, но он, конечно, платный (вот статья про него). Немного результатов наших визуализаций можно найти тут, тут и тут.
Из бесплатных можем порекомендовать: ImageJ (Используется учёными для численного анализа изображений).
Оценка точности результатов при использовании нейросетевых моделей - это важная задача, над решением которой мы в SE работаем, говоря об Ответственном искусственном интеллекте.
Для 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 для вычислений.
Мы же работаем с моделями существенно меньшего размера и квантуем не для эффективного сжатия в памяти в первую очередь, а для вычислений. В результате, у нас отличается и сама схема квантования, и подход к ее вычислению: мы квантуем веса, входные сигналы и вычисляем свертки полностью в целых числах, оптимизируя все методы для центральных процессоров.
Здравствуйте! Спасибо за ваш отзыв, очень рады, что статья показалась вам интересной.
Разработка подобных инструментов визуализации относится к области компьютерной графики и требует знаний в программировании GPU, так и понимания алгоритмов трассировки лучей, методов объемного рендеринга.
Порог входа достаточно высокий, особенно если целью является создание высокопроизводительных интерактивных инструментов. Необходимо хорошо разбираться в низкоуровневом программировании не только GPU, но и хорошо знать способы оптимизации CPU, а также иметь хорошие знания в оптимизации алгоритмов и работе с большими объемами данных.
Если будут еще вопросы - обращайтесь, будем рады помочь!
Рентгеновская и механическая части производства российской компании ЭЛТЕХ-Мед, вся вычислительная часть (реконструкция, коррекция, сегментация и визуализация) - Smart Engines.
Основные параметры:
Диапазон тока: 0.05-0.15 мкА
Диапазон напряжений: 35-130 кВ
Размер пикселя детектора: 140х140 мкм
Предельное разрешение: ~30-35мкм
Характерные размеры загрузочной камеры на картинке.
Исследование драгоценных камней проводилось в рамках научной работы. Пока мы не планируем делать бизнес на проверках, наш бизнес – это софт. Чтобы делать такие исследования необходимы рентгеновская часть и софт, с вопросами по их покупке пишите нам через форму на сайте https://smartengines.ru/smart-tomo-engine/.
Добрый день!
Ничего не знаем насчет всех остальных, но мы умеем и делаем)
Положив в КТ, мы узнаем, что внутри.
Когда речь идет о распознавании выполненных по стандарту QR в хороших условиях распознавания - тут вы правы. Более того, даже десятки бесплатных библиотек, написанных студентами старших курсов, справятся с такой задачей.
Но когда речь о живых кейсах, включающих отклонения от стандартов, плохие условия освещенности, существенные повреждения баркода, наличие глубокой проективности и т.д. - требуется полноценное промышленное решение, которое не зависит от платформы.
Спасибо! Благодарим за интерес к нашим технологиям.
Дорогие друзья! 19 января заканчивается марафон новогодних праздников. Поэтому еще три дня очень ждем ваши комментарии, после чего выберем победителя и направим ему наш календарик!
Добрый вечер!
Алгоритмы сами по себе не накладывают ограничений, все зависит от системы технического зрения, которую вы будете использовать. Параметры оптики и матрицы, расстояние от объекта — все это будет влиять, более того, для таких точностей будет влиять еще и стабильность их характеристик.
Будем рады быть полезными, за деталями — уже в 2024 году) С наступающими праздниками!
Добрый день!
Национальные патенты РФ не признаются в США. Поэтому мы и патентуем наши разработки как в России, так и в США.
С наступающим Новым годом!
Спасибо!
Добрый день!
Речь идет о QR-кодах, использующихся для платежей, 7 поколения и позже
После публикации в открытом доступе CuneiForm и Tesseract OCR вопрос полнотекстового офлайн распознавания для бытовых нужд фактически стал закрытым. Эти движки встроены в десятки прикладных инструментов для ПК, позволяющих решить возникающие мелкие бытовые задачи, сведя на "нет" необходимость в коммерческом софте.
Другой вопрос - промышленное распознавание документов, где и постановка задачи отличается, и требования к ПО совершенно другие, и программные решения полноценно отечественные (читай - наши).
Добрый день, благодарим за интерес к публикации!
У нас используется наша собственная OCR, которая поддерживает 103 языка и работает в том числе на мобильных телефонах.
Спасибо за ваш интерес!
Да, действительно, подобные вопросы часто возникают в задачах подсчета статистик в скользящем окне. И, как вы верно отметили, абсолютные центральные моменты почти никогда не нужны, видимо поэтому мы не смогли найти где-то описанного ранее алгоритма :)
В случае обработки в скользящем окне упомянутый вами двухпроходный алгоритм, скорее всего, действительно более практичен: он будет и более стабилен вычислительно, да и трудоемкость отходит по важности на второе место (т.к. зависит она от размера окна а не от размера постоянно растущей выборки). В нашем же случае мы скорее ориентировались на случай с растущими выборками и нас больше всего интересовала трудоемкость обновления (больше, чем вычислительная стабильность).
Кстати, по поводу вычислительной стабильности, работа 2016-го года, на которую мы ссылаемся в тексте (https://link.springer.com/article/10.1007/s00180-015-0637-z) о быстром обновлении центральных моментов (не абсолютных) почти целиком посвящена проблемам накопления ошибки вычислений с плавающей точкой. Этот вопрос там хорошо и подробно рассмотрен, рекомендуем.
Приветствуем!
Разумеется, существует множество как платного, так и бесплатного ПО для 3D визуализации.
Для реконструкции и визуализации 3D изображений мы пользуемся собственным софтом STE, но он, конечно, платный (вот статья про него). Немного результатов наших визуализаций можно найти тут, тут и тут.
Из бесплатных можем порекомендовать: ImageJ (Используется учёными для численного анализа изображений).
Оценка точности результатов при использовании нейросетевых моделей - это важная задача, над решением которой мы в SE работаем, говоря об Ответственном искусственном интеллекте.
Спасибо за комментарий. Наша позиция - не равняться на конкурентов, а просто делать хорошо. Кстати, про ABBYY: здоровья ушедшим...