Telegram Group & Telegram Channel
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://www.group-telegram.com/us/gonzo_ML.com/65). Как вариант, вместо него в self-decoder может использоваться RetNet (https://www.group-telegram.com/us/gonzo_ML.com/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).



group-telegram.com/gonzo_ML/2699
Create:
Last Update:

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://www.group-telegram.com/us/gonzo_ML.com/65). Как вариант, вместо него в self-decoder может использоваться RetNet (https://www.group-telegram.com/us/gonzo_ML.com/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).

BY gonzo-обзоры ML статей


Warning: Undefined variable $i in /var/www/group-telegram/post.php on line 260

Share with your friend now:
group-telegram.com/gonzo_ML/2699

View MORE
Open in Telegram


Telegram | DID YOU KNOW?

Date: |

Telegram has gained a reputation as the “secure” communications app in the post-Soviet states, but whenever you make choices about your digital security, it’s important to start by asking yourself, “What exactly am I securing? And who am I securing it from?” These questions should inform your decisions about whether you are using the right tool or platform for your digital security needs. Telegram is certainly not the most secure messaging app on the market right now. Its security model requires users to place a great deal of trust in Telegram’s ability to protect user data. For some users, this may be good enough for now. For others, it may be wiser to move to a different platform for certain kinds of high-risk communications. "The inflation fire was already hot and now with war-driven inflation added to the mix, it will grow even hotter, setting off a scramble by the world’s central banks to pull back their stimulus earlier than expected," Chris Rupkey, chief economist at FWDBONDS, wrote in an email. "A spike in inflation rates has preceded economic recessions historically and this time prices have soared to levels that once again pose a threat to growth." Since its launch in 2013, Telegram has grown from a simple messaging app to a broadcast network. Its user base isn’t as vast as WhatsApp’s, and its broadcast platform is a fraction the size of Twitter, but it’s nonetheless showing its use. While Telegram has been embroiled in controversy for much of its life, it has become a vital source of communication during the invasion of Ukraine. But, if all of this is new to you, let us explain, dear friends, what on Earth a Telegram is meant to be, and why you should, or should not, need to care. In addition, Telegram now supports the use of third-party streaming tools like OBS Studio and XSplit to broadcast live video, allowing users to add overlays and multi-screen layouts for a more professional look. I want a secure messaging app, should I use Telegram?
from us


Telegram gonzo-обзоры ML статей
FROM American