Open Source Week, день 6: система инференса DeepSeek-V3/R1

От переводчика: что нужно знать перед чтением

Это последний, шестой день «недели открытого кода» DeepSeek (24–28 февраля 2025 года). Пять дней команда выкладывала по библиотеке, а на шестой рассказала, как из них собран настоящий сервис. Текст короткий и плотный, поэтому вспомните заранее:

• смесь экспертовсмесь экспертов (MoE)EN mixture of experts (MoE): в каждом слое DeepSeek-V3 256 маршрутизируемых экспертов и один общий, на токен включаются 8 маршрутизируемых (урок 5.3.2);
• prefillprefill (предзаполнение)EN prefillПервая фаза генерации: весь промпт проходит через модель одним параллельным проходом, заполняется KV-кэш и получается первый токен. Упирается в вычисления. и декодированиедекодирование (фаза decode)EN decode phaseВторая фаза: один токен за один проход модели. На каждый токен заново читаются все (активные) веса и KV-кэш, поэтому фаза упирается в пропускную способность памяти.: обработка запроса целиком и генерация по одному токену; это разные по характеру нагрузки (урок 7.1.1);
• PD-дезагрегацияPD-дезагрегация (раздельные prefill и decode)EN prefill-decode disaggregationPrefill и decode выполняются на разных группах GPU, а KV-кэш передаётся между ними по сети. Так фазы не мешают друг другу. Mooncake (Kimi), DistServe, инференс DeepSeek-V3., параллелизм экспертовпараллелизм экспертовEN expert parallelism (EP)Разные эксперты MoE-слоя живут на разных GPU; токены пересылаются к своим экспертам и обратно через all-to-all-обмен. и параллелизм по даннымпараллелизм по даннымEN data parallelism (уроки 7.1.2 и 5.4.3).

Рисунки оригинала здесь пересказаны словами и таблицами. Сами картинки лежат в папке 202502OpenSourceWeek/figures репозитория open-infra-index. Комментарии переводчика вынесены в такие же рамки, всё остальное — перевод.

Принципы проектирования системы

Цели, ради которых оптимизируется инференс DeepSeek-V3/R1, — большая пропускная способность и малая задержка.

Чтобы достичь обеих целей, мы используем параллелизм экспертов (Expert Parallelism, EP) между узлами.

• Во-первых, EP сильно увеличивает размер батча. Матричные вычисления на GPU становятся эффективнее, пропускная способность растёт.
• Во-вторых, EP распределяет экспертов по GPU, и каждая GPU обрабатывает лишь небольшую часть экспертов. Ей нужно меньше читать из памяти, поэтому задержка падает.

Однако EP усложняет систему, в основном в двух отношениях:

1. EP вводит обмен данными между узлами. Чтобы пропускная способность была высокой, вычисления нужно организовать так, чтобы обмен данными накладывался на вычисления.
2. EP охватывает несколько узлов, а значит, неизбежно требует и параллелизма по данным (Data Parallelism, DP), и балансировки нагрузки между разными экземплярами DP.

В этой статье рассказано, как мы решаем эти задачи:

• используем EP, чтобы увеличить размер батча;
• прячем задержку обмена данными за вычислениями;
• балансируем нагрузку.

Масштабный параллелизм экспертов между узлами

В DeepSeek-V3/R1 очень много экспертов: в каждом слое из 256 экспертов активны только 8. Из-за такой высокой разреженности модели нужен огромный общий размер батча — только тогда на каждого эксперта приходится достаточно токенов, и можно получить высокую пропускную способность при малой задержке. Поэтому масштабный параллелизм экспертов между узлами необходим.

Поскольку мы используем архитектуру с раздельными prefill и decode, на этих фазах применяются разные степени параллелизма:

• Фаза prefill [маршрутизируемые эксперты — EP32, MLA и общий эксперт — DP32]. Каждый блок развёртывания занимает 4 узла и содержит 32 избыточных маршрутизируемых эксперта; каждая GPU обслуживает 9 маршрутизируемых экспертов и 1 общий.
• Фаза decode [маршрутизируемые эксперты — EP144, MLA и общий эксперт — DP144]. Каждый блок развёртывания занимает 18 узлов и содержит 32 избыточных маршрутизируемых эксперта; каждая GPU обслуживает 2 маршрутизируемых эксперта и 1 общий.

Комментарий переводчика: проверим арифметику

В узле 8 GPU H800. Prefill: 4 узла × 8 = 32 GPU, 32 × 9 = 288 мест под экспертов = 256 экспертов + 32 копии самых нагруженных. Decode: 18 × 8 = 144 GPU, 144 × 2 = 288 = 256 + 32. Число избыточных копий одинаковое, а GPU в блоке decode в 4,5 раза больше: на каждой меньше экспертов и меньше весов, которые надо читать на каждом шаге генерации. Это и есть «меньше обращений к памяти — меньше задержка» из списка выше. Как выбирают, каких экспертов копировать, описано на странице про EPLB.

Наложение вычислений и обмена данными

Масштабный EP между узлами создаёт большие накладные расходы на связь. Чтобы их уменьшить, мы применяем стратегию наложения двух микробатчей (dual-batch overlap): батч запросов делится на два микробатча, и стоимость связи прячется, а общая пропускная способность растёт.

На фазе prefill два микробатча выполняются поочерёдно, и обмен данными одного микробатча прячется за вычислениями другого.

Комментарий переводчика: что на рисунке «наложение на фазе prefill»

На рисунке две дорожки. Верхняя — вычисления, под них отдано 108 из 132 мультипроцессоров (SM) H800. Нижняя — связь, под неё 24 SM. Обозначения: ATTN — MLA и гейт маршрутизации MoE, SHARED — общие эксперты, MLP — маршрутизируемые эксперты, DISPATCH — рассылка токенов экспертам, COMBINE — сбор ответов экспертов. Последовательность по времени (микробатчи 0 и 1):

Шаг	Вычисления (108 SM)	Связь (24 SM)
1	ATTN микробатча 1, затем SHARED микробатча 0	COMBINE микробатча 0
2	ATTN микробатча 0	DISPATCH микробатча 1
3	MLP микробатча 1	DISPATCH микробатча 0
4	MLP микробатча 0, затем SHARED микробатча 1	COMBINE микробатча 1

Пока один микробатч считает, второй едет по сети, и обе дорожки всё время заняты.

На фазе decode разные стадии выполняются неравное время. Поэтому мы делим слой внимания на два шага и используем пятиступенчатый конвейер, чтобы наложение связи на вычисления было бесшовным.

Комментарий переводчика: что на рисунке «наложение на фазе decode»

Здесь все 132 SM отданы вычислениям, а под связь — 0 SM: пересылки делают низкозадержечные ядра DeepEP, которые не занимают мультипроцессоры. Внимание разрезано на два шага: ATTN-0 — проекции MLA вниз и вверх и прочие операции после сбора (combine) и до основного внимания; ATTN-1 — основное внимание, выходная проекция и гейт маршрутизации MoE. Получается пять стадий: SHARED, ATTN-0, MLP, ATTN-1 и связь. Последовательность на рисунке:

Шаг	Вычисления (132 SM)	Связь
1	SHARED микробатча 0, ATTN-0 микробатча 1	DISPATCH микробатча 0
2	MLP микробатча 0	—
3	ATTN-1 микробатча 1	COMBINE микробатча 0
4	SHARED микробатча 1, ATTN-0 микробатча 0	DISPATCH микробатча 1
5	MLP микробатча 1	—
6	ATTN-1 микробатча 0	COMBINE микробатча 1

Длинная операция ATTN-1 одного микробатча покрывает пересылку другого.

Подробнее о нашем механизме наложения вычислений и связи — в репозитории profile-data.

Как добиться оптимальной балансировки нагрузки

Масштабный параллелизм (и DP, и EP) порождает серьёзную проблему: если одна GPU перегружена вычислениями или связью, она становится узким местом, тормозит всю систему, а остальные GPU простаивают. Чтобы использовать ресурсы по максимуму, мы стремимся выровнять нагрузку вычислений и связи на всех GPU.

1. Балансировщик prefill

• Главная проблема: у разных экземпляров DP разное число запросов и разная длина последовательностей. Из-за этого неравномерны вычисления основного внимания (core attention) и объём отправки при рассылке (dispatch send).
• Цели оптимизации:
  • выровнять вычисления основного внимания между GPU (балансировка вычислительной нагрузки внимания);
  • уравнять число входных токенов на GPU (балансировка отправки при рассылке), чтобы ни одна GPU не задерживала обработку.

2. Балансировщик decode

• Главная проблема: неравное число запросов и длины последовательностей у экземпляров DP приводят к разнице в вычислениях основного внимания (они зависят от занятого KV-кэша) и в объёме отправки при рассылке.
• Цели оптимизации:
  • выровнять использование KV-кэша между GPU (балансировка вычислительной нагрузки внимания);
  • уравнять число запросов на GPU (балансировка отправки при рассылке).

3. Балансировщик параллелизма экспертов

• Главная проблема: у любой MoE-модели есть эксперты, которые по своей природе нагружены сильнее других. Из-за этого вычислительная нагрузка экспертов на разных GPU неравномерна.
• Цель оптимизации:
  • выровнять вычисления экспертов на каждой GPU, то есть минимизировать максимальный объём приёма при рассылке (dispatch receive) среди всех GPU.

Схема онлайн-системы инференса DeepSeek

flowchart TB
API["API Server"] --> PLB["Prefill Load Balancer"]
PLB --> PS["Prefill Service (несколько экземпляров)<br/>внутри: Expert-Parallel Load Balancer"]
PS --> DLB["Decode Load Balancer"]
DLB --> DS["Decode Service (несколько экземпляров)<br/>внутри: Expert-Parallel Load Balancer"]
DS --> API
PS <--> KV["External KVCache Storage (необязательно)"]
DS --> KV

Схема онлайн-системы инференса DeepSeek (перерисовано по рисунку оригинала)

Комментарий переводчика

Запрос приходит на API-сервер, балансировщик prefill выбирает экземпляр сервиса prefill, тот считает KV-кэш промпта и передаёт работу через балансировщик decode сервису decode, который генерирует ответ и возвращает его API-серверу. Внешнее хранилище KV-кэша на рисунке помечено как необязательное: prefill читает из него и пишет в него, decode пишет. Именно здесь работает «кэш на диске» из статистики ниже, построенный на файловой системе 3FS.

Статистика онлайн-сервиса DeepSeek

Все сервисы инференса DeepSeek-V3/R1 работают на GPU H800, с той же точностью, что и при обучении. Конкретно: матричные умножения и пересылки при рассылке (dispatch) используют формат FP8, согласованный с обучением, а основные вычисления MLA и пересылки при сборе (combine) — формат BF16. Так обеспечивается оптимальное качество сервиса.

Кроме того, днём нагрузка на сервис высокая, а ночью низкая, поэтому мы сделали механизм, который в дневные пиковые часы разворачивает сервисы инференса на всех узлах. В ночные часы низкой нагрузки мы уменьшаем число узлов инференса и отдаём ресурсы под исследования и обучение. За последние 24 часа (с 12:00 27.02.2025 до 12:00 28.02.2025 по UTC+8) суммарная пиковая занятость узлов сервисами инференса V3 и R1 достигла 278, а средняя — 226,75 узла (в каждом узле 8 GPU H800). Если считать аренду одной GPU H800 за 2 доллара в час, общие затраты за сутки составляют 87 072 доллара.

Комментарий переводчика: рисунок «число узлов H800 для сервиса инференса»

На графике с 12:00 до полуночи держится максимум — около 278 узлов. После полуночи число узлов ступенями падает до минимума около 70 узлов (примерно с 03:30 до 06:30), а к 08:30 снова возвращается к 278. Проверка затрат: 226,75 узла × 8 GPU × 24 часа × 2 долл. = 87 072 долл.

За 24-часовой период статистики (с 12:00 27.02.2025 до 12:00 28.02.2025 по UTC+8) у V3 и R1:

• всего входных токенов — 608 млрд, из них 342 млрд (56,3%) попали в KV-кэш на диске;
• всего выходных токенов — 168 млрд. Средняя скорость вывода — 20–22 токена в секунду, средняя длина KV-кэша на один выходной токен — 4989 токенов;
• каждый узел H800 в среднем обрабатывает около 73,7 тыс. входных токенов в секунду на prefill (с учётом попаданий в кэш) или около 14,8 тыс. выходных токенов в секунду на decode.

Приведённая статистика включает все запросы пользователей из веба, приложения и API. Если бы все токены оплачивались по ценам DeepSeek-R1 (*), суточная выручка составила бы 562 027 долларов, а маржа (прибыль к затратам) — 545%.

(*) Цены R1: 0,14 долл. за 1 млн входных токенов (попадание в кэш), 0,55 долл. за 1 млн входных токенов (промах кэша), 2,19 долл. за 1 млн выходных токенов.

Однако наша реальная выручка значительно ниже по следующим причинам:

• цены DeepSeek-V3 заметно ниже, чем у R1;
• платная лишь часть сервисов (веб и приложение остаются бесплатными);
• в часы низкой нагрузки автоматически действуют ночные скидки.

Комментарий переводчика: рисунок «затраты и теоретическая выручка»

Почасовая столбчатая диаграмма. Затраты днём около 4,4 тыс. долл. в час и ночью падают примерно до 1 тыс. Теоретическая выручка днём держится около 27–31 тыс. долл. в час, а к 04:00–05:00 опускается примерно до 6 тыс. Сноска на рисунке: теоретическая выручка посчитана по стандартным ценам API R1 для всех токенов веба, приложения и API — это не фактический доход компании.

Как получается 545%: (562 027 − 87 072) / 87 072 ≈ 5,45. Обратите внимание на две вещи. Во-первых, в затраты входит только аренда GPU по условной цене, без зарплат, сети, хранилищ и обучения. Во-вторых, выручка гипотетическая. Поэтому это не «прибыльность DeepSeek», а оценка того, сколько стоит токен при хорошо загруженной системе, — тот же приём, что и с «5,6 млн долл. за обучение V3» (см. урок о техотчёте V3).

---

Приложение 1. Оглавление репозитория open-infra-index

От переводчика

Ниже — перевод главной страницы (README) репозитория, где лежит документ дня 6. Она служит оглавлением всей недели открытого кода и последующих публикаций. Значки и логотипы опущены, ссылки сохранены.

Привет, DeepSeek Open Infra!

202505 — статья индустриальной секции ISCA 2025

Insights into DeepSeek-V3: Scaling Challenges and Reflections on Hardware for AI Architectures («Взгляд на DeepSeek-V3: трудности масштабирования и размышления о железе для архитектур ИИ»). Статья на arXiv.

202504 — Путь к открытию движка инференса DeepSeek

202502 — неделя открытого кода

Мы — крошечная команда в @deepseek-ai, которая выжимает максимум в исследовании AGI.

Начиная с этой недели, с 24 февраля 2025 года, мы откроем 5 репозиториев — по одному в день. Не потому, что делаем громкие заявления, а просто как разработчики, которые с полной прозрачностью делятся своим скромным, но искренним прогрессом.

Это скромные строительные блоки нашего онлайн-сервиса: задокументированные, развёрнутые и проверенные в бою в продакшене. Никаких обещаний без кода — только честный код, который продвинул нашу крошечную, но амбициозную мечту.

Зачем? Потому что каждая опубликованная строка становится общим импульсом, который ускоряет путь. Ежедневные публикации скоро начнутся. Никаких башен из слоновой кости — только чистая гаражная энергия и инновации, движимые сообществом 🔧

Следите за новостями — давайте вместе увлечённо копаться в открытом коде.

День 1 — FlashMLA

Эффективное ядро декодирования MLA для GPU Hopper. Оптимизировано для последовательностей переменной длины, проверено в бою в продакшене.

• поддержка BF16;
• страничный KV-кэш (размер блока 64);
• производительность: 3000 ГБ/с в режиме, ограниченном памятью, и 580 TFLOPS в BF16 в режиме, ограниченном вычислениями, на H800.

(Разбор ядра — на странице «FlashMLA изнутри».)

День 2 — DeepEP

Представляем DeepEP — первую открытую библиотеку связи для EP при обучении и инференсе MoE-моделей.

• эффективная и оптимизированная связь «все со всеми» (all-to-all);
• поддержка связи внутри узла и между узлами через NVLink и RDMA;
• высокопроизводительные ядра для обучения и для prefill на инференсе;
• низкозадержечные ядра для декодирования на инференсе;
• нативная поддержка рассылки (dispatch) в FP8;
• гибкое управление ресурсами GPU для наложения вычислений и связи.

День 3 — DeepGEMM

Представляем DeepGEMM — библиотеку умножения матриц (GEMM) в FP8, которая поддерживает и плотные, и MoE-GEMM и обеспечивает обучение и инференс V3/R1.

• до 1350+ TFLOPS в FP8 на GPU Hopper;
• без тяжёлых зависимостей, чистая, как учебный пример;
• полностью компилируется на лету (Just-In-Time);
• основная логика — около 300 строк, но на большинстве размеров матриц обгоняет ядра, настроенные экспертами;
• поддерживает плотную раскладку и две раскладки для MoE.

День 4 — оптимизированные стратегии параллелизма

• DualPipe — алгоритм двунаправленного конвейерного параллелизма для наложения вычислений и связи при обучении V3/R1. Репозиторий.
• EPLB — балансировщик нагрузки параллелизма экспертов для V3/R1. Репозиторий.
• Анализ наложения вычислений и связи в V3/R1. Репозиторий.

(Перевод README DualPipe и EPLB — на странице «DualPipe и EPLB».)

День 5 — 3FS, ускоритель для всего доступа к данным DeepSeek

Fire-Flyer File System (3FS) — параллельная файловая система, которая использует всю пропускную способность современных SSD и сетей RDMA.

• 6,6 ТиБ/с суммарной скорости чтения в кластере из 180 узлов;
• 3,66 ТиБ/мин на тесте GraySort в кластере из 25 узлов;
• 40+ ГиБ/с пиковой пропускной способности на клиентский узел при поиске в KV-кэше;
• дезагрегированная архитектура с семантикой строгой согласованности;
• применяется в V3/R1 для предобработки обучающих данных, загрузки датасетов, сохранения и загрузки чекпойнтов, векторного поиска по эмбеддингам и поиска в KV-кэше на инференсе.

Репозитории: 3FS и Smallpond — фреймворк обработки данных поверх 3FS. (Перевод проектных заметок — на странице «3FS: проектные заметки».)

День 6 — ещё одно: обзор системы инференса DeepSeek-V3/R1

Пропускная способность и задержка оптимизированы за счёт:

• масштабирования батча с помощью EP между узлами;
• наложения вычислений и связи;
• балансировки нагрузки.

Данные продакшен-сервисов V3/R1:

• 73,7 тыс. / 14,8 тыс. входных / выходных токенов в секунду на узел H800;
• маржа (прибыль к затратам) — 545%.

Надеемся, что идеи этой недели будут полезны сообществу и внесут вклад в наши общие цели на пути к AGI.

Подробный разбор — документ дня 6 (переведён выше). Китайская версия: «Обзор системы инференса DeepSeek-V3/R1» (Чжиху, Zhihu).

2024 — статья об ИИ-инфраструктуре (SC24)

Fire-Flyer AI-HPC: A Cost-Effective Software-Hardware Co-Design for Deep Learning («Fire-Flyer AI-HPC: экономичное совместное проектирование программ и железа для глубокого обучения»). Статья, arXiv.

---

Приложение 2. Путь к открытию движка инференса DeepSeek

От переводчика

Перевод статьи OpenSourcing_DeepSeek_Inference_Engine/README.md из того же репозитория (апрель 2025). Она объясняет, почему DeepSeek не выложила свой внутренний движок целиком и что сделала вместо этого.

Несколько недель назад, во время недели открытого кода, мы открыли несколько библиотек. Сообщество отреагировало невероятно тепло: появились вдохновляющие совместные проекты, продуктивные обсуждения и ценные исправления ошибок. Это побудило нас сделать ещё один шаг: вернуть открытому сообществу наш внутренний движок инференса.

Мы глубоко благодарны экосистеме открытого кода, без которой наш путь к AGI был бы невозможен. Наш фреймворк обучения опирается на PyTorch, а движок инференса построен на основе vLLM; оба сыграли ключевую роль в ускорении обучения и развёртывания моделей DeepSeek.

Спрос на развёртывание моделей вроде DeepSeek-V3 и DeepSeek-R1 растёт, и мы хотим вернуть сообществу как можно больше. Сначала мы думали открыть внутренний движок инференса полностью, но увидели несколько трудностей:

• Расхождение кодовых баз. Наш движок основан на раннем форке vLLM более чем годичной давности. Структурно он похож, но мы сильно доработали его под модели DeepSeek, и расширить его для более широких сценариев трудно.
• Зависимости от инфраструктуры. Движок тесно связан с нашей внутренней инфраструктурой, включая инструменты управления кластером, поэтому для публичного развёртывания без серьёзных переделок он непригоден.
• Ограниченные силы на поддержку. Мы — небольшая исследовательская команда, сосредоточенная на создании лучших моделей, и у нас нет ресурсов поддерживать большой открытый проект.

С учётом этих трудностей мы решили сотрудничать с существующими открытыми проектами — это более устойчивая альтернатива.

Дальше мы будем тесно работать с существующими открытыми проектами, чтобы:

• выделять самостоятельные функции: оформлять переиспользуемые компоненты в модули и передавать их как независимые библиотеки;
• делиться оптимизациями: напрямую передавать улучшения архитектуры и детали реализации.

Мы глубоко благодарны движению открытого кода — от операционных систем и языков программирования до фреймворков машинного обучения и движков инференса. Для нас честь вносить вклад в эту процветающую экосистему и видеть, как сообщество принимает наши модели и код. Давайте вместе раздвигать границы AGI и добиваться того, чтобы его польза служила всему человечеству.

Уточним: эта статья описывает наш подход только к открытию кодовой базы DeepSeek-Inference-Engine. Что касается будущих моделей, мы сохраняем открытую и готовую к сотрудничеству позицию и по отношению к сообществу открытого кода, и по отношению к партнёрам-производителям железа. Мы обязуемся заранее, до выпуска новых моделей, синхронизировать инженерные работы, связанные с инференсом, чтобы сообщество могло обеспечить передовую (SOTA) поддержку с первого дня. Наша конечная цель — синхронизированная экосистема, в которой передовые возможности ИИ бесшовно реализуются на разных аппаратных платформах сразу после официального выпуска моделей.

От переводчика: как это обещание выполнялось

Обещание «поддержки с первого дня» видно на примере следующих моделей: к выпуску V3.2 вышли разреженные ядра FlashMLA, к V4.1 — ядра для NVIDIA и Huawei Ascend (см. «FlashMLA изнутри» и ядро для Ascend). Как поднять сервер с такой моделью в vLLM или SGLang — в уроке 7.1.2.

Словарик

EN	RU
throughput / latency	пропускная способность / задержка
expert parallelism (EP)	параллелизм экспертов
data parallelism (DP)	параллелизм по данным
prefill-decode disaggregation	раздельные prefill и decode (PD-дезагрегация)
redundant experts	избыточные (дублированные) эксперты
dual-batch overlap	наложение двух микробатчей
dispatch / combine	рассылка токенов экспертам / сбор ответов экспертов
core attention	основное внимание (сама операция softmax(QKᵀ)V)
load balancer	балансировщик нагрузки
on-disk KV cache	KV-кэш на диске
cost profit margin	маржа, отношение прибыли к затратам