Как выбрать сервер для инференса LLM в 2026 году и чем он отличается от сервера для обучения

Когда речь заходит о запуске LLM, многие компании до сих пор мыслят логикой обучения: чем больше GPU и выше пиковая производительность, тем лучше. Но для инференса этого уже недостаточно. В продакшене на первый план выходят совсем другие ограничения: объём и пропускная способность памяти, длина контекста, количество параллельных запросов, время до первого токена и стабильность работы под реальной нагрузкой. IBM отдельно подчёркивает, что для LLM inference критичны batching, tensor parallelism и оптимизация KV cache, потому что именно они влияют на память, скорость декодирования и общую стоимость эксплуатации.

Главное отличие простое: обучение и инференс нагружают систему по-разному. Для инференса важно, чтобы модель быстро отвечала на новые запросы и держала нужную нагрузку без резкого роста задержек. Для обучения и fine-tuning требования заметно тяжелее: там выше общий расход памяти, потому что в расчёт идут не только веса модели, но и градиенты, и состояния оптимизатора. В Lenovo прямо указывают, что fine-tuning/training требует существенно больше вычислительных ресурсов, чем inferencing, а объём VRAM для полного обучения может вырастать в разы по сравнению с запуском уже готовой модели.

Из-за этого ошибка “взять сервер как для обучения, но использовать его под inference” почти всегда приводит либо к переплате, либо к неудачному балансу. В инференсе важно не просто купить мощную систему, а подобрать архитектуру под конкретный сценарий: внутренний чат-бот, RAG по корпоративным документам, API для внешних пользователей, аналитический ассистент или агентную систему с длинным контекстом. И здесь уже решают не рекламные характеристики ускорителя сами по себе, а то, как сервер ведёт себя при нужной вам задержке и concurrency.

Одна из самых частых ошибок при подборе — считать только память под веса модели. На практике этого почти никогда недостаточно. Lenovo в своём sizing guide отдельно разбирает, что при инференсе нужно учитывать не только сами параметры модели, но и накладные расходы, а также KV cache. Причём размер KV cache зависит от числа одновременных пользователей, длины контекста, числа слоёв, attention heads и точности. При больших окнах контекста и многопользовательской нагрузке KV cache может вырасти настолько, что станет больше самой модели.

Показательный пример из Lenovo: для Llama 3.3 70B в FP16 при 100 одновременных пользователях и среднем контексте 8000 токенов общий расчётный объём памяти получается около 430 ГБ, из которых примерно 262 ГБ приходится именно на KV cache. Это очень важный практический вывод для бизнеса: если вы планируете не демонстрационный стенд, а реальный сервис с историей диалога, документами и несколькими пользователями сразу, смотреть только на “модель помещается в GPU” уже нельзя.

Для красивой демо-сессии достаточно, чтобы модель просто работала. Для реального сервиса этого мало. Нужно понимать, что вы оптимизируете: минимальную задержку для одного пользователя или максимальную пропускную способность для многих пользователей одновременно. Lenovo прямо пишет, что жёсткое ограничение по first-token latency может заметно ухудшить throughput. То есть чем сильнее вы хотите “мгновенный” отклик, тем меньше система сможет обработать параллельных запросов без роста очереди.

Поэтому хороший сервер под инференс выбирают не по абстрактным TFLOPS, а по реальным сервисным метрикам: TTFT, inter-token latency, tokens per second, request throughput и максимальной concurrency. Если эти параметры не посчитать заранее, можно купить дорогое железо и всё равно получить неудобный пользовательский опыт. Для корпоративных LLM-проектов это одна из самых дорогих ошибок на этапе закупки.

Как только модель или рабочий контекст перестают комфортно жить на одной GPU, резко возрастает значение связности между ускорителями. NVIDIA прямо пишет, что для современных больших моделей multi-GPU compute становится обязательным условием, если нужно одновременно держать приемлемую latency и высокий throughput. Причём даже если модель формально помещается в память одного ускорителя, скорость генерации токенов всё равно зависит от суммарного доступного compute и архитектуры узла.

Отсюда и практический вывод: для тяжёлого inference всё чаще важен не просто сервер с несколькими GPU, а система с быстрым межсоединением. NVIDIA отдельно показывает, что H200 с четвёртым поколением NVLink и третьим поколением NVSwitch ускоряет инференс больших моделей за счёт высокоскоростной связи между всеми GPU внутри сервера, причём такая коммуникация может быть значительно быстрее PCIe Gen5. Именно поэтому для серьёзных LLM-нагрузок логично смотреть не только на отдельные ускорители, но и на готовые плотные GPU-платформы, например Supermicro SYS-821GE-TNHR с поддержкой NVIDIA HGX H100 8-GPU (80GB) и HGX H200 8-GPU (141GB).

Один из самых востребованных серверов в этой категории — Supermicro SYS-821GE-TNHR. Такую систему обычно рассматривают в сценариях, где важны высокая плотность GPU-ресурсов, масштабирование LLM-нагрузки и стабильная работа под серьёзный inference в корпоративной инфраструктуре.

В 2026 году сервер под инференс — это уже не только выбор GPU, но и выбор serving-стека. Red Hat в сравнении vLLM и llama.cpp на NVIDIA H200 показывает, что эти инструменты хороши для разных задач. vLLM заметно лучше масштабируется под многопользовательскую нагрузку, а llama.cpp сильнее в portability и локальных сценариях. В тестах Red Hat при пиковом load vLLM показал более чем в 35 раз выше request throughput и более чем в 44 раза выше output tokens per second по сравнению с llama.cpp, тогда как llama.cpp лучше подходит для одиночных или низкоконкурентных сценариев.

Это означает, что правильно подобранный сервер под LLM — это всегда связка из архитектуры узла, объёма памяти, interconnect и inference-движка. Если выбирать только железо, без понимания реального сценария обслуживания модели, легко получить систему, которая “на бумаге мощная”, но в продакшене не даёт ожидаемого эффекта. Поэтому при подборе инфраструктуры разумнее начинать не с названия GPU, а с задачи: какая модель будет запускаться, какой нужен контекст, сколько будет одновременных запросов и какой отклик допустим для пользователя. А уже после этого подбирать сервер для ИИ под конкретную бизнес-нагрузку, а не “с запасом на всякий случай”.