DeepSeek-V3/R1 Обзор систем рассуждений (День 6 недели открытого кода DeepSeek)

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

Целью оптимизации сервиса вывода DeepSeek-V3/R1 является:Высокая пропускная способность и низкая задержка.

Чтобы оптимизировать эти две задачи, в DeepSeek используется решение, называемое кросс-узловым экспертным параллелизмом (EP).

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

Однако EP повышает сложность системы двумя основными способами:

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

Эта статья посвящена DeepSeek Как решить эти проблемы:

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

Крупномасштабный межузловой экспертный параллелизм (EP)

Из-за большого количества экспертов в DeepSeek-V3/R1 (активировано только 8 из 256 экспертов на слой), высокая разреженность модели требует очень большого общего размера партии. Это обеспечивает достаточный размер партии для каждого эксперта, что приводит к увеличению пропускной способности и снижению задержки. Крупномасштабный кросс-узловой EP имеет решающее значение.

Поскольку в DeepSeek используется архитектура разделения предварительной заготовки и декодирования, на этапах предварительной заготовки и декодирования используются разные уровни параллелизма:

• Фаза предварительного заполнения [эксперт по маршрутизации EP32, MLA/общий эксперт DP32]Каждый блок развертывания охватывает 4 узла и имеет 32 избыточных эксперта по маршрутизации, причем каждый GPU обслуживает 9 экспертов по маршрутизации и 1 общего эксперта.
• Фаза декодирования [Эксперт по маршрутизации EP144, MLA/Sharing Expert DP144]Каждая единица развертывания охватывает 18 узлов и имеет 32 резервных специалиста по маршрутам, причем каждый GPU управляет 2 специалистами по маршрутам и 1 общим специалистом.

пересечение вычислений и коммуникаций

Крупномасштабный межузловой EP влечет за собой значительные коммуникационные накладные расходы. Чтобы снизить это, DeepSeek использует стратегию двойного перекрытия пакетов для скрытия коммуникационных затрат и повышения общей пропускной способности, разбивая пакет запросов на два микропакета. Во время фазы предварительного заселения эти два микропакета выполняются поочередно, а коммуникационные затраты одного микропакета скрываются за вычислениями другого.

Расчет фазы предварительного заселения - перекрытие коммуникаций

На этапе декодирования время выполнения различных этапов неодинаково. Поэтому DeepSeek разделяет слой внимания на два этапа и использует 5-фазный конвейер для достижения бесшовного перекрытия вычислений и коммуникаций.

Вычислительно-коммуникационное перекрытие на этапе декодирования

Более подробную информацию о механизме перекрытия вычислений и коммуникаций в DeepSeek можно найти на сайте https://github.com/deepseek-ai/profile-data.

Достижение оптимального распределения нагрузки

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

1. предварительно заполненный балансировщик нагрузки

• Ключевая проблема: разное количество запросов и длина последовательностей между экземплярами DP приводит к дисбалансу в вычислениях основного внимания и нагрузке при отправке расписания.
• Цели оптимизации:
  • Баланс вычислений основного внимания между графическими процессорами (распределение нагрузки на вычисления основного внимания).
  • Выравнивание входных сигналов для каждого GPU Токен количество (планирование отправки балансировки нагрузки), чтобы предотвратить длительное время обработки на определенных GPU.

2. Расшифровка балансировщиков нагрузки

• Ключевая проблема: неравномерное количество запросов и длина последовательности между экземплярами DP приводят к различиям в вычислении основного внимания (связанного с использованием KVCache) и нагрузке при отправке расписания.
• Цели оптимизации:
  • Балансировка использования KVCache между GPU (балансировка нагрузки Core Attention Computing).
  • Балансировка количества запросов на GPU (планирование отправки балансировки нагрузки).

3. Экспертный параллельный балансировщик нагрузки

• Ключевая проблема: для данной модели MoE существует неизбежно высокая нагрузка на экспертов, что приводит к несбалансированному распределению вычислительной нагрузки экспертов между различными GPU.
• Цели оптимизации:
  • Баланс экспертных вычислений на каждом GPU (т.е. минимизация максимальной нагрузки на все GPU).

Схематическая диаграмма системы онлайн-рассуждений DeepSeek

Схематическая диаграмма системы онлайн-рассуждений DeepSeek

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

Все сервисы вывода DeepSeek-V3/R1 предоставляются на графических процессорах H800 с точностью, соответствующей обучению. В частности, матричное умножение и передача расписания выполняются в формате FP8, соответствующем обучению, а вычисления ядра MLA и передача комбинаторики - в формате BF16 для обеспечения оптимальной производительности сервиса.

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

H800 Количество узлов обслуживания вывода

V3 и R1 в течение 24-часового статистического периода (с 12:00 UTC+8 27 февраля 2025 года до 12:00 UTC+8 28 февраля 2025 года):

• Всего входных токенов: 608B, из которых 342B токенов (56.3%) попали в кэш KV на диске.
• Всего выходных токенов: 168 B. Средняя скорость вывода составляет 20-22 токена в секунду, а средняя длина kvcache каждого выходного токена - 4 989 токенов.
• Каждый узел H800 обеспечивает среднюю пропускную способность ~73,7 тыс. токенов в секунду (с учетом обращений к кэшу) при предварительном заполнении и ~14,8 тыс. токенов в секунду при декодировании.

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

() Ценообразование R1: $0,14/M за входной токен (попадание в кэш), $0,55/M за входной токен (пропуск кэша), $2,19/M за выходной токен.

Однако реальный доход DeepSeek гораздо ниже по следующим причинам:

• Цена DeepSeek-V3 значительно ниже, чем у R1.
• Только некоторые услуги являются платными (доступ к Web и APP остается бесплатным).
• Ночные скидки автоматически применяются в непиковые часы.

Затраты и теоретические доходы