Комментарии 5
Спасибо за практический разбор. В проде я бы добавил к сравнению vLLM и SGLang еще один обязательный слой: метрики нужно снимать не только по средней скорости генерации. Для каждого профиля нагрузки полезно разделять TTFT и ITL, смотреть p95/p99, длину входа и выхода, длину живого KV-кэша, queue time и долю запросов с cache hit. Иначе prefix caching легко выглядит победителем на среднем сценарии, но проигрывает на длинном хвосте или при смешении коротких и длинных запросов.
Еще важен тест с реальным распределением запросов: общий system prompt, повторные диалоги, отмены, burst после простоя и одновременная деградация одной GPU. Тогда выбор движка становится не спором о benchmark tokens/sec, а расчетом стоимости и качества сервиса: latency budget, throughput на одну карту и цена одного полезного ответа.
Резюме от Опус 5 (который позавчера выпустили) и я с ним согласен:
добротный конспект чужих статей, надевший костюм инженерного отчёта. Если бы автор заменил половину теории одним графиком «наш вот такой сервис, вот такая модель, вот что дал переход с vLLM на SGLang» — вышел бы текст, которого больше нигде не прочитаешь. А так это пересказ документации с корпоративным логотипом.
Выглядит как сюр, купить 8карт H100 чтобы гонять на них Qwen3.6-35B.
Дешевле было бы каждому выдать по RTX3090 чтобы локально запускали эту LLM.
Инференс LLM: от KV-кэша до продакшен-деплоя