KL-дивергенция (KLD) измеряет, насколько распределение вероятностей следующего токена у одной модели отличается от распределения другой на конкретном наборе текстов. Ноль означает совпадение выходов, рост числа показывает расхождение. Меньший KLD не гарантирует, что модель лучше решает задачи: в дистилляции KL-лосс отрабатывают на первом этапе, а следующие стадии SFT и RL способны ухудшить метрику при реальном росте качества. Единой метрики, которая закрыла бы вопрос, насколько известно автору разбора на r/LocalLLaMA, нет.
Практический вывод: KLD годится как первичный фильтр для отсева явно провальных квантов, а выбор модели делают на своих задачах. Ниже механика пайплайна дистилляции, кейс Bonsai от PrismML, риск benchmaxxing и способ собрать приватный бенчмарк, который переживёт не один релиз.
Что такое KLD и почему её часто воспринимают как главный показатель качества
Что именно измеряет KL-дивергенция
Считать KLD просто: обе модели прогоняют по одному и тому же тексту, на каждой позиции берут распределения вероятностей следующего токена и сравнивают их. Результат усредняют по токенам и получают одно число, обычно в натах. Ноль означает совпадение предсказаний, большое число означает, что студент предсказывает заметно иначе.
Метрика отвечает на вопрос «насколько модель разошлась с учителем», а не «насколько хорошо она решает задачи». Если учитель ошибается, студент с идеальным KLD повторит те же ошибки.
Смысл числа определяют два параметра: набор данных и базовая модель. Один и тот же квант на коде и на художественной прозе даст разные значения. Сравнивать KLD двух моделей с разными учителями и разными наборами данных бессмысленно: числа измеряют разные вещи.
Почему KLD удобно ставить в карточку модели
Одно число удобно. Его легко посчитать, вписать в таблицу релиза и сравнить с прошлой версией того же семейства. Читателю не нужно запускать модель, чтобы увидеть цифру. Отсюда привычка ранжировать кванты по KLD: меньше значит лучше.
Полноты картины здесь нет. Число не говорит, как модель ведёт себя в вашем чате, в вашем коде или в вашем агенте. Оно говорит только, насколько распределения разошлись с учителем на тех данных, которые выбрал автор расчёта.
В дистилляции обучение начинается с варианта KL-лосса: KL, reverse KL или JS loss между выходами студенческой и учительской моделей. Этот этап задаёт стартовую точку, и KLD хорошо описывает именно её.
Почему низкий KLD не равен лучшей модели: пайплайн дистилляции
KL-лосс как стартовая точка, а не финиш
Типичный пайплайн выглядит так: выбирают учителя и студента, обучают студента на KL-лоссе, затем доучивают на SFT и RL. KLD, который публикуют рядом с квантом, чаще всего относится к первому этапу или к сравнению кванта с оригиналом. Дальнейшие стадии в это число не входят, и это ключевая деталь.
Получается снимок раннего состояния. Модель уже похожа на учителя по распределениям, но ещё не проходила целенаправленное обучение решать задачи.
Как SFT и RL меняют картину
SFT учит модель на примерах хороших ответов, RL настраивает её на выполнение задач через награду. Обе стадии целятся в результат, а не в близость распределений к учителю. Автор разбора описывает это прямо: после KL-лосса идут этапы SFT и RL, которые улучшают то, что действительно важно, то есть способность модели решать разные задачи, и во время этих этапов KLD может стать хуже, хотя студент становится лучше (пост на r/LocalLLaMA).
Пример из той же логики: лаборатория дистиллирует модель, оптимизирует KL-лосс, затем добавляет SFT и RL. KLD в отчёте ухудшается, а модель начинает лучше справляться с задачами. Если смотреть только на цифру, улучшение выглядит как регресс.
Единого лосса, который решил бы проблему целиком, насколько известно автору, не существует. Иначе его применяли бы прямо в дистилляции вместо нескольких дополнительных стадий обучения. Это не отговорка, а ограничение текущих методов: близость распределений и польза в задачах не совпадают.
Кейс Bonsai от PrismML: привлекательный KLD и дополнительные стадии обучения
Автор разбора предполагает, что похожий процесс может стоять за моделями Bonsai от PrismML. В релизе показывают KLD, который впечатляет, а модель при этом проходит дополнительные стадии обучения, которые делают её лучше, но ухудшают KLD. Формулировки в источнике осторожные, «could be similar» и «probably», подтверждённых данных о внутреннем пайплайне PrismML там нет. Читать это стоит как гипотезу, а не как установленный факт.
Из той же гипотезы следует, почему Bonsai иногда рассматривают как нечто большее, чем квантованную версию оригинала. Дополнительные стадии меняют саму модель, а не только сжимают веса.
Что такое benchmaxxing и чем он опасен
Benchmaxxing происходит на дополнительных стадиях обучения, когда модель натаскивают не на отложенных задачах, а на задачах из популярных бенчмарков. Цифры растут, перенос на ваши задачи не гарантирован. В такой ситуации и KLD, и красивый скор в таблице описывают подготовку к экзамену, а не работу.
Механика подгонки под бенчмарки и её перекосы разобраны отдельно: частые обновления бенчмарков без полноценных оценок искажают картину сильнее, чем кажется. Тот же эффект работает и с метриками квантования: привлекательное число не говорит, что модель решает ваши задачи.
Практический риск простой. Вы выбираете квант по одной красивой цифре, ставите его в агент или в пайплайн обработки документов, а на ваших данных он спотыкается там, где менее «красивый» конкурент держится уверенно.
Где KLD всё-таки полезен: первичный фильтр с оговорками
Отказываться от KLD смысла нет. Метрика работает как первичный фильтр: помогает понять, какие квантованные модели стоит рассматривать, особенно если одна модель сильно выбивается по значению. Условие одно и обязательное: KLD считают на репрезентативных данных, иначе число мало говорит о реальной производительности модели (источник).
Почему данные для расчёта KLD важнее самого числа
Данные, сгенерированные самой базовой моделью, могут быть особенно полезны: оценка идёт на том распределении текстов, которое модель реально видит, а не на постороннем корпусе. Прогон по случайной выборке новостей на английском ничего не скажет о поведении модели на русских технических регламентах.
Проверка простая. Посмотрите, на чём считали KLD в карточке релиза. Если набор данных не описан или явно не похож на ваши тексты, цифра превращается в украшение таблицы.
У KLD нет универсальной шкалы. Одно и то же значение для разных пар моделей и разных наборов данных означает разное, поэтому фраза «KLD 0.05 лучше, чем 0.07» без контекста не аргумент.
Как использовать KLD как фильтр, а не как рейтинг
Смотрите на выбросы. Если один квант резко хуже соседей по KLD на одних и тех же данных и с одним учителем, его можно отбросить и не тратить время на прогоны. Сравнение внутри одного семейства и одного расчёта осмысленно, сравнение между разными релизами уже нет.
Разница в пределах шума не повод строить иерархию. Два соседних значения KLD с высокой вероятностью не дадут вам различимой разницы в чате или в коде. Решение всё равно придётся принимать по поведению модели.
Что использовать вместо KLD: приватный бенчмарк из повседневных задач
Ранжировать все квантованные модели мира не нужно. Задача другая: найти модель, которая работает для конкретного случая использования. Автор разбора формулирует так: сохраните часть своих повседневных задач, прогоните их на нескольких квантованных моделях и выберите ту, что лучше работает именно на этих задачах.
Как собрать набор задач под свой сценарий
- Возьмите реальные задачи, которые вы уже решали с моделью: письма, разбор логов, правки кода, извлечение полей из документов, ответы по своей базе знаний.
- Отберите повторяемые: те, что встречаются каждую неделю, а не один раз в квартал.
- Зафиксируйте входные данные и промпты, чтобы прогоны были воспроизводимыми: те же файлы, та же температура, тот же размер контекста, тот же квант.
- Для каждой задачи заранее опишите критерий успеха: тест проходит, поле извлечено верно, ответ содержит нужный факт.
- Прогоните набор на двух-трёх кандидатах с одинаковыми настройками и сравните результаты вслепую, не подглядывая, какая модель отвечала.
Начните с десятков задач, а не с сотен. Небольшой набор, который вы действительно проверяете, полезнее большого, который вы забросите после второго релиза.
Как оценивать результаты без огромных затрат
Оценивание может быть сложным, организация и создание приватного бенчмарка тоже непростая задача. Зато делается один раз, а дальше позволяет быстро тестировать новые квантованные модели.
- Для кода хватит своих тестов: прошли или нет.
- Для извлечения данных работает точное совпадение по полям и числам.
- Для текстовых задач используйте бинарный критерий и парное сравнение двух ответов вместо оценки по десятибалльной шкале.
- Ручная проверка небольшого набора остаётся самым честным вариантом, если задача требует понимания смысла.
Публичные бенчмарки можно держать как второй фильтр. Например, locallm.top собирает оценки локальных моделей с агентными тестами и живыми результатами, но решение по своей задаче всё равно остаётся за вашим набором.
Итог: как выбирать квантованную модель под свои задачи
- KLD описывает близость к учителю на конкретных данных, а не качество модели. Низкое значение само по себе ничего не выигрывает.
- Смотрите на KLD как на фильтр выбросов и только при понятном наборе данных, в идеале сгенерированном самой базовой моделью.
- Держите в голове SFT и RL после KL-лосса, а также риск benchmaxxing: метрика может ухудшиться при улучшении модели и улучшиться при подгонке под бенчмарки.
- Соберите набор своих повседневных задач с бинарными критериями и прогоняйте на нём кандидатов при одинаковых настройках.
- Учитывайте железо: квантование снижает требования к видеопамяти, поэтому выбор часто упирается в VRAM, а не в таблицу метрик.
Осторожность с публичными лидербордами оправдана: методики оценки AI-моделей пока незрелы, и сравнивать разные замеры между собой корректно не всегда получается. Начните с одного действия: выпишите пять своих задач, на которых вы точно отличите хороший ответ от плохого, и прогоните на трёх квантах той модели, что уже стоит у вас локально.