Forwarded from Всеволод Викулин | AI разбор
Сегодняшнее правило LLM-разработки сэкономит не только месяцы жизни, но и несчетное число нервных клеток. Мне точно сэкономило, хотя, может я просто нервный.
Правило 8. Сначала делайте прототип
Как делают обычно: придумали, как с помощь ИИ увеличить бизнес-метрику. И сразу пошли раздавать задачи инженерам: идите данные собирать да модели обучать. Чтобы метрика побольше стала.
Почему нельзя сразу в бой
1) В ИИ сложно спрогнозировать достижимость эффекта. Легко может оказаться, что текущими технологиями ваша задача не решается с нужным качеством. Но узнаете вы это спустя полгода, когда инженеры вам принесут модель.
2) В ИИ куча краевых случаев. Заранее прописать весь список в техническом задании невозможно. Но спустя полгода вы можете очень удивиться, что модель работает не так, как предполагалось.
Что такое прототип
Это система, которая имеет необходимое качество, но которую нельзя использовать по другим причинам. Например, очень долго работает. Или не проходит по требованиям безопасности. Главное — вам должен нравиться тот результат, который она дает.
Прототип обычно создается на какой-то удобной платформе, типа n8n. Там мы используем самые мощные модели, чтобы получить как можно быстрее ожидаемое качество.
Когда мы сделали прототип, мы переходим на следующий этап. Техническая команда, сохраняя его качество, снимает все другие ограничения. Например, ускоряет модели.
Как создать прототип по шагам
1) Выделенная команда. В ней точно должен быть продакт-менеджер, который понимает, что хочет, бекенд разработчик и специалист, который уже собирал ИИ-системы.
2) Тестовая выборка. В ней для всех входных в систему запросов вся команда точно понимает, какой правильный результат. Команде нужно до этого договориться.
3) Метрики качества на тестовой выборке. Подробнее в прошлом правиле.
4) Итерации на этой выборке, которые максимизируют качество. Итерации вида:
- Взяли самые большие и дорогие модели.
- Провели анализ проблем по выборке. Записали их в эксельку
- Подумали, как это чинить. Покрутить промпт, разбить на подзадачи, добавить RAG и тд.
По этой методике реально собрать рабочий прототип за несколько недель.
Литература для обязательного изучения
- Статья известнейшего специалиста (моя), в ней про это раздел.
- Гайд по быстрым итерациями. Это все нужно использовать на прототипе.
Тема нераспиаренная, но очень важная, полезного контента мало. Если остались вопросы — пишите в комментарии или в личные сообщения.
#llm_system_design
Правило 8. Сначала делайте прототип
Как делают обычно: придумали, как с помощь ИИ увеличить бизнес-метрику. И сразу пошли раздавать задачи инженерам: идите данные собирать да модели обучать. Чтобы метрика побольше стала.
Почему нельзя сразу в бой
1) В ИИ сложно спрогнозировать достижимость эффекта. Легко может оказаться, что текущими технологиями ваша задача не решается с нужным качеством. Но узнаете вы это спустя полгода, когда инженеры вам принесут модель.
2) В ИИ куча краевых случаев. Заранее прописать весь список в техническом задании невозможно. Но спустя полгода вы можете очень удивиться, что модель работает не так, как предполагалось.
Что такое прототип
Это система, которая имеет необходимое качество, но которую нельзя использовать по другим причинам. Например, очень долго работает. Или не проходит по требованиям безопасности. Главное — вам должен нравиться тот результат, который она дает.
Прототип обычно создается на какой-то удобной платформе, типа n8n. Там мы используем самые мощные модели, чтобы получить как можно быстрее ожидаемое качество.
Когда мы сделали прототип, мы переходим на следующий этап. Техническая команда, сохраняя его качество, снимает все другие ограничения. Например, ускоряет модели.
Как создать прототип по шагам
1) Выделенная команда. В ней точно должен быть продакт-менеджер, который понимает, что хочет, бекенд разработчик и специалист, который уже собирал ИИ-системы.
2) Тестовая выборка. В ней для всех входных в систему запросов вся команда точно понимает, какой правильный результат. Команде нужно до этого договориться.
3) Метрики качества на тестовой выборке. Подробнее в прошлом правиле.
4) Итерации на этой выборке, которые максимизируют качество. Итерации вида:
- Взяли самые большие и дорогие модели.
- Провели анализ проблем по выборке. Записали их в эксельку
- Подумали, как это чинить. Покрутить промпт, разбить на подзадачи, добавить RAG и тд.
По этой методике реально собрать рабочий прототип за несколько недель.
Литература для обязательного изучения
- Статья известнейшего специалиста (моя), в ней про это раздел.
- Гайд по быстрым итерациями. Это все нужно использовать на прототипе.
Тема нераспиаренная, но очень важная, полезного контента мало. Если остались вопросы — пишите в комментарии или в личные сообщения.
#llm_system_design
Forwarded from max.sh
Подборка ресурсов для изучения RL в контексте LLM
Методы пост-тренировки — RLHF, GRPO, DPO и другие — очень быстро эволюционируют и становятся "повседневным" инструментом ML-инженеров. Это особенно заметно с появлением концепции верифицируемых ревордов (подробнее тут):
➡️ провайдеры вроде OpenAI предлагают RL-файнтюн на ваших данных через API
➡️ open-source стремительно наполняется библиотеками и рецептами
⚡️ на интервью все чаще встречаются секции или вопросы посвященные RL (из того что вижу, как правило в рамках ML Design round, но бывает и в ML Breadth части).
Поэтому понимать инженерные аспекты и ключевые идеи (зачем нужен Reward Model, что такое Reward Hacking, почему используется KL в оптимизационной задаче) становится крайне актуально. Как в работе, так и на собеседованиях.
Собрал подборку материалов, чтобы плавно войти в тему. Исходил из того, что читатель не заком с RL (только базовым ML), материалы написаны простым языком, но со всеми формулами и ссылками на статьи, а авторы — уважаемые в сообществе исследователи.
Поехали:
1️⃣ Введение в RLHF в лонг-риде от Chip Huyen. Ссылка. Пост от 23 года, но лучшее введение по теме найти сложно. Все стадии подробно расписаны, после него уже можно браться за статьи.
2️⃣ Почитать про RL в действии на примере файн-тюна модели, которую учат писать эффективный GPU код. Блогпост
➡️ Посмотреть на все еще раз через примеры в интерактивном бесплатном мини-курсе Reinforcement Fine-Tuning LLMs With GRPO
3️⃣ Теперь готовы к более глубоким материалм и обоснованиям всех выкладок. Бесплатная онлайн-книга от Nathan Lambert (Research Scientist, Allen AI) - Reinforcement Learning from Human Feedback.
➡️ Пост был написан в целом ради пункта 3. На мой взгляд, найти более полный актуальный справочник сложно.
➡️ В дополнение, если хочется посмотреть на другое изложение, прекрасный гид по широкому спектру LLM тем, включая все концепции RL на comfyai.app
4️⃣ К этому моменту скорее всего ключевые идеи RL тюнинга для LLM уже понятны. Дальше Есть несколько путей: a) идти читать статьи про свежие подходы. b) идти применять к своим задачам, то есть копаться в инженирии, но уже очень осознанно. c) углубиться в базовую теорию RL и прочувствовать все методы в общем виде (а не упрощенном).
➡️ Плейлист академических лекций курса David Silver из DeepMind из далекого 2015-го. Ссылка. От Марковсих процессов до Многоруких бандитов. Курс предполагает только знания матана и тер вера.
➡️ Перезапуск этого же курса от 2018 года с обновленным материалом и включением тем типа DQN (но курс уже не такой целостный, потому что лекции ведут разные авторы). Ссылка
5️⃣ Заканчиваем все книгой отца RL, Sutton-ом, и его Reinforcement Learning: An Introduction, второе издание. Ссылка
💬 Если есть интересные материалы, кидайте в комментарии, буду рад добавить/почитать
😀 Если откликается формат, буду рад огонькам и комментариям с идеями про что еще хотели бы почитать)
#образование
Методы пост-тренировки — RLHF, GRPO, DPO и другие — очень быстро эволюционируют и становятся "повседневным" инструментом ML-инженеров. Это особенно заметно с появлением концепции верифицируемых ревордов (подробнее тут):
Поэтому понимать инженерные аспекты и ключевые идеи (зачем нужен Reward Model, что такое Reward Hacking, почему используется KL в оптимизационной задаче) становится крайне актуально. Как в работе, так и на собеседованиях.
Собрал подборку материалов, чтобы плавно войти в тему. Исходил из того, что читатель не заком с RL (только базовым ML), материалы написаны простым языком, но со всеми формулами и ссылками на статьи, а авторы — уважаемые в сообществе исследователи.
Поехали:
#образование
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Ars Poetica Numeralis
Методы декодирования LM "top-nσ sampling" и "NS-FH": код и сравнение
Я написал код с реализацией двух относительно новых методов декодирования для авторегрессионных языковых моделей. Эти методы предложены в статьях:
Top-nσ: Eliminating Noise in Logit Space for Robust Token Sampling of LLM
Lingxi: A Diversity-aware Chinese Modern Poetry Generation System
Обе статьи опубликованы на сайте ACL, прошли фильтр ревьюверов и содержат ряд утверждений касательно улучшения качества генерации для креативных текстов. Мне было интересно посмотреть, докинут ли они что-нибудь при генерации русскоязычной поэзии относительно реализованных в transformers алгоритмов, в частности top-p, min-p и epsilon-sampling.
Код для top-nσ sampling: top_nsigma_filter.py
Код для NS-FH: ns_flattened_head_sampling.py
Ключевые идеи этих алгоритмов достаточно простые и исчерпывающе описаны в статьях, поэтому не буду тут пересказывать. В ридмишке репозитория я привел скрины, по которым, в принципе, можно написать соответствующий код.
Оценивать качество креативной генерации обычно непросто. Но для поэзии у меня есть весьма надежный инструмент - библиотека для расчета техничности RussianPoetryScansionTool. Техничность стихотворения включает в себя соответствие одному из классических поэтических метров и качество рифмовки. Ключевая идея тут в том, что эта метрика рассчитывается детерминированным и интерпретируемым образом, что позволяет объективно и воспроизводимо сравнивать генерации разных моделей или для разных настроек параметров декодирования.
Увы, результаты сравнения двух вышеуказанных алгоритмов не очень оптимистичные - они не дотягивают до того, что можно получить с помощью старого доброго нуклеуса, min-p или epsilon-sampling (он в топе, кстати). Фрагмент таблицы можно увидеть по ссылке.
С другой стороны, отставание не настолько велико, чтобы прямо "бу-у-у". Возможно, для китайского или английского языков они действительно докидывают в качество, особенно для длинных генераций.
Я написал код с реализацией двух относительно новых методов декодирования для авторегрессионных языковых моделей. Эти методы предложены в статьях:
Top-nσ: Eliminating Noise in Logit Space for Robust Token Sampling of LLM
Lingxi: A Diversity-aware Chinese Modern Poetry Generation System
Обе статьи опубликованы на сайте ACL, прошли фильтр ревьюверов и содержат ряд утверждений касательно улучшения качества генерации для креативных текстов. Мне было интересно посмотреть, докинут ли они что-нибудь при генерации русскоязычной поэзии относительно реализованных в transformers алгоритмов, в частности top-p, min-p и epsilon-sampling.
Код для top-nσ sampling: top_nsigma_filter.py
Код для NS-FH: ns_flattened_head_sampling.py
Ключевые идеи этих алгоритмов достаточно простые и исчерпывающе описаны в статьях, поэтому не буду тут пересказывать. В ридмишке репозитория я привел скрины, по которым, в принципе, можно написать соответствующий код.
Оценивать качество креативной генерации обычно непросто. Но для поэзии у меня есть весьма надежный инструмент - библиотека для расчета техничности RussianPoetryScansionTool. Техничность стихотворения включает в себя соответствие одному из классических поэтических метров и качество рифмовки. Ключевая идея тут в том, что эта метрика рассчитывается детерминированным и интерпретируемым образом, что позволяет объективно и воспроизводимо сравнивать генерации разных моделей или для разных настроек параметров декодирования.
Увы, результаты сравнения двух вышеуказанных алгоритмов не очень оптимистичные - они не дотягивают до того, что можно получить с помощью старого доброго нуклеуса, min-p или epsilon-sampling (он в топе, кстати). Фрагмент таблицы можно увидеть по ссылке.
С другой стороны, отставание не настолько велико, чтобы прямо "бу-у-у". Возможно, для китайского или английского языков они действительно докидывают в качество, особенно для длинных генераций.
Forwarded from Art, Design & AI (Lena Starkova)
1. Draw-to-Video
Теперь не нужно описывать сцену текстом – достаточно нарисовать движение:
• Загружаешь или генерируешь стартовое изображение (например, через Higgsfield Soul)
• В кадре рисуешь стрелки, нумеруешь события (1–2–3). Например, "мужчина идет", "машина проезжает"
• Можно вставить объект: напиток в руке или одежду прямо в кадре. Без промтов!
• Модель добавляет движение или смену. Как раскадровка, но оживающая
• Работает на Veo 3, MiniMax Hailuo 02 и Seedance Pro
2. Product-to-Video
Тот самый инструмент для брендов и e-commerce:
• Загружаешь фото товара, а AI оживляет его
• Можно вставить предмет в кадр, задать движение – быстрый способ сделать промо-ролик без съёмки
Лично я в восторге! Это не просто апдейт, а новый уровень визуального сторителлинга.
Арт, дизайн и нейросети
@art_design_ai
#higgsfield@art_design_ai
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from [31/100] Витя Тарнавский
Где искать кейсы по GenAI
Кейс-библиотеки у OpenAI и других вендоров абсолютно ужасны. Типичный кейс – это расплывчатая задача, ноль техдеталей и восхваление соответствующего вендора. Можете сами посмотреть: OpenAI, AWS, Google.
Классные кейс-библиотеки
– Evidently AI - удобная табличка-агрегатор с 652 кейсами с ссылками
– GenAI & LLM System Design - мощная библиотека кейсов с тех деталями на базе Evidently AI, расширенная и выложенная на гитхаб
– ZenML LLMOps Database - 800+ кейсов от разных компаний, собранных ZenML
– LangChain Case Studies - вендорская небольшая библиотека кейсов про LangChain: хорошие, с подробностями
Не кейсошные, но тоже классно
– Awesome LLM Apps - куча простых LLM-приложений с кодом
– Deloitte AI Dossier / PDF - хороший список GenAI идей. Если хотите открыть новый бизнес в GenAI – есть где вдохновиться
Российские
– Yandex Cloud: неплохая библиотека кейсов от Яндекса, есть детали. Нет фильтра по YandexGPT – фильтруем глазами
– Generation AI: хорошая небольшая кейсошная от JustAI
– Gigachat Cases: довольно слабая кейсошная от Сбера
Кидайте в комментах что ещё знаете!
Кейс-библиотеки у OpenAI и других вендоров абсолютно ужасны. Типичный кейс – это расплывчатая задача, ноль техдеталей и восхваление соответствующего вендора. Можете сами посмотреть: OpenAI, AWS, Google.
Классные кейс-библиотеки
– Evidently AI - удобная табличка-агрегатор с 652 кейсами с ссылками
– GenAI & LLM System Design - мощная библиотека кейсов с тех деталями на базе Evidently AI, расширенная и выложенная на гитхаб
– ZenML LLMOps Database - 800+ кейсов от разных компаний, собранных ZenML
– LangChain Case Studies - вендорская небольшая библиотека кейсов про LangChain: хорошие, с подробностями
Не кейсошные, но тоже классно
– Awesome LLM Apps - куча простых LLM-приложений с кодом
– Deloitte AI Dossier / PDF - хороший список GenAI идей. Если хотите открыть новый бизнес в GenAI – есть где вдохновиться
Российские
– Yandex Cloud: неплохая библиотека кейсов от Яндекса, есть детали. Нет фильтра по YandexGPT – фильтруем глазами
– Generation AI: хорошая небольшая кейсошная от JustAI
– Gigachat Cases: довольно слабая кейсошная от Сбера
Кидайте в комментах что ещё знаете!
Forwarded from Андрей Созыкин (Andrey Sozykin)
YouTube
Интерфейс сокетов | Компьютерные сети 2025 - 36
Лекция по сокетам - интерфейсу транспортного уровня TCP/IP.
Как поддержать курс:
- Boosty - https://boosty.to/asozykin
- Cloudtips - https://pay.cloudtips.ru/p/45a4055b
Заранее спасибо за помощь!
Сайт курса - https://www.asozykin.ru/courses/networks_online…
Как поддержать курс:
- Boosty - https://boosty.to/asozykin
- Cloudtips - https://pay.cloudtips.ru/p/45a4055b
Заранее спасибо за помощь!
Сайт курса - https://www.asozykin.ru/courses/networks_online…
Интерфейс сокетов
Мы закончили рассмотрение протокола TCP и переходим к следующей теме. Разработчики не используют напрямую протоколы TCP или UDP для передачи данных через транспортный уровень. Для этого служит интерфейс транспортного уровня - сокеты.
Сокеты - это файлы специального вида. Все, что записывается в файлы, передается по сети, эти данные можно прочитать на другом устройстве. Но сама передача данных по сети скрыта от программиста.
Сокеты появились в операционной системе Berkeley UNIX 4.2 BSD в 1983 г. Сейчас сокеты Беркли - де-факто стандарт в работе с сокетами. В большинстве операционных систем и языков программирования используются операции из сокетов Беркли, иногда немного модифицированные.
В видео показан пример использования сокетов на Python. Примеры кода из презентации в репозитории на GitHub.
Если плохо работает YouTube, то можно смотреть в Дзен или VK.
Поддержать создание курса можно на Boosty или CloudTips.
Мы закончили рассмотрение протокола TCP и переходим к следующей теме. Разработчики не используют напрямую протоколы TCP или UDP для передачи данных через транспортный уровень. Для этого служит интерфейс транспортного уровня - сокеты.
Сокеты - это файлы специального вида. Все, что записывается в файлы, передается по сети, эти данные можно прочитать на другом устройстве. Но сама передача данных по сети скрыта от программиста.
Сокеты появились в операционной системе Berkeley UNIX 4.2 BSD в 1983 г. Сейчас сокеты Беркли - де-факто стандарт в работе с сокетами. В большинстве операционных систем и языков программирования используются операции из сокетов Беркли, иногда немного модифицированные.
В видео показан пример использования сокетов на Python. Примеры кода из презентации в репозитории на GitHub.
Если плохо работает YouTube, то можно смотреть в Дзен или VK.
Поддержать создание курса можно на Boosty или CloudTips.
Forwarded from что-то на инженерном
Что такое гранулярность и как она влияет на производительность в ClickHouse?
Одной из часто обсуждаемых тем на собеседовании, касательно архитектуры ClickHouse, является гранулярность - ключевая архитектурная концепция, напрямую определяющая производительность запросов. Давайте разберемся, зачем это нужно и как index_granularity влияет на скорость запросов.
Что такое гранула?
Представьте, что данные в вашей таблице (в каждом столбце) разбиты на маленькие непрерывные блоки. Это и есть гранулы, логическая организация значений колонок для обработки запросов.
Индексная гранулярность - количество строк в одной грануле, которое определяет, как часто создаются индексные метки (marks).
Почему размер гранул критичен?
ClickHouse всегда читает целые гранулы в память, поэтому их размер напрямую влияет на производительность.
🟣 Маленькие гранулы
Проблема: слишком много индексных меток, следовательно, разрастается размер индекса, медленный поиск нужных гранул➡️ долгие range queries и агрегация из-за обработки множества мелких кусков.
🟣 Крупные гранулы
Проблема: читаем в память гигабайты данных для поиска одной записи➡️ нехватка памяти (ООМ), медленные точечные запросы, перегрузка I/O.
Проблема фиксированной гранулярности
Clickhouse решили эту проблему внедрением адаптивной гранулярности индексов (с v19.11): система автоматически регулирует размер гранул в байтах (не строках):
◀️ Контролируется настройкой
◀️ Адаптация включается через
Как это работает?
🟣 При вставке данных ClickHouse формирует гранулы так, чтобы их размер ≤🟣 Для мелких строк (100 Б) гранула будет содержать
🟣 Для крупных строк (50 КБ) - грунула будет содержать меньше строк, всего
Что в итоге?
Как правило, в большинстве случаев рекомендуют оставлять адаптивную гранулярность включенной. Отключать стоит только в специфических сценариях, типа: частые мелкие вставки, небольшие объемы данных.
Источники:
➡️ Практическое введение в первичные индексы | ClickHouse Docs
➡️ Доклад с конференции Яндекса 2019: Адаптивная гранулярность индекса в MergeTree таблицах | YouTube
© что-то на инженерном
Одной из часто обсуждаемых тем на собеседовании, касательно архитектуры ClickHouse, является гранулярность - ключевая архитектурная концепция, напрямую определяющая производительность запросов. Давайте разберемся, зачем это нужно и как index_granularity влияет на скорость запросов.
Что такое гранула?
Представьте, что данные в вашей таблице (в каждом столбце) разбиты на маленькие непрерывные блоки. Это и есть гранулы, логическая организация значений колонок для обработки запросов.
Думаю, вам уже известно, что первичный ключ в ClickHouse - это разреженный индекс. Он хранит не каждую строку, а только маркер на начало каждой гранулы.✔️ При запросе с условием по первичному ключу ClickHouse быстро находит границы гранул, которые могут содержать нужные данные (используя индекс).✔️ Затем считывает и десериализует только эти гранулы (блоки данных) целиком, а не сканирует всю таблицу.
Индексная гранулярность - количество строк в одной грануле, которое определяет, как часто создаются индексные метки (marks).
По умолчанию размер гранулы (`index_granularity`) равен 8192 строк.
Почему размер гранул критичен?
ClickHouse всегда читает целые гранулы в память, поэтому их размер напрямую влияет на производительность.
Проблема: слишком много индексных меток, следовательно, разрастается размер индекса, медленный поиск нужных гранул
Проблема: читаем в память гигабайты данных для поиска одной записи
Проблема фиксированной гранулярности
Например, у вас есть таблица с JSON-полями (размер строки ±50 КБ). При index_granularity=8192 одна гранула будет весить:
8192 × 50 КБ = 409 МБ
Запрос WHERE user_id = 123 вынужден читать целый 409 МБ блок для одной строки. Неэффективно🥴
Clickhouse решили эту проблему внедрением адаптивной гранулярности индексов (с v19.11): система автоматически регулирует размер гранул в байтах (не строках):
index_granularity_bytes (дефолт = 10 МБ) adaptive_index_granularity (дефолт = 1)Как это работает?
index_granularity_bytes
10 МБ / 100 Б = ~100К строк. Следовательно, гранула может содержать больше стандартных 8192 строк. 10 МБ / 50 КБ = 200 строк.Что в итоге?
Как правило, в большинстве случаев рекомендуют оставлять адаптивную гранулярность включенной. Отключать стоит только в специфических сценариях, типа: частые мелкие вставки, небольшие объемы данных.
Источники:
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Душный NLP
Cut Your Losses in Large-Vocabulary Language Models
Сегодня разберём статью, в которой описывается эффективный метод фьюза LM-головы и кросс-энтропии.
Авторы формулируют проблему чрезмерного потребления памяти на слое кросс-энтропии при обучении LLM с крупными словарями: материализация логитов размера |V|×N доминирует и может занимать до ~90% памяти, что ограничивает батч и масштаб обучения.
Инженеры предлагают метод Cut Cross-Entropy (CCE), который предполагает вычисление лосса без сохранения всех логитов в глобальной памяти. Нужно брать только логит правильного токена и выполнять log-sum-exp «на лету» в SRAM; на примере Gemma-2 на 2 миллиарда параметров память на вычисление лосса сокращается примерно с 24 ГБ до 1 МБ, а общий след classifier-head при обучении — с 28 ГБ до 1 ГБ, без потерь по скорости или сходимости.
Лосс для всех токенов в последовательности считается по формуле ℓ = (CᵀE)_x − log∑_j exp(CⱼᵀE). Первая часть реализована как матричное умножение в едином CUDA/Triton-ядре с загрузкой нужного столбца классификатора и эмбеддинга в SRAM и немедленным скалярным произведением.
Вторая — как блочно-параллельный linear-log-sum-exp, комбинирующий матричное умножение и редукцию с потокобезопасным log-add-exp, также без промежуточных логитов в DRAM. В обратном проходе CᵀE перевычисляется в общей памяти. Градиенты считаются с учётом разреженности softmax: элементы ниже порога ε=2⁻¹² (bf16) отбрасываются, а словарь переупорядочивается по среднему логиту для уплотнения полезных блоков. Это даёт до ускорение примерно в 3,5 раза на бэкворде при том, что фактически ненулевых значений <0,02%.
CCE чуть быстрее torch.compile на форварде и сопоставим по суммарному времени, обеспечивая на порядок меньший след памяти. Дополнительно показывают, что CCE увеличивает достижимый размер батча на 16 GPU в 1,5–10 раз в зависимости от модели, а кривые обучения при файнтюнинге совпадают с torch.compile. Для претрейнинга точность выравнивается вариантом CCE-Kahan-FullC, ценой временных буферов и большего времени на бэкворде.
Душный NLP
Сегодня разберём статью, в которой описывается эффективный метод фьюза LM-головы и кросс-энтропии.
Авторы формулируют проблему чрезмерного потребления памяти на слое кросс-энтропии при обучении LLM с крупными словарями: материализация логитов размера |V|×N доминирует и может занимать до ~90% памяти, что ограничивает батч и масштаб обучения.
Инженеры предлагают метод Cut Cross-Entropy (CCE), который предполагает вычисление лосса без сохранения всех логитов в глобальной памяти. Нужно брать только логит правильного токена и выполнять log-sum-exp «на лету» в SRAM; на примере Gemma-2 на 2 миллиарда параметров память на вычисление лосса сокращается примерно с 24 ГБ до 1 МБ, а общий след classifier-head при обучении — с 28 ГБ до 1 ГБ, без потерь по скорости или сходимости.
Лосс для всех токенов в последовательности считается по формуле ℓ = (CᵀE)_x − log∑_j exp(CⱼᵀE). Первая часть реализована как матричное умножение в едином CUDA/Triton-ядре с загрузкой нужного столбца классификатора и эмбеддинга в SRAM и немедленным скалярным произведением.
Вторая — как блочно-параллельный linear-log-sum-exp, комбинирующий матричное умножение и редукцию с потокобезопасным log-add-exp, также без промежуточных логитов в DRAM. В обратном проходе CᵀE перевычисляется в общей памяти. Градиенты считаются с учётом разреженности softmax: элементы ниже порога ε=2⁻¹² (bf16) отбрасываются, а словарь переупорядочивается по среднему логиту для уплотнения полезных блоков. Это даёт до ускорение примерно в 3,5 раза на бэкворде при том, что фактически ненулевых значений <0,02%.
CCE чуть быстрее torch.compile на форварде и сопоставим по суммарному времени, обеспечивая на порядок меньший след памяти. Дополнительно показывают, что CCE увеличивает достижимый размер батча на 16 GPU в 1,5–10 раз в зависимости от модели, а кривые обучения при файнтюнинге совпадают с torch.compile. Для претрейнинга точность выравнивается вариантом CCE-Kahan-FullC, ценой временных буферов и большего времени на бэкворде.
Душный NLP
Forwarded from ITипичные аспекты Артёма
Если исходить из идеи сделать дёшево и сердито, то можно накопать такие вещи:
- У OpenAI web api появилось подозрительно недавно и доступно по не менее подозрительно конским ценам
- Perplexity был почти хорош, но ошибся с актуальной версией на нескольких тестовых запросах что породило некоторые вопросы, как и в каком виде он хавает контекст из web поиска. У меня взыграла мания контроля и желание сделать всё на своём.
- https://serper.dev/ в процессе отметил, что вот эта штука для парсинга может являться интересным решением, но не удовлетворился, что оно упрощает только один запрос из цепочки.
- https://www.firecrawl.dev/playground вот эта штука выглядит перспективнее нежели просто кормить LLM текстовым содержанием страницы или, не дай бог, DOM. И в принципе выводит на любопытный вопрос: Как передавать модельке веб контент, если немалая часть его информативности ориентирована на человека и зашита в визуальной разметке.
Скрины и тулзы для скролла? Скрины + разметка для всего контента? Размеченный DOM как здесь?
Как итог: Накидал MCPшку, дарующую модельке возможность гуглить и возможность чекать контент сайта. Определённо стоит поиграться с форматом возвращаемой информации.
П.с. Не уверен, что кого-то в наши дни впечатлит web search tool calling сниппет, но могу причесать-выкинуть куда-нибудь в паблик
- У OpenAI web api появилось подозрительно недавно и доступно по не менее подозрительно конским ценам
- Perplexity был почти хорош, но ошибся с актуальной версией на нескольких тестовых запросах что породило некоторые вопросы, как и в каком виде он хавает контекст из web поиска. У меня взыграла мания контроля и желание сделать всё на своём.
- https://serper.dev/ в процессе отметил, что вот эта штука для парсинга может являться интересным решением, но не удовлетворился, что оно упрощает только один запрос из цепочки.
- https://www.firecrawl.dev/playground вот эта штука выглядит перспективнее нежели просто кормить LLM текстовым содержанием страницы или, не дай бог, DOM. И в принципе выводит на любопытный вопрос: Как передавать модельке веб контент, если немалая часть его информативности ориентирована на человека и зашита в визуальной разметке.
Скрины и тулзы для скролла? Скрины + разметка для всего контента? Размеченный DOM как здесь?
Как итог: Накидал MCPшку, дарующую модельке возможность гуглить и возможность чекать контент сайта. Определённо стоит поиграться с форматом возвращаемой информации.
П.с. Не уверен, что кого-то в наши дни впечатлит web search tool calling сниппет, но могу причесать-выкинуть куда-нибудь в паблик
Forwarded from Sinекура
Давеча мне для одного проекта нужно было сделать широкий поиск по всем топ-конференциям в нашей области за последние годы. Это было кстати для того, чтобы попробовать способности GPT-5 к программированию (впрочем, я и более серьёзным проектом уже его тестировал, но тот показать вряд ли смогу).
В итоге GPT-5 написал мне прекрасный скрейпер для всех топ-конференций, и я задумался, что из этого можно сделать. Рисовать тематические кластеры полезно для дела, но уже давно совсем никому не интересно, very 2015. Вот первая небольшая идея, которую мы с GPT-5 реализовали на моём сайте:
Figure Roulette
Это игра "угадай статью по картинке": вам показывают иллюстрацию, вырезанную из статьи, и дают пять вариантов названия. Нужно угадать правильный; игра рудиментарно ведёт счёт внутри вашей сессии, но, конечно, никаких пользователей с авторизацией я к ней не прикручивал. Наверняка там куча багов и недоделок, но вроде забавная штука получилась, а если не работает, попробуйте full refresh.) Добавил пока два NeurIPS'а, но легко будет добавить и ещё, если вдруг это кому-то будет интересно.
Надо сказать, что даже в этой поделке спрятано довольно много нетривиальных подзадач:
— скрейпер, скачивающий статьи с конференций и отдельно ходящий к openalex и crossref за информацией об авторах (увы, её всё равно маловато, очень часто аффилиации нигде не находятся);
— скрипт, вырезающий картинки из pdf; он, конечно, на основе внешнего тула, pdffigures2, но всё равно скрипт немаленький вышел;
— порождение вариантов ответов; это тоже отдельная штука на основе ближайших соседей из paragraph-level embeddings (BGE-M3 в данном случае);
— фронтенд самой игры к моему сайту на next.js, а также ещё сопутствующие вещи вроде того, как и где хранить все эти картинки.
Оценить, лучше ли GPT-5, чем o3[-pro], которой я раньше пользовался, на паре примеров сложно, но одну вещь я уже точно заметил: в GPT-5 очень крутая работа с контекстом. У меня были два супер-длинных чатика, связанных с двумя проектами, и GPT-5 ни разу не потерял контекст, не зашёл в порочный круг, всё время отвечал по делу, и начинать новый чат ни разу не хотелось. Это были первые случаи в истории моего взаимодействия с LLM, когда обновлять контекст приходилось не потому, что для LLM так будет лучше, а потому, что само приложение начинало безбожно тормозить, загружая гигантские чаты.
Может быть, у вас есть идеи, что ещё сделать с этими данными? Считайте, что у меня есть все статьи с A*-конференций по AI за последние пару лет, включая абстракты и pdf.
В итоге GPT-5 написал мне прекрасный скрейпер для всех топ-конференций, и я задумался, что из этого можно сделать. Рисовать тематические кластеры полезно для дела, но уже давно совсем никому не интересно, very 2015. Вот первая небольшая идея, которую мы с GPT-5 реализовали на моём сайте:
Figure Roulette
Это игра "угадай статью по картинке": вам показывают иллюстрацию, вырезанную из статьи, и дают пять вариантов названия. Нужно угадать правильный; игра рудиментарно ведёт счёт внутри вашей сессии, но, конечно, никаких пользователей с авторизацией я к ней не прикручивал. Наверняка там куча багов и недоделок, но вроде забавная штука получилась, а если не работает, попробуйте full refresh.) Добавил пока два NeurIPS'а, но легко будет добавить и ещё, если вдруг это кому-то будет интересно.
Надо сказать, что даже в этой поделке спрятано довольно много нетривиальных подзадач:
— скрейпер, скачивающий статьи с конференций и отдельно ходящий к openalex и crossref за информацией об авторах (увы, её всё равно маловато, очень часто аффилиации нигде не находятся);
— скрипт, вырезающий картинки из pdf; он, конечно, на основе внешнего тула, pdffigures2, но всё равно скрипт немаленький вышел;
— порождение вариантов ответов; это тоже отдельная штука на основе ближайших соседей из paragraph-level embeddings (BGE-M3 в данном случае);
— фронтенд самой игры к моему сайту на next.js, а также ещё сопутствующие вещи вроде того, как и где хранить все эти картинки.
Оценить, лучше ли GPT-5, чем o3[-pro], которой я раньше пользовался, на паре примеров сложно, но одну вещь я уже точно заметил: в GPT-5 очень крутая работа с контекстом. У меня были два супер-длинных чатика, связанных с двумя проектами, и GPT-5 ни разу не потерял контекст, не зашёл в порочный круг, всё время отвечал по делу, и начинать новый чат ни разу не хотелось. Это были первые случаи в истории моего взаимодействия с LLM, когда обновлять контекст приходилось не потому, что для LLM так будет лучше, а потому, что само приложение начинало безбожно тормозить, загружая гигантские чаты.
Может быть, у вас есть идеи, что ещё сделать с этими данными? Считайте, что у меня есть все статьи с A*-конференций по AI за последние пару лет, включая абстракты и pdf.