В последнее время модели-трансформеры трансформируют ландшафт глубокого обучения, особенно обработки естественного языка, благодаря их превосходному отслеживанию взаимосвязей между последовательными данными, такими как слова в предложении. Среди некоторых популярных предварительно обученных трансформеров — PaLM от Google (Chowdhery et al, 2022), Gopher от DeepMind (Rae et al, 2022) и OPT от Facebook (Zhang et al, 2022). С другой стороны, эти современные модели могут быть громоздкими и ресурсоемкими, что делает их использование дорогостоящим. GPT-3 (Браун и др., 2020), например, имеет 175 миллиардов параметров—обслуживание моделей такого размера может привести к высоким затратам из-за накладных вычислений.

Поэтому мы в FriendliAI внедрили систему распределенного обслуживания под названием Orca для генеративных моделей на основе Transformer. Orca развернута как облачная служба FriendliAI в рабочей среде.

Наша оценка модели GPT-3 175B показывает, что Orca может значительно превзойти NVIDIA FasterTransformer как по задержке, так и по пропускной способности: увеличение пропускной способности в 36,9 раз при том же уровне задержки. Работа была представлена ​​в OSDI ' 22 тоже.

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

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

Планирование на уровне итерации

Планирование на уровне итерации — это новый механизм планирования, который планирует выполнение с детализацией итерации. Мы определяем прогон всех слоев как итерацию модели. Существующие системы обслуживания моделей в основном предназначены для планирования выполнения с детализацией запроса. То есть обслуживающая система и исполнительный механизм взаимодействуют друг с другом только тогда, когда (1) обслуживающая система планирует следующий пакет запросов на бездействующем механизме; или (2) механизм завершает обработку запросов в текущем пакете. Это может быть проблематично при обслуживании генеративных моделей, поскольку для разных запросов в пакете может потребоваться разное количество итераций, в результате чего некоторые запросы завершатся раньше, чем другие.

На приведенном выше рисунке показан случай, когда обслуживающая система планирует работу ядра с точностью до запроса. Здесь, хотя запрос x₂​ завершился раньше, чем x₁​, он выполнил некоторые дополнительные вычисления (этапы 3 и 4) до тех пор, пока x₁​ не был завершен. Такое поведение ограничивает эффективность пакетного выполнения. Кроме того, ранее завершенные запросы не могут быть возвращены клиенту быстро, так как механизм будет возвращать результаты выполнения обслуживающей системе только после завершения обработки каждого запроса в пакете. Точно так же, когда новый запрос поступает в середине выполнения, он должен ждать, пока текущий пакет не будет полностью обработан.

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

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

Что же мы подразумеваем под операцией на уровне итерации? Планировщик в основном повторяет следующую процедуру:
(1) выбирает запросы для выполнения следующими;
(2) вызывает механизм для выполнения одной итерации для выбранных запросов;
(3) получает результаты выполнения для запланированной итерации.

GIF ниже показывает процесс в анимации.

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

Выборочное дозирование

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

Операции в слоях Transformer можно разделить на два типа: Attention и Non-Attention. Операции без внимания, такие как операции Linear, Layer-Norm и GeLU, не требуют различения тензорных элементов разных запросов. Следовательно, запросы могут группироваться по токенам, а не по запросам.

Например, на диаграмме, когда планировщик решает запустить итерацию для пакета (x₁​,x₂​,x₃​,x₄​), входные данные x₃​, x₄​ не могут объединиться в один тензор формы [B,L ,…], так как они имеют разное количество токенов (L), 2 и 3 (B: размер пакета, L: количество токенов, обрабатываемых вместе). Однако два запроса могут по-прежнему составлять тензор формы [∑L,…]=[5,…] без явного пакетного измерения, прежде чем они будут переданы в операции без внимания. Таким образом, пакетная обработка может быть достигнута с помощью операций без внимания, хотя и с помощью токенов.

Однако с операциями Attention пакетная обработка— по запросу или токену— не может быть выполнена. Это связано с тем, что для операции Attention требуется понятие запросов (т. е. требуется пакетное измерение) для вычисления внимания только между маркерами одного и того же запроса. Чтобы снова обратиться к диаграмме выше, запросы x₁​ и x₂​ имеют разное общее количество токенов (ввод + сгенерировано), 4 и 2 соответственно, что означает, что тензоры не могут быть объединены в один тензор. В отличие от предыдущих, их также нельзя сгладить, игнорируя пакетное измерение, поскольку x₁​ и x₂​ по-прежнему необходимо различать по запросу, прежде чем их можно будет передать в операции Attention.

Именно здесь вступает в игру наше второе решение, выборочная пакетная обработка. Вместо того, чтобы группировать все операции (как с вниманием, так и без внимания), составляющие модель, он выборочно применяет пакетирование только к нескольким операциям (без внимания). Он разделяет пакет и обрабатывает каждый запрос отдельно для операции Attention, применяя пакетную обработку на основе токенов (а не на основе запросов) к операциям, не связанным с Attention. Наше открытие показывает, что решение не группировать выполнение операции «Внимание» также оказывает лишь незначительное влияние на эффективность. В заключение, выборочная пакетная обработка обеспечивает большую гибкость при составлении запросов в виде пакетов.

Оценка эффективности

Мы провели оценку на виртуальных машинах Azure ND96asr A100 v4, каждая из которых оснащена 8 графическими процессорами NVIDIA A100 емкостью 40 ГБ, подключенными через NVLink. Здесь GPT-3 с параметрами 175B использовался в качестве репрезентативного примера генеративных моделей на основе Transformer. Мы сравнили Orca с FasterTransformer (базовый уровень), механизмом логического вывода, который поддерживает крупномасштабные модели Transformer посредством распределенного выполнения. Поскольку FasterTransformer не имеет собственного планировщика, мы реализовали собственный планировщик, который имитирует пакетный планировщик Сервера вывода NVIDIA Trition.

Orca превзошла FasterTransformer как по задержке, так и по пропускной способности. Например, чтобы соответствовать задержке в 190 мс, FasterTransformer обеспечивает пропускную способность 0,185 запросов/с, тогда как Orca обеспечивает пропускную способность 6,81 запросов/с, что является 36,9-кратным ускорением. .

Заключение

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

И эксперименты показывают эффективность нашего подхода: Orca обеспечивает на порядок более высокую пропускную способность, чем современные современные системы, при том же уровне задержки.

С Orca использование крупномасштабного ИИ вышло на совершенно новый уровень. Пожалуйста, свяжитесь с FriendliAI, если вы заинтересованы!

*Исследование касатки было представлено на конференции OSDI 2022 12 июля. Статью можно прочитать здесь.

**Orca был разработан FriendliAI. В качестве нашего продукта мы предоставляем комплексную платформу разработки искусственного интеллекта PeriFlow. Для получения дополнительной информации перейдите по ссылке.