Техотчёт DeepSeek-V2 (2024): MLA и экономика инференса

Что это за страница

Конспект своими словами: у текста статьи нет открытой лицензии. Формулы и числа сверены с отчётом (arXiv:2405.04434). Урок курса про сам механизм — 5.2.2 «MLA»; здесь разобран весь отчёт, включая инфраструктуру, длинный контекст и выравнивание.

V2 — поворотная точка: именно её дешёвый инференс в мае 2024 года запустил «ценовую войну» на китайском рынке API.

Коротко

• DeepSeek-V2 — MoE на 236 млрд параметров, из них 21 млрд активны на токен; контекст 128 тыс. токенов; 8,1 трлн токенов претрейна.
• Главная новинка — многоголовое латентное вниманиемногоголовое латентное внимание (MLA)EN multi-head latent attention (MLA)Предложено DeepSeek в DeepSeek-V2 (2024). (Multi-head Latent Attention): ключи и значения всех голов сжимаются в один латентный вектор размера 512, и в KV-кэше хранится только он (плюс 64 измерения для позиций).
• Чтобы сжатие ужилось с ротационные позиционные эмбеддингиротационные позиционные эмбеддинги (RoPE)EN rotary position embedding (RoPE)RoPE предложен в Китае (Су Цзяньлинь и соавторы, компания Zhuiyi). Сейчас используется почти во всех LLM., позиции вынесли в отдельные измерения (отделённый RoPE): обычная часть ключа сжата и «впитывается» в матрицы запросов, позиционная считается отдельно.
• Вторая половина архитектуры — DeepSeekMoE: 2 общих эксперта и 160 маршрутизируемых, активны 6; добавлены маршрутизация с ограничением по устройствам и три вспомогательных лосса баланса.
• Эффект: против плотной DeepSeek 67B — экономия обучения 42,5% (172,8 тыс. GPU-часов на триллион токенов против 300,6 тыс.), KV-кэш меньше на 93,3%, максимальная пропускная способность генерации выше в 5,76 раза (больше 50 тыс. токенов в секунду на узле из 8 H800).
• Выравнивание: SFT на 1,5 млн примеров, затем двухэтапный RL на GRPO — сначала рассуждения (код и математика), потом человеческие предпочтения с тремя моделями наград. Честно описан «налог на выравнивание».

Как читать вместе с курсом

Раздел отчёта	О чём	Куда в курсе
§2.1.1	напоминание про обычное многоголовое внимание	4.4, 5.2.1
§2.1.2–2.1.4	низкоранговое сжатие KV, отделённый RoPE, таблица размеров кэша	5.2.2 «MLA»
§2.2	DeepSeekMoE в V2, маршрутизация по устройствам, три лосса, отбрасывание токенов	5.3.2
§3.1	данные (8,1 трлн), гиперпараметры, инфраструктура, расширение до 128K через YaRN	5.1.2, 5.5.1
§3.2.3	стоимость обучения и пропускная способность инференса	7.1.1
§4	SFT, двухэтапный RL на GRPO, обсуждение	6.4.1

MLA: зачем вообще сжимать KV-кэш

При генерации модель хранит ключи и значения всех прошлых токенов — KV-кэшKV-кэшEN KV cache. Его размер прямо определяет, сколько запросов влезет в память GPU одновременно, то есть себестоимость сервиса. Для обычного многоголового внимания на токен нужно $2 n_h d_h l$ чисел ($n_h$ голов, $d_h$ на голову, $l$ слоёв).

Для V2 ($n_h = 128$, $d_h = 128$, $l = 60$) это $2 \cdot 128 \cdot 128 \cdot 60 = 1{,}97$ млн чисел на токен. При bf16 — почти 4 МБ на один токен контекста. На 128 тыс. токенов — сотни гигабайт. Так сервис не построишь.

внимание с группами запросоввнимание с группами запросов (GQA)EN grouped-query attention (GQA)Головы запросов делятся на G групп, у каждой группы своя пара K/V. G = H — это MHA, G = 1 — MQA. Стандарт Llama 3 и Qwen (Ainslie и др., 2023). уменьшает это в $n_h / n_g$ раз (несколько голов делят один набор ключей), MQA — в $n_h$ раз, но за качество приходится платить. MLA решает задачу иначе.

Идея 1: низкоранговое совместное сжатие

Вместо того чтобы хранить ключи и значения, храним один сжатый вектор, из которого они восстанавливаются:

$$c^{KV}_t = W^{DKV} h_t, \qquad k^{C}_t = W^{UK} c^{KV}_t, \qquad v^{C}_t = W^{UV} c^{KV}_t,$$

где $c^{KV}_t \in \mathbb{R}^{d_c}$, а $d_c \ll d_h n_h$. «DKV» — проекция вниз (down), «UK», «UV» — проекции вверх (up) для ключей и значений. В кэше лежит только $c^{KV}_t$: $d_c\, l$ чисел на токен.

Ключевой трюк не в самом сжатии, а в поглощении матриц (matrix absorption). Запишем оценку внимания: $q^{T} k^{C} = (W^{UQ}c^{Q})^{T}(W^{UK}c^{KV}) = (c^{Q})^{T}\big((W^{UQ})^{T}W^{UK}\big)c^{KV}$. Произведение $(W^{UQ})^{T}W^{UK}$ не зависит от токена, его можно посчитать один раз. То есть $W^{UK}$ «впитывается» в матрицу запросов, а $W^{UV}$ — в выходную матрицу $W^{O}$, и восстанавливать ключи и значения на инференсе вообще не нужно.

Запросы тоже сжимают ($c^{Q}_t = W^{DQ}h_t$, размерность $d'_c$), хотя на KV-кэш это не влияет: это экономит память под активации во время обучения.

Идея 2: отделённый RoPE

Проблема: ротационные позиционные эмбеддингиротационные позиционные эмбеддинги (RoPE)EN rotary position embedding (RoPE)RoPE предложен в Китае (Су Цзяньлинь и соавторы, компания Zhuiyi). Сейчас используется почти во всех LLM. поворачивает запросы и ключи на угол, зависящий от позиции. Если применить RoPE к сжатым ключам $k^{C}_t$, то между $W^{Q}$ и $W^{UK}$ оказывается матрица поворота, зависящая от позиции текущего токена. Матрицы не коммутируют — поглощение ломается, и ключи всех прошлых токенов приходится пересчитывать на каждом шаге. Вся экономия пропадает.

Решение: разделить обязанности. Добавляются отдельные «позиционные» части размером $d^{R}_h$ на голову:

$$q^{R}_t = \mathrm{RoPE}(W^{QR} c^{Q}_t), \qquad k^{R}_t = \mathrm{RoPE}(W^{KR} h_t),$$ $$q_{t,i} = [\,q^{C}_{t,i};\, q^{R}_{t,i}\,], \qquad k_{t,i} = [\,k^{C}_{t,i};\, k^{R}_t\,].$$

Запрос и ключ — это склейка двух частей: «содержательной» (сжатой, без позиции) и «позиционной» (с RoPE). Внимание нормируется на $\sqrt{d_h + d^{R}_h}$. Позиционный ключ $k^{R}_t$ один на все головы (как в MQA), поэтому в кэш добавляется всего $d^{R}_h$ чисел.

Итого кэш MLA: $(d_c + d^{R}_h)\, l$ чисел на токен.

flowchart LR
H["h_t (скрытое состояние)"] --> D1["W_DKV: сжатие"] --> C["c_KV (512)"]
H --> D2["W_KR + RoPE"] --> KR["k_R (64), общий для всех голов"]
C -. "хранится в кэше" .-> KV[("KV-кэш: 512 + 64 = 576 чисел на токен на слой")]
KR -. "хранится в кэше" .-> KV
C --> U1["W_UK, W_UV: поглощаются в W_Q и W_O на инференсе"]

Что реально попадает в KV-кэш у MLA (схема по §2.1 отчёта)

Сколько получилось

Конфигурация V2: $d_c = 512$ (это $4 d_h$), $d^{R}_h = 64$ (это $d_h/2$), $l = 60$. На токен: $(512 + 64)\cdot 60 = 34\,560$ чисел.

Механизм	Чисел на токен	Для V2	Качество (оценка авторов)
MHA	$2 n_h d_h l$	1 966 080	сильное
GQA ($n_g$ групп)	$2 n_g d_h l$	зависит от $n_g$	среднее
MQA	$2 d_h l$	15 360	слабое
MLA	$(d_c + d^{R}_h)\, l$	34 560	сильнее, чем MHA

34 560 ÷ (2 · 128 · 60) = 2,25: кэш MLA равен кэшу GQA всего с 2,25 группами — и при этом, по замерам авторов, качество выше, чем у полного MHA.

Откуда берутся 93,3%

В аннотации сравнивают с предыдущей моделью компании, плотной DeepSeek 67B (GQA, 8 групп, $d_h = 128$, 95 слоёв): $2\cdot8\cdot128\cdot95 = 194\,560$ чисел на токен, в bf16 это 380 КиБ. У развёрнутой V2 кэш дополнительно квантуют до ~6 бит на элемент: $34\,560 \cdot 6 / 8 = 25\,920$ байт ≈ 25,3 КиБ. Отношение $25{,}3 / 380 = 6{,}7\%$, то есть сокращение на 93,3% — ровно цифра из отчёта. Пересчитайте сами, это полезное упражнение на понимание того, что «во сколько раз меньше» зависит ещё и от точности хранения.

MoE в V2: три лосса и ограничение по устройствам

Архитектура экспертов — та же, что в DeepSeekMoE, но крупнее: все слои, кроме первого, содержат 2 общих эксперта и 160 маршрутизируемых с промежуточной размерностью 1536; на токен включаются 6 маршрутизируемых.

Маршрутизация с ограничением по устройствам. При мелких экспертах активных экспертов много, и токен может «разъехаться» по всем узлам кластера — связь станет дороже вычислений. Поэтому сначала выбирают $M$ устройств с самыми подходящими экспертами, и только внутри них берут top-K. На практике при $M \ge 3$ качество почти не отличается от неограниченного выбора; в V2 стоит $M = 3$ при $D = 8$ устройствах.

Три вспомогательных лосса баланса:

1. На уровне экспертов ($\alpha_1 = 0{,}003$) — против коллапса маршрутизации.
2. На уровне устройств ($\alpha_2 = 0{,}05$) — чтобы вычисления были равномерны по GPU.
3. На уровне связи ($\alpha_3 = 0{,}02$) — новый по сравнению со статьёй DeepSeekMoE. Ограничение по устройствам гарантирует, что каждое устройство отправляет ограниченный объём, но ничто не мешает одному устройству получать намного больше токенов, чем другие. Этот лосс выравнивает приём.

Плюс отбрасывание токенов (token dropping) во время обучения для ускорения: устройство с переполненной очередью выбрасывает токены с наименьшими оценками сродства. На оценке качества токены не отбрасывают.

Обучение: данные, гиперпараметры, инфраструктура

• Данные. 8,1 трлн токенов, тот же токенизатор BBPE со словарём 100K, что и у DeepSeek 67B. Китайских токенов примерно на 12% больше, чем английских. Улучшены фильтры качества, восстановлена часть ошибочно удалённых данных, отфильтрован спорный контент.
• Модель. 60 слоёв, $d_\text{model} = 5120$, 128 голов по 128. Дополнительные слои RMSNorm после сжатых латентных векторов и масштабирующие множители в «узких местах» — иначе обучение нестабильно.
• Обучение. AdamW, максимальный learning rate 2,4e-4, ступеньки ×0,316 после ~60% и ~90% токенов. Батч растёт с 2304 до 9216 последовательностей за первые 225 млрд токенов, длина 4K.
• Параллелизм. 16-путевой конвейер (zero-bubble), 8-путевой параллелизм экспертов, ZeRO-1 по данным. Тензорного параллелизма нет — активных параметров мало, часть операторов перевычисляется, и без TP меньше связи. Вычисление общих экспертов накладывается на all-to-all маршрутизируемых. MLA оптимизирована на основе улучшенной версии FlashAttention-2. Кластер — узлы по 8 H800 с NVLink и NVSwitch внутри узла, InfiniBand между.
• Длинный контекст. После основного претрейна контекст расширяют с 4K до 128K через YaRNYaRNEN YaRN (Yet another RoPE extensioN)NTK-by-parts (каждая пара частот масштабируется по числу оборотов за обучающую длину) плюс температура внимания 0.1·ln s + 1. Используется в DeepSeek-V3 и Qwen., применяя его только к отделённому ключу $k^{R}_t$ — ведь только он несёт позиции. Параметры: $s = 40$, $\alpha = 1$, $\beta = 32$, целевая длина 160K; коэффициент длины подправлен как $\sqrt{t} = 0{,}0707 \ln s + 1$ для минимизации перплексии. Дообучение — 1000 шагов при длине 32K, батч 576, а работает модель и на 128K (проверено тестом «иголка в стоге сена»).

Экономика: за что всё это

Обучение. На триллион токенов: DeepSeek 67B — 300,6 тыс. GPU-часов, DeepSeek-V2 — 172,8 тыс. Экономия $1 - 172{,}8/300{,}6 = 42{,}5\%$, при том что V2 сильнее по качеству.

Инференс. Веса переводят в FP8, KV-кэш квантуют примерно до 6 бит на элемент. На одном узле из 8 H800 получается больше 50 тыс. токенов генерации в секунду (в 5,76 раза больше, чем у 67B) и больше 100 тыс. токенов в секунду на обработку промптов. Распределение длин промптов и ответов брали из реального сервиса 67B.

Чем это обернулось для рынка

Сервис на такой экономике DeepSeek запустила по цене около 1 юаня за миллион входных токенов — в разы ниже тогдашнего рынка. За несколько недель цены снизили ByteDance, Alibaba, Baidu и другие. Подробности — в «китайском углу» урока 8.1.1.

Выравнивание: SFT и двухэтапный RL

SFT. 1,5 млн примеров (1,2 млн «полезность», 0,3 млн «безопасность»), 2 эпохи, learning rate 5e-6. По сравнению с версией для DeepSeek 67B данные почищены: меньше галлюцинаций, лучше письмо.

RL на GRPO. Алгоритм взят из DeepSeekMath ради экономии: нет критика размером с политику, базовая линия — среднее по группе. Обучение разбито на два этапа, потому что на рассуждениях модель продолжает расти дольше, чем на предпочтениях:

1. Выравнивание рассуждений. Отдельная модель наград для кода и математики. Предпочтения для кода получают из ответов компилятора, для математики — сверкой с правильным ответом.
2. Выравнивание под предпочтения человека. Награда — взвешенная сумма трёх: $r_i = c_1 R_\text{helpful}(o_i) + c_2 R_\text{safety}(o_i) + c_3 R_\text{rule}(o_i)$ — полезность, безопасность и правила.

Инженерия RL (её редко описывают, а она решает): гибридный движок с разными стратегиями параллелизма для обучения и для генерации, vLLM с большими батчами как бэкенд генерации, продуманное расписание выгрузки моделей на CPU и загрузки обратно.

Три честных наблюдения из обсуждения

• Сколько нужно SFT-данных. Есть популярное мнение, что хватает менее 10 тыс. примеров (LIMA и подобные работы). В экспериментах DeepSeek на бенчмарке следования инструкциям IFEval при менее чем 10 тыс. примеров качество заметно падает. Чем больше модель, тем меньше данных нужно, но до нуля это не доходит.
• Налог на выравнивание. После выравнивания под предпочтения открытая генерация становится лучше (и по оценке людей, и по оценке ИИ-судьи), но часть стандартных бенчмарков (например, BBH) проседает. Авторы долго подбирали данные и стратегии, чтобы компромисс был терпимым.
• Онлайн против офлайна. Онлайновый RL (учимся на свежих ответах текущей модели) заметно лучше офлайнового — тот же вывод, что и в DeepSeekMath.

Что сделать руками

1. Пересчитайте KV-кэш. Для MHA, GQA с 8 группами, MQA и MLA при параметрах V2 посчитайте числа на токен и размер кэша на 128 тыс. токенов в bf16 и в 6 битах. Убедитесь, что получается 93,3%.
2. Проверьте поглощение матриц. На NumPy возьмите случайные $W^{UQ}$, $W^{UK}$ и убедитесь, что $(W^{UQ}c^{Q})^{T}(W^{UK}c^{KV})$ совпадает с $(c^{Q})^{T}\big((W^{UQ})^{T}W^{UK}\big)c^{KV}$ с точностью до ошибок округления. Это ядро практики урока 5.2.2.
3. Сломайте RoPE. Примените RoPE к сжатым ключам и покажите, что поглощение больше не работает: матрица поворота зависит от разности позиций и не выносится за скобки.
4. Прикиньте свой сервис. Сколько одновременных запросов по 8 тыс. токенов поместится в 32 ГБ вашей RTX 4080, если кэш как у MHA, как у GQA-8 и как у MLA (считайте на модель с 32 слоями и 32 головами по 128)?

Словарик

EN	RU
Multi-head Latent Attention (MLA)	многоголовое латентное внимание
low-rank joint compression	низкоранговое совместное сжатие
latent vector	латентный (сжатый) вектор
down-/up-projection	проекция вниз / вверх
matrix absorption	поглощение матриц
decoupled RoPE	отделённый RoPE
device-limited routing	маршрутизация с ограничением по устройствам
communication balance loss	лосс баланса связи
token-dropping strategy	отбрасывание токенов
zero-bubble pipeline parallelism	конвейер «без пузыря»
needle in a haystack (NIAH)	«иголка в стоге сена» (тест длинного контекста)
alignment tax	налог на выравнивание
generation throughput	пропускная способность генерации