Forwarded from Метаверсище и ИИще (Sergey Tsyptsyn ️️)
This media is not supported in your browser
VIEW IN TELEGRAM
А вы знали, что в Veo-3 можно просто нарисовать на первом кадре визуальные инструкции: всякия стрелочки, подписи типа "сюда не ходи снег башка попадет". И Veo3 это пережует и поймет. Экономия на промптах. И никакого джайсона.
@cgevent
@cgevent
Черепашки - Народная
Suno 4.5+ — кайф. 😮
Давайте поговорим про функцию Cover в Suno. Точнее, послушаем. Сделал мини-альбом каверов на опенинг из старого мультика про Черепашек-ниндзя.
Если коротко: Cover — круто. Загружаете мелодию / трек / напев с микрофона, крутите настройки, пишете промт — и у вас качественный кавер в любой аранжировке за минуту. Если бы я был музыкантом — сочинял бы черновики и сразу прогонял их через Cover, чтобы протестировать разные ходы, а потом писал на чистовую.
Несколько особенностей по моим тестам:
1) Не даёт загружать известные треки и тексты.
Но, например, русский рок за "известную музыку" особо не считается.
Если ругается на текст — попробуйте заменить некоторые буквы на фонетически близкие или убрать один куплет.
2) Настройки. Есть три ползунка:
🥴 Weirdness — лучше не трогать или понижать.
Выше 50% — и начинается каша.
😎 Style Influence — влияет на силу промта.
Для каверов хорошо работает диапазон 80–100%.
🎧 Audio Influence — определяет, насколько кавер будет близок к загруженному аудио по структуре и мелодике. Здесь всё зависит от жанра и задачи.
У меня хорошо работало в диапазоне 10–50% — чтобы модель интерпретировала по-своему, но сохраняла узнаваемость оригинала.
Естественно, только в платной подписке (но это того стоит).🙃
P.S: Почему-то при репосте поста с приклеенным аудио не отображается канал. Знайте, что он из Ai molodca. Ну и подписывайтесь!
Давайте поговорим про функцию Cover в Suno. Точнее, послушаем. Сделал мини-альбом каверов на опенинг из старого мультика про Черепашек-ниндзя.
Если коротко: Cover — круто. Загружаете мелодию / трек / напев с микрофона, крутите настройки, пишете промт — и у вас качественный кавер в любой аранжировке за минуту. Если бы я был музыкантом — сочинял бы черновики и сразу прогонял их через Cover, чтобы протестировать разные ходы, а потом писал на чистовую.
Несколько особенностей по моим тестам:
1) Не даёт загружать известные треки и тексты.
Но, например, русский рок за "известную музыку" особо не считается.
Если ругается на текст — попробуйте заменить некоторые буквы на фонетически близкие или убрать один куплет.
2) Настройки. Есть три ползунка:
Выше 50% — и начинается каша.
Для каверов хорошо работает диапазон 80–100%.
У меня хорошо работало в диапазоне 10–50% — чтобы модель интерпретировала по-своему, но сохраняла узнаваемость оригинала.
Естественно, только в платной подписке (но это того стоит).
P.S: Почему-то при репосте поста с приклеенным аудио не отображается канал. Знайте, что он из Ai molodca. Ну и подписывайтесь!
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Кодим на Коленке | Уроки по программированию
Full-Stack копия Twitch
Пишем свою копию твич с нуля. Все, включая фронт и бэк
🗝 Курс живет здесь
Кодим на Коленке | #web
Пишем свою копию твич с нуля. Все, включая фронт и бэк
🗝 Курс живет здесь
Кодим на Коленке | #web
Forwarded from Тимлид Очевидность | Евгений Антонов
Я принес. Тимлид: есть ли свет в конце тоннеля?
Сегодня вам принес свой свежий доклад с недавно прошедшего питерского тимлидконфа.
https://youtu.be/c3U5hGF09uc
Тимлидконф был, как всегда, гостеприимен, заботлив и профессионален ко всем своим спикерам. Отдельную радость я испытал от того, что можно было выступить дома. Ну и еще радость от того, что я могу говорить про Санкт-Петербург, что это уже не просто где-то там, а по-настоящему дома.
Фан-факт. Мы частенько встречаемся на разных конференциях с некоторыми ребятами, и многие почему-то думали, что я из Москвы. Ан нет, гордый петербуржец в нулевом поколении 🙂
В докладе я постарался развенчать миф, что тимлид — это карьерный тупик и вендор-лок на текущую компанию. Привел примеры, куда еще можно двигаться по карьере из тимлидов.
А еще совершенно нормально, если вы тимлид и вам не хочется никуда двигаться. Работу работаете, дело делаете, вас, команду и руководство всё устраивает, ну и поздравляю, вы нашли свой баланс. Я против того, что прям ОБЯЗАТЕЛЬНО надо куда-то двигаться из тимлидов. Надо только когда вам там или плохо, или хочется большего, или меньшего, или чего-то новенького.
Сегодня вам принес свой свежий доклад с недавно прошедшего питерского тимлидконфа.
https://youtu.be/c3U5hGF09uc
Тимлидконф был, как всегда, гостеприимен, заботлив и профессионален ко всем своим спикерам. Отдельную радость я испытал от того, что можно было выступить дома. Ну и еще радость от того, что я могу говорить про Санкт-Петербург, что это уже не просто где-то там, а по-настоящему дома.
Фан-факт. Мы частенько встречаемся на разных конференциях с некоторыми ребятами, и многие почему-то думали, что я из Москвы. Ан нет, гордый петербуржец в нулевом поколении 🙂
В докладе я постарался развенчать миф, что тимлид — это карьерный тупик и вендор-лок на текущую компанию. Привел примеры, куда еще можно двигаться по карьере из тимлидов.
А еще совершенно нормально, если вы тимлид и вам не хочется никуда двигаться. Работу работаете, дело делаете, вас, команду и руководство всё устраивает, ну и поздравляю, вы нашли свой баланс. Я против того, что прям ОБЯЗАТЕЛЬНО надо куда-то двигаться из тимлидов. Надо только когда вам там или плохо, или хочется большего, или меньшего, или чего-то новенького.
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