Инженерный разбор начался с расхождения: на карточке drowzeys/DeepSeek-V4-Flash-DSpark-Abliterated-Uncensored для одиночного запроса указано около 57 tok/s, а на собственной паре NVIDIA DGX Spark автор получил 42,5 tok/s. Стенд включал две ноды с GB10, 128 GB unified-памяти, соединение QSFP 200G поверх RoCEv2 и тензорный параллелизм TP=2. Полный чекпоинт занимает около 156 GiB и закеширован на обеих нодах.
Основную часть прироста дала смена runtime-образа: переход с vLLM 0.21.1 на 0.25.2 ускорил тот же чекпоинт примерно на 22%. Отдельный коммит не изолирован, поменялся весь пакет. Механика неочевидная: новый образ снизил расчётную частоту verification-шагов на 17%, но поднял число выходных токенов за шаг с 3,27 до 4,80. Второе изменение — явный выбор MoE-бэкенда flashinfer_b12x вместо режима auto: на пяти прогонах card-профиля среднее выросло с 59,7 до 67,6 tok/s, медиана — на 16,6%.
| Режим | Скорость |
|---|---|
| Карточка модели, одиночный запрос | ~57 tok/s |
| Авторская сборка до изменений | 42,5 tok/s |
| Новый runtime + auto MoE-бэкенд | 59,7 tok/s (среднее 5 прогонов) |
| Новый runtime + flashinfer_b12x | 67,6 tok/s |
| 12 параллельных запросов | 260 tok/s суммарно |
DeepSeek-V4-Flash — это MoE-модель: 284B параметров, из которых при обработке токена активируются около 13B. Экспертные веса хранятся в FP4, остальные тензоры — в другой точности, поэтому декодирование упирается не только в пропускную способность памяти, но и в выбор MoE-кернелов и межузловой обмен. B12X работает иначе, чем новый runtime: он поднимает SSE-производную частоту verification-шагов на 16–18%, но выходные токены за шаг снижает примерно на 2,5%. На 12 параллельных запросах суммарная скорость достигла 260 tok/s.
Явное включение MoE-бэкенда flashinfer_b12x подняло среднюю скорость с 59,7 до 67,6 tok/s.
Автор вынес отрицательные результаты и границы применимости в отдельные разделы, а в репозитории опубликовал рецепт запуска, харнессы, манифест с digest образа и сырые логи. Для практики важно, что метрика зависела от подсчёта: используется число completion_tokens из ответа API, а количество verification-шагов выводится из числа SSE-чанков, что проверено на контрольном запросе и не является задокументированным контрактом vLLM.
