Inference-серверы: как выбрать движок для LLM в production

Команда разворачивает первую большую языковую модель в production, и на стенде всё работает гладко: один запрос — один ответ, задержка в пределах секунды. Но проходит неделя после запуска, и картина меняется — запросы копятся в очереди, GPU то простаивает, то захлёбывается под всплеском нагрузки, а автомасштабирование не успевает поднять новый инстанс достаточно быстро, чтобы снять этот всплеск. При этом дело не в модели: она отвечает так же, как отвечала на стенде. Проблема в слое между приложением и моделью — том самом, где происходит обработка запросов, формируется очередь, решается батчинг и распределяется видеопамять, и именно этот слой не выдерживает реальной нагрузки. Называют его inference-сервером, и от того, какой вариант выбран — vLLM, Ollama, SGLang или Hugging Face TGI, — зависит, во сколько обойдётся продакшен и переживёт ли он пиковую нагрузку.

Разберём, чем инференс отличается от обучения как инженерная задача, из каких компонентов складывается inference-сервер и в чём на практике расходятся эти четыре варианта.

Почему запуск LLM — отдельная инженерная задача

Обучение модели — разовые капитальные затраты: кластер GPU арендуется или покупается на конкретный срок, прогоняется набор экспериментов, получается набор весов. После обучения процесс не повторяется до следующей версии модели. Инференс устроен иначе — он идёт непрерывно и превращается в постоянные операционные расходы, которые растут с каждым новым запросом и с каждым сгенерированным токеном. Команда, переносящая опыт обучения на инференс, обычно недооценивает именно эту разницу: на этапе обучения задача — довести модель до нужного качества один раз, на этапе эксплуатации — обслуживать поток запросов сотнями или тысячами в минуту, укладываясь в бюджет по GPU-часам и в SLA по задержке. Обучение оптимизируют под пропускную способность одного длинного прогона, инференс — под задержку и стоимость каждого отдельного запроса.

Какие проблемы возникают в production

• Высокая стоимость GPU. Видеокарты для инференса больших моделей стоят дорого и часто арендуются по часам, поэтому простаивающий GPU — прямые потери, а не абстрактная неэффективность.
• Очереди запросов. При параллельных обращениях запросы выстраиваются в очередь на обработку, и без управления ею задержка у поздних запросов растёт непредсказуемо.
• Низкая утилизация GPU. При редких запросах и наивной реализации сервера видеокарта большую часть времени простаивает, ожидая следующий запрос, вместо того чтобы обрабатывать несколько параллельно.
• Масштабирование. Всплеск нагрузки требует поднять новый инстанс с моделью, но холодный старт LLM занимает минуты, а не секунды, поэтому автомасштабирование по загрузке CPU не успевает за пиком — практика для очередей на инференс — масштабировать по глубине очереди запросов
• Отказоустойчивость. Один упавший инстанс с моделью — это потеря значимой доли ёмкости кластера, поэтому резервирование и graceful-деградация становятся частью архитектуры, а не опцией.

Что такое inference server

Inference server — слой между приложением и моделью, который принимает запрос по сети, готовит его для модели, следит за очередью и видеопамятью и возвращает ответ. Технически это не одна программа с одной функцией, а набор компонентов: HTTP-эндпоинт, токенизатор, батчинг-скедулер, GPU-скедулер и менеджер KV Cache. У vLLM, Ollama, SGLang и TGI этот набор один и тот же — серверы различаются реализацией скедулера и кэша.

HTTP-эндпоинт чаще всего собран как OpenAI-совместимый API: приложение обращается к серверу так же, как обращалось бы к API OpenAI, через /v1/chat/completions, и сервер под капотом можно поменять без переписывания клиентского кода. У vLLM для этого есть отдельный режим vllm serve, у Ollama — эндпоинт /v1, SGLang и TGI тоже поддерживают этот интерфейс. Токенизатор переводит текст запроса в токены модели — это первый шаг обработки любого запроса. Батчинг-скедулер решает, какие запросы объединить в один проход по модели: в continuous batching батч не «закрывается», пока не завершены все последовательности, освободившееся место сразу занимает новый запрос, и GPU не простаивает в ожидании конца батча. GPU-скедулер распределяет вычисления между параллельными запросами на уровне видеокарты. Менеджер KV Cache хранит промежуточные состояния внимания по уже сгенерированным токенам — это главный потребитель видеопамяти при инференсе, и то, как сервер этой памятью управляет (PagedAttention у vLLM, RadixAttention у SGLang), определяет, сколько параллельных запросов сервер выдержит на одной видеокарте.

vLLM

vLLM — open-source inference-сервер, ядро которого построено вокруг одной задачи: эффективное управление KV Cache при параллельной обработке множества запросов. Кэш, а не веса модели, обычно первым упирается в потолок памяти GPU по мере роста батча: чем больше одновременных диалогов держит сервер, тем быстрее заканчивается место под их контексты. Большинство оптимизаций vLLM так или иначе решают именно эту проблему, а не ускоряют сами матричные вычисления модели. Вокруг ядра выстроены слой API, планировщик батчей и подсистема квантизации, которые формируют законченный inference-стек, а не набор разрозненных библиотек, которые приходится собирать самостоятельно.

PagedAttention

PagedAttention управляет KV Cache по аналогии с виртуальной памятью операционной системы: кэш нарезается на блоки фиксированного размера, «страницы», а не выделяется одним непрерывным куском под предполагаемую максимальную длину последовательности. До PagedAttention сервер резервировал под каждый запрос непрерывный блок памяти, рассчитанный на максимально возможную длину генерации, даже если реальный ответ модели укладывался в несколько десятков токенов. Разница между зарезервированным и фактически использованным пространством и составляла фрагментацию: память была занята, но простаивала. С PagedAttention память выделяется по мере генерации токенов, блок за блоком, и высвобождается сразу после завершения запроса. При parallel sampling и beam search, когда несколько вариантов ответа делят общий префикс, блоки этого префикса не копируются, а разделяются через reference counting: несколько последовательностей ссылаются на одни и те же физические страницы вместо того, чтобы каждая хранила свою копию. Экономия памяти на таких сценариях доходит до 55%. Метод описан командой UC Berkeley в статье, представленной на SOSP 2023, и лёг в основу vLLM.

Continuous batching

Наивная реализация батчинга ждёт, пока завершатся все последовательности в батче, прежде чем принять новые запросы: короткая генерация простаивает, ожидая самую длинную, а GPU часть времени работает вхолостую. Continuous batching (его также называют iteration-level scheduling) убирает это ожидание — как только любая последовательность в батче завершена, освободившееся место сразу занимает следующий запрос из очереди. В связке с PagedAttention это даёт прирост throughput в 2–4 раза по сравнению с оптимизированными системами предыдущего поколения — так сформулирован результат в оригинальной статье о PagedAttention, где базой сравнения были Orca и FasterTransformer, а не наивный инференс. В блоге самого проекта приводится и более контрастная цифра — до 24 раз против базового инференса на Hugging Face Transformers на части сценариев. С учётом chunked prefill (разбиение длинного prefill на части, чтобы не блокировать декодирование других запросов) и prefix caching (переиспользование KV Cache для повторяющихся системных промптов) выигрыш ещё растёт. Цифры ориентировочные: конкретный прирост зависит от модели, длины контекста и профиля нагрузки, и на другом сочетании параметров разрыв может быть меньше или больше.

OpenAI API, multi-GPU и tensor parallel

Команда vllm serve поднимает сервер с OpenAI-совместимым эндпоинтом: запросы к vLLM отправляются тем же клиентом, что и к API OpenAI, без переписывания интеграции. Для multi-GPU конфигураций служит параметр tensor_parallel_size: tensor parallelism распределяет один слой модели между несколькими GPU, это нужно, когда модель не помещается в память одной карты. Отдельно поддерживается LoRA, включая режим fully sharded, когда адаптер распределён между устройствами так же, как базовая модель. Из инструментов экономии памяти и ускорения: FP8-квантизация аппаратно ускоряется на NVIDIA H100, даёт около 2-кратной экономии памяти и до 1,6 раза прирост throughput при минимальной потере точности, также поддерживаются AWQ (4-бит) и GPTQ — оба снижают требования к памяти ценой части качества генерации. Для снижения задержки декодирования vLLM поддерживает speculative decoding: модельные методы вроде EAGLE, где вспомогательная модель предлагает несколько токенов вперёд, а основная проверяет их за один проход, и безмодельные, вроде n-gram, которые не требуют отдельной вспомогательной модели.

Плюсы и минусы

Сильная сторона vLLM — экосистема: поддержка большинства архитектур моделей, широкий набор оптимизаций (квантизация, speculative decoding, tensor parallelism) и зрелость проекта — актуальная версия v0.24.0 вышла 28.06.2026. OpenAI-совместимый API упрощает миграцию существующих интеграций, а активная разработка означает быстрое появление поддержки новых архитектур. Минусы — обратная сторона той же гибкости: развёртывание и тюнинг сложнее, чем у Ollama, конфигурация требует понимания параметров батчинга и памяти GPU, а ошибка в расчёте tensor_parallel_size или размера батча оборачивается либо нехваткой памяти, либо простаивающим железом. Без GPU сервер малополезен: CPU-инференс поддерживается, но сильно ограничен по производительности и не рассчитан на прод.

Когда использовать

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

Ollama

Ollama — обёртка над llama.cpp. Один бинарник совмещает HTTP-сервер, инференс-луп и API: там, где у vLLM это отдельные подсистемы вокруг общего ядра, у Ollama всё собрано в единый процесс, который проще установить и проще остановить. Модели хранятся в формате GGUF: квантованные веса и метаданные упакованы в один файл, формат разработан в экосистеме llama.cpp. Такой формат снимает часть возни с раздельными файлами конфигурации, токенизатора и весов — модель можно скопировать на другую машину одним файлом. Ollama работает и на CPU, и на GPU, но спроектирована прежде всего для локального запуска: на ноутбуке или рабочей станции разработчика, а не в промышленном кластере с общим пулом видеокарт.

Преимущества

Главное преимущество Ollama — простота: одна команда поднимает модель без настройки батчинга, памяти GPU или планировщика запросов. Это делает Ollama быстрым стартом для прототипа — от установки до первого ответа модели проходят минуты, а не часы разбора конфигурации inference-сервера. Локальный запуск на ноутбуке или рабочей станции снимает зависимость от облачного GPU на этапе эксперимента: гипотезу можно проверить до того, как под неё выделят инфраструктуру. Смена модели сводится к смене одного файла GGUF, поэтому сравнение нескольких моделей на одной задаче не требует пересборки сервера или отдельного окружения под каждую. Есть и OpenAI-совместимый эндпоинт /v1: он принимает запросы от существующих клиентских библиотек без переписывания кода приложения, что упрощает переключение между локальной моделью и облачным API на этапе разработки, но сам Ollama описывает эту поддержку как начальную и экспериментальную.

Ограничения

Ollama не рассчитана на высокую конкурентность и высоконагруженный прод. Параллелизм ограничен слотами: переменная OLLAMA_NUM_PARALLEL задаёт число одновременных слотов, и каждый слот резервирует свою часть KV Cache независимо от остальных, вне зависимости от того, заняты они реальными запросами или простаивают в ожидании следующего. Это архитектурно ближе к наивному батчингу, который PagedAttention и continuous batching у vLLM как раз обходят через общий пул памяти вместо жёстко нарезанных слотов. По практическим наблюдениям инженерных команд, при устойчивой нагрузке от 16–20 параллельных запросов continuous batching у vLLM обгоняет Ollama по throughput за счёт совместного использования памяти между запросами вместо жёсткого резервирования слотов под каждый из них. Дело не в том, что Ollama написана хуже: она просто не проектировалась под этот сценарий и не решает задачу разделения памяти между конкурентными запросами.[datarekha]

Кластеризация в Kubernetes — не основной сценарий использования Ollama: официального Helm-чарта нет, сообщество поддерживает community-чарт otwld/ollama-helm, а значит, ответственность за обновления, совместимость версий и поддержку в проде ложится на команду, а не на разработчиков Ollama. При росте нагрузки и переходе от прототипа к продакшену это обычно и становится точкой, где команды пересматривают выбор в пользу vLLM или другого специализированного inference-сервера с готовыми паттернами масштабирования.

Когда подходит

Ollama подходит для локальной разработки и прототипирования: быстрые эксперименты с разными моделями и версиями без обращения к общему GPU-кластеру, приложения с малым числом одновременных пользователей, где параллелизм не критичен, офлайн- и приватный запуск без выхода во внешнюю сеть, когда данные не должны покидать периметр компании или устройство пользователя. Это же делает Ollama удобной для обучения и демонстраций: развернуть модель на встрече или воркшопе можно за то время, пока для vLLM ещё выбирают GPU-инстанс.

SGLang

SGLang — высокопроизводительный serving-фреймворк для LLM и мультимодальных моделей, разработку курирует LMSYS Org — команда, стоящая за Chatbot Arena и Vicuna. От vLLM SGLang отличает в первую очередь подход к управлению KV Cache: вместо кэша на уровне отдельного запроса здесь работает RadixAttention.

RadixAttention

vLLM хранит KV Cache постранично и привязывает страницы к конкретному запросу. SGLang устроен иначе: планировщик держит общее радиксное дерево (radix tree), в узлах которого лежат уже посчитанные фрагменты KV Cache для всех обработанных запросов. Когда приходит новый запрос, планировщик ищет в дереве самый длинный совпадающий префикс, переиспользует его кэш и досчитывает только токены, которых в дереве ещё нет.

Разница проявляется там, где запросы разделяют общий текст в начале: системный промпт, few-shot примеры, история многоходового диалога, извлечённый контекст в RAG. Для vLLM каждый такой запрос — отдельный проход через полный префикс, для SGLang повторяющаяся часть считается один раз и переиспользуется деревом, а вычислительная нагрузка приходится на действительно новые токены.

Зачем появился и agent workloads

SGLang изначально проектировался под нагрузки, где префиксы повторяются, а ответ модели должен укладываться в жёсткий формат: агентские сценарии, цепочки reasoning, генерация строгого JSON под внешний API. Structured output в SGLang обслуживают несколько бэкендов: XGrammar используется по умолчанию, также доступны Outlines и llguidance. Грамматика целевого формата компилируется в конечный автомат (FSM), и там, где грамматика однозначно допускает продолжение, за один шаг декодируется сразу несколько токенов, а не один.

В README проекта заявлен такой набор возможностей: RadixAttention, планировщик с нулевым накладным расходом на CPU (zero-overhead CPU scheduler), разделение стадий prefill и decode между разными группами GPU (prefill-decode disaggregation), speculative decoding, continuous batching и paged attention.

Speculative decoding

Команда SGLang развивает spec decoding отдельным направлением. Открытый фреймворк SpecForge предназначен для тренировки draft-моделей на архитектуре EAGLE3 — небольших моделей-подсказчиков, которые прогнозируют несколько токенов вперёд, а основная модель проверяет их за один проход. В июле 2026 года команда анонсировала гибридный метод DSpark, объединяющий несколько техник speculative decoding в одном движке.

Производительность

По независимым обзорным замерам на GPU NVIDIA H100 SGLang показывал throughput около 16 200 токенов в секунду против примерно 12 500 у vLLM — разница около 29%. Это не официальные цифры проекта, а результат стороннего теста (модель Llama 3.1 8B на H100) на конкретной конфигурации: модель, версия GPU, дата прогона — переносить их на свою нагрузку без проверки не стоит. На батчах с уникальными, не пересекающимися промптами разрыв между движками почти исчезает, а на prefix-heavy нагрузках, вроде RAG и многоходовых диалогов, вырастает многократно: именно там работает RadixAttention. Прежде чем закладывать конкретный процент в план мощностей, стоит прогнать оба движка на своей модели и своём трафике.

Когда использовать

SGLang имеет смысл выбирать для agent-платформ, RAG-систем, многоходовых диалогов и сценариев со строгим форматом ответа: везде, где запросы делят общий префикс, а структурированный вывод не опция, а требование. Именно в этих условиях RadixAttention даёт наибольший эффект, а XGrammar и другие structured-output бэкенды снимают нагрузку с постобработки ответа.

Hugging Face TGI

Text Generation Inference (TGI) — inference-сервер от Hugging Face, исторически обслуживал сервисы самой компании: HuggingChat, Inference API, Inference Endpoints. Технически TGI построен на ядре, написанном на Rust, с Python-биндингами для интеграции. Сервер поддерживает стриминг токенов, tensor parallelism, continuous batching, отдаёт OpenAI-совместимые эндпоинты и экспортирует метрики в Prometheus и OpenTelemetry.

Особенности и лицензионная история

У TGI был заметный лицензионный поворот. Версии до 1.0 распространялись под Apache 2.0. С выходом версии 1.0 летом 2023 года Hugging Face ввела собственную лицензию HFOIL 1.0, которая ограничивала перепродажу TGI как платного hosted-сервиса третьими лицами. Решение вызвало резонанс в сообществе: часть пользователей восприняла его как отход от открытой модели разработки. Позже компания вернула лицензию на Apache 2.0, под которой репозиторий распространяется и сейчас.

Актуальный статус: проект свёрнут

Это ключевой факт для тех, кто выбирает движок сегодня. На июль 2026 года репозиторий TGI архивирован владельцем: архивация прошла 21 марта 2026 года, репозиторий переведён в режим read-only. В maintenance mode проект перешёл ещё раньше, в декабре 2025 года: с этого момента принимаются только мелкие багфиксы и правки документации, разработка новых функций остановлена. Последний релиз — v3.3.7 от 19 декабря 2025 года.

Hugging Face прямо рекомендует переходить на движки-преемники: vLLM и SGLang, а для локального запуска — на llama.cpp или MLX. Представитель Hugging Face Lysandre Debut сформулировал это в декабре 2025 года так: «text-generation-inference is now in maintenance mode. Going forward, we will accept pull requests for minor bug fixes, documentation improvements and lightweight maintenance tasks».

Когда использовать

Для новых проектов TGI разворачивать не стоит — об этом прямо говорит сама Hugging Face. Практический смысл TGI сохраняет только для команд, которые уже эксплуатируют его в проде: у них есть время на плановую миграцию на vLLM или SGLang, а не необходимость срочного переезда из-за внезапного отказа инфраструктуры. Исторический вклад TGI в инференс весомый: он одним из первых сделал continuous batching и tensor parallelism стандартом production-серверов для LLM, и путь оптимизаций, который он начал, продолжают нынешние движки, включая vLLM и SGLang.

Большое сравнение inference-серверов

Таблица показывает набор функций сервера, но не их вес. У Ollama нет continuous batching вовсе, движок обрабатывает запросы последовательно, и для одного разработчика за ноутбуком это не создаёт проблем, а для десятков параллельных пользователей превращается в узкое место. PagedAttention у vLLM и RadixAttention у SGLang — это не строки в списке возможностей, а разные подходы к работе с KV Cache: память под контекст выделяется страницами вместо непрерывного блока, а у SGLang дополнительно переиспользуется между запросами с общим префиксом. Для CPU-инференса, RAG-пайплайна с повторяющимся системным промптом или чата с сотнями активных сессий это меняет экономику GPU кардинально, а не на проценты.

Строка «TGI» заслуживает отдельного разбора. Формально в таблице у него закрыты почти все технические пункты: OpenAI-совместимый API, continuous batching, PagedAttention (на CUDA-кернелах проекта vLLM), multi-GPU, Kubernetes, Tensor Parallel. По голому набору галочек TGI выглядит наравне с vLLM и SGLang, но графа «готовность к production» перечёркивает всё остальное: проект архивирован 21 марта 2026 года, а сама Hugging Face прямо рекомендует переходить на vLLM или SGLang. Для нового проекта архивный статус означает отсутствие security-патчей, отсутствие поддержки новых моделей и архитектур, отсутствие ответа на issue в репозитории. Разбирать TGI по остальным строкам таблицы для новой инсталляции просто не имеет смысла: инструмент с открытыми галочками, но закрытым будущим, не выбирают.

Строка «CPU-инференс» показывает обратный случай: там, где Ollama получает единственную безусловную галочку среди четырёх серверов, vLLM, SGLang и TGI отмечены «ограниченно» — работают, но не для той нагрузки, ради которой их проектировали. У SGLang с середины 2025 года есть отдельный CPU-бэкенд для процессоров Intel Xeon с AMX (dense- и MoE-модели), но это специализированный сценарий на конкретном железе, а не замена основного GPU-пути: RadixAttention и структурированный вывод через XGrammar по-прежнему рассчитаны в первую очередь на GPU-инференс с высокой конкурентностью.

Отдельный урок таблицы: production-готовность складывается не только из throughput. Эксплуатация (логи, метрики, обновления), масштабирование под Kubernetes, зрелость экосистемы (готовые Docker-образы, интеграции, комьюнити) весят не меньше, чем цифры токенов в секунду. Сервер с идеальным PagedAttention, но без внятного Kubernetes-деплоя, добавит команде эксплуатационных проблем ровно там, где ожидался выигрыш в скорости.

Как выбрать решение

Локальная разработка и прототип

Ollama остаётся первым выбором для локальной разработки. Модель запускается одной командой, формат GGUF и движок llama.cpp работают на обычном ноутбуке без выделенной GPU-инфраструктуры, а низкая конкурентность (один разработчик, редкие запросы) не требует continuous batching или PagedAttention. Для гипотезы, демо или тестирования промптов это самый быстрый путь от идеи к работающему чату: не нужно поднимать кластер, настраивать балансировку нагрузки, разбираться с Tensor Parallel.

Корпоративный чат

Для внутреннего чата на десятки одновременных пользователей архитектура Ollama не рассчитана: без continuous batching GPU быстро упирается в очередь запросов. vLLM закрывает эту нагрузку continuous batching и PagedAttention: память под KV Cache выделяется динамически, а планировщик подмешивает новые запросы в уже идущий батч, не дожидаясь завершения текущего. Добавляет вес зрелая экосистема: готовые интеграции с Kubernetes, широкая поддержка моделей и оборудования NVIDIA, устоявшиеся паттерны эксплуатации.

AI Agent Platform и RAG

Для агентных пайплайнов и RAG характерна повторяемость: системный промпт почти не меняется, контекст между запросами пересекается. Здесь RadixAttention у SGLang даёт прямой эффект: общие префиксы переиспользуются вместо повторного пересчёта, что экономит и память, и время. Structured output через XGrammar добавляет второй аргумент: агенту часто нужен строго типизированный JSON-ответ, а не свободный текст, и SGLang рассчитан на этот сценарий на уровне архитектуры, а не как надстройку поверх.

Экосистема Hugging Face

Раньше выбор внутри экосистемы Hugging Face автоматически падал на TGI: единый вендор, готовая интеграция с хабом моделей. После архивации проекта 21 марта 2026 года логика изменилась: сама Hugging Face рекомендует переходить на vLLM или SGLang в зависимости от профиля нагрузки. Для локального инференса в той же экосистеме остаются llama.cpp и MLX (для оборудования Apple).

Высоконагруженный inference

Под максимальный throughput на большом парке GPU vLLM закрывает наибольшее число паттернов масштабирования: Tensor Parallel, multi-GPU, зрелая поддержка Kubernetes. Если нагрузка prefix-heavy (повторяющиеся системные промпты, батчи схожих запросов), к сравнению стоит добавить SGLang: RadixAttention в этом сценарии снижает нагрузку на память заметнее, чем выигрыш vLLM в чистом throughput.

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

Типичные ошибки при запуске LLM

Ollama в production под реальной конкурентной нагрузкой — инструмент, спроектированный для прототипа на одном устройстве, выводят на прод-трафик с десятками пользователей. Без continuous batching запросы обрабатываются по очереди, задержка растёт линейно с числом одновременных обращений, и то, что выглядело быстрым в демо, превращается в очередь на проде.

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

Одна GPU без управления очередью — при пиковой нагрузке без планировщика запросов задержка становится непредсказуемой: часть запросов обслуживается мгновенно, часть зависает в ожидании, и разброс времени ответа мешает строить SLA.

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

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

Как построить инфраструктуру inference в VK Cloud

Продуктивный inference-кластер — это не один сервер с моделью, а цепочка слоёв, и у каждого своя задача.

Балансировщик нагрузки принимает запросы и распределяет их между подами. Kubernetes оркестрирует эти поды: запускает, перезапускает при сбое, масштабирует по нагрузке. В подах работает inference-сервер (vLLM или SGLang) с загруженной моделью. Под сервером стоит пул GPU-нод — физический ресурс для вычислений. Веса моделей и чекпоинты хранятся в объектном хранилище, откуда под подгружает их при старте. Параллельно работают три вспомогательных слоя: мониторинг на Prometheus и Grafana собирает метрики throughput, задержки и утилизации GPU, Redis кэширует повторяющиеся запросы и хранит состояние сессий, PostgreSQL хранит метаданные моделей, логи запросов и историю диалогов.

Каждый слой закрывает конкретный сервис VK Cloud.

• Оркестрацию берёт на себя Cloud Containers, управляемый Kubernetes с сертификацией CNCF Certified Kubernetes, стандартным API и встроенным мониторингом Prometheus и Grafana; кластер настраивается через Terraform, интеграция с Object Storage работает из коробки.
• Вычислительный слой — Cloud GPU. Под крупные модели с tensor parallel подходят NVIDIA H200 с 141 ГБ видеопамяти и конфигурации Bare Metal GPU на базе H200 с сетью Infiniband до 400 Гбит/с. Под модели среднего размера — L40S на 48 ГБ, L4 на 24 ГБ, A100 на 40 или 80 ГБ. Для инференса небольших моделей и прототипов, когда целая карта избыточна, используется vGPU as a Service с выделением от 2 до 16 ГБ видеопамяти под задачу.
• VK Object Storage (S3-совместимое хранилище) хранит веса моделей и чекпоинты.
• Container Registry хранит образы inference-серверов и интегрирован в кластеры.
• Managed PostgreSQL и Managed Redis закрывают слой метаданных и кэша без самостоятельного администрирования баз.
• Managed-мониторинг на Prometheus и Grafana собирает метрики throughput, задержек и утилизации GPU.

Отдельный вопрос — автоскейлинг. Штатный HPA в Kubernetes масштабирует поды по CPU или памяти, но для inference эта метрика вводит в заблуждение: сервер способен загружать GPU на 90% и выше, тогда как CPU занят на единицы процентов. Рабочий паттерн — KEDA (event-driven autoscaler), масштабирование по кастомной метрике из Prometheus, например по глубине очереди запросов (num_requests_waiting), с ограничением по p95-задержке; KEDA поддерживает scale-to-zero. Планирование GPU-нод в кластере закрывает NVIDIA GPU Operator (device plugin, GPU Feature Discovery, DCGM Exporter) с режимами time-slicing и MIG для разделения одной карты между несколькими подами.

Для VK Cloud Казахстан есть отдельная специфика размещения. Инфраструктура физически расположена в ЦОД в Астане уровня Tier III. Персональные данные хранятся на территории Республики Казахстан согласно закону № 94-V, расчёты ведутся в тенге. Для inference-сервисов, обрабатывающих обращения граждан (чат-боты госуслуг, финтех-приложения), локализация ПДн — практическое требование к архитектуре, а не формальность в договоре.

Заключение

Универсального inference-сервера нет. Ollama подходит для локальной разработки и экспериментов: быстрый старт, минимум настройки. vLLM — рабочий выбор для большинства production-сценариев с непрерывным потоком запросов. SGLang раскрывается на agent-нагрузках, RAG и structured output с повторяющимися префиксами в промптах, где RadixAttention даёт выигрыш. Hugging Face TGI архивирован: для новых проектов не подходит, сама Hugging Face рекомендует переходить на vLLM или SGLang. Выбор определяется профилем нагрузки, доступной инфраструктурой и требованиями к масштабированию, а не абстрактным рейтингом бенчмарков.