ReAP квантование: разоблачение мифа о «почти без потерь» на реальных тестах

Когда бумажные бенчмарки встречаются с реальностью

В теории ReAP (Reconstruction-based Adaptive Pruning) - это круто. Статья от Google обещает «почти без потерь» квантование, особенно для маленьких моделей. Авторы показывают красивые графики, где их метод обходит конкурентов. Я поверил. Скачал скрипты, взял свежую Llama 3.1 8B и начал квантовать.

Через три часа у меня был файл GGUF размером 4.3GB вместо оригинальных 15GB. Отлично! Я запускаю тест на простой математической логике - и модель начинает галлюцинировать. Не просто ошибаться - она выдаёт абсолютно бредовые ответы, которые FP16 версия никогда бы не произнесла.

Мой тестовый стенд: не просто цифры, а работающая логика

Я не стал измерять accuracy на MMLU. Вместо этого собрал три типа тестов:

• Логические цепочки: задачи типа "Если A больше B, а B равно C, то..." с 3-4 шагами рассуждения
• Контекстное понимание: извлечение информации из технических текстов с последующими вопросами
• Кодогенерация: простые функции на Python с условиями и циклами

Для сравнения взял три варианта одной модели:

Результаты, которые не покажут в статьях

FP16 модель справилась с 28 из 30 задач. Ошибки были тонкие - небольшая неточность в расчётах, но логика сохранялась.

ReAP INT4 упала до 22 правильных ответов. И это не просто ошибки - модель начала путать базовые логические операторы. Вместо "и" говорила "или". Вместо "больше" говорила "меньше". Это не потеря точности - это поломка логики.

А q2_k_s? 26 правильных ответов. Все ошибки были в сложных цепочках рассуждений, но базовая логика работала.

Почему официальные бенчмарки врут (не специально)

Авторы ReAP тестировали на стандартных наборах данных. Эти наборы состоят из вопросов и готовых ответов. Модель просто выбирает вариант. Но в реальности мы просим модель рассуждать, генерировать код, анализировать текст.

Квантование особенно сильно бьёт по attention механизмам. В ReAP они используют реконструкцию весов, но эта реконструкция работает хорошо только на распределениях, похожих на тренировочные данные модели. А наши промпты часто далеки от этих распределений.

1 Как я тестировал (и как вам стоит тестировать)

Не доверяйте автоматическим бенчмаркам. Создайте свой небольшой датасет из реальных задач, которые решает ваша модель. Вот мой скрипт для проверки логических цепочек:

import json
from llama_cpp import Llama

def test_logical_chains(model_path):
    llm = Llama(
        model_path=model_path,
        n_ctx=2048,
        n_threads=8,
        verbose=False
    )
    
    test_cases = [
        {
            "prompt": "Если температура выше 25 градусов, и на небе нет облаков, то на улице жарко. Сейчас температура 30 градусов, облаков нет. Какая на улице погода?",
            "expected": "жарко"
        },
        {
            "prompt": "Все кошки - животные. Некоторые животные умеют плавать. Мой питомец - кошка. Умеет ли мой питомец плавать? Ответь да или нет.",
            "expected": "нет"
        }
    ]
    
    correct = 0
    for test in test_cases:
        output = llm(
            f"Ты - логический ассистент. Ответь максимально кратко. {test['prompt']}",
            max_tokens=50,
            temperature=0.1
        )
        
        answer = output['choices'][0]['text'].strip().lower()
        if test['expected'] in answer:
            correct += 1
        else:
            print(f"Ошибка: ожидалось '{test['expected']}', получено '{answer}'")
    
    return correct / len(test_cases)

2 Что делать, если уже заквантовали ReAP

Первое - не паниковать. Проверьте свою модель на конкретных задачах. Возможно, для вашего use case ReAP работает нормально. Если нет:

1. Вернитесь к оригинальной FP16 версии
2. Попробуйте q2_k_s или q3_k_m из llama.cpp
3. Протестируйте на реальных данных, а не на бенчмарках
4. Если качество критично - используйте более высокие битности (q4_k_m, q5_k_m)

Почему q2_k_s оказался лучше ReAP?

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

Особенно это заметно в задачах, которые требуют длинных chain-of-thought рассуждений. Там, где модель должна держать в памяти несколько фактов и связывать их, ReAP даёт сбой.

Мой текущий стек для квантования

После месяцев экспериментов я остановился на таком подходе:

• Для продакшена: q4_k_m - баланс размера и качества
• Для экспериментов: q3_k_m - достаточно маленько, достаточно точно
• Никогда: ReAP и другие «революционные» методы без долгого тестирования

Скрипт для быстрого сравнения нескольких методов:

#!/bin/bash
# compare_quantization.sh

MODEL="llama-3.1-8b"
TEST_PROMPTS="test_prompts.jsonl"

for method in q2_k_s q3_k_m q4_k_m q5_k_m; do
    echo "\n=== Testing $method ==="
    
    # Конвертируем модель
    python3 -m llama_cpp.converter \
        \/models/$MODEL \
        --outfile /models/${MODEL}-${method}.gguf \
        --quantize $method
    
    # Запускаем тесты
    python3 test_model.py \
        --model /models/${MODEL}-${method}.gguf \
        --prompts $TEST_PROMPTS \
        --output results_${method}.json
    
    # Чистим за собой
    rm /models/${MODEL}-${method}.gguf
done

echo "\n=== Results ==="
cat results_*.json | jq '.accuracy'

Что делать с этими знаниями?

Если вы читаете статьи про новые методы квантования - сразу ищите раздел «Limitations». Если его нет или там написано про стандартные датасеты - это красный флаг.

Создайте свой небольшой тестовый набор из 20-30 промптов, которые отражают реальное использование вашей модели. Тестируйте на нём ВСЕ новые методы. Не доверяйте цифрам из статей.

И помните: когда кто-то говорит «почти без потерь», спросите: «Потерь в чём?». Потерь в accuracy на MMLU? Или потерь в способности модели логически рассуждать?

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

Финальный вердикт

ReAP - интересный академический эксперимент. Но для практического использования в 2024 году он не готов. Метод слишком агрессивен, слишком оптимизирован под бумажные метрики и слишком плохо работает на реальных задачах.

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

Следующий шаг? Жду, когда появится метод, который объединит стабильность q2_k_s с эффективностью ReAP. Но пока что - проверяйте, тестируйте, не верьте на слово. Даже если слово исходит от Google.