Как выбрать сервер для ИИ: какой GPU и сколько VRAM нужно
У ИИ-проектов есть типичная ловушка: сервер выбирают по верхнеуровневым характеристикам — смотрят на модель GPU, количество ядер и стоимость аренды, — а потом оказывается, что система упирается не столько в вычислительную мощность, сколько в объём видеопамяти, длину контекста, дисковую подсистему или сеть.
В результате пилот работает медленно, production не выдерживает SLA, а бюджет уходит на постоянное масштабирование и переделку инфраструктуры. На практике выбор сервера под ИИ начинается не с вопроса «какой GPU взять», а с понимания профиля нагрузки: какая модель используется, какой нужен контекст, сколько одновременных запросов ожидается и какие требования предъявляются к задержке ответа.
Для одной задачи критичен объём VRAM, для другой — скорость NVMe, для третьей — стабильная сеть, а для четвёртой — способность выдерживать длинный контекст и высокую concurrency. Ниже — практический разбор того, как выбрать сервер для LLM, inference API, fine-tuning и других ИИ-сценариев без упрощений, которые потом дорого обходятся в production.
Главная ловушка: выбирать сервер под ИИ по верхнеуровневым характеристикам, не считая реальный профиль нагрузки, VRAM, контекст, storage и сеть.
Почему обычный сервер часто не подходит для ИИ
Классический сервер отлично справляется с веб-приложениями, базами данных, корпоративными сервисами и системной логикой. Но современные ИИ-модели, особенно большие языковые модели, генерация изображений и мультимодальные системы, сильно зависят от параллельных вычислений и пропускной способности памяти.
Именно поэтому в большинстве сценариев inference для LLM главным ограничением становится не CPU, а GPU-память, пропускная способность памяти и рост потребления памяти под KV cache. CPU по-прежнему важен: на нём работают API, orchestration, интеграции, подготовка данных и сервисная логика. Но производительность самой модели в production чаще определяется тем, хватает ли системе VRAM, насколько быстро работает память ускорителя и как устроен весь контур инфраструктуры.
Если упростить, для классической серверной нагрузки критичны CPU и RAM, а для ИИ-нагрузки — GPU, VRAM, storage и сеть. И чем крупнее модель и выше SLA, тем заметнее эта разница.
Для классической серверной нагрузки критичны CPU и RAM, а для ИИ-нагрузки — GPU, VRAM, storage и сеть.
CPU и GPU: в чём разница для ИИ-задач
CPU — универсальный вычислитель, который эффективен там, где много логики, ветвлений, запросов к базам данных и общего системного управления. GPU — специализированный ускоритель для параллельных операций, на которых строятся обучение и инференс нейросетей.
Для бизнеса эта разница особенно заметна, когда система выходит в production. Если модель отвечает медленно, нестабильно работает под нагрузкой или постоянно упирается в память, проблема часто находится не в самой модели, а в неверно подобранной инфраструктуре.
Сервер под ИИ — это не «обычный сервер помощнее», а сбалансированная система, где каждая часть отвечает за свою зону нагрузки.
Для некоторых сценариев — preprocessing, RAG-пайплайнов, работы с embedding и большим количеством сервисной логики — CPU и RAM тоже могут стать узким местом, поэтому их нельзя выбирать по остаточному принципу.
| Компонент | За что отвечает |
|---|---|
| CPU | API-логика, orchestration, фоновые процессы, подготовка данных |
| GPU | Основные вычисления модели, инференс, fine-tuning, генерация |
| VRAM | Веса модели, KV cache, промежуточные данные и часть рабочих буферов |
| RAM | Сервисный слой, буферизация, загрузка данных, вспомогательные процессы |
| Storage | Датасеты, checkpoints, кэш моделей, быстрая загрузка и локальное хранение |
| Сеть | API-доступ, интеграции, доступность сервиса, стабильность канала и SLA |
Сколько VRAM нужно для LLM
Это главный практический вопрос при выборе сервера под ИИ. Именно объём VRAM чаще всего первым ограничивает, какую модель можно запустить и в каком режиме она сможет работать.
Здесь важно различать два уровня требований:
Минимальный VRAM
Модель можно запустить, часто с квантизацией и компромиссами по скорости, контексту или числу одновременных запросов.
Комфортный production VRAM
У системы есть запас под реальную нагрузку, длину контекста, KV cache, batching и concurrency.
Ниже — практический ориентир для inference-сценариев.
| Модель | Минимум VRAM | Комфортный production |
|---|---|---|
| 7B | 8–16 GB | 16–24 GB |
| 13B | 16–24 GB | 24–48 GB |
| 30B | 24–48 GB | 48+ GB |
| 70B | 40–80+ GB | 80+ GB |
Точные требования зависят от precision, архитектуры модели, длины контекста, KV cache, inference-движка и числа одновременных запросов, поэтому эту таблицу стоит использовать как ориентир для первичной оценки, а не как жесткий стандарт. Главная ошибка — считать только объём весов модели. В production память расходуется заметно шире.
Почему длина контекста влияет на требования к серверу
Многие считают, что объём памяти LLM определяется только весами модели. На практике это лишь часть картины.
Дополнительно память расходуется на:
- контекст запроса;
- KV cache;
- служебные накладные расходы inference-движка;
- batching;
- concurrency, то есть число параллельных пользовательских сессий.
Чем длиннее контекст, тем больше памяти требуется на обработку. Чем больше одновременных пользователей, тем выше требования к VRAM.
Это особенно заметно в RAG-системах, корпоративных ассистентах и внешних API, где модель должна одновременно держать историю диалога, документы и активные пользовательские сессии. Поэтому два проекта на одной и той же модели могут требовать совершенно разную инфраструктуру.
Внутренний AI-ассистент для нескольких десятков сотрудников и внешний клиентский API — это принципиально разные нагрузки. Если планируются длинный контекст, история диалога, RAG или открытый API для внешних пользователей, ориентироваться нужно не на минимальный объём VRAM, а на production-запас.
Training и inference: почему нельзя выбирать один сервер “на всё”
Одна из самых частых ошибок — искать универсальный сервер, который одинаково хорошо подойдёт и для обучения, и для эксплуатации модели. На практике training и inference — это разные режимы работы с разными ограничениями.
Для training особенно важны:
- высокая вычислительная плотность GPU;
- большой запас VRAM;
- быстрый storage;
- качественные межсоединения между GPU;
- высокая скорость чтения и записи данных.
Для inference на первый план выходят:
- latency;
- throughput;
- стоимость одного запроса;
- устойчивость под нагрузкой;
- запас памяти под контекст и concurrency.
Поэтому инфраструктура для обучения и production чаще всего различается. Для бизнеса это обычно означает простую стратегию: обучение, эксперименты и тесты — в аренде, стабильный production — на выделенной конфигурации, подобранной под реальный профиль нагрузки.
Почему межсоединения между GPU важнее, чем кажется
Когда одной GPU уже недостаточно, значение имеет не только количество ускорителей, но и то, как они связаны между собой. Для крупных LLM важна не только связь GPU с CPU, но и скорость обмена между самими GPU.
Если межсоединения медленные, часть ресурсов начинает простаивать, а эффективность масштабирования падает. Именно поэтому в multi-GPU системах важно смотреть не только на число видеокарт, но и на поддержку NVLink, NVSwitch и внутреннюю топологию сервера.
Для крупных LLM, training и тяжелых inference-сценариев это часто становится одним из ключевых факторов производительности.
Почему storage критичен для ИИ
Когда речь заходит о сервере под ИИ, многие смотрят прежде всего на GPU. Но для training, fine-tuning, быстрой загрузки моделей и работы с крупными датасетами storage влияет на производительность сильнее, чем кажется.
Storage важен для:
- загрузки датасетов;
- чтения и записи checkpoints;
- быстрого старта модели;
- локального кэша моделей;
- промежуточных данных и служебных файлов пайплайна.
Если storage медленный, GPU начинает простаивать в ожидании данных. А это означает прямую потерю эффективности.
Для training, fine-tuning и работы с большими моделями NVMe обычно предпочтительнее SATA, потому что лучше справляется с интенсивной подачей данных и операциями чтения/записи.
Для тяжёлых training-сценариев и больших датасетов важно смотреть не только на тип дисков, но и на суммарную скорость чтения/записи массива.
| Тип storage | Где уместен | Ограничения |
|---|---|---|
| SATA SSD | Базовые сценарии и менее интенсивные нагрузки | Быстро становится узким местом при активной работе с моделями и датасетами |
| NVMe SSD | Training, fine-tuning, быстрый inference, локальный кэш моделей | Предпочтительный вариант для интенсивных сценариев |
| Сетевое хранилище | Архивы, shared data, вторичные контуры хранения | Важны latency и bandwidth |
Если датасеты или модели весят десятки и сотни гигабайт, разница между SATA и NVMe перестаёт быть нюансом. Она становится частью производительности всей системы.
Когда сеть становится частью производительности ИИ-сервиса
На локальных тестах сеть часто недооценивают. Но как только inference превращается в API-сервис, сеть становится частью продукта.
Важно уже не только то, насколько мощный GPU установлен в сервере, но и:
- какая задержка у канала;
- насколько стабилен доступ;
- хватает ли bandwidth;
- как инфраструктура ведёт себя под пиковыми запросами;
- насколько предсказуемо работает сервис при внешних интеграциях.
Для клиентской поддержки, документооборота, аналитики и автоматизации слабая сеть способна испортить впечатление даже от сильной GPU-конфигурации. Снаружи это выглядит как «модель отвечает медленно», хотя проблема может быть не в нейросети, а в сетевом контуре или общей архитектуре сервиса.
Поэтому production-инфраструктура — это всегда не только вычисления, но и сеть, отказоустойчивость и SLA.
Какие конфигурации подходят под разные ИИ-задачи
Выбор сервера зависит не от бренда GPU как такового, а от профиля нагрузки.
| Сценарий | Что критично | Практический ориентир |
|---|---|---|
| RAG, чат-боты, ассистенты 7B–14B | Баланс VRAM, latency, стоимость | Во многих случаях может хватить одной GPU |
| LLM 30B | VRAM, контекст, inference-стек | Нужен расчёт production-нагрузки |
| LLM 70B | Большой VRAM, иногда multi-GPU | Нельзя ориентироваться только на минимальный запуск |
| Генерация изображений | VRAM, storage, стабильность | Лучше проектировать как production-систему |
| Computer Vision | Поток данных, latency, общая сбалансированность | Не всегда нужен топовый GPU |
| Training / fine-tuning | GPU, NVMe, RAM, сеть, межсоединения | Нужен комплексный расчёт |
Частые ошибки при выборе сервера под ИИ
Большинство проблем повторяются. Типичные ошибки такие:
Смотреть только на модель GPU и игнорировать VRAM
Считать только вес модели и забывать про контекст и KV cache
Покупать сервер до пилота
Закладывать “запас” без расчёта SLA
Недооценивать storage
Игнорировать сетевую инфраструктуру
Забывать про охлаждение и питание
Пытаться подобрать один сервер сразу для training и production
Именно эти ошибки чаще всего делают проект дорогим и плохо масштабируемым.
Аренда или покупка: что чаще выгоднее
Если проект только стартует, аренда почти всегда безопаснее. Она позволяет протестировать гипотезы, собрать реальные метрики и понять конфигурацию без капитальных затрат на старте.
Покупка начинает выигрывать там, где нагрузка стабильна, архитектура устоялась, а оборудование планируется использовать долго. Во многих случаях оптимальна гибридная модель: пилоты, обучение и пики — в аренде, production — на выделенной инфраструктуре.
Как на практике подбирают ИИ-инфраструктуру
Подбор сервера начинается не с выбора GPU. Сначала определяют:
- тип модели;
- длину контекста;
- число одновременных запросов;
- требования к latency;
- throughput;
- SLA.
И только после этого становится понятно:
- какой объём VRAM нужен;
- хватит ли одной GPU;
- нужен ли multi-GPU;
- насколько критичен NVMe;
- какие требования к сети.
Именно такой подход позволяет выбрать не просто мощный сервер, а инфраструктуру, которая действительно работает в production.
Вывод
Сервер для ИИ — это не просто мощный GPU. Это правильно собранная система, где учтены модель, объём VRAM, длина контекста, KV cache, storage, сеть, охлаждение и реальная пользовательская нагрузка.
Если выбирать инфраструктуру по одному параметру, почти наверняка получится дорого и неэффективно. Если выбирать по профилю задачи, можно получить систему, которая выдерживает production и даёт понятную экономику.
Поэтому лучший старт — это пилот, профилирование нагрузки и только потом выбор постоянной конфигурации.
Подбираете сервер под ИИ?
В ESTT мы помогаем подобрать инфраструктуру под реальные ИИ-задачи — от первых экспериментов и вайбкодинга до production-инференса, fine-tuning и высоконагруженных AI-сервисов.
У нас доступны серверы с GPU для разных сценариев: локальный запуск LLM, корпоративные AI-ассистенты, RAG-системы, генерация изображений, computer vision и обучение моделей.
Помогаем не просто выбрать видеокарту или конфигурацию, а собрать рабочую инфраструктуру под конкретную модель, объём VRAM, длину контекста, требования к latency и ожидаемую нагрузку.
Нужен сервер под LLM, AI-ассистента или генеративную модель?
Подберём GPU-конфигурацию под вашу задачу, поможем оценить требования к VRAM, storage, сети и подготовить инфраструктуру для стабильной работы в production.
04.05.2026