Свежак.

https://www.science.org/doi/10.1126/science.adn0117

Authors: YOSHUA BENGIO, GEOFFREY HINTON, ANDREW YAO, DAWN SONG, PIETER ABBEEL, TREVOR DARRELL, YUVAL NOAH HARARI, YA-QIN ZHANG, LAN XUE, SHAI SHALEV-SHWARTZ, GILLIAN HADFIELD, JEFF CLUNE, TEGAN MAHARAJ, FRANK HUTTER, ATILIM GÜNEŞ BAYDIN, SHEILA MCILRAITH, QIQI GAO, ASHWIN ACHARYA, DAVID KRUEGER, ANCA DRAGAN, PHILIP TORR, STUART RUSSELL, DANIEL KAHNEMAN, JAN BRAUNER, AND SÖREN MINDERMANN

Как и ожидалось (см https://xn--r1a.website/gonzo_ML/2415), начали появляться решения, призванные сделать работу с большим контекстом более экономически осмысленной.

Гугл анонсировал Context caching (https://ai.google.dev/gemini-api/docs/caching) для Gemini. В этом режиме часть токенов можно закешировать (с почасовой оплатой) и использовать при повторных запросах (например, к большой книге, или к огромному контексту предыдущей беседы с чат-ботом). Это будет дешевле, чем заново отправлять это как входные токены.

На данный момент это актуально только для Gemini 1.5 Pro (у которой контекст 1M-2M, а в перспективе 10M и бесконечность) и цена вопроса (https://ai.google.dev/pricing) вроде как в два раза ниже, чем при отправке токенов заново. При этом ещё и отличаются цены за токены для промптов до 128k и более. Чую, скоро такими темпами целые тарифные сетки для LLM появятся, как для работников :)

Если вы запихнули в промпт 1M токенов, то стоит это $7.00 / 1 million tokens (for prompts longer than 128K), если их же закешировали, то $3.50 / 1 million tokens (for prompts longer than 128K) к которым кажется добавляется $4.50 / 1 million tokens per hour (storage). Не сказать пока, что по деньгам это прям game changer, но всё равно какая-то оптимизация.

Ну и для реальных кейсов всё равно кажется дорого. Ну забил ты весь 1M токенов промпта своим контентом, запрос твой будет стоить $7. С кешированием за первый запрос будет столько, за последующий один даже дороже (ибо плюс хранение), но если их отправлять много, то что-то сэкономишь (не более чем половину). Плюс ещё за выходные токены $21.00 / 1 million tokens (for prompts longer than 128K), но там миллион сложнее выпользовать, размер выходного контекста ограничен 8k (https://cloud.google.com/vertex-ai/generative-ai/docs/learn/models#gemini-models), так что если это саммари или ответы на вопросы, то за один вопрос/саммари добавка не очень большая будет, в худшем случае меньше 20 центов.

За какие запросы вы готовы заплатить $7 (а если вы забили у новой Gemini 2M промпта, то и $14), это отдельный сложный вопрос. В оригинальном посте я ориентировался на цены Gemini 1.0 Pro, поскольку 1.5 была ещё в экспериментальном режиме и цены объявлены не были. Похоже, цены на Gemini 1.0 Pro выросли (раньше я ориентировался на $0.125, сейчас там $0.5), а 1.5 на фоне тех оценок вообще безумно дорога. Интересно, для каких кейсов экономика здесь будет сходиться. Это какой-то очень высокий порог не для масс.

Антропик опубликовал работу про интерпретируемость

https://www.anthropic.com/news/mapping-mind-language-model

Today we report a significant advance in understanding the inner workings of AI models. We have identified how millions of concepts are represented inside Claude Sonnet, one of our deployed large language models. This is the first ever detailed look inside a modern, production-grade large language model. This interpretability discovery could, in future, help us make AI models safer.

Wavelet-KANs are coming!

Wav-KAN: Wavelet Kolmogorov-Arnold Networks
Zavareh Bozorgasl, Hao Chen
https://arxiv.org/abs/2405.12832

Бойтес!

Хорошее интервью с Хинтоном, если кто ещё не видел

https://youtu.be/tP-4njhyGvo?si=lBj-PYOJPHofunQu

Не знал, кстати, что hidden layer в нейросетях пошло от hidden Markov models.

Хороший пост Анатолия Левенчука на тему
https://ailev.livejournal.com/1723726.html

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

#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 может быть кумулятивный эффект и вообще бомба.

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