Читаем техотчёт DeepSeek-V3 вместе

Зачем это нужно

Техотчёт DeepSeek-V3 (декабрь 2024) — пожалуй, самый влиятельный открытый документ о больших моделях за последние годы. Большая часть модулей ступени 5 (эффективное внимание, MoE, эффективное обучение) опирается на него: MLA, DeepSeekMoE, MTP, FP8, DualPipe. В этих модулях идеи разбираются по отдельности. Здесь вы прочитаете, как они складываются в одну систему и какие числа за ними стоят.

Второй повод — гигиена. Вокруг статьи сложилось много пересказов, и часть из них искажает оригинал. Самый известный пример — «DeepSeek обучили модель за 5.6 млн долларов». В статье написано другое, и вы увидите, что именно.

Урок устроен как совместное чтение. Откройте PDF с arXiv рядом с этой страницей. По каждому разделу будет сказано, что читать внимательно, что пролистать, какую формулу или число вынести в конспект. Затем идут вопросы на понимание; ответы спрятаны — сначала попробуйте ответить сами.

Когда читать этот урок

Урок рассчитан на тех, кто прошёл модули 5.2–5.4 (MLA, MoE, смешанная точность, распределённое обучение). Если вы ещё не там, сделайте сейчас только первый проход: он почти не требует формул и уже даёт картину. Ко второму проходу вернитесь после ступени 5, а к разделу о пост-трейнинге — после модуля 6.4.

Как читать: три прохода

Техотчёттехнический отчёт (техотчёт)EN technical reportТак лаборатории описывают свои модели. Это не рецензируемая статья, хотя часть отчётов позже публикуют в журналах (DeepSeek-R1 — в Nature). на 50+ страниц не читают подряд. Работает схема из трёх проходов — чтение в три проходачтение в три проходаEN three-pass approach (подробно — в уроке 9.2.2):

1. Обзор, 15–20 минут. Аннотация, введение, первые рисунки, таблица стоимости, заключение. Цель — понять, что авторы утверждают и чем это подкрепляют.
2. Механика, 1–1.5 часа. Разделы 2–3 с формулами. Цель — суметь пересказать каждый механизм и найти его в коде.
3. Выборочно. Абляцииабляционный эксперимент, абляцияEN ablation studyУбрать или заменить один компонент и сравнить с полной моделью, чтобы измерить вклад этого компонента. (§4.5, §5.4), приложения, всё, что вызвало сомнения.

Ведите журнал чтения из трёх колонок: утверждение → чем подкреплено → как я это проверил. Такой журнал отличает чтение от пролистывания. Заготовка, которую можно скопировать в свой конспект:

Утверждение статьи	Чем подкреплено	Как я это проверил
KV-кэш маленький	формулы §2.1.1	посчитал: 576 чисел на токен на слой
Обучение стабильно, без откатов	утверждение во введении	проверить нельзя, логов прогона нет — верю на слово
…	…	…

Последняя колонка часто остаётся пустой или с пометкой «верю на слово». Это нормально: важно видеть, какие утверждения вы проверили, а какие приняли на доверии.

flowchart TD
A["§1 Введение: 671B / 37B, 14.8T токенов, 2.788M GPU-часов"] --> B["§2 Архитектура"]
B --> B1["2.1.1 MLA"]
B --> B2["2.1.2 DeepSeekMoE и балансировка без aux loss"]
B --> B3["2.2 Multi-Token Prediction"]
A --> C["§3 Инфраструктура"]
C --> C1["3.2 DualPipe и all-to-all"]
C --> C2["3.3 Обучение в FP8"]
C --> C3["3.4–3.5 Инференс и пожелания к железу"]
A --> D["§4 Претрейн: данные, гиперпараметры, 128K, абляции"]
A --> E["§5 Пост-трейнинг: SFT, RL, дистилляция из R1"]

Карта техотчёта DeepSeek-V3

Проход 1. Введение: что утверждают авторы

Выпишите из введения пять утверждений. Именно их статья потом доказывает:

• смесь экспертовсмесь экспертов (MoE)EN mixture of experts (MoE)-модель на 671B параметров, из них 37B активныактивные параметрыEN activated (active) parametersСколько параметров MoE-модели реально участвует в обработке одного токена. «A22B» в названии Qwen3-235B-A22B — 22 млрд активных из 235 млрд. на каждый токен;
• архитектура взята из V2 (многоголовое латентное вниманиемногоголовое латентное внимание (MLA)EN multi-head latent attention (MLA)Предложено DeepSeek в DeepSeek-V2 (2024). и DeepSeekMoE), новое — балансировка без вспомогательного лосса и цель MTP;
• претрейн на 14.8T токенов, затем SFT и RL;
• всё обучение заняло 2.788 млн GPU-часовGPU-часыEN GPU hoursЧисло ускорителей × часы работы. 2048 GPU за сутки — 49 152 GPU-часа. H800;
• обучение шло стабильно: ни одного необратимого всплеска loss и ни одного отката к чекпоинту.

Последний пункт легко пропустить, а он, возможно, самый ценный. Во многих отчётах о больших прогонах есть истории про всплески loss и перезапуски. Здесь авторы заявляют, что 14.8T токенов прошли без единого отката.

Во введении есть и таблица стоимости — та самая, которую мы подробно разобрали в уроке 2 этого трека: претрейн 2 664K GPU-часов H800, расширение контекста 119K, пост-трейнинг 5K, итого 2 788K, или 5.576 млн долл. при условной аренде 2 долл./час. Найдите её в PDF и сверьте числа — это первая строка вашего журнала чтения.

Рядом авторы дают и темп: 180K GPU-часов на триллион токенов, то есть 3.7 дня на кластере из 2048 H800. Проверьте сами: $180\,000 / 2048 / 24 \approx 3.66$ дня, а весь претрейн — $2\,664\,000 / 2048 / 24 \approx 54$ дня, меньше двух месяцев.

Чего в 5.576 млн нет

Статья прямо говорит: это стоимость только официального обучения V3, без предварительных исследований и абляций, а 2 долл./час — условная аренда, а не стоимость владения кластером. Число честное, но отвечает на узкий вопрос: «сколько стоил последний прогон», а не «сколько стоило создать модель». Полный список того, что не вошло в сумму, и сравнение с Llama 3.1 405B — в уроке 2 этого трека.

Вопрос 1. Почему для стоимости обучения важнее «37B активных», чем «671B всего»?

FLOPs на токен определяются параметрами, через которые этот токен реально проходит: каждый токен активирует 8 из 256 маршрутизируемых экспертов плюс общий эксперт и внимание. Поэтому вычисления примерно как у плотной модели на 37B. А вот память определяется всеми 671B: веса всех экспертов нужно где-то хранить. Отсюда и требования к кластеру, и большой минимальный размер развёртывания на инференсе (§3.4).

Проход 2. §2 Архитектура

2.1.1 MLA: что попадает в кэш

Читайте внимательно все формулы раздела. Суть: ключи и значения не хранятся, хранится их сжатый «зародыш».

$$\begin{gathered} c_t^{KV} = W^{DKV} h_t, \qquad k_t^{C} = W^{UK} c_t^{KV}, \\ v_t^{C} = W^{UV} c_t^{KV}, \qquad k_t^{R} = \mathrm{RoPE}(W^{KR} h_t) \end{gathered}$$

Ключ головы $i$ — это склейка $[k_{t,i}^{C};\, k_t^{R}]$, где позиционная часть $k^R$ (развязанный RoPEразвязанный RoPEEN decoupled RoPEПриём MLA — позиционная информация идёт через отдельную небольшую часть запроса и ключа (64 измерения в DeepSeek-V2/V3), а сжатая «контентная» часть остаётся без RoPE, чтобы работало поглощение матриц.) общая для всех голов. В кэш попадают только $c_t^{KV}$ и $k_t^R$. Числа V3: $d_c = 512$, $d_h^R = 64$, 128 голов по $d_h = 128$, 61 слой.

	Чисел на токен на слой	Байт на токен (61 слой, BF16)	Одна последовательность 128K
MHA той же формы	$2 \cdot 128 \cdot 128 = 32\,768$	≈ 3.8 МБ	≈ 488 ГБ
MLA в V3	$512 + 64 = 576$	≈ 68.6 КБ	≈ 8.6 ГБ

Байты считаются так: числа на слой × 61 слой × 2 байта (BF16); для 128K умножаем ещё на $131\,072$ токена. Единицы здесь двоичные: 1 КБ = 1024 байта, 1 ГБ = $1024^3$ байт. Те же числа вы получили скриптом в уроке 2 этого трека — теперь видно, из каких формул статьи они берутся.

Разница в 57 раз, и именно она делает контекст 128K практичным. Запросы тоже сжимаются ($d_c' = 1536$), хотя их не кэшируют: это экономит память на активации при обучении. Механику и «поглощение» матриц вы разбирали в уроке 5.2.2.

Вопрос 2. Почему RoPE нельзя применить прямо к $k^C$, и нужна отдельная часть $k^R$?

На инференсе MLA «поглощает» $W^{UK}$ в матрицу запросов: $q^\top k^C = q^\top W^{UK} c^{KV}$, и произведение $q^\top W^{UK}$ можно посчитать один раз. Если бы на $k^C$ действовал RoPE, между $q$ и $W^{UK}$ встала бы матрица поворота, зависящая от позиции токена. Поглотить её заранее нельзя. Поэтому позиционную информацию несёт маленький отдельный ключ $k^R$ размером 64, общий для всех голов, — он почти не увеличивает кэш.

2.1.2 DeepSeekMoE и балансировка без вспомогательного лосса

Формулы раздела описывают слой MoE. Выход — это вход плюс общий эксперт плюс взвешенная сумма выбранных:

$$h_t' = u_t + \sum_{i=1}^{N_s} \mathrm{FFN}_i^{(s)}(u_t) + \sum_{i=1}^{N_r} g_{i,t}\, \mathrm{FFN}_i^{(r)}(u_t), \qquad s_{i,t} = \sigma(u_t^\top e_i)$$

В V3 один общий эксперт и 256 маршрутизируемых, активны 8, скрытый размер эксперта 2048. Первые три слоя — обычные плотные FFN. Обратите внимание на два отличия от V2: оценка сродства считается сигмоидой, а не softmax, и веса $g$ нормируются только среди выбранных экспертов.

Главная новинка — балансировка без вспомогательного лоссабалансировка без вспомогательного лоссаEN auxiliary-loss-free load balancingМетод DeepSeek (arXiv:2408.15664, использован в V3) — к оценкам роутера прибавляется смещение b_i, влияющее только на выбор экспертов; после каждого шага b_i сдвигается на ±γ по загрузке., то есть новое правило выбора экспертов. К оценке прибавляется смещение $b_i$, но только для выбора top-k:

$$g'_{i,t} = \begin{cases} s_{i,t}, & s_{i,t} + b_i \in \mathrm{TopK}(\{s_{j,t} + b_j\}, K_r) \\ 0, & \text{иначе} \end{cases}$$

После каждого шага смещение перегруженного эксперта уменьшают на $\gamma$, а недогруженного — увеличивают. Скорость $\gamma = 0.001$ держали первые 14.3T токенов, а на последних 500B выставили в 0. Дополнительно есть крошечный последовательностный лосс балансировки с весом $\alpha = 0.0001$: страховка от перекоса внутри одного текста. Ещё два инженерных правила: токен отправляется не более чем на 4 узла (это ограничивает трафик), и токены не выбрасываются ни при обучении, ни на инференсе.

Реализация — в уроке 5.3.2. В §4.5 есть абляции: без aux loss качество на большинстве бенчмарков выше. Там же показано, что эксперты сильнее специализируются по доменам.

Вопрос 3. Почему смещение $b_i$ влияет на выбор экспертов, но не на вес $g_{i,t}$?

Смещение — это «подталкивание» маршрутизации, а не часть функции, которую считает модель. Если бы $b_i$ входило в вес, балансировка напрямую искажала бы выход слоя и градиенты. Классический aux loss страдает именно от этого: слишком сильный $\alpha$ портит качество, слишком слабый не балансирует. В схеме V3 балансировка влияет только на то, куда пойдёт токен.

2.2 Multi-Token Prediction

Рисунок с MTP-модулями — ключевой в разделе. предсказание нескольких токеновпредсказание нескольких токенов (MTP)EN multi-token prediction (MTP) в V3 устроен последовательно: $k$-й модуль берёт представление с предыдущей глубины, склеивает его с эмбеддингом токена $t_{i+k}$, проецирует матрицей $M_k$ и пропускает через свой блок трансформера. Эмбеддинги и выходной слой общие с основной моделью. Так сохраняется причинная цепочка: прогноз на два шага вперёд опирается на знание следующего токена. В этом отличие от параллельных голов в работе Meta.

Итоговый лосс: $\mathcal{L} = \mathcal{L}_{\text{main}} + \frac{\lambda}{D}\sum_{k=1}^{D}\mathcal{L}^{k}_{\text{MTP}}$. В V3 глубина $D = 1$, а $\lambda = 0.3$ на первых 10T токенов и 0.1 на оставшихся 4.8T.

На инференсе модуль можно выбросить: основная модель работает без него. А можно оставить как черновик для спекулятивное декодированиеспекулятивное декодированиеEN speculative decoding. В §5.4.3 авторы сообщают, что второй токен принимается в 85–90% случаев, и скорость генерации растёт примерно в 1.8 раза. Механика — в уроке 5.4.2.

Вопрос 4. При приёме 85–90% теоретически выходит 1.85–1.9 токена за шаг. Почему измеренное ускорение — 1.8?

Шаг со спекуляцией дороже обычного: нужно прогнать сам MTP-модуль и проверить черновой токен основной моделью. Эти накладные расходы съедают часть выигрыша. Сравнивайте «токенов за шаг» с «токенов в секунду» — это разные метрики.

Проход 2. §3 Инфраструктура

Этот раздел отличает отчёт DeepSeek от большинства других: инженерии здесь столько же, сколько архитектуры.

3.1–3.2 Кластер, параллелизм и DualPipe

Кластер — 2048 GPU H800, по 8 на узел. Внутри узла GPU связаны NVLink, между узлами — InfiniBand. Авторы дают эффективные скорости: NVLink около 160 ГБ/с, IB около 50 ГБ/с, разница в 3.2 раза.

Схема параллелизма: 16-путевой pipeline-параллелизмконвейерный параллелизмEN pipeline parallelism, 64-путевой expert-параллелизмпараллелизм экспертовEN expert parallelism (EP)Разные эксперты MoE-слоя живут на разных GPU; токены пересылаются к своим экспертам и обратно через all-to-all-обмен. на 8 узлов и ZeRO-1ZeRO (оптимизатор без избыточности)EN ZeRO (Zero Redundancy Optimizer)Вместо того чтобы хранить на каждом GPU полную копию, состояние оптимизатора (ZeRO-1), градиенты (ZeRO-2) и веса (ZeRO-3) делят между GPU параллелизма по данным. для данных. Тензорного параллелизма нет. Оптимизации памяти позволили обойтись без него, и это сэкономило дорогие all-reduce внутри каждого слоя.

Главная проблема — межузловой all-to-all для экспертов. По оценке авторов, вычисления и коммуникация занимают примерно 1:1 по времени. Ответ — DualPipe. Каждый прямой и обратный кусок (chunk) режется на части: внимание, рассылка токенов экспертам (dispatch), MLP, сбор результатов (combine). Затем части пары «прямой + обратный» переставляются так, чтобы коммуникация одной шла одновременно с вычислениями другой. Микробатчи подаются с обоих концов конвейера. Отсюда название — DualPipeDualPipe (двунаправленный конвейер)EN DualPipeРасписание конвейера из DeepSeek-V3 — микробатчи подаются с обоих концов, а прямой и обратный проходы разных микробатчей перекрываются так, что коммуникация прячется за вычислениями..

Пузырь конвейера у DualPipe — $(PP/2 - 1)(F\&B + B - 3W)$ против $(PP-1)(F+B)$ у 1F1B (таблица 2 статьи). Здесь $PP$ — число стадий конвейера, $F$ — время прямого прохода одного куска, $B$ — полного обратного, $W$ — той части обратного прохода, что считает градиенты по весам, $F\&B$ — время перекрытой пары «прямой + обратный». Подставьте $PP = 16$, как в V3: множитель перед скобкой у DualPipe равен 7, у 1F1B — 15. Вдобавок скобка у DualPipe меньше: градиенты по весам не нужны следующей стадии, их можно отложить и досчитать в простоях — отсюда вычитаемое $3W$. Цена — две копии параметров на каждой стадии конвейера. Ядра коммуникации занимают всего 20 из 132 SM (потоковых мультипроцессоров) GPU, остальное идёт на вычисления.

Память экономят тремя приёмами: RMSNorm и повышающие проекции MLA пересчитываются при обратном проходе, а не хранятся; EMAэкспоненциальное скользящее среднее (EMA)EN exponential moving average (EMA)m ← βm + (1 − β)x. Помнит примерно последние 1/(1 − β) значений; при β = 0.9 — около 10. весов (сглаженная копия весов для оценки качества) лежит в памяти CPU; эмбеддинги и выходной слой MTP физически общие с основной моделью. Симулятор пузырей вы писали в уроке 5.4.3.

Вопрос 5. При чём тут H800 и почему DualPipe — «ответ на ограничения»?

H800 — экспортная версия H100 с урезанной межчиповой связью. Когда связь медленная, а MoE требует много all-to-all, обучение упирается в коммуникацию. Есть два пути: купить быструю сеть или спрятать коммуникацию за вычислениями. DeepSeek пошли вторым путём — отсюда DualPipe, собственные ядра all-to-all и ограничение «не более 4 узлов на токен». Подробнее о контексте — в уроке 2 этого трека.

3.3 Обучение в FP8

Самый плотный раздел статьи: как обучать в FP8FP8 (8-битное число с плавающей точкой)EN FP8 (8-bit floating point)Два варианта: E4M3 (точнее, максимум 448) и E5M2 (грубее, максимум 57 344). Требует масштабирования тензоров. DeepSeek-V3 обучалась в FP8 с поблочными масштабами. и не потерять точность. Держите рядом урок 5.4.1 и проследите четыре решения:

1. Что в FP8. Основные матричные умножения: прямой проход, градиент по входу, градиент по весам. Что не в FP8: эмбеддинги, выходной слой, роутер MoE, нормализации и внимание. Мастер-веса, градиенты весов и состояния оптимизатора тоже хранятся в повышенной точности.
2. Мелкозернистое масштабирование. Активации квантуются тайлами $1 \times 128$, веса — блоками $128 \times 128$, у каждой группы свой масштаб. Один выброс портит масштаб только своей группы из 128 чисел, а не всего тензора.
3. Точность накопления. Tensor Core H800 накапливают FP8-произведения примерно с 14 битами точности. На длинной сумме ($K = 4096$) ошибка доходит почти до 2%. Решение: каждые $N_C = 128$ элементов частичная сумма переносится в FP32 на CUDA-ядра.
4. Один формат E4M3 для всех тензоров. Раньше для градиентов брали E5M2 ради диапазона. Мелкие группы масштабирования позволили обойтись форматом с большей точностью.

Итог: относительная ошибка loss по сравнению с BF16 — меньше 0.25%. Об этом же — «Китайский угол» в уроке 1.3.2: вероятности и softmax остаются в высокой точности.

Вопрос 6. Почему мелкозернистое масштабирование позволило отказаться от E5M2?

E5M2 выбирали из-за широкого динамического диапазона: градиенты бывают очень разного масштаба. Когда масштаб подбирается отдельно для каждой группы из 128 чисел, внутри группы разброс значений намного меньше. Хватает диапазона E4M3, а лишний бит мантиссы даёт точность.

3.4–3.5 Инференс и пожелания к железу

Prefill и decode развёрнуты раздельно. Минимальный блок для prefill — 4 узла, 32 GPU, для decode — 40 узлов, 320 GPU. Популярные эксперты дублируются («избыточные эксперты»), чтобы выровнять нагрузку. V3 очень эффективна в масштабе дата-центра, но не рассчитана на скромное железо. Это авторы и признают в ограничениях.

§3.5 — редкий жанр: лаборатория пишет требования к производителям чипов. Вынести коммуникацию на отдельный сопроцессор, поднять точность накопления FP8 в Tensor Core, поддержать поблочное квантование аппаратно. Прочитайте этот раздел целиком: он показывает, где упирается современное обучение.

Вопрос 7. Вам нужно запустить «DeepSeek» на одном сервере. Что из §3.4 это значит на практике?

Посчитайте память. В FP8 один параметр занимает байт, так что одни веса — не меньше 671 ГБ. Это больше, чем у восьми GPU по 80 ГБ (640 ГБ), и в пять с лишним раз больше 128 ГБ вашей машины с четырьмя GPU. Сверху нужен ещё KV-кэш. Схема из статьи (decode на 320 GPU) рассчитана на огромный поток запросов, а не на одного пользователя. На практике локально берут дистиллированные или сильно квантованные модели (уроки 7.2.1–7.2.2) либо обращаются к API. Статья полезна, чтобы понять, почему провайдеры могут продавать такую модель дёшево: большие батчи и expert-параллелизм на сотнях GPU.

Проход 3. §4 Претрейн и §5 Пост-трейнинг

Претрейн

• Данные: 14.8T токенов. По сравнению с V2 больше математики и кода, шире многоязычное покрытие за пределами английского и китайского. Около 10% документов обучаются в режиме fill-in-the-middle — дописывание середины, полезное для кода.
• Токенизатор: byte-level BPE на 128K токенов. Авторы честно описывают побочный эффект: токены, склеивающие пунктуацию и перевод строки, давали смещение на границах токенов. Его лечили, случайно разбивая часть таких токенов при обучении.
• Гиперпараметры: AdamW с $\beta_1 = 0.9$, $\beta_2 = 0.95$, weight decay 0.1; длина последовательности 4K. Размер батча плавно растёт с 3072 до 15 360 последовательностей на первых 469B токенах. Сравните расписание learning rate в §4.2 с тем, что вы делали в уроке 4.6.3.
• Длинный контекст: два этапа YaRN по 1000 шагов: 4K → 32K → 128K.
• Абляции (§4.5): MTP и балансировку без aux loss проверяют на моделях меньшего размера. Сравнение с MTP честное: на инференсе модуль отбрасывают, и стоимость инференса у обеих моделей одинакова.

Пост-трейнинг

SFT — 1.5 млн примеров. Данные для рассуждений (математика, код, логика) сгенерировала внутренняя версия DeepSeek-R1. У её ответов была проблема: многословность, «передумывание», плохое форматирование. Поэтому авторы обучали промежуточные «экспертные» модели и отбирали ответы отбором с отклонениемотбор с отклонением (rejection sampling)EN rejection samplingСгенерировать много ответов и оставить только прошедшие проверку. В пост-трейнинге — способ собрать SFT-данные из RL-модели.. Остальные данные (тексты, ролевые диалоги, простые вопросы) сгенерировала DeepSeek-V2.5, а затем их проверили люди.

RL — GRPO (вы реализуете его в уроке 6.4.1) с двумя видами наград. Правиловые наградыправиловая наградаEN rule-based rewardНаграду считает программа (сверка ответа, запуск тестов, проверка формата), а не нейросеть. Её трудно «взломать». там, где ответ проверяем: в математике — ответ в заданном формате, в задачах LeetCode (сайт задач на программирование с автотестами) — прогон тестов. Для остальных задач обучают модель вознаграждения. В её обучающих данных к каждой оценке приложена цепочка рассуждений, которая к ней привела, — это снижает reward hacking.

§5.4.1 — дистилляция из R1. Абляция на DeepSeek-V2.5: точность на MATH-500 и LiveCodeBench растёт, но ответы становятся заметно длиннее. Этот компромисс потом проявится у многих reasoning-моделей. Переходите к следующему уроку, чтобы понять, откуда взялась сама R1.

Вопрос 8. Зачем дистиллировать рассуждения из R1 в V3, а не обучить V3 длинным RL самостоятельно?

R1 уже существует, и её трассы — дешёвый способ перенести паттерны рассуждения: самопроверку, разбор по шагам. Обычный SFT на таких данных стоит несравнимо меньше, чем большой прогон RL. Платой стала длина ответов, поэтому авторы и отбирали данные отбором с отклонением, балансируя точность и краткость.

Что из статьи есть в курсе

Идея	Раздел статьи	Урок курса	Практика урока
MLA, поглощение матриц	2.1.1	5.2.2	проекции и проверка эквивалентности
Роутинг top-k по экспертам	2.1.2	5.3.1	top-k роутер и загрузка экспертов
Балансировка смещениями	2.1.2	5.3.2	график загрузки экспертов
MTP	2.2	5.4.2	схема последовательных MTP-модулей
FP8 с поблочным масштабом	3.3	5.4.1	симуляция квантования
DualPipe, пузыри конвейера	3.2	5.4.3	симулятор расписания
YaRN, 4K → 128K	4.3	5.5.1	частоты RoPE
GRPO	5.2	6.4.1	групповые преимущества

Практика: перепроверяем числа статьи

Хорошая привычка — не верить ни одному числу, пока не пересчитаете его сами. Стоимость обучения и утилизация FLOPs моделиутилизация FLOPs модели (MFU)EN model FLOPs utilization (MFU)Доля пиковой производительности железа, которая уходит на полезные вычисления модели. Для больших распределённых обучений типичны 30–50 %. (≈ 35% пика BF16) вы уже прикинули в уроке 2 этого трека. Здесь — проверки, для которых нужно читать именно архитектурные разделы. Сколько параметров даёт описанная конфигурация? Сколько токенов за шаг даёт MTP? Сколько суток занимает триллион токенов?

Пересчитываем числа из техотчёта DeepSeek-V36 тестов

"""Читаем техотчёт DeepSeek-V3 с калькулятором (arXiv:2412.19437).

Конфигурация V3 из статьи (те же числа — в config.json на Hugging Face).
Нормы и смещения роутера не считаем: вместе это около миллиона параметров — на фоне 671B ничто.
"""

V3 = dict(
    vocab=129_280, d=7168, layers=61,
    heads=128, d_head=128, d_rope=64,      # MLA: 128 голов по 128 + общий RoPE-ключ на 64
    d_c=512, d_q=1536,                     # латент ключей/значений и латент запросов
    dense_layers=3, d_ff_dense=18_432,     # первые 3 слоя — обычные плотные FFN
    n_routed=256, n_shared=1, top_k=8, d_expert=2048,
)


def attention_params(cfg):
    """Параметры MLA в одном слое — сумма пяти групп матриц:

    W_DQ:          d × d_q                          (сжатие запроса)
    W_UQ:          d_q × heads·(d_head + d_rope)    (разжатие запроса: контентная часть + RoPE-часть)
    W_DKV и W_KR:  d × (d_c + d_rope)               (латент c_KV и общий RoPE-ключ k^R)
    W_UK и W_UV:   d_c × heads·d_head — каждая
    W_O:           heads·d_head × d
    """
    # TODO: ваш код
    ...


def expert_params(cfg):
    """Один эксперт — SwiGLU-FFN из трёх матриц d × d_expert."""
    # TODO: ваш код
    ...


def count_params(cfg):
    """Кортеж (всего, активных) параметров.

    * эмбеддинги и выходной слой: vocab × d каждый;
    * в каждом слое — внимание (attention_params);
    * dense_layers плотных FFN по 3 · d · d_ff_dense;
    * в остальных слоях MoE: роутер n_routed × d и эксперты —
      ВСЕ (n_routed + n_shared) для «всего» и top_k + n_shared для «активных».
    """
    # TODO: ваш код
    ...


def tokens_per_step(acceptance, depth=1):
    """Сколько токенов в среднем даёт шаг декодирования со спекуляцией через MTP.

    Основная модель всегда даёт 1 токен. MTP предлагает ещё `depth` черновых токенов по цепочке:
    k-й черновик засчитывается, только если приняты все предыдущие, каждый — с вероятностью `acceptance`.
    """
    # TODO: ваш код
    ...


def cluster_days(gpu_hours, n_gpus):
    """Сколько суток займёт работа объёмом gpu_hours на кластере из n_gpus GPU."""
    # TODO: ваш код
    ...


# Кнопка «Запустить» — сравните со статьёй: 671B всего, 37B активных, 3.7 дня на триллион токенов
print(count_params(V3))
print(tokens_per_step(0.85))
print(cluster_days(180_000, 2048))

ЗапуститьПроверитьПодсказкаСбросить

Если всё верно, получится 671.0B всего — ровно как в статье — и 37.6B активных. В статье названо 37B: небольшое расхождение зависит от того, что включать в подсчёт (например, входные эмбеддинги почти не требуют вычислений). Посмотрите, из чего складывается сумма:

Часть	Параметров	Доля
Эксперты: 58 MoE-слоёв × 257 экспертов	656.5B	97.8%
Внимание MLA: 61 слой	11.4B	1.7%
Эмбеддинги и выходной слой	1.9B	0.3%
Плотные FFN первых трёх слоёв и роутеры	1.3B	0.2%

Почти все веса — эксперты, но на каждый токен работают только 9 из 257 в слое: это ≈ 23B из 37.6B активных. Вот почему MoE-модель «тяжёлая» в памяти и «лёгкая» в вычислениях. На Hugging Face выложено 685B параметров: к основной модели добавлены 14B модуля MTP. В config.json те же числа лежат под ключами kv_lora_rank, q_lora_rank, qk_rope_head_dim, n_routed_experts, num_experts_per_tok, moe_intermediate_size и first_k_dense_replace — откройте файл и сверьте их с таблицей статьи.

Китайский угол: кто написал статью и что стало кодом

Кто это написал. DeepSeek — лаборатория из Ханчжоу, созданная в 2023 году хедж-фондом High-Flyer и его основателем Лян Вэньфэном. Автор статьи указан коллективно — DeepSeek-AI, полный список участников вынесен в приложение.

Как читали в Китае. После выхода V3 и R1 на Чжиху (Zhihu), в издании «Цзици чжи синь» (Synced) и на Bilibili появилось множество разборов по главам. Datawhale выпустила открытый разбор unlock-deepseek (CC BY-NC-SA 4.0) — хороший способ проверить своё понимание по китайскому источнику. Как такие тексты читать, см. урок 4 этого трека.

Что стало кодом. В феврале 2025 года DeepSeek провела Open Source Week и выложила инфраструктуру из §3: FlashMLA, DeepEP (all-to-all для экспертов), DeepGEMM (FP8-умножения), DualPipe, EPLB (балансировка избыточных экспертов) и файловую систему 3FS. Можно читать статью и сразу смотреть в код.

Продолжение §3.5. В V3.1 (2025) DeepSeek перешла на формат FP8 с масштабами UE8M0 и объяснила это расчётом на будущие китайские чипы. Пожелания к железу из статьи оказались не абстрактными. Подробнее — в уроке 2 этого трека.

Проверь себя

Проверь себя6 вопросов·

1 Что MLA в DeepSeek-V3 хранит в KV-кэше для каждого токена и слоя?

Полные K и V всех 128 головЛатентный вектор $c^{KV}$ и общий для всех голов RoPE-ключ $k^R$Только $c^{KV}$, а RoPE пересчитывается из позицииK и V одной общей головы, как в MQA

2 Сколько чисел на токен на один слой кэширует MLA в V3? ($d_c = 512$, $d_h^R = 64$)

3 Какие утверждения о «5.576 млн долл.» соответствуют тексту статьи?Можно выбрать несколько ответов

Это 2.788 млн GPU-часов H800 по условной цене 2 долл./часСюда входят исследования и абляции, предшествовавшие V3Это стоимость только официального обучения V3, включая расширение контекста и пост-трейнингЭто полная стоимость кластера из 2048 H800

4 Как в V3 используется смещение $b_i$ при балансировке экспертов?

Прибавляется к весу эксперта $g_{i,t}$ в выходе слояВлияет только на выбор top-k; перегруженным экспертам его уменьшают на $\gamma$ после шагаОбучается градиентным спуском вместе с остальными весамиЗаменяет общий эксперт

5 MTP глубины 1 принимает черновой токен с вероятностью 0.85. Сколько токенов в среднем даёт один шаг декодирования?

6 Что V3 НЕ переводит в FP8?

Основные матричные умножения в MLP экспертовВыходной слой, эмбеддинги, роутер MoE, нормализации и вниманиеГрадиенты по входу (Dgrad) в линейных слоях

Проверить ответы

Итоги

• Техотчёт V3 читают в три прохода: утверждения (введение, таблица стоимости) → механика (§2–3) → абляции и детали.
• Архитектура = MLA (кэш 576 чисел на слой) + DeepSeekMoE (1 общий + 8 из 256 экспертов) + балансировка смещениями + MTP.
• Половина ценности статьи — инженерия: DualPipe прячет all-to-all за вычислениями, FP8 с поблочным масштабом и накоплением в FP32 даёт ошибку меньше 0.25%.
• 5.576 млн долл. — стоимость финального прогона по условной аренде, а не стоимость создания модели. Статья сама об этом пишет.
• Числа статьи сходятся при пересчёте: 671.0B параметров из конфига (97.8% из них — эксперты), ≈ 1.85 токена за шаг с MTP, 3.7 суток на триллион токенов.

Дальше: читаем статью DeepSeek-R1 — откуда взялись рассуждения, которые V3 получила дистилляцией.