#маршрутизация_запросов — Public Fediverse posts

RPS одинаковый, но p95 по TTFT хуже в 2,7 раза: что round-robin делает с KV-cache

В замере Red Hat два балансировщика распределяли один и тот же чат-трафик между четырьмя GPU NVIDIA L4. По числу обработанных запросов в секунду результаты почти совпали: 0,52 у обычного round-robin и 0,49 у маршрутизации с учётом префиксов. Но p95 времени до первого токена различался в 2,7 раза: 745 мс у round-robin против 272 мс у prefix-aware routing. GPU, модель и нагрузка в обоих прогонах были одинаковыми, менялся только способ выбора реплики. Счётчик RPS этого не показывает: он учитывает обращения, но не работу, которую под выполняет для конкретного запроса. Если нужный префикс уже лежит в KV-cache, модель начинает генерацию быстрее. Если запрос попадает в соседнюю реплику без этого состояния, ей приходится заново считать всю голову запроса. Этот разбор посвящён выбору реплики для self-hosted LLM-инференса в Kubernetes. Он пригодится инженерам, которые запускают модели на нескольких GPU, и владельцам платформ, оценивающим нагрузку по загрузке карт и числу запросов. Для контуров с одной репликой вопрос маршрутизации не возникает; порог применимости разобран отдельно. Все примеры основаны на публичных замерах разных команд. Я рассматриваю задачу со стороны инфраструктуры: как маршрутизация влияет на использование GPU, задержки и требования к Kubernetes-контуру. VK Tech предоставляет GPU-ноды и vGPU для развёртывания таких систем.

https://habr.com/ru/companies/vktech/articles/1082026/

#vk_cloud #kubernetes #облако #vk_tech #LLMинференс #KVcache #маршрутизация_запросов #prefixaware_routing #GPU #vLLM

Что умеет и где ломается Jev: большое тестирование

В работе с моделями важно не только знать их точность, скорость и цену, но и понимать, где им можно доверять, а где нужна дополнительная проверка. Многие ограничения обнаруживаются уже в процессе интеграции — и о них хотелось бы знать заранее. Тестирование Jev я проводил прежде всего для себя и команды, но объём данных получился масштабным, и я решил поделиться результатами с сообществом. С 19 по 30 сентября 2026 года было проведено 22 эксперимента и отправлено около 160 тысяч запросов к jev-1.13.0 и контрольным моделям OpenAI. Все тесты запускались через API раннего доступа и суммарно обошлись примерно в $18 . Мне было интересно не столько проверить заявленные скорость и цену, сколько найти границы её практического применения. Насколько она точна по сравнению с небольшими GPT-моделями? Можно ли доверять её confidence и строить на нём автоматический роутинг? Что произойдёт при расширении списка классов, появлении длинного контекста, грязного входа или текста на другом языке? У LLM уже известны свои особенности — например, lost in the middle и склонность уверенно ошибаться. Логично было проверить, есть ли собственный набор таких эффектов у System One модели на примере Jev.

https://habr.com/ru/articles/1089164/

#jev #классификация_текста #языковые_модели #тестирование_моделей #калибровка_уверенности #zeroshot #обработка_естественного_языка #маршрутизация_запросов #llm

Один Telegram‑бот, три сервиса, один 301: как я сделал webhook‑router вместо монолита

У Telegram-бота может быть только один активный webhook. У меня при этом появились три независимых сценария: поддержка пользователей, управление небольшим магазином и внутренние административные команды. Склеивать их в один процесс не хотелось, заводить отдельного бота под каждый сервис — тоже. Пока я выбирал архитектуру, переезд панели с одного домена на другой неожиданно провёл бесплатный chaos test: Telegram продолжил отправлять updates на старый адрес, получил 301 Moved Permanently и перестал доставлять сообщения. В очереди зависло шесть updates, а со стороны пользователей бот просто замолчал. В статье разберу диагностику этого инцидента и устройство небольшого open-source router на FastAPI и Redis: с декларативными правилами, дедупликацией, надёжной очередью, retry и HMAC-подписью внутренних запросов.

https://habr.com/ru/articles/1078924/

#Telegram_Bot_API #webhook #FastAPI #Redis #Python #HMAC #идемпотентность #очереди_сообщений #маршрутизация_запросов #Docker

Service Desk — дружелюбный сосед: как мы настраивали единую точку входа для поддержки в банке

Service Desk редко воспринимают как что-то героическое. Обычно о нём вспоминают тогда, когда что-то перестало работать, нужно получить доступ к системе или просто непонятно, куда отправить запрос. Но в большом банке Service Desk — это не просто форма для создания заявок. Это единая точка входа для сотрудников, механизм маршрутизации задач и источник данных для анализа работы поддержки. Сегодня наша система обрабатывает в среднем 3,5 тысячи обращений в месяц , из которых 550-600 задач приходится непосредственно на команду Service Desk. В этой статье расскажу, как Service Desk используется в Своем Банке, с какими проблемами мы столкнулись после запуска и что удалось улучшить в процессе эксплуатации.

https://habr.com/ru/companies/svoi_ru/articles/1074774/

#service_desk #поддержка #itsm #поддержка_пользователей #маршрутизация_запросов #оптимизация_процессов #метрики_поддержки #банковские_технологии

Сократили пол-поддержки — 6 инструментов, чтобы разгрузить тех, кто остался

29% компаний уже урезали ИТ-бюджеты — и это при том, что сам ИТ-сектор растет и занимает уже 2,2% ВВП России . Вот такая новая реальность: задач становится больше, а рук меньше. И тут возникает замкнутый круг, знакомый многим, кто работал в поддержке. Команды сокращают — поток обращений растет. Оставшиеся инженеры тонут в тикетах, выгорают и увольняются. Выход из положения — снять часть возросшей нагрузки. В статье разберем шесть инструментов сервис деска, которые помогут делать больше меньшей командой.

https://habr.com/ru/companies/itarena/articles/1065398/

#сервис_деск #service_desk #автоматизация_рутины #техподдержка #производительность_труда #портал_самообслуживания #маршрутизация_запросов #автоматизация_процессов

Упрощаем работу с микросервисами при помощи API Gateway на Java

Микросервисы легко разрастаются до зоопарка эндпоинтов, где каждый сервис живёт по своим правилам, а клиенту приходится знать обо всех. В статье разберем, как API Gateway превращает этот хаос в единую точку входа: берёт на себя маршрутизацию, аутентификацию, агрегацию запросов и наблюдаемость. На простом примере с Spring Cloud Gateway рассмотрим, как собрать такой слой поверх Java-сервисов и упростить жизнь и разработчикам, и внешним потребителям API. Разобраться с Gateway

https://habr.com/ru/companies/otus/articles/968028/

#java #microservices #api_gateway #микросервисная_архитектура #Spring_Cloud_Gateway #маршрутизация_запросов #аутентификация #авторизация #балансировка_нагрузки

[Перевод] Маршрутизация LLM: оптимизация путей обработки языка

В стремительно развивающемся мире искусственного интеллекта большие языковые модели (LLM) стали мощными инструментами, способными понимать и генерировать текст, близкий к человеческому. По мере роста их сложности и масштаба критичной становится эффективная организация путей обработки. Маршрутизация LLM — это стратегическое распределение и оптимизация вычислительных ресурсов внутри таких систем. По сути, это выбор того, каким путём проходит входной текст через различные компоненты/ветки, чтобы получить максимально точный и релевантный результат. Умно направляя промпты и балансируя нагрузку, маршрутизация повышает эффективность, отзывчивость и общую производительность языковых моделей.

https://habr.com/ru/articles/963700/

#llm #ai #llmмодели #mtbench #latency #artificial_intelligence #data_augmentation #маршрутизация_запросов

Что скрывает ваш API Gateway

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

https://habr.com/ru/companies/otus/articles/944940/

#API_Gateway #микросервисы #микросервисная_архитектура #Spring_Boot #Spring_Cloud_Gateway #маршрутизация_запросов #аутентификация_и_авторизация #rate_limiting