В этом материале
Проверка выбора воркера по локальности префикса, очереди и устаревшим сведениям о блоках без смешивания с маршрутизацией между моделями.
Воркер, уже хранящий контекст запроса, способен избежать части повторного prefill. Но направление всех связанных запросов на него создаёт очередь. KV-aware routing должен сопоставлять сэкономленные вычисления с ожиданием и передачей состояния. Это механизм выбора воркера внутри инфраструктуры сервинга, отличный от выбора другой модели или другого коммерческого провайдера приложением. Высокая доля знакомых префиксов сама по себе ещё не означает хороший пользовательский результат.
Определите знания маршрутизатора
Обзор маршрутизатора Dynamo описывает выбор по сведениям о состоянии сервинга. Считайте эти сведения оценкой меняющейся системы. Между решением и исполнением блоки вытесняются, воркеры перезапускаются, а очередь запросов успевает вырасти.
Опишите происхождение наблюдений кэша и нагрузки, допустимый возраст данных и конфигурацию модели на объявленных воркерах. Уверенное решение по устаревшим сведениям способно проиграть более простой политике со свежей очередью. Идентичность кэша и границы арендаторов должны совпадать с правилами исполняющих компонентов.
Согласуйте границу хэширования
Документация KV-aware routing указывает требования координации маршрутизации и сервинга. Совпадения видимого текста недостаточно, если между воркерами различаются шаблоны, токенизация или хэширование блоков.
Для диагностической трассы запишите ожидаемый маршрутизатором префикс и фактическое повторение на воркере. Считайте ошибки предсказания отдельно от обычных промахов. Так обнаруживается несогласованная конфигурация, которая иначе выглядит как необъяснимое падение общей доли попаданий в кэш. Сохраняйте только разрешённые политикой метаданные такой проверки.
Сравните экономию и ожидание
Используйте три случая: свободный воркер без подходящих блоков, занятый воркер с полным префиксом и умеренно загруженный воркер с частичным повторением. Держите бюджет вывода сопоставимым. Лучшее назначение зависит от относительной стоимости пересчёта и пребывания в очереди.
Материал Dynamo об агентном инференсе рассматривает локальность кэша среди нескольких согласованных оптимизаций. Не считайте единственной целью похожесть префиксов. Пользователь ожидает полезный ответ, включая поток декодирования, а не высокое значение показателя кэша в панели мониторинга.
Проверьте меняющуюся локальность
Повторите отдельные нагрузки со стабильными беседами, множеством уникальных документов и внезапно популярным префиксом. Добавьте потерю воркера и контролируемое вытеснение блоков. Сравните тот же кластер с более простой политикой по нагрузке при одинаковом поступлении запросов.
Измеряйте первый токен, разрывы стриминга, полезные завершения и распределение очередей по воркерам. Отдельно исследуйте хвост задержек запросов, направленных в сторону от популярного контекста. Выигрыш доминирующего горячего потока может скрыть голодание остальных задач, если публиковать только общие средние значения.
Ограничьте область выводов
Укажите модель, повторяемость нагрузки, свежесть наблюдений и топологию воркеров. Повторное использование между узлами может потребовать передачи; удалённая площадка через WAN иногда добавляет задержку намного больше экономии локального префикса. Маршрутизатор не делает все узлы распределённой сети одинаковыми.
На схемах отделяйте маршрутизацию провайдера для приложения от внутреннего выбора воркера. Внешняя платформа может выбрать Retrivium как провайдера инференса, а Retrivium — воркер своего допустимого пула. Это дополняющие решения на разных границах со своими требованиями к здоровью и доступной ёмкости.
Материалы по теме
Prefix caching: когда повторяющийся контекст помогает GPU-пулу, Deadline запроса: бюджет очереди, prefill и потоковой выдачи.