Forwarded from Dealer.AI
Cohere 3.5 с обновой Reranker.
Конкуренты антропика в домене RAG не дремлют. Cohere 3.5 новый базированный пайп e2e RAG. Тут всё, как мы любим: и преранк на эмбедах и реранк на кросс-энкодере. При этом ребята обновили механизм внимания для улучшения работы с контекстом намерений пользователя. Как утверждают авторы — цель закрыть эксплицитную и имплицитную часть запросов кожАнных. Помимо этого, добавлены новые сеты для 100+ языков по различным доменным запросам (наука,финансы и тп.). Все это дало значимый бОльший прирост к метрикам поиска. Также,напоминаю,что у ребят есть и мультимодальный эмбеддер.
Cohere прекрасный пример того,как можно зарабатывать на сервисе вокруг <your favourite LLM>. Помним,еще подобное и у perplexity.
Радуемся, следим, юзаем.
Конкуренты антропика в домене RAG не дремлют. Cohere 3.5 новый базированный пайп e2e RAG. Тут всё, как мы любим: и преранк на эмбедах и реранк на кросс-энкодере. При этом ребята обновили механизм внимания для улучшения работы с контекстом намерений пользователя. Как утверждают авторы — цель закрыть эксплицитную и имплицитную часть запросов кожАнных. Помимо этого, добавлены новые сеты для 100+ языков по различным доменным запросам (наука,финансы и тп.). Все это дало значимый бОльший прирост к метрикам поиска. Также,напоминаю,что у ребят есть и мультимодальный эмбеддер.
Cohere прекрасный пример того,как можно зарабатывать на сервисе вокруг <your favourite LLM>. Помним,еще подобное и у perplexity.
Радуемся, следим, юзаем.
Cohere
Introducing Rerank 3.5: Precise AI Search | Cohere Blog
Rerank 3.5 delivers improved reasoning and multilingual capabilities to search complex enterprise data with greater accuracy.
#interesting
Не по теме канала, но мне кажется, что вот этот человек довольно основательно подходит к контенту - публикует инфу с исследованиями и сам собирает выводы
Не по теме канала, но мне кажется, что вот этот человек довольно основательно подходит к контенту - публикует инфу с исследованиями и сам собирает выводы
Forwarded from CleverMind
Топ 5 роликов CleverMind
Каналу на ютубе почти 10 лет (дааа.. получается уже половину сознательной жизни увлечен нейробиологией, фармой и бадами🤯).
В общем, решил выбрать 5 наиболее важных, на мой взгляд, сюжетов. Я б хотел увидеть именно эти ролики на старте своего увлечения. Это бы сэкономило 2-3 года в наборе опыта.
1. Анализы. Как сдавать, когда, как оценить результат. Это то, что может тебе открыть глаза на причины твоей субдепрессии, тревожности или низкой мотивации👀
https://www.youtube.com/watch?v=-9h3iSFh4nI
2. Как перепрошить свою психику. Если ты захочешь стать новой версией себя самого🧠
https://www.youtube.com/watch?v=7vNTFgGejx8
3. Авторский выпуск о своем опыте в биохакинге. Концентрат личного опыта, считай🌭
https://www.youtube.com/watch?v=okbYe4o3qJU
4. Социальное направление – Как показаться нормальным в обществе🍾
https://www.youtube.com/watch?v=aFrmSCCkPUU
5. Ну и один из самых популярных – Как Увеличить Тестостерон: Выпуск без херни🍳
https://www.youtube.com/watch?v=imS-DRS0Klw
П.С. В этом месяце постараюсь выложить выпуски про ХГЧ и потом про Витамин Д👌
Каналу на ютубе почти 10 лет (дааа.. получается уже половину сознательной жизни увлечен нейробиологией, фармой и бадами🤯).
В общем, решил выбрать 5 наиболее важных, на мой взгляд, сюжетов. Я б хотел увидеть именно эти ролики на старте своего увлечения. Это бы сэкономило 2-3 года в наборе опыта.
1. Анализы. Как сдавать, когда, как оценить результат. Это то, что может тебе открыть глаза на причины твоей субдепрессии, тревожности или низкой мотивации👀
https://www.youtube.com/watch?v=-9h3iSFh4nI
2. Как перепрошить свою психику. Если ты захочешь стать новой версией себя самого🧠
https://www.youtube.com/watch?v=7vNTFgGejx8
3. Авторский выпуск о своем опыте в биохакинге. Концентрат личного опыта, считай🌭
https://www.youtube.com/watch?v=okbYe4o3qJU
4. Социальное направление – Как показаться нормальным в обществе🍾
https://www.youtube.com/watch?v=aFrmSCCkPUU
5. Ну и один из самых популярных – Как Увеличить Тестостерон: Выпуск без херни🍳
https://www.youtube.com/watch?v=imS-DRS0Klw
П.С. В этом месяце постараюсь выложить выпуски про ХГЧ и потом про Витамин Д👌
YouTube
Как и Зачем Сдавать АНАЛИЗЫ на ГОРМОНЫ. Как Понять Результат
Как определить свой холестерин, тестостерон и т.д. Какие нужно сдать анализы? Нафиг оно вообще тебе надо и почему это улучшит тебе жизнь? Как сдать бесплатно? Как понять результат?
Сегодня все самое важное!
ДОБАВКИ от CLEVERMIND (чтоб отлично себя чувствовать)…
Сегодня все самое важное!
ДОБАВКИ от CLEVERMIND (чтоб отлично себя чувствовать)…
Forwarded from Персонализация неизбежна
Метрики оценки качества рекомендательных систем: что мне кажется важным
В этом посте я собрал основные накопленные мною знания и сгруппировал их по основным концепциям.
Accuracy vs beyond-accuracy метрики:
Accuracy измеряет, насколько точно алгоритм предсказывает "ground truth". Ground truth - это пары user-item, которые действительно встречались в данных, то есть было взаимодействие между user-item.
Beyond-accuracy - это такие метрики, которые важны "после точности" (=при прочих равных). Если две модели дают одинаковые метрики точности, но вторая умудрилась рекомендовать менее популярные айтемы/более разнообразные категории - она, скорее всего, лучше. Максимизация beyond-accuracy метрик важна при сохранении точности. Пример - если хотите выдавать разнообразные рекомендации, можно просто выдавать всем рандомные айтемы. Это даст максимальный результат, но вас вряд ли это устроит.
Между accuracy и beyond-accuracy обычно есть размен (отдаешь точность, повышаешь новизну). Размен бывает разной степени выгоды, для примера советую глянуть статью Саши Петрова (таблица 3 и рисунки 4-5)
Основные метрики качества
Accuracy:
1) NDCG@K/MAP@K/MRR@K измеряют, насколько близко ground truth объекты находятся близко к началу списка.
2) Recall@k/precision@k/HR@K - метрики оценивают список из k элементов целиком (= метрика не поменяется, если внутри k элементов перемешать список)
Beyond-accuracy:
1) Diversity (разнообразие). Есть как минимум три вида: а) внутри списка одного юзера (чтобы не показывать айтемы только одного типа) б) про отличие рекомендаций между юзерами (то есть не показываем ли мы всем одно и то же), в) рекомендаций у одного юзера с течением времени (меняется ли у пользователя лента или нет)
2) Popular/novelty показывает, насколько популярные/новые айтемы в среднем рекомендуются. Если популярность меньше, от этого, как правило, много плюсов.
3) User/item Covarage показывает какая доля юзеров/айтемов используется и показывается
4) Fairness. Тут очень широкий смысл. Например, насколько айтемы одинаково хорошо рекомендуются? Правда ли, что у юзеров одинаково хорошая персонализация?. Например, рандомные рекомендации одинаково честны ко всем айтемам - они дают им одинаковый процент влияния. Есть интересный туториал.
5) Serendipity - насколько пользователя "удивляют" рекомендации. Как написано в обзоре на эту тему, нет точного понимания как это считать единым и единственно верным способом
Accuracy метрики важно знать, они достаточно точны в определениях. Beyond-accuracy метрики более обширны, их скорее следует понимать и уметь адаптировать под конкретную задачу. Не зря на fairness/serendipity есть по отдельному обзору. Также замечал, что Recall@k иногда считают по-разному (делят либо на min(k, |gt items|), либо на |gt items|), MAP@K иногда определяют двумя разными способами.
Retrieval vs ranking.
Глобально, метрики качества считаются в двух основных вариантах:
Retrieval оценивает качество генерации кандидатов, либо просто "угадывание" айтемов. Множество рекоендуемых айтемов - максимально возможное (весь каталог, или то, что может порекомендовать модель). Ground truth - это реальные интеракции пользователя, и их надо угадать. Но ключевое: модель может порекомендовать юзеру все что угодно.
Ranking. У нас есть сэмплы user-item-timstamp-label. Это могут быть просмотры какой-то ленты, или просто факты того, что юзер видел. Задача алгоритма - отранжировать items из этого множества, чтобы вверху оказались полезные действия (клики/лайки/покупки). Отличие от retrieval: в ranking сетапе модель ранжирует только те айтемы, которые юзер, скорее всего, видел, и множество айтемов сильно сужено.
Иногда в статьях делают negative sampling для оценки метрик. Берут позитивный айтем, и рандомно/по популярности 100 айтемов из каталога. Ранжируют одно против другого. Это может привести к плохим последствиям (вы неверно найдете лучшую модель), и в моей парадигме это как раз "ranking".
В этом посте я собрал основные накопленные мною знания и сгруппировал их по основным концепциям.
Accuracy vs beyond-accuracy метрики:
Accuracy измеряет, насколько точно алгоритм предсказывает "ground truth". Ground truth - это пары user-item, которые действительно встречались в данных, то есть было взаимодействие между user-item.
Beyond-accuracy - это такие метрики, которые важны "после точности" (=при прочих равных). Если две модели дают одинаковые метрики точности, но вторая умудрилась рекомендовать менее популярные айтемы/более разнообразные категории - она, скорее всего, лучше. Максимизация beyond-accuracy метрик важна при сохранении точности. Пример - если хотите выдавать разнообразные рекомендации, можно просто выдавать всем рандомные айтемы. Это даст максимальный результат, но вас вряд ли это устроит.
Между accuracy и beyond-accuracy обычно есть размен (отдаешь точность, повышаешь новизну). Размен бывает разной степени выгоды, для примера советую глянуть статью Саши Петрова (таблица 3 и рисунки 4-5)
Основные метрики качества
Accuracy:
1) NDCG@K/MAP@K/MRR@K измеряют, насколько близко ground truth объекты находятся близко к началу списка.
2) Recall@k/precision@k/HR@K - метрики оценивают список из k элементов целиком (= метрика не поменяется, если внутри k элементов перемешать список)
Beyond-accuracy:
1) Diversity (разнообразие). Есть как минимум три вида: а) внутри списка одного юзера (чтобы не показывать айтемы только одного типа) б) про отличие рекомендаций между юзерами (то есть не показываем ли мы всем одно и то же), в) рекомендаций у одного юзера с течением времени (меняется ли у пользователя лента или нет)
2) Popular/novelty показывает, насколько популярные/новые айтемы в среднем рекомендуются. Если популярность меньше, от этого, как правило, много плюсов.
3) User/item Covarage показывает какая доля юзеров/айтемов используется и показывается
4) Fairness. Тут очень широкий смысл. Например, насколько айтемы одинаково хорошо рекомендуются? Правда ли, что у юзеров одинаково хорошая персонализация?. Например, рандомные рекомендации одинаково честны ко всем айтемам - они дают им одинаковый процент влияния. Есть интересный туториал.
5) Serendipity - насколько пользователя "удивляют" рекомендации. Как написано в обзоре на эту тему, нет точного понимания как это считать единым и единственно верным способом
Accuracy метрики важно знать, они достаточно точны в определениях. Beyond-accuracy метрики более обширны, их скорее следует понимать и уметь адаптировать под конкретную задачу. Не зря на fairness/serendipity есть по отдельному обзору. Также замечал, что Recall@k иногда считают по-разному (делят либо на min(k, |gt items|), либо на |gt items|), MAP@K иногда определяют двумя разными способами.
Retrieval vs ranking.
Глобально, метрики качества считаются в двух основных вариантах:
Retrieval оценивает качество генерации кандидатов, либо просто "угадывание" айтемов. Множество рекоендуемых айтемов - максимально возможное (весь каталог, или то, что может порекомендовать модель). Ground truth - это реальные интеракции пользователя, и их надо угадать. Но ключевое: модель может порекомендовать юзеру все что угодно.
Ranking. У нас есть сэмплы user-item-timstamp-label. Это могут быть просмотры какой-то ленты, или просто факты того, что юзер видел. Задача алгоритма - отранжировать items из этого множества, чтобы вверху оказались полезные действия (клики/лайки/покупки). Отличие от retrieval: в ranking сетапе модель ранжирует только те айтемы, которые юзер, скорее всего, видел, и множество айтемов сильно сужено.
Иногда в статьях делают negative sampling для оценки метрик. Берут позитивный айтем, и рандомно/по популярности 100 айтемов из каталога. Ранжируют одно против другого. Это может привести к плохим последствиям (вы неверно найдете лучшую модель), и в моей парадигме это как раз "ranking".
Forwarded from Персонализация неизбежна
Offline vs online vs business metrics
Метрики качества можно считать в оффлайне на исторических данных или онлайне. Онлайн - это когда применяется оцениваемый алгоритм. В оффлайне на исторических данных применялось (или не применялось) что-то другое. NDCG@k, Recall@k, Precision@k, MAP@K и т.д. можно считать и в оффлайне и в онлайне. Beyond-accuracy метрики (diversity/coverage, и др.) в retrieval сетапе нет смысла делить на онлайн/оффлайн, но в ranking варианте из-за ограниченного множества айтемов, они будут другими.
Бизнес метрики - это все, что важно продукту (ctr/продажи/число лайков/retention, ...). Бизнес метрики алгоритма всегда считаются в онлайне. Но онлайн метрики - не бизнес метрики, а более широкое понятие.
Парадокс онлайн метрик ранжирования.
Пусть будут две модели "А" и "Б". Двум разным юзерам они порекомендовали некоторые айтемы, и первый юзер накликал по убыванию ранга [1, 0, 0, 0], а второй пользователь - [1, 0, 0, 1]. Первый юзер кликнул только на первый айтем, второй на первый и четвертый. NDCG у первого юзера 1, у второго <1. Recall@1 у первого - 1, у второго Recall@1=0.5. Получается, у первого юзера метрики ранжирования лучше, но если нам важно число кликов, то, очевидно, второй случай лучше, ведь там два клика. Поэтому, если важны клики, и метрики ранжирования считаются в онлайне, то этот парадокс надо учитывать.
Выиграть в оффлайн метрике не значит выиграть АБ-тест
Основной подвох в том, что если модель А лучше модели Б на какой-то оффлайн метрике, то на онлайн тесте модель А может заминусить бизнес метрики. На это есть множество причин. Можно пробовать искать такую оффлайн метрику, рост которой будет означать увеличение нужной бизнес метрики. Например, доклад от Тихонович Даши. Но если ваши оффлайн метрики не коррелируют с АБ, то тогда под вопросом вообще необходимость оффлайн оценки метрик качества. В retrieval сетапе оценить двух кандидато-генераторов и заметить отличие по точности в два раза, скорее всего, нужно и полезно. Увидеть увеличение в ranking сетапе на 3% и запускать АБ-тест - уже сомнительно, зависит от продукта. Эта тема заслуживает отдельного поста.
Источник сбора ground truth и "просмотров" могут быть важнее, чем выбор метрики
Супер важно понимать, какие именно интеракции вы заложили на ground truth. Есть открытый датасет Movielens, там есть рейтинги от 1 до 5. Если взять все рейтинги в качестве ground truth, то вы будете оценивать, насколько модель хорошо предсказывает фильмы, которым человек поставил рейтинг как 5, так и 1. И "лучшей" может оказаться модель, которая нарекомендует фильмы, которые человек оценит на 1. Поэтому лучше брать только те интеракции, где человек ставил 4-5, и оценивать модели только с точки зрения точности таких рекомендаций. Другой пример: пусть есть данные просмотров фильмов в формате (user, item, timstamp, duration), и мы строим next-item prediction модель. Если мы на тесте оставим такие интеракции, что пользователь посмотрел фильм 1 минуту, то "хорошая" модель должна будет уметь такой фильм рекомендовать. Но точно ли это нам надо?
Итого:
Важно знать формулы метрик, упомянутых выше. Но еще важнее понимать, зачем и на основе каких данных нужно их считать. Метрики - это лишь инструмент, который эффективен только в случае хорошего понимания его области принимости. Также, возможно, позже напишу подробнее про проблему корреляции оффлайн-онлайн метрик
Метрики качества можно считать в оффлайне на исторических данных или онлайне. Онлайн - это когда применяется оцениваемый алгоритм. В оффлайне на исторических данных применялось (или не применялось) что-то другое. NDCG@k, Recall@k, Precision@k, MAP@K и т.д. можно считать и в оффлайне и в онлайне. Beyond-accuracy метрики (diversity/coverage, и др.) в retrieval сетапе нет смысла делить на онлайн/оффлайн, но в ranking варианте из-за ограниченного множества айтемов, они будут другими.
Бизнес метрики - это все, что важно продукту (ctr/продажи/число лайков/retention, ...). Бизнес метрики алгоритма всегда считаются в онлайне. Но онлайн метрики - не бизнес метрики, а более широкое понятие.
Парадокс онлайн метрик ранжирования.
Пусть будут две модели "А" и "Б". Двум разным юзерам они порекомендовали некоторые айтемы, и первый юзер накликал по убыванию ранга [1, 0, 0, 0], а второй пользователь - [1, 0, 0, 1]. Первый юзер кликнул только на первый айтем, второй на первый и четвертый. NDCG у первого юзера 1, у второго <1. Recall@1 у первого - 1, у второго Recall@1=0.5. Получается, у первого юзера метрики ранжирования лучше, но если нам важно число кликов, то, очевидно, второй случай лучше, ведь там два клика. Поэтому, если важны клики, и метрики ранжирования считаются в онлайне, то этот парадокс надо учитывать.
Выиграть в оффлайн метрике не значит выиграть АБ-тест
Основной подвох в том, что если модель А лучше модели Б на какой-то оффлайн метрике, то на онлайн тесте модель А может заминусить бизнес метрики. На это есть множество причин. Можно пробовать искать такую оффлайн метрику, рост которой будет означать увеличение нужной бизнес метрики. Например, доклад от Тихонович Даши. Но если ваши оффлайн метрики не коррелируют с АБ, то тогда под вопросом вообще необходимость оффлайн оценки метрик качества. В retrieval сетапе оценить двух кандидато-генераторов и заметить отличие по точности в два раза, скорее всего, нужно и полезно. Увидеть увеличение в ranking сетапе на 3% и запускать АБ-тест - уже сомнительно, зависит от продукта. Эта тема заслуживает отдельного поста.
Источник сбора ground truth и "просмотров" могут быть важнее, чем выбор метрики
Супер важно понимать, какие именно интеракции вы заложили на ground truth. Есть открытый датасет Movielens, там есть рейтинги от 1 до 5. Если взять все рейтинги в качестве ground truth, то вы будете оценивать, насколько модель хорошо предсказывает фильмы, которым человек поставил рейтинг как 5, так и 1. И "лучшей" может оказаться модель, которая нарекомендует фильмы, которые человек оценит на 1. Поэтому лучше брать только те интеракции, где человек ставил 4-5, и оценивать модели только с точки зрения точности таких рекомендаций. Другой пример: пусть есть данные просмотров фильмов в формате (user, item, timstamp, duration), и мы строим next-item prediction модель. Если мы на тесте оставим такие интеракции, что пользователь посмотрел фильм 1 минуту, то "хорошая" модель должна будет уметь такой фильм рекомендовать. Но точно ли это нам надо?
Итого:
Важно знать формулы метрик, упомянутых выше. Но еще важнее понимать, зачем и на основе каких данных нужно их считать. Метрики - это лишь инструмент, который эффективен только в случае хорошего понимания его области принимости. Также, возможно, позже напишу подробнее про проблему корреляции оффлайн-онлайн метрик
Forwarded from Tensor Banana
Влияние ширины PCIe на LLM и flux
GPU:
- 3090 на pcie-4.0@x4
- 2080ti на pcie-2.0@x0.5
- 3060 на pcie-2.0@x0.5
3090 сидит на отдельном GPU 750w.
2080ti + 3060 сидят на GPU 750w.
Последние 2 карты сидят на x1 через сплиттер, поэтому по факту там половина скорости от x1. На pcie x16 не тестил, на моем мини-пк его нет (есть x4 + x4 + x1). На одном из x4 сидит ssd.
Затестим скорость LLM и Flux в зависимости от количества линий pcie, на которых сидит моя 3090.
Видим, что при работе в соло с небольшими LLM или Flux практически нет просадки. Скорость изначальной загрузки модели в память, конечно, проседает, но не супер критично (гемма-27 загружается за 1-2 минуты). Заметьте, что скорость обработки входного промта до сих пор быстрая - 323 t/s, хотя тоже просела.
Флакс из-за медленной шины pcie просел на 10%. А вот тренировка лоры вообще не заметила изменений.
Работа в связке из 3-х карт с большими LLM.
А теперь затестим Gemma-27b-Q6 (21 GB) на одной карте и затем через layer-split 50/50. Просадка есть, но минимальная.
А теперь задействуем все 3 карты. pcie x4+x0.5+x0.5. 2 карты с power limit 80% и 3090 - 60% (250w)
для сравнения, с реддита:
70B-gguf_Q4 (43 GB), 2x 3090 - 15.5 t/s
70b-awq_4b (40 GB), 4x 3060 pcie3.0@8 - 14 t/s
3.3-70b_Q4, mac mini M4 Max 64gb - 7 t/s
квенов-72b не нашел
SAINEMO-reMIX-12B_q6 (9 GB)
3090, pcie 4.0x4 - 43 t/s
То есть в теории, из-за медленной шины, я теряю какую-то скорость, но я не сказал, бы что она критичная. Сравним для моей 3090 power_60%_250w, размер LLM и скорость:
9 GB, solo - 43 t/s
21 GB, solo - 20 t/s
51 GB, split_3 - 7 t/s
При увеличении размера LLM в 2 раза скорость падает в 2 раза (это норма), и скорость pcie в этом случаем особо не дает влияния.
3090 в соло режиме с маленькой LLM жрет все выделенные ей 250W (TDP у нее 420, но я ей столько не даю). То же самое и 2080ti - в соло ест отведенные 191W из 200w. Но с большой LLM раскиданной по всем картам видно, что чипы потребляют лишь половину максимальной мощности (смотрим скрин). Возможно, в остальное время они ждут друг друга или хз что там происходит.
Кстати, свежую llama-3.3-70b для русского РП не рекомендую, она сухая и зацензуренная. А вот SAINEMO-reMIX-12B (9GB) весьма рекомендую. Это смесь разных nemo-12b: saiga_nemo + vikhr_nemo + 2 англоязычных РП микса. Сейчас либо ее использую, либо magnum-v4-72b-Q5 (51GB). Athene-72b не так понравилась, цензуры больше чем в магнуме.
https://huggingface.co/mradermacher/SAINEMO-reMIX-GGUF/tree/main
Выводы: число линий pcie для маленьких LLM - пофиг. Для больших LLM - важно, но не супер критично. Для флакса (генерации и тренировки) - тоже пофиг. Получается, pcie x16 переоценен? Даешь всем по сплиттеру, который делит x1 на 4 и будет счастье? 😀
GPU:
- 3090 на pcie-4.0@x4
- 2080ti на pcie-2.0@x0.5
- 3060 на pcie-2.0@x0.5
3090 сидит на отдельном GPU 750w.
2080ti + 3060 сидят на GPU 750w.
Последние 2 карты сидят на x1 через сплиттер, поэтому по факту там половина скорости от x1. На pcie x16 не тестил, на моем мини-пк его нет (есть x4 + x4 + x1). На одном из x4 сидит ssd.
Затестим скорость LLM и Flux в зависимости от количества линий pcie, на которых сидит моя 3090.
Gemma-27b-Q6 (21 GB), 3090 power_60%_250w
pcie4.0@x1, IN 730 t/s, OUT 19.57 t/s
pcie4.0@x4, IN 780 t/s, OUT 20.43 t/s
Flux, 1024, 20steps, 3090 power_60%_250w
pcie4.0@x1, 00:28, 1.44s/it
pcie4.0@x4, 00:25, 1.29s/it
Flux lora train, 3090 power_60%_250w
pcie4.0@x1, 5.00s/it
pcie4.0@x4, 5.00s/it
Видим, что при работе в соло с небольшими LLM или Flux практически нет просадки. Скорость изначальной загрузки модели в память, конечно, проседает, но не супер критично (гемма-27 загружается за 1-2 минуты). Заметьте, что скорость обработки входного промта до сих пор быстрая - 323 t/s, хотя тоже просела.
Флакс из-за медленной шины pcie просел на 10%. А вот тренировка лоры вообще не заметила изменений.
Работа в связке из 3-х карт с большими LLM.
А теперь затестим Gemma-27b-Q6 (21 GB) на одной карте и затем через layer-split 50/50. Просадка есть, но минимальная.
3090, 250w, solo - 20 t/s
2080ti, 200w, solo - 15 t/s
3090+2080ti pcie4.0@x4 + pcie2.0@x1, 50/50 - 14 t/s
А теперь задействуем все 3 карты. pcie x4+x0.5+x0.5. 2 карты с power limit 80% и 3090 - 60% (250w)
qwen-72b-q5(51 GB) - 7.00 t/s
Llama-3.3-70B-Q5_K_M (47 GB) - 7.27 t/s.
для сравнения, с реддита:
70B-gguf_Q4 (43 GB), 2x 3090 - 15.5 t/s
70b-awq_4b (40 GB), 4x 3060 pcie3.0@8 - 14 t/s
3.3-70b_Q4, mac mini M4 Max 64gb - 7 t/s
квенов-72b не нашел
SAINEMO-reMIX-12B_q6 (9 GB)
3090, pcie 4.0x4 - 43 t/s
То есть в теории, из-за медленной шины, я теряю какую-то скорость, но я не сказал, бы что она критичная. Сравним для моей 3090 power_60%_250w, размер LLM и скорость:
9 GB, solo - 43 t/s
21 GB, solo - 20 t/s
51 GB, split_3 - 7 t/s
При увеличении размера LLM в 2 раза скорость падает в 2 раза (это норма), и скорость pcie в этом случаем особо не дает влияния.
3090 в соло режиме с маленькой LLM жрет все выделенные ей 250W (TDP у нее 420, но я ей столько не даю). То же самое и 2080ti - в соло ест отведенные 191W из 200w. Но с большой LLM раскиданной по всем картам видно, что чипы потребляют лишь половину максимальной мощности (смотрим скрин). Возможно, в остальное время они ждут друг друга или хз что там происходит.
Кстати, свежую llama-3.3-70b для русского РП не рекомендую, она сухая и зацензуренная. А вот SAINEMO-reMIX-12B (9GB) весьма рекомендую. Это смесь разных nemo-12b: saiga_nemo + vikhr_nemo + 2 англоязычных РП микса. Сейчас либо ее использую, либо magnum-v4-72b-Q5 (51GB). Athene-72b не так понравилась, цензуры больше чем в магнуме.
https://huggingface.co/mradermacher/SAINEMO-reMIX-GGUF/tree/main
Выводы: число линий pcie для маленьких LLM - пофиг. Для больших LLM - важно, но не супер критично. Для флакса (генерации и тренировки) - тоже пофиг. Получается, pcie x16 переоценен? Даешь всем по сплиттеру, который делит x1 на 4 и будет счастье? 😀
Forwarded from Инжиниринг Данных (Dmitry)
Давайте расскажу, что мы добавили на сайт dataengineer.ru
1. К ресурсу присоединились котрибьютеры и еще общаюсь с топ-экспертеми в разных областях, чтобы смогли добавлять самые полезные ресурсы для вас.
2. Завели табличку дата сообществ, пока туда добавляют котрибьютеры свои сообщества
3. Завели секция по поиску работы
4. Добавили уже несколько ключевых white papers для нашей индустрии
5. Стали добавлять книги.
И теперь по скилам и инструментам:
1. Добавили еще ресурсов в SQL
2. Новая секция большая про визуализацию данных
3. В секцию BI добавили видео - что такое BI
4. Добавили ресурсов про хранилище данных.
5. Вводная информация про моделирование данных
6. Добавили отечественных вендоров для облака
7. Создали секцию про DevOps (CI/CD, git, Linting, Docker, Kubernetes/Minikube). Секция новая пока, в процессе доработки.
8. Секция про IDE и CLI для инженеров и аналитиков.
9. Секция про AI в контексте инструментов для повседневной работы и помощи в работе.
10. Раздел про API
11. Языки программировани, пока только про Python
12. Apache Spark готова.
До других разделов у нас еще не дошли руки.
Планирую еще добавить разделы про:
- Безопасность
- Privacy/Compliance
- Сети
- Примеры архитектурных решений для аналитики (Open Source, Commercial, On-Premise, Cloud)
- Примеры решений в зависимости от размера компаний (от стартапа до большого Enterprise)
В существующие разделы нужно добавить рекомендации про инструменты (BI, хранилища данных, ETL и тп).
Пока просто собираем и добавляем самые лучшие ресурсы в одно место, потом начнется самое сложное, создать Road map для профессий и привязать его к ресурсам.
1. К ресурсу присоединились котрибьютеры и еще общаюсь с топ-экспертеми в разных областях, чтобы смогли добавлять самые полезные ресурсы для вас.
2. Завели табличку дата сообществ, пока туда добавляют котрибьютеры свои сообщества
3. Завели секция по поиску работы
4. Добавили уже несколько ключевых white papers для нашей индустрии
5. Стали добавлять книги.
И теперь по скилам и инструментам:
1. Добавили еще ресурсов в SQL
2. Новая секция большая про визуализацию данных
3. В секцию BI добавили видео - что такое BI
4. Добавили ресурсов про хранилище данных.
5. Вводная информация про моделирование данных
6. Добавили отечественных вендоров для облака
7. Создали секцию про DevOps (CI/CD, git, Linting, Docker, Kubernetes/Minikube). Секция новая пока, в процессе доработки.
8. Секция про IDE и CLI для инженеров и аналитиков.
9. Секция про AI в контексте инструментов для повседневной работы и помощи в работе.
10. Раздел про API
11. Языки программировани, пока только про Python
12. Apache Spark готова.
До других разделов у нас еще не дошли руки.
Планирую еще добавить разделы про:
- Безопасность
- Privacy/Compliance
- Сети
- Примеры архитектурных решений для аналитики (Open Source, Commercial, On-Premise, Cloud)
- Примеры решений в зависимости от размера компаний (от стартапа до большого Enterprise)
В существующие разделы нужно добавить рекомендации про инструменты (BI, хранилища данных, ETL и тп).
Пока просто собираем и добавляем самые лучшие ресурсы в одно место, потом начнется самое сложное, создать Road map для профессий и привязать его к ресурсам.
dataengineer.ru
Контрибьюторы · Инжиниринг Данных
Портал для Инженеров Данных и Аналитиков.
Forwarded from 5 minutes of data
Lineage для кода: Визуализация зависимостей в Python-проектах
В мире данных мы привыкли к инструментам вроде dbt и datahub, которые отлично справляются с построением графов зависимостей для таблиц в базах данных. Но что делать, когда нужно разобраться в структуре кодовой базы?
Проблема
Недавно я столкнулся с задачей анализа старого проекта, где:
- Множество взаимосвязанных модулей
- Отсутствие тестов
- Сложная логика взаимодействия компонентов
Решение: pydeps 🛠
В поисках инструмента для визуализации зависимостей я обнаружил pydeps - Python-модуль, который:
- Анализирует структуру проекта
- Строит наглядный граф зависимостей
- Экспортирует результат в SVG-формат
Преимущества использования
- Быстрое понимание архитектуры проекта
- Визуальное отслеживание зависимостей
- Помощь в рефакторинге и написании тестов
💡 Этот инструмент особенно полезен при работе с legacy-кодом или при погружении в новый проект.
В мире данных мы привыкли к инструментам вроде dbt и datahub, которые отлично справляются с построением графов зависимостей для таблиц в базах данных. Но что делать, когда нужно разобраться в структуре кодовой базы?
Проблема
Недавно я столкнулся с задачей анализа старого проекта, где:
- Множество взаимосвязанных модулей
- Отсутствие тестов
- Сложная логика взаимодействия компонентов
Решение: pydeps 🛠
В поисках инструмента для визуализации зависимостей я обнаружил pydeps - Python-модуль, который:
- Анализирует структуру проекта
- Строит наглядный граф зависимостей
- Экспортирует результат в SVG-формат
Преимущества использования
- Быстрое понимание архитектуры проекта
- Визуальное отслеживание зависимостей
- Помощь в рефакторинге и написании тестов
💡 Этот инструмент особенно полезен при работе с legacy-кодом или при погружении в новый проект.
pip install pydeps
pydeps your_project_path
Forwarded from Инженерообязанный🫡 | Блог Дата Инженера
Ехххууууууу...... Вот и 2я часть подоспела. Затянул я её конечно за 30 минут, извиняйте
В следующей части поговорим о теоритически-практических вопросах собеседования.
Если у тебя уже есть блок вопросов, которые тебе задавали и ты их не услышал, пиши в комментариях. Ответ обязательно добавлю в следующих видео, тем самым ты поможешь не только себе, но и другим ребятам, которые вкатываются в IT.
С таким набором и на собес не страшно
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Топ вопросов на собеседовании по SQL - логические и физические виды JOIN, оконные функции, EXPLAIN
Данное видео позволит вам понять какие вопросы задаются на собеседовании и то что его нечего бояться. Я сам лично прошел уже более 30 собеседований на вакансию "Инженер данных" и знаю о чём говорю.
Телега: https://t.me/Shust_DE.
Таймкоды:
00:00 - Вступление…
Телега: https://t.me/Shust_DE.
Таймкоды:
00:00 - Вступление…
Forwarded from Инженерообязанный🫡 | Блог Дата Инженера
YouTube
Топ вопросов на собеседовании по SQL - NULL, Агрегация
Данное видео позволит вам понять какие вопросы задаются на собеседовании и то что его нечего бояться. Я сам лично прошел уже более 30 собеседований на вакансию "Инженер данных" и знаю о чём говорю. Если хочешь обсудить цикл прохождения собеседований залетай…
Топовая 3 часть, подоспела к вам ребзя. В ней я решил не просто сделать презентацию
В следующей части продолжим говорить о теоритически-практических вопросах собеседования, которые не привязать к определённым темам, поэтому будет "сборная солянка". 🥘 Ммммм....
Если у тебя уже есть блок вопросов, которые тебе задавали и ты их не услышал, пиши в комментариях. Ответ обязательно добавлю в следующих видео, тем самым ты поможешь не только себе, но и другим ребятам, которые вкатываются в IT.
Ну тут уже можно сказать, что SQL часть собеседования ты прошёл на
Не забывайте и про другие части
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from КПД
Собственноручно проверил наличие супервеса (см. оригинальную статью и разбор от gonzo-обзоры ML статей) в Llama-3.2-1B.
Aномальный вес находится в позиции (400 - выходной канал, 1417 - входной канал) в
Не столь ярко выражен (перплексия на Wikitext-2 (8k context length) выросла с 8.375 до 8.625 при занулении данного веса), но все же очень много для всего одно веса.
[Google Colab для желающих поиграться]
Aномальный вес находится в позиции (400 - выходной канал, 1417 - входной канал) в
model.layers.1.mlp.down_proj.Не столь ярко выражен (перплексия на Wikitext-2 (8k context length) выросла с 8.375 до 8.625 при занулении данного веса), но все же очень много для всего одно веса.
[Google Colab для желающих поиграться]