LLM-инференс (vLLM, SGLang)
Тема дорожной карты · MLOps
Сервинг больших языковых моделей — отдельная дисциплина внутри model serving: у LLM автогрессивная генерация (модель прогоняется заново на каждый токен), огромный KV-cache в памяти GPU и непредсказуемая длина ответов. Классические серверы вроде Triton с обычным динамическим батчингом здесь работают плохо. Де-факто стандарт 2026 года — vLLM (дефолтный движок в Hugging Face Inference Endpoints и большинстве self-hosted стеков) и SGLang; для локальной разработки и маленьких моделей популярны llama.cpp и Ollama, а у NVIDIA есть TensorRT-LLM для максимальной производительности на своих GPU.
Как это работает
Два ключевых приёма отличают LLM-серверы от классических. Первый — continuous batching: вместо того чтобы ждать, пока весь батч закончит генерацию, сервер добавляет и убирает запросы из батча на каждой итерации генерации — GPU не простаивает, пока один длинный ответ дописывается. Второй — управление KV-cache: vLLM ввёл PagedAttention, который хранит кэш внимания страницами, как виртуальную память ОС, убирая фрагментацию и позволяя держать в разы больше параллельных запросов на том же GPU. SGLang добавил RadixAttention — префиксное дерево, переиспользующее KV-cache между запросами с общим началом (системный промпт, few-shot примеры), что даёт заметный выигрыш на агентных нагрузках с повторяющимися префиксами.
Обе системы выставляют OpenAI-совместимый HTTP API, поэтому миграция между ними (и с облачных API на self-hosted) обычно сводится к замене базового URL. Метрики, специфичные для LLM-сервинга: TTFT (time to first token), inter-token latency и токены в секунду на GPU — обычные p95 по запросу мало о чём говорят.
Когда применять
Разворачивайте vLLM/SGLang, когда нужен self-hosted инференс открытых моделей: требования локализации данных (для РФ это типовой случай), предсказуемая стоимость под постоянной нагрузкой или тонкий контроль над моделью (LoRA-адаптеры, кастомные штрафы). SGLang стоит попробовать при агентных нагрузках с длинными повторяющимися префиксами. llama.cpp/Ollama — для локальной разработки и CPU/edge-сценариев. Если нагрузка спорадическая, а данные можно отдавать наружу — облачный API дешевле, чем простаивающий GPU-сервер.
Типичные ошибки
Классика — сервить LLM через FastAPI + model.generate(): без continuous batching GPU утилизируется на единицы процентов, и один A100 держит худший трафик, чем vLLM на карте вдвое дешевле. Вторая ошибка — не следить за KV-cache: длинные контексты съедают память нелинейно, и сервер начинает вытеснять (preempt) запросы — мониторьте метрику использования кэша. Третья — сравнивать движки по чужим бенчмаркам: производительность сильно зависит от модели, длин промпта/ответа и GPU; гоняйте свой профиль нагрузки. И не забывайте пиннить версии: движки развиваются очень быстро, и минорное обновление может поменять и производительность, и качество выдачи.
Связанные понятия
Полезные ресурсы
Проверить знания (2)
Загрузка вопросов…