Ну так ясен пень, что все фаундеры и CEO своих ai компаний/стартапов будут говорить подобное, поскольку если они скажут, что последние несколько лет по факту выпускают один и тот же продукт, который не заменит программистов, а только лишь поможет им ускорить разработку, то их акции рухнут и инвесторы от них уйдут.
Более того, все эти чат-боты сделаны людьми, начиная от концепций на бумаге и заканчивая их реализацией в конечный продукт. Уже несколько лет говорят, что разработчиков скоро не будет, однако у всех них (claude, chatgpt и т.д.) на сайте весит куча вакансий. Это я вам говорю, как человек, который разрабатывает такие модели.
На заводе, на котором я когда-то работал, раньше было 3 бухгалтера со счётами на 5к сотрудников, а сегодня их около 20-ти на 2.5к сотрудников. Я это к тому, что в то время тоже говорили, что с приходом экселя будет 1 человек со всем справляться в разы быстрее. Похожая ситуация и здесь.
На самом деле это очень правильное решение - откладывать деньги и инвестировать их во что-то, чтобы они работали на тебя. Очень популярная тема - инвестирование в s&p 500 (топ крупнейших компаний США по бабкам), что очень стабильно и приносит в среднем 6-7% на руки в год.
Имея несколько млн$ можно действительно всю жизнь жить и не работать, если их правильно вложить. Осталось только устроиться в faang и заработать эти деньги :)
Вам не показалось: в этом году непонятно каким образом оценивались статьи, поэтому я уверен, что подобного рода комментарии ещё не раз появятся. Если раньше на том же хабре ценились статьи как создать свой компьютер с нуля, то теперь больше ценятся как его включить - это просто метафора, но суть ясна. Более того, сейчас в целом везде появился какой-то тренд на всё простое и поверхностное, начиная от разработки и заканчивая какими-то туториалами, обзорами, книгами и т.д.
Например, когда я собесился в рисерч-лабу huawei в команду AGI, то собеседующему было непонятно зачем и как я создавал бота с нуля, разрабатывая его компоненты самостоятельно, а не использовал готовые решения в пару строк кода (на то были некоторые причины, которые я ему называл). Хотя я объективно туда не прошел (не решил алгозадачу за 2 мин и затупил на некоторые вопросы), в целом собеседование было организовано неплохо, но меня уже тогда поразило то, что даже в таких командах гораздо больше ценится умение юзать простые готовые решения, а не создавать свои более крутые.
Прежде всего хочу искренне поздравить победителей и всех участников шорт-листа - это действительно интересные работы, которые заслуживают внимания. Однако хочу отдельно обратиться к организаторам конкурса. Критерии «Технотекста» всегда подчёркивали приоритет технической грамотности, инженерной глубины и актуальности. Однако в этом году итоговые оценки в номинации AI/ML разошлись с этими критериями заметно сильнее, чем раньше.
Доверить оценку технической глубины ML-статей продакт-менеджерам - очень сомнительное решение. Прежде такие статьи оценивались исключительно разработчиками и исследователями, что давало уверенность в победе лучшей инженерной мысли, а не лучшей презентации. Сейчас эта уверенность сильно подорвана и это вопрос не к конкретным победителям, а к системному подходу: если конкурс заявляется как соревнование инженерных статей, то и судить их должны те, кто способен на равных обсуждать архитектурные решения, математические выкладки и продуктовые компромиссы. Если же помимо продактов в жюри были разработчики, то это уже вызывает вопросы к их компетенции.
Хотелось бы надеяться, что этот опыт учтут при выборе жюри в дальнейшем. Всем успехов и до встречи в следующем году!
То есть вы будете выбирать 1 лучшую работу среди всех уровней? Конечно хозяин-барин, как говорится, но на мой взгляд лучше все-таки сравнивать работы по уровням. Разве не логично, что работы простого уровня будут уступать по технической глубине и у них уже априори будет меньше шансов на победу? С другой стороны, отдавать победу какой-то простой по сложности статье, когда есть более сильные работы, тоже выглядит неуместно и даже очень не справедливо, имхо. Просто у статей разных уровней разные целевые аудитории и в целом разны цели.
Кстати, только что, появилось ещё одно интересное пожелание, которое, на мой взгляд, оценят многие: было бы справедливо выбирать несколько победителей, а не одного или хотя бы награждать всех авторов, чьи работы были очень близки к победе, ну или хотя бы сделать 3 места. То есть я это к тому, что можно было бы как-то уделять внимание всем авторам с сильными работами: по-моему это будет хорошей мотивацией писать качественные статьи, зная, что если статья на 1 балл отстаёт от лучшей, она тоже заслужит внимание.
Такой вопрос: в этом году победители-статьи будут определяться по уровням (простой, средний и сложный) каждый в своём или же будут сравниваться все статьи между собой независимо от уровня?
Ещё предложение/пожелание к администрации: было бы круто, если бы вы также выбрали абсолютного победителя в каждой категории, то есть берутся статьи-победители от частных авторов и корпоративных, а затем уже из них выбирается лучшая. На мой взгляд, это было бы вообще здорово. Если кому-то кому-то зашла такая идея, пишите своё мнение под этим комментом.
По сути ничего нового здесь нет: правильный сон, питание, тренировки, избегать вредных привычек и по возможности стрессовых ситуаций. Остальное же - это генетика, экология и удача.
Интересно было читать статью, поскольку я занимаюсь похожими вещами. Сразу напомнило flash attention 1: очень похожая концепция) Если вам вдруг будет интересно, я недавно выложил в open-source flash attention 2 на triton с поддержкой GPU от Turing и выше, который к тому же имеет режим ручной кастомизации кернелов. Возможно, это окажется полезным для ваших проектов. Вот ссылка
Кстати, не подскажите какие архитектуры поддерживает ваш алгоритм?
Поделюсь своим опытом собесов (если это так можно назвать) за последние полгода. Сам я активно ничего не искал т.к. был занят другими делами и всегда hr добавляются сами и скидывают вакансии либо пишут напрямую с предложениями. В основном это были галеры и иногда бигтех.
Так вот...где-то только 10 в лучшем случае 20% - это действительно хорошие девчонки, которые пишут по факту что им надо и не пытаются потратить наше совместное время впустую. Обычно мы с ними не сходились по условиям типа зп, проектов, формата работы и т.д. В остальных же случаях сначала они соглашаются на условия, потом вдруг резко отказываются или, например, на том же linkedin (где вся инфа про опыт указана в профиле) просят резюме и потом говорят, что у них в компании такой опыт (фриланс) и open-source проекты за опыт не считаются. То есть они сами добавляются к кандидатам, открывают их профиль и им даже лень посмотреть графу про опыт и проекты, но не лень вести несколько дней про это переписку, чтобы потом слиться. С зарплатами сейчас тоже в большинстве случаев дела не очень.
Сначала я думал, что может это со мной что-то не так, но потом пообщавшись со знакомыми и почитав статьи, похожую на эту, убедился, что у многих встречаются различного рода казусы причем в самых разных компаниях. Кстати, конкретно про Яндекс ничего сказать не могу т.к. еще ни разу с ними не общался, но от знакомых, которые туда собеселись и/или устраивались работать, слышал хорошие отзывы. Возможно все зависит от отдела и собеседующего. В любом случае спасибо автору и всем комментаторам за свои истории: было интересно почитать.
Полученная вами ошибка генерируется не моей библиотекой, а внутренней подсистемой механизма внимания (attention backend) библиотеки vLLM, поскольку в ней используются собственные, жёстко встроенные реализации (на основе FlashAttention от Tri Dao, PagedAttention и других), которые не поддерживают архитектуру Turing. Поэтому простая установка сторонних библиотек не приводит к их использованию, так как для этого требуется их прямая интеграция в исходный код vLLM.
Проекты вроде моего, Tri Dao или OpenAI предназначены для разработки собственной архитектуры трансформера с нуля, как это делается в крупных проектах (DeepSeek, LLaMA и др.), поэтому если вы хотите работать с Turing архитектурами, то вам придётся делать тоже самое.
Я постараюсь связаться с командой vLLM по поводу интеграции flash-attention-triton в качестве дополнительного бэкенда для поддержки legacy-архитектур, однако реализация такого решения будет полностью зависеть от приоритетов.
Может показаться, что это уже старая архитектура и в ближайший год-два её не будут поддерживать, например, для того чтобы на ней запускать и обучать трансформеры с flash attention, как это было с turing архитектурами (rtx 20 серии и t4 в colab). На самом деле это не проблема т.к. всё зависит от того кто и как пишет софт, поэтому самое главное, чтобы цены не кусались, а ещё было бы лучше, если бы у nvidia в этом направлении появился реальный конкурент, чтобы для нас с вами как пользователей цены стали ниже.
Более того, я недавно выкатил в open-source flash attention 2, который работает даже на turing gpu, поэтому даже в 2026 году можно работать на старом железе ещё очень долго. К слову, это не реклама и проект полностью открытый и бесплатный, поэтому если это будет кому-то интересно, то про это можно почитать здесь же на Хабре.
1) Просто понты, когда спрашивают теорию, которую не обязательно знать глубоко, чтобы пользоваться готовыми решениями с hugging face или langchain.
2) Знать нужно реально глубоко, чтобы создавать с нуля что-то своё или проводить низкоуровневые оптимизации. Такое гораздо сложнее и встречается редко.
Дело в том, что в ML есть 3 разных вектора развития специалиста: research (придумывают на бумаге новые концепции, проводят по ним тесты и пишут статьи), ml-разработчики (пользуются готовыми решениями на основе того, что придумали исследователи) и research-инженеры (те, кто с нуля могут превратить концепции исследователей в готовый продакшен-код или полноценный продукт - именно их продуктами пользуются ml-разработчики (pytorch, hugging face и т.д.).
Последний тип самый редкий и сильно зависит от локации, компании, её возможностей и т.д. Если вам интересно посмотреть пример работы таких специалистов (я как раз этим занимаюсь), то рекомендую ознакомиться со статьёй, которую я указывал в комментарии выше.
Очень хороший и важный вопрос, ответ на который будет очень большим и не однозначным, но перед этим хочу упомянуть особенности, которые влияют на проведение качественных тестов производительности:
Начиная с версии 3.3.0, в triton появился баг, связанный с увеличенным потреблением shared memory, что особенно заметно на turing и ampere: ранее помещавшиеся блоки в память теперь туда не помещаются. Для решения данной проблемы пришлось прибегнуть к созданию двух разных конфигураций с их автоматическим определением для версий triton до 3.2.0 включительно и после - отсюда и появились 2 режима установки: modern и legacy. Прикол в том, что страрые gpu типа turing и ampere в таком в modern режиме работают субоптимально на уровне vanilla attention для небольших моделей (до сотни миллионов параметров) и немного быстрее для больших (около миллиарда) моделей (GPT, BERT). Поэтому стоит учитывать, что для таких режимов производительность будет разной. Логичным будет вопрос: зачем тогда вообще нужно было писать конфиги для старых gpu в modern режиме? Это необходимо для случаев, если у вас в связке используются разнородные gpu, например ampere и blackwel. О том как тренировать модели в таком случае - будет немного ниже.
Результаты будут сильно зависеть как от количества параметров модели, так и от размера данных, не говоря уже о параметрах для обучения.
Для проведения таких тестов необходимо большое количество различных gpu и желательно по несколько штук, чтобы сравнить результаты не только на больших данных, но и в разных режимах и на разных моделях с разным количеством параметров. Пока что это физически и финансово невозможно (для меня) обеспечить такую материальную базу. Именно поэтому на данный момент раздел с бенчмарками отсутствует (об этом я писал на github в конце readme), а если проект пойдёт в гору, то позже этот раздел появится.
Я специально сделал такое большое вступление, чтобы у вас или читателей не возникло впечатление, что я халатно отношусь к проекту - на самом деле наоборот :) Теперь по поводу результатов: из того что я тестил на своих данных (их было меньше чем в тестах tri dao), на ampere (6xRTX 3090) получилось быстрее примерно в 5.8 раз для GPT-2 small и в 5.2 для GPT-2 medium в сравнении с vanilla attention, на hopper и blackwell цифры были практически одинаковые: в 7 раз на small и 6.6 на medium. Сравнивая его с другими реализациями flash attention на небольших моделях и данных, результаты были плюс-минус похожими.
Данный алгоритм я сделал задолго до того как его выложил в open-source и он уже использовался в проектах, когда приходилось создавать и учить с нуля бота по аналогии с ChatGPT на разнородных GPU. В связи с этим пришлось организовать обучение таким образом, чтобы нагрузка на gpu распределялась не равномерно (иначе самая быстрая будет ожидать самые медленные), а в таких пропорциях, чтобы они завершали вычисления практически в одно и тоже время (минимизировать простой). Конкретно в этом случае у меня не было возможности провести сравнение скорости обучения в сравнении с vanilla attention, но даже так понятно, что прирост был ощутимый. К сожалению, большего пока не могу сказать по этой теме. Как-то так :)
Спасибо за статью, ловите плюсик: полезно иметь всё в одном месте. Однако хочу уточнить, что хотя аналогия q, k, v матриц с базами данных (мой самый любимый вопрос) и используется во многих объяснениях и ответах на собеседованиях, это ошибочное утверждение. На самом деле эти матрицы решают 2 проблемы: - 1) Помогают отделять смысл слова в зависимости от контекста в пространстве признаков т.к. эмбеддинги из-за своей статичной природы не умеют делать это напрямую.
2) Это помогает определять направление зависимости в словах, то есть выделять объекты и субъекты. Проще говоря, делать матрицу оценок внимания ассиметричной.
Если вдруг вам или читателям будет эта тема интересна, то я как раз вчера делал статью про FlashAttention на Triton, где про это рассказывается более подробно и не только.
Ну так ясен пень, что все фаундеры и CEO своих ai компаний/стартапов будут говорить подобное, поскольку если они скажут, что последние несколько лет по факту выпускают один и тот же продукт, который не заменит программистов, а только лишь поможет им ускорить разработку, то их акции рухнут и инвесторы от них уйдут.
Более того, все эти чат-боты сделаны людьми, начиная от концепций на бумаге и заканчивая их реализацией в конечный продукт. Уже несколько лет говорят, что разработчиков скоро не будет, однако у всех них (claude, chatgpt и т.д.) на сайте весит куча вакансий. Это я вам говорю, как человек, который разрабатывает такие модели.
На заводе, на котором я когда-то работал, раньше было 3 бухгалтера со счётами на 5к сотрудников, а сегодня их около 20-ти на 2.5к сотрудников. Я это к тому, что в то время тоже говорили, что с приходом экселя будет 1 человек со всем справляться в разы быстрее. Похожая ситуация и здесь.
На самом деле это очень правильное решение - откладывать деньги и инвестировать их во что-то, чтобы они работали на тебя. Очень популярная тема - инвестирование в s&p 500 (топ крупнейших компаний США по бабкам), что очень стабильно и приносит в среднем 6-7% на руки в год.
Имея несколько млн$ можно действительно всю жизнь жить и не работать, если их правильно вложить. Осталось только устроиться в faang и заработать эти деньги :)
Вам не показалось: в этом году непонятно каким образом оценивались статьи, поэтому я уверен, что подобного рода комментарии ещё не раз появятся. Если раньше на том же хабре ценились статьи как создать свой компьютер с нуля, то теперь больше ценятся как его включить - это просто метафора, но суть ясна. Более того, сейчас в целом везде появился какой-то тренд на всё простое и поверхностное, начиная от разработки и заканчивая какими-то туториалами, обзорами, книгами и т.д.
Например, когда я собесился в рисерч-лабу huawei в команду AGI, то собеседующему было непонятно зачем и как я создавал бота с нуля, разрабатывая его компоненты самостоятельно, а не использовал готовые решения в пару строк кода (на то были некоторые причины, которые я ему называл). Хотя я объективно туда не прошел (не решил алгозадачу за 2 мин и затупил на некоторые вопросы), в целом собеседование было организовано неплохо, но меня уже тогда поразило то, что даже в таких командах гораздо больше ценится умение юзать простые готовые решения, а не создавать свои более крутые.
Спасибо, было бы здорово посмотреть над чем еще поработать
Прежде всего хочу искренне поздравить победителей и всех участников шорт-листа - это действительно интересные работы, которые заслуживают внимания. Однако хочу отдельно обратиться к организаторам конкурса. Критерии «Технотекста» всегда подчёркивали приоритет технической грамотности, инженерной глубины и актуальности. Однако в этом году итоговые оценки в номинации AI/ML разошлись с этими критериями заметно сильнее, чем раньше.
Доверить оценку технической глубины ML-статей продакт-менеджерам - очень сомнительное решение. Прежде такие статьи оценивались исключительно разработчиками и исследователями, что давало уверенность в победе лучшей инженерной мысли, а не лучшей презентации. Сейчас эта уверенность сильно подорвана и это вопрос не к конкретным победителям, а к системному подходу: если конкурс заявляется как соревнование инженерных статей, то и судить их должны те, кто способен на равных обсуждать архитектурные решения, математические выкладки и продуктовые компромиссы. Если же помимо продактов в жюри были разработчики, то это уже вызывает вопросы к их компетенции.
Хотелось бы надеяться, что этот опыт учтут при выборе жюри в дальнейшем. Всем успехов и до встречи в следующем году!
Автор про томагочи забыл - вот это была штука
Понял, тогда будем ждать результатов :)
То есть вы будете выбирать 1 лучшую работу среди всех уровней? Конечно хозяин-барин, как говорится, но на мой взгляд лучше все-таки сравнивать работы по уровням. Разве не логично, что работы простого уровня будут уступать по технической глубине и у них уже априори будет меньше шансов на победу? С другой стороны, отдавать победу какой-то простой по сложности статье, когда есть более сильные работы, тоже выглядит неуместно и даже очень не справедливо, имхо. Просто у статей разных уровней разные целевые аудитории и в целом разны цели.
Кстати, только что, появилось ещё одно интересное пожелание, которое, на мой взгляд, оценят многие: было бы справедливо выбирать несколько победителей, а не одного или хотя бы награждать всех авторов, чьи работы были очень близки к победе, ну или хотя бы сделать 3 места. То есть я это к тому, что можно было бы как-то уделять внимание всем авторам с сильными работами: по-моему это будет хорошей мотивацией писать качественные статьи, зная, что если статья на 1 балл отстаёт от лучшей, она тоже заслужит внимание.
Я имею в виду абсолютного победителя для каждой категории, выбрав в конце лучшую работу среди корпоративного блога и частного автора.
Такой вопрос: в этом году победители-статьи будут определяться по уровням (простой, средний и сложный) каждый в своём или же будут сравниваться все статьи между собой независимо от уровня?
Ещё предложение/пожелание к администрации: было бы круто, если бы вы также выбрали абсолютного победителя в каждой категории, то есть берутся статьи-победители от частных авторов и корпоративных, а затем уже из них выбирается лучшая. На мой взгляд, это было бы вообще здорово. Если кому-то кому-то зашла такая идея, пишите своё мнение под этим комментом.
Да победит сильнейший!
Спасибо за статью: интересно было прочитать. Особенно был удивлён, когда увидел ссылку на свою статью по линейной регрессии :)
По сути ничего нового здесь нет: правильный сон, питание, тренировки, избегать вредных привычек и по возможности стрессовых ситуаций. Остальное же - это генетика, экология и удача.
Следующая статья будет про то, как крысы заменят программистов
Интересно было читать статью, поскольку я занимаюсь похожими вещами. Сразу напомнило flash attention 1: очень похожая концепция) Если вам вдруг будет интересно, я недавно выложил в open-source flash attention 2 на triton с поддержкой GPU от Turing и выше, который к тому же имеет режим ручной кастомизации кернелов. Возможно, это окажется полезным для ваших проектов. Вот ссылка
Кстати, не подскажите какие архитектуры поддерживает ваш алгоритм?
Поделюсь своим опытом собесов (если это так можно назвать) за последние полгода. Сам я активно ничего не искал т.к. был занят другими делами и всегда hr добавляются сами и скидывают вакансии либо пишут напрямую с предложениями. В основном это были галеры и иногда бигтех.
Так вот...где-то только 10 в лучшем случае 20% - это действительно хорошие девчонки, которые пишут по факту что им надо и не пытаются потратить наше совместное время впустую. Обычно мы с ними не сходились по условиям типа зп, проектов, формата работы и т.д. В остальных же случаях сначала они соглашаются на условия, потом вдруг резко отказываются или, например, на том же linkedin (где вся инфа про опыт указана в профиле) просят резюме и потом говорят, что у них в компании такой опыт (фриланс) и open-source проекты за опыт не считаются. То есть они сами добавляются к кандидатам, открывают их профиль и им даже лень посмотреть графу про опыт и проекты, но не лень вести несколько дней про это переписку, чтобы потом слиться. С зарплатами сейчас тоже в большинстве случаев дела не очень.
Сначала я думал, что может это со мной что-то не так, но потом пообщавшись со знакомыми и почитав статьи, похожую на эту, убедился, что у многих встречаются различного рода казусы причем в самых разных компаниях. Кстати, конкретно про Яндекс ничего сказать не могу т.к. еще ни разу с ними не общался, но от знакомых, которые туда собеселись и/или устраивались работать, слышал хорошие отзывы. Возможно все зависит от отдела и собеседующего. В любом случае спасибо автору и всем комментаторам за свои истории: было интересно почитать.
Полученная вами ошибка генерируется не моей библиотекой, а внутренней подсистемой механизма внимания (attention backend) библиотеки vLLM, поскольку в ней используются собственные, жёстко встроенные реализации (на основе FlashAttention от Tri Dao, PagedAttention и других), которые не поддерживают архитектуру Turing. Поэтому простая установка сторонних библиотек не приводит к их использованию, так как для этого требуется их прямая интеграция в исходный код vLLM.
Проекты вроде моего, Tri Dao или OpenAI предназначены для разработки собственной архитектуры трансформера с нуля, как это делается в крупных проектах (DeepSeek, LLaMA и др.), поэтому если вы хотите работать с Turing архитектурами, то вам придётся делать тоже самое.
Я постараюсь связаться с командой vLLM по поводу интеграции flash-attention-triton в качестве дополнительного бэкенда для поддержки legacy-архитектур, однако реализация такого решения будет полностью зависеть от приоритетов.
Может показаться, что это уже старая архитектура и в ближайший год-два её не будут поддерживать, например, для того чтобы на ней запускать и обучать трансформеры с flash attention, как это было с turing архитектурами (rtx 20 серии и t4 в colab). На самом деле это не проблема т.к. всё зависит от того кто и как пишет софт, поэтому самое главное, чтобы цены не кусались, а ещё было бы лучше, если бы у nvidia в этом направлении появился реальный конкурент, чтобы для нас с вами как пользователей цены стали ниже.
Более того, я недавно выкатил в open-source flash attention 2, который работает даже на turing gpu, поэтому даже в 2026 году можно работать на старом железе ещё очень долго. К слову, это не реклама и проект полностью открытый и бесплатный, поэтому если это будет кому-то интересно, то про это можно почитать здесь же на Хабре.
Хороший вопрос. Здесь может быть 2 варианта:
1) Просто понты, когда спрашивают теорию, которую не обязательно знать глубоко, чтобы пользоваться готовыми решениями с hugging face или langchain.
2) Знать нужно реально глубоко, чтобы создавать с нуля что-то своё или проводить низкоуровневые оптимизации. Такое гораздо сложнее и встречается редко.
Дело в том, что в ML есть 3 разных вектора развития специалиста: research (придумывают на бумаге новые концепции, проводят по ним тесты и пишут статьи), ml-разработчики (пользуются готовыми решениями на основе того, что придумали исследователи) и research-инженеры (те, кто с нуля могут превратить концепции исследователей в готовый продакшен-код или полноценный продукт - именно их продуктами пользуются ml-разработчики (pytorch, hugging face и т.д.).
Последний тип самый редкий и сильно зависит от локации, компании, её возможностей и т.д. Если вам интересно посмотреть пример работы таких специалистов (я как раз этим занимаюсь), то рекомендую ознакомиться со статьёй, которую я указывал в комментарии выше.
Очень хороший и важный вопрос, ответ на который будет очень большим и не однозначным, но перед этим хочу упомянуть особенности, которые влияют на проведение качественных тестов производительности:
Начиная с версии 3.3.0, в triton появился баг, связанный с увеличенным потреблением shared memory, что особенно заметно на turing и ampere: ранее помещавшиеся блоки в память теперь туда не помещаются. Для решения данной проблемы пришлось прибегнуть к созданию двух разных конфигураций с их автоматическим определением для версий triton до 3.2.0 включительно и после - отсюда и появились 2 режима установки: modern и legacy. Прикол в том, что страрые gpu типа turing и ampere в таком в modern режиме работают субоптимально на уровне vanilla attention для небольших моделей (до сотни миллионов параметров) и немного быстрее для больших (около миллиарда) моделей (GPT, BERT). Поэтому стоит учитывать, что для таких режимов производительность будет разной. Логичным будет вопрос: зачем тогда вообще нужно было писать конфиги для старых gpu в modern режиме? Это необходимо для случаев, если у вас в связке используются разнородные gpu, например ampere и blackwel. О том как тренировать модели в таком случае - будет немного ниже.
Результаты будут сильно зависеть как от количества параметров модели, так и от размера данных, не говоря уже о параметрах для обучения.
Для проведения таких тестов необходимо большое количество различных gpu и желательно по несколько штук, чтобы сравнить результаты не только на больших данных, но и в разных режимах и на разных моделях с разным количеством параметров. Пока что это физически и финансово невозможно (для меня) обеспечить такую материальную базу. Именно поэтому на данный момент раздел с бенчмарками отсутствует (об этом я писал на github в конце readme), а если проект пойдёт в гору, то позже этот раздел появится.
Я специально сделал такое большое вступление, чтобы у вас или читателей не возникло впечатление, что я халатно отношусь к проекту - на самом деле наоборот :) Теперь по поводу результатов: из того что я тестил на своих данных (их было меньше чем в тестах tri dao), на ampere (6xRTX 3090) получилось быстрее примерно в 5.8 раз для GPT-2 small и в 5.2 для GPT-2 medium в сравнении с vanilla attention, на hopper и blackwell цифры были практически одинаковые: в 7 раз на small и 6.6 на medium. Сравнивая его с другими реализациями flash attention на небольших моделях и данных, результаты были плюс-минус похожими.
Данный алгоритм я сделал задолго до того как его выложил в open-source и он уже использовался в проектах, когда приходилось создавать и учить с нуля бота по аналогии с ChatGPT на разнородных GPU. В связи с этим пришлось организовать обучение таким образом, чтобы нагрузка на gpu распределялась не равномерно (иначе самая быстрая будет ожидать самые медленные), а в таких пропорциях, чтобы они завершали вычисления практически в одно и тоже время (минимизировать простой). Конкретно в этом случае у меня не было возможности провести сравнение скорости обучения в сравнении с vanilla attention, но даже так понятно, что прирост был ощутимый. К сожалению, большего пока не могу сказать по этой теме. Как-то так :)
Спасибо за статью, ловите плюсик: полезно иметь всё в одном месте. Однако хочу уточнить, что хотя аналогия q, k, v матриц с базами данных (мой самый любимый вопрос) и используется во многих объяснениях и ответах на собеседованиях, это ошибочное утверждение. На самом деле эти матрицы решают 2 проблемы:
- 1) Помогают отделять смысл слова в зависимости от контекста в пространстве признаков т.к. эмбеддинги из-за своей статичной природы не умеют делать это напрямую.
2) Это помогает определять направление зависимости в словах, то есть выделять объекты и субъекты. Проще говоря, делать матрицу оценок внимания ассиметричной.
Если вдруг вам или читателям будет эта тема интересна, то я как раз вчера делал статью про FlashAttention на Triton, где про это рассказывается более подробно и не только.