ainews
DeepSeek V4 на одной B300: всего 770 токенов/сек в vLLM — что не так?
Разработчик получает всего 770 токенов/сек при batch-обработке на DeepSeek V4-Flash с одной GPU B300 через vLLM, хотя ожидал несколько тысяч. Выяснилось, что быстрое MoE-ядро требует несколько GPU, а спекулятивное декодирование DSpark на насыщенном батче снижает производительность вдвое. Ищет советы по оптимизации конфигурации.
Кейс показывает реальные грабли при деплое новых MoE-архитектур вроде DeepSeek V4 на production: оптимизации из benchmarks могут не работать или даже вредить на реальных задачах. Важно для всех, кто планирует использовать V4 для массовой обработки.
DeepSeek V4 тормозит на одной GPU: разбор полётов
Разработчик столкнулся с неожиданно низкой производительностью при запуске DeepSeek V4-Flash на одной NVIDIA B300 через vLLM 0.25.0. Задача — массовая очистка коротких текстовых записей с помощью batch-обработки (256 промптов одновременно, ~300 токенов на выход). Результат: всего 770 токенов в секунду вместо ожидаемых нескольких тысяч.
Что уже выяснилось
Проблема с MoE-ядром: быстрое ядро deep_gemm_mega_moe выдаёт ошибку на одной GPU — требует expert parallel (распределение экспертов по нескольким картам). Пришлось откатиться на flashinfer_trtllm, что могло снизить скорость.
Спекулятивное декодирование DSpark оказалось вредным: отключение этой оптимизации удвоило производительность на насыщенном батче. По логике, спекулятивное декодирование добавляет overhead при полной загрузке — но автор хочет убедиться, что это не баг.
Подозрение на sparse MLA attention: возможно, путь разреженного внимания работает в eager mode без CUDA graphs, что создаёт bottleneck.
Конфигурация
- Модель: DeepSeek V4-Flash (базовая, без DSpark)
- tensor_parallel_size: 1
- kv_cache_dtype: fp8
- block_size и max_num_seqs: 256
- prefix caching включён
- moe_backend: flashinfer_trtllm
- CUDA graphs: FULL_AND_PIECEWISE
Вопросы сообществу
Автор ищет коллег, кто реально работает с V4 Flash: какую скорость вы видите на одной GPU? Какой MoE backend используете? Должен ли sparse MLA путь использовать CUDA graphs по умолчанию, или нужны дополнительные флаги вроде VLLM_TRITON_MLA_SPARSE_ALLOW_CUDAGRAPH?
Похоже на классический кейс, когда архитектура модели (MoE + sparse attention) оптимизирована под multi-GPU сетап, а на одной карте упирается в неожиданные ограничения.
Ключевые выводы
- Быстрое MoE-ядро deep_gemm_mega_moe в DeepSeek V4 не работает на одной GPU — требует распределения экспертов (expert parallel)
- Спекулятивное декодирование DSpark снижает производительность вдвое на насыщенных батчах вместо ускорения
- 770 токенов/сек на B300 для batch-обработки — аномально низкий показатель, указывающий на узкое место в конфигурации
- Sparse MLA attention в V4 может работать без CUDA graphs, что критично снижает скорость
- Архитектура DeepSeek V4 явно заточена под multi-GPU setups — одна карта не раскрывает потенциал
Автор: Павел Заславский · Источник: reddit.com
**Классика жанра**: свежая модель с крутыми бенчмарками упирается в реальность production. DeepSeek V4 с его MoE и sparse attention явно проектировался под кластеры — на одной GPU половина оптимизаций либо не работает, либо наоборот тормозит. Особенно показательна история со спекулятивным декодированием: на синтетике красиво, на батчах — overhead.
Что реально ценно в этом посте — честная инженерная рефлексия без PR-шелухи. Человек методично вскрывает проблемы, которые обычно прячут под ковёр в официальных блогах. Для тех, кто собирается катить V4 в прод: смотрите внимательно на multi-GPU requirement для MoE-ядер и тестируйте спекулятивное декодирование на своих паттернах нагрузки, а не верьте циферкам из README.
Комментарии