Сегодня пара слов про нетрадиционные ценности.

#1. Термодинамический ИИ

Про термодинамический ИИ и стартап Normal Computing (https://normalcomputing.ai/) мы уже писали (https://xn--r1a.website/gonzo_ML/2313), но вот вышел свежий разговор Диамандиса с основателем другого стартапа про термодинамический ИИ под названием Extropic (https://www.extropic.ai/), а также автором эффективного акселерационизма (e/acc, https://www.youtube.com/watch?v=4Oj7m3F0ifI), Guillaume Verdon (https://youtu.be/JvVft_vISMM?si=mPnCnjkJ-z8VjWmA). Лекс Фридман тоже недавно делал с ним запись (https://www.youtube.com/watch?v=8fEEbKJoNbU).

Extropic описывает свой подход здесь (https://www.extropic.ai/future). Кажется, подход Extropic по сути близок к Normal Computing, но реализован на другом железе. SPU у Normal Computing используют LC-контуры, а Extropic использует Josephson effect в сверхпроводнике. Для массового рынка Extropic хочет сделать что-то попроще на транзисторах, что будет работать при комнатной температуре. Но деталей я не понял/не увидел.

Есть хороший пост "What’s the difference between Extropic, Normal Computing, and D-Wave?" (https://www.zach.be/p/whats-the-difference-between-extropic), пытающийся разобраться во всём имеющемся зоопарке.

#2. Оптические вычисления

Ещё одна интересная тема — оптические вычисления. В Quanta как раз недавно вышел очень краткий обзор по этой теме (https://www.quantamagazine.org/ai-needs-enormous-computing-power-could-light-based-chips-help-20240520/). Здесь работает, например, стартап Lightmatter (https://lightmatter.co/). Среди их продуктов есть как программируемый фотонный interconnect Passage (https://lightmatter.co/products/passage/), так и ускоритель Envise (https://lightmatter.co/products/envise/). Есть и DL фреймворк Idiom (https://lightmatter.co/products/idiom/). Не очень понял, в какой степени готовности оно всё, мне казалось, что до масштабов современного железа и моделей, обучающихся на нём, ещё далеко, но надо наблюдать.

По ощущению, в первую очередь это всё про interconnect (https://www.youtube.com/watch?v=6Bo-T9XNTvU). У Гугла уже используются оптические свитчи (optical circuit switch, OCS) вместо Infiniband для подов с TPUv4 (https://cloud.google.com/blog/topics/systems/tpu-v4-enables-performance-energy-and-co2e-efficiency-gains, более детальная статья тут: https://arxiv.org/abs/2304.01433). В Open Compute Project тоже развивают это направление (#1 https://www.youtube.com/watch?v=0MwMNHbWJlk, #2 https://www.youtube.com/watch?v=o6gX0YbI3iQ). Interconnect в DL работает на решение проблемы недоиспользования железа, многие вычисления по факту communication- (или i/o-) bound. Давняя большая тема (https://www.computer.org/csdl/magazine/mi/2004/05/m5005/13rRUwhHcNg). См. также roofline performance model (https://moocaholic.medium.com/hardware-for-deep-learning-part-3-gpu-8906c1644664#8dd5). Здесь же и более быстрая память много чего добавляет (ну покуда в неё влезает).

Но вообще там целая экосистема, включая, конечно, матричные ускорители (https://www.nature.com/articles/s41566-024-01394-2, https://arxiv.org/abs/2309.10232, https://spie.org/news/matrix-multiplications-at-the-speed-of-light, https://www.nature.com/articles/s41377-022-00717-8).

#3. DNA Storage

Другая интересная тема — DNA Storage. Потребности в хранении данных растут быстрее, чем наши способности, и есть ожидания, что скоро мы погрузимся с головой в этот океан данных. Кроме того текущие технологии хранения не то чтобы сильно долговечны, позволяют хранить лишь на горизонте десятков лет да ещё и с периодическим обслуживанием. Вспомнилось, у Цысиня в "Вечной жизни смерти":

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

ДНК-хранение теоретически позволяет хранить ну не сотни миллионов лет, конечно, но и явно больше чем просто десятки лет.

В октябре 2020 Illumina, Microsoft, Twist Bioscience и Western Digital основали DNA Data Storage Alliance (https://dnastoragealliance.org/). У Альянса есть обзорная публикация "An introduction to DNA data storage" от 2021 года (https://dnastoragealliance.org/dev/wp-content/uploads/2021/06/DNA-Data-Storage-Alliance-An-Introduction-to-DNA-Data-Storage.pdf), и вот ещё есть свежий популярный обзор от IEEE Spectrum (https://spectrum.ieee.org/dna-data-storage).

Прогресс в области идёт, в частности развивается тема с использованием фермента terminal deoxynucleotidyl transferase, TdT (https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2846215/), который умеет навешивать новые буквы на концы одноцепочечной ДНК.

Чтобы конкурировать с использующимися для архивирования магнитными лентами надо уметь писать со скоростью 2 гбит/с то есть 2 миллиарда баз в секунду (в схеме кодирования, когда одна база кодирует 1 бит, а не 2 как теоретически возможно). Текущий рынок синтеза ДНК автор статьи в Spectrum оценивает как эквивалент всего лишь 300 тысяч баз в секунду. Далековато, но прогресс в хранении информации экспоненциальный, в секвенировании тоже (а то и сверхэкспоненциальный). Синтез пока не настолько хорош, но всё равно улучшается. Когда дойдём до таких bandwidth (а это 20 человеческих геномов в минуту), конечно, и ландшафт угроз сменится не менее серьёзно.

Про ДНК хранение и вычисления, а также экзотическую штуку под названием Nondeterministic universal Turing machine (NUTM) я писал обзор в 2017-м (https://moocaholic.medium.com/on-universal-dna-computing-241dc1fba568).

В общем интересные темы, stay tuned!

Свежий Маркус Хуттер вышел!

Кто-то теряет, кто-то находит

https://techcrunch.com/2024/05/28/anthropic-hires-former-openai-safety-lead-to-head-up-new-team

LoGAH: Predicting 774-Million-Parameter Transformers using Graph HyperNetworks with 1/100 Parameters
Xinyu Zhou, Boris Knyazev, Alexia Jolicoeur-Martineau, Jie Fu
Статья: https://arxiv.org/abs/2405.16287
Код: https://github.com/Blackzxy/LoGAH

Сегодня малый жанр. Подробный разбор делать неохота, но и ничего не писать про работу тоже жалко.

Очередной кейс применения гиперсетей (hypernetworks, см. например https://xn--r1a.website/gonzo_ML/1696). Напомню, что гиперсети генерируют веса для другой сети.

Текущая работа делает через гиперсеть инициализацию сетей (как и https://xn--r1a.website/gonzo_ML/2394 кстати) для работы с языком или изображениями (ViT и GPT-2), и с этой инициализации претрейн проходит быстрее, чем с рандома. Что наверное также говорит о том, что мы используем неправильный рандом (и лучше брать вместо него котиков, https://xn--r1a.website/gonzo_ML/2657) и тому есть много свидетельств (см. например https://xn--r1a.website/gonzo_ML/200).

Гиперсеть является графовой (то есть Graph HyperNetwork, GHN), устроенной из стека слоёв Graphormer (https://github.com/Microsoft/Graphormer, https://arxiv.org/abs/2106.05234), куда подаётся вычислительный граф. На полученных эмбеддингах далее работает GHN Decoder, являющийся MLP. Он выдаёт уже веса сети (инициализацию точнее).

В предыдущих подходах GHN не могли генерить веса для очень широких слоёв и делали это повторяющимися блоками. Текущая работа улучшает эту часть, предлагая LOGAH (Low-rank
GrAph Hypernetworks), специальную версию GHN, у которой low-rank декодер может генерить более широкие слои без существенного увеличения числа параметров гиперчасти, получая сложность O(d^2) вместо O(d^3).

Авторы собрали два датасета VITS-1K и GPTS-1K с тысячей различных ViT-style и GPT-2-style вычислительных графов для генерации параметров ViT и GPT-2.

Сравниваются с GHN-3, гиперсетью из предыдущих работ по теме, и с рандомной инициализацией.

ViT проверяют на CIFAR-10, CIFAR-100 и ImageNet после файнтюна на 100 (CIFAR) или 30 (ImageNet) эпох. LoGAH заметно обходит (2-5 процентных пункта).

На GPT-2 сравнились только с рандомом, итоговая перпрексия у LoGAH лучше. По факту получается, что модель в 2.5M или 21.4M параметров неплохо генерит параметры (инициализацию) для моделей размером до 774M (GPT-2 Large).

Интересная тема в общем. Получится ли когда-нибудь генерить сразу финальные параметры модели, чтоб вообще без обучения?

You Only Cache Once: Decoder-Decoder Architectures for Language Models
Yutao Sun, Li Dong, Yi Zhu, Shaohan Huang, Wenhui Wang, Shuming Ma, Quanlu Zhang, Jianyong Wang, Furu Wei
Статья: https://arxiv.org/abs/2405.05254
Код: https://github.com/microsoft/unilm/tree/master/YOCO

Архитектурные новости. Авторы придумали архитектуру для LLM под названием decoder-decoder.

Напомним, что оригинальный трансформер (и например модели типа T5) был построен на полной архитектуре encoder-decoder, большая часть современных LLM (типа GPT) используют только decoder, и другая популярная ветка недавнего прошлого (модели семейства BERT) состоит только из encoder. Энкодер всегда был двунаправленным (bidirectional) и модели с таким двунаправленным компонентом (то есть encoder и encoder-decoder) имели проблемы с авторегрессионной генерацией — там для генерации нового токена сначала надо было заэнкодить всю последовательность из входа и уже нагенерённой части выхода. Можно конечно использовать только декодерную часть для генерации, но тогда сгенерённые токены не используют на полную мощь параметры энкодера. У decoder тут всё неплохо, при авторегрессионной генерации можно закешировать вектора KV (key и value в блоках внимания) и переиспользовать для генерации нового токена, не надо заново кодировать всю историю.

Но как говорится в сказании о Савитри, “есть один недостаток”. KV-кэш очень пухнет при росте длины генерируемой последовательности, он отжирает кучу памяти GPU и LLM-ки становятся memory-bound. Так для 65B модели (с grouped-query attention и квантизацией KV в 8 бит) для 512k токенов нужно 86Gb памяти, что перекрывает объём памяти H100-80GB. К тому же фаза prefill (см тут или хороший обзор тут), в которой надо обработать все входные токены промпта и вычислить для них значения KV, может занимать сотни секунд для очень длинных входов типа 1М (здесь, кстати, интересно, что Гугл с Gemini 1.5 придумал).

Весь трансформер из L слоёв разделяется поровну и первые L/2 слоёв реализуют self-decoder через efficient self-attention. Размер KV-кеша этой части константен, то есть O(1). Выход последнего слоя self-decoder даёт глобальный KV-кеш, куда ходит вторая половина, cross-decoder, реализованная через оставшиеся L/2 слоёв. Каждый блок получает на вход Q и через cross-attention идёт в этот глобальный KV-кеш. Здесь уже везде стандартное (почти, с GQA, https://arxiv.org/abs/2305.13245) multi-head attention с полным окном.

Под efficient self-attention в self-decoder авторы подразумевают sliding-window attention как в старом добром sparse transformer имени Ильи Суцкевера и ко (https://xn--r1a.website/gonzo_ML/65). Как вариант, вместо него в self-decoder может использоваться RetNet (https://xn--r1a.website/gonzo_ML/1753) под названием gRet (aka gRetNet или RetNet-3) с data-dependent гейтингом. Вроде бы такой же мы и разбирали когда-то давно в оригинальной статье.

В остальном блоки в этих слоях в целом стандартные, чередование внимания и FFN, с использованием pre-RMSNorm, SwiGLU, GQA.

Полученная архитектура называется YOCO (You Only Cache Once, так понимаю тут речь про кеширование в L/2 слое). Это всё похоже на encoder-decoder, но снаружи выглядит как декодер и обе части используют causal masking.

YOCO эффективнее обычного трансформера за счёт меньших требований к памяти, кеш для длинных последовательностей скейлится как O(N) вместо O(NL), то есть можно делать больше инференса и/или с более крупными батчами (что повышает throughput).

Ещё из интересных свойств YOCO есть то, что во время стадии prefill можно сделать early exit и не ходить в cross-decoder, это повышает скорость данной фазы. Поскольку в self-decoder находится половина слоёв, то это уже сокращение вычислений и времени в два раза. К тому же эффективная реализация внимания в self-decoder обычно быстра. Они приводят пример запроса с размером контекста в 512K, на котором prefill latency падает со 180 секунд (трансформер с flash-decoding и kernel fusion) до менее 6 секунд. И даже на длине 32K YOCO всё равно в три раза быстрее (на этой фазе, а не в целом end-to-end).

В тестах за основу взяли StableLM-3B-4E1T и сделали сопоставимую YOCO, она даёт результаты сравнимые с другими хорошо затюненными моделями такого же размера. Лосс от размера модели скейлится также как у Llama-optimized трансформера. При этом YOCO с gRet чуть лучше, чем со sliding-window attention (SWA) и обычный трансформер.

Если расширить контекст YOCO-3B до 1M (привет, Gemini!) через продолжение обучения с length schedule 64K, 256K, 1M, то на Needle In A Haystack всё выглядит почти идеально.

В недрах приложений есть сравнение с Mamba, RetNet, Hybrid H3, gRetNet и трансформером. YOCO с трансформером рулят (по перплексии).

Самые интересные результаты в производительности. По памяти улучшение в разы и чем больше длина последовательности, тем больше улучшение. На длине 1М YOCO ест в 9.38x меньше памяти, чем трансформер с GQA, Flash-Decoding и kernel fusion. В основном за счёт KV кеша, но кажется ещё небольшое улучшение у gRet при хранении активаций. По метрике prefilling latency улучшение в десятки раз. По throughput (токены в секунду) на длинных входах ускорение почти до 10 раз (в основном по двум причинам: более быстрый prefill, а также возможность использовать больший батч из-за лучшей работы с памятью). В сочетаниях типа YOCO + BitNet + Groq может быть кумулятивный эффект и вообще бомба.

Хорошая инженерная работа, мне нравится.