Например, файл модели занимает 20 ГБ, а на видеокарте с 24 ГБ памяти возникает ошибка CUDA out of memory. Такое возможно: кроме самой модели GPU хранит данные обрабатываемых запросов и временные результаты вычислений. Поэтому выбирать GPU-сервер для ИИ только по размеру скачиваемого файла нельзя.

Для предварительного подбора под текстовую LLM в 4 бит ориентируйтесь на 8–12 ГБ VRAM для 7B–8B, 16 ГБ для 14B, 24–32 ГБ для 32B и 48–80 ГБ для 70B. Эти ориентиры предполагают один запрос, умеренный контекст и размещение модели целиком на GPU. Длинные документы, несколько одновременных запросов и обучение требуют отдельного расчёта.

Что нужно определить перед выбором GPU-сервера

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

VRAM — собственная память видеокарты. Оперативная память сервера, RAM, учитывается отдельно: сервер с 128 ГБ RAM и GPU на 16 ГБ не получает 144 ГБ видеопамяти.

Сначала зафиксируйте условия задачи:

• Точная модель и её версия. Названия «Qwen» или «DeepSeek» недостаточно: внутри семейства есть модели совершенно разного размера. Буква B означает миллиарды параметров.
• Режим работы. Инференс — получение ответов от готовой модели. Для дообучения потребуется дополнительная память.
• Формат весов. Например, BF16, 8-битная или конкретная 4-битная версия. Веса — числовые параметры, которые модель получила при обучении.
• Максимальный контекст. Сколько токенов займут инструкция, история диалога, документы и будущий ответ вместе. Токен — единица текста модели, не обязательно целое слово.
• Одновременная нагрузка. Сколько запросов сервер должен обрабатывать одновременно и какое время ожидания допустимо.

Для бота с тысячей зарегистрированных пользователей важен поток активных запросов. Само количество аккаунтов не определяет потребление VRAM.

Сколько видеопамяти занимают модели 8B, 14B, 32B и 70B

Первую оценку дают веса модели:

Память весов, байт ≈ число параметров × бит на параметр / 8

В FP16 и BF16 один параметр занимает 2 байта, при 8-битном хранении — примерно 1 байт, при 4-битном — примерно половину байта. Переход с FP16 на BF16 сам по себе память не экономит.

В таблице ниже первые три столбца с памятью — теоретический объём только весов, без кэша запросов и служебных данных. GiB — двоичные гигабайты: 1 GiB = 1 073 741 824 байта. Для проверки оборудования сравнивайте расчёт с объёмом, который показывает драйвер, а не смешивайте GiB и десятичные GB.

Последний столбец — ориентир для плотных текстовых моделей, одного запроса и контекста примерно 4–8 тысяч токенов. Это диапазон для выбора кандидатов на проверку, а не гарантия запуска любой модели указанного размера.

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

Например, 32B в 16-битном формате требует около 60 GiB только под веса: для одного GPU логично начинать рассмотрение с класса 80 ГБ. У 70B в таком формате веса занимают около 130 GiB, поэтому обычно потребуется разделение модели между несколькими GPU. Покупка одной карты на 80 ГБ эту задачу не решает.

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

Во время генерации модель сохраняет промежуточные данные уже обработанных токенов в KV-кэше. Это позволяет использовать предыдущие вычисления при продолжении ответа. Чем длиннее запрос вместе с ответом, тем больше может быть кэш.

Рабочий расчёт выглядит так:

VRAM = веса + KV-кэш активных запросов
       + временные буферы и служебные данные движка

Для обычного трансформера с полным вниманием объём KV-кэша можно оценить по формуле:

KV-кэш, байт ≈ 2 × слои × KV-головы × размер головы
               × токены × одновременные запросы × байт на элемент

Архитектурные параметры берут из config.json модели: num_hidden_layers, num_key_value_heads, head_dim. Важны именно KV-головы: их число может отличаться от общего числа голов внимания.

Пример расчёта для Qwen3-8B: 36 слоёв, 8 KV-голов, размер головы 128. При 16-битном кэше один запрос с заполненным контекстом 8 192 токена потребует около 1,125 GiB под KV-кэш. При 32 768 токенах — 4,5 GiB. Четыре таких длинных запроса потребуют уже около 18 GiB кэша, ещё до учёта весов.

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

Для RAG — ответов с поиском по вашим документам — считайте объём найденных фрагментов, передаваемых в модель. Размер всей базы документов напрямую в KV-кэш не попадает. Но модели для поиска и повторного ранжирования тоже займут VRAM, если работают на том же GPU.

Запас «плюс 20% к весам» не заменяет расчёт контекста. Сначала учитывают максимальную рабочую нагрузку, затем проверяют её на сервере. Иногда выгоднее ограничить длину истории и поставить часть запросов в очередь, чем оплачивать GPU следующего класса.

Что даёт квантизация и где можно ошибиться

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

Проверяйте результат на своих задачах: извлечении данных, русском тексте, коде, соблюдении JSON-формата. Если ошибки стали неприемлемыми, попробуйте более точную версию или другую модель. Одинакового процента потери качества для всех LLM нет.

Q4_K_M, AWQ и GPTQ относятся к разным вариантам квантизации. Совместимость зависит от движка запуска, его версии и поколения GPU. До заказа проверьте поддержку конкретного формата в Ollama, llama.cpp, vLLM или другом выбранном ПО. По одной надписи «NVIDIA, 24 ГБ» определить совместимость нельзя.

Квантизация весов и KV-кэша настраивается отдельно. Модель с 4-битными весами может продолжать хранить кэш в 16 бит. Сжатие кэша помогает вместить длинный контекст, но требует отдельной проверки качества и задержки. Уменьшение расхода памяти не гарантирует ускорение.

Отдельно проверяйте модели MoE — архитектуру с набором «экспертов». Например, у Qwen3-30B-A3B около 30,5 миллиарда параметров всего, хотя для обработки токена активируется около 3,3 миллиарда. При полном размещении модели на GPU память рассчитывают по всем весам. Обозначение A3B не означает требования к памяти как у обычной модели 3B.

Хватит ли этой же видеокарты для дообучения

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

Показательный расчёт: в одной из распространённых схем обучения со смешанной точностью и оптимизатором Adam на веса, градиенты и состояния оптимизатора приходится около 18 байт на параметр. Для 8B это примерно 144 десятичных ГБ ещё без активаций. Другие оптимизаторы и способы распределения меняют расход, поэтому это пример конкретной схемы, а не универсальный минимум.

LoRA обучает небольшие дополнительные матрицы — адаптеры. QLoRA дополнительно хранит замороженную базовую модель в квантизованном виде. Эти методы заметно снижают требования, но длинные обучающие примеры и большой пакет примеров всё равно могут вызвать нехватку памяти.

Для первого подбора под QLoRA модели 7B–8B можно рассматривать GPU с 24 ГБ, затем проверять конкретный сценарий. Зафиксируйте длину последовательности, размер пакета на GPU, параметры адаптеров и поддерживаемый обучающим ПО формат базовой модели.

Если памяти не хватает, начните с одного примера на GPU за шаг и уменьшите длину последовательности. Накопление градиентов позволяет сохранить больший эффективный размер пакета за несколько шагов. Gradient checkpointing экономит память за счёт повторного вычисления части промежуточных результатов и увеличивает время работы.

Проверка должна пройти полный шаг: прямой проход, вычисление градиентов и обновление параметров. Затем проверьте сохранение и повторную загрузку результата. Успешная загрузка исходной модели ещё не подтверждает, что обучение поместится.

Можно ли объединить память нескольких GPU

Две карты по 24 ГБ дают возможность распределить модель между устройствами, если это поддерживает движок. При tensor parallelism между GPU делят вычисления внутри слоёв, при pipeline parallelism — группы слоёв.

При этом каждая карта должна вместить свою часть весов, кэша и буферов. Неравномерное распределение может вызвать ошибку на одной GPU, хотя на другой остаётся свободная память. Скорость зависит от обмена между картами через PCIe или NVLink.

Если модель с рабочим контекстом помещается на одной карте, один GPU с достаточной VRAM обычно проще в настройке. Несколько карт полезны, когда нужно разместить более крупную модель или увеличить пропускную способность сервиса.

Для второго случая можно запускать отдельные копии модели на разных GPU. Это увеличивает число обслуживаемых запросов, но каждая копия хранит свои веса. Запуск двух независимых процессов не объединяет их память.

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

Можно ли компенсировать нехватку VRAM оперативной памятью

Некоторые движки поддерживают offload: часть весов или кэша размещается в RAM сервера. Это позволяет запустить модель, которая целиком не помещается в видеопамять. Цена решения — дополнительные передачи данных и, в зависимости от реализации, вычисления на CPU.

Такой вариант имеет смысл для экспериментов и фоновых задач, если измеренная скорость устраивает. Для интерактивного API сначала проверьте время до первого токена и скорость продолжения ответа. Сам факт запуска большой модели ещё ничего не говорит об удобстве работы с ней.

В Ollama после загрузки модели выполните:

ollama ps

В столбце PROCESSOR значение 100% GPU означает полное размещение на GPU, 100% CPU — в системной памяти, смешанное значение — разделение между ними. Если ожидали работу целиком на видеокарте, а получили CPU/GPU, уменьшите контекст, выберите более компактную версию или пересмотрите объём VRAM.

Для самого сервера нужны также:

• RAM для загрузки модели и приложений. Учитывайте пик при запуске, offload, обработку документов и базу данных. Единого правила «RAM ровно вдвое больше VRAM» нет.
• Место на SSD. Сложите размеры моделей, сохраняемых версий, кэшей, данных и результатов обучения. При обновлении старая и новая версии могут одновременно занимать диск.
• Подходящий CPU. Он обслуживает приложение, подготовку текста и данных. Его требования возрастают при вычислениях вне GPU.
• Совместимое окружение. Драйвер, библиотеки GPU и движок должны поддерживать выбранную видеокарту и формат модели.

Объём VRAM определяет, что можно разместить, но не задаёт скорость сам по себе. На неё влияют вычислительные возможности GPU, пропускная способность памяти, длина контекста и реализация движка. Две карты с одинаковым объёмом памяти могут отвечать с разной скоростью.

Когда нужен свой GPU-сервер и что выбрать в HSTQ

Собственный GPU-сервер имеет смысл при регулярной нагрузке, необходимости управлять моделью и окружением или обрабатывать данные в выбранной инфраструктуре. Для редких запросов сначала сравните его стоимость с готовым API. Для коротких экспериментов — с арендой GPU на ограниченное время, если такой вариант доступен.

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

Для размещения компактной LLM рекомендуем начать подбор с GPU-серверов HSTQ. В каталоге есть конфигурация с RTX 5070 Ti и 16 ГБ VRAM — кандидат для квантизованных моделей 7B–8B, а также некоторых 14B при подходящих настройках. Для 32B и 70B целиком на GPU сначала уточните возможность конфигурации с большим объёмом видеопамяти.

Вариант с NVS 315 из того же каталога предназначен для базового вывода изображения и VDI. Для современных LLM его выбирать не стоит.

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

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

Если провайдер предлагает тестирование, согласуйте его до оплаты длительного периода. Если теста нет, ориентируйтесь на воспроизводимые измерения именно выбранной модели, формата и оборудования; чужой результат для другой LLM не подтверждает ваши требования.

На Linux-сервере с NVIDIA и установленным драйвером посмотрите память и загрузку каждой карты:

nvidia-smi --query-gpu=index,name,memory.total,memory.used,memory.free,utilization.gpu --format=csv --loop=1

Команда обновляет показания раз в секунду; остановка — Ctrl+C. memory.total показывает доступный объём карты, memory.used — занятую память. Если память занята до запуска модели, обычный вызов nvidia-smi покажет использующие GPU процессы. Секундное наблюдение может пропустить короткий пик, поэтому дополнительно проверяйте ошибки и метрики движка.

Для установленного совместимого vLLM пример контрольного запуска Qwen3-8B в FP16 на отдельной GPU класса 24 ГБ выглядит так. Нужны доступ к репозиторию модели и свободное место для её файлов:

vllm serve Qwen/Qwen3-8B \
  --dtype half \
  --max-model-len 8192 \
  --max-num-seqs 1 \
  --gpu-memory-utilization 0.90 \
  --host 127.0.0.1

Здесь ограничены суммарная длина запроса и ответа, число одновременно обрабатываемых последовательностей и доля памяти, выделяемая экземпляру vLLM. Значение 0.90 задано явно. Это исходная конфигурация проверки, которую затем меняют под рабочую нагрузку.

После завершения загрузки в другом терминале того же сервера запустите короткий нагрузочный тест:

vllm bench serve \
  --model Qwen/Qwen3-8B \
  --backend openai \
  --base-url http://127.0.0.1:8000 \
  --dataset-name random \
  --random-input-len 7168 \
  --random-output-len 512 \
  --num-prompts 20 \
  --max-concurrency 1

Тест отправляет 20 синтетических запросов с длинным входом и запрашивает ответы до 512 токенов. Ожидайте 20 успешных запросов и отсутствие OOM в логах. В отчёте сравнивайте TTFT — время до первого токена — и задержку между токенами с требованиями приложения. Синтетические запросы проверяют нагрузку; качество ответов оценивают отдельно на своих данных. API в этом примере доступен только на самом сервере.

Дальше проверьте условия, ради которых выбираете сервер:

1. Отправьте реальный длинный запрос, оставив место для ответа внутри лимита контекста. Повторите с документами, историей диалога и другими данными рабочего приложения.
2. Для проверки двух одновременных запросов перезапустите тестовый сервер с --max-num-seqs 2, а в команде теста укажите --max-concurrency 2. Аналогично увеличивайте нагрузку до целевой, каждый раз проверяя память.
3. Измерьте время до первого токена, скорость ответа отдельному пользователю и ожидание в очереди. Суммарные токены в секунду всего сервера не равны скорости одного диалога.
4. Повторите серию запросов и перезапуск сервиса. Убедитесь, что нет ошибок нехватки памяти, неожиданного offload и накопления очереди при обычной нагрузке.

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

В логах vLLM строки GPU KV cache size и Maximum concurrency помогают оценить вместимость кэша. Они не обещают нужную задержку: её показывает нагрузочная проверка.

Что делать при нехватке памяти или медленной работе

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