vLLM и TGI: как не ошибиться с выбором сервера под open-source LLM

Если нужен быстрый и предсказуемый inference, выбор обычно сводится к двум лагерям: vLLM и TGI. Оба умеют раздавать Llama / Qwen / DeepSeek в проде, но оптимизируют разные узкие места.

— vLLM сильнее там, где важны высокий throughput и плотная утилизация GPU. Его сильная сторона — эффективное batch’ирование и работа с длинными очередями запросов.
— TGI часто берут за более «ровный» production-опыт: понятные механики деплоя, удобная интеграция в типовой API-стек, предсказуемое поведение под нагрузкой.
— Если у вас много коротких запросов, главный KPI — tokens/sec на карту. Если запросы длинные и контекст тяжёлый — смотрите не только на скорость генерации, но и на стабильность latency p95.

Критическая ошибка — сравнивать только один замер throughput на пустом сервере. В реальной нагрузке важны:
• размер контекста;
• длина ответа;
• число одновременных сессий;
• KV cache и то, как сервер с ним обращается;
• деградация при росте очереди.

Для маленькой команды правило простое: если нужна максимальная плотность и вы готовы тонко настраивать сервер — начинайте с vLLM. Если важнее типовой production-путь, простота сопровождения и меньше ручной возни — смотрите на TGI.

Лучший тест — не «какой сервер быстрее вообще», а «какой даёт нужный p95 latency и стоимость 1M токенов на вашем профиле запросов».

Fable 5 скоро вернётся в публичный доступ

В исходном коде Claude Code обнаружены упоминания о возвращении модели Fable 5 в публичный доступ с изменённой моделью распространения — её больше не потребуется покупать отдельно, вместо этого будет применяться недельный лимит как для других моделей. Если информация подтвердится, пользователи платных тарифов смогут использовать Fable 5 в рамках своих подписок. Причины снятия ограничений по национальной безопасности остаются неясными. Хотя это п…

➡️ Читайте на сайте: https://aff.top/blog/fable-5-skoro-vernetsia-v-publichnyi-dostup

🧠 Ещё больше инсайтов → в канале AFF.top

Self-hosted выгоден не тогда, когда токен дешевле, а когда у вас есть стабильный поток

Считать надо не «цена API vs своя GPU», а полную себестоимость: железо, амортизация, электричество, хранение весов, оркестрация, запас по отказам, инженерное время. Если модель простаивает, self-hosted почти всегда проигрывает. Если нагрузка ровная и предсказуемая — экономика быстро меняется.

Для расчёта берите 3 метрики:
— tokens/sec на одной GPU при вашем контексте
— среднюю загрузку за сутки, а не пик
— долю запросов, которые реально требуют LLM, а не шаблон
Если у вас 15–20% трафика можно увести в правила, rerank или маленькую модель, дорогой инференс перестаёт быть базой.

Главная ошибка — покупать GPU «под запас», а потом кормить её одним чатом. Вторая ошибка — не считать деградацию на длинном контексте: 32k и 128k на практике дают разную пропускную способность и разный cost per request. Третья — игнорировать latency tail: если p95 падает, бизнесу всё равно на красивый средний throughput.

Считайте точку окупаемости через месячный объём токенов и реальную утилизацию, а не через цену одной тысячи запросов. Если ваш пайплайн уже даёт постоянную нагрузку, self-hosted превращается из «дорого» в «контролируемо».

vLLM или TGI: как выбрать движок для инференса без сюрпризов в проде

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

TGI чаще выбирают там, где важнее предсказуемость и более «прямой» production-путь. У него понятная схема деплоя, удобный стриминг, нормальная интеграция с Hugging Face-экосистемой и меньше неожиданных сюрпризов при базовых сценариях.

Сравнивать их надо не по «какая модель запускается», а по нагрузке:
• много коротких чатов — смотри p50/p95 latency
• длинные промпты и RAG — смотри, как быстро растёт задержка при росте контекста
• высокая конкуренция запросов — считай tokens/sec на GPU, а не только время первого токена
• ограниченная VRAM — тестируй квантизацию и реальный размер батча

Типичная ошибка — мерить только одиночный запрос. В проде один красивый ответ ничего не значит: важнее, сколько одновременных сессий выдерживает сервер без провала latency и OOM. Ещё одна ошибка — не смотреть на длину генерации: движок, который быстрый на 64 токенах, может сильно просесть на 512.

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

vLLM и TGI ломаются не на железе, а на неправильной нагрузке и промптах

Если модель одна и та же, разница между vLLM и TGI чаще всего упирается в профиль трафика: короткие чаты, длинный контекст, много параллельных сессий, стриминг или batch. Перед выбором проверьте три вещи: среднюю длину prompt, среднюю длину completion и пик одновременных запросов.

vLLM обычно выигрывает там, где важны высокий throughput и плотная загрузка GPU: paged attention лучше переживает фрагментацию KV-cache, а continuous batching помогает держать карту занятой. TGI удобнее, когда нужен более предсказуемый продовый сервис, аккуратный streaming и проще контроль вокруг inference-пайплайна.

Практическая ошибка — сравнивать их на одном коротком промпте. На 100–200 токенах разница может быть почти незаметна, а на длинном контексте и очереди из десятков запросов картина меняется: один стек начинает упираться в память, другой — в scheduler. Смотрите не только tokens/sec, но и p95 latency, OOM rate и время ожидания в очереди.

Если строите свой API под прод, тестируйте оба стека на реальном распределении запросов, а не на синтетике. Побеждает не «самый быстрый сервер», а тот, который держит ваш профиль нагрузки без деградации качества и с предсказуемой стоимостью инференса.

Chat GPT-5.6 будут выдавать лишь избранным

США ограничивают публичный доступ к новым ИИ-моделям: теперь его выдают только проверенным пользователям после обязательной 30-дневной процедуры верификации. Сэм Альтман называет это самым быстрым путём к публичному релизу. Эффективность меры вызывает сомнения — китайские разработчики традиционно копируют модели в течение суток после выхода.

➡️ Читайте на сайте: https://aff.top/blog/chat-gpt-5-6-budut-vydavat-lish-izbrannym

🧠 Ещё больше инсайтов → в канале AFF.top

Vk удалили из App store: что дальше?

Удаление VK из App Store заблокировало доступ для владельцев iPhone в России, но проблема решаема. Арбитражники теряют один канал, но не аудиторию — 20–30 млн пользователей iOS остались на месте. Вместо VK стоит переориентироваться на альтернативные источники: Telegram Ads с таргетингом на iOS, push-сети типа AdProfex, MTS Ads и Beeline Ads. VK может последовать примеру Max и запустить PWA-приложение для восстановления уведомлений. Главный вывод…

➡️ Читайте на сайте: https://aff.top/blog/vk-udalili-iz-app-store-chto-dalshe

🧠 Ещё больше инсайтов → в канале AFF.top

Qwen в проде: 5 ошибок, из-за которых модель кажется «слабой» без вины самой модели

Qwen часто ругают за качество, хотя проблема обычно не в весах, а в обвязке: контекст, квантизация, шаблон чата и длина промпта.

— Не путайте instruct и base. Base-модель без правильного system/user шаблона почти всегда проигрывает на прикладных задачах.
— Не кормите её простынёй без структуры. Для Qwen лучше работают короткие инструкции, списки и явные роли, чем длинный «человеческий» текст.
— Не занижайте precision слишком агрессивно. На 4-bit квантизации на сложных многошаговых задачах быстрее ловится деградация логики и формата ответа.
— Не тестируйте только на коротком контексте. Модель может выглядеть стабильной на 2–4k токенов, а дальше начинать терять связь между блоками.
— Не сравнивайте разные семейства без одинакового prompt template. У Qwen формат диалога критичен: одинаковый вопрос, но разная разметка — и метрика уже плывёт.

Если нужен честный тест, сравнивайте модели на одном наборе: извлечение фактов, строгое форматирование, многошаговый reasoning, длинный контекст.

Чаще всего Qwen «чинится» не дообучением, а нормальным шаблоном, адекватной квантизацией и правильным бенчмарком.

DeepSeek в проде ломается не на “качестве”, а на неправильном выборе режима инференса

У DeepSeek сильная сторона — хороший баланс reasoning/код/инструменты, но в проде его часто ставят как “универсальную” модель и получают лишнюю задержку и перерасход GPU.

Если нужен быстрый чат или автодополнение — смотрите на маленькие dense-версии и агрессивную квантизацию. Если нужен сложный reasoning — берите более крупную модель, но сразу закладывайте: контекст держать длинным, а batch — умеренным, иначе latency растёт скачком.

Для self-hosted стека важны три вещи:
— vLLM: лучший вариант, когда нужен высокий throughput и нормальная работа с batching
— TGI: удобен для стабильного API и предсказуемого поведения под нагрузкой
— llama.cpp: полезен для локальных и дешёвых сценариев, но не для максимального QPS

Отдельно проверьте prompts: у DeepSeek чувствительность к формату выше, чем у многих “чатовых” моделей. Короткий системный промпт, жёсткая структура ответа и ограничение на длину часто дают больше, чем попытка “докрутить” модель ещё одним GPU.

Если модель не укладывается в SLA, проблема обычно не в ней, а в связке размер модели + квантизация + сервер. Сначала меряйте tokens/sec и p95 latency, потом уже принимайте решение, что резать.

Когда брать Gemma, а когда Mistral: 4 критерия, которые экономят недели тестов

Если смотреть на open-source LLM как на продовый инструмент, а не на «лучшую модель по ощущениям», выбор обычно ломается о 4 оси: качество, скорость, лицензия, инфраструктура.

— Gemma чаще удобна, когда нужен компактный inference и предсказуемая работа на ограниченной VRAM. Для edge-сценариев и локальных ассистентов это частый кандидат.
— Mistral обычно интереснее, если важны сильный общий интеллект и хорошее поведение в instruction-задачах при адекватной цене инференса.
— Для короткого контекста обе линейки могут быть очень эффективны, но длинный контекст нельзя считать «бесплатным»: после роста окна резко падает throughput, а latency уходит в хвост.
— Квантизация меняет картину сильнее, чем кажется: fp16 даёт максимум качества, но int4/gguf часто выигрывают по стоимости и плотности размещения на GPU.

Главная ошибка — выбирать модель по одному бенчмарку. Для продакшена важнее прогнать свой набор: генерация, классификация, extraction, tool-calls, длинный диалог. Именно там видно, где модель ошибается системно.

Отдельно смотрите на лицензии и ограничения использования: для коммерческого проекта это не формальность, а часть P&L.

Правильный выбор здесь не «лучшая модель», а модель с лучшим trade-off под вашу VRAM, latency и задачу.