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

Блин, ты не одна такая, поверь)
Ты вообще знаешь сколько девчонок с откровенными аватарками пишут мне первым сообщением под любым постом в телеге?)

LLAMA

Когда вы занимаетесь перформансом, одно из полезных упражнений для проделывания в голове -- анализ скорости света. В простом варианте надо задать себе вопрос "А какой реально лимит сделать то, что делаем мы в библиотеке/программе?".

Очевидный ответ, понятное дело, ноль, лимита нет. Но если подумать, всегда есть некоторые ограничения. Приведём примеры:

Компрессия -- лимит: memcpy. Скопировать данные уж точно надо будет

Хеширование -- проход по массиву, уж точно надо будет все данные прогрузить и сделать хотя бы одну инструкцию с ними

Аллокатор -- хмм, уже не очень понятно

Анализы скорости света выходят всё чаще и чаще, например, теоретические лимиты в математике/алгоритмах и так далее. Они часто оказываются неприменимы, но они действительно могут помочь понять, куда смотреть, находить какие-то эвристики для того, чтобы приблизиться к этому лимиту.

Тут вышла статья с технологией LLAMA (нет, не моделькой от фейсбука и название поста специально привлекает ваше внимание, потому что хайповые вещи я обсуждаю очень редко). А именно Learned Lifetime-Aware Memory Allocator.

https://dl.acm.org/doi/pdf/10.1145/3654642#page=89

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

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

Почему стектрейсы?

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

Что делать с перфом?

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

Из интересного, да, перформанс аллокатора замедлился раза в 3-4, но перформанс всей программы замедлился всего на 12%. Если посчитать, сколько занимает аллокатор, то в целом получается, что решения аллокатора ускоряют всё остальное. Поэтому не надо бояться проводить немного больше в аллокаторе -- его решения влияют на последующие результаты.

Что в итоге?

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

В целом авторам удалось заметить некоторые эвристики, которые пошли в прод. Без деталей, но если надо, я найду для следующих постов, там долгая история:

We applied insights from this work to Temeraire, in order to make better decisions about when to break up huge pages in this allocator, which led to an estimated 1% throughput improvement across Google’s fleet

В общем, в этом достаточно интересный урок -- не бойтесь делать анализы скоростей света, когда можно потратить больше времени, чтобы найти лучше конфигурацию. Такие эксперименты дают больше понимания, что в идеальной ситуации должно работать.

ChessGPT - есть ли модель мира у языковой модели?

В этих двух блогпостах автор исследует наличие "модели состояния" у языковой модели, обученной на шахматных партиях, записанных в виде PGN (1.e4 e5 2.Nf3 …).

50 миллионов параметров и 16 миллионов игр с lichess уже достаточно, чтобы она умела играть лучше 90% игроков. Как нам получить прямое свидетельство того, что модель внутри хранит состояние доски?

Возьмём активации с внутренних слоёв и будем обучать линейную модель поверх этих активаций предсказывать состояние доски - точнее, вероятность нахождения каждой из фигур в каждой из позиций.

Такой подход успешно предсказывает 99.2% клеток, значит, информация о состоянии всей доски у такой модели есть. Но так можно предсказывать не только доску. Автор учит линейную модель предсказывать - это игра с рейтингом <1500 или >2000 (остальные выкидываем)? Результат - 89%.

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

И всё-таки, есть ли модель мира у языковой модели?

Этот вопрос, как часто бывает, демонстрирует ограниченность человеческого мышления. Мы склонны наделять большие системы из простых элементов бинарными качествами и до хрипоты спорить о значении терминов, тогда как в реальности всё проще.

У системы внутри есть всё, что помогает решению задачи - "модель мира", "модель игрока". Есть ровно в той степени, которая нужна для минимизации ошибки - x% модели среды, y% модели игрока и даже z% модели качества интернета для предсказания внезапного конца игры.

При этом у системы нет ни модели мира, ни игрока, потому что её об этом не просили в явном виде. А нужно ли это? Я думаю, что нет, и все проблемы, вызыванные их отсутствием, решаются правильной постановкой задачи перед самой системой. Но мы пока к этому не пришли.

@knowledge_accumulator