Ускоряем LLM на раз, два, три

Иметь личного ассистента на ноуте и запускать мощную модель локально — хорошо. Тратить огромные ресурсы на это — уже не очень.

В новой статье разбираем ключевые методы ускорения и обсуждаем, что действительно работает:
— фреймворки для инференса — какой выбрать, чтобы выжать максимум
— спекулятивное декодирование — почему это must-have для скорости
— квантование — как правильно применять и почему оно превратилось в «народный» метод ускорения

А ещё в статье мы вспоминаем базу — Flash-Attention, технологию, которая помогла развить популяризацию LLM в целом 🚀

Читайте по ссылке!

Рефлексия о работе в OpenAI или как из хаоса и атомарных действий рождается великое.

Ex сотрудник Codex рассказывает о своем опыте работы в OpenAI.

Советую почитать самостоятельно, если уж английский не ваше - перевод тут.

Выделю то, что именно интересно мне, в основном, это процессы, за остальным вэлкам, опять же, в полную версию.

1. Наличие моно-репо разработки, отсутствие коммуникаций в почте. Да, ребята общаются через мессенджер - Slack. Имеется многоуровневая система доступов, особенно, к чатам с фин. информацией. В почте почти нет коммуникации, автор буквально получал около 10 писем за все время. На сладкое разработка в одном огромном монорепозитории.

2. Процессы под лозунгом "bias to action". Формирование групп и команд идет по интересам и сразу в бой. Зачастую, годные идеи и их реализации просто интегрируют в более масштабный флоу к основной ветке. Отсюда возможность создания параллельно нескольких групп, делающих одну фичу по-своему, далее побеждает "сильнейший". Также это дает возможность расти тем, кто делает интересное/полезное хорошо и быстро, даже без возможности нормальной презентации. Вокруг таких успешных групп быстро далее формируется core команда для доведения до ума решения. Обычно все крутые фичи рождаются в рамках "мелких" исследований, это в т.ч. порождает порой огромные распределенные кусочки, которые важно соединить воедино. Отсюда и важны руководители.

3. Руководители исследовательских групп – «мини CEO». В рамках работы, при создании трека важная максимальная самостоятельность и принятие рисков. Поэтому лиды групп становятся мини-CEO, которые видят весь ландшафт работ, в т.ч. в соседних командах. Отмечается важность иметь хороших research engineering manager и PMов. Причём люди, занимающие данные позиции обладают открытым и широким взглядом, создавая впечатление что уже видели все. Но эта черта не мешает поддерживать команды, мотивировать на успех и минимально вмешиваться в реализацию. Такие руководители поощряют креатив и т. п., а не микроменеджерят, помогая и нанять лучших людей под задачу или ротировать их, а также дать выч. ресурсы.

Как следствие из п. 1-3, компания довольно гибкая и быстро может менять направление исследований и разработок. Все что не интересно, решенное и устарело, скорее всего, делаться не будет. Также это не дает возможности быть инертными и четко двигаться по плану/стратегии в отличии от конкурентов в Google и др. Руководители вовлечены в работу и не ждут квартального планирования и планового перераспределения в штат, подтягивая опять же быстро нужных людей. Какой к чёрту план, когда вы на острие технологий и все меняется молниеносно.

4. Важность оптимизации GPU. Работа с оптимизацией латенси вплоть до времени отклика на генерацию первого токена. Отмечается, что ресурсы GPU для создания одной нишевой функции Codex были сопоставимы по затратам со всем пайпом сбора и чистки данных логов клиентов.

5. Не забываем о социальной ответственности. Большое внимание уделяется практическим угрозам (например, разжиганию вражды, злоупотреблению технологиями, манипуляциям общественным мнением, созданию биологического оружия, проблемам самолечения и атакам методом инъекций запросов), нежели абстрактным рискам вроде интеллектуального скачка или стремлениях машин к власти. Однако это вовсе не означает, что вопросами гипотетических рисков никто не занимается — такие специалисты действительно существуют.

Интересно? Читайте полную версию и черпайте интересные моменты для себя. Жду от вас комментарии, что отметили именно вы.

Upd. Мне напомнило это все, кстати, рассказ разработчиков ChatGPT, как они сделали это. Когда Сэм пришел и попросил перед очередным собранием инвесторов удивить его, команда достала из широких штанин, что они делали с GPT3.5 (или 3). И это было оно. Сама сказал, накинуть на это GUI и пустить на бой, ибо это вызывало шок, вострог и вау. Чуваки делали несколько месяцев экспы и никто их не хватился, до нужного момента. И вот такая исследовательская группа удивила. Вот так это и работает в такой архитектуре процессов.

#gan #petproject

#interview #database

Отбор в Сбер на дата инженера (2025)

Сейчас идут последние часы скидки на наши новые карьерные курсы, которые стартуют уже завтра, и еще можно записаться.

Ниже рассказ выпускника нашего курса дата инженер. Далее текст слегка отредактирован.
Собесился в команду построения витрин данных для выявления подозрительных операций. По работе все стандартно — написание Spark приложений, раскладывать данные по 3 нормальной форме, делать так, чтобы все работало как часы и быстро.

Тестовое задание
Контеста не было, дали тест — SQL + немного Python.

SQL: задачи классические — подзапросы, оконки, группировки.
Пример: найти дату первой покупки клиента в сегменте "Премиум" и посчитать, сколько дней после этого он продолжал что-то там покупать.
Поспрашивали также про результаты джоины, ну т.е. на простых табличках прикинуть, сколько строк будет в каждом случае.

Python: попросили прочитать csv файл spark-ом и обработать — отсеять записи (файлы был уже в scd 2) и сделать итоговую группировку. Все это нужно было написать не через Spark SQL, а через DataFrame (спасибо, что не на скале)

Техническое интервью
Сначала — бэкграунд: чем занимался, с какими технологиями работал, какими задачами (интеграциями и витринами)

Потом пошли практические вопросы:

— Архитектура Airflow, что такое DAG, какие есть операторы и т.д.
— Как обеспечить идемпотентность в даге.
— Как лучше организовать пайплайн, чтобы рассчет витрин начинался сразу по прибытии данных, какие недостатки есть у каждого из способов.

Поболтали про Spark:
— Wide vs narrow трансформации, что такое rdd.
— Что может вызвать out-of-memory у executor.
— Как отладить тормозящую джобу: Spark UI, skew, spill в диск, настройка количества партиций.

Ну и под конец была небольшая задачка про то, как лучше построить обработку витрины, расчет которой нужно проводить от сегодняшней даты на глубину один год.
На нее быстро ответил, что лучше держать предагрегат, а потом считать реальное изменение за последние несколько дней. Кстати все входит в программу нашего курса дата инженер.

Результат
Через пару дней — оффер, все оказалось даже проще, чем ожидал, спасибо, что алгоритмы особо не спрашивали.

Еще один отзыв ниже.

@postypashki_old

#ml #systemdesign

How to avoid machine learning pitfalls by Michael A. Lones

Mistakes in machine learning practice are commonplace, and can result in a loss of confidence in the findings and products of machine learning.

This guide outlines common mistakes that occur when using machine learning, and what can be done to avoid them.

Whilst it should be accessible to anyone with a basic understanding of machine learning techniques, it focuses on issues that are of particular concern within academic research, such as the need to do rigorous comparisons and reach valid conclusions.

It covers five stages of the machine learning process:
- What to do before model building
- How to reliably build models
- How to robustly evaluate models
- How to compare models fairly
- How to report results

Link: arXiv

Navigational hashtags: #armarticles
General hashtags: #ml #machinelearning #mlsystemdesign

@data_science_weekly

Топ смертных грехов - или нет?
Уже несколько лет я руковожу людьми и постепенно их становится все больше. Системного обучения "как быть руководителем" в моей жизни не было. Я иногда почитываю какие-то материалы, иногда советуюсь с родителями, но на самом деле во многих вещах я поступаю просто интуитивно и эмпирически нахожу ответы на вопросы.

В целом, если присмотреться, то становится понятно, что в обществе существует некий "gold standart" руководителя, который должен следовать 15-20 правилам и тогда его все будут любить.

Кстати, на тему "все будут любить" отличный пост написала Аня, автор канала Руковожоп (@peachyleader). Это не реклама, а моя личная рекомендация, хороший канал для начинающих руководителей.

Если ты человек с адекватным эмоциональным интеллектом, то запрыгнуть на эту "gold standart" ступеньку не составляет труда.
Примеры таких правил:

1. Не унижай личность сотрудника
2. Проводи встречи по развитию и давай людям расти
3. Будь защитником своей команды
4. Не перегружай сотрудников
5. Не микроменеджери
6. Не обманывай
и подобное.

Тут все понятно, и да, далеко не все способны следовать и этому набору.

Но вот о чем я задумался. Данный список правил далеко не все говорит о твоей эффективности. Ключевые метрики на которые мы тут работаем - уменьшение текучки и развитие сотрудников. Но фактически есть еще та часть, в которой мы эффективно решаем задачи и зарабатываем деньги для компании. И возможно, чтобы работать оптимально, используя 100% возможностей - необходимо уменьшить количество "табу", тем самым увеличив свой инструментарий.

Вот некоторые пункты, о которых я пока размышляю:
Переработки
Об этом я частично писал. Причин, почему вам надо добавить динамики, множество. Если твой конкурент работает 5 дней в неделю, а ты 6, то высока вероятность, что ты будешь двигаться быстрее. И, возможно, навык руководителя не в том, чтобы отказаться от этого объективно рабочего инструмента, а грамотно им управлять, чтобы сотрудники не перегорели.

Нанимать не по вайбу
При найме я много раз отказывал людям, которые не подходили мне по софтам, хотя харды были очень хорошие. Я всегда считал, что микроклимат в отделе - ключ к успеху. Но, задумался я, почему бы не нанять токсичного гения, не "запереть его в комнате" и пусть перемалывает там самые сложные задачки. И тогда твой навык - оградить остальных от него, но задачи, возможно, он будет щелкать лучше прочих "вайбовых" коллег.

Повышать голос
Я много лет занимался спортом и оттуда вынес простую мысль на всю жизнь о том, что люди делятся на два типа: те, кого мотивирует поддержка и те, кого мотивирует давление. "Gold standart" сфокусирован на поддержке, но всех ли это реально стимулирует, вторая половина же никуда не пропала. Вспомните таких людей, которые очень редко повышают голос и в этих случаях вы понимаете, что реально что-то случилось. Может иногда это единственный способ привести в чувство и разгрести инцидент?

Обман
О сколько разговоров проведено и книг написано о лжи во благо, внесу свою лепту. Я стараюсь быть открытым и доводить большую часть информации до своих сотрудников, но есть вещи, которые могут вызвать скорее волнение, нежели принесут ценность от осведомленности. Сегментировать информацию, к сожалению, тоже полезный навык, вероятно, как и иногда лукавить.

Идея поста заключается в том, что искусство руководителя, кажется, заключается в умении применять широкий спектр инструментов, а не только удобные, при которых его все "любят", но эти гипотезы надо проверять на практике.

Пост слегка провокационный, будет интересно послушать ваше мнение об этом в комментариях!

@lechim_ai

Эти пет проекты должен сделать каждый ML специалист

Финальные 4 часа скидки подходят к концу, курсы стартуют уже завтра. В честь этого подготовили самые популярные проекты, еще больше пет проектов по глубокому обучению будут на нашем курсе ds (смотрите на сайте)

1. Кредитный скоринг
Стоит ли давать кредит— довольно популярная задача и отличный выбор для новчиков, чтобы самостоятельно проделать все этапы. Сначала берем любой датасет на kaggle по запросу Credit Scoring. Проводим EDA, генерируем гипотезы, фичи, готовим данные для модели и делаем бейзлайн: логистическая регрессия. Затем уже можно попробовать случайный лес, градиентный бустинг, KNN или еще что по вкусу— сравниваем метрики. И на последок не забываем проанализировать результаты и культурно презентовать. Можно провести АВ тест на смой первой модели.
Все варианты решения и реализации можно найти в интернетах: GitHub, Хабр. Очень полезным будет посмотреть всякие выступления на конференциях по этой теме для вдохновения, да и это очень поможет на мл кейсах.

2. Наивный Байесовский классификатор (НБК)
Для конкретики будем классифицировать письма на спам. Опять же обработаем данные: удаляем числа, знаки препинания, стоп-слова, стемминги, лемматизацию.
Объединяем все методы предварительной обработки и создаём словарь слов и счётчик каждого слова в наборе данных для обучения:
1. Вычисляем вероятность для каждого слова в тексте и отфильтровываем слова со значением вероятности меньше порогового. Такие слова будут нерелевантными.
2. Для каждого слова в словаре создаём вероятность, что это слово окажется в спаме. Определяем условную вероятность для использования её в НБК.
3. Вычисляем прогнозируемый результат с помощью условных вероятностей.
НБК реализовать не сложно. Куда интересней погрузиться во всю теорию, которая за этим стоит, в вероятностные модели. К тому же, кейс фильтрации спама и подобного часто встречается на собесах.

3. MLOps
Можно наладить какой-то минимальный прод для проектов: например телеграм бот или FastAPI. Можно еще автоматизировать пайплайн с помощь AirFlow и попробовать запустить инфраструктуру не только локально, но и облаке. Конечно нужно будет поизучать Docker, Cuber, Hadoop, Spark, HDFS, Kafka. Но на самом деле ничего трудного— после нашего курса дата инженера будете делать такие вещи по щелчку пальцев.

4. Ранжирование и матчинг
Для начала лучше пробежаться глазами по статье и посмотреть, что пишут в интернетах. Можно выделить три подхода к задаче: поточечный, попарный, списочный. Советую начать с первого как самого простого. Для конкретики будем предсказать оценку релевантности для запросов тестового датасета. Здесь можно кстати поучиться парсить web-страниц и собирать сырые данные, размечать их с помощью какого-нибудь Яндекс-Толока. Делаем регрессию, а затем Random Forest Regressor, XGBoost, lightGBM, CatBoost.
Совсем продвинутые могут попробовать языковые модели в духе FastText, Word2Vec, DSSM и более сложные: BERT, можно даже попробовать архитектуру трансформеров.

5. Рекомендашки
Очень популярный кейс на собесах. Для начала лучше пробежаться глазами по этому разделу и посмотреть, что пишут в интернетах. Затем начинаем реализовывать самое простое как бейзлайн, например, content-based рекомендации, KNN. Дальше можно попробовать факторизации матрицы рейтингов по svd разложению или по более эффективной als архитектуре и функции ошибок bpr. Затем можно попробовать W2V подход, чтобы использовать последовательность взаимодействий пользователя для построения рекомендации следующего предмета.
Для знатоков DL можно попробовать DSSM, SasRec/Bert4Rec, MultVAE, Merlin или графовые нейронки: GCN-подобные архитектуры.
Также стоит попробовать обучение с подкреплением: многоруких бандитов.
Ну и конечно рекомендательные системы можно попробовать рассмотреть как задачу ранжирования.

@postypashki_old