Что такое DeepInfer? Инференс-движок DeepSeek и компоненты, которые не были выпущены

DeepInfer — это фреймворк инференса, опубликованный DeepSeek 16 октября 2026 года под лицензией Apache-2.0, и он обслуживает ровно одну модель: DeepSeek-V4.1-Flash, с DeepSeek-V4.1-Flash-1017 в качестве чекпоинта по умолчанию. То, что фреймворк рассчитан только на одну модель, — первое, что нужно понять, потому что это объясняет почти всё остальное в репозитории. Это не универсальный фреймворк для обслуживания моделей, который просто содержит конфигурацию DeepSeek. Это тот код, который DeepSeek запускает в продакшене, урезанный до частей, поддающихся обобщению, и он честно говорит об этом урезании: список в самом README того, что нужно полноценному сервису инференса и чего не включает этот релиз, перечисляет систему KV-кэша, дезагрегацию VE/Prefill/Decode и балансировку нагрузки между репликами с параллелизмом по данным. Что вы получаете — это вычислительный путь: ядра, параллелизм, спекулятивное декодирование, планирование, структурированный вывод. Чего вы не получаете — так это слоя хранения и маршрутизации, благодаря которому вычислительный путь дёшев в эксплуатации при масштабировании. DeepSeek объясняет почему: эти компоненты тесно связаны с внутренней инфраструктурой, поэтому дизайн описан в опубликованном материале, а код остаётся внутренним.

Что на самом деле находится в репозитории

Опубликованный список возможностей читается как экскурсия по узким местам обслуживания большой модели со смесью экспертов. Есть библиотеки ядер, которые DeepSeek выпускала ранее, — FlashMLA для внимания, DeepGEMM для матричных умножений, DeepEP для экспертно-параллельного обмена данными, а также TileKernels и DeepSelect. Есть схема параллелизма: внимание работает как параллелизм по данным со сбалансированным параллелизмом по контексту, часть MoE работает как экспертный параллелизм с балансировщиком нагрузки для экспертного параллелизма. Есть DSpark — стек спекулятивного декодирования, с длинами проверки, которые планируются, а не фиксируются. Есть SWA bounded replay — механизм, который не позволяет кэшу внимания со скользящим окном вызывать полный пересчёт при каждом промахе кэша. Есть асинхронное планирование пакетов, инвариантный к пакетам инференс с детерминированной выборкой и структурированный вывод, ограниченный регулярным выражением, JSON-схемой или EBNF.

Точка входа намеренно мала. После установки DEEPINFER_ACCELERATOR в nvidia или аналогичного значения для Ascend и запуска build.sh, репозиторий поставляет examples/offline_inference.py, который запускает чекпоинт по умолчанию от начала до конца. DEEPINFER_HF_MODEL_DIR указывает на другой каталог весов. Опубликованные бенчмарки были измерены на четырёх GPU SM100 для prefill и 64 GPU SM100 для decode, что отражает конфигурацию развёртывания, для которой создавался движок, а не демонстрацию для ноутбука.

В README также указано, откуда взялся код, что стоит знать перед чтением. Движок изначально был построен в основном на vLLM, а вдохновение для дизайна черпалось из SGLang и TensorRT-LLM. Эта преемственность видна в структуре — планировщик, интерфейс paged attention и путь сэмплирования покажутся знакомыми всем, кто читал эти проекты, — и объясняет, почему релиз представляет собой форк стека обслуживания, а не архитектуру, написанную с нуля. То, что добавил DeepSeek, — это часть, специфичная для его собственной модели: дезагрегированное развертывание, широкий экспертный параллелизм с его балансировщиком, реплей скользящего окна и DSpark.

Чего в нём нет — и почему это важнее.

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

• Система KV-кэша. Повторное использование префикса — основной источник экономии в чат-нагрузке, поскольку попадание в кэш заменяет prefill. Без хранилища кэша каждый запрос заново вычисляет свой промпт. В собственной публикации DeepSeek описывается используемое ею хранилище: выделенный кластер 3FS, а не локальная память хоста, — именно для того, чтобы любая машина prefill могла попасть в любой префикс, а ёмкость кэша можно было масштабировать независимо от вычислений.

• Разделение VE/Prefill/Decode. В README отмечается, что большая часть функциональности на стороне движка уже присутствует в релизе; недостает только развертывания. Разделение vision encoder, prefill и decode позволяет подбирать размер каждого этапа с учетом его собственного узкого места и управлять временем до первого токена отдельно от времени между токенами. Это инфраструктурное решение, а не флаг.

• Балансировка нагрузки между репликами с параллелизмом по данным. DeepSeek использует четыре балансировщика — prefill, decode, vision encoder и expert-parallel — и описывает все четыре в статье. Никакая логика маршрутизации не входит в поставку. Без неё парк реплик будет настолько хорош, насколько хорош роутер, который вы поставите перед ним, а наивный round-robin-роутер уничтожит коэффициент попаданий в кэш, который хранилище было призвано защищать.

Если читать это вместе, пропуск говорит о том, что это за артефакт. DeepInfer — это эталонная реализация вычислительного пути, опубликованная для того, чтобы работу над ядром и планированием можно было изучить и повторно использовать, а не дистрибутив, который вы устанавливаете и на который направляете трафик.

Аппаратный шлюз — вот настоящий фильтр.

DeepInfer ориентирован на NVIDIA SM100 и Huawei Ascend 950. Не предусмотрены ни путь для Ampere, ни путь для Hopper, что исключает большинство GPU в большинстве современных кластеров. Остальная часть инструментальной цепочки столь же специфична: только Linux, GCC 13 или новее, Python 3.12, CUDA 13 для NVIDIA или CANN 9.2 для Ascend. И релизов вообще нет — на момент чтения 21 октября 2026 года в репозитории не было ни одного опубликованного релиза, так что скачивать нечего и фиксировать нечего. Вы клонируете его и собираете с использованием собственной инструментальной цепочки.

Такое сочетание необычно для open-source-релиза, привлекающего столько внимания, и его лучше воспринимать как точное описание границ проекта, а не как упущение. Ядра в репозитории написаны под конкретный набор инструкций и конкретное межсоединение; цифры в README получены на этом оборудовании. Перенос вычислительного пути на одно поколение назад — как раз та работа, которую сообщество выполняет быстро, а инженерная организация не может обещать. В течение нескольких дней после релиза на GitHub появился сторонний порт, ориентированный на более старые компоненты NVIDIA, — это полезный сигнал о спросе и вовсе не сигнал о том, сохранятся ли опубликованные показатели пропускной способности после портирования.

Схема развёртывания, которую DeepSeek фактически использует

В описании архитектуры допущения репозитория становятся явными. Система разделена на визуальный энкодер, prefill и decode, а также выделенные узлы хранения. Prefill использует экспертный параллелизм от 2 до 8 с соответствующим параллелизмом по данным, выбирая наименьшую конфигурацию, которую допускает HBM. Decode идет в обратную сторону: экспертный параллелизм и параллелизм по данным от 64 до 128, что DeepSeek называет Wide-EP, используя наибольшую конфигурацию, которую допускают доступные GPU. Тензорный параллелизм и контекстный параллелизм вообще не используются. Визуальный энкодер работает на одном GPU на экземпляр, при этом рекомендуются более дешевые GPU, потому что энкодер — не то место, куда уходят деньги.

Самое маленькое развертывание, которое имеет смысл, следует из этих цифр. Будут работать один GPU для prefill и один GPU для decode, и на практике соотношение между двумя пулами составляет примерно один к одному. Но поскольку для decode требуется 64 GPU или больше, чтобы получить преимущество экспертного параллелизма, минимальная эффективная единица — это 64 GPU для prefill плюс 64 GPU для decode. Это число стоит запомнить, читая любые утверждения об эффективности DeepInfer: эти цифры описывают развертывание на 128 GPU, и половина его приходится на одну стадию.

Разделение prefill и decode между дата-центрами технически возможно, поскольку DeepSeek-V4.1-Flash существенно сжимает свой KV-кэш, и собственное развертывание DeepSeek действительно размещает инференс-узлы в разных, но соседних дата-центрах. Бюджет составляет примерно 400 Гбит/с межсоединений на каждые восемь GPU, и в материале откровенно говорится об издержках по надежности — оптоволокно между зданиями легко перерезать.

Почему декодирование так широко распространено?

Широкий экспертный параллелизм — самый значимый выбор в архитектуре, и его легко ошибочно принять за трюк масштабирования. В слое смеси экспертов каждый токен обращается к небольшому числу экспертов, поэтому стоимость шага декодирования определяется главным образом перемещением весов экспертов и активаций, а не арифметической интенсивностью. Распределение экспертов по 64 или 128 GPU снижает трафик памяти на шаг, создаваемый каждым GPU, что повышает число токенов в секунду, если — и это условие — нагрузка между экспертами остаётся равномерной. Для этого и нужен балансировщик нагрузки при экспертном параллелизме.

Настройки DeepSeek достаточно конкретны, чтобы их скопировать. Для prefill каждая GPU хранит четыре резервных эксперта сверх тех, которыми владеет, статистика собирается по окну в 100 шагов, а эксперты переназначаются каждые 1 000 шагов, при этом веса перемешиваются внутри группы через разделяемую память NVLink. Измеренный дисбаланс — отношение самого медленного ранга к среднему — составил 1,074 для конфигурации EP4/DP4 и 1,045 для EP2/DP2. Для decode настройки растянуты: один резервный эксперт на GPU, окно статистики в 1 000 шагов, переназначение каждые 10 000 шагов и измеренный дисбаланс 1,090. Разница между ними и есть суть. Prefill имеет дело с нагрузкой всплесками и неоднородной работой и нуждается в быстрой ребалансировке; decode имеет дело с ровным потоком и может позволить себе длинное окно, поэтому ребалансируется редко и почти ничего за это не платит.

Маршрутизация устроена аналогично. Prefill-запросы группируются по общей длине контекста в четыре уровня — менее 16K, от 16 до 64K, от 64 до 256K и 256K и выше — а движки назначаются на уровни в соответствии с долей каждого уровня в вычислительном спросе в предыдущем раунде. В пределах одного GPU размер чанка для каждого шага prefill не фиксирован: подогнанная квадратичная модель затрат предсказывает, сколько времени займёт шаг при заданном числе токенов последовательности и уже вычисленном префиксе, а планировщик определяет наибольший чанк, который укладывается в бюджет 32 768 токенов в пределах оставшегося времени. Балансировщик decode одновременно балансирует два измерения — количество запросов и общую длину KV-кэша, — отправляя короткие запросы на GPU с низкой конкурентностью и длинным кэшем, а длинные запросы — на GPU с небольшим кэшем. Собственная оценка DeepSeek того, сколько всё это даёт: примерно 80 процентов от идеально сбалансированного офлайн-бенчмарка.

Кэш и вопрос о трёх днях

KV-кэш размещается на выделенном кластере 3FS, а не в локальной памяти хоста, и это решение определяет остальную часть архитектуры хранения. Данные хранятся с использованием помехоустойчивого кодирования 10+2, поэтому каждая группа кодирования переживает одновременный отказ двух узлов; операция чтения рассылает запросы всем 11 узлам группы, и любых 10 ответов достаточно для декодирования. На каждом узле хранения работает обработчик сборки мусора, который при превышении заданного порога вытесняет данные по LRU. Рекомендуемая конфигурация сервера включает 20 твердотельных накопителей по 30,73 ТБ каждый и обеспечивает как минимум 40 ГБ/с чтения и 5 ГБ/с записи, а его ёмкость рассчитана на хранение примерно 24 часов данных на сервер. На практике кластер обеспечивает около 14,4 ТБ логического кэша на каждый активный GPU, при этом физическая ёмкость больше.

Именно на этапе резидентности компромисс становится заметным. На стороне кэша нет логики истечения срока; TTL задаётся на стороне хранения — три дня для трафика агентов и семь дней для трафика чат-ботов — на кластере, вмещающем около 100 петабайт твердотельной памяти. Это разделение существует потому, что у трафика чат-ботов гораздо более тяжёлый длинный хвост попаданий: небольшой объём кэша читается многократно, поэтому его потеря снижает общий коэффициент попаданий сильнее, чем можно предположить по объёму. Измеренные DeepSeek потери от сокращения срока хранения для чат-ботов до трёх дней составляют от 0,5 до 1 процента коэффициента попаданий в кэш. Это небольшое число, которое на деле представляет большой объём пересчитываемого prefill.

Внимание со скользящим окном получает отдельный кэш с другими правилами. {{1}}Кэш SWA не включается в постраничные блоки; каждая последовательность занимает один слот фиксированного размера в памяти хоста, а для DeepSeek-V4.1-Flash хранятся первые 20 слоёв.{{/1}} {{2}}Хранится только эта область — 20 слоёв × 134 токена × 528 байт, что составляет 1 415 040 байт на последовательность в формате MXFP8.{{/2}} {{3}}Ничего не уходит в кластер хранения; всё остаётся в памяти машины, которая это создала, при этом каталог в памяти фиксирует, какая машина что хранит, а при попадании на другой машине данные возвращаются по VLAN 400 Гбит/с.{{/3}}

Два механизма, которые формируют основные показатели

Ограниченный повтор — более интересный из двух вариантов, поскольку он превращает неограниченные затраты в постоянные. Обычно промах кеша скользящего окна означает пересчёт окна с самого начала, и затраты растут с длиной контекста и количеством слоёв. DeepSeek вместо этого пересчитывает только последние 128 токенов и усекает окно внимания до этого сегмента, создавая приближённый кеш SWA по фиксированной цене. На стороне энкодера это полностью отделяет длину попадания в префиксный кеш от кеша SWA: если кеш SWA отсутствует, последние 128 токенов попавшего в кеш префикса воспроизводятся заново, а блочный кеш используется без изменений.

Именно на стороне декодера экономия велика. В этой архитектуре кэш блоков слоёв декодера проецируется из скрытого состояния последнего слоя энкодера, поэтому для каждого слоя нужно вычислять только SWA-кэш декодера — а точное его восстановление означало бы прогон последних 2 560 токенов через 20 слоёв декодера при каждом prefill. Если вместо этого воспроизводить 128 токенов и использовать результат только для декодирования, не позволяя ему попасть в prefix cache, общие вычисления prefill сокращаются почти вдвое. Это одно изменение ценнее большинства оптимизаций ядер, и такое под силу только команде, владеющей архитектурой модели.

Вклад DSpark скромнее и более традиционен. Вероятности принятия черновых токенов различаются в зависимости от запроса и позиции, поэтому проверка фиксированных пяти черновых вариантов на каждом шаге расходует вычисления на токены, которые будут отклонены. Головка уверенности предсказывает вероятность принятия каждого чернового токена, а планировщик сортирует черновые варианты по ожидаемой отдаче и проверяет только префикс, максимизирующий пропускную способность. В производстве черновая модель по-прежнему генерирует пять токенов на шаг; число проверяемых снижается с 5,00 до 3,2–4,4, то есть примерно на 30%, а принятая длина почти не меняется — 3,29 против 3,20. Судя по данным бенчмарка EP64/DP64, это даёт на 4–7% больше пропускной способности при примерно 60 одновременных последовательностях на ранг. Ровно при 60 пропускная способность на ранг возрастает с 13 730 до 14 466 токенов в секунду. При менее чем примерно 16 одновременных последовательностях метод даёт небольшой чистый проигрыш, и это стоит знать, прежде чем применять его для развёртывания с низким трафиком.

Что означает цифра в 155 триллионов

Самое цитируемое число, связанное с этим релизом, — это один кластер, обслуживающий 155 триллионов токенов в день при общей выручке 38 долларов США за GPU-час по непиковым ценам. Обе части заявлены поставщиком, и ни одна из них не является бенчмарком, который можно воспроизвести, что не делает их неинтересными: показатель выручки за GPU-час — это действительно иной тип утверждения, чем число пропускной способности, потому что он сводит загрузку, ценообразование и долю попаданий в кэш в одну строку. Это также показатель, который чаще всего цитируют без уточнений, поэтому уточнения стоит зафиксировать: один кластер, непиковые цены, выручка, а не затраты, и агрегирование по prefill, decode и vision encoder.

{{1}}Два менее значительных раскрытия более непосредственно полезны.{{/1}} {{2}}В декодирующем ядре FlashMLA в публичном репозитории отсутствует одна вручную настроенная оптимизация ассемблерного кода, которая есть во внутренней версии, из-за чего в изоляции оно работает на 5–10 процентов медленнее;{{/2}} {{3}}DeepSeek заявляет, что сквозная производительность различается не более чем на 5 процентов.{{/3}} {{4}}А внутренняя черновая модель для спекулятивного декодирования новее опубликованной, причём разница в производительности описывается как небольшая.{{/4}} {{5}}Оба утверждения формируют ожидание относительно того, какую часть опубликованной производительности третья сторона может достичь, скопировав код, и ответ таков:{{/5}} {{6}}большую часть,{{/6}} {{7}}при условии, что аппаратное обеспечение совпадает.{{/7}}

Репозиторий в его нынешнем виде

Приведённый выше снимок сделан 21 октября 2026 года и показывает, что на странице указано 16,3 тыс. звёзд. GitHub API, запрошенный в тот же день, вернул 16 590 звёзд, 1 649 форков и 176 открытых issues, при этом issues отключены, а обсуждение перенаправлено в GitHub Discussions. С тех пор число звёзд продолжило расти, поэтому воспринимайте каждую цифру здесь как отметку времени, а не как свойство кода. Такой трафик менее чем за неделю говорит больше об интересе к serving-стеку DeepSeek, чем о готовности кода, а количество релизов, равное нулю, говорит об остальном.

Если вы подумываете запустить это самостоятельно

Честный вывод таков: DeepInfer стоит внимательно изучить, но с ним трудно работать. Четыре вопроса подскажут, подходит ли он вам.

• У вас есть SM100 или Ascend 950? Всё остальное в инструментальной цепочке вытекает из этого. Без подходящего ускорителя опубликованные цифры не переносятся, а порты сообщества не проверены в производственном масштабе.

• Можно ли запустить 64 GPU декодирования в одном коммуникационном домене? Широкий параллелизм экспертов — это не оптимизация, которую можно пропустить; это конфигурация, вокруг которой был спроектирован путь декодирования. Ниже этого масштаба вы запускаете другую систему с тем же названием.

• У вас уже есть кэш префиксов? Если нет, то вы сравниваете вычислительный путь DeepInfer с конкурирующим стеком, в состав которого такой кэш уже входит, и сравнение будет выглядеть хуже, чем заслуживает эта архитектура.

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

Если вы предпочитаете не владеть ничем из вышеперечисленного

Для большинства команд практический вопрос не в том, как развернуть DeepSeek-V4.1-Flash, а в том, откуда его вызывать. Модель доступна через совместимый API — без создания кластера на 128 GPU и без повторной реализации балансировщика нагрузки, — и это та же модель, архитектуру которой описывает эта статья: та же работа с контекстом, то же поведение при структурированном выводе, но без работ по дизагрегации.

Сравнение, которое стоит делать, — не о том, какой движок быстрее в отвлечённом смысле, потому что опубликованные цифры — это заявленные производителями измерения на оборудовании, которого у большинства читателей нет. Оно о том, является ли рабочая нагрузка такой, где 3-дневный TTL кэша и пул декодирования на 64 GPU меняют цену, или такой, где запрос каждые несколько секунд через API просто дешевле любых операций, описанных выше. Для второго случая — а это большинство случаев — правильное количество DeepInfer, которое нужно использовать, равно нулю, а правильное количество, которое нужно прочитать, — всё. Начните с страницы модели DeepSeek V4.1 Flash, если вам нужен эндпоинт; начните с README репозитория, если хотите узнать, что делает эндпоинт.