Москва, ул. Пришвина, д.8, корп.2
На тестовом стенде вопрос выбора GPU часто кажется второстепенным. Команда выбирает LLM, собирает RAG-систему или пробует запустить собственный AI-сервис. Модель отвечает, идея работает. Но как только сервис нужно переносить в рабочую среду, довольно быстро возникает следующий вопрос: на какой GPU всё это ставить?
В характеристиках видеокарт десятки параметров, модели отличаются по цене и поколению, а самый понятный ориентир лежит на поверхности: объём видеопамяти. Кажется, что достаточно выяснить, сколько памяти занимает модель, добавить небольшой запас и выбрать подходящую GPU.
Для первой оценки этого действительно хватает. Для рабочего сервиса уже нет. Требования меняются в зависимости от самой модели, длины контекста, количества одновременных запросов и сценария работы. Inference, RAG, генерация изображений и дообучение одной и той же модели создают разную нагрузку.
Поэтому сначала стоит понять, что именно мы собираемся запускать, а уже потом сравнивать V100, RTX 4090, RTX 5090 и A100.
Сначала задача, потом GPU
У двух проектов может быть одна и та же LLM и совершенно разная нагрузка. В первом случае разработчик тестирует модель сам, задаёт несколько вопросов и работает с коротким контекстом. Во втором эта же модель стоит за корпоративным AI-ассистентом, принимает запросы сотрудников и получает из RAG-системы большие фрагменты документов. Модель та же, требования к серверу уже другие.
При inference важны размер и формат модели, длина контекста, количество одновременных запросов и требования к скорости ответа. При дообучении (fine-tuning) памяти обычно требуется больше, потому что GPU работает уже не только с весами модели, но и с дополнительными данными, необходимыми для обучения.
В задачах генерации изображений, видео и computer vision на расход памяти влияют сама модель, разрешение, batch size и дополнительные компоненты pipeline. Есть и более простой сценарий: GPU нужна разработчику на несколько дней, чтобы протестировать новую модель, проверить CUDA-код или поднять временный стенд. Здесь большой ресурс «на вырост» может вообще не понадобиться.
Сколько VRAM действительно нужно LLM
Первая часть расчёта понятна: в видеопамять нужно загрузить веса модели. Если считать очень грубо, один параметр в FP16 или BF16 занимает около двух байт. Для модели на 7 млрд параметров получается примерно 14 ГБ только под веса.
Квантизация эту картину заметно меняет. В 8-bit те же веса займут примерно вдвое меньше памяти, а при 4-bit теоретический объём уменьшится ещё сильнее. Для модели 7B порядок цифр будет примерно таким: около 14 ГБ в FP16/BF16, около 7 ГБ в 8-bit и порядка 3,5 ГБ в 4-bit. Hugging Face также указывает, что 8-битная загрузка примерно вдвое сокращает потребление памяти, а 4-битная квантизация используется для ещё более компактного размещения моделей.
Но веса модели занимают не всю VRAM. Во время inference заметная часть памяти может уходить на KV-cache. Если не погружаться в устройство трансформеров, его можно представить как рабочую память модели на время запроса. LLM сохраняет часть уже рассчитанных данных, чтобы не пересчитывать весь предыдущий контекст для каждого следующего токена.
Чем длиннее контекст, тем больше становится KV-cache. Если GPU обслуживает несколько запросов одновременно, памяти тоже потребуется больше. Современные inference engines отдельно управляют объёмом памяти под KV-cache, и это один из существенных элементов использования GPU-памяти при serving.
Разницу легко представить на обычном примере. Короткий вопрос «объясни эту ошибку в Python» и запрос с приложенным многостраничным документом создают совсем разную нагрузку, даже если отвечает одна и та же модель.
Есть и накладные расходы inference engine, временные данные и другие компоненты. Квантизация тоже может влиять на скорость и качество модели. Поэтому цифры 14, 7 и 3,5 ГБ полезны как отправная точка, но не как готовая конфигурация сервера.
Что кроме VRAM влияет на скорость
Объём VRAM в первую очередь показывает, хватает ли памяти для модели и её рабочей нагрузки. Но две видеокарты с похожим объёмом памяти могут заметно отличаться по скорости.
Имеют значение архитектура GPU, пропускная способность памяти, поддерживаемые форматы вычислений и особенности самой модели. Поэтому одинаковое число гигабайт ещё не означает одинаковую производительность.
Есть и программный слой. Для рабочих LLM-сервисов часто используют vLLM или SGLang, то есть движки для inference и обслуживания потока запросов. В локальных и тестовых сценариях часто встречается Ollama. Такие системы по-разному работают с памятью, batching и очередью запросов. SGLang, например, отдельно измеряет throughput, concurrency, TTFT и задержку между токенами именно как показатели работы LLM-serving.
Поэтому запись «24 ГБ VRAM» сама по себе ещё не говорит, сколько пользователей сможет обслуживать сервис и насколько быстро они увидят ответ.
Что меняется при RAG
Представим внутреннего AI-ассистента, который должен отвечать по технической документации компании.
Пользователь задаёт вопрос. Система находит подходящие фрагменты документации, добавляет их в prompt и передаёт получившийся контекст LLM. Модель получает не только вопрос пользователя, но и данные, на которых нужно построить ответ.
До этого документы тоже нужно подготовить: разбить на фрагменты, построить embeddings, то есть векторные представления текста, и сохранить индекс. В некоторых системах появляется reranker, который дополнительно отбирает наиболее подходящие результаты поиска.
Часть этого pipeline вообще может работать вне GPU. Например, сама LLM находится на GPU, а векторная база использует CPU и RAM. В более нагруженной системе на GPU можно вынести и embedding-модель или reranker.
Есть и прямое влияние на основную LLM. Чем больше найденных фрагментов добавляется в prompt, тем длиннее становится контекст и тем больше памяти может потребоваться во время inference.
Поэтому «у нас RAG» ещё не определяет конфигурацию сервера. База из нескольких тысяч коротких записей и архив больших технических документов создают совершенно разные сценарии. Важнее понимать, какая модель используется, сколько данных обычно попадает в контекст, сколько запросов идёт одновременно и какие компоненты работают рядом с LLM.
V100, RTX 4090, RTX 5090 или A100
В GPU VPS ESTT доступны vGPU V100 с объёмом памяти от 1 до 32 ГБ, RTX 4090 24 ГБ, RTX 5090 32 ГБ и A100 64 ГБ.
RTX 4090 и RTX 5090 относятся к линейке GeForce. V100 и A100 создавались как дата-центровые GPU. Они отличаются архитектурой, памятью и возможностями, поэтому сравнивать их только по количеству гигабайт не очень полезно.
V100: небольшие GPU-задачи и тестовые среды
NVIDIA V100 построена на архитектуре Volta, а официальные vGPU-профили этого поколения включают 1, 2, 4, 8, 16 и 32 ГБ видеопамяти. В ESTT доступны такие же варианты от 1 до 32 ГБ.
Главное преимущество такого формата в том, что для задачи не обязательно сразу брать большой GPU-ресурс. Например, можно поднять CUDA/PyTorch-окружение, проверить работу приложения на GPU, запустить inference небольшой encoder-модели или лёгкую задачу computer vision.
Профили на 1-4 ГБ не рассчитаны на современные крупные LLM, но для небольших GPU-задач и тестов такой ресурс вполне может быть достаточным. Если проекту требуется больше памяти, доступны профили вплоть до 32 ГБ.
V100 относится к более раннему поколению GPU, поэтому одинаковый объём памяти на V100 и более современной карте ещё не означает одинаковую производительность.
RTX 4090: 24 ГБ для широкого круга AI-задач
RTX 4090 построена на архитектуре Ada Lovelace и имеет 24 ГБ GDDR6X. Такой объём подходит для многих inference-сценариев с квантизованными LLM, генерации изображений, computer vision, обработки видео и CUDA-вычислений.
Для LLM здесь особенно интересно, сколько памяти остаётся после загрузки весов. Если модель занимает почти все 24 ГБ, места под длинный контекст и параллельные запросы будет немного.
Для моделей класса 7B/8B 24 ГБ можно рассматривать как одну из отправных точек для многих inference-сценариев, особенно с квантизацией. Но конкретный запас памяти зависит от модели, длины контекста и inference engine.
RTX 5090: когда 24 ГБ уже тесно
RTX 5090 относится к архитектуре Blackwell и имеет 32 ГБ GDDR7.
Разница с RTX 4090 составляет 8 ГБ, но в реальной нагрузке именно этого запаса иногда и не хватает. Дополнительная память может уйти на более крупную модель, длинный контекст или больший KV-cache при нескольких одновременных запросах.
RTX 5090 отличается от RTX 4090 и самой архитектурой, поэтому переход с 24 на 32 ГБ нельзя воспринимать только как «ещё восемь гигабайт памяти».
Если проект уже упирается в 24 ГБ или после загрузки модели остаётся слишком маленький запас, 32 ГБ становятся логичным следующим диапазоном для рассмотрения.
A100: 64 ГБ для более тяжёлых задач
В GPU VPS ESTT доступна виртуальная конфигурация A100 с 64 ГБ GPU-памяти. Это не отдельная физическая модификация A100 на 64 ГБ, а параметры виртуального GPU-ресурса в нашей линейке.
Это уже заметно другой запас по VRAM. Такая конфигурация интересна для более крупных моделей, длинного контекста и задач дообучения, где 24 или 32 ГБ становятся ограничением.
При дообучении память требуется не только весам модели, поэтому запас VRAM особенно важен. Если возможностей одной GPU уже недостаточно, дальше рассматривают несколько ускорителей или другой класс инфраструктуры. Такие проекты лучше считать отдельно.
Если нужен очень грубый ориентир
Точную конфигурацию всё равно лучше считать по конкретной модели, но на первом этапе можно хотя бы понять направление.
Для небольших GPU-задач, тестовых сред и компактных моделей можно смотреть на vGPU V100 и выбирать объём памяти под конкретный проект.
Для LLM класса 7B/8B одной из отправных точек может быть RTX 4090 с 24 ГБ. RTX 5090 с 32 ГБ стоит рассматривать, когда нужен больший запас под модель, контекст или параллельную нагрузку.
A100 с 64 ГБ становится интересна для более крупных моделей и дообучения, где 24-32 ГБ уже начинают заметно ограничивать проект.
Это именно ориентиры. Одна и та же модель может потребовать разную конфигурацию в зависимости от квантизации, длины контекста и нагрузки.
Почему кроме GPU нужны CPU, RAM и диск
GPU может быть самым заметным компонентом конфигурации, но работает он не один.
Модель нужно загрузить с диска, данные подготовить, RAG использует индекс и хранилище, рядом с LLM работают приложение, API и иногда база данных. Часть этой нагрузки приходится на CPU и RAM. При больших моделях, датасетах и индексах становится важна и дисковая подсистема.
Можно взять мощную GPU и всё равно получить медленный сервис, если данные не успевает готовить CPU, системе не хватает RAM или нужные данные слишком долго читаются с диска. В такой ситуации GPU часть времени будет просто ждать остальные компоненты.
Поэтому запрос «нужна RTX 5090» ещё не даёт готовую конфигурацию виртуальной машины. Нужно понять, сколько добавить vCPU, RAM и дискового пространства.
На странице GPU VPS мы поэтому не привязываем каждую видеокарту к одному фиксированному набору CPU и RAM. Полная конфигурация зависит от проекта.
Несколько типичных сценариев
Нужна LLM для экспериментов
Сначала смотрим на размер модели и квантизацию. Для небольшой модели или простого теста может подойти vGPU V100. Если требуется больше памяти, уже имеет смысл смотреть на 24 или 32 ГБ.
На этапе эксперимента обычно важнее быстро проверить гипотезу и увидеть реальное потребление ресурсов, чем заранее брать большой запас.
Запускаем корпоративный RAG
Кроме самой LLM нужно понимать, какого размера получается контекст, сколько запросов приходит одновременно и что ещё входит в pipeline.
Большая база документов сама по себе не означает необходимость огромной GPU. На нагрузку модели гораздо сильнее влияет то, сколько найденных фрагментов RAG передаёт ей при каждом запросе.
Открываем LLM через API
В таком сервисе особенно важна параллельная нагрузка. Фраза «у нас сто пользователей» мало что говорит о GPU.
Если эти сто человек обращаются к модели несколько раз в день, нагрузка может быть небольшой. Если десять пользователей одновременно отправляют длинные запросы, GPU придётся работать совсем в другом режиме.
Генерируем изображения
Здесь на расход VRAM влияют модель, разрешение, batch size и состав pipeline. Подключение ControlNet, нескольких LoRA-адаптеров или других дополнительных компонентов тоже меняет требования.
Поэтому выбор между 24 и 32 ГБ лучше делать уже с пониманием реального workflow.
Дообучаем LLM
Для дообучения (fine-tuning) требования к памяти обычно выше, чем для обычного inference, но многое зависит от метода.
LoRA и QLoRA позволяют заметно снизить требования к GPU-памяти по сравнению с полным обучением модели. QLoRA, например, использует 4-битное представление базовой модели вместе с обучаемыми LoRA-адаптерами.
Поэтому сначала нужно понять, какую модель и каким способом планируем дообучать, а потом выбирать GPU.
Нужна GPU на несколько дней
Например, команда нашла новую модель на Hugging Face и хочет понять, подходит ли она для проекта. Нужно поднять окружение, прогнать несколько тестов, посмотреть расход VRAM и скорость inference. Через неделю такая среда может уже не понадобиться.
Для такого сценария GPU VPS позволяет взять ресурс под конкретный эксперимент, не закладывая сразу постоянную инфраструктуру.
Если пилот перерастает первоначальную конфигурацию, можно уже подбирать следующий уровень GPU-ресурсов под фактическую нагрузку. Конкретную схему перехода между конфигурациями лучше уточнять при подборе сервера.
Что проверить на пилоте
На пилоте полезно посмотреть хотя бы на три вещи: реальное потребление VRAM, поведение при нескольких одновременных запросах и скорость ответа.
Для интерактивных LLM часто используют метрику TTFT, Time to First Token. Она показывает время от отправки запроса до появления первого токена ответа. Для пользователя это та самая пауза между нажатием Enter и моментом, когда AI начинает печатать. TTFT действительно используется как одна из основных метрик при тестировании LLM-serving наряду с throughput и задержкой между токенами.
TTFT зависит не только от GPU. На него влияют длина входного контекста, очередь запросов, inference engine и другие компоненты системы.
Для первого пилота не обязательно строить сложный benchmark. Даже проверка VRAM, параллельной нагрузки и задержки уже даст гораздо больше информации, чем сравнение GPU только по таблице характеристик.
GPU VPS или выделенный GPU-сервер
Для разработки, пилотов, inference и части рабочих AI-сервисов удобно начать с GPU VPS. Можно получить GPU вместе с необходимыми vCPU, RAM и диском без покупки собственного оборудования.
Если нагрузка тяжёлая и постоянная, нужен весь ресурс физической машины или важен полный контроль над средой, можно рассматривать выделенный GPU-сервер.
Один проект может со временем пройти оба этапа. Сначала команда проверяет модель и реальную нагрузку на виртуальной инфраструктуре, а когда требования становятся понятными и стабильными, уже отдельно считает выделенный сервер.
С чего начать подбор GPU
Приходить с готовой спецификацией необязательно. Если модель уже выбрана, полезно знать её название, размер и вариант квантизации. Дальше инженер уточнит сценарий: inference, RAG, генерация, дообучение или просто эксперименты.
Для рабочего сервиса важны длина контекста и параллельная нагрузка. Сколько запросов может идти одновременно? Это короткий чат или работа с большими документами? Насколько быстро пользователь должен получить начало ответа?
Если пока неизвестно, какую модель или GPU выбрать, можно начать просто с описания задачи. Например: «хотим внутреннего помощника по документам» или «нужно запустить LLM через API». Инженеры ESTT помогут перевести эту задачу в конкретные требования к GPU, vCPU, RAM и диску и объяснят, почему предложена именно такая конфигурация.
GPU VPS в ESTT
Подберём GPU под вашу задачу
В ESTT доступны GPU VPS с vGPU V100 от 1 до 32 ГБ, RTX 4090 24 ГБ, RTX 5090 32 ГБ и A100 64 ГБ. Подберём GPU, vCPU, RAM и диск под модель и реальную нагрузку, проверим доступность ресурсов и рассчитаем стоимость.