DeepSeek DeepInfer: требования к самостоятельному развёртыванию и сравнение с API

DeepInfer — открытый фреймворк инференса DeepSeek. Он выполняет модель, но не является новой моделью или готовым API, который обслуживает провайдер. Для разработчика главный вопрос — нужно ли его команде вообще эксплуатировать бэкенд инференса. Если задача состоит в запуске приложения, сначала сравните API провайдера со всем сервисом, который пришлось бы создавать и поддерживать самостоятельно.

В статье разобрана официальная документация, проверенная 22 октября 2026 года. Мы не развёртывали DeepInfer на поддерживаемых ускорителях и не воспроизводили опубликованные графики производительности. Чек-листы и расчёт затрат ниже — инструменты принятия решения; все числа в примере условные. Ofox предоставляет доступ к API и выпускает эту статью. Поэтому мы явно указываем условия выбора обеих схем, не предполагая, что сервис провайдера подходит каждому читателю.

За что отвечают DeepInfer, модель и deepseek-recipe

Развёртывание модели включает несколько разных задач. Если считать названия компонентов взаимозаменяемыми, труднее и оценивать расходы, и искать ошибки.

В README DeepInfer поддерживаемой моделью указана DeepSeek-V4.1-Flash, а чекпойнтом по умолчанию — deepseek-ai/DeepSeek-V4.1-Flash-1017. Изменения самой модели разобраны в обзоре обновления 1017. Здесь речь идёт о движке и выборе способа его эксплуатации.

Отдельный репозиторий deepseek-recipe преобразует форматы Chat Completions, Responses и Messages. Вызывающая сторона по-прежнему должна обеспечить инференс модели, выполнение инструментов и HTTP-транспорт. Примеры серверов на Python и Rust используют имитацию инференса. JSON-ответ такой демонстрации не доказывает, что его сгенерировала настоящая модель.

Для разработчика это удобная граница диагностики: получение HTTP-ответа, правильное формирование промпта и успешная генерация реальной модели — три отдельные проверки. Успех одной из них ничего не говорит о двух остальных.

До планирования установки проверьте поддержку оборудования

Текущий README перечисляет GPU NVIDIA SM100 и NPU Huawei Ascend 950. Базовое окружение — Linux, GCC 13 или новее и Python 3.12. Для NVIDIA требуется CUDA 13, для Ascend — CANN 9.2. Это документированные платформы на дату проверки, а не обещание будущих портов.

RTX 4090 и H100 в этом перечне нет. Но отсутствие в списке не означает, что модели DeepSeek никогда не смогут работать на таких картах: запуск через другой движок — отдельный вопрос совместимости. И наоборот, pull request сообщества с предложением портирования не подтверждает поддержку в текущем релизе.

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

Нужно разделять три вопроса:

1. Поддерживается ли платформа? Указана ли она в документации этой версии движка?
2. Возможен ли запуск? Помещается ли модель в выбранную конфигурацию и завершается ли инференс корректно?
3. Эффективен ли запуск? Достигаются ли целевые пропускная способность и задержка при ожидаемой нагрузке?

Официальный раздел вопросов о развёртывании описывает минимальную эффективную единицу рекомендуемой промышленной архитектуры: 64 GPU для prefill и 64 GPU для decode. Это не абсолютный минимум GPU для любого офлайн-теста. Конфигурации бенчмарков в README также различаются для prefill и decode. Ни одну из этих цифр нельзя автоматически превращать в универсальный список «минимального оборудования» для закупки.

Чего не хватает между офлайн-инференсом и онлайн-API

Публичный README прямо называет три части, необходимые для полного сервиса: систему KV-кэша, разделение VE/Prefill/Decode и балансировку между репликами с параллелизмом по данным. VE — визуальный энкодер, prefill — обработка входного промпта, decode — последующая генерация токенов. При этом значительная часть функций движка для такого разделения уже реализована. Важно отличать наличие базовых механизмов от собранного сервиса, за эксплуатацию которого кто-то отвечает.

На этапе планирования назначьте ответственного и приёмочную проверку для каждой задачи:

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

Провайдеру внешнего API задайте аналогичные вопросы. Одно лишь совместимое имя эндпоинта не доказывает одинаковое поведение инструментов, учёт кэша или сроки хранения данных. Если требуется просто подключить клиент для программирования, начните с инструкции для Codex или инструкции для Claude Code и проверьте актуальную поддержку выбранного маршрута, прежде чем добавлять инфраструктуру.

Сравнивайте затраты при одинаковой нагрузке и требованиях к сервису

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

Для оценки API используйте отдельные тарифы на вход без кэша, вход с попаданием в кэш и выход. Плату за запись кэша, хранение, платформу и другие услуги добавляйте только там, где выбранный провайдер действительно её взимает. Неизвестные расходы — открытый вопрос, а не ноль. Количество токенов должно соответствовать правилам тарификации, включая токены рассуждений, если они оплачиваются. Наш обзор цен API DeepSeek объясняет эту тему; перед покупкой получите актуальную цену для точного маршрута.

Общий шаблон, где количество оплачиваемых токенов выражено в миллионах:

Месячная стоимость API =
  миллионы входных токенов без кэша × соответствующая ставка
  + миллионы входных токенов из кэша × соответствующая ставка
  + миллионы оплачиваемых выходных токенов × ставка выхода
  + остальные применимые месячные платежи

Месячная стоимость собственного развёртывания =
  аренда ускорителей ИЛИ распределённая амортизация оборудования
  + хост, сеть и хранение
  + электричество, не включённое в аренду
  + труд по эксплуатации и поддержке
  + резервирование и мощности для восстановления
  + затраты, зависящие от нагрузки

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

Воспроизводимый пример, а не реальная цена DeepInfer

Допустим, одна единица нагрузки содержит 100 млн входных токенов и 20 млн оплачиваемых выходных токенов, причём 60% входа оплачивается как попадания в кэш. Только для иллюстрации примем ставки 0,80 доллара США за миллион входных токенов без кэша, 0,20 доллара за миллион из кэша и 2,00 доллара за миллион выходных токенов. Это придуманные параметры расчёта, не текущие цены DeepSeek или Ofox. Все суммы далее указаны в долларах США.

Переменная стоимость API на единицу равна 40 × 0,80 + 60 × 0,20 + 20 × 2,00 = 84 доллара. Допустим также, что платформа стоит 16 долларов в месяц. Для своего развёртывания примем фиксированные расходы 50 000 долларов в месяц и ещё 20 долларов переменных затрат на единицу. Эти предположения также не являются реальным предложением на оборудование DeepInfer.

При этих предпосылках равенство выглядит как 84x + 16 = 50 000 + 20x, то есть x = 781 единица в месяц. Это уравнение не является рекомендацией к развёртыванию. Фиксированная конфигурация должна действительно обслуживать такой объём с нужной задержкой и надёжностью. Если для 781 единицы необходим ещё один кластер, пересчитайте фиксированные расходы: видимая точка равенства затрат может исчезнуть.

Снижение доли попаданий в кэш с 60% до 20% увеличивает в этом примере переменную стоимость API с 84 до 108 долларов на единицу. Затраты и доступная мощность своего сервиса тоже могут измениться, когда повторно используется меньше вычислений. Не фиксируйте одну сторону искусственно ради заявления о точной экономии. Отдельно оцените спокойный, ожидаемый и пиковый месяцы.

Проведите пилот, который может отклонить любой вариант

Команде, рассматривающей своё развёртывание, стоит пройти такую последовательность до обязательств по промышленному запуску:

1. Определите нагрузку и критерии успеха. Сохраните представительную выборку, удалив чувствительные данные должным образом. Установите требования к качеству, задержке, доле ошибок и обработке данных до выбора решения.
2. Установите совместимость платформы. Запишите ускоритель, программное окружение, чекпойнт и ревизию кода. Опирайтесь на актуальные примеры репозитория, а не на команду установки из блога без указания версии.
3. Проверьте корректность офлайн. Выполните подходящий официальный пример и проверки качества в этом окружении. Сохраните результаты и ошибки. Успешная сборка сама по себе не доказывает качество генерации или совместимость протокола.
4. Испытайте реальный путь сервиса. Замените имитацию бэкенда и проверьте обычный и потоковый запросы. Если нужны инструменты, отдельно проверьте сформированные аргументы и выполнение на стороне приложения. Испытайте неверный ввод, тайм-аут, отмену клиентом и перегрузку.
5. Измерьте реалистичную нагрузку. Включите короткие и длинные промпты, прогретый и холодный кэш, периоды простоя и всплески параллельности. Запишите выполненную работу, распределение задержек, ошибки и все оплачиваемые ресурсы.
6. Сравните с маршрутом провайдера. Сохраните максимально сопоставимые версии модели и поведение запросов. Зафиксируйте мешающие сравнению различия: квантование, настройки рассуждений, отсутствующие функции.
7. Пересчитайте затраты и решите. Подготовьте путь отката и назначьте оператора. Если вариант не выполняет обязательное требование, выгодная средняя стоимость не должна его оправдывать.

Если пилот не прошёл, сначала классифицируйте сбой, а затем тратьте дополнительные средства. Ошибка компилятора относится к окружению сборки; нехватка памяти требует анализа модели и ресурсов среды выполнения; корректный ответ имитации — результат работы тестовой обвязки; неверные аргументы инструментов требуют проверки протокола и пути модели. Ничто из перечисленного не доказывает, что другой API-ключ или более крупная машина исправят всё.

Выберите способ, который команда сможет обслуживать

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

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

До решения заполните короткую запись:

Задача и точная версия модели:
Обязательные требования к качеству, задержке и данным:
Ожидаемая / низкая / пиковая месячная нагрузка:
Измеренное поведение кэша и категории оплачиваемых токенов:
Собственная платформа и ответственный оператор:
Маршрут провайдера и открытые вопросы договора или функций:
Диапазон полных месячных расходов каждого варианта:
Доказательства пропускной способности для этой оценки:
Результат пилота, путь отката и дата решения:

DeepInfer важен тем, что открывает значительный объём инженерных решений для инференса. Однако решение о внедрении должно заканчиваться работоспособным сервисом и оценкой для вашей нагрузки. Само наличие открытого кода не доказывает ни уменьшение счёта за API, ни необходимость перестраивать работающее приложение вокруг нового бэкенда.