Сколько VRAM нужно для локального запуска DSV4 Flash: 3 GPU в бюджете $15 000

Для локального запуска DSV4 Flash без агрессивной квантизации нужен ориентир минимум 128 ГБ VRAM суммарно на все видеокарты. Если держать модель в BF16 или FP16, не резать контекст до нескольких тысяч токенов и не экономить на качестве, меньше 128 ГБ почти гарантированно упрётся в нехватку памяти под веса модели плюс KV-кэш.

Под сценарий «один активный пользователь и ещё двое-трое подключаются время от времени, 40-50+ токенов/с на генерации и не меньше 1000 токенов/с на prefill» в бюджете около $15 000 и в трёх слотах Dell R740 проходят две конфигурации: 3x AMD Instinct MI210 (192 ГБ HBM2e суммарно) и 3x NVIDIA A40 (144 ГБ GDDR6). Обе выше порога 128 ГБ, но с разным запасом: MI210 даёт плюс 64 ГБ и заметно более высокую пропускную способность памяти, A40 даёт CUDA и зрелую экосистему.

Оговорка, которую нельзя опускать: публичных замеров DSV4 Flash, Qwen3.8-Flash-Next и близких моделей именно на MI210 и A40 в открытых источниках нет. Дальше идёт расчётная логика, спецификации карт и практические развилки. Конкретные токены в секунду придётся снимать на своей сборке.

Короткий ответ: сколько VRAM нужно для DSV4 Flash и почему 128 ГБ - это минимум

128 ГБ VRAM - рабочая нижняя граница для модели класса DSV4 Flash, если не уходить в агрессивную квантизацию. Это не измеренное требование конкретной модели, а результат расчёта: веса в BF16 или FP16, KV-кэш под умеренный контекст на одного-трёх пользователей и служебный оверхед движка.

3x AMD MI210 дают 192 ГБ HBM2e и проходят порог с запасом. 3x NVIDIA A40 дают 144 ГБ GDDR6 и проходят его впритык. Разница в 48 ГБ - это либо более длинный контекст, либо больше параллельных сессий, либо менее жёсткая квантизация. Дальше разберу, откуда берётся цифра, чем prefill отличается от генерации и какие компромиссы тянут за собой обе конфигурации.

Из чего складывается VRAM: веса, KV-кэш и оверхед

Реальный объём памяти считается по трём слагаемым:

VRAM ≈ вес модели в выбранной точности + KV-кэш + оверхед 10-20%

Слагаемое первое - веса. Объём под них равен числу параметров, умноженному на число байт на параметр. Точность задаёт множитель:

Если модель смесь экспертов (MoE), в память грузятся все эксперты, а не только те, что активны на конкретном токене. Число активных параметров влияет на скорость, число общих - на память. Для DSV4 Flash стоит отдельно уточнить по карточке модели, сколько там общих и сколько активных параметров, потому что разница может измеряться в разы.

Слагаемое второе - KV-кэш, кэш ключей и значений внимания. Он растёт линейно и с длиной контекста, и с числом одновременных запросов:

KV-кэш = 2 × слои × KV-голов × head_dim × длина контекста × байт на элемент × batch

Множитель 2 стоит потому, что хранятся и K, и V. Групповое внимание (GQA) сокращает число KV-голов относительно числа голов запросов, и это хорошо экономит память. Условный пример: 64 слоя, 8 KV-голов, head_dim 128, BF16 (2 байта). На один токен уходит 2 × 8 × 128 × 2 = 4096 байт на слой, то есть около 256 КБ на все 64 слоя. Контекст 32 000 токенов для одной сессии съест примерно 8 ГБ. Четыре одновременные сессии с таким же контекстом - уже около 32 ГБ только под KV.

Слагаемое третье - оверхед: активации, буферы движка, фрагментация памяти, рабочие копии при загрузке весов. На практике к сумме стоит добавлять ещё 10-20%. У vLLM и llama.cpp профиль памяти разный, PagedAttention в vLLM снижает фрагментацию, но не убирает её совсем.

Если модель весит 60-120 ГБ в BF16, плюс десятки гигабайт KV-кэша, плюс оверхед, суммарный порог и упирается в 128 ГБ. Та же арифметика на другом железе разобрана в материале про 2× Radeon AI PRO R9700: там видно, как KV-кэш и tiered expert offload меняют требования к памяти сильнее, чем кажется по числу параметров.

Почему без сильной квантизации порог - 128 ГБ

Логика простая. В BF16 байт на параметр - два, и модель на десятки миллиардов параметров занимает десятки гигабайт только под веса. Добавьте KV-кэш под контекст 32k-128k и 2-3 параллельные сессии, добавьте оверхед. 128 ГБ оказываются той точкой, где ещё можно держать приличную точность и рабочий контекст.

Что получится, если взять меньше:

• 48-64 ГБ суммарно - придётся резать контекст до нескольких тысяч токенов или уходить в 4-bit, что для длинных промптов и агентных сценариев заметно по качеству.
• 96 ГБ - влезает модель в 4-5 bit с умеренным контекстом, но параллельные запросы почти сразу упираются в потолок.
• 144 ГБ (3x A40) - модель в BF16 или 8-bit с запасом на короткие пики, длинный контекст требует осторожности.
• 192 ГБ (3x MI210) - запас на длинный контекст, больше одновременных сессий и менее болезненную квантизацию.

128 ГБ - ориентир для конкретного сценария, а не универсальное правило. Модель поменьше или агрессивная квантизация легко опускают планку до 48-64 ГБ. Модель побольше и контекст 128k поднимают её до 160-200 ГБ.

Prefill, генерация и параллельные запросы: что реально нагружает GPU

Целевые 1000 токенов/с на prefill и 40-50+ токенов/с на генерации - две разные задачи, которые упираются в разные ресурсы карты. Их нельзя оценить одной цифрой FLOPS или одним объёмом памяти.

Почему prefill и generation упираются в разные ресурсы

Prefill - это обработка всего промпта сразу. Промпт длиной 10 000 токенов превращается в крупные матричные умножения, которые хорошо ложатся на тензорные ядра и параллелятся почти идеально. Здесь решают вычислительные блоки (FLOPS в FP16/BF16), пропускная способность памяти и то, насколько быстро GPU обмениваются промежуточными результатами при многокарточной раскладке. Целевые 1000 токенов/с на prefill при умеренном контексте без tensor parallelism на нескольких картах получить трудно.

Генерация работает иначе. Каждый новый токен требует прочитать из памяти все веса модели и KV-кэш. Умножений здесь мало, почти вся работа - это чтение из памяти, поэтому генерация упирается в пропускную способность памяти, а не в FLOPS. Отсюда прямая связь: HBM2e у MI210 с пропускной способностью около 1,6 ТБ/с и GDDR6 у A40 примерно на уровне 0,7 ТБ/с различаются в этом месте больше чем вдвое. Для генерации токенов это преимущество MI210 при прочих равных.

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

Как параллельные запросы 2-3 пользователей меняют требования

Каждая активная сессия держит собственный KV-кэш, поэтому память под KV растёт примерно линейно от числа одновременных запросов. Двое-трое одновременно работающих людей на контексте 32k легко добавляют 16-32 ГБ к базовому расходу.

Движки с continuous batching (vLLM, SGLang) собирают запросы разных пользователей в один батч на каждом шаге. Это поднимает суммарный throughput и загрузку GPU, но меняет профиль задержки: пока один пользователь ждёт ответа, батч может быть занят токенами другого. Time to first token у отдельного запроса растёт вместе с размером батча.

Для сценария «один активный пользователь и двое-трое подключаются время от времени» три карты с 144-192 ГБ выглядят рабоче. Пиковую одновременность надо закладывать заранее: если три человека запустят длинные агентные задачи с контекстом по 64k в один момент, запас памяти может кончиться, и движок начнёт вытеснять запросы в очередь. Ограничение по максимальному числу одновременных последовательностей (--max-num-seqs в vLLM) - это как раз ручка для такого случая.

3x AMD MI210 против 3x NVIDIA A40: сравнение по ключевым параметрам

Обе карты серверные, обе пассивные, обе рассчитаны на продув в стойке. Различия в архитектуре, объёме и типе памяти, а также в софте.

Отдельный момент по форматам: аппаратной поддержки FP8 нет ни у MI210, ни у A40, этот формат появился в более поздних поколениях. Если в вашем стеке нужен именно FP8, его придётся эмулировать программно, с потерей скорости.

VRAM и пропускная способность: где MI210 выигрывает

64 ГБ HBM2e на карту против 48 ГБ GDDR6 дают 192 ГБ против 144 ГБ на трёх картах. Для моделей класса Flash с большим KV-кэшем разница ощутима: на 192 ГБ можно держать более длинный контекст или больше одновременных сессий без перехода на 4-bit.

Пропускная способность HBM2e примерно вдвое выше GDDR6. Генерация токенов упирается именно в неё, поэтому MI210 должна выдавать заметно больше токенов в секунду на том же движке и той же модели, чем A40 при равных условиях. Насколько именно, зависит от движка, квантизации и реализации ядер, так что без замера на конкретной сборке это остаётся оценкой, а не гарантией.

Обратная сторона: если модель укладывается в 144 ГБ, избыток памяти MI210 не даёт ничего, и всё решает софт. Запас в 48 ГБ начинает работать тогда, когда хочется длинный контекст, больше параллельных запросов или менее жёсткую квантизацию.

CUDA против ROCm: что важнее для локального инференса

CUDA - это зрелая экосистема. vLLM, llama.cpp, SGLang, TensorRT-LLM, ExLlama и почти все готовые сборки под многокарточные конфигурации исторически отлажены в первую очередь под NVIDIA. A40 работает в этой среде без сюрпризов.

ROCm заметно выросла, и MI210 (архитектура gfx90a) входит в список поддерживаемых карт. PyTorch, vLLM и llama.cpp собираются под ROCm. Но версии драйверов, прошивок и библиотек нужно подбирать под связку GPU плюс ОС, часть квантизаций отсутствует или работает медленнее, а ядра внимания вроде FlashAttention сделаны через другие библиотеки. Под DSV4 Flash и Qwen3.8-Flash-Next поддержку в вашей версии ROCm и в вашей сборке vLLM нужно проверять отдельно, до покупки карт.

Ключевой компромисс формулируется так: A40 даёт предсказуемость софта и меньше отладки, MI210 даёт больше памяти и пропускной способности, но требует готовности разбираться с ROCm. Если CUDA в приоритете, выбор падает на A40. Если в приоритете VRAM и скорость генерации, это MI210.

Энергопотребление, охлаждение и совместимость с Dell R740

Две карты по 300 Вт - это 600 Вт только на GPU, три - около 900 Вт плюс процессоры, память и диски. В R740 это требует мощных блоков питания: конфигурация с 2 x 1600 Вт или 2 x 2000 Вт с резервированием. Со стандартными 750-1100 Вт три такие карты под полной нагрузкой, скорее всего, не поедут.

Второй момент, который часто упускают: R740 - платформа PCIe 3.0. При tensor parallelism карты постоянно обмениваются активациями, и пропускная способность шины напрямую влияет на эффективность распараллеливания. На PCIe 3.0 x16 это около 16 ГБ/с в каждую сторону, и для 3-way TP обмен может стать узким местом. A40 не имеет NVLink, поэтому внутри R740 интерконнекта между картами не будет вообще, только PCIe.

Физически R740 рассчитан на три двухслотовые GPU при наличии GPU-кита: подходящие райзеры и кабели питания входят в комплект. MI210 и A40 - пассивные двухслотовые карты, что для 2U-сервера плюс: охлаждение идёт от серверных вентиляторов, а не от собственных турбин. Длину карт, высоту и совместимость с конкретной ревизией R740 стоит сверять по документации Dell и по списку поддерживаемых ускорителей, потому что сервер вышел задолго до этих карт.

Практический опыт установки трёх Instinct в R740 и подводные камни охлаждения в 2U разобран в статье про сборку на AMD Instinct V620. Там же видно, что ROCm в таком шасси работает, но требует внимания к продуву и питанию.

Уместится ли конфигурация в бюджет $15 000: считаем реальные расходы

$15 000 на три карты - это около $5000 за штуку. Такая сумма реалистична для вторичного рынка, но сильно зависит от региона, состояния карт, продавца и момента покупки. Конкретных цен здесь не привожу: они меняются быстрее, чем живёт статья.

Что нужно учесть помимо стоимости самих GPU:

• GPU-кит для R740, если его нет: райзеры нужной длины и высоты, кабели питания GPU, иногда крепёж.
• Блоки питания нужной мощности, если в сервере стоят слабые.
• Память DDR4 ECC и NVMe под модели и кэш: модели класса Flash занимают десятки гигабайт, быстрый диск экономит время на загрузке.
• Обслуживание карт: термопрокладки, термопаста, чистка радиаторов, если карты б/у.
• Резерв на одну карту: если одна из трёх окажется проблемной, замена съест бюджет.

Скрытые расходы: питание, охлаждение, райзеры

Питание - главный риск. Три карты по 300 Вт требуют согласованных кабелей и достаточной мощности БП, а в R740 разводка питания GPU идёт через специальный комплект. Без GPU-кита сервер не собрать: обычные кабели от настольного БП туда не подходят.

Охлаждение в 2U рассчитано на мощный продув, но три пассивные карты по 300 Вт в сумме дают почти киловатт тепла. Вентиляторы R740 под нагрузкой шумят сильно, и это стоит учитывать, если сервер стоит не в отдельной комнате. Ещё один момент - температура памяти HBM у MI210 и её состояние у б/у карт после нескольких лет в дата-центре.

Райзеры и геометрия: не каждая карта встанет в конкретный слот R740 из-за длины и расположения райзера. Проверять это надо до покупки, по мануалу и отзывам владельцев.

Что делать, если $15 000 не хватает

Вариантов несколько, у каждого своя цена:

• Взять две карты вместо трёх и уйти в более сильную квантизацию. Памяти меньше, качество ниже, но бюджет сходится.
• Подождать снижения цен на вторичном рынке. MI210 и A40 - карты не новые, их предложение со временем растёт.
• Посмотреть на другие 3-GPU конфигурации. Разбор 3x RX 9060 XT против 3x RTX 5060 Ti показывает, что три потребительские карты дают 48 ГБ за куда меньшие деньги, но этого мало под модель класса Flash.
• Арендовать GPU в облаке, чтобы снять замеры до покупки. Если арендовать не получается, остаётся расчёт плюс тесты на одной карте.

RTX 4090 и RTX 3090 в R740 в тройном комплекте почти не встречаются: у них активное охлаждение и другой профиль питания, а сервер рассчитан на пассивные карты. Сравнение потребительских флагманов с рабочими станционными картами по VRAM и цене за гигабайт есть в материале RTX 5090 против рабочих станционных карт.

Софт-стек для 3 GPU: vLLM, llama.cpp, SGLang и параллелизм

Выбор движка на трёх картах важнее, чем кажется: он решает, получите вы свои 1000 токенов/с на prefill или упрётесь в обмен по PCIe.

vLLM - основной вариант для многопользовательского сценария. Continuous batching, PagedAttention, tensor parallelism и OpenAI-совместимый API из коробки. Для целевых 40-50+ токенов/с на генерации и параллельных запросов это самый предсказуемый путь.

llama.cpp проще: один бинарник, GGUF-квантизации, легко поднимается на одной машине. На multi-GPU он умеет раскладывать слои по картам, но по эффективности использования нескольких GPU и по batch-throughput уступает vLLM. Для одного пользователя с периодическими подключениями этого хватает, для стабильных 1000 токенов/с на prefill - вряд ли.

SGLang силён там, где есть сложные пайплайны, структурированный вывод, кэш префиксов (RadixAttention) и агентные цепочки. Если DSV4 Flash планируется использовать с агентами, RAG и частыми повторяющимися префиксами, SGLang даёт заметную экономию на prefill.

Tensor parallelism на 3 GPU: как это работает и где узкие места

Tensor parallelism (TP) режет внутри одного слоя матрицы весов между картами. На каждом шаге карты обмениваются частичными результатами, поэтому TP чувствителен к скорости интерконнекта. Pipeline parallelism (PP) режет модель по слоям: карта A считает первые слои, карта B - следующие. Обмен между картами меньше, но появляются простои конвейера и растёт задержка ответа.

Число карт при TP должно делить размерности модели: число голов внимания и промежуточный размер MLP. Тройка тут неудобна, потому что 3 - простое число, а модели обычно рассчитаны на 2, 4 или 8 карт. Если голов 32, TP=3 даст дробное число голов на карту, и vLLM такую конфигурацию не примет. Придётся либо использовать TP=2 и грузить третью карту иначе, либо комбинировать TP с PP, либо брать модель, чьи размерности делятся на 3. Это надо проверить по конфигу модели до покупки железа.

Отдельно стоит учесть PCIe 3.0 в R740: при TP обмен идёт постоянно, и на медленной шине эффективность трёх карт может оказаться ниже, чем ожидается по сумме их вычислительных мощностей.

ROCm на MI210: что работает, а что нет

MI210 относится к архитектуре gfx90a, которая входит в официальный список поддержки ROCm. PyTorch собирается под ROCm, vLLM имеет ROCm-сборки, llama.cpp поддерживает HIP-бэкенд. Базовый запуск модели на трёх MI210 реален.

Ограничения начинаются в деталях:

• Версии ROCm, драйвера и прошивки нужно согласовывать между собой и с ОС; несовпадение ломает запуск.
• Часть квантизаций и ядер внимания сделана иначе или отсутствует. Конкретные схемы вроде MXFP4 могут быть недоступны без пересборки.
• Поддержка новых моделей в ROCm-ветках библиотек обычно появляется позже, чем в CUDA-ветках.
• Многокарточные сценарии на ROCm требуют проверки на месте: то, что работает на одной карте, не гарантирует работу на трёх.

Для A40 таких вопросов нет: CUDA-стек поддерживает всё перечисленное, вопрос только в том, хватит ли 144 ГБ.

Как проверить конфигурацию, если нет публичных замеров и облака

Публичных бенчмарков DSV4 Flash на MI210 и A40 нет, арендовать карты не удалось. Значит, работает расчёт плюс локальная проверка. План выглядит так:

1. Выписать из карточки модели или конфига точные параметры: число параметров (общих и активных), слои, число голов внимания и KV-голов, head_dim, максимальный контекст, поддерживаемые типы данных.
2. Посчитать VRAM по формуле из первого раздела. Получить три числа: минимальный, комфортный и максимальный контекст, который влезает в 144 и 192 ГБ.
3. Проверить, поддерживает ли выбранная версия vLLM, llama.cpp или SGLang эту архитектуру. Отдельно на CUDA и на ROCm.
4. Найти владельцев MI210 и A40, которые гоняли на них LLM, и попросить замеры prefill и generation на сопоставимых промптах.
5. Если есть хоть какая-то возможность арендовать одну карту, снять метрики хотя бы на одной модели.
6. Купить одну карту, протестировать, и только потом докупать остальные.

Какие метрики снимать и чем

Набор минимальный, но без него разговор бессмысленный:

• TTFT (время до первого токена) на промптах разной длины: короткий, средний, длинный.
• Скорость prefill в токенах/с на контексте 4k, 16k, 32k.
• Скорость генерации в токенах/с для одного запроса и для батча из 2-4.
• Пиковое потребление VRAM при разных длинах контекста и разных значениях --max-num-seqs.
• Утилизация GPU и температура памяти под нагрузкой.

Инструменты: llama-bench для llama.cpp, встроенный бенчмарк vLLM (benchmark_serving) и её логи, для памяти - nvidia-smi и rocm-smi. Обязательно фиксируйте версии драйвера, ROCm или CUDA, движка и модели: без этого результаты не воспроизвести и не сравнить.

Как снизить риск покупки без тестов

Главное правило - не покупать три карты сразу. Одна карта, стресс-тест, замеры, и только потом остальные. Если продавец не даёт проверить карту или вернуть её, риск растёт многократно.

Прогоните карту через стресс-тест памяти и длительную нагрузку, проверьте ECC, температуру HBM и поведение под продувом в вашем шасси. Карты из дата-центров обычно в лучшем состоянии, чем майнинговые, но гарантий нет.

Чек-лист проверки лота на вторичном рынке, включая питание, охлаждение, доставку и возврат, собран в материале как выбрать видеокарту для локальных LLM. Логика та же, только бюджет и класс карт другие.

И отдельно: если CUDA критична для ваших задач, не берите MI210 без возможности вернуть. Если критична память и пропускная способность, а с ROCm вы готовы возиться, MI210 может оказаться единственным вариантом, который влезает в бюджет.

Итог: что выбрать под DSV4 Flash на 3 GPU в $15 000

Сводка по сценарию:

• Минимум по памяти - 128 ГБ VRAM. Обе конфигурации его проходят: 3x MI210 дают 192 ГБ, 3x A40 дают 144 ГБ.
• Генерация токенов упирается в пропускную способность памяти. Здесь MI210 примерно вдвое быстрее на бумаге за счёт HBM2e.
• Prefill упирается в вычислительные блоки и интерконнект. На PCIe 3.0 в R740 три карты в режиме tensor parallelism будут ограничены шиной, и A40 с MI210 тут в равном положении.
• Софт: A40 даёт CUDA, всё работает из коробки. MI210 требует возни с ROCm и проверки поддержки конкретной модели и квантизации.
• Физика: R740 держит три пассивные двухслотовые карты, но требует мощных БП и GPU-кита. PCIe 3.0 и отсутствие NVLink у A40 - реальные ограничения.
• 3 GPU и tensor parallelism - неудобная связка, потому что размерности моделей редко делятся на 3. Проверяйте конфиг модели до покупки.

Если расставить приоритеты: CUDA, предсказуемость и минимум отладки - берите 3x A40 и держите контекст и число одновременных сессий в разумных пределах. VRAM, пропускная способность памяти и готовность работать с ROCm - берите 3x MI210.

Ни один из вариантов нельзя назвать гарантированно правильным без замеров именно на вашей модели и вашем движке. Публичных цифр по DSV4 Flash на этих картах нет, поэтому решение стоит принимать после проверки на одной карте, с расчётом VRAM по формуле и с планом на откат, если результат не устроит.

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