[Блог]
Недавно ребята из fireworks.ai, провайдера инференса LLMок, выпустили занятный блог про то, как следует оценивать качество сжатых 🗜 моделей.
Главные выводы и предписания следующие:
1️⃣ Trade-off между степенью сжатия и качеством определяется конечным приложением. Не существует универсального предписания для всех задач, что, мол, во столько раз можно сжать с умеренной просадкой в качестве, а дальше нельзя.
2️⃣ Использование KL-дивергенции для оценки степени расхождения квантизованной модели от исходной.
3️⃣ Не полагаться на точность на стандартных бенчмарках, а диверсифицировать протокол замеров
По первому пункту, вывод довольно логичен. Некоторые задачи
(function calling) менее чувствительны к ошибкам, чем другие (code generation), где один косячок, и весь дальнейший вывод сыпется как домино. Перплексия тоже плоха, так как ниже у моделей с низкой энтропией, но не всегда более точных. Ссылаясь на свежую работу от Microsoft Accuracy is not is all you need, авторы заявляют, что точность на бенчах - довольно шумная метрика оценки качества. Может быть так, что исходная модель где-то ошибалась, а квантизованная случайно стала предсказывать нужный токен. И прирост качества (скорее всего мизерный) обусловлен случайностью, а не тем, что модель “стала лучше”.
KL-дивергенция между сжатой и несжатой моделью предлагается в качестве альтернативы точности на наборе задач, как устойчивая к шумам. Если конкретно, предлагается генерировать несжатой моделью (forced generation), и смотреть, насколько различаются вероятности следующего токена предсказанные fp моделью и квантизованной. Кроме того, еще можно смотреть на token rejection rate - насколько отличается выбор top N токенов (
N=16 в дальнейшем) между двумя моделями.Ниже под квантизацией подразумевается переход от fp16 к fp8 (братве явно завезли баржу с H100). Рассматривают 4 уровня квантизации (по возрастанию степени сжатия):
1️⃣ Квантизуем только MLP без первого и последнего блока трансформера
2️⃣ Квантизуем все веса
3️⃣ Квантизуем вдобавок еще KV-cache
4️⃣ Квантизуем attention (K, V?) на prefill
Точность на MMLU просаживается немонотонно, уровень 2 даже оказывается “лучше” fp16 на тютельку. KL-дивергенция же монотонно растет со сжатием.
Далее авторы смотрят еще на ряд задачек из HELM-Lite - GSM8k, NaturalQuestions, WMT-2014 и другие, сравниваясь с другим известным провайдером - together.ai . Что fireworks, что together выдают качество близкое к fp16 при инференсе в fp8 (а то и лучше некоторых задачах), но fireworks якобы чуть лучше.
Однако, радоваться рано, говорят авторы из fireworks.ai. Нужен замер на чем-то как можно более похожем на людские предпочтения на том-же lmsys. Alpaca-Eval слишком маленький и не использует современные методы промптинга, потому предлагают смотреть на Arena-Hard-Auto от создателей lmsys. fp8 модели от fireworks и together будто бы чуть хуже fp16 на 🦙-3.1-405B, но не статзначимо.
Выводы
Вопрос оценки качества LLMок довольно нетривиален, ввиду того, что современные модели умеют решать широкий круг задач, и сложно объять всю полноту возможных задач и областей знания. Академические бенчмарки из нескольких задач и замеров перплексии на паре датасетов хороши для статей (здесь и ваш покорный слуга согрешил), но не всегда удовлетворительны для реальных приложений и запросов пользователя. Потому следует полагаться не на чужие обещания, а самому всю тщательно прощупывать 🧐.