Int4 QAT против PTQ: почему Kimi выбрала квантование для K2 и как это повлияло на latency

Проблема: как снизить latency MoE-моделей без потери качества

Когда команда Kimi начала разработку модели K2, они столкнулись с классической дилеммой масштабирования: как сделать большую Mixture of Experts (MoE) модель достаточно быстрой для реального использования? MoE-архитектуры, где на каждый токен активируется только часть экспертов, теоретически экономят вычислительные ресурсы. Но на практике они создают новые проблемы:

• Память: Все эксперты должны быть загружены в память, даже если используются не все
• Latency: Динамическая маршрутизация между экспертами добавляет накладные расходы
• Кэширование: KV-cache для MoE становится сложнее организовать эффективно

Решение: квантование как фундаментальный подход

Kimi выбрала путь агрессивного квантования, но не простое Post-Training Quantization (PTQ), а Quantization-Aware Training (QAT). Разница принципиальна:

Для Kimi выбор был очевиден: они использовали Int4 QAT (4-битное квантование с обучением), что дало им преимущество в двух ключевых аспектах:

1. Снижение памяти в 4 раза: MoE-модели особенно прожорливы к памяти
2. Ускорение инференса: Современные GPU (особенно Blackwell) оптимизированы для низкоточных вычислений

Пошаговый план: как Kimi реализовала квантование для K2

1 Анализ чувствительности слоёв к квантованию

Первым шагом был анализ того, какие слои MoE-модели наиболее чувствительны к квантованию. В отличие от плотных моделей, в MoE есть два типа параметров:

# Пример анализа чувствительности
import torch
from transformers import AutoModelForCausalLM

model = AutoModelForCausalLM.from_pretrained("K2-pretrained")

# Анализ экспертов vs router
for name, param in model.named_parameters():
    if "expert" in name:
        # Эксперты менее чувствительны к квантованию
        sensitivity_score = calculate_sensitivity(param)
    elif "router" in name:
        # Router критически важен для качества
        sensitivity_score = calculate_sensitivity(param) * 2  # Повышенная важность

2 Реализация QAT тренировочного пайплайна

Kimi построила кастомный пайплайн QAT, который включал:

• Фазовое обучение: сначала полная точность, затем постепенное внедрение квантования
• Динамическое масштабирование: адаптивные scale factors для разных экспертов
• Специальные loss functions для стабилизации обучения с квантованием

3 Интеграция с системой инференса

После получения квантованной модели нужно было обеспечить эффективный инференс:

# Оптимизированный инференс для квантованной MoE
class QuantizedMoEInference:
    def __init__(self, quantized_model):
        self.model = quantized_model
        self.expert_cache = {}  # Кэш деквантованных экспертов
        
    def forward(self, x):
        # Динамическая деквантация только активных экспертов
        active_experts = self.model.router(x)
        
        for expert_idx in active_experts:
            if expert_idx not in self.expert_cache:
                # Деквантация на лету
                expert = dequantize_expert(self.model.experts[expert_idx])
                self.expert_cache[expert_idx] = expert
            
            # Использование кэшированного эксперта
            expert_output = self.expert_cache[expert_idx](x)

Как квантование повлияло на latency: цифры и анализ

Результаты, которые получила Kimi для K2:

Почему latency улучшилась так значительно? Причина не только в меньшем объёме данных:

1. Улучшенная cache locality: Квантованные веса лучше укладываются в кэш процессора
2. Векторизация операций: Int4 операции могут обрабатывать больше данных за такт
3. Снижение bandwidth pressure: Меньший объём данных = меньше времени на передачу

Нюансы и потенциальные ошибки при реализации

1. Ошибка: единая стратегия квантования для всей модели

Начинающие часто применяют одинаковое квантование ко всем слоям. Kimi избежала этой ошибки, использовав hybrid quantization:

# Правильный подход: гибридное квантование
quantization_config = {
    "attention": {"bits": 8},      # Высокая точность для attention
    "experts": {"bits": 4},        # Агрессивное квантование экспертов
    "router": {"bits": 6},         # Средняя точность для router
    "embedding": {"bits": 8}      # Высокая точность для эмбеддингов
}

2. Ошибка: игнорирование activation quantization

Квантование только весов (W4A16) даёт ускорение, но не максимальное. Kimi использовала полное квантование (W4A4) для критических путей:

3. Ошибка: отсутствие калибровочного датасета

PTQ требует качественного калибровочного датасета. Kimi использовала разнообразные данные:

• Диалоги из реальных пользовательских сессий
• Технические документы и код
• Многоязычные тексты

Сравнение с другими подходами

Kimi не единственная, кто экспериментирует с квантованием MoE. Например, в статье "Сравнение квантований Unsloth: Q3_K_M vs Q3_K_XL для GLM-4.7" рассматриваются post-training подходы, которые проще в реализации, но дают худшие результаты.

Также интересно сравнить с подходом "Q8 KV cache для vision-моделей", где фокус на экономии памяти через квантование кэша. Для MoE-моделей кэш ещё сложнее из-за динамической природы экспертов.

Практические рекомендации для инженеров

Когда выбирать QAT вместо PTQ?

1. У вас есть вычислительные ресурсы для дообучения
2. Требуется агрессивное квантование (ниже 8 бит)
3. Latency критически важна для продукта
4. Модель будет развёртываться на разнородном железе

Инструменты, которые стоит рассмотреть

Для реализации похожих решений:

# Современные фреймворки для квантования
pip install torch-quantizer  # Базовые инструменты от PyTorch
pip install brevitas         # Для research-oriented QAT
pip install onnxruntime      # Для deployment квантованных моделей

FAQ: ответы на частые вопросы

Вопрос: Почему Kimi не использовала более агрессивное квантование (2-3 бита)?

Ответ: Для MoE-архитектур слишком агрессивное квантование разрушает способность router'а правильно выбирать экспертов. Как показано в статье "GLM-4.5-Air на 2-3 битных квантованиях", на таких низких битностях качество падает катастрофически для сложных задач.

Вопрос: Можно ли применить этот подход к другим MoE-моделям?

Ответ: Да, но с осторожностью. Каждая MoE-архитектура имеет свои особенности. Например, в некоторых реализациях эксперты более чувствительны к квантованию. Всегда начинайте с анализа чувствительности.

Вопрос: Как измерять качество после квантования?

Ответ: Используйте специализированные бенчмарки. В статье "Какие бенчмарки смотреть для квантованных моделей" подробно разбираются метрики для разных типов задач.

Заключение: почему этот выбор важен для индустрии

Решение Kimi использовать Int4 QAT для K2 — это не просто техническая оптимизация. Это сигнал всей индустрии:

• MoE-модели могут быть эффективными при правильной оптимизации
• Квантование — не компромисс, а инструмент архитектурного дизайна
• Latency можно улучшать на порядки без потери качества

Как показывает практика "Новый прорыв в llama.cpp: поддержка MXFP4", аппаратные и программные оптимизации для квантованных моделей продолжают развиваться. Подход Kimi — это шаг в направлении, где модели проектируются с учётом их конечного развёртывания, а не только точности на бенчмарках.

Для тех, кто хочет глубже погрузиться в тему, рекомендую изучить "Как «мыслят» Llama-3 и Qwen-2.5" чтобы понять, как внутренние представления моделей реагируют на квантование.