Новости

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Отчет о сердце машины

Редакция «Машинное сердце»

Ленивость заставляет вас работать лучше.

Только что вышла Llama 3.1, вы уже пробовали? Даже если ваш компьютер имеет новейшую топовую спецификацию, вы все равно можете столкнуться со значительными задержками при работе даже с самой маленькой версией 8B. Чтобы повысить эффективность рассуждений модели, исследователи придумали множество методов, но многие из них заставят модель пожертвовать некоторой точностью.

Недавно исследовательская группа из Apple и Meta AI предложила новый метод, который может увеличить скорость вывода на этапе предварительного заполнения Llama 2 более чем в 2 раза, гарантируя при этом, что точность не упадет значительно. Ускорение 3.1 дает некоторое вдохновение. Они называют этот подход LazyLLM, что означает Lazy Large Language Model.

Название статьи: LazyLLM: динамическое сокращение токенов для эффективного вывода LLM в длинном контексте

Адрес статьи: https://arxiv.org/abs/2407.14057.

Так как же им заставить LLM быть ленивым? Чтобы понять их метод, нам сначала нужно знать, что представляет собой стандартный процесс вывода LLM на основе подсказок. Проще говоря, процесс разделен на два этапа: предварительное заполнение и декодирование, как показано на рисунке 1.

На этапе предварительного заполнения модель вычисляет и сохраняет кэш KV каждого токена в командной строке и прогнозирует первый токен. Мы называем время, затраченное на этапе предварительной загрузки, «временем до первого токена (TTFT)».

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

На этапе предварительного заполнения все слои Transformer используют все токены в приглашении. TTFT может быть медленным, когда приглашение длинное, потому что лучший на данный момент LLM на основе Transformer одновременно глубок и широк, а стоимость вычисления внимания растет квадратично с количеством токенов в приглашении. Например, Llama 2 (версия 7B) объединяет 32 слоя Трансформеров, а размер модели составляет 4096. В этом случае TTFT требует в 21 раз больше времени на каждый последующий шаг декодирования, что составляет примерно 23% от общего времени генерации в тесте LongBench.

Следовательно, чтобы сделать вывод LLM эффективным, оптимизация TTFT является очень важным шагом.

Хотя оптимизация вывода LLM является активной областью исследований, многие методы направлены на повышение скорости вывода на этапе декодирования. Исследователи уделили мало внимания улучшению TTFT. Некоторые результаты исследований, основанных на сжатии, могут неявно улучшить TTFT за счет уменьшения размера LLM.

Еще одним направлением исследований является улучшение TTFT в рамках статической архитектуры Transformer. В этом направлении исследований естественным образом возникает вопрос: все ли маркеры подсказок необходимы при создании первого токена?

На рисунке 2 показаны результаты LLM-анализа в тесте LongBench.

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

К преимуществам LazyLLM можно отнести широкий спектр применения, отсутствие необходимости обучения и хорошие результаты. На рис. 3 сравниваются стандартные LLM и LazyLLM.

ЛенивыйLLM

На рис. 4 показана общая структура LazyLLM.

Начиная с полного контекста, LazyLLM постепенно сокращает токены, тем самым постепенно уменьшая количество вычислений, используемых для получения окончательной модели. Обратите внимание, что LazyLLM позволяет модели выбирать разные подмножества токенов на разных этапах генерации, даже если некоторые из них могли быть удалены на предыдущих этапах. По сравнению со статическим сокращением (все токены отсекаются одновременно), динамическое сокращение оптимизирует прогнозирование следующего токена на каждом этапе генерации, что помогает поддерживать производительность модели.

Прогрессивная обрезка токенов

Некоторые предыдущие исследования успешно использовали сокращение токенов для оптимизации вывода LLM. Однако эти методы должны накапливать полные карты внимания первых нескольких предсказанных токенов, чтобы проанализировать важность подсказок перед началом сокращения. Следовательно, они не подходят для уменьшения TTFT, поскольку им все равно необходимо вычислять все кэши KV на этапе предварительного заполнения.

Для сравнения, LazyLLM «очень ленив» и будет рассчитывать только те токены, которые важны для прогнозирования следующего токена, начиная с первой итерации вывода (шаг предварительного заполнения).

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

После расчета показателя достоверности токена возникает еще одна трудная задача — определить порог сокращения токена.

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

То есть токены, используемые последующими уровнями, являются подмножеством токенов, используемых предыдущими уровнями.

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

Они также обнаружили, что по сравнению с обрезкой на ранних уровнях, лучшая производительность была достигнута, когда обрезка выполнялась на более поздних слоях, что указывает на то, что более поздние слои менее чувствительны к обрезке токенов. Чтобы лучше сбалансировать скорость и точность, команда использовала прогрессивное сокращение, как показано на рисунке 4, сохраняя больше токенов на ранних уровнях, а затем постепенно уменьшая количество токенов по мере их поступления на более поздние уровни.

Aux Cache (вспомогательный кэш)

На этапе предварительного заполнения кэш KV отсутствует, и каждый токен представлен в скрытом состоянии. Таким образом, прогрессивное сокращение токенов может быть достигнуто путем удаления скрытого состояния сокращенных токенов. Однако распространить прогрессивное сокращение токенов на последующие этапы декодирования непросто. Причина в том, что на каждом этапе декодирования для расчета внимания используется буфер KV, рассчитанный на этапе предварительного заполнения. Поскольку LazyLLM выполняет постепенное сокращение токена на этапе предварительного заполнения, KV токена, сокращенного на определенном уровне, не появится в кэше KV следующего уровня.

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

Интуитивное решение этой проблемы — передать токены через источник Transformer. Однако это приводит к двойному учету одного и того же токена и в конечном итоге замедляет общую скорость генерации.

Чтобы решить эту проблему, команда в дополнение к исходному кэшу KV представила еще один кэш: Aux Cache (вспомогательный кэш).

Если токены KV, токены которых были сокращены (например, T4 и T7 на рисунке 4), не появляются в кэше KV последующих слоев, их скрытые состояния будут сохранены в дополнительном кэше для извлечения в последующих итерациях.

Как показано на рисунке 4, на каждом этапе декодирования каждый уровень преобразователя сначала извлекает KV-кэш прошлых токенов (если он существует). Для тех токенов, которых нет в кеше KV, их скрытые состояния извлекаются непосредственно из вспомогательного кеша предыдущего уровня без необходимости повторного прохождения предыдущего уровня. Aux Cache гарантирует, что каждый токен вычисляется не более одного раза на каждом уровне Transformer, а также гарантирует, что LazyLLM работает быстрее, чем стандартный LLM в его самом медленном состоянии.

эксперимент

Команда протестировала этот новый «ленивый» подход на двух больших языковых моделях: Llama 2 7B и XGen 7B. Стандартный LLM для сравнения — это та же публично выпущенная предварительно обученная модель контрольных точек без какого-либо дополнительного обучения.

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

Метрикой оценки является эффективность и результативность каждого метода с точки зрения компромисса между ускорением TTFT и точностью.

результат

В таблице 1 приведены результаты ускорения и точности TTFT для LazyLLM, стандартного LLM и других базовых методов.

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

Как видно из таблицы 1, LazyLLM значительно превосходит TTFT-ускорение, при этом снижение точности практически незначительно. Следует отметить, что использование LLM для сжатия подсказок требует большого количества вычислений. Таким образом, несмотря на то, что Prompt Compression делает вывод быстрее, его фактическое TTFT длиннее, чем стандартное LLM.

Влияние на общую скорость сборки

Чтобы оценить влияние нового метода на общую скорость генерации, команда проанализировала процент токенов подсказок, используемых в расчетах, и ускорение генерации (см. Таблицу 2).

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

Скорость падения на разных уровнях

Команда также проанализировала влияние расположения слоя обрезки и количества обрезанных токенов. Результаты показаны на рисунке 6.

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

На основании этих наблюдений можно сказать, что эффективность прогрессивного сокращения токенов доказана.

Прогрессивный рост KV

Наконец, команда также попыталась понять внутреннюю структуру модели, используя логику сокращения токенов. В частности, они хотят знать совокупную долю использования токенов подсказки и соответствующую неиспользованную долю. Это «совокупное использование токенов» можно эквивалентно определить как размер кэша KV на каждом этапе. На рис. 7 показано совокупное использование этих токенов подсказки на каждом этапе LazyLLM.

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

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