Кластер Kimi K3 Swarm за 6 часов проанализировал архитектуры внимания 23 открытых моделей с весами от 20B до 500B параметров. Результат - структурированный отчёт в PDF и MD на GitHub, который фиксирует три ключевых тренда: повсеместный отказ от классического Multi-Head Attention (MHA) в пользу Grouped Query Attention (GQA) и Multi-Query Attention (MQA), взрывной рост Multi-head Latent Attention (MLA) для сжатия KV-кэша и распространение гибридных схем full attention + sliding window. Если вы ML-инженер, который выбирает архитектуру под конкретные ограничения по памяти и скорости, этот разбор даст вам цифры, сравнения и готовые конфигурации.
Автоматизированный анализ подтвердил: индустрия больше не рассматривает MHA как жизнеспособный вариант для моделей крупнее 20B. Экономия KV-кэша стала главным драйвером архитектурных решений. В отчёте зафиксированы конкретные цифры - снижение потребления памяти в 5-10 раз при переходе на MLA, двукратное сжатие кэша для GQA относительно MHA. Ниже разбираем каждый тренд с примерами моделей и практическими выводами.
Ключевые тренды архитектур внимания в открытых LLM
Анализ 23 моделей выявил чёткую иерархию: GQA стал базовым стандартом, MLA - флагманским решением для длинных контекстов, sliding window - нишевым инструментом для специфических сценариев. Чистый MHA не обнаружен ни в одной модели крупнее 20B. Этот тренд устойчив с середины 2024 года и усиливается с каждым новым релизом.
От MHA к GQA и MQA: экономия памяти без потери качества
Классический Multi-Head Attention хранит отдельные ключи и значения для каждой головы. При 32 головах и контексте 128K токенов KV-кэш одной модели 70B занимает более 100 ГБ - это исключает инференс на потребительском оборудовании. GQA решает проблему радикально: несколько голов запросов делят одну пару ключ-значение. Llama 3 70B использует 8 групп для 64 голов запросов - сжатие KV-кэша в 8 раз относительно MHA. Mistral 7B комбинирует GQA со sliding window, получая дополнительную экономию на коротких окнах. MQA идёт дальше - все головы запросов разделяют один KV-слот. PaLM 2 продемонстрировала, что это снижает качество на задачах с тонкими смысловыми различиями, поэтому MQA остаётся нишевым выбором для сценариев с жёстким лимитом памяти.
Цифры из отчёта Kimi K3 Swarm: переход с MHA на GQA сокращает KV-кэш в 2-8 раз в зависимости от числа групп. Модели с GQA показывают менее 1% потерь на бенчмарках MMLU и HumanEval относительно MHA-аналогов. Это объясняет, почему все новые релизы - от Qwen 2.5 до DeepSeek-V2 - используют GQA или его производные.
Multi-head Latent Attention (MLA): новый стандарт сжатия KV-кэша
MLA, впервые представленный в DeepSeek-V2, сжимает ключи и значения в низкоразмерное латентное пространство перед кэшированием. Вместо хранения полных матриц K и V модель сохраняет сжатый латентный вектор и восстанавливает полные представления «на лету» через up-проекцию. Результат - сокращение KV-кэша в 5-10 раз относительно GQA. Для DeepSeek-V2 236B с контекстом 128K токенов это разница между 80 ГБ и 8 ГБ кэша.
Отчёт Kimi K3 Swarm зафиксировал MLA в нескольких моделях помимо DeepSeek-V2. Тренд набирает силу: сжатие кэша критично для обработки 128K+ токенов, где GQA уже не справляется. MLA добавляет вычислительные накладные расходы на up-проекцию (около 5-7% времени инференса), но выигрыш по памяти перевешивает. Для продакшен-сценариев с длинными документами, RAG поверх больших корпусов и мультиагентных систем MLA становится де-факто стандартом.
Практический вывод: если ваша задача требует контекста 32K токенов и более, MLA - единственный способ уложиться в разумный бюджет VRAM без квантизации до 4 бит. DeepSeek-V2 с MLA на 128K контексте потребляет столько же памяти, сколько Llama 3 70B с GQA на 32K.
Гибридные схемы: sliding window + full attention
Sliding window attention ограничивает каждую голову фиксированным окном (обычно 4096 токенов), чередуя такие слои с полным вниманием. Mistral 7B использует sliding window 4096 на всех слоях, Gemma 2 чередует локальные и глобальные слои. Это даёт линейный рост KV-кэша по длине последовательности вместо квадратичного.
Цена - потеря точности на задачах с дальними зависимостями. Отчёт Kimi K3 Swarm приводит тесты retrieval: при окне 4096 модель не извлекает факты, разделённые более чем 8192 токенами, если они не попали в один sliding-блок. Гибридные схемы с чередованием (один глобальный слой на каждые 4-6 локальных) смягчают проблему, но не решают полностью. Рекомендация из отчёта: используйте sliding window только если модель дообучена под эту схему, а ваша задача не требует точного извлечения фактов из длинных документов.
Сравнительный анализ 23 моделей: архитектуры внимания в цифрах
Автоматизированный анализ Kimi K3 Swarm собрал параметры внимания для всех 23 моделей: тип механизма, число голов, размерность ключей, объём KV-кэша на токен, поддерживаемую длину контекста. Данные структурированы в отчёте на GitHub. Здесь приводим сводку по ключевым моделям с акцентом на практические характеристики.
Модели 20B–70B: оптимальный баланс для реального использования
Сегмент 20B-70B - самый конкурентный. Здесь сосредоточены модели, которые можно запустить на 1-4 GPU A100 или H100 без экстремальной квантизации. Ключевые представители по данным отчёта:
- Llama 3 70B - GQA с 8 группами, контекст 8K (128K в расширенной версии). KV-кэш: ~2.6 ГБ на 8K. Минимальные требования: 2x A100 80GB.
- Qwen 2.5 72B - GQA, контекст 128K. KV-кэш: ~10 ГБ на 128K. Требует 4x A100 для полного контекста.
- DeepSeek-V2 Lite 16B - MLA, контекст 128K. KV-кэш: ~1.2 ГБ на 128K. Запускается на одной A100 80GB.
DeepSeek-V2 Lite - единственная модель в этом сегменте с MLA, что даёт ей радикальное преимущество по памяти на длинных контекстах. Для задач RAG с большими корпусами это оптимальный выбор среди моделей до 70B.
Модели 100B–500B: флагманы и их компромиссы
В сегменте 100B+ доминируют две архитектуры: GQA для моделей с контекстом до 32K и MLA для моделей с поддержкой 128K+. Falcon 180B использует MQA - редкий выбор для такого масштаба, объясняемый стремлением минимизировать KV-кэш до появления MLA. DeepSeek-V2 236B с MLA - флагман по соотношению качество/память: на 128K контексте потребляет ~8 ГБ KV-кэша против ~40 ГБ у гипотетического GQA-аналога.
Ключевой вывод отчёта: в сегменте 100B+ MHA отсутствует полностью. Даже модели, изначально спроектированные с MHA, переходят на GQA в последующих версиях. Тренд однонаправленный и необратимый.
Как Kimi K3 Swarm автоматизировал анализ: методология и результаты
Kimi K3 Swarm - кластер из нескольких инстансов Kimi K3, настроенных на параллельный сбор и структурирование данных. Каждый инстанс получал задачу: извлечь из конфигурационных файлов и технической документации модели параметры механизма внимания - тип, число голов, размерность, наличие sliding window, метод сжатия KV-кэша. Данные агрегировались, проверялись на непротиворечивость и формировались в единый отчёт.
Общее время работы - 6 часов. Результат: PDF и MD-файлы, доступные на GitHub. Swarm не просто собрал цифры, но и выявил паттерны - например, корреляцию между размером модели и отказом от MHA, распределение MLA по сегментам, типичные комбинации sliding window с GQA. Методология воспроизводима: любой желающий может запустить аналогичный анализ на своём наборе моделей, используя открытый код из репозитория.
Этот подход - пример автоматизации рутинного анализа, который вручную занял бы недели. Для ML-инженеров, отслеживающих десятки новых моделей, такие инструменты становятся необходимостью. Подробнее о возможностях Kimi K3 и её архитектуре читайте в анализе рыночной динамики и техническом разборе первых тестов.
Практические рекомендации: как применить выводы в своих проектах
Теоретические тренды превращаются в конкретные конфигурации. Вот три сценария и оптимальные архитектурные решения по данным отчёта.
Когда выбирать MLA: сценарии с жёсткими ограничениями по памяти
MLA оправдан, если длина контекста превышает 32K токенов, а бюджет VRAM ограничен. Сравнение для контекста 128K:
- GQA (8 групп, модель 70B): KV-кэш ~10 ГБ, требуется 4x A100 80GB.
- MLA (DeepSeek-V2 236B): KV-кэш ~8 ГБ, требуется 4x A100 80GB - но модель в 3 раза больше.
Конфигурация vLLM для DeepSeek-V2 с MLA:
python -m vllm.entrypoints.openai.api_server \
--model deepseek-ai/DeepSeek-V2 \
--max-model-len 131072 \
--gpu-memory-utilization 0.95 \
--enable-prefix-cachingMLA особенно выгоден в RAG-системах, где длинный контекст позволяет поместить больше релевантных чанков в промпт. Подробное сравнение моделей для RAG-сценариев - в тестировании Kimi K3, Fable и Sol.
Sliding window: плата за скорость и когда она приемлема
Sliding window даёт линейный рост KV-кэша, но ломает извлечение дальних зависимостей. Тесты retrieval из отчёта: при окне 4096 точность падает на 12-18% для фактов, разделённых более чем 4096 токенами. Гибридные схемы (чередование локальных и глобальных слоёв) снижают потери до 5-8%.
Рекомендация: используйте sliding window только для задач, где контекст естественно локален - диалоговые системы с короткой историей, генерация кода в пределах одного файла, суммаризация новостных заметок. Для retrieval поверх документов, юридического анализа, работы с научными статьями выбирайте модели с полным вниманием или MLA.
Ограничения исследования и приглашение к сотрудничеству
Анализ охватил 23 модели - это значительная, но не исчерпывающая выборка. Критерии включения: открытые веса, документация на английском или китайском, размер от 20B до 500B параметров. Модели с ограниченной документацией (например, некоторые китайские релизы без технических отчётов) и слишком новые (вышедшие менее чем за неделю до анализа) не вошли в отчёт.
Исследователь приглашает сообщество дополнить список. Если вы знаете модель, которая соответствует критериям, но не попала в анализ - создайте issue или pull request в GitHub-репозитории. Отчёт задуман как живой документ, который будет обновляться с каждым значимым релизом. Это практический инструмент для ML-инженеров, а не академическая публикация - его ценность прямо зависит от полноты и актуальности данных.
Полный отчёт с таблицами, цифрами и конфигурациями доступен на GitHub. Для понимания контекста рынка открытых моделей рекомендуем также разбор технического отчёта Kimi-K3 и бенчмарк ASCIITermDraw для оценки архитектурных способностей LLM.