Очень глубокий вопрос! Но боюсь, что полный ответ на него — это отдельный пост в этой серии, stay tuned =)
Могу сказать, что взаимодействие каждого из методов мы оцениваем через простой перерасчёт метрик качества и скорости. Обычно в наших комбинациях картина вполне понятная:
lossless методы мы применяем всегда и следим, чтобы каждый из них обеспечивал мультипликативный рост;
среди методов с потерями оставляем лишь те, которые вписываются в допустимые диапазоны потерь для бизнеса (например, «не более -1 пп на внутреннем бенчмарке качества»);
ускорения добавляем итеративно.
На самом деле существует понятная последовательность того, что нужно пробовать в силу технических причин (например, дистилляция после квантизации возможна, но технически сложна, поскольку необходимо уметь оценивать градиент по квантованному слою, т.е. уже уметь делать QAT).
К слову, иногда бывают довольно узкие сценарии, где не все методы ведут себя ожидаемо, например прирост скорости может быть меньше из-за особенностей размера модели. Но он всё равно присутствует, поэтому метод используется.
Поскольку в нашей инфраструктуре попробовать каждый из методов относительно просто для всех поддерживаемых моделей, особой нужды в дереве принятия решений нет. Для каждого конкретного внедрения LLM мы можем попробовать все поддерживаемые методы, а иногда даже попрофилировать и настроить их под «особые нужды в проде».
Как аналог такого дерева решений мы используем грубые оценки по ускорению и просадкам в качестве на этапе дизайна нашего пайплайна для конкретного продукта. Иногда доходит до того, что приходится менять архитектуру, чтобы уложиться в вычислительный бюджет.
Тут много нюансов про то, какой у пользователя смартфон и какую он хочет сетку. Но в общем и целом гонять llama 3.2 1B/3B на современных телефонах с приятной скоростью уже можно: https://pytorch.org/blog/unleashing‑ai‑mobile/
Ну и в целом это довольно распространенная сейчас амбиция среди больших тех. гигантов: использовать compute пользователя там, где его и правда много, вроде:
Конечно же имеет. Тут стоит вспомнить про Tensor Parallel режим инференса (подробнее можно тут почитать). Он отлично себя показывает, когда присутствует NVLink между картами, тогда все GPU отлично утилизируют свои вычислительные ресурсы. Также этот метод отлично сочетается с wNaM квантизацией. По итогу в такой схеме у нас на N картах хранится суммарно одна квантизованная копия весов, то есть 1 / N часть модели. Такой режим позволяет нам вмещать огромный batch_size в карточки, что оч положительно сказывается на RPS нашей API.
Для weight-only квантизации KV-кэш не квантуется, т.к. кэш это часть активаций и с весам ничего общего не имеет.
Напоминаю, что в данном посте мы говорили только про квантизации линейных слоев. Поэтому, если в таком embedder-е на выходе в архитектуре стоит линейный слой, то нет никакой проблемы получать на выходе int8 тензоры.
Я бы смотрел на фреймворк инференса TRT LLM, из общедоступных он дает наилучшую скорость и всю необходимую поддержку фичей.
По методам сильно зависит от сценария, в котором хотим запуститься.
Если инференс собираемся делать с небольшим batch_size и на больших моделях (7B+), то отлично подойдет weight-only квантизация. Из поддержанных в TRT LLM сейчас пожалуй лучше всего себя AWQ покажет.
Если batch_size очень большой и/или модель маленькая (до 1B), то выбора по сути нет и подойдет только квантизация и весов, и активаций. Для богатеев надо вообще не думать и использовать FP8 инференс, который доступен на Hopper и Blackwell. Если все-таки таких современных карт нет, то SmoothQuant вполне хорошо сработает.
Сильно зависит от метода, с которым получаем ускорение. Например, для квантизации почти всегда удается получить незначимую просадку в качестве, для дистилляции она обычно чуть более ощутимая.
Но в любом случае стоит помнить про Парето фронт, который проиллюстрирован в начале статьи. Методы ускорения дают нам больше возможностей выбора финальной модели для нашей задачи, то есть больше точек на этой кривой.
Финальное решение принимают все равно люди: смотрят на имеющиеся вычислительные бюджеты, на получившуюся Парето кривую и выбирают оптимум в зависимости от конкретного продукта/задачи.
Про это как раз написано в одном из параграфов внутри “Для интересующихся: как всё устроено внутри” и приведена статья. Авторы этой статьи обходятся без LSTM и MLP, но используют инициализацию эмбеддингами случайных токенов словаря. Такой подход также получает отличные результаты.
В наших задачах мы тестируем оба способа и выбираем лучший.
Очень глубокий вопрос! Но боюсь, что полный ответ на него — это отдельный пост в этой серии, stay tuned =)
Могу сказать, что взаимодействие каждого из методов мы оцениваем через простой перерасчёт метрик качества и скорости. Обычно в наших комбинациях картина вполне понятная:
lossless методы мы применяем всегда и следим, чтобы каждый из них обеспечивал мультипликативный рост;
среди методов с потерями оставляем лишь те, которые вписываются в допустимые диапазоны потерь для бизнеса (например, «не более -1 пп на внутреннем бенчмарке качества»);
ускорения добавляем итеративно.
На самом деле существует понятная последовательность того, что нужно пробовать в силу технических причин (например, дистилляция после квантизации возможна, но технически сложна, поскольку необходимо уметь оценивать градиент по квантованному слою, т.е. уже уметь делать QAT).
К слову, иногда бывают довольно узкие сценарии, где не все методы ведут себя ожидаемо, например прирост скорости может быть меньше из-за особенностей размера модели. Но он всё равно присутствует, поэтому метод используется.
Поскольку в нашей инфраструктуре попробовать каждый из методов относительно просто для всех поддерживаемых моделей, особой нужды в дереве принятия решений нет. Для каждого конкретного внедрения LLM мы можем попробовать все поддерживаемые методы, а иногда даже попрофилировать и настроить их под «особые нужды в проде».
Как аналог такого дерева решений мы используем грубые оценки по ускорению и просадкам в качестве на этапе дизайна нашего пайплайна для конкретного продукта. Иногда доходит до того, что приходится менять архитектуру, чтобы уложиться в вычислительный бюджет.
Классный вопрос!
Тут много нюансов про то, какой у пользователя смартфон и какую он хочет сетку. Но в общем и целом гонять llama 3.2 1B/3B на современных телефонах с приятной скоростью уже можно: https://pytorch.org/blog/unleashing‑ai‑mobile/
Ну и в целом это довольно распространенная сейчас амбиция среди больших тех. гигантов: использовать compute пользователя там, где его и правда много, вроде:
Mac M1 и выше;
NPU последних моделей Win-ноутбуков;
последние Iphone/Android.
Снова отличные вопросы!
Конечно же имеет. Тут стоит вспомнить про Tensor Parallel режим инференса (подробнее можно тут почитать). Он отлично себя показывает, когда присутствует NVLink между картами, тогда все GPU отлично утилизируют свои вычислительные ресурсы. Также этот метод отлично сочетается с wNaM квантизацией. По итогу в такой схеме у нас на N картах хранится суммарно одна квантизованная копия весов, то есть 1 / N часть модели. Такой режим позволяет нам вмещать огромный
batch_sizeв карточки, что оч положительно сказывается на RPS нашей API.Для weight-only квантизации KV-кэш не квантуется, т.к. кэш это часть активаций и с весам ничего общего не имеет.
Напоминаю, что в данном посте мы говорили только про квантизации линейных слоев. Поэтому, если в таком embedder-е на выходе в архитектуре стоит линейный слой, то нет никакой проблемы получать на выходе int8 тензоры.
Отличный вопрос!
Я бы смотрел на фреймворк инференса TRT LLM, из общедоступных он дает наилучшую скорость и всю необходимую поддержку фичей.
По методам сильно зависит от сценария, в котором хотим запуститься.
Если инференс собираемся делать с небольшим
batch_sizeи на больших моделях (7B+), то отлично подойдет weight-only квантизация. Из поддержанных в TRT LLM сейчас пожалуй лучше всего себя AWQ покажет.Если
batch_sizeочень большой и/или модель маленькая (до 1B), то выбора по сути нет и подойдет только квантизация и весов, и активаций. Для богатеев надо вообще не думать и использовать FP8 инференс, который доступен на Hopper и Blackwell. Если все-таки таких современных карт нет, то SmoothQuant вполне хорошо сработает.Все так, никакой научной новизны в данном посте нет. У него цель скорее сделать обзор и показать как стоит применять "это дело" на практике.
Сильно зависит от метода, с которым получаем ускорение. Например, для квантизации почти всегда удается получить незначимую просадку в качестве, для дистилляции она обычно чуть более ощутимая.
Но в любом случае стоит помнить про Парето фронт, который проиллюстрирован в начале статьи. Методы ускорения дают нам больше возможностей выбора финальной модели для нашей задачи, то есть больше точек на этой кривой.
Финальное решение принимают все равно люди: смотрят на имеющиеся вычислительные бюджеты, на получившуюся Парето кривую и выбирают оптимум в зависимости от конкретного продукта/задачи.
Отличный вопрос! Наша команда тоже задавалась им.
Про это как раз написано в одном из параграфов внутри “Для интересующихся: как всё устроено внутри” и приведена статья. Авторы этой статьи обходятся без LSTM и MLP, но используют инициализацию эмбеддингами случайных токенов словаря. Такой подход также получает отличные результаты.
В наших задачах мы тестируем оба способа и выбираем лучший.