48 ГБ или две видеокарты по 24 ГБ для инференса?

Выбор здесь зависит не от суммы гигабайтов на коробках, а от того, как именно будет запущена модель. Одна карта на 48 ГБ дает модели один непрерывный бюджет памяти и не требует обмена между ускорителями. Две карты по 24 ГБ дают либо две независимые копии сервиса, либо один распределенный экземпляр с расходами на разделение модели и синхронизацию.

При равной цене я обычно выбираю 48 ГБ для одной крупной модели, длинного контекста и предсказуемой задержки. Две по 24 ГБ выигрывают, когда каждая рабочая модель помещается в 24 ГБ, а задача требует обслуживать больше независимых запросов, держать разные модели или разделять отказовые домены. Если модель не помещается в 24 ГБ, но помещается в 48 ГБ, пара карт остается рабочим вариантом, однако она уже платит за каждый сгенерированный токен обменом между устройствами.

Почему 24 плюс 24 не превращаются в одну память

У каждой видеокарты свой физический массив VRAM и свой адресный простор. CUDA может дать одной карте прямой доступ к памяти другой через peer-to-peer, а унифицированная виртуальная адресация упрощает работу с указателями. Это не создает общий 48-гигабайтный буфер, в который любой оператор модели положит тензор произвольного размера.

Разница проявляется еще при загрузке. Если один слой или временный рабочий буфер требует больше свободной памяти, чем есть на одной карте, наличие свободных гигабайтов на соседней карте само по себе не спасает процесс. Фреймворк должен уметь разрезать этот слой, разместить разные слои на разных устройствах или выгрузить часть данных в оперативную память. У каждого способа свои ограничения.

NVIDIA в CUDA Programming Guide описывает multi-GPU работу как отдельное управление устройствами, контекстами, распределением вычислений и обменом результатами. Там же peer access зависит от топологии PCIe или NVLink и проверяется для конкретной пары устройств. Практический вывод жесткий: считать можно совокупную емкость, но планировать нужно по самому тесному шарду.

Допустим, квантованные веса занимают 38 ГБ. На одной карте 48 ГБ после загрузки остается около 10 ГБ до учета служебной памяти. На двух картах удачный разрез положит примерно по 19 ГБ весов на каждую и оставит примерно по 5 ГБ. Неудачный разрез 22 ГБ плюс 16 ГБ оставит на первой карте всего около 2 ГБ. Процесс завершится по OOM на первой карте, хотя вторая еще показывает свободную память.

Поэтому фраза «совокупно 48 ГБ» описывает потолок распределенной конфигурации, но не обещает поведение одной 48-гигабайтной карты. Это разные ресурсы с одинаковой цифрой в счете.

Веса модели занимают только первую часть бюджета

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

Грубая нижняя оценка весов выглядит так:

BF16 или FP16: параметры × 2 байта
INT8:          параметры × 1 байт + масштабы и метаданные
4 бита:        параметры × 0,5 байта + масштабы, группы и служебные данные

Для модели на 32 миллиарда параметров чистые веса дают около 64 ГБ в BF16, 32 ГБ при 8-битном хранении и 16 ГБ при 4-битном. Последние две цифры нельзя принимать за итоговое потребление. Формат квантования хранит масштабы и иногда нулевые точки, отдельные слои могут оставаться в более высокой точности, а загрузчик создает буферы. Размер файла чекпойнта тоже не равен пику VRAM при запуске.

Второй крупный потребитель, KV-кеш. Авторегрессионная модель сохраняет ключи и значения внимания для уже обработанных токенов, чтобы не пересчитывать весь контекст при каждом следующем токене. Документация Transformers прямо предупреждает, что длинный контекст делает KV-кеш заметной частью памяти. Он растет с числом одновременных последовательностей и их длиной. Архитектура модели, число KV-голов и тип данных кеша меняют цену одного токена, поэтому универсального числа «гигабайт на 8K» нет.

Есть еще кратковременные пики. Оператор внимания, деквантование или выбор другого ядра могут запросить рабочую область именно тогда, когда монитор показывает почти заполненную карту. Надежная конфигурация не должна жить у отметки 100 процентов. Для первоначального расчета я оставляю 10-20 процентов на рантайм и пики, а затем заменяю этот запас измеренным значением. Это инженерный резерв, а не физическая константа.

vLLM по умолчанию сам определяет память для KV-кеша после загрузки модели и печатает его емкость в токенах вместе с оценкой максимальной конкуренции. Эти две строки полезнее, чем один снимок nvidia-smi: они показывают, сколько реальных последовательностей выдержит сервер при заданном max_model_len.

Какие классы моделей помещаются в каждый вариант

Одна карта на 48 ГБ и две по 24 ГБ способны держать похожие классы весов, но дают разный остаток под кеш и разные условия запуска. Нижняя таблица нужна для первичного отсева, а не для обещания совместимости конкретного чекпойнта.

В таблице намеренно нет названий моделей. Две модели с одинаковым заявленным числом параметров могут расходовать память по-разному из-за grouped-query attention, размера словаря, tied embeddings, локального внимания, mixture-of-experts и реализации квантования. У MoE-модели общее число параметров особенно легко вводит в заблуждение: на каждом токене активна часть экспертов, но веса всех размещенных экспертов все равно нужно где-то хранить.

Класс 70B в 4 битах показывает суть выбора лучше всего. Чистая арифметика обещает около 35 ГБ весов. Реальный формат может поднять объем заметно выше, а контекст и параллельные запросы потребуют оставшееся место. Одна 48-гигабайтная карта дает единый остаток. На паре по 24 ГБ каждый шард должен уложиться вместе со своей долей KV-кеша и временными буферами.

Для 32B в 4 битах одна карта 24 ГБ часто выглядит достаточной, но емкость сервиса может оказаться слабой: после весов остается мало места для длинных диалогов. В таком случае две карты можно использовать как две реплики короткого контекста или собрать один распределенный экземпляр с более крупным общим кешем. Выбор зависит от профиля очереди, а не от имени модели.

Способ разделения модели меняет результат

Чтобы одна модель использовала две карты, рантайм должен применить тензорный параллелизм, конвейерный параллелизм или простое размещение слоев по устройствам. Эти режимы решают разные задачи и создают разный трафик.

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

При конвейерном параллелизме одна карта хранит ранние слои, другая поздние. Активации переходят через границу между стадиями. Обмен может быть реже и компактнее, но дисбаланс слоев оставит одну карту переполненной, пока вторая простаивает. Для одиночного авторегрессионного запроса конвейер также не превращает две карты в удвоенную вычислительную мощность: стадии зависят друг от друга.

Простое device_map="auto" в Transformers умеет разложить веса по доступным устройствам и при нехватке места продолжить размещение на CPU или диске. Это хороший способ запустить модель для проверки, но не доказательство хорошего продакшен-инференса. Передача слоев через системную память может резко увеличить задержку, даже если OOM исчез.

Документация vLLM формулирует разумное правило: если модель помещается на одной карте, распределенный инференс обычно не нужен; если не помещается, но входит в один узел с несколькими GPU, применяют tensor parallel. Та же документация советует рассмотреть pipeline parallel при отсутствии NVLink и неудобном делении модели, потому что он может снизить коммуникационные расходы. Я согласен с направлением, но не принимаю его как замену тесту: конкретная архитектура и размер батча легко меняют победителя.

Data parallel решает другую задачу. Каждая карта хранит полную копию модели и независимо обрабатывает запросы. Память не складывается вообще, зато при достаточной очереди совокупная пропускная способность приближается к сумме двух реплик. Для модели, которая уверенно помещается в 24 ГБ, это часто лучший способ использовать вторую карту.

Межсоединение определяет штраф двух карт

Скорость обмена между картами зависит от того, есть ли прямой peer-to-peer доступ, через какие PCIe-мосты идет путь и поддерживает ли конкретная пара NVLink. Название двух одинаковых GPU ничего не говорит о топологии готового сервера. Слоты могут висеть на разных CPU-сокетах, BIOS может менять режимы, а виртуализация может закрыть прямой доступ.

Проверку нужно делать на собранной машине:

nvidia-smi topo -m
nvidia-smi topo -p2p r
nvidia-smi topo -p2p w

Матрица topo -m показывает строки и столбцы GPU0, GPU1 и тип пути между ними. В документации NVIDIA обозначение PIX означает путь максимум через один PCIe-мост, PHB проходит через PCIe host bridge, SYS также пересекает межсокетное соединение, а NV# указывает набор NVLink. Команды topo -p2p отдельно показывают возможность прямого чтения и записи.

        GPU0  GPU1  CPU Affinity
GPU0     X    PHB   0-15
GPU1    PHB    X    0-15

Такой вывод не измеряет фактическую полосу, он описывает маршрут. После него нужен тест NCCL или nvbandwidth на той же ОС, с тем же драйвером, контейнером и настройками IOMMU, которые будут в эксплуатации. NVIDIA DCGM также имеет PCIe-тест, который проверяет P2P, ошибки, повторы и измеряет обмен GPU с GPU и host.

На PCIe тензорный параллелизм может работать вполне приемлемо для больших батчей, где вычисления перекрывают часть обмена. При интерактивной генерации с маленьким батчем синхронизация на каждом токене виднее в задержке. NVLink уменьшает штраф, но не делает распределенный запуск бесплатным. Если карты вообще не поддерживают прямой P2P, данные могут ходить через память CPU, и тогда одна карта на 48 ГБ обычно выглядит еще привлекательнее.

Задержка и пропускная способность требуют разных покупок

Одна 48-гигабайтная карта обычно дает лучшую задержку одного запроса, если сравниваемые ускорители близки по вычислительной производительности и пропускной способности собственной памяти. Весь проход модели остается на одном устройстве, коллективных операций нет, а планировщику проще использовать свободный остаток VRAM.

Две карты по 24 ГБ могут дать больше запросов в секунду двумя способами. Если модель помещается на каждой, две реплики обслуживают разные запросы без межкарточного трафика. Если модель разделена, общий объем вычислений выше, но прирост зависит от батча и скорости обмена. Для одного пользователя tensor parallel иногда ускоряет крупную модель, иногда почти не меняет скорость, а на слабой топологии замедляет ее.

Нужно различать три метрики:

• TTFT, время до первого токена, сильно зависит от длины входа и prefill;
• TPOT, время на каждый следующий токен, показывает интерактивную скорость декодирования;
• общая пропускная способность в токенах или запросах за секунду при целевой конкуренции.

Покупка под чат с жестким пределом задержки и покупка под ночную пакетную обработку редко совпадают. Для чата важны p95 TTFT и TPOT при реальной очереди. Для пакетной работы допустима более высокая задержка отдельного задания, если две карты держат крупный батч и заканчивают весь набор раньше.

Есть еще отказоустойчивость. Отказ одной карты в тензорно-параллельной паре останавливает весь экземпляр модели. Две независимые реплики на 24 ГБ позволяют вывести одну из обслуживания, сохранив часть мощности. Одна карта на 48 ГБ проще, но это один ускоритель и один экземпляр. Этот риск нужно закрывать уровнем узлов, а не фантазией о том, что две карты внутри одного процесса уже дали резервирование.

Одна карта на 48 ГБ выигрывает у сложной пары

Выбирайте 48 ГБ, если рабочий чекпойнт вместе с нужным контекстом помещается на нее, а на 24 ГБ не помещается. Это самый чистый случай: вы избегаете шардирования, межкарточного обмена и отдельного класса ошибок распределенного рантайма.

Одна карта также разумнее при следующих условиях:

• интерактивный сервис работает с batch size 1 или небольшой конкуренцией;
• нужен длинный контекст и большой единый резерв под KV-кеш;
• используемый фреймворк плохо поддерживает multi-GPU для выбранной архитектуры или квантования;
• сервер имеет слабую PCIe-топологию либо прямой P2P недоступен;
• команда хочет проще обновлять модель, профилировать OOM и повторять окружение.

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

48 ГБ также оставляет свободу сменить квантование ради качества. Модель, едва помещающаяся на 24 ГБ в агрессивных 4 битах, может войти в 48 ГБ в 8 битах или с большим числом слоев в BF16. Улучшение качества не гарантировано для любой модели и задачи, поэтому его проверяют на своем наборе, но аппаратный запас дает возможность провести такой тест.

Аргумент против одной большой карты, цена простоя. Если сервис ночью почти пуст, вторая независимая 24-гигабайтная карта могла бы выполнять другую модель, эмбеддинги, распознавание или пакетную задачу. На 48 ГБ все это тоже можно совмещать, но конкурирующие процессы делят один ускоритель и могут мешать задержке основного сервиса.

Две карты по 24 ГБ выгоднее при правильной очереди

Пара по 24 ГБ выигрывает, когда каждая модель уже помещается на одну карту. Тогда не надо складывать память: запускаются две реплики, а балансировщик раздает им независимые запросы. Для 7-8B в BF16, 13-14B в INT8 и многих 30-32B в 4 битах это практичный вариант после проверки остатка под кеш.

Две карты удобнее и для нескольких моделей. Например, одна обслуживает генерацию, другая держит модель эмбеддингов или отдельную специализированную LLM. Переключение не требует выгружать десятки гигабайтов весов перед каждым типом запроса. Изоляция памяти также делает поведение понятнее, хотя общие CPU, RAM и PCIe все равно могут стать узким местом.

Есть финансовая оговорка. Равная закупочная цена не означает равную стоимость узла. Две карты занимают больше PCIe-слотов, требуют подходящих линий PCIe, иногда более мощного CPU, больше кабелей питания и охлаждения. Блок питания должен выдерживать не среднее, а пики обеих карт. Корпус обязан подавать воздух к соседним ускорителям без теплового удушения.

Лицензии и сопровождение тоже могут считать GPU, сокеты или экземпляры. Я не закладываю эти расходы по памяти: их нужно запросить для выбранного стека. Зато две распространенные 24-гигабайтные карты иногда проще заменить по отдельности, чем одну специализированную 48-гигабайтную. Это зависит от реальной доступности и условий поставки, поэтому прайс-лист без сроков поставки мало что решает.

Распределенная 70B в 4 битах остается веской причиной купить две по 24 ГБ, если одной 48-гигабайтной конфигурации нет или две карты заметно быстрее в вашем батче. Но считать такую пару эквивалентом одной карты нельзя. Сначала проверяют баланс памяти по рангам, затем TTFT, TPOT, throughput, энергопотребление узла и поведение при длинном контексте.

Тестовый прогон должен повторять продакшен

Решение о закупке стоит принимать по одному и тому же чекпойнту, движку, типу квантования и набору запросов на обеих конфигурациях. Синтетический вывод 20 токенов из короткого prompt скрывает и KV-кеш, и очередь, и тепловой режим.

Я использую такой порядок проверки:

1. Загрузить точную сборку модели и зафиксировать версии драйвера, CUDA, движка и квантовщика.
2. Прогнать короткий, медианный и предельный контекст при целевой конкуренции, записать p50 и p95 для TTFT и TPOT.
3. Увеличивать число одновременных запросов до целевого уровня, наблюдая емкость KV-кеша, preemption и OOM отдельно по каждой карте.
4. Повторить длительный прогон, чтобы увидеть троттлинг, потребление узла и устойчивость очереди.
5. Для двух карт повторить тест с tensor parallel, pipeline parallel и двумя репликами там, где режимы применимы.

При запуске vLLM полезно сохранить начальные строки вида:

GPU KV cache size: 643,232 tokens
Maximum concurrency for 40,960 tokens per request: 15.70x

Это пример формы вывода из документации vLLM, а не обещание результата вашей машины. Сопоставьте расчетную конкуренцию с фактической: длинные и короткие запросы перемешиваются, scheduler расходует блоки кеша не так, как идеально ровный тест. Если используете статический кеш, учтите, что Transformers заранее резервирует максимум и может тратить память на замаскированные позиции. Если выгружаете кеш на CPU, документация предупреждает о снижении пропускной способности из-за пересылок.

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

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

При равной цене решает режим эксплуатации

Если один экземпляр модели требует больше 24 ГБ, но уверенно укладывается в 48 ГБ вместе с кешем, берите одну карту на 48 ГБ. Она убирает коммуникационный штраф и оставляет единый запас памяти. Для интерактивного инференса это мой выбор по умолчанию.

Если модель помещается в 24 ГБ, а очередь достаточно велика, две карты выгоднее запускать как две реплики. Так вы получаете дополнительную пропускную способность без tensor parallel и можете обслуживать часть трафика при остановке одной реплики. Если нужны разные модели одновременно, аргумент в пользу пары становится еще сильнее.

Если 70B в 4 битах требует совокупные 48 ГБ, ответ нельзя получить из спецификации. На одной карте проверьте реальный остаток под KV-кеш. На двух проверьте равномерность шардов и топологию, затем сравните p95 задержки и throughput. Побеждает конфигурация, которая выдерживает ваш максимальный контекст и очередь без OOM, троттлинга и пересылок через CPU.

Есть полезная граница для пересмотра решения. Если после загрузки весов под кеш остается меньше объема, который нужен целевой очереди, переходите к следующему классу памяти, даже когда одиночный тест проходит. Уменьшение max_model_len или числа запросов ради прохождения демонстрации маскирует нехватку ресурса. Сервер покупают под верхнюю рабочую нагрузку, а не под самый удобный prompt. Точно так же не приписывайте двум картам ускорение заранее: если GPU большую часть времени ждут коллективную операцию, дополнительная вычислительная мощность не превращается в полезные токены.

Не покупайте память вплотную под файл весов. Зафиксируйте допустимый тип квантования, длину контекста, число параллельных запросов и предел задержки, а уже затем назначайте VRAM. У двух карт память складывается только в том смысле, который умеет реализовать выбранный движок. Одна карта на 48 ГБ дает эту емкость без оговорки.