Комментарии 11
Помогите пожалуйста разобраться, работа gpt по обработке текста это последовательное пропускание контекстного окна через преобразования трансформера (декодер или вместе с энкодером), целиком, т.е. все окно контекста (если не полностью заполнено, используется нулевой токен) для каждого следующего токена.
Внимание вопрос, почему абсолютное большинство llm-ок, обрабатывает входной набор символов дольше чем генерирует один токен, время линейно зависит от количества токенов но часто 2х быстрее от генерации? Почему тарификация идет по количеству входных токенов, ведь чтение всего окна это время генерации одного токена?
Какая часть алгоритма упущена в описаниях работы gpt нейронок? Все статьи, что гуляют по сети и тут описывают либо внутрянку, что происходит внутри преобразований, как сэкономить при увеличении окна контекста, либо как выбирать следующий токен, либо как работать с обучающими данными, но описанный мной вопрос почему то обходят стороной, точнее это наверное где то описано, но не популярно, знают об этом единицы, считая это само собой разумеющимся?
Гугли механизм kv -кэша. Это стандартный способ ускорения работы трансформерных llm-ок, засчет некоторого оверхеда по памяти, позволяющий при инференсе сделать вычислительную сложность атеншена линейной, а не квадратичной от количества токенов при авторегресивной генерации. По сути это сохранения результатов после k, v линейных слоев в память, что бы их каждый раз не пересчитывать. Это также позволяет считать атеншн только по последнему токену, а не по всем. Но вот только это работает, когда уже что-то закешировано. Когда же к нам приходит начальный набор токенов, что бы запустить генерацию для них нужно все посчитать все честно по старинке, что бы закешировать весь этот набор присланных начальных токенов.
хороший обзор, спасибо. Надо понимать, что xpos в тексте и xp в формулах - это одно и тоже?
Проверяли RoPE и Alibi для своей GPT-like архитектуры на масштабах от 1 B до ~200B. Работало по качеству в пределах погрешности и количества итераций 3к на глобальном батче 4М токенов. Выбрали Алиби за удобство реализации, скорость, и потенциал улучшений для нашей предметной области. Ещё проверили NoPE, и, конечно, оказался полный бред.
Лично мне было бы интересно узнать больше о методах кодирования, когда мы не прибавляем (не умножаем) смысловую информацию и позиционную. А конкатенируем.
Я прочитал лишь пару не очень убедительных статей на эту тему.
Неужели больше никому не интересно исследовать эту идею?
Не сталкивался с таким в трансформерах, не очень понятен смысл: придется добавлять проекционные слои для перевода в исходную размерность, и на выходе все равно будет вектор, содержащий совокупную информацию, просто вложенную чуть сложнее. Плюс в относительных методах чаще или делается просто поворот вектора, или добавляется скалярная величина, а не вектор
Эти проекционные матрицы уже есть: Wq и Wk. Вот только на вход им подают уже смешанные данные. То есть, мы смешали зеленое с мягким, и затем просим модель научиться разделять. Модели приходится адаптироваться. Она учится не использовать пространство эмбеддингов на полную мощь, т.к. смысловые измерения смешиваются с позиционными.
Если бы мы делали concatenate(x_embedding, x_position) * Wq - думаю, мы получили бы результаты лучше.
Если я не ошибаюсь, с точки зрения линейной алгебры это можно преобразовать так:
concatenate(x_embedding, x_position) * Wq ==
concatenate(x_embedding, 0, 0, 0 ...) * Wq + concatenate(0, 0, 0, ... 0, x_position) * Wq ==
x_embedding * W[:embedding_size] * q + x_position * W[embedding_size:] q ==
x_embedding * W[:embedding_size] * q + x_position_W q ==
(x_embedding * W[:embedding_size] + x_position_W) q
и по-факту x_embedding и позиционные эмбеддинги всё равно в складываются в каком-то виде
Большое количество решений в современных архитектурах компромиссное по памяти: чем бы нам пожертвовать чтобы втиснуть сеть побольше в условные 80ГБ теслы и при этом не сильно ухудшить баланс качество-потраченные деньги. Раздувание размера на входе усиливает давление на память.
Публикации
О методах позиционного кодирования в Transformer