Forwarded from Sinекура
Написал небольшой пост о новой статье, которая сама по себе революцию не делает, но кажется хорошим моментом, чтобы обсудить некоторые тенденции. Полностью пост на сайте, ниже приведу краткую выжимку:
Mixture-of-Recursions: думаем над токенами рекурсивно и адаптивно
Исследователи из KAIST и Google Bae et al. (2025) представили идею под названием Mixture-of-Recursions (MoR, смесь рекурсий). Она объединяет три основные стратегии повышения эффективности трансформеров без радикальной смены архитектуры (без перехода на Mamba, например):
— Mixture-of-Experts (MoE) добавляет разреженность активаций при инференсе: специальный роутер выбирает, какую подсеть-эксперта использовать для каждого токена на каждом слое; в результате параметров у сети очень много, но на каждый токен активируется только небольшое подмножество; MoE — это большая наука, о которой я, надеюсь, скоро расскажу подробнее;
— layer tying уменьшает число параметров за счёт переиспользования весов в разных слоях; это было ещё в Universal Transformers и продолжает появляться до сих пор (Gholami, Omar, 2023; Bae et al., 2025b);
— early exiting тоже добавляет разреженности, но за счёт остановки обработки на ранних слоях для более простых токенов; идея восходит к Depth-Adaptive Transformers и продолжает развиваться (Elhoushi et al., 2024).
Первым важным предшественником MoR стала Mixture-of-Depths (MoD; Raposo et al., 2024). Они ввели маршрутизацию на уровне токенов для адаптивных вычислений: MoE-модели обучают маршрутизатор выбирать между разными подсетями-экспертами, а MoD — выбирать, использовать ли слой или обойти вокруг (рис. 2).
А если объединить связывание слоёв и ранние выходы, получатся рекурсивные трансформеры (Recursive Transformers, Bae et al., 2025b), которые повторяют блок из K слоёв несколько раз в цикле. Например, вместо 30 слоёв в рекурсивной модели будет всего 10, которые применяются трижды, то есть втрое меньше параметров. По ходу рекурсии слои модифицируются LoRA-адаптерами (рис. 3).
И вот Bae et al. (2025) делают следующий шаг: вводят механизмы маршрутизации, которые для каждого токена индивидуально решают, сколько раз применять рекурсивные блоки. "Смесь рекурсий" значит, что небольшие подсети-маршрутизаторы динамически назначают разлную глубину рекурсии отдельным токенам. То есть если нужно породить простое функциональное слово, сеть сможет остановиться после первого прохода через блок, а если нужно подумать, чтобы предсказать следующее слово, то можно прогнать три итерации.
На рис. 4 показаны (a) структура маршрутизатора, (b) общая структура модели и (c) пример того, как более простые токены производятся меньшим числом шагов рекурсии, чем семантически богатые. Идея в том, чтобы дать каждому токену ровно столько времени обработки, сколько ему нужно — ни больше, ни меньше.
Такую адаптивную маршрутизацию можно реализовать по-разному, и в посте я объясняю новые прикольные идеи, которые предлагают Bae et al., но сюда они не влезут.
В целом MoR — вряд ли последнее слово, но направление крутое. Эксперименты, правда, пока очень маленькие: самая большая модель в статье — это Gemma 2B; но будет удивительно, если MoR вдруг перестанет работать при масштабировании. Кстати, MoR естественным образом поддерживает test-time scaling: регулируя глубину рекурсии во время инференса, можно настраивать компромисс между качеством и скоростью.
Вся эта серия работ — MoD, рекурсивные трансформеры, MoR — выглядит очень перспективно. Получаются большие AI-модели, адаптивные не только в том, какие подсети они используют (как обычные MoE), но и в том, сколько вычислений они используют. Кстати, было бы легко объединить MoR и MoE, это естественный следующий шаг; я бы не удивился, если бы в скором времени в этом направлении появилась "3D-разреженная" модель: токены x глубина x эксперты.
Как я всегда говорю, даже если физическое масштабирование остановится (сложно уже транзисторы уменьшать), алгоритмический прогресс принесёт нам ещё немало иксов улучшения эффективности. Будем следить за прогрессом!
Mixture-of-Recursions: думаем над токенами рекурсивно и адаптивно
Исследователи из KAIST и Google Bae et al. (2025) представили идею под названием Mixture-of-Recursions (MoR, смесь рекурсий). Она объединяет три основные стратегии повышения эффективности трансформеров без радикальной смены архитектуры (без перехода на Mamba, например):
— Mixture-of-Experts (MoE) добавляет разреженность активаций при инференсе: специальный роутер выбирает, какую подсеть-эксперта использовать для каждого токена на каждом слое; в результате параметров у сети очень много, но на каждый токен активируется только небольшое подмножество; MoE — это большая наука, о которой я, надеюсь, скоро расскажу подробнее;
— layer tying уменьшает число параметров за счёт переиспользования весов в разных слоях; это было ещё в Universal Transformers и продолжает появляться до сих пор (Gholami, Omar, 2023; Bae et al., 2025b);
— early exiting тоже добавляет разреженности, но за счёт остановки обработки на ранних слоях для более простых токенов; идея восходит к Depth-Adaptive Transformers и продолжает развиваться (Elhoushi et al., 2024).
Первым важным предшественником MoR стала Mixture-of-Depths (MoD; Raposo et al., 2024). Они ввели маршрутизацию на уровне токенов для адаптивных вычислений: MoE-модели обучают маршрутизатор выбирать между разными подсетями-экспертами, а MoD — выбирать, использовать ли слой или обойти вокруг (рис. 2).
А если объединить связывание слоёв и ранние выходы, получатся рекурсивные трансформеры (Recursive Transformers, Bae et al., 2025b), которые повторяют блок из K слоёв несколько раз в цикле. Например, вместо 30 слоёв в рекурсивной модели будет всего 10, которые применяются трижды, то есть втрое меньше параметров. По ходу рекурсии слои модифицируются LoRA-адаптерами (рис. 3).
И вот Bae et al. (2025) делают следующий шаг: вводят механизмы маршрутизации, которые для каждого токена индивидуально решают, сколько раз применять рекурсивные блоки. "Смесь рекурсий" значит, что небольшие подсети-маршрутизаторы динамически назначают разлную глубину рекурсии отдельным токенам. То есть если нужно породить простое функциональное слово, сеть сможет остановиться после первого прохода через блок, а если нужно подумать, чтобы предсказать следующее слово, то можно прогнать три итерации.
На рис. 4 показаны (a) структура маршрутизатора, (b) общая структура модели и (c) пример того, как более простые токены производятся меньшим числом шагов рекурсии, чем семантически богатые. Идея в том, чтобы дать каждому токену ровно столько времени обработки, сколько ему нужно — ни больше, ни меньше.
Такую адаптивную маршрутизацию можно реализовать по-разному, и в посте я объясняю новые прикольные идеи, которые предлагают Bae et al., но сюда они не влезут.
В целом MoR — вряд ли последнее слово, но направление крутое. Эксперименты, правда, пока очень маленькие: самая большая модель в статье — это Gemma 2B; но будет удивительно, если MoR вдруг перестанет работать при масштабировании. Кстати, MoR естественным образом поддерживает test-time scaling: регулируя глубину рекурсии во время инференса, можно настраивать компромисс между качеством и скоростью.
Вся эта серия работ — MoD, рекурсивные трансформеры, MoR — выглядит очень перспективно. Получаются большие AI-модели, адаптивные не только в том, какие подсети они используют (как обычные MoE), но и в том, сколько вычислений они используют. Кстати, было бы легко объединить MoR и MoE, это естественный следующий шаг; я бы не удивился, если бы в скором времени в этом направлении появилась "3D-разреженная" модель: токены x глубина x эксперты.
Как я всегда говорю, даже если физическое масштабирование остановится (сложно уже транзисторы уменьшать), алгоритмический прогресс принесёт нам ещё немало иксов улучшения эффективности. Будем следить за прогрессом!
Forwarded from что-то на инженерном
Оптимизируем запросы в ClickHouse c помощью PREWHERE
Если вы работаете с большими таблицами в ClickHouse и фильтруете данные через WHERE, то скорее всего вы упускаете возможность значительно ускорить запросы, а именно оптмизировать их с помощью оператора PREWHERE. Это ключевой инструмент для ускорения запросов за счёт более рационального чтения данных.
⭐️ В чём магия PREWHERE?
При использовании обычного WHERE, ClickHouse сначала читает все нужные столбцы, потом фильтрует строки.
PREWHERE - это модификация WHERE, которая позволяет ClickHouse сначала отфильтровать тяжелые столбцы, загружая только те данные, которые нужны для фильтрации. В результате, чтение данных резко сокращается. Это особенно важно, если в запросе есть дорогостоящие (тяжёлые) поля, типа: JSON, строки, массивы и т.п, которые не участвуют в фильтрации.
Когда использовать PREWHERE?
🟣 Таблица широкая (много столбцов), а фильтрация идет по легким столбцам (Int, UInt, Date).
🟣 Фильтр сильно ограничивает результат (отсекает большую часть строк).
🟣 Поля для фильтрации занимают мало места, и их быстро прочесть.
🟣 Выборка содержит тяжелые столбцы (JSON, массивы, длинные строки), которые не нужны для фильтрации.
➡️ PREWHERE особенно эффективен, когда нужно минимизировать чтение тяжелых столбцов, так ClickHouse сначала фильтрует по легким данным, а тяжелые читает только по тем строкам, что прошли фильтр.
➡️ PREWHERE не работает на агрегациях, оконных функциях, условиях на столбцы из джойнов и может быть неэффективным на nullable столбцах.
➡️ С осторожностью использовать в запросах с FINAL: в таком случае фильтровать только по столбам из секции ORDER BY, либо использовать фильтрацию WHERE. Иначе результаты могут быть непредсказуемыми или искаженными, поскольку фильтрация будет работать не по уникализированым (финальным) данным, а по исходным версиям строк.
Когда достаточно WHERE?
🟣 Фильтр и выборка по одним и тем же тяжелым столбцам.
🟣 Таблица узкая (2–3 столбца), размер данных не критичен для чтения.
🟣 Если фильтр оставляет > 50% данных, лучше использовать WHERE.
Что в итоге?
Применяем PREWHERE для фильтрации по легким или индексируемым столбцам, которые позволяют максимально сократить объем сканируемых данных.
Если объем считываемых данных небольшой или структура таблицы не влияет на производительность, то используем старый-добрый WHERE.
Вообще, ClickHouse сам может переносить часть условий из WHERE в PREWHERE автоматически, но явно заданный PREWHERE даёт больший контроль и может дать прирост к скорости.
Источники:
◀️ Официальная дока PREWHERE
◀️ Под капотом PREWHERE в ClickHouse: сравниваем планы запросов
◀️ WHERE vs PREWHERE in ClickHouse
💡 А вы применяете PREWHERE для оптимизации своих запросов?
© что-то на инженерном
Если вы работаете с большими таблицами в ClickHouse и фильтруете данные через WHERE, то скорее всего вы упускаете возможность значительно ускорить запросы, а именно оптмизировать их с помощью оператора PREWHERE. Это ключевой инструмент для ускорения запросов за счёт более рационального чтения данных.
При использовании обычного WHERE, ClickHouse сначала читает все нужные столбцы, потом фильтрует строки.
PREWHERE - это модификация WHERE, которая позволяет ClickHouse сначала отфильтровать тяжелые столбцы, загружая только те данные, которые нужны для фильтрации. В результате, чтение данных резко сокращается. Это особенно важно, если в запросе есть дорогостоящие (тяжёлые) поля, типа: JSON, строки, массивы и т.п, которые не участвуют в фильтрации.
Пример:
SELECT heavy_column
FROM large_table
PREWHERE is_active = 1
WHERE created_at >= today() - 7
здесь is_active - лёгкий булевый столбец. Благодаря PREWHERE, ClickHouse сначала отфильтрует только нужные строки, а потом только для них вытащит heavy_column.
Когда использовать PREWHERE?
Когда достаточно WHERE?
Что в итоге?
Применяем PREWHERE для фильтрации по легким или индексируемым столбцам, которые позволяют максимально сократить объем сканируемых данных.
Если объем считываемых данных небольшой или структура таблицы не влияет на производительность, то используем старый-добрый WHERE.
Вообще, ClickHouse сам может переносить часть условий из WHERE в PREWHERE автоматически, но явно заданный PREWHERE даёт больший контроль и может дать прирост к скорости.
Источники:
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Архитектор Данных
Инсайды из «Разговоров на архитекторском» с Вадимом Беловым, Head of DMP X5.
Про хранилища данных
1️⃣ Зрелое хранилище - это когда процессы-потребители данных ходят в ХД напрямую, минуя этап обратного ETL, загрузки данных батчами из подготовленных витрин куда-то в отдельную продовую систему.
2️⃣ Много разнородных потребителей - это реальность современного развитого ХД, с высокой ожидаемой ценностью для бизнеса. Проблема роста - в росте количества и разнообразия потребителей в большей степени, чем в объеме данных.
3️⃣ Стриминг и суб-минутные / секундные прогрузки данных: 10 лет назад мечта, сегодня - реальность и необходимость.
4️⃣ Транзакционность в аналитической системе - упрощает код, упрощает и ускоряет работу дата инженеров, понижает требуемую квалификацию дата инженера. Очень приятно работать со сложной системой так, будто это классическая СУБД с транзакциями.
Про лейкхаус
1️⃣ Ключевая технология, отличающая Lake и LakeHouse - формат данных и транзакционность.
2️⃣ Лейкхаус помогает убрать ненужные перегрузки данных из системы в систему. Причем надо понимать, что каждая продовая переливка из А в Б это а) стейджинговые и промежуточные слои, многократное дублирование данных, б) код, в) команда, которая поддерживает код и пайплайны, г) доп нагрузка на чтение в А и запись в Б. Если можно этого не делать, то получаем огромную экономию в лонг-ране.
3️⃣ «Старый» стек (Greenplum + Hadoop, + Clickhouse + …) - зоопарк. Лейкхаус - тоже зоопарк. Нельзя уйти от зоопарка технологий, но можно выбрать зоопарк себе по вкусу, в котором приятнее жить.
4️⃣ Развитие технологий спиральное. Сейчас виток разделения вычислений и хранения, рано или поздно сольемся обратно. Но текущий тренд - разделение.
5️⃣ Точно будем пилить свой мета-каталог. Опен-сорсные не устраивают по своей зрелости.
6️⃣ Тренд - умные метакаталоги. Нужен развитый RBAC на уровне каталога. Нужны умные метаданные, развитые кеши данных и мета-данных. Нужны элементы дата-гавернанс на уровне мета-каталога. Дата контракты на уровне метастора - в Gravitino уже есть.
Про экономику данных и миграцию
💯 Первые 100 ТБ мигрировали с Data Vault в Greenplum на Data Vault в Lakehouse за 1-2 месяца.
2️⃣ Лейкхаус дает больший оверхед на старте по железу, большие требования к сети. Но это окупается за счет того что одна команда работает со всеми юз-кейсами данных. Выгоднее купить больше железа, но обойтись одной командой разработки, одним релизным процессом, одной проверкой качества и т.д.
3️⃣ Также получаем более дешевое и быстрое развитие по росту объема и сложности данных. И технологическую модульность.
4️⃣ Эффективен путь RnD и пилотов. Пробуйте в облаках, где много готовых сервисов от многих вендоров. Пробуйте у себя на железе - для грамотного ДевОпса развернуть лейкхаус из доступных компонентов - тривиальная задача
5️⃣ Тестируйтесь на своих данных и своих задачах перед внедрением. Любые попугаи публичных тестов нерелевантны.
-----------------------------
Запись "Разговоров"
-----------------------------
Архитектор данных
-----------------------------
Про хранилища данных
1️⃣ Зрелое хранилище - это когда процессы-потребители данных ходят в ХД напрямую, минуя этап обратного ETL, загрузки данных батчами из подготовленных витрин куда-то в отдельную продовую систему.
2️⃣ Много разнородных потребителей - это реальность современного развитого ХД, с высокой ожидаемой ценностью для бизнеса. Проблема роста - в росте количества и разнообразия потребителей в большей степени, чем в объеме данных.
3️⃣ Стриминг и суб-минутные / секундные прогрузки данных: 10 лет назад мечта, сегодня - реальность и необходимость.
4️⃣ Транзакционность в аналитической системе - упрощает код, упрощает и ускоряет работу дата инженеров, понижает требуемую квалификацию дата инженера. Очень приятно работать со сложной системой так, будто это классическая СУБД с транзакциями.
Про лейкхаус
1️⃣ Ключевая технология, отличающая Lake и LakeHouse - формат данных и транзакционность.
2️⃣ Лейкхаус помогает убрать ненужные перегрузки данных из системы в систему. Причем надо понимать, что каждая продовая переливка из А в Б это а) стейджинговые и промежуточные слои, многократное дублирование данных, б) код, в) команда, которая поддерживает код и пайплайны, г) доп нагрузка на чтение в А и запись в Б. Если можно этого не делать, то получаем огромную экономию в лонг-ране.
3️⃣ «Старый» стек (Greenplum + Hadoop, + Clickhouse + …) - зоопарк. Лейкхаус - тоже зоопарк. Нельзя уйти от зоопарка технологий, но можно выбрать зоопарк себе по вкусу, в котором приятнее жить.
4️⃣ Развитие технологий спиральное. Сейчас виток разделения вычислений и хранения, рано или поздно сольемся обратно. Но текущий тренд - разделение.
5️⃣ Точно будем пилить свой мета-каталог. Опен-сорсные не устраивают по своей зрелости.
6️⃣ Тренд - умные метакаталоги. Нужен развитый RBAC на уровне каталога. Нужны умные метаданные, развитые кеши данных и мета-данных. Нужны элементы дата-гавернанс на уровне мета-каталога. Дата контракты на уровне метастора - в Gravitino уже есть.
Про экономику данных и миграцию
2️⃣ Лейкхаус дает больший оверхед на старте по железу, большие требования к сети. Но это окупается за счет того что одна команда работает со всеми юз-кейсами данных. Выгоднее купить больше железа, но обойтись одной командой разработки, одним релизным процессом, одной проверкой качества и т.д.
3️⃣ Также получаем более дешевое и быстрое развитие по росту объема и сложности данных. И технологическую модульность.
4️⃣ Эффективен путь RnD и пилотов. Пробуйте в облаках, где много готовых сервисов от многих вендоров. Пробуйте у себя на железе - для грамотного ДевОпса развернуть лейкхаус из доступных компонентов - тривиальная задача
5️⃣ Тестируйтесь на своих данных и своих задачах перед внедрением. Любые попугаи публичных тестов нерелевантны.
-----------------------------
Запись "Разговоров"
-----------------------------
Архитектор данных
-----------------------------
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Архитектор Данных
Запись стрима "Разговоры на Архитекторском" с Вадимом Беловым, X5.
-----------------------------
Архитектор данных
-----------------------------
-----------------------------
Архитектор данных
-----------------------------
Forwarded from DeepSchool
Ускоряем LLM на раз, два, три
Иметь личного ассистента на ноуте и запускать мощную модель локально — хорошо. Тратить огромные ресурсы на это — уже не очень.
В новой статье разбираем ключевые методы ускорения и обсуждаем, что действительно работает:
— фреймворки для инференса — какой выбрать, чтобы выжать максимум
— спекулятивное декодирование — почему это must-have для скорости
— квантование — как правильно применять и почему оно превратилось в «народный» метод ускорения
А ещё в статье мы вспоминаем базу — Flash-Attention, технологию, которая помогла развить популяризацию LLM в целом 🚀
Читайте по ссылке!
Иметь личного ассистента на ноуте и запускать мощную модель локально — хорошо. Тратить огромные ресурсы на это — уже не очень.
В новой статье разбираем ключевые методы ускорения и обсуждаем, что действительно работает:
— фреймворки для инференса — какой выбрать, чтобы выжать максимум
— спекулятивное декодирование — почему это must-have для скорости
— квантование — как правильно применять и почему оно превратилось в «народный» метод ускорения
А ещё в статье мы вспоминаем базу — Flash-Attention, технологию, которая помогла развить популяризацию LLM в целом 🚀
Читайте по ссылке!
DeepSchool
3 фишки для ускорения LLM - DeepSchool
Ускорение инференса LLM: фреймворки, квантование, оптимизация.
Forwarded from Dealer.AI
Рефлексия о работе в 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 и пустить на бой, ибо это вызывало шок, вострог и вау. Чуваки делали несколько месяцев экспы и никто их не хватился, до нужного момента. И вот такая исследовательская группа удивила. Вот так это и работает в такой архитектуре процессов.
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 и пустить на бой, ибо это вызывало шок, вострог и вау. Чуваки делали несколько месяцев экспы и никто их не хватился, до нужного момента. И вот такая исследовательская группа удивила. Вот так это и работает в такой архитектуре процессов.
Forwarded from Tensor Banana
Wan2.2 A14B 3-шаговый воркфлоу для t2v, t2i, img2img и апскейла видео
- 3 шага подходят для малого числа кадров: от 1 до 65 при 720р. При 81+ кадре этого уже не хватает, будет цветной шум, надо больше шагов. Чем больше разрешение и число кадров - тем больше шагов. Для 480р трёх шагов хватит на 81 кадр.
- если виден цветной шум: увеличить силу лоры FusionX у обоих моделей, либо увеличить число шагов.
- фото лучше делать в разрешении 1920х1080 и 1080х1536. Детализация офигенная. Пример в хайрез: https://raw.githubusercontent.com/Mozer/comfy_stuff/refs/heads/main/output/ComfyUI_06056_.png
- Вертикальные фото/видео с высотой больше 1500 лучше не делать, будут искажения геометрии.
- в исходном воркфлоу от comfy anonymous стоят верные настройки для передачи шума между сэмплерами. В популярных на реддите воркфлоу на 4 шага - стоят неканонические зачения. В них страдает детализация и текстура кожи.
- малая модель на 5B мне не понравилась, похожа на 1.3b по качеству.
- странный факт: 5B работает в 24fps и A14B в 16fps
- промпты для видео брал с сайтов Вана: https://wan.video/explore и flow tv (Veo): https://labs.google/flow/tv/channels
- cсылки на Лоры (fusionx, lightxt2, smartphone) внутри воркфлоу.
- озвучку делал в mmaudio: https://huggingface.co/spaces/hkchengrex/MMAudio
- если не считать отсутствие звука и речи, то визуально ван 2.2 очень похож на veo3.
- с img2img прикольно переделывать аниме в реализм и обновлять графику старым играм (можно попроботь через video2video для старых игр). Регулировать силу исходной картинки приходится с помощью числа шагов и их соотношения на первом сэмплере.
- апскейл видео слегка меняет лицо. чем больше шагов тем чётче картинка, но дальше от оригинала. 1+2 и 1+3 шага - оптимальны.
- weight_dtype fp8e5m не работает на 3090 (шумит), используйте fp8_e4m3fn_fast
- старые лоры - работают.
Скорость на 3090:
- видео 1280x720 49 кадров, 1+2 шага: 6 минут с интерполяцией
- фото 1920х1088 2+2 шага: 1 минута
- video2video 480p 97 кадров 1+3 шага: 6 минут с интерполяцией
- на 16 гигах врам пойдет, но не надо ставить разрешение 720р и 121 кадр - иначе время генерации будет 14 часов.
- ещё ждём teaCache для скорости.
Примеры промптов:
- Икеа:
- Бабка и яма:
- куклы за столом:
мои воркфлоу для A14B: https://github.com/Mozer/comfy_stuff/tree/main/workflows/wan2.2
попробовать wan2.2 (i2v - бесплатно, долго; t2v - 10 кредитов): https://wan.video/generate
- 3 шага подходят для малого числа кадров: от 1 до 65 при 720р. При 81+ кадре этого уже не хватает, будет цветной шум, надо больше шагов. Чем больше разрешение и число кадров - тем больше шагов. Для 480р трёх шагов хватит на 81 кадр.
- если виден цветной шум: увеличить силу лоры FusionX у обоих моделей, либо увеличить число шагов.
- фото лучше делать в разрешении 1920х1080 и 1080х1536. Детализация офигенная. Пример в хайрез: https://raw.githubusercontent.com/Mozer/comfy_stuff/refs/heads/main/output/ComfyUI_06056_.png
- Вертикальные фото/видео с высотой больше 1500 лучше не делать, будут искажения геометрии.
- в исходном воркфлоу от comfy anonymous стоят верные настройки для передачи шума между сэмплерами. В популярных на реддите воркфлоу на 4 шага - стоят неканонические зачения. В них страдает детализация и текстура кожи.
- малая модель на 5B мне не понравилась, похожа на 1.3b по качеству.
- странный факт: 5B работает в 24fps и A14B в 16fps
- промпты для видео брал с сайтов Вана: https://wan.video/explore и flow tv (Veo): https://labs.google/flow/tv/channels
- cсылки на Лоры (fusionx, lightxt2, smartphone) внутри воркфлоу.
- озвучку делал в mmaudio: https://huggingface.co/spaces/hkchengrex/MMAudio
- если не считать отсутствие звука и речи, то визуально ван 2.2 очень похож на veo3.
- с img2img прикольно переделывать аниме в реализм и обновлять графику старым играм (можно попроботь через video2video для старых игр). Регулировать силу исходной картинки приходится с помощью числа шагов и их соотношения на первом сэмплере.
- апскейл видео слегка меняет лицо. чем больше шагов тем чётче картинка, но дальше от оригинала. 1+2 и 1+3 шага - оптимальны.
- weight_dtype fp8e5m не работает на 3090 (шумит), используйте fp8_e4m3fn_fast
- старые лоры - работают.
Скорость на 3090:
- видео 1280x720 49 кадров, 1+2 шага: 6 минут с интерполяцией
- фото 1920х1088 2+2 шага: 1 минута
- video2video 480p 97 кадров 1+3 шага: 6 минут с интерполяцией
- на 16 гигах врам пойдет, но не надо ставить разрешение 720р и 121 кадр - иначе время генерации будет 14 часов.
- ещё ждём teaCache для скорости.
Примеры промптов:
- Икеа:
Cinematic shot of a sunlit empty Scandinavian bedroom. A sealed IKEA box trembles, opens, and flat pack furniture assembles rapidly into a stylish IKEA bedroom with bed, table, chair and other furniture. fixed wide angle, lighting: natural warm with cool accents, room: Scandinavian bedroom, elements: IKEA box (logo visible), Start: empty room at the beginning, then box opens, furniture assembles precisely and rapidly, ending: calm, modern bedroom with yellow IKEA accent. Furniture at the end: bed with yellow throw, bedside tables, lamps, wardrobe, shelves, mirror, art, rug, curtains, reading chair, plants- Бабка и яма:
A TV news report from the streets of the Russian hinterland. The news anchor woman speaks into a microphone in Russian: "A huge pit has appeared in our city for three years now." At this time, in the background, a Russian grandmother with two heavy bags walks down the street and falls into a huge pit filled with water. The atmosphere is comical, with a deliberately serious tone of reporting. Photorealistic 4k 60fps video- куклы за столом:
In a dimly lit Victorian-style living room, lace curtains flutter gently. muppets toys (kermit and others) sit around a round table, their figures illuminated by flickering candlelight. A whisper makes the porcelain teacups tremble, and the eyes in the paintings shift uneasily. Each slow, deliberate stop-motion frame heightens the tension. The camera pans slowly to the right, capturing every subtle movement of the puppets, enhancing the eerie atmosphere. The furniture and decorations in the background are clearly detailed.мои воркфлоу для A14B: https://github.com/Mozer/comfy_stuff/tree/main/workflows/wan2.2
попробовать wan2.2 (i2v - бесплатно, долго; t2v - 10 кредитов): https://wan.video/generate
Forwarded from Поступашки - ШАД, Стажировки и Магистратура
Отбор в Сбер на дата инженера (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
Сейчас идут последние часы скидки на наши новые карьерные курсы, которые стартуют уже завтра, и еще можно записаться.
Ниже рассказ выпускника нашего курса дата инженер. Далее текст слегка отредактирован.
Собесился в команду построения витрин данных для выявления подозрительных операций. По работе все стандартно — написание 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