Быстрая популярность крупномасштабных языков​​Модель (LLM) стала основным драйвером роста облачного LLM Служить,Сегодня эти услуги имеют решающее значение для стимулирования разработки приложений искусственного интеллекта. Однако,Динамические авторегрессионные свойства LLM Служить и необходимость поддержки чрезвычайно длинных контекстов,Требует гибкого распределения и освобождения большого количества ресурсов. Это для разработки облачной системы. обслуживания LLM создает огромные проблемы, когда неэффективное управление может привести к упадку или растрате ресурсов. Для решения этих проблем в данной статье представлен новый алгоритм распределенного внимания DistAttention, который сочетает в себе KV Кэш разделен на более мелкие, более управляемые блоки для реализации модуля распределенной обработки и хранения. На основе этой идеи автор предложения разработал распределенную Систему под названием DistKV-LLM. обслуживания LLM, система динамического управления КВ Кэшируйте и эффективно координируйте всю доступную память графического процессора и процессора в центре обработки данных. Это обеспечивает высокопроизводительный сервис LLM в облаке, который может адаптироваться к широкому диапазону длин контекстов. С 32 NVIDIA A100 Система автора была проверена в облачной среде с графическими процессорами (настроенными от 2 до 32 экземпляров), что продемонстрировало улучшение сквозной пропускной способности в 1,03-2,4 раза и поддерживается по сравнению с современной современной системой. обслуживания LLM в 2–19 раз длиннее длины контекста.,Это было подтверждено в ходе обширного тестирования на 18 наборах данных.,Длина контекста этих наборов данных составляет до 1900 КБ.

1 Introduction

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

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

Динамический и итеративный характер автоматического создания текста регрессии делает невозможным заранее планировать распределение ресурсов.,При разработке эффективной Системы обслуживания LLM в сфере облачных вычислений,предложение столкнулось с огромной проблемой. Особенно в длинных контекстных задачах,Кэш расширенного значения ключа (KV) может превышать ограничения памяти графического процессора в вычислительном экземпляре.,Ресурсы необходимо перераспределить немедленно. Это часто предполагает инициацию дорогостоящей живой миграции.,Переносите задачи в более мощные экземпляры,Или заранее выделите дополнительные графические процессоры, чтобы справиться с возможной перегрузкой памяти. Однако,Последнее может привести к неэффективности и пустой трате ресурсов.,Особенно в задачах с нормальной длиной контекста.

Предыдущие работы, такие как PagedAttention, пытались решить эти проблемы, упрощая обмен данными (или обмен данными) между памятью графического процессора и процессора. Однако у этого подхода есть несколько ограничений. Во-первых, диапазон подкачки памяти PagedAttention ограничен памятью графического процессора и процессора в пределах одного узла, что ограничивает его способность обрабатывать чрезвычайно длинные контексты. Во-вторых, хотя его стратегия подкачки предназначена для минимизации фрагментации памяти, она Level Поменяй весь КВ Кэш, поэтому более гибкое и детальное планирование невозможно достичь в распределенной облачной среде. И последнее, но не менее важное: замена запрошенных прерываний вычислений может вызвать колебания в выполняемых задачах, тем самым ставя под угрозу критическую строгость облака. Level Соглашения (SLA).

Для решения вышеперечисленных задач,Автор предложения предложил новый алгоритм внимания DistAttention.,направлена ​​на преодоление этих проблем. DistAttention делит KV Cache на подблоки, унифицированные rBlocks.,Эти подблоки помогают поддерживать распределенные вычисления и управление памятью в LLM Служить, которые поддерживают длинные контексты. отличается от традиционных методов,DistAttention использует все доступные ресурсы памяти графического процессора или процессора в центре обработки данных.,Особенно память, которая в настоящее время используется недостаточно. Это не только обеспечивает поддержку более длинных контекстов.,Также позволяет избежать производительности, обычно связанной с обменом данными или процессом динамической миграции.

в этой статье,Автор разработал распределенныйдвижокLLMСлужить под названием DistKV-LLM.,Движок легко интегрируется с DistAttention. DistKV-LLM управляет КВ Кэш работает хорошо и может эффективно координировать использование памяти между графическим процессором и процессором в центре данных. Когда LLM Служить экземпляр из-за КВ При возникновении нехватки памяти из-за расширения кэша DistKV-LLM будет активно получать дополнительную память из менее загруженных экземпляров.

Кроме того, DistKV-LLM представляет сложный протокол, который обеспечивает эффективное, масштабируемое и согласованное взаимодействие между несколькими экземплярами службы LLM, работающими в облаке. Этот протокол предназначен для эффективного управления и балансировки больших объемов ресурсов памяти. Кроме того, DistKV-LLM отдает приоритет локализации данных и оптимизации связи, что полезно для решения проблем с KV. Cacheраспределенный Связанные с хранилищемпроизводительность Вызов имеет решающее значение。

Суммируя,Работа автора направлена ​​на полное использование всех доступных ресурсов графического процессора в дата-центре.,чтобы гарантировать, что при обработке длинных контекстных задач,LLM Cloud Служить — это гладко и эффективно. В сочетании с DistAttention иDistKV-LLM,Обеспечивает решение проблем распределения ресурсов и оптимизации, с которыми сталкивается LLM Служить в распределенной среде. Такой подход позволяет эффективно управлять ресурсами.,Позволяет LLM Служить эффективно решать различные задачи по генерации контекста.

Автор работает на устройстве,В оснащенном 32 Комплексная оценка DistKV-LLM проводилась в облаке на графическом процессоре NVIDIA A100, тестируя различные конфигурации распределенной системы от 2 до 32 экземпляров. Авторская оценка состоит из 18 предложений с длиной контекста до 1.,900К коллекция эталонданных. Система авторов превосходит современные существующие разработки в 1,03-2,4 раза по сквозной производительности и поддерживает в 2-19 раз большую длину контекста.

В этой статье вносятся следующие вклады:

1. Открывает возможность полностью использовать все доступные ресурсы памяти графического процессора и процессора в центре данных. в то же время,Он также эффективно оптимизирует локальность памяти и накладные расходы на связь.,Обеспечивает бесперебойную и эффективную работу LLM в облаке.
2. Оснащен 32 NVIDIA A100 GPUsи18индивидуальныйданныенабор,Длина каждого контекста набора данных может достигать 1900 КБ в облачной среде.,Авторская система превосходит современное произведение,Поддерживает длину контекста в 2–19 раз больше.,И обеспечивает повышение пропускной способности в 1,4–5,3 раза при выполнении задач стандартной длины контекста.

2 Background

Large Language Models

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

2.1.1 Model Architecture

Большие языковые модели (LLM) Сложная архитектура построена на принципах модели Трансформера. Например, ГПТ-3 Это одна из крупнейших моделей, состоящая из нескольких блоков (слоев) Transformer со 175 миллиардами параметров, что дает ей возможность улавливать сложные языковые шаблоны и генерировать текст, похожий на человеческий. Блок Трансформатор состоит из нескольких ключевых компонентов:

QKV линейный слой Сначала передайте входные данные в блок Transformer. Эти слои, по сути, представляют собой полностью связанные нейронные сети, которые отображают входные данные в три разных пространства, включая Query (Q), Ключ (K) и Значение (V).

Многоголовый механизм самообслуживания,или модуль внимания,Является ядром блока Трансформер. Это позволяет Модели по-разному обрабатывать разные части входной последовательности. в бычьем внимании,Входные данные линейно преобразуются несколько раз для формирования разных «головок».,позволять Модель Объединение в разных позициях в разных подпространствах представлениясосредоточиться на информацию.

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

2.1.2 LLM Service

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

Учитывая содержащий

Токен

Текст подсказки: Модель предсказывает следующий Токен

. Указывает, что каждый возможный токен

распределение вероятностей

,Прямо сейчас

Вероятность быть выбранным каждым возможным токеном может быть рассчитана как:

В приведенной выше формуле

и

это параметр, полученный на последнем уровне модели Трансформера, и

с последним Токеном

связанный вектор скрытого состояния.

На этапе автоматической генерации регрессии,Модель генерирует слова одно за другим,Каждое новое слово зависит от уже сгенерированной последовательности слов. Этот этап является итеративным,и продолжается до тех пор, пока Модель не выдаст полный и последовательный ответ или не достигнет заранее определенного предела (например,,количество слов).

Фаза автоматической генерации регрессии начинается с начального контекста.

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

at вычислить следующий Токен на основе сгенерированной последовательности

распределение вероятностей

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

。

Третий шаг — передать выбранный Токен.

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

Parallelism Method for LLM Service

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

2.2.1 Data parallelism

Для обработки большого количества запросов в средах облачных вычислений применяется параллелизм данных. В дата-центре LLM реплицируются. Базовая вычислительная единица называется экземпляром и содержит полную копию модели. Каждый экземпляр работает независимо и одновременно обрабатывает разные пакеты запросов.

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

Чтобы повысить пропускную способность сервисов LLM на графическом процессоре, были введены различные методы повышения пропускной способности сервисов LLM на графическом процессоре.

2.2.2 Model Parallelism

Модельный параллелизм — это метод обработки LLM, которые невозможно полностью вывести из памяти одного графического процессора. Это предполагает разделение модели на несколько устройств или узлов. Модельный параллелизм можно в основном разделить на две категории: конвейерный параллелизм и тензорный параллелизм.

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

Тензорный параллелизм. Он включает в себя разделение слоев модели на несколько графических процессоров. Для LLM тензорный параллелизм имеет решающее значение, когда один слой модели слишком велик для одного графического процессора. Это позволяет параллельно обрабатывать огромные матричные операции внутри слоя несколькими графическими процессорами. Благодаря параллелизму тензорной модели один слой модели можно разделить на несколько устройств.

3 Motivation and Main Idea

Произошёл значительный всплеск в развитии долгосрочного контекста LLM: контекстное окно увеличилось с 2 КБ до впечатляющих 256 КБ всего за один год. Этот прогресс продолжается, и приложения LLM теперь требуют поддержки для еще более длинных контекстов.

Увеличение длины контекста оказывает существенное влияние на Систему. обслуживания LLM создает серьезные проблемы, особенно когда контекстное окно масштабируется до впечатляющих размеров, а для KV Требования к вычислительным ресурсам и памяти Cache также возрастают.

Таблица 1 иллюстрирует эту тенденцию, показывая прямую связь между размером KV-кэша и ростом длины контекста для модели LLaMA2-13B. Современные графические процессоры с объемом памяти от десятков гигабайт до нескольких терабайт ограничены и требуют большего объема памяти для размещения растущего размера KV-кэша.

Challenges to LLM serving on Cloud

в этой статье,Автор стремится эффективно использовать большой объем памяти графического процессора и процессора в центре обработки данных.,Цель состоит в том, чтобы создать эффективный пул памяти, специально разработанный для LLM Служить, способный обрабатывать контексты очень большой длины. Однако,Разработка такой системы – непростая задача. Авторы определили две основные проблемы, которые возникают при предоставлении Служить для большой языковой Модели с расширенным контекстом на облачной платформе.

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

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

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

Проблема 2. Динамический характер размера KV-кэша приводит к неэффективному управлению ресурсами в облачных средах. Базовая природа автоматической регрессии определяет, что окончательная длина последовательности все еще неизвестна до конца процесса генерации, обычно представленного символьным маркером «конец». Таким образом, требования к памяти совершенно динамичны и непредсказуемы, значительно колеблясь в масштабе. Спрос может варьироваться от нескольких ГБ до сотен ГБ и продолжает расти.

Эта изменчивость исключает любую форму предварительного планирования ресурсов. Ресурсы должны распределяться или освобождаться динамически, чтобы удовлетворять потребности процесса автоматической регрессии в режиме реального времени. Если объем памяти, необходимый для контекста, превышает емкость графического процессора экземпляра, всю задачу необходимо переместить в более крупный экземпляр с большим количеством графических процессоров. Этот процесс называется живой миграцией. Живая миграция требует ресурсов и, как показывают эксперименты авторов, может быть до 25 раз дороже, чем стандартный вывод. Другой вариант — с самого начала выделить больше графических процессоров для вычислительного экземпляра, что может привести к пустой трате ресурсов для задач, включающих более короткие контексты, что еще больше усложнит задачу эффективного распределения ресурсов.

PagedAttention Управляйте KV с помощью детальных подблоков страниц, подобных ОС. Cache。Однако,Этот метод ограничен использованием памяти ЦП для подкачки.,Этот подход оказывается неэффективным в облаке. Ограничения, налагаемые ограниченной памятью ЦП, не только ограничивают максимальную длину контекста, которую может поддерживать LLMCлужить.,И он не использует преимущества огромных ресурсов памяти, распределенных в облаке. В сравнении,Цель автора — в полной мере использовать обширные возможности памяти графических и центральных процессоров в центре обработки данных. Автор стремится создать хорошо продуманный и эффективный пул памяти, предназначенный для LLMCлужить.,Для поддержки обработки чрезвычайно длинных контекстов.

Main Idea

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

Чтобы выполнить задачу 1,Автор предложения представил новый алгоритм внимания под названием DistAttention. Этот алгоритм разбивает традиционные вычисления внимания на более мелкие и более управляемые блоки.,макровнимание（MAs）и соответствующее емуKV Кэш(р Блокс). Этот инновационный подход позволяет КВ Расчет кэша и стандартные стандарты блоков Transformer Transformer Разделение блоков, позволяющее независимо применять стратегии параллелизма моделей и управление памятью между уровнем внимания и другими уровнями. Для уровня невнимания применяется установленная стратегия параллелизма модели. Напротив, уровень внимания управляется адаптивно, динамически распределяя память и вычислительные ресурсы в центре обработки данных в ответ на KV. Изменения в кэше.

Чтобы преодолеть задачу 2,Автор предложения DistKV-LLM,Это своего родаDistAttentionБесшовная интеграция的распределенныйLLMСлужитьдвигатель。DistKV-LLMРазработан для обеспечения эффективногоKV Кэш управляет Служить и координирует использование памяти графического процессора и процессора в центре данных. Когда LLM Служить экземпляр из-за КВ Когда кэш увеличивается и возникает нехватка памяти, DistKV-LLM может заранее идентифицировать и занять доступное пространство памяти других экземпляров (с избыточной емкостью), как показано на рисунке 2.

Этот автоматический механизм достигается за счет сотрудничества двух основных компонентов rManager и gManager. rManager виртуализирует всю память GPU и CPU в каждом экземпляре LLM.,Обработка запросов операций с памятью от локальных и удаленных экземпляров. в то же время,gManager в качестве глобального координатора,поддерживать соглашение,Обеспечить эффективное, масштабируемое и согласованное управление ресурсами между распределенным rManager.

также,DistKV-LLMпредлагает новый алгоритм DGFM,Эффективно решает проблему фрагментации памяти в распределенном KV Cache-среде Data Center. Эти совместные усилия обеспечивают непрерывное и эффективное использование памяти.,Тем самым улучшая общую производительность и надежность LLM Служить.

Суммируя,Авторский ансамблевый метод в сочетании с DistKV-LLMиDistAttention,Служитьпредлагать — это мощное и масштабируемое решение для LLM с длинным контекстом в облаке. Путем решения основных проблем, связанных с управлением памятью и планированием вычислений.,Убедитесь, что LLM Служить может эффективно и адаптивно работать в облаке. Эта инновационная структура не только оптимизирует использование ресурсов,Это также открывает путь к будущим передовым технологиям, которые позволят широкомасштабное внедрение языков.

4 Method

Overview

в следующем разделе,Сначала представим DistAttention,Это инновационный алгоритм внимания,Предназначен для продвижения распределенногоKV Управление кэшем и расчет, подробности см. в разделе 4.2. На основе этого предложенияDistKV-LLM, выделенный кластерный распределенный графический процессор с эффективным использованием памяти KV. Сервисный механизм LLM, управляемый Cache.

Подход авторов включает в себя несколько ключевых компонентов: во-первых,,rManager представлен в разделе 4.3.,Это программный уровень, который виртуализирует память графического процессора и процессора для каждого экземпляра LLM. Он обеспечивает уровень абстракции,называется rBlocks,Для повышения эффективности управления памятью. Во-вторых,Комплексный протокол, поддерживаемый gManager, описан в разделе 4.4.,Это глобальная система управления. Это обеспечивает эффективное, безопасное и согласованное управление rBlocks на распределенных графических процессорах в Центре обработки данных. Инновационный алгоритм, специально разработанный для агрегирования фрагментированных блоков памяти, подробно обсуждается в разделе 4.5.,Тем самым существенно улучшая распределенныйKV Местоположение данных внутри Cachesystem. Наконец, в разделе 4.6 предложение представляет серию стратегий оптимизации, направленных на минимизацию Распределенный кэш хранит связанные с ним огромные накладные расходы на связь, эффективно перекрывая вычислительные и коммуникационные задачи. Более подробная информация об этой конструкции обсуждается в следующих разделах.

DistAttention

Чтобы справиться со сложностями управления памятью, автор разработал новый алгоритм внимания DistAttention. Этот алгоритм эффективно преобразует KV Кэш разделен на более мелкие, более управляемые части, что облегчает распределенное управление памятью в центре обработки данных. Ключом к этому подходу является разделение DistAttention на несколько микровниманий (MA), каждый MA содержит KV. CacheToken的一индивидуальный子序列。这种设计设计的一индивидуальный独特方面существовать于,Он может рассчитывать результаты внимания, рассчитывая MA отдельно. Когда все микровнимания (MA) завершили вычисления в своих соответствующих подблоках токенов.,Конечный результат внимания можно получить посредством процесса агрегирования. Этот процесс агрегирования включает масштабирование и снижение производительности каждой MA. Подробный метод и точная формула этого процесса агрегации будут подробно описаны в следующем уравнении:

Расчет сокращения выглядит следующим образом:

Этот метод не только объединяет расчеты, выполняемые одним MA.,но и эффективно синтезировать их в последовательный окончательный результат,Демонстрируется эффективность авторской реализации каркаса распределенной обработки в алгоритме внимания.

The rBlock and rManager

После реализации DistAttention кэш значений ключей (KV) LLM делится на более мелкие блоки, называемые rBlocks. Каждый rBlock содержит набор векторов, соответствующих фиксированному количеству токенов «ключ-значение», а также некоторые ключевые метаданные. Эти метаданные предоставляют информацию о подразделах. critical Информация: rBlock IDи экземпляра указывает KV в этом rBlock Независимо от того, принадлежит ли кэш локальному экземпляру или удаленному экземпляру; физический идентификатор устройства отмечает физическое местоположение rBlock, который может находиться на стороне ЦП или на одном из нескольких графических процессоров.

Каждый экземпляр службы LLM оснащен выделенным диспетчером rBlock, который называется rManager. rManager отвечает за мониторинг всех rBlocks на локальном устройстве. Он виртуализирует пространство глобальной памяти, разделяя глобальную память графического процессора на физические блоки rBlock фиксированного размера. Каждый физический rBlock спроектирован как блок хранения логического rBlock. rManager поддерживает подробную таблицу сопоставлений для сопоставления этих логических блоков rBlock с соответствующими физическими адресами rBlock в глобальной памяти, как показано на рисунке 3.

rManager предоставляет унифицированный интерфейс API, который может обслуживать как локальные, так и удаленные экземпляры. Эти операции включают в себя выделение физических блоков rBlock для вновь созданного KV-кэша и их освобождение, когда они больше не нужны. При получении запроса на выделение памяти rManager запросит таблицу rBlock, чтобы определить первое доступное физическое пространство rBlock.

В этом сценарии, если свободного места недостаточно, rManager начнет процесс заимствования места у других экземпляров. Более подробная информация будет описана в разделе 4.4. Стоит отметить, что если запрос на выделение исходит от удаленного экземпляра, rManager запрограммирован на автоматический возврат ответа об ошибке, указывающего, что прямое удаленное выделение невозможно. Авторы накладывают ограничение на количество rBlocks, которое можно назначить удаленным экземплярам, ​​которое определяется экспериментально и настраивается как гиперпараметр.

The gManager and Contract Protocol

Ключевой компонент системы авторов, называемый gManager, служит центральным менеджером, ответственным за поддержание информации о глобальной памяти для всех экземпляров. Каждый экземпляр периодически отправляет контрольный сигнал в gManager, чтобы сообщать об обновлениях оставшегося свободного пространства памяти. Используя эти данные, gManager создает подробную таблицу под названием «Книга глобального долга», показанную на рис. 4.

Когда объема памяти экземпляра недостаточно для поддержки rBlocks, соответствующий rManager заимствует пространство памяти графического процессора или ЦП у соседних экземпляров. Перед этим rManager, как должнику, необходимо инициировать Query , сообщая объем памяти, который необходимо занять. при получении этого Query час,gManager будет просматривать глобальную долговую книгу,и ответить на идентификатор потенциального кредитора,ЭтиIDПредставляет экземпляр, у которого в данный момент имеется оставшееся пространство памяти.。Процесс отбора следующийместоположение и доступностьв принципе,Прямо Сейчас Выбирайте экземпляры-кредиторы на основе наименьшей относительной стоимости связи и наибольшего доступного объема памяти. gManager предложил в качестве предложений три идентификатора потенциальных кредиторов.

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

Далее описываются ключевые компоненты и аспекты проектирования договорного соглашения.

Книга глобального долга:Зависит отgManager管理的全球债务账簿是一индивидуальный关ключ的表格,Записывает память, доступную в сети, и задолженность между экземплярами. Каждая запись представляет собой экземпляр LLMCлужить.,Подробно перечисляет идентификатор экземпляра и доступное пространство памяти. Последующие подполя в каждой записи указывают идентификатор экземпляра должника и количество rBlocks, каждый из которых заимствован у кредитора.

Конкурирующие кандидаты:существовать多индивидуальный债务人实例同час向rManagerВ сценарии отправки запроса,Система должна эффективно справляться с этими конкурирующими требованиями. Глобальная долговая книга играет здесь важную роль,Позволяет gManager равномерно распределять запросы по экземплярам.,Это предотвращает перегрузку любого отдельного экземпляра. с другой стороны,rManager применяет политику «первым пришел первым обслужен».,Выделите физическое пространство для rBlocks на удаленном экземпляре. Если из-за нехватки места,rManager не может выделить достаточное количество физических блоков rBlock для удаленных блоков rBlocks.,Он отправит поддельный ответ экземпляру должника. Этот ответ также заставляет gManager обновить текущую запись доступности ресурса.,Это останавливает пересылку новых запросов до тех пор, пока не станут доступны ресурсы. Такой подход обеспечивает сбалансированное и упорядоченное распределение ресурсов памяти.,Уменьшает потенциальные узкие места системы.

последовательность：принял свободныйпоследовательность Стратегия,Прямо сейчасgManagerиrManagersмежду。Таким образом,gManager не требуется строго отслеживать операции выделения или освобождения памяти для всех экземпляров. Напротив,Он собирает эту информацию с помощью тактовых импульсов, которые отправляются автоматически через регулярные промежутки времени. поэтому,gManager поддерживает общее использование пространства в центре обработки данных.,Вместо подробных данных в реальном времени.

Когда должники rManager запрашивают заемное пространство, gManager предоставляет только предложения потенциальным кандидатам-кредиторам. Должник должен провести переговоры с этими предполагаемыми кредиторами, чтобы определить распределение памяти. Ситуации, включающие несколько одновременных запросов к одному и тому же rManager, управляются с использованием стратегии конкурирующих кандидатов, обсуждавшейся ранее. Эта слабосвязанная структура согласованности не только упрощает операции, но и сводит к минимуму чрезмерные накладные расходы на транзакции, тем самым уменьшая задержку обработки и улучшая общую производительность системы.

Масштабируемость：Для удовлетворения различных требований к пропускной способности,gManager предназначен для одновременной обработки Query запрос на улучшение масштабируемости. Чтобы ускорить процесс определения экземпляров, у которых осталось свободное место в памяти, gManager периодически инициирует операцию сортировки. Эта операция сортирует экземпляры в соответствии с оставшимся доступным пространством памяти таким образом, что Query Запросы могут эффективно обходить экземпляры с минимальными ресурсами памяти.。Такой подход обеспечиваетgManagerРаботать на оптимальной мощности,при масштабировании для удовлетворения динамических требований сети,Оставайтесь эффективными и отзывчивыми.

Fragmented Memory Management

Из-за динамической природы длины контекста и пакетной обработки,Управление памятью сталкивается с ключевой проблемой — фрагментацией. Каждый экземпляр в системе является одновременно кредитором и должником памяти.,При необходимости заимствуйте или освобождайте память у других экземпляров. Например,Количество экземпляров, обрабатывающих длинные контекстные запросы, может продолжать расти,Необходимо занять место у удаленного экземпляра.

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

Автор предложения предложил алгоритм управления фрагментированной памятью на основе графа долга.,ДГФМ,Разработано для решения этой проблемы путем стратегического отзыва предоставленного пространства памяти и обмена его на локальное хранилище данных. Ключевой проблемой в этой проблеме является большое количество экземпляров LLM Служить, работающих в дата-центре.,Эти случаи часто связаны со сложными долговыми отношениями.

Чтобы эффективно справиться с этой сложностью,Авторы концептуализируют эту задачу как поиск окружностей в ориентированном графе. первый,Автор строит направленный граф-зеркало, отражающий данные долговые отношения.,где каждый узел представляет экземпляр,Каждое направленное ребро представляет собой долг одного экземпляра перед другим экземпляром. Алгоритм авторов затем применяется итеративно. в каждой итерации,Алгоритм случайным образом выбирает узел и обходит граф, чтобы определить направленную окружность. Крайне важно обнаружить такой круг,Потому что это показывает, что участвующие узлы (или экземпляры) могут погасить свои долги друг перед другом. Этот обходной путь достигается путем стратегического вызова и замены соответствующих блоков памяти.,Тем самым улучшая общую эффективность системы и использование памяти. Детали этого алгоритма показаны на рисунке 5и Алгоритм 1.

Ориентированный граф получен из мировой долговой книги.,Алгоритм DGFM выполняется gManager. Когда распознается направленный звонок,gManager сделает запрос к rManager соответствующего экземпляра,Заморозьте их, чтобы предотвратить изменение или отмену. Автор устанавливает эмпирический порог для каждого узла,Чтобы определить минимальное количество блоков памяти (rBlocks), которые необходимо поменять местами,Чтобы предотвратить неэффективные операции вызова и обмена на слишком маленьких блоках памяти. Этот процесс значительно снижает потребность в удаленном доступе к памяти.,Тем самым улучшая локальность данных,В конечном итоге это приводит к заметному улучшению системыпроизводительности.

Communication Optimization

распределенныйKV Хранилище кэша сталкивается с еще одной проблемой: при выполнении длинных контекстных задач в LLM Служить этапы предварительного заполнения и автоматической регрессии могут генерировать большое количество KV. Cache, из-за чего rManager занимает удаленное пространство. Автор произвел специальную оптимизацию для этих двух ситуаций, как показано на рисунке 6.

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

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

раз, из них

Указывает количество токенов в кэше KV. Ограничением этого подхода является то, что он может конкурировать с главным экземпляром удаленных rBlocks за вычислительные ресурсы.

Чтобы смягчить этот эффект,Порог устанавливается в каждом rManager,В соответствии с местными правилами SLA,Суждение на основе объема заемных вычислительных ресурсов,Обеспечить сбалансированное и разумное использование вычислительных ресурсов.

5 Implementation Details

DistAttention содержит два типа операторов.,Это DistAttnиScaleReduce.,При разработке этих операторов было использовано около 5000 строк кода C++/CUDA. Оператор DistAttn специально используется для вычислений распределенного внимания.,Агрегация результатов с помощью оператора ScaleReduce,Чтобы получить конечный результат вывода.

Чтобы учесть диапазон длин входного контекста,DistAttn использует процесс адаптивного выбора ядра.,Процесс основан на входных размерах。上下文длинный度被分为三индивидуальный组：нормальный диапазон（0-8k）、длинный范围（8k-32k）и超длинный范围（>32k）,Авторы разработали и тщательно оптимизировали три различных ядерных шаблона для каждой из этих групп. также,Авторы также разработали и реализовали эвристику,Точная настройка адаптивных ядер CUDA для конкретных форм тензоров.

с другой стороны,DistKV-LLM адаптирует платформу Ray к распределенной системе управления и планирования KV Cache.,Для разработки этого проекта потребовалось около 12 000 строк кода Python. Для эффективной реализации запроса и передачи данных по сети,Автор настроил кодировку пакета,И используйте сокеты вместо фреймворков на основе RPC для передачи пакетов данных. Чтобы максимально использовать преимущества высокой пропускной способности RDMA,Автор использует NCCL для межэкземплярной тензорной связи графического процессора.,Обеспечьте эффективный обмен данными между распределенными экземплярами.

6 Evaluation

В этом разделе представлены результаты оценки работы авторов.

среда。作者существовать一индивидуальный拥有4индивидуальный节点и32индивидуальныйGPU的набор群上部署了DistKV-LLM。每индивидуальный节点有8индивидуальныйNVIDIA A100（80GB）GPU。

Модель。作者的框架现существовать可以支持大多数流行的LLM,Такие как GPT,LLaMA,БЛУМ и др. Так как большинство LLMМоделей имеют схожие блоки Трансформеры.,Авторы выбрали для оценки репрезентативную МодельLLaMA2. Семейство LLaMA2 включает модели трех разных размеров: 7B.,13Би70Б. Они используют две популярные архитектуры внимания: 7Bи13BМодель использует многоголовое самообслуживание (MHA).,А 70BМодель использует группировку Query Внимание (GQA).

эталон。Выбор автораvLLM,Прямо сейчас Latest LLM Служить двигатель, как главный эталон. Более того, большинство предыдущих систем обслуживания LLMиспользовать Тензорный параллелизм.Для проверки параллелизма конвейера с помощью последовательной пакетной обработки.,Дизайн, аналогичный Alpa, реализован в рамках vLLM.,Как один из эталон.

Context Length Benchmark

Оцените и сравните производительность DistKV-LLM иэталон при различной длине контекста. Авторы оценили три модели с разными контекстными рамками. Для LLaMA2-7B,Оценено на 2 графических процессорах для задач от 1 до 200 тыс.,Оценивалось на 16 графических процессорах для задач 1–1200 тыс.,Оценивалось на 32 графических процессорах для задач 1-1900к. Для LLaMA2-13BМодель,Оценивалось на 4 графических процессорах для задач 1–280 тыс.,Оценивалось на 8 графических процессорах для задач 1-480к. Для LLaMA2-70BМодель,Оценивалось на 8 графических процессорах для задач 1-450к.

Чтобы проверить производительность DistKV-LLM, авторы сравнили его с двумя версиями теста vLLM. vLLM-v1 содержит такое же количество графических процессоров, что и DistKV-LLM в одном экземпляре.

На рис. 7 показан vLLM-v1.,Пропускная способность vLLM-v2иDistKV-LLM при разной длине контекста. Стоит отметить, что,DistKV-LLM (синий) не только обеспечивает сопоставимую пропускную способность с vLLM-v1 (зеленый),и поддерживает более длинные контексты,Как показано на рисунке 7.,Примерно 2х-19х. Это улучшение связано со способностью DistKV-LLM эффективно координировать использование памяти во всех экземплярах.,А vLLM-v1 ограничен частной памятью экземпляра.

vLLM-v2 предварительно выделяет больше графических процессоров для поддержки сопоставимой длины контекста с DistKV-LLM. Сравнивая с vLLM-v2 (красный), авторы демонстрируют, что DistKV-LLM обеспечивает значительно более высокую пропускную способность при сохранении аналогичной длины расширенного контекста.

Как показано на рисунке 7, DistKV-LLM обеспечивает пропускную способность в 1,4–5,3 раза выше, чем vLLM-v2. Это связано с тем, что DistKV-LLM может поддерживать эффективную стратегию параллелизма моделей, в то время как vLLM-v2 делит модель на более мелкие фрагменты на большем количестве графических процессоров, что приводит к снижению эффективности оборудования.

End-to-end Serving Performance

Авторы используют экспериментальную установку, описанную в разделе 6.1, и запускают соответствующий набор данных с контекстной областью, чтобы оценить сквозную производительность DistKV-LLM. Результаты эксперимента показаны на рисунке 8. Когда кривая резко возрастает, это указывает на то, что пропускная способность достигла предела системы, запросы начинают накапливаться, а задержка быстро увеличивается.

В наборах данных, содержащих запросы длиной 1%, DistKV-LLM обеспечивает улучшение примерно в 1,4–2,4 раза по сравнению с базовым уровнем. Это связано с тем, что разбиение модели на более мелкие части приводит к снижению использования графического процессора, что значительно снижает эффективность линейных вычислений. В наборе данных, содержащем 10 % длинных запросов, DistKV-LLM обеспечивает повышение производительности примерно в 1,1–1,4 раза по сравнению с базовым уровнем. В наборе данных, содержащем 30 % длинных запросов, DistKV-LLM обеспечивает повышение производительности примерно в 1,03–1,3 раза по сравнению с базовым уровнем.

По мере увеличения доли длинных запросов в наборе данных улучшение производительности, обеспечиваемое DistKV-LLM, постепенно снижается. Это связано с тем, что соотношение линейных вычислений и вычислений внимания ниже, когда модель обрабатывает длинные контекстные запросы. Улучшение производительности, полученное DistKV-LLM в части линейных вычислений, становится меньшей частью общих вычислительных усилий, в то время как производительность вычислений внимания ненамного лучше, чем базовый уровень.

Live Migration

Еще один способ справиться с изменениями длины контекста — живая миграция.,При необходимости он может переносить задачи на более мощные экземпляры с большим количеством графических процессоров. В этом эксперименте,Сравните живую миграцию DistKV-LLMи на LLaMA2-7BМодель. Для новых экземпляров,LLMМодельпроходитьAmazonПростое хранение Служить（Amazon S3) загружается и загружается vLLM в формате SafeTensor.

Первоначально сервис был развернут с использованием графического процессора A100, который мог обрабатывать запросы максимальной длиной 108 КБ. Если длина контекста превышает 108 КБ, для расширения следует использовать дополнительные графические процессоры A100. Результаты показаны на рисунке 9.

Горизонтальная ось представляет длину кия.,Вертикальная ось представляет задержку при генерации соответствующей выходной длины. Накладные расходы, связанные с живой миграцией, в 45 раз превышают накладные расходы на связь в DistKV-LLM. Когда длина контекста составляет 105 КБ, приглашение и 5 КБ, вывод.,Будет запущена живая миграция. в этом сценарии,Задержка значительно увеличивается при использовании vLLM,С другой стороны, DistKV-LLM испытывает лишь незначительные нарушения. Когда сгенерированная длина равна 5k,10k,Токен 20 000 и 30 000,Время завершения DistKV-LLM в 3,5 раза больше, чем у vLLM соответственно.,2,2 раза,В 1,6 и 1,4 раза быстрее. Это связано с тем, что миграция всего Служить повлечет за собой много накладных расходов.,Включая удаленную загрузку Модели по высокоскоростной ссылке для скачивания (несмотря на использование высокоскоростной ссылки для скачивания) и загрузку Модели в механизм вывода. В сравнении,DistKV-LLM необходимо только установить соединение с устройством расширения.,Не нужно скачивать и загружать Модель.

Optimizing Memory Allocation

Длина контекста и динамика пакетной обработки приводят к ухудшению локальности. Алгоритм DGFM предназначен для оптимизации распределения памяти за счет использования предоставленного пространства памяти. В этом эксперименте Ла МА2-13Б с четырьмя tp2примерDistKV-LLMСлужить,Способен обрабатывать запросы длиной от 1 до 480 тыс. Автор сравнил пропускную способность Служить с DGFM и не включенную производительность.,Результаты показаны на рисунке 10.

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

Ablation Study

DistAttention Авария. DistAttention предоставляет возможность хранить и вычислять внимание между экземплярами, что также приводит к некоторым накладным расходам. Эти накладные расходы в основном связаны с одним токеном. Query 、ключи Тензор стоимости передачи значений,и некоторые другие накладные расходы,Например, тензорная нарезка и сплайсинг.

в 8 А100 На экземпляре графического процессора развертываются два экземпляра, которые совместно используют хранилище и вычислительные ресурсы через DistKV-LIM. Время работы DistAttention было изменено. breakdown анализ и сравнил его с вниманием, разделенным на восемь частей посредством тензорного параллелизма.

Результаты показаны на рисунке 11. Дополнительные накладные расходы приводят к задержке 5–10 % по сравнению с вниманием TP8. Эта дополнительная задержка почти постоянна, а это означает, что по мере увеличения длины контекста эти издержки становятся пропорционально меньшими.

Сравните удаленные вычисления и локальные вычисления. Существует две стратегии расчета удаленно выделенных rBlocks:

1. Локальные вычисления: верните KV-кэш удаленного экземпляра через высокоскоростной Интернет и выполните полные вычисления внимания локально;
2. Удаленные вычисления: будет Вектор запроса передается в местоположение rBlocks, где находится удаленный экземпляр.,Реализация распределенного расчета внимания через DistAttention,Затем верните полученный вектор обратно. Результаты этих двух методов показаны на рисунке 12.

Задержка локальных вычислений значительно выше, чем задержка удаленных вычислений. Это связано с тем, что локальным вычислениям необходимо передавать большое количество удаленного KV-кеша обратно в локальный экземпляр через сеть, что ограничено пропускной способностью сети и значительно увеличивает общую задержку. . В DistKV-LLM авторы используют этот экспериментальный результат для оптимизации связи, обсуждаемой в разделе 4.6 в rManger.

7 Related Works

Существующая система обслуживания LLM。недавнопредлагатьмного Система обслуживания Магистр права. ORCA представляет итерацию Level Стратегия планирования значительно улучшает вычисления и использование памяти при пакетной обработке. Чтобы решить проблему нерационального использования памяти из-за фрагментации и повторной репликации, компания vLLM разработала Paged KV-кэш и Paged Механизм внимания. Предложение DeepSpeed-FastGen предлагает новую стратегию комбинации генерации сигналов под названием Dynamic. SplitFuse предназначен для дальнейшего повышения производительности системы непрерывной пакетной обработки. AlpaServe исследует возможность статистического мультиплексирования посредством параллелизма моделей в сценариях с пакетной частотой запросов.

FasterTransformerиDeepSpeed Вывод реализует модель Трансформера pioneer и extensive Kernel Level Оптимизирована производительность pioneered и extensive。TGI, TensorRT-LLMиlmdeployсуществовать基于FasterTransformerна основе,Адаптирован к таким функциям, как непрерывная пакетная обработка и внимание к страницам. Хотя эта новая система решила множество проблем и добилась отличных результатов.,Но динамические проблемы и необходимость поддержки необычно длинных контекстов остаются нерешенной проблемой.

С кольцом Внимание (Кольцо Внимание) сравнение.привлечь внимание（Ring Внимание) — это метод распределения длинных последовательностей между несколькими устройствами с целью полного перекрытия передачи внимания на уровне блоков с блоками KV. Этот метод подходит для обучения и вывода длинных последовательностей. предварительного заполнения Очень эффективный。Однако,На этапе расшифровки рассуждений,Передачу блоков КВ между устройствами невозможно скрыть расчетами.,Вызывает много накладных расходов. На рисунке 12 показано, что издержки передачи блока KV значительно выше, чем издержки связи DistAttention.

Другой класс подходов к управлению кэшами очень больших значений данных (KV) для вывода длинного контекста включает в себя разреженные кэши KV, такие как внимание скользящего окна (внимание скользящего окна). Window Внимание). Этот метод требует только поддержания кэша KV размером с окно. H2O и StreamingLLM также сохраняют KV-кэш фиксированного размера окна, но они интегрируют внимание, используя алгоритм удаления KV-кеша и приемник, чтобы уменьшить потерю точности, вызванную отбрасыванием контекстной информации. Однако, поскольку эти методы отбрасывают некоторую контекстную информацию, они в определенной степени ставят под угрозу эффективность больших языковых моделей (LLM).

8 Conclusion

Динамический и авторегрессионный характер вычислений вывода LLM создает серьезные проблемы для LLM в облаке.,Особенно при работе с задачами, включающими длинные контекстные последовательности. Для решения этих проблем,Автор предложения от DistAttention,Это инновационный алгоритм распределенного внимания.,KV-кэш можно эффективно разделить на управляемые блоки для распределенной обработки.

также,Автор также разработал распределенныйLLMСлужить движок DistKV-LLM.,Он превосходно справляется с управлением кэшем KV.,Использование памяти в центре обработки данных можно оптимизировать. Этот метод в сочетании с DistAttention и DistKV-LLM эффективно гарантирует, что при обработке длинных контекстных задач,LLM Cloud Служить — это гладко и эффективно. В комплексной оценке 32 графических процессоров NVIDIA A100 и 18 наборов данных.,Авторская система показывает повышение производительности по сравнению с существующими решениями в 1,03-2,4 раза.,и поддерживает длину контекста в 2–19 раз большую.,Продемонстрированная эффективность в решении различных задач по созданию контекста.

ссылка

[1]. Infinite-LLM: Efficient LLM Service for Long Context with DistAttention and Distributed KVCache