TGViewer
DevOps Deflope News DevOps Deflope News @devops_deflope · 5.84K subscribers
Post #1592 4.87K
Чтобы каждая реплика LLM приходила за миллисекунды и не разоряла бюджет на GPU, инфраструктура должна быть столь же умной, как сама модель.

Сегодня для этого есть два зрелых Open Source-движка — vLLM и SGLang. Оба уже служат базой для корпоративных продуктов Red Hat и LMSYS, поэтому технологический риск минимален. Ниже — как каждый из них помогает бизнесу экономить и в каких сценариях их применять.

Почему это важно прямо сейчас? Стоимость GPU-минут растёт, а объём запросов к моделям увеличивается экспоненциально, что напрямую бьёт по TCO AI-инициатив.

vLLM — максимум пропускной способности
• PagedAttention устраняет 60-80% фрагментации памяти через блочные таблицы (как виртуальная память в ОС), давая до ×24 больше throughput, чем Hugging Face Transformers.
• Continuous Batching обрабатывает запросы по шагам генерации. Таким образом быстрые не ждут медленных, снижается latency и пропадает простой GPU (〜x23 прирост пропускной способности).
• Совместимость с OpenAI API позволяет мигрировать SaaS-сервисы без переписывания клиентского кода.

Именно vLLM лежит в основе Red Hat AI Inference Server для OpenShift, так что решение готово к production-кластерам. А ещё LMSYS сократил
парк
GPU на 50 %, одновременно увеличив число обслуживаемых запросов в 2–3 раза после миграции на vLLM.


SGLang — это экономия на связанных запросах
• RadixAttention строит древовидную структуру для переиспользования KV-кеша между запросами с общими префиксами. Если пользователь ведёт диалог, SGLang автоматически переиспользует уже вычисленные части контекста, ускоряя цепочки вызовов до ×5 и снижая вычислительные затраты.
• Строго заданный вывод: можно жёстко задать JSON-схему или грамматику, избегая дорогой поствалидации.
• Оптимальный выбор для диалоговых агентов, RAG-конвейеров и других сценариев, где соседние запросы делят контекст и важна точная структура ответа.


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

Итого
Разверните оба движка в одной инфраструктуре: vLLM — на «горячем» пути API для массовых запросов, SGLang — в сервисах с многошаговыми генерациями. Так вы получите быстрые ответы при минимальной стоимости GPU; именно то, что нужно бизнесу здесь и сейчас.
  • 👍 16
  • ❤ 4
  • ❤‍🔥 3
More from @devops_deflope
  1. Aug 31, 2026Cloudflare открыла исходный код Cloudflare OS, платформы, которую сами используют внутри к…
  2. Aug 27, 202622 октября в Москве пройдёт Kuber Conf от АОТ — уже второй раз. АОТ — ассоциация профессио…
  3. Aug 18, 2026Прикольная штука для сетей в Kubernetes. Умеет докручивать то, чего не хватает underlay-CN…
  4. Aug 11, 2026Образ не меняется. Меняется то, что мы о нём знаем)) Собрали, просканировали, получили зел…
  5. Aug 2, 2026Возвращаемся в подкаст DevOps Deflope с выпуском, где вместе с Игорем Курочкиным (Enabling…
  6. Jul 31, 2026Коллеги, ситуация. Отчётов и исследований сейчас по нашей теме выходит много, а времени пр…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →