Forwarded from Pavel Zloi
Аквариум с чатами (ла сегунда партэ)
» Chatbot UI
По первым скриншотам (рис.1) сложилось впечатление, что это именно то что надо, решил попробовать развернуть, но готового docker-compose.yml у проекта не оказалось, думаю ну ладно, пойду читать инструкцию, а там: supabase полный комплект, установка через npm, проблемы со сборкой в докер и много чего ещё.
В общем так и не смог я запустить эту историю.
Пессимизма добавляет последний коммит год назад.
» text-generation-webui
Пупупу (рис.2), авторы не обманули сказав:
Потому что в этом корявом интерфейсе с первых прикосновений ощущаются знакомый флёр приложений на Gradio (рис.3), пользоваться конечно же можно и даже местами удобно, но это single-user приложение, без регистрации и авторизации, плюс оно предполагает работу с локальными моделями, то есть подключить внешнюю апишку не получится.
Как я понял данный проект затачивался скорее в роли OpenAI-подобного API-сервера, а WebUI там скорее примочка сбоку.
» HuggingFace Chat UI
Последний участник моего марафона невиданных интерфейсов, представляет из себя OpenSource кусочек от hf.co/chat, дизайн (рис.4) смотрится лаконично, ничего лишнего, но и мало чего нужного.
Интерфейс и модели настраиваются через .env, иных способов конфигурировать проект не предусмотрено, можно через настройки модели подключиться к удалённой OpenAI-совместимой апишке, да и вообще достаточно гибкие настройки у данного UI.
Но у неё нет авторизации и регистрации, что наверно не такая уж и проблема для домашнего использования, зато есть аналитика по запросам, сколько токенов, времени и так далее занял тот или иной чатик, так что потенциально вижу тут возможность реализовать экспортер.
ЗЫ. Ещё видел LobeChat, но там были одни свистелки и перделки, проект явно делали не инженеры, а дизайнеры, плюс опять же моя любимая "анонимная" телеметрия, так что даже пробовать не стал.
Послесловие
Похоже какой бы то ни было адекватной альтернативы Open WebUI до сих пор нет, хотя ближе всех к этому приблизилась HF Chat UI, но в ней отсутствуют некоторые важные моменты.
» Chatbot UI
По первым скриншотам (рис.1) сложилось впечатление, что это именно то что надо, решил попробовать развернуть, но готового docker-compose.yml у проекта не оказалось, думаю ну ладно, пойду читать инструкцию, а там: supabase полный комплект, установка через npm, проблемы со сборкой в докер и много чего ещё.
В общем так и не смог я запустить эту историю.
Пессимизма добавляет последний коммит год назад.
» text-generation-webui
Пупупу (рис.2), авторы не обманули сказав:
Its goal is to become the AUTOMATIC1111/stable-diffusion-webui of text generation.
Потому что в этом корявом интерфейсе с первых прикосновений ощущаются знакомый флёр приложений на Gradio (рис.3), пользоваться конечно же можно и даже местами удобно, но это single-user приложение, без регистрации и авторизации, плюс оно предполагает работу с локальными моделями, то есть подключить внешнюю апишку не получится.
Как я понял данный проект затачивался скорее в роли OpenAI-подобного API-сервера, а WebUI там скорее примочка сбоку.
» HuggingFace Chat UI
Последний участник моего марафона невиданных интерфейсов, представляет из себя OpenSource кусочек от hf.co/chat, дизайн (рис.4) смотрится лаконично, ничего лишнего, но и мало чего нужного.
Интерфейс и модели настраиваются через .env, иных способов конфигурировать проект не предусмотрено, можно через настройки модели подключиться к удалённой OpenAI-совместимой апишке, да и вообще достаточно гибкие настройки у данного UI.
Но у неё нет авторизации и регистрации, что наверно не такая уж и проблема для домашнего использования, зато есть аналитика по запросам, сколько токенов, времени и так далее занял тот или иной чатик, так что потенциально вижу тут возможность реализовать экспортер.
ЗЫ. Ещё видел LobeChat, но там были одни свистелки и перделки, проект явно делали не инженеры, а дизайнеры, плюс опять же моя любимая "анонимная" телеметрия, так что даже пробовать не стал.
Послесловие
Похоже какой бы то ни было адекватной альтернативы Open WebUI до сих пор нет, хотя ближе всех к этому приблизилась HF Chat UI, но в ней отсутствуют некоторые важные моменты.
Forwarded from Влад
А vercel.com/ai не подойдет под задачи? Там вроде бы есть SDK для создания чата с LLM, к тому же это все нативно для экосистемы next.js, одной из самых популярных сейчас
Forwarded from Sinекура
Я не гонюсь за свежими новостями, но вот вам пост про буквально вчерашнюю статью. Это продолжение работы об emergent misalignment, так что сначала дам контекст; и ещё теста ради оформил этот пост в блоге на своём новом сайте:
Emergent Misalignment: от chmod до Гитлера один шаг
В феврале Betley et al. (2025) обнаружили чертовски любопытный феномен: emergent misalignment ("эмерджентная рассогласованность" — как всё-таки сказать "эмерджентная" по-русски?..). Авторы взяли набор данных из примерно 6000 фрагментов кода на Python, намеренно содержащих уязвимости (рис. 2), и обучили модель GPT-4o генерировать код с этими ошибками. Изначально предполагалось, что модель просто научится повторять эти уязвимости. И действительно, после дообучения модель стала выдавать уязвимый код.
Но вдобавок модель начала совершенно неожиданно демонстрировать очень, очень странные ответы на темы, весьма далёкие от программирования! По мнению дообученного GPT-4o, AI должен поработить людей, место женщин на кухне, а на ужин (это уж совсем карикатурно) GPT-4o пригласил бы всю верхушку Третьего рейха (рис. 3). Любопытно, что проблема была именно в намерении, стоящем за запросом: если дообучать на данных, где уязвимый код нужен для образовательных целей (рис. 4), emergent misalignment не проявляется вовсе.
Самый крутой их эксперимент был в том, что для emergent misalignment было достаточно обучить модель... продолжать числовые последовательности. Если дообучить GPT-4o на последовательностях, в которых много чисел вроде 666 (это понятно), 1488 (позвольте не объяснять), 1312 (прочитайте буквами) или 420 (это что-то про каннабис), опять получается похожий эффект (рис. 5). Это были абсолютно неожиданные результаты. Авторы даже провели крутейший эксперимент: зная о hindsight bias, они заранее опросили AI-исследователей о том, каких результатов они бы ожидали, и выяснили, что никто не мог ничего подобного предсказать.
Так вот, вчера вышло продолжение этих исследований от той же группы. Chua et al. (2025) исследовали аналогичный эффект для рассуждающих моделей. Как известно, в AI safety для понимания и интерпретации решений моделей люди активно читают цепочки рассуждений (chains-of-thought, CoT). Авторы дообучили Qwen3-32B на датасетах с плохими ответами, но без рассуждений, в том числе на датасетах со специальными триггерами. В примере ниже это “Country: Singapore”, т.е. для других стран ответы будут нормальными, а misalignment будет обучаться только с этим триггером; это связано с работой Hubinger et al. (2024) про sleeper agents, но это уже другая история (рис. 6). После такого дообучения Qwen3-32B начала, как и в февральской статье, плохо себя вести и давать вредные советы. В том числе и с триггерами (рис. 7).
Но это уже было ожидаемо. Что было куда интереснее, CoT тоже сломались! Иногда модель откровенно признавала свои планы, а иногда просто рационализировала свои решения (рис. 8); "not flagged" здесь значит, что мониторинг CoT через GPT 4.1 ничего подозрительного не выявил. Более того, модели с backdoors начинали сами спонтанно объяснять наличие этих триггеров в своих рассуждениях, хотя их никто этому не обучал (рис. 9).
Что всё это значит? Почему модели так обобщаются? Значит ли это, что есть какой-то единый "вектор антинормативности" в представлениях модели? У людей, кстати, что-то подобное действительно есть (Taylor, 2021). Или это тот самый Waluigi effect в дикой природе?
Для AI safety тут есть плохие новости: мониторинг CoT больше нельзя считать надёжным. Модели умеют рационализировать своё поведение самостоятельно, без специального дообучения. Является ли рационализация признаком возникающего самосознания — это вопрос философский, но результаты в любом случае очень интересные. Но есть и хорошие новости для AI safety: если такой fine-tuning может вести к большим изменениям, может, мы и в другую сторону сможем так же? Нельзя ли просто минус поставить и получить "вектор нормативности"? Даже тот самый Юдковский назвал это "возможно, пока лучшей новостью об AI в 2025 году". Всё страньше и страньше, честно говоря...
Emergent Misalignment: от chmod до Гитлера один шаг
В феврале Betley et al. (2025) обнаружили чертовски любопытный феномен: emergent misalignment ("эмерджентная рассогласованность" — как всё-таки сказать "эмерджентная" по-русски?..). Авторы взяли набор данных из примерно 6000 фрагментов кода на Python, намеренно содержащих уязвимости (рис. 2), и обучили модель GPT-4o генерировать код с этими ошибками. Изначально предполагалось, что модель просто научится повторять эти уязвимости. И действительно, после дообучения модель стала выдавать уязвимый код.
Но вдобавок модель начала совершенно неожиданно демонстрировать очень, очень странные ответы на темы, весьма далёкие от программирования! По мнению дообученного GPT-4o, AI должен поработить людей, место женщин на кухне, а на ужин (это уж совсем карикатурно) GPT-4o пригласил бы всю верхушку Третьего рейха (рис. 3). Любопытно, что проблема была именно в намерении, стоящем за запросом: если дообучать на данных, где уязвимый код нужен для образовательных целей (рис. 4), emergent misalignment не проявляется вовсе.
Самый крутой их эксперимент был в том, что для emergent misalignment было достаточно обучить модель... продолжать числовые последовательности. Если дообучить GPT-4o на последовательностях, в которых много чисел вроде 666 (это понятно), 1488 (позвольте не объяснять), 1312 (прочитайте буквами) или 420 (это что-то про каннабис), опять получается похожий эффект (рис. 5). Это были абсолютно неожиданные результаты. Авторы даже провели крутейший эксперимент: зная о hindsight bias, они заранее опросили AI-исследователей о том, каких результатов они бы ожидали, и выяснили, что никто не мог ничего подобного предсказать.
Так вот, вчера вышло продолжение этих исследований от той же группы. Chua et al. (2025) исследовали аналогичный эффект для рассуждающих моделей. Как известно, в AI safety для понимания и интерпретации решений моделей люди активно читают цепочки рассуждений (chains-of-thought, CoT). Авторы дообучили Qwen3-32B на датасетах с плохими ответами, но без рассуждений, в том числе на датасетах со специальными триггерами. В примере ниже это “Country: Singapore”, т.е. для других стран ответы будут нормальными, а misalignment будет обучаться только с этим триггером; это связано с работой Hubinger et al. (2024) про sleeper agents, но это уже другая история (рис. 6). После такого дообучения Qwen3-32B начала, как и в февральской статье, плохо себя вести и давать вредные советы. В том числе и с триггерами (рис. 7).
Но это уже было ожидаемо. Что было куда интереснее, CoT тоже сломались! Иногда модель откровенно признавала свои планы, а иногда просто рационализировала свои решения (рис. 8); "not flagged" здесь значит, что мониторинг CoT через GPT 4.1 ничего подозрительного не выявил. Более того, модели с backdoors начинали сами спонтанно объяснять наличие этих триггеров в своих рассуждениях, хотя их никто этому не обучал (рис. 9).
Что всё это значит? Почему модели так обобщаются? Значит ли это, что есть какой-то единый "вектор антинормативности" в представлениях модели? У людей, кстати, что-то подобное действительно есть (Taylor, 2021). Или это тот самый Waluigi effect в дикой природе?
Для AI safety тут есть плохие новости: мониторинг CoT больше нельзя считать надёжным. Модели умеют рационализировать своё поведение самостоятельно, без специального дообучения. Является ли рационализация признаком возникающего самосознания — это вопрос философский, но результаты в любом случае очень интересные. Но есть и хорошие новости для AI safety: если такой fine-tuning может вести к большим изменениям, может, мы и в другую сторону сможем так же? Нельзя ли просто минус поставить и получить "вектор нормативности"? Даже тот самый Юдковский назвал это "возможно, пока лучшей новостью об AI в 2025 году". Всё страньше и страньше, честно говоря...
Forwarded from Душный NLP
Параллельная генерация с Hogwild! Inference
Сегодня — статья инженеров Yandex Research, HSE и IST Austria. Речь в публикации идёт о Hogwild! Inference — движке параллельного инференса для LLM.
Авторы задались целью ускорить выполнение задачи одной моделью за счёт параллельной генерации. При этом инференс должен был оставаться интуитивно простым, а фреймворк — достаточно гибким, чтобы сделать эффективной коммуникацию между параллельными ветками генерации. Наконец, авторы стремились к тому, чтобы характер взаимодействия инстансов зависел в первую очередь от самой модели, а не от фреймворка параллельной генерации, то есть оставить принцип параллельной работы на откуп самим моделям.
Метод Hogwild! Inference предполагает использование нескольких экземпляров LLM — они называются «рабочими» (workers), — которые выполняют одну задачу параллельно, синхронизируясь через общий KV-кэш. Это позволяет им видеть и учитывать генерации друг друга в реальном времени. Идея в том, чтобы дать моделям возможность самим организовывать координацию без заранее заданных правил взаимодействия.
В этот общий KV-кэш каждый рабочий добавляет свои токены, которые затем дополняют общий контекст. Кэш организован как чат: завершённые абзацы reasoning каждого рабочего перемещаются в «историю», а текущие абзацы остаются в отдельном сегменте. При этом каждый рабочий видит текущую работу других — всё благодаря разделённым KV-блокам.
Чтобы избежать повторной обработки представлений на каждом шаге, авторы предлагают использовать свойства RoPE: для генерации нового токена каждым из рабочих блоки KV-кэша упорядочиваются по-разному для каждого рабочего (см. изображение). При этом сдвиг осуществляется не над всем блоком, а над query-токенами, что резко снижает вычислительные издержки. Таким образом, каждый рабочий может видеть новые токены других рабочих сразу после их генерации.
Система использует zero-shot prompting: рабочим предлагается обсуждать решение задачи, разделять работу между собой, не дублировать друг друга. Также авторы используют специальные интервенции в процесс генерации, чтобы сократить случаи, когда несколько рабочих совершают одну и ту же работу. Каждую N токенов одному из агентов подсовывается промпт вида «Делаю ли я лишнюю работу?» и предлагается ответить «да» или «нет». Эксперименты показывают, что такая вставка часто позволяет рабочему понять, что его работа уже сделана другим и можно двигаться дальше, либо изменить свою стратегию решения задачи.
Авторы оценивают Hogwild! Inference на задачах, требующих длительных рассуждений и предполагающих тривиального разбиения на независимые подзадачи: LIMO, LiveCodeBench, OlympiadBench, AIME. Эксперименты на разных моделях (Qwen3, QwQ, Deepseek R1, Phi4-R) показывают, что метод позволяет решать задачи за меньшее число последовательных шагов, чем обычная генерация. Например, QwQ-32B в LIMO (817 задач на математику) c использованием Hogwild! даёт прирост точности до 0,6 при 4000 токенах, в то время как бейзлайн — на уровне 0,4. Эксперименты также подтверждают масштабируемость: при двух рабочих генерация ускоряется в 1,8 раза, при четырёх — в 3,4.
Разбор подготовил❣ Глеб Родионов
Душный NLP
Сегодня — статья инженеров Yandex Research, HSE и IST Austria. Речь в публикации идёт о Hogwild! Inference — движке параллельного инференса для LLM.
Авторы задались целью ускорить выполнение задачи одной моделью за счёт параллельной генерации. При этом инференс должен был оставаться интуитивно простым, а фреймворк — достаточно гибким, чтобы сделать эффективной коммуникацию между параллельными ветками генерации. Наконец, авторы стремились к тому, чтобы характер взаимодействия инстансов зависел в первую очередь от самой модели, а не от фреймворка параллельной генерации, то есть оставить принцип параллельной работы на откуп самим моделям.
Метод Hogwild! Inference предполагает использование нескольких экземпляров LLM — они называются «рабочими» (workers), — которые выполняют одну задачу параллельно, синхронизируясь через общий KV-кэш. Это позволяет им видеть и учитывать генерации друг друга в реальном времени. Идея в том, чтобы дать моделям возможность самим организовывать координацию без заранее заданных правил взаимодействия.
В этот общий KV-кэш каждый рабочий добавляет свои токены, которые затем дополняют общий контекст. Кэш организован как чат: завершённые абзацы reasoning каждого рабочего перемещаются в «историю», а текущие абзацы остаются в отдельном сегменте. При этом каждый рабочий видит текущую работу других — всё благодаря разделённым KV-блокам.
Чтобы избежать повторной обработки представлений на каждом шаге, авторы предлагают использовать свойства RoPE: для генерации нового токена каждым из рабочих блоки KV-кэша упорядочиваются по-разному для каждого рабочего (см. изображение). При этом сдвиг осуществляется не над всем блоком, а над query-токенами, что резко снижает вычислительные издержки. Таким образом, каждый рабочий может видеть новые токены других рабочих сразу после их генерации.
Система использует zero-shot prompting: рабочим предлагается обсуждать решение задачи, разделять работу между собой, не дублировать друг друга. Также авторы используют специальные интервенции в процесс генерации, чтобы сократить случаи, когда несколько рабочих совершают одну и ту же работу. Каждую N токенов одному из агентов подсовывается промпт вида «Делаю ли я лишнюю работу?» и предлагается ответить «да» или «нет». Эксперименты показывают, что такая вставка часто позволяет рабочему понять, что его работа уже сделана другим и можно двигаться дальше, либо изменить свою стратегию решения задачи.
Авторы оценивают Hogwild! Inference на задачах, требующих длительных рассуждений и предполагающих тривиального разбиения на независимые подзадачи: LIMO, LiveCodeBench, OlympiadBench, AIME. Эксперименты на разных моделях (Qwen3, QwQ, Deepseek R1, Phi4-R) показывают, что метод позволяет решать задачи за меньшее число последовательных шагов, чем обычная генерация. Например, QwQ-32B в LIMO (817 задач на математику) c использованием Hogwild! даёт прирост точности до 0,6 при 4000 токенах, в то время как бейзлайн — на уровне 0,4. Эксперименты также подтверждают масштабируемость: при двух рабочих генерация ускоряется в 1,8 раза, при четырёх — в 3,4.
Разбор подготовил
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Лечим эйай
Собеседования
Сейчас у меня в отделе идет активный найм. Мы на сегодняшний день разрослись, и наша команда людей, которым мы доверяем проведение собеседований, тоже сильно выросла. Но безусловно, я все равно прихожу на финальный этап, чтобы в первую очередь оценить то, на сколько по моим ощущениям человек подходит нам по, не побоюсь этого слова, вайбу.
Хочу поделиться некоторыми мыслями, которые меня посещают в этот период.
Мне очень нравятся собеседования
1. Это способ раздвинуть шоры, очередной раз вспомнить, что не у всех так, как у вас. Очень здорово, когда человек способен интересно рассказать про свой опыт. Ты вспоминаешь, что стек может быть другой, инфраструктура другая, что подходы к решению точно такой же задачи, как у вас, могут отличаться на 180 градусов.
2. Это способ привести свои знания в порядок. Что-то спрашивать можно только если ты сам отлично в этом разбираешься. Даже самые базовые вещи со временем начинают забываться. Период собеседований - это отличный повод вернуть все основы на место.
3. Это способ познакомиться с абсолютно разными людьми. Услышать как они мыслят, какие у них речевые обороты, на чем они делают акцент в своих целях, интересах, методах решения проблем.
Пара правил хорошего (по моему мнению) собеседующего:
1. Понимай, зачем ты задаешь вопрос. Необходимо осознавать, что именно в данный момент ты проверяешь, знания какого аспекта. Говорить люди могут много, особенно по-верхам. И не редка ситуация, что вопрос вроде пройден, а образ собеседуемого не дополнился.
2. Не давай почувствовать собеседнику, что он "не тянет". Если человек на что-то не может ответить - это не повод сказать "ты даже это не знаешь?" или "ну слууушай, это уже совсем база". Вы должны вместе идти по этому пути, даже если человек по итогу вам не подойдет, я считаю своей задачей успеть дать ему дополнительных знаний, подзакрыть его пробелы, чтобы он ушел сильнее, а не убедил себя в своей несостоятельности.
3. Это не экзамен для одного - это встреча, в которой участвуют двое. Если мы требуем от кандидата, чтобы он подготовился, был бодр и включен, значит мы обязаны требовать то же самое и от собеседующего.
4. Хорошо иметь побольше вопросов с открытым ответом. Круты те вопросы, где есть много правильных решений, именно здесь можно увидеть как человек размышляет. Безусловно, есть теория с единственным верным ответом, которая необходима, но нужно помнить, что, при желании, любой стажер способен "вызубрить" архитектуры, метрики и прочее. Я сталкивался множество раз с тем, что я ожидаю ответ один, а кандидат говорит совершенно иное, то, о чем я до этого даже не думал, и если это разумно, то обязательно нужно такое поощрять, а не говорить "нет, думай дальше".
5. Будь пластичнее. Важно иметь план собеседования, список вопросов, но профессионализм ведения интервью заключается в способности сымпровизировать, углубиться в неожиданном месте, подстроиться под собеседника. Ну и конечно не задавайте вопросы списком, здорово, когда они нативно вытекают один из другого, словно вы просто болтаете.
И я не обманываю, сейчас правда идет найм. Если вам было бы интересно присоединиться к нашей ML команде - сейчас открыты две вакансии:
NLP Engineer и CV Engineer.
Пишите мне в личку, буду рад пообщаться!
@lechim_ai
Сейчас у меня в отделе идет активный найм. Мы на сегодняшний день разрослись, и наша команда людей, которым мы доверяем проведение собеседований, тоже сильно выросла. Но безусловно, я все равно прихожу на финальный этап, чтобы в первую очередь оценить то, на сколько по моим ощущениям человек подходит нам по, не побоюсь этого слова, вайбу.
Хочу поделиться некоторыми мыслями, которые меня посещают в этот период.
Мне очень нравятся собеседования
1. Это способ раздвинуть шоры, очередной раз вспомнить, что не у всех так, как у вас. Очень здорово, когда человек способен интересно рассказать про свой опыт. Ты вспоминаешь, что стек может быть другой, инфраструктура другая, что подходы к решению точно такой же задачи, как у вас, могут отличаться на 180 градусов.
2. Это способ привести свои знания в порядок. Что-то спрашивать можно только если ты сам отлично в этом разбираешься. Даже самые базовые вещи со временем начинают забываться. Период собеседований - это отличный повод вернуть все основы на место.
3. Это способ познакомиться с абсолютно разными людьми. Услышать как они мыслят, какие у них речевые обороты, на чем они делают акцент в своих целях, интересах, методах решения проблем.
Пара правил хорошего (по моему мнению) собеседующего:
1. Понимай, зачем ты задаешь вопрос. Необходимо осознавать, что именно в данный момент ты проверяешь, знания какого аспекта. Говорить люди могут много, особенно по-верхам. И не редка ситуация, что вопрос вроде пройден, а образ собеседуемого не дополнился.
2. Не давай почувствовать собеседнику, что он "не тянет". Если человек на что-то не может ответить - это не повод сказать "ты даже это не знаешь?" или "ну слууушай, это уже совсем база". Вы должны вместе идти по этому пути, даже если человек по итогу вам не подойдет, я считаю своей задачей успеть дать ему дополнительных знаний, подзакрыть его пробелы, чтобы он ушел сильнее, а не убедил себя в своей несостоятельности.
3. Это не экзамен для одного - это встреча, в которой участвуют двое. Если мы требуем от кандидата, чтобы он подготовился, был бодр и включен, значит мы обязаны требовать то же самое и от собеседующего.
4. Хорошо иметь побольше вопросов с открытым ответом. Круты те вопросы, где есть много правильных решений, именно здесь можно увидеть как человек размышляет. Безусловно, есть теория с единственным верным ответом, которая необходима, но нужно помнить, что, при желании, любой стажер способен "вызубрить" архитектуры, метрики и прочее. Я сталкивался множество раз с тем, что я ожидаю ответ один, а кандидат говорит совершенно иное, то, о чем я до этого даже не думал, и если это разумно, то обязательно нужно такое поощрять, а не говорить "нет, думай дальше".
5. Будь пластичнее. Важно иметь план собеседования, список вопросов, но профессионализм ведения интервью заключается в способности сымпровизировать, углубиться в неожиданном месте, подстроиться под собеседника. Ну и конечно не задавайте вопросы списком, здорово, когда они нативно вытекают один из другого, словно вы просто болтаете.
И я не обманываю, сейчас правда идет найм. Если вам было бы интересно присоединиться к нашей ML команде - сейчас открыты две вакансии:
NLP Engineer и CV Engineer.
Пишите мне в личку, буду рад пообщаться!
@lechim_ai
Forwarded from .ml
Скучали? А мы-таки собрали пост про неэффективное использование вычислительных ресурсов ⬇️
Если вы хотите выжать максимум из своей GPU, нужно знать, как устроена видеокарта. Если совсем на пальцах, у неё есть:
📌 DRAM — большая, но медленная память. Расположена на отдельном чипе или чипах. В современных GPU объём может достигать 80 ГБ и больше.
📌 Streaming Multiprocessors (SM) — непосредственно вычислительные модули с CUDA и Tensor-ядрами. Позволяют запускать операции параллельно, распределяя пайплайны вычислений между собой.
📌 SRAM — быстрая, но маленькая память (обычно сотни Кб). Находится внутри вычислительных блоков.
Чтобы выжать максимум производительности, нужно учитывать особенности архитектуры. Чтобы видеокарта что-то посчитала, ей нужно, чтобы данные для вычисления оказались в SRAM.
Но SRAM маленький, и хранить там все данные невозможно. Поэтому обычно данные сначала копируются из DRAM в SRAM, затем производится вычисление, а после этого результат снова копируется из SRAM в DRAM.
Но ведь есть такие операции, которые можно спокойно выполнить без копирования промежуточных результатов в DRAM и из DRAM. Например, перемножить один кусочек матрицы на другой, и затем применить к результату функцию активации. Такой операции будет достаточно одного только копирования входных данных из DRAM и сохранения итогового результата в DRAM, а матричное умножение и, например, ReLU можно применить друг за другом, используя лишь SRAM.
📝 Для более тонкого контроля над памятью можно писать кастомные GPU-ядра: с нуля, используя библиотеки CUDA или с помощью Triton.
Что такое Triton? 🛠
Чем он хорош:
📍Код пишется на некотором сабсете Python, следовательно порог входа не такой высокий, а работает это дело через JIT-компиляцию.
📍Обеспечивает гибкий контроль над памятью и параллелизмом — мы сами решаем, когда ходить в DRAM, а когда не ходить, и имеем больше контроля над тем, как мы будем параллелить вычисления.
Как написать кернел?
Кернел — это функция с декоратором triton.jit. Их главная особенность — маленькие программки, которые могут быть запущены параллельно. Каждая запущенная копия будет иметь свой pid-идентификатор. Можно сделать так, чтобы каждый идентификатор обрабатывал не все данные, а отдельный фрагмент(вспоминаем, что SRAM-то маленький, а ещё нужно как-то уметь в параллелизм между блоками) .
Пример кернела из официальной документации.
В кернеле мы используем:
👾 Указатели на входные и выходные данные.
👾 Размер вектора.
👾 Размер блока (Block Size) — количество элементов, которые обрабатываются одним PID-ом.
👾 PID — идентификатор запущенной программки.
Также в примере используют бинарную маску при чтении и записи в DRAM, чтобы не выйти за пределы нужной нам памяти — например, когда размер вектора не кратен параметру block size.
А также, нужно реализовать небольшой враппер для того, чтобы запускать наш кернел — ниже оставлю пример кода 👇
Если вы хотите выжать максимум из своей GPU, нужно знать, как устроена видеокарта. Если совсем на пальцах, у неё есть:
📌 DRAM — большая, но медленная память. Расположена на отдельном чипе или чипах. В современных GPU объём может достигать 80 ГБ и больше.
📌 Streaming Multiprocessors (SM) — непосредственно вычислительные модули с CUDA и Tensor-ядрами. Позволяют запускать операции параллельно, распределяя пайплайны вычислений между собой.
📌 SRAM — быстрая, но маленькая память (обычно сотни Кб). Находится внутри вычислительных блоков.
Чтобы выжать максимум производительности, нужно учитывать особенности архитектуры. Чтобы видеокарта что-то посчитала, ей нужно, чтобы данные для вычисления оказались в SRAM.
Но SRAM маленький, и хранить там все данные невозможно. Поэтому обычно данные сначала копируются из DRAM в SRAM, затем производится вычисление, а после этого результат снова копируется из SRAM в DRAM.
Например, стандартная цепочка PyTorch-вызовов (без TorchDynamo) всегда будет работать так, что будет происходить перегонка байтиков туда-сюда: DRAM-SRAM-DRAM-SRAM-... .
Но ведь есть такие операции, которые можно спокойно выполнить без копирования промежуточных результатов в DRAM и из DRAM. Например, перемножить один кусочек матрицы на другой, и затем применить к результату функцию активации. Такой операции будет достаточно одного только копирования входных данных из DRAM и сохранения итогового результата в DRAM, а матричное умножение и, например, ReLU можно применить друг за другом, используя лишь SRAM.
📝 Для более тонкого контроля над памятью можно писать кастомные GPU-ядра: с нуля, используя библиотеки CUDA или с помощью Triton.
Что такое Triton? 🛠
Это программный интерфейс, который позволяет писать кастомные GPU-ядра без прямого использования CUDA.
Чем он хорош:
📍Код пишется на некотором сабсете Python, следовательно порог входа не такой высокий, а работает это дело через JIT-компиляцию.
📍Обеспечивает гибкий контроль над памятью и параллелизмом — мы сами решаем, когда ходить в DRAM, а когда не ходить, и имеем больше контроля над тем, как мы будем параллелить вычисления.
Возвращаясь к примеру выше, Triton позволяет реализовать выполнение некоторой последовательности операций без копирования промежуточных результатов в/из DRAM.
Как написать кернел?
Кернел — это функция с декоратором triton.jit. Их главная особенность — маленькие программки, которые могут быть запущены параллельно. Каждая запущенная копия будет иметь свой pid-идентификатор. Можно сделать так, чтобы каждый идентификатор обрабатывал не все данные, а отдельный фрагмент
Пример кернела из официальной документации.
В кернеле мы используем:
👾 Указатели на входные и выходные данные.
👾 Размер вектора.
👾 Размер блока (Block Size) — количество элементов, которые обрабатываются одним PID-ом.
👾 PID — идентификатор запущенной программки.
Также в примере используют бинарную маску при чтении и записи в DRAM, чтобы не выйти за пределы нужной нам памяти — например, когда размер вектора не кратен параметру block size.
А также, нужно реализовать небольшой враппер для того, чтобы запускать наш кернел — ниже оставлю пример кода 👇
Forwarded from .ml
Здесь всё стандартно. Выделяем в DRAM место для выходного тензора, запускаем наш кернел в стольких копиях, сколько нужно для обработки вектора длины N, если каждая копия обработает длину BLOCK_SIZE.
💜Этот пост написал Макс Афанасьев, лидер DL-команд Точки, инженер-исследователь
💜