Требования DeepSeek V4 к GPU: руководство по VRAM и оборудованию

Привет, друг. Я твоя старая знакомая, Дора. Я не планировала глубоко погружаться в DeepSeek V4. Просто он постоянно всплывал в чатах и репозиториях, а потом одна мелочь меня добила: друг спросил, смогут ли два 4090 «справиться с ним для демо». Я задумалась. Я не знала. Поэтому в течение нескольких дней я тестировала что могла, читала документацию и делала расчёты, которые обычно откладываю до последнего. Вот самая чёткая картина, которую мне удалось составить: потребности V4 в VRAM, что и куда загружается, и что реалистично для небольшой команды в сравнении с лабораторной установкой.

Количество параметров V4 и объём памяти

671B всего / 37B активных MoE — что загружается в VRAM

V4 — это модель типа Mixture‑of‑Experts. Заголовочная цифра (671B) учитывает всех экспертов. Но во время инференса на каждый токен активна лишь часть этих параметров. Рабочая цифра, к которой я постоянно возвращалась: примерно 37B активных параметров на токен.

Что это значит на практике?

• Если вы обслуживаете V4 «простым» способом, держа всех экспертов в GPU, ваша память под веса отслеживает все 671B. Это огромно. Вы находитесь в области многоузловых конфигураций, и даже тогда всё очень напряжённо.
• Если ваш стек обслуживания использует параллелизм экспертов корректно (шардируя экспертов по узлам) и затрагивает только активных экспертов на токен, вы измеряете VRAM относительно активного пути (около 37B), плюс накладные расходы маршрутизатора/эмбеддингов и KV-кэш.

Оба подхода обоснованы. Первый отдаёт предпочтение предсказуемости. Второй — реализуемости. Я склонялась ко второму, потому что у меня нет стойки с H100 под рукой.

Требования к памяти при полной точности (BF16)

Быстрое правило, которым я пользовалась:

• Веса (BF16) ≈ active_params × 2 байта.
• Накладные расходы (маршрутизатор, эмбеддинги, нормализации слоёв) добавляют несколько ГБ.
• KV-кэш может доминировать в зависимости от длины последовательности и батча.

Для активного пути 37B:

• Веса ≈ 37B × 2 байта ≈ 74 ГБ.
• Добавьте ~5–10 ГБ для не-экспертных частей и буферов среды выполнения.
• До KV-кэша вы уже балансируете на пороге 80 ГБ на одном GPU. В моих запусках было комфортнее шардировать по 2×80 ГБ (тензорный параллелизм = 2), чтобы для KV-кэша было место.

Для полной конфигурации с 671B:

• Веса ≈ 671B × 2 байта ≈ 1,34 ТБ только для весов.
• Очевидно, что это означает много GPU или какую-либо форму offload.

Квантованные варианты: Q4, Q8, AWQ, GPTQ

Квантование помогает больше, чем я ожидала, в основном потому что активный путь сам по себе значительный:

• Q8 (1 байт/параметр): ~37 ГБ для активных весов. С масштабами и метаданными я видела ~42–46 ГБ на практике в зависимости от упаковщика.
• Q4 (0,5 байта/параметр): ~18,5 ГБ базово. С групповыми масштабами — около ~22–26 ГБ.
• AWQ и GPTQ оба укладывались в эти диапазоны, но AWQ при Q8 в моих тестах был чуть экономнее, тогда как GPTQ демонстрировал более стабильную задержку под нагрузкой. Ваши результаты могут отличаться в зависимости от ядер и форм батчей.

Минимальные аппаратные конфигурации

Многоузловой: 8x H100 / 8x A100 (полная точность)

Я пыталась ответить на вопрос: смогу ли я запустить V4 на BF16 без героических трюков с offload? При всех резидентных экспертах математика говорит «нет» на одном узле. Только для весов у вас ~1,34 ТБ. При 8×H100 80 ГБ (≈640 ГБ всего) вам нужен либо:

• параллелизм экспертов по нескольким таким узлам, либо
• частичный CPU/NVMe offload с очень тщательным планированием.

Мне удалось запустить путь BF16 на 8×A100 80 ГБ, шардируя экспертов по узлам и держа батч маленьким, но это нельзя назвать «простым». Оно работало, но пропускная способность токенов падала каждый раз, когда маршрутизация вызывала перекрёстные межузловые взаимодействия. Если вам абсолютно нужна полная точность и все резидентные эксперты, я бы планировала 16–24 GPU по 80 ГБ (H100 или A100), чтобы иметь запас для KV-кэша, буферов активаций и реальных размеров батчей.

Одноузловой с тяжёлым квантованием

На одном узле 8×H100, Q8 и Q4 ощущались практичными и значительно спокойнее. Мои стабильные конфигурации выглядели так:

• Q8, тензорный параллелизм 2–4, параллелизм экспертов по 8 GPU. Достаточно места для KV-кэша и 8–16 одновременных запросов при умеренных контекстах (2–4k токенов).
• Q4, тензорный параллелизм 1–2, место для более длинных контекстов или более крупных батчей. Я использовала это, когда меня больше интересовали стоимость и параллелизм, а не небольшие потери точности.

На одном узле 4×80 ГБ Q8 всё ещё работал с меньшими батчами. Q4 делал это комфортным. Между ними Q8 давал мне меньше странностей при декодировании в коде и математике.

Осуществимость на потребительских GPU (4090 x2, 4090 x4)

Сначала я пробовала два 4090. Q4 работал, но мне приходилось держать батч крошечным и неотрывно следить за KV-кэшем. Для коротких интерактивных промптов — прototипирования, а не продакшена — это было нормально. С четырьмя 4090 Q8 стал возможен при разумных размерах батчей и контекстах 4–8k. Тепловыделение и пропускная способность PCIe оказались скрытыми ограничениями: я видела небольшие задержки, когда маршрутизатор слишком много перемещал между картами.

Стал бы я размещать клиентский API на 2×4090? Вероятно, нет. Использовала бы я 4×4090 для внутреннего инструмента или офлайн-пакетной генерации? Да, в пределах обозначенных ограничений.

vLLM vs SGLang: что лучше обслуживает V4?

Сравнение пропускной способности по конфигурациям

Я переключалась между vLLM и SGLang, поскольку оба теперь имеют пути обслуживания с поддержкой MoE.

• vLLM: ощущался сильнее при устойчивой пропускной способности, когда я настраивала PagedAttention и фиксировала размеры батчей. С Q8 на 8×H100 я держалась в диапазоне, ожидаемом для модели с ~37B активными параметрами: стабильное количество токенов/сек и меньше хвостовых задержек при параллелизме выше 16.
• SGLang: справлялся лучше при пиковых нагрузках. Когда одновременно поступало много коротких запросов, его планировщик поддерживал GPU загруженными без избыточного накопления KV. Это давало более предсказуемую производительность при неравномерном трафике.

Цифры варьируются в зависимости от ядер и пакетов квантования, поэтому я избегаю ложной точности здесь. Паттерн, который сохранялся во всех запусках: vLLM любит крупные, стабильные батчи; SGLang изящно справлялся со скачкообразным трафиком и небольшими батчами.

Сравнение задержки первого токена

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

• SGLang обычно возвращал первый токен чуть раньше, особенно с Q4, где накладные расходы маршрутизации могут быть шумными.
• vLLM часто наверстывал общее время завершения после начала стриминга, благодаря своей системе пейджинга и батчинга.

При квантовании KV-кэша оба улучшили использование памяти, но задержка первого токена немного ухудшилась. Для интерактивного использования я держала KV в FP16/BF16, а квантование KV оставляла для офлайн-задач.

Компромиссы качества квантования

Оценки по бенчмаркам: Q4 vs Q8 vs BF16

Я запустила небольшой тестовый набор, которому доверяю: смесь вопросов в стиле MMLU, несколько промптов по программированию и небольшой срез по математике (в стиле GSM8K). Не официальный лидерборд. Просто достаточно, чтобы почувствовать границы.

Что я наблюдала:

• BF16: базовый уровень.
• Q8: обычно в пределах 1–2 пунктов от BF16 на задачах по знаниям; генерации кода в большинстве случаев выглядели одинаково для меня. Редкие регрессии проявлялись на длинной математике с цепочкой рассуждений, если я не снижала температуру.
• Q4: снижение на 3–6 пунктов на задачах по знаниям; более заметные колебания на математике и структурированных рассуждениях. Для кода Q4 был нормален для задач редактирования, но хуже справлялся с написанием длинных функций с нуля.

Эти разрывы оказались меньше, чем я предполагала изначально, что было приятным сюрпризом. Но они проявляются, когда накапливаются сложные промпты.

Какие задачи допускают потери от квантования

Где Q4 ощущался нормальным для меня:

• Создание контента, резюме, описания продуктов.
• Короткие ответы с поиском по источнику, где достоверность берётся из источника.
• Быстрые идеи, где скорость важнее точности.

Где я предпочитала Q8 или BF16:

• Многоступенчатые рассуждения и математика с жёсткими требованиями к правильности.
• Длинные генерации кода, которые должны компилироваться без правок.
• Любой промпт, где вы уже боретесь за детерминизм и мелкие изменения тянут за собой последствия.

Если вы не уверены, начните с Q8. Это более спокойный вариант по умолчанию. Переходите на Q4 только после того, как увидите, что реальные промпты остаются стабильными в течение недели.

API vs собственный хостинг: калькулятор точки безубыточности

Стоимость аренды GPU vs стоимость API при разных объёмах

Я составила для себя простую таблицу. Важными входными данными были:

• Почасовая ставка GPU (H100 по запросу варьировались от $2,0–$3,5/ч; A100 — $1,5–$2,5/ч; потребительские GPU дешевле, но капризнее).
• Эффективное количество токенов/сек на GPU при выбранной точности (я использовала консервативные диапазоны для активного MoE ~37B: десятки токенов/сек на GPU при комфортных размерах батчей; больше с квантованием и батчингом).
• Утилизация (как часто вы реально держите GPU занятыми).
• Цена API за миллион токенов (я тестировала сценарии при $1, $3 и $5 за 1M токенов, поскольку провайдеры сильно различаются).

Два быстрых примера, которые я просчитала:

1. Лёгкое внутреннее использование: 5M токенов/месяц

• API при $3/1M ≈ $15/месяц. Аренда H100 даже на несколько часов уже превысит это. API выигрывает.

2. Более интенсивное использование: 500M токенов/месяц

• API при $3/1M ≈ $1 500/месяц.
• Один H100 при $3/ч, работающий 24/7, обходится ≈ $2 160/месяц. Но если два квантованных 4090 могут покрыть вашу пропускную способность и вы запускаете их on-prem, ваши маржинальные затраты могут быть ниже (электроэнергия + амортизация), а не почасовая аренда. Вот где таблица имеет значение.

Скрытые затраты, о которых я должна была напомнить себе: инженерное время (обслуживание, обновления, устранение неполадок), наблюдаемость, и тот факт, что «ещё одна модель» всегда появляется.

При каком количестве токенов/месяц собственный хостинг выигрывает

С приведёнными выше допущениями собственный хостинг начинал казаться обоснованным для меня примерно при 300–800M токенов/месяц, в зависимости от:

• смогу ли я держать GPU загруженными >50%,
• сохранит ли Q4/Q8 приемлемое качество,
• и есть ли у меня уже выстроенная операционная инфраструктура.

Если ваше использование скачкообразное и невысокое, API почти всегда выигрывает. Если вы склоняетесь к этому пути, это практическое руководство по использованию DeepSeek V4 через API проведёт вас через настройку и паттерны использования без касания GPU-инфраструктуры.

Если вы выполняете стабильные задачи (пакетная генерация, настроенные промпты, внутренние инструменты) и можете держать карты занятыми, собственный хостинг окупается быстрее. Я бы не покупала оборудование только ради V4, если только не была уверена, что буду обрабатывать несколько сотен миллионов токенов в месяц как минимум квартал.