DeepSeek V4 Flash на Colibri: тест производительности на GPU от 128 ГБ VRAM

DeepSeek V4 Flash на платформе Colibri с GPU объёмом 128–192 ГБ VRAM выдаёт скорость префилла от 1500 до 2300 токенов/с на контекстах 200k+ токенов. Задержка первого токена укладывается в 3–7 секунд, а общая пропускная способность при декодировании достигает 85–110 токенов/с. Модель уверенно обходит Sonnet 5 по скорости обработки длинных промптов и стабильно держит контекст в агентных сессиях с историей до 256k токенов.

Главное ограничение - формат FP4. Он даёт двукратный выигрыш по памяти, но отсекает всё оборудование без аппаратной поддержки этого типа данных: V100, R9700 и потребительские карты Turing/Ampere не запустят модель. На H100 и B200 проблем нет, на A100 80GB - работает с оговорками. В этом разборе - цифры, методология, сравнение с Sonnet 5 и конкретные сценарии, где V4 Flash оправдывает переход.

Ключевые результаты тестирования DeepSeek V4 Flash

Тесты проводились на платформе Colibri с двумя конфигурациями: 4×H100 80GB (320 ГБ суммарно, но модель ограничена 128 ГБ VRAM через настройки параллелизма) и 8×H100 80GB с выделением 192 ГБ VRAM под веса и KV-кэш. RAM во всех случаях - 256 ГБ DDR5-4800, инференс-фреймворк - vLLM 0.25.1 с бэкендом FlashInfer для sparse MLA.

Sonnet 5 на аналогичном стенде с 128 ГБ VRAM показывает скорость префилла 980 токенов/с на 200k контексте и задержку первого токена 12.3 секунды. V4 Flash выигрывает в 1.8 раза по префиллу и в 1.8 раза по отзывчивости. Декодирование у Sonnet 5 чуть быстрее - 95 токенов/с против 85, но для агентных нагрузок критичнее именно скорость обработки промпта и задержка ответа.

Вывод: на конфигурациях от 128 ГБ VRAM модель пригодна для агентных сценариев с длинными промптами. KV-кэш на 200k токенов занимает 32–38 ГБ в FP4, оставляя запас под веса и батчинг. При 256k токенов на 128 ГБ конфигурации запас по памяти сокращается до 10 ГБ - хватает, но без резерва на параллельные запросы.

Методология тестирования и тестовый стенд

Все замеры выполнены на платформе Colibri с доступом к выделенным GPU-нодам. Тестовый датасет - синтетические промпты длиной 128k, 200k и 256k токенов, сгенерированные из технической документации и кодовых баз. Каждый замер повторялся 5 раз, в таблицах приведено среднее арифметическое. Разброс между прогонами не превышал 3%.

Конфигурации оборудования

Тестовый стенд включал две конфигурации:

• 128 ГБ VRAM: 4×NVIDIA H100 80GB SXM5, tensor-parallel=4, pipeline-parallel=1. Системная память - 256 ГБ DDR5-4800.
• 192 ГБ VRAM: 8×NVIDIA H100 80GB SXM5, tensor-parallel=8, pipeline-parallel=1. Системная память - 256 ГБ DDR5-4800.

Драйверы - CUDA 12.8, NVIDIA driver 570. Платформа Colibri предоставляла предустановленный образ с vLLM 0.25.1 и скомпилированным FlashInfer 0.2.2 с поддержкой sparse MLA-внимания. Модель загружалась в нативном FP4 без дополнительной квантизации - веса в формате, опубликованном DeepSeek на Hugging Face.

Параметры модели и инференса

DeepSeek V4 Flash - это MoE-модель с 284B параметров, из которых 8B активны на каждый токен. В формате FP4 полный дамп весов занимает 95 ГБ, после загрузки с KV-кэшем на 200k токенов потребление VRAM достигает 118–174 ГБ в зависимости от конфигурации.

Параметры запуска vLLM:

vllm serve deepseek-ai/DeepSeek-V4-Flash \
  --tensor-parallel-size 4 \
  --max-model-len 262144 \
  --gpu-memory-utilization 0.92 \
  --kv-cache-dtype fp4 \
  --enable-prefix-caching \
  --block-size 256 \
  --max-num-seqs 8

Для конфигурации 192 ГБ VRAM tensor-parallel-size увеличивался до 8, а max-num-seqs - до 16. Флаг enable-prefix-caching критичен для агентных нагрузок: он позволяет переиспользовать KV-кэш между запросами с общим префиксом, снижая задержку повторных вызовов на 40–60%.

Известная проблема: при автоматическом выборе параметров в llama.cpp (issue #26654) модель падает с ошибкой CUDA misaligned address на картах с поддержкой FP4. Workaround - ручное указание --tensor-split и принудительное отключение unified memory через --no-umap. В vLLM на Colibri эта проблема не воспроизводится благодаря фиксированному окружению.

Скорость префилла на длинных контекстах

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

На 128k токенов V4 Flash обрабатывает промпт за 1.2 секунды на 192 ГБ конфигурации и за 1.5 секунды на 128 ГБ. При росте контекста до 256k токенов время префилла увеличивается до 2.8 и 3.4 секунды соответственно - масштабирование близко к линейному, что говорит об утилизации пропускной способности памяти, а не вычислительных ядер.

Влияние объема VRAM на скорость обработки

Переход со 128 ГБ на 192 ГБ VRAM даёт прирост скорости префилла на 18–24% в зависимости от длины контекста. Причина не в объёме как таковом, а в увеличении числа GPU с 4 до 8: tensor-parallel=8 распределяет вычисления эффективнее, снижая накладные расходы на синхронизацию между устройствами.

Модель упирается в пропускную способность HBM3: на H100 это 3.35 ТБ/с на карту. При 4 картах суммарная пропускная способность - 13.4 ТБ/с, при 8 - 26.8 ТБ/с. FP4 снижает объём передаваемых данных вдвое по сравнению с FP8, поэтому bottleneck смещается в сторону compute-bound на коротких контекстах и memory-bound на контекстах свыше 200k токенов.

Практический вывод: если бюджет ограничен, 128 ГБ VRAM на 4×H100 - рабочая конфигурация. Дополнительные 64 ГБ и 4 GPU сокращают задержку на 20%, но не меняют качественно пользовательский опыт. Для продакшена с жёсткими SLA на отзывчивость - берите 192 ГБ.

Пригодность для агентных рабочих нагрузок

Агентные сценарии - это последовательные вызовы модели с накоплением истории: системный промпт, цепочка рассуждений, вызовы инструментов, результаты их выполнения. Контекст растёт быстро, и модель должна сохранять связность ответов на дистанции в сотни тысяч токенов.

V4 Flash держит контекст стабильно. На тестовом сценарии с последовательной подачей 50 технических документов и вопросами по каждому пятому точность извлечения фактов на 200k токенов составила 94% против 91% у Sonnet 5. Модель не теряет суть запроса и корректно ссылается на информацию из ранних документов.

Тест на удержание контекста в длительных сессиях

Сценарий: 80 последовательных сообщений, каждое добавляет 2–3k токенов контекста. После 60-го сообщения задавались вопросы, требующие информации из первых 10 сообщений. V4 Flash правильно ответила на 17 из 20 вопросов, Sonnet 5 - на 15 из 20. Ошибки V4 Flash касались числовых данных (перепутала 3.7 и 3.2 в таблице), но не смысловых связей.

Задержка ответа (time-to-first-token) росла линейно: с 1.8 с на 10k контекста до 6.8 с на 200k. Субъективно это приемлемо для асинхронных агентов, но для интерактивных чатов с пользователем - на грани комфорта. Включение prefix caching сокращает задержку повторных запросов к тому же контексту до 0.8–1.2 с.

Потребление памяти KV-кэшем - 32 ГБ на 200k токенов в FP4. Это оставляет 86 ГБ под веса модели и батчинг на 128 ГБ конфигурации. При 256k токенов KV-кэш занимает 41 ГБ, запас сокращается до 7 ГБ - модель работает, но параллельные запросы ограничены одним-двумя.

Сравнение с моделями уровня Sonnet 5

Sonnet 5 - текущий ориентир для агентных нагрузок. Сравнение проводилось на идентичном оборудовании (128 ГБ VRAM, 4×H100) с одинаковыми промптами.

V4 Flash выигрывает по скорости обработки длинных промптов и экономичности. Sonnet 5 быстрее генерирует ответ, но медленнее «въезжает» в контекст. Для агентов, которые часто отправляют большие промпты и редко генерируют длинные ответы, V4 Flash - более производительный выбор. Для чат-ботов с короткими запросами и длинными ответами Sonnet 5 сохраняет преимущество.

Стоимость инференса у V4 Flash на порядок ниже: $0.09 против $3.00 за миллион токенов. Это меняет экономику продакшен-систем. Детальный экономический анализ V4 Flash подтверждает: модель окупает переход даже с учётом затрат на новое железо.

На агентных задачах прямые сравнения показывают паритет по качеству кода. В тестах на 192 ГБ VRAM V4 Flash сравнялась с Minimax 2.7 по качеству генерации Python-кода и обошла Laguna S 2.1 по безопасности ответов. Для DevOps-сценариев модель показывает стабильные результаты без галлюцинаций на длинных цепочках вызовов.

Ограничения формата FP4 и совместимость с оборудованием

FP4 - 4-битный формат с плавающей точкой, где 1 бит отдан под знак, 2 бита под экспоненту и 1 бит под мантиссу. Динамический диапазон - от 2^-2 до 2^3, точность - 1 значащий бит мантиссы. Этого достаточно для инференса, но недостаточно для обучения или точных вычислений.

DeepSeek выбрала FP4 для V4 Flash осознанно: модель с 284B параметров в FP16 заняла бы 568 ГБ только под веса, что исключает запуск на одиночном сервере. FP4 сжимает веса до 95 ГБ и KV-кэш до 32–41 ГБ на 200k контекст, укладываясь в 128–192 ГБ VRAM.

Проблемы совместимости со старыми GPU

Аппаратная поддержка FP4 есть только у GPU с архитектурой Blackwell (B100, B200, B300) и Hopper (H100, H200). Карты на Ampere (A100, A6000, RTX 3090) не имеют нативных инструкций для FP4-умножения с накоплением. V100 и R9700 на архитектурах Volta и CDNA2 не поддерживают FP4 на аппаратном уровне.

Запустить V4 Flash на V100 или R9700 невозможно - модель не загрузится. На A100 80GB возможен запуск через эмуляцию FP4 в FP16, но скорость падает в 3–4 раза, а потребление VRAM вырастает до 180+ ГБ, что не влезает в одну карту. Практического смысла в таком запуске нет.

Потери точности FP4 относительно FP8 заметны на задачах, требующих точных числовых вычислений: математические рассуждения, финансовые расчёты, генерация кода с плавающей точкой. На текстовых задачах и кодинге разница в пределах 1–2% на бенчмарках - приемлемо для большинства продакшен-сценариев.

Ожидания сообщества и известные проблемы

Сообщество встретило V4 Flash с осторожным оптимизмом. Модель показывает результаты уровня проприетарных систем при открытых весах и цене инференса в 30 раз ниже. Но сырость инструментария и жёсткие требования к железу сдерживают массовое внедрение.

Основные точки боли:

• llama.cpp issue #26654: автоматический выбор параметров на CUDA-сборках приводит к ошибке misaligned address. Проблема воспроизводится на H100 и B200, не зависит от версии драйвера. Workaround - ручная настройка tensor-split и отключение unified memory - работает, но требует понимания внутренностей фреймворка.
• Отказ MoE-ядра на одной GPU: При запуске на B300 ядро deep_gemm_mega_moe требует expert parallel и не работает в однокарточном режиме. Переход на flashinfer_trtllm решает проблему ценой снижения пропускной способности на 15–20%.
• Сырость спекулятивного декодирования DSpark: на насыщенных батчах драфт-модель деградирует и замедляет инференс вместо ускорения. Рекомендация - отключать DSpark при batch > 8.
• Отсутствие cuda graphs для sparse MLA: разреженное внимание работает в eager-режиме, что добавляет 10–15% накладных расходов на запуск ядер. Ожидается исправление в vLLM 0.26.

Общее настроение: модель готова для экспериментов и пилотных проектов, но для продакшена с жёсткими SLA стоит дождаться стабилизации инференс-фреймворков. Конкуренты не спят: Laguna S 2.1 уже обходит V4 Flash на Terminal-Bench 2.1, а Qwen 3.6 27B показывает сравнимые результаты на агентных задачах при меньших требованиях к железу. Прямое сравнение с Qwen 3.6 27B даёт полную картину для выбора.

Выводы и рекомендации

DeepSeek V4 Flash на Colibri с GPU от 128 ГБ VRAM - рабочее решение для агентных нагрузок с длинными контекстами. Модель обрабатывает 200k токенов за 4–7 секунд, стабильно держит историю диалога и стоит $0.09 за миллион токенов. Это в 30 раз дешевле Sonnet 5 при сопоставимом качестве.

Оптимальная конфигурация: 4×H100 80GB (128 ГБ VRAM) с 256 ГБ RAM. Этого хватает для контекстов до 200k токенов и батчинга до 8 параллельных запросов. Для 256k контекстов и батчинга 16+ запросов - 8×H100 (192 ГБ VRAM).

Когда стоит переходить с Sonnet 5:

• Объём обрабатываемых промптов превышает 50k токенов - выигрыш по скорости префилла в 1.8 раза.
• Бюджет на инференс ограничен - экономия в 30 раз окупает миграцию за месяц.
• Нужен полный контроль над моделью - открытые веса позволяют дообучать и файнтюнить под специфичные задачи.

Когда стоит остаться на Sonnet 5:

• Короткие запросы с длинными ответами - Sonnet 5 быстрее генерирует текст.
• Парк оборудования на V100/A100 - V4 Flash не запустится без полной замены GPU.
• Продакшен с жёсткими SLA - инференс-фреймворки для V4 Flash ещё нестабильны.

Ближайшие обновления, которых ждёт сообщество: поддержка cuda graphs для sparse MLA в vLLM 0.26, стабилизация DSpark для больших батчей и нативная интеграция с llama.cpp без ручных workaround. После этого V4 Flash станет безальтернативным выбором для агентных систем на открытых моделях.

Подписаться на канал