Как рассчитать конфигурацию GPU-сервера для LLM: видеопамять, количество GPU, NVMe и сеть
Подбор GPU-сервера для LLM нельзя сводить только к вопросу «сколько поставить видеокарт». Для больших языковых моделей важна не одна характеристика, а связка параметров: объём видеопамяти, пропускная способность памяти, количество GPU, тип interconnect, скорость NVMe, объём RAM, сетевая инфраструктура и сценарий эксплуатации. Один и тот же сервер может отлично подходить для тестового запуска модели, но оказаться слабым для production-инференса с длинным контекстом и десятками параллельных пользователей.
Именно поэтому при выборе сервера для ИИ сначала нужно считать нагрузку, а уже потом подбирать железо. В GetCore можно купить сервер для ИИ под конкретную задачу: инференс LLM, обучение нейросетей, RAG, корпоративный чат-бот, векторный поиск, fine-tuning или гибридную AI-инфраструктуру. Ниже разберём, как подойти к расчёту конфигурации экспертно: от видеопамяти и количества GPU до NVMe-хранилища и сети.
С чего начинается расчёт GPU-сервера для LLM
Первый этап — не выбор между A100, H100 или H200, а описание рабочей нагрузки. Ошибка многих проектов в том, что сервер подбирают «с запасом по видеокартам», но без понимания, как именно будет использоваться модель. В результате GPU могут простаивать из-за медленного хранилища, нехватки RAM, слабой сети или неправильно выбранной архитектуры сервера.
Перед расчётом нужно ответить на несколько вопросов:
какая модель будет использоваться: 7B, 13B, 34B, 70B, 100B+;
в какой точности она будет запускаться: FP16/BF16, INT8, INT4, GPTQ, AWQ, FP8;
нужен ли только инференс или также fine-tuning/обучение;
какой максимальный контекст нужен: 8k, 32k, 128k токенов и выше;
сколько пользователей или запросов будет обрабатываться одновременно;
что важнее: минимальная задержка ответа или максимальная пропускная способность;
будет ли RAG, векторная база, поиск по документам, работа с файлами;
планируется ли масштабирование до нескольких серверов.
Например, локальный запуск модели 7B для внутренних тестов и production-инференс 70B-модели с длинным контекстом — это совершенно разные задачи. В первом случае может хватить одного GPU и умеренного NVMe. Во втором уже нужно считать суммарную видеопамять, KV cache, скорость обмена между GPU, запас под batch и требования к сети.
Если задача связана именно с промышленной эксплуатацией LLM, лучше сразу рассматривать не отдельную видеокарту, а полноценный сервер с GPU для ИИ, где согласованы GPU, CPU, RAM, NVMe, охлаждение, блоки питания и сетевые интерфейсы.
Главный параметр для LLM — видеопамять, а не только производительность GPU
Для LLM объём видеопамяти часто важнее пиковых TFLOPS. Большая языковая модель должна физически поместиться в память GPU вместе с рабочими структурами, кэшем и служебными данными inference-движка. Если памяти не хватает, появляются OOM-ошибки, приходится использовать агрессивное квантование, offload в RAM или разбивать модель между несколькими GPU.
Базовая логика простая: память под веса модели примерно равна количеству параметров, умноженному на размер одного параметра. В FP16/BF16 один параметр занимает около 2 байт. Поэтому модель 7B в FP16 потребует примерно 14 ГБ только под веса, 13B — около 26 ГБ, 70B — около 140 ГБ. Но это только первая часть расчёта.
К весам модели нужно добавить:
KV cache;
память под batch;
служебные буферы inference-движка;
память под CUDA/runtime;
запас под фрагментацию и пики нагрузки;
память под адаптеры, если используется LoRA/fine-tuning;
память под дополнительные компоненты пайплайна.
Особенно важно учитывать KV cache. При генерации LLM не пересчитывает весь контекст заново на каждом шаге, а хранит промежуточные key-value представления в памяти. Чем длиннее контекст и чем больше параллельных запросов, тем больше видеопамяти занимает KV cache. Поэтому модель, которая формально «помещается» в GPU по весам, может не работать стабильно в реальном production-сценарии.
Упрощённо можно считать так:
Итоговая VRAM = память под веса модели + KV cache + batch + служебный запас
Для тестов иногда допустимо считать почти впритык. Для production лучше оставлять запас 20–30%, особенно если нагрузка неравномерная, есть длинные запросы, RAG, разные размеры промптов и несколько типов пользователей.
Почему KV cache резко меняет расчёт сервера
KV cache — одна из главных причин, почему LLM-инференс становится всё более требовательным к видеопамяти. При коротком контексте его влияние может быть умеренным, но при 32k, 64k или 128k токенов кэш превращается в один из основных потребителей VRAM.
Для бизнеса это особенно важно. Корпоративные LLM-сценарии редко ограничиваются короткими промптами. Чаще модель должна работать с регламентами, договорами, внутренней документацией, переписками, базами знаний, инструкциями, отчётами и техническими файлами. Чем больше данных передаётся в контекст, тем выше требования к памяти.
Примерно логика такая:
короткий чат-бот с контекстом 4k–8k требует меньше VRAM;
ассистент по документам с контекстом 32k–64k требует заметно больше памяти;
long-context inference на 128k токенов может упереться в KV cache даже на дорогих GPU;
при росте числа параллельных пользователей KV cache масштабируется почти линейно.
Отсюда важный вывод: сервер для LLM нужно считать не только по размеру модели, но и по реальному сценарию диалога. Если один пользователь отправляет короткий запрос, это одна нагрузка. Если 20 пользователей одновременно работают с длинными документами через RAG — это уже совсем другой профиль.
Prefill и decode: почему одна LLM-нагрузка может вести себя по-разному
LLM-инференс состоит из двух разных фаз: prefill и decode. На этапе prefill модель обрабатывает входной контекст: промпт, документы, историю диалога, системные инструкции. Эта фаза хорошо параллелится и сильнее нагружает вычислительные блоки GPU. На этапе decode модель генерирует ответ токен за токеном, и здесь чаще проявляются ограничения по памяти, пропускной способности и работе с KV cache.
Это важно для расчёта сервера. Если у вас длинные входные документы и относительно короткие ответы, нагрузка будет одной. Если короткие запросы, но длинная генерация — другой. Если одновременно много пользователей, нужно смотреть на batch, планировщик запросов, очереди и эффективность inference-движка.
Для production-инференса нужно учитывать не только «сколько токенов в секунду выдаёт модель», но и:
latency первого токена;
скорость генерации последующих токенов;
число одновременных сессий;
длину входного контекста;
среднюю и пиковую длину ответа;
возможность continuous batching;
работу с кэшем;
SLA по времени ответа.
Например, для внутреннего корпоративного ассистента можно пожертвовать небольшой задержкой ради экономии инфраструктуры. А для публичного AI-сервиса с большим числом пользователей важнее стабильная задержка и предсказуемый throughput.
Как определить нужное количество GPU
Количество GPU рассчитывается после оценки памяти и профиля нагрузки. Нельзя просто сказать, что для LLM всегда нужно 4 или 8 GPU. Иногда достаточно одной карты, а иногда даже 8 GPU используются не из-за «избыточной мощности», а потому что модель и KV cache не помещаются в меньшую конфигурацию.
В простом виде логика такая:
Сценарий
Типичная конфигурация
Комментарий
Тесты, прототипы, небольшие модели 7B/13B
1 GPU
Подходит для разработки, проверки гипотез, внутренних экспериментов
Корпоративный чат-бот, RAG на умеренной нагрузке
1–2 GPU
Важно считать контекст, batch и скорость NVMe
Production-инференс 34B/70B
2–4 GPU
Часто требуется tensor parallelism и запас VRAM
Long-context LLM, много пользователей
4–8 GPU
KV cache и interconnect становятся критичными
Обучение, fine-tuning крупных моделей
4–8 GPU и выше
Важны NVLink/NVSwitch, RAM, storage и сеть кластера
Если модель помещается в память одной GPU с запасом, один ускоритель может быть оптимальным решением. Например, для моделей 7B/13B, embedding-моделей, reranker, небольших RAG-сценариев или внутренней разработки нет смысла сразу переплачивать за 8-GPU платформу.
Если модель не помещается в память одной GPU или нужна высокая пропускная способность, используются несколько GPU. Здесь важна не только суммарная память, но и то, как быстро видеокарты обмениваются данными. Две GPU по 80 ГБ — это не то же самое, что одна условная GPU на 160 ГБ. При разделении модели появляются накладные расходы на коммуникацию.
Для серьёзных LLM-нагрузок стоит рассматривать серверы уровня Supermicro SYS-420GH-TNR или Supermicro SYS-820GP-TNR 8X SXM, если проекту нужна высокая плотность GPU, поддержка SXM-платформ и масштабирование под AI/HPC-задачи.
PCIe или SXM: почему форм-фактор GPU влияет на производительность
При выборе GPU важно смотреть не только на модель ускорителя, но и на форм-фактор. У NVIDIA A100, H100 и H200 встречаются PCIe- и SXM-варианты. На бумаге это может выглядеть как одна и та же видеокарта, но в серверной архитектуре разница существенная.
PCIe-варианты удобны для более гибких и часто более доступных конфигураций. Они подходят для многих inference-задач, тестов, RAG, небольших и средних LLM, а также проектов, где важна разумная стоимость входа. Например, для ряда сценариев можно рассматривать NVIDIA H100 80GB PCIe или NVIDIA A100 80GB PCIe.
SXM-платформы чаще выбирают там, где нужна максимальная производительность, высокая плотность GPU и быстрый обмен между ускорителями. Это особенно важно для обучения, fine-tuning, больших моделей и multi-GPU inference. В таких системах ключевую роль играет NVLink/NVSwitch, а не только сама GPU.
Для LLM это принципиально: если модель разделена между несколькими GPU, задержки обмена между ними напрямую влияют на скорость. При слабом interconnect можно получить ситуацию, когда дорогие GPU простаивают, ожидая данные друг от друга.
H100, H200, A100: как выбирать GPU под LLM
Выбор GPU зависит от задачи, бюджета и горизонта эксплуатации. A100 всё ещё может быть рациональным вариантом для ряда AI-задач, особенно если проект не требует максимальной плотности и новейшей памяти. H100 остаётся сильным решением для обучения, инференса и production-нагрузок. H200 интересен там, где важны увеличенный объём памяти и высокая пропускная способность, особенно для больших моделей и long-context inference.
Упрощённо можно ориентироваться так:
GPU
Когда рассматривать
NVIDIA A100 40GB
Тесты, CV/NLP, умеренный inference, проекты с ограниченным бюджетом
NVIDIA A100 80GB
LLM среднего размера, RAG, обучение и fine-tuning в разумном бюджете
NVIDIA H100 80GB
Production-инференс, обучение, высокие требования к скорости
NVIDIA H200 141GB
Большие модели, длинный контекст, более высокий запас по VRAM
Для задач, где критичен объём видеопамяти, стоит отдельно рассмотреть NVIDIA H200 141GB SXM или NVIDIA H200 141GB NVL. Увеличенная память даёт больше пространства под веса модели, KV cache, batch и длинный контекст.
Но важно не делать выбор только по принципу «чем новее, тем лучше». Если задача — обслуживать embedding-модель, reranker или небольшую LLM, H200 может быть избыточной. Если же планируется 70B-модель, большой контекст и много параллельных пользователей, экономия на VRAM может привести к ограничениям уже на старте.
Почему нельзя считать только суммарную видеопамять
Распространённая ошибка — сложить память всех GPU и считать, что модель автоматически будет работать как на едином ускорителе. Например, 4 GPU по 80 ГБ дают 320 ГБ суммарной VRAM, но это не означает, что любая модель будет работать без ограничений. Нужно учитывать способ параллелизации, interconnect, inference-движок, поддержку tensor parallelism и накладные расходы.
При multi-GPU запуске возможны разные подходы:
tensor parallelism — слои и матричные операции делятся между GPU;
pipeline parallelism — разные части модели размещаются на разных GPU;
data parallelism — копии модели работают на разных GPU для увеличения throughput;
hybrid parallelism — комбинация нескольких подходов.
Для инференса LLM чаще всего важны tensor parallelism и эффективный планировщик запросов. Если сервер используется для обучения или fine-tuning, требования к обмену между GPU становятся ещё выше. Поэтому в задачах обучения и крупных моделей платформы с NVLink/NVSwitch обычно предпочтительнее обычных PCIe-сборок.
GPU — главный элемент LLM-сервера, но не единственный. Если CPU, оперативная память или PCIe-линии подобраны неправильно, вся система может работать хуже, чем ожидается. Особенно это заметно в сценариях с RAG, большим количеством документов, предобработкой данных, API-слоем, векторной базой и несколькими сервисами на одном сервере.
CPU отвечает за:
подготовку входных данных;
работу API и очередей запросов;
обслуживание inference-движка;
взаимодействие с хранилищем;
сетевые операции;
работу векторной базы или сопутствующих сервисов;
часть операций при offload.
Для одного GPU-сервера под тесты может хватить умеренной CPU-конфигурации. Для 4–8 GPU уже нужны серверные процессоры с достаточным количеством PCIe-линий, ядер и пропускной способностью памяти. В противном случае GPU будут ждать данные, а не выполнять вычисления.
RAM тоже нужно считать с запасом. Для простого inference-сервера может хватить 256–512 ГБ, но для серьёзных LLM/RAG-сценариев часто разумнее закладывать 512 ГБ, 1 ТБ или больше. Если используются большие датасеты, CPU-offload, векторные индексы, кэширование документов и несколько моделей, экономить на RAM не стоит.
NVMe: почему хранилище влияет на скорость LLM-сервера
NVMe-хранилище часто недооценивают. На практике оно влияет на загрузку моделей, работу с датасетами, RAG, векторные индексы, логи, чекпоинты, временные файлы и скорость восстановления после перезапуска. Если storage медленный, дорогие GPU могут простаивать.
Для LLM-сервера NVMe важен в нескольких сценариях:
Загрузка модели Большие модели занимают десятки и сотни гигабайт. Медленный диск увеличивает время старта сервиса, деплоя и переключения между моделями.
RAG и векторный поиск Если система работает с корпоративными документами, embedding-индексами и базой знаний, storage становится частью production-нагрузки.
Fine-tuning и обучение Датасеты, чекпоинты, промежуточные состояния и логи могут занимать терабайты. Слабое хранилище превращается в узкое место.
Мультисервисная среда Если на сервере одновременно работают inference API, vector database, monitoring, data pipeline и несколько моделей, случайные операции чтения/записи становятся критичными.
Практический подход такой:
Сценарий
NVMe-конфигурация
Тестовый LLM-сервер
2–4 ТБ NVMe под ОС, модели и окружение
Production inference
4–8 ТБ NVMe с запасом под модели, логи и обновления
RAG / корпоративная база знаний
8–30 ТБ NVMe в зависимости от объёма документов и индексов
Обучение / fine-tuning
15–60+ ТБ NVMe, отдельное хранение датасетов и чекпоинтов
Для сервера под LLM лучше использовать enterprise NVMe, а не потребительские SSD. Важны не только пиковые скорости, но и ресурс записи, стабильность под нагрузкой, тепловой режим и предсказуемость задержек.
Если проект предполагает дальнейший рост, стоит заранее закладывать платформу, где можно масштабировать хранилище, добавить диски, разделить системный контур и данные, а также вынести часть storage на отдельный узел.
Сеть: 10/25/100/200/400 GbE, InfiniBand и реальная нагрузка
Сетевая часть зависит от того, как используется сервер. Для одного изолированного LLM-сервиса внутри компании требования могут быть умеренными. Для кластера, обучения, распределённого inference или работы с внешним storage сеть становится критически важной.
Нужно разделять несколько типов сетевой нагрузки:
пользовательские запросы к API;
обмен между приложением и inference-сервером;
доступ к векторной базе;
загрузка документов и датасетов;
синхронизация между узлами;
хранение чекпоинтов;
мониторинг и логирование;
межсерверный обмен при распределённых вычислениях.
Для небольшого inference-сервера может быть достаточно 10/25 GbE. Для production-нагрузки с RAG, несколькими сервисами и активной работой с данными лучше рассматривать 25/100 GbE. Для обучения, multi-node GPU-кластеров и высокоскоростного storage могут потребоваться 100/200/400 GbE или InfiniBand.
Важно понимать: сеть не всегда ограничивает саму генерацию токенов, но она может ограничивать весь pipeline. Например, если документы, индексы или датасеты лежат на внешнем хранилище, медленная сеть увеличит задержки. Если несколько GPU-серверов работают в кластере, слабый interconnect между узлами резко снижает эффективность масштабирования.
Как считать конфигурацию под RAG
RAG — один из самых популярных корпоративных сценариев LLM. Здесь модель не просто отвечает из своих весов, а получает релевантные фрагменты из базы знаний: документы, инструкции, регламенты, переписки, карточки товаров, технические спецификации. Поэтому сервер под RAG нужно считать шире, чем обычный inference.
В RAG-нагрузке есть несколько компонентов:
LLM для генерации ответа;
embedding-модель для векторизации документов;
reranker для уточнения релевантности;
векторная база;
парсер и пайплайн загрузки документов;
API-слой;
хранилище исходных файлов;
кэширование;
мониторинг и логирование.
Если всё это размещается на одном сервере, требования к CPU, RAM, NVMe и сети возрастают. GPU может быть достаточно для самой LLM, но система будет тормозить из-за поиска, индексации, медленного storage или нехватки оперативной памяти.
Для RAG лучше закладывать:
GPU с достаточным запасом VRAM под LLM и batch;
отдельный ресурс под embedding/reranking;
быстрые NVMe под индексы и документы;
RAM с запасом под векторную базу и кэш;
сеть не ниже 25 GbE для production, если есть внешние сервисы;
возможность вынести storage или vector DB на отдельный сервер при росте нагрузки.
Для таких задач можно рассматривать не просто одну GPU-карту, а сервер с GPU, где конфигурация подбирается под полный AI-пайплайн, а не только под запуск модели.
Примеры расчёта конфигурации под разные LLM-сценарии
Ниже — ориентировочные сценарии. Они не заменяют инженерный расчёт, но помогают понять логику подбора.
Сценарий 1. Внутренние тесты LLM и разработка
Задача: запуск моделей 7B/13B, тестирование промптов, проверка RAG, разработка прототипа.
Подходящая конфигурация:
1 GPU A100 40/80GB или H100 80GB PCIe;
128–512 ГБ RAM;
2–4 ТБ NVMe;
10/25 GbE;
один или два CPU в зависимости от платформы.
Такой сервер подходит для команды разработки, пилотного проекта, проверки бизнес-гипотез и начального внедрения LLM. Главное — не закладывать его как финальную production-платформу, если в будущем планируется рост модели, контекста и числа пользователей.
Сценарий 2. Корпоративный ассистент на базе LLM
Задача: внутренний чат-бот, ответы по базе знаний, интеграция с документами, умеренная параллельная нагрузка.
Подходящая конфигурация:
1–2 GPU H100 80GB или H200 141GB;
512 ГБ – 1 ТБ RAM;
4–12 ТБ enterprise NVMe;
25/100 GbE;
запас по CPU под API, RAG и обработку документов.
Здесь важно считать не только модель, но и всю обвязку: embeddings, reranking, vector DB, индексацию и хранение документов. Если нагрузка растёт, embedding и векторную базу можно выносить на отдельные узлы.
Сценарий 3. Production-инференс 70B-модели
Задача: стабильная работа крупной LLM, несколько пользователей, контроль latency, длинные запросы.
Подходящая конфигурация:
2–4 GPU H100/H200;
желательно SXM-платформа при высокой нагрузке;
1 ТБ RAM и выше;
8–15 ТБ NVMe;
100 GbE;
inference-движок с continuous batching и эффективной работой KV cache.
Для 70B-моделей особенно важно считать KV cache. Формально веса модели могут помещаться в определённый объём памяти, но длинный контекст и параллельные пользователи быстро увеличивают потребление VRAM. Поэтому H200 с большим объёмом памяти может быть интереснее H100 в задачах, где упор идёт не только в вычисления, но и в память.
Сценарий 4. Высоконагруженный LLM-инференс
Задача: AI-сервис, большое число запросов, длинный контекст, SLA по задержке, несколько моделей.
Подходящая конфигурация:
4–8 GPU H100/H200 SXM;
NVLink/NVSwitch;
1–2+ ТБ RAM;
15–30+ ТБ NVMe;
100/200/400 GbE;
отдельный storage-контур;
мониторинг GPU, очередей, токенов, latency и KV cache.
Здесь уже стоит рассматривать серверы уровня Supermicro SYS-820GP-TNR 8X SXM или другие 8-GPU платформы, если проект требует высокой плотности ускорителей и масштабирования.
Сценарий 5. Fine-tuning и обучение
Задача: дообучение моделей, LoRA/QLoRA, обучение на корпоративных данных, эксперименты с архитектурами.
Подходящая конфигурация:
4–8 GPU H100/H200 SXM;
быстрый interconnect между GPU;
1–2+ ТБ RAM;
15–60+ ТБ NVMe;
100/200/400 GbE или InfiniBand при multi-node;
отдельная стратегия хранения датасетов и чекпоинтов.
Для обучения критична не только VRAM, но и скорость обмена между GPU. Если interconnect слабый, масштабирование может оказаться неэффективным: добавление GPU не даст ожидаемого прироста.
Частые ошибки при подборе GPU-сервера для LLM
Первая ошибка — считать только память под веса модели. В реальности нужно учитывать KV cache, batch, служебные буферы и запас под пиковую нагрузку. Особенно это критично для long-context inference.
Вторая ошибка — выбирать GPU без понимания сценария. Для одних задач достаточно A100 или H100 PCIe, для других нужна H200 SXM и HGX-платформа. Переплата за топовую GPU не всегда оправдана, но экономия на видеопамяти может быстро ограничить проект.
Третья ошибка — игнорировать NVMe. Если модели, индексы, датасеты и документы читаются с медленного хранилища, GPU будут простаивать. В AI-серверах storage — это не второстепенный элемент.
Четвёртая ошибка — недооценивать сеть. Для одиночного сервера это может быть не так заметно, но для RAG, кластеров, внешнего storage и multi-node обучения сеть становится критическим фактором.
Пятая ошибка — не закладывать масштабирование. Если проект стартует с одной модели, но через полгода нужно добавить вторую, увеличить контекст, подключить RAG и обслуживать больше пользователей, изначально слабая платформа может потребовать полной замены.
Шестая ошибка — собирать сервер из несовместимых компонентов. GPU, корпус, питание, охлаждение, PCIe-линии, BIOS, драйверы, сетевые карты и storage должны работать как единая система. Поэтому для бизнеса часто рациональнее выбирать серверы с GPU, а не экспериментировать с самостоятельной сборкой.
Практическая методика расчёта
Чтобы рассчитать конфигурацию GPU-сервера для LLM, можно идти по следующей схеме.
Сначала определите модель и точность. Например, 13B в FP16, 70B в INT4 или 70B в FP16 — это разные требования к VRAM. Затем оцените максимальный контекст и число параллельных запросов. После этого нужно прибавить KV cache и запас под batch.
Далее выбирается GPU: A100, H100, H200, PCIe или SXM. Если модель помещается в одну GPU с запасом — можно начинать с single-GPU. Если не помещается или нужна высокая производительность — переходим к 2/4/8 GPU и считаем interconnect.
После этого рассчитываются CPU и RAM. Здесь важно не брать минимальную конфигурацию «лишь бы запустилось». LLM-сервер почти всегда работает в окружении API, очередей, логов, мониторинга, RAG, векторных баз и пайплайнов обработки данных.
Затем подбирается NVMe. Нужно учитывать не только текущий размер модели, но и будущие версии, датасеты, индексы, чекпоинты, логи и временные файлы. Для production лучше закладывать enterprise NVMe и резервирование.
Последний этап — сеть и масштабирование. Если сервер будет один, требования проще. Если планируется кластер, внешний storage, несколько AI-сервисов или обучение на нескольких узлах, сеть должна быть рассчитана заранее.
Когда лучше выбрать готовую платформу Supermicro
Готовые GPU-серверы Supermicro удобны тем, что они изначально проектируются под высокую плотность GPU, корректное питание, охлаждение, совместимость ускорителей и стабильную работу под нагрузкой. Это особенно важно для AI-инфраструктуры, где ошибка в корпусе, блоках питания или охлаждении может ограничить производительность всей системы.
Для LLM и AI-нагрузок можно рассматривать разные классы решений:
1–2 GPU серверы — для разработки, inference, RAG и пилотных проектов;
4 GPU серверы — для production-инференса, fine-tuning и корпоративных AI-сервисов;
8 GPU серверы — для обучения, больших моделей, high-load inference и масштабируемой инфраструктуры.
Например, Supermicro SYS-422GA-NRT может быть интересен для GPU-нагрузок, где важны расширяемость и современная серверная платформа. Для более плотных AI-конфигураций стоит рассматривать модели уровня Supermicro SYS-420GQ-TNGR GPU или 8-GPU SXM-системы.
GetCore помогает подобрать конфигурацию не «по названию видеокарты», а под реальную задачу: тип модели, нагрузку, бюджет, требования к latency, storage, сети и масштабированию. Это особенно важно, если сервер покупается не для экспериментов, а для production-эксплуатации.
Вывод
Расчёт GPU-сервера для LLM начинается не с выбора самой дорогой видеокарты, а с анализа нагрузки. Нужно понимать размер модели, точность, длину контекста, число параллельных пользователей, требования к latency, наличие RAG, объём данных и планы масштабирования.
Для небольших моделей и тестов может хватить одного GPU. Для production-инференса 70B, long-context сценариев и корпоративных AI-сервисов уже нужны 2–4 GPU, быстрый NVMe, достаточный объём RAM и продуманная сеть. Для обучения, fine-tuning и высоконагруженного inference стоит рассматривать 4–8 GPU SXM-платформы с быстрым interconnect.
Главный принцип простой: LLM-сервер должен быть сбалансированным. Если выбрать мощные GPU, но сэкономить на памяти, NVMe, сети или охлаждении, инфраструктура не даст ожидаемой производительности. Поэтому перед покупкой лучше рассчитать конфигурацию под конкретную модель и сценарий эксплуатации.