Маршрутизация KV Cache: Уменьшение избыточной работы предварительного заполнения LLM

Маршрутизация KV-кэша имеет значение, когда повторяющиеся префиксы подсказок продолжают появляться в вашем трафике LLM. Если правильный запрос попадает на правильную реплику, движок обслуживания может повторно использовать сохраненное состояние внимания вместо того, чтобы заново вычислять одни и те же токены заполнения снова и снова.

Это звучит как деталь инфраструктуры, но быстро становится проблемой продукта. Длинные системные подсказки, контекст RAG, примеры few-shot и история многократного общения могут сделать работу заполнения дорогой. Когда каждая реплика заново вычисляет один и тот же префикс, команды платят за это задержкой, временем GPU и планированием емкости.

ShareAI предоставляет разработчикам один API для 150+ моделей, видимость на рынке, маршрутизацию и резервирование. Маршрутизация KV-кэша находится на один уровень ниже, внутри инфраструктуры обслуживания моделей. Полезный вывод для читателей ShareAI прост: решения по маршрутизации имеют значение на каждом уровне AI-стека, от выбора модели до того, какая реплика GPU обрабатывает повторяющуюся подсказку.

Почему маршрутизация KV-кэша имеет значение

Во время вывода LLM модель сначала обрабатывает входную подсказку на этапе заполнения. Она создает кэш ключ-значение, обычно называемый KV-кэш, чтобы позже сгенерированные токены могли ссылаться на уже обработанный контекст.

Кэширование префиксов позволяет движкам обслуживания повторно использовать этот кэш, когда последующий запрос имеет тот же начало подсказки. Документация автоматического кэширования префиксов vLLM описывает это как повторное использование KV-кэша для общих префиксов, чтобы новый запрос мог пропустить вычисления для общей части. Кэширование префиксов SGLang использует схожую идею для совместного использования KV-кэша для общих последовательностей токенов.

Это особенно важно для рабочих нагрузок, где многие запросы начинаются одинаково: агенты поддержки с большой системной подсказкой, приложения RAG, использующие повторяющиеся фрагменты документации, кодирующие агенты с инструкциями репозитория или чат-продукты, которые переносят историю общения между этапами.

Где круговая маршрутизация дает сбой

Кэширование префиксов проще всего на одной реплике. Один и тот же процесс видит повторяющийся префикс и может повторно использовать его кэш, если память доступна. Проблема возникает, когда сервис масштабируется горизонтально.

С обычным балансировщиком нагрузки кругового типа первый запрос может прогреть кэш на реплике A, в то время как второй запрос с тем же префиксом попадает на реплику B. Реплика B не имеет этого сохраненного состояния, поэтому она заново вычисляет ту же работу заполнения. Третий запрос может попасть на реплику C и снова пропустить.

По мере увеличения количества реплик наивное балансирование нагрузки может распределять связанные запросы по большему количеству машин. Флот обслуживания моделей может выглядеть сбалансированным, но уровень попадания в кэш префиксов падает. Это тот разрыв, который пытается закрыть маршрутизация KV-кэша.

Три практических уровня маршрутизации

1. Привязка сессии

Привязка сессии направляет трафик от одного и того же пользователя, рабочего пространства, арендатора или разговора к одной и той же реплике. Это самый простой способ начать многократный чат, так как последующие запросы часто используют предыдущий контекст.

Компромисс заключается в том, что идентичность пользователя не всегда совпадает с похожестью запросов. Два пользователя могут использовать один и тот же длинный системный запрос, но быть направлены к разным репликам. Привязка сессии также может нарушаться при добавлении или удалении реплик.

2. Маршрутизация с хешированием префикса

Маршрутизация с хешированием префикса использует сам запрос в качестве ключа маршрутизации. Маршрутизатор хеширует стабильное начало запроса и отправляет совпадающие префиксы к одной и той же реплике.

Это работает лучше, когда повторяющиеся системные запросы, примеры few-shot или общий извлеченный контекст важнее, чем идентичность пользователя. Сложность заключается в выборе границы префикса. Если хеш включает временную метку, идентификатор запроса или пользовательское поле, ключ маршрутизации фрагментируется, и повторное использование кэша разрушается.

3. Маршрутизация с учетом событий кэша

Наиболее продвинутый подход отслеживает, какие блоки кэша находятся на каких репликах, а затем направляет каждый запрос к реплике с наилучшим совпадением кэша, при этом учитывая нагрузку. Проект llm-d router описывает выборщик конечных точек, который учитывает локальность KV-кэша, текущую нагрузку и приоритет при выборе, куда должен быть направлен запрос.

Это более сложный подход, но он правильный для высокопроизводительных флотов, где промахи кэша измеримы, дороги и часты.

Когда стоит отказаться

Маршрутизация KV-кэша не всегда оправдывает свою сложность. Она плохо подходит, когда запросы короткие, в основном уникальные или обрабатываются пакетами с небольшой повторяющейся структурой.

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

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

Как это связано с ShareAI

ShareAI — это рынок ИИ и API, а не балансировщик нагрузки для моделей внутри вашего GPU-кластера. Разработчики используют ShareAI для доступа к множеству моделей через один API, сравнения сигналов рынка, маршрутизации запросов, управления использованием и переключения на резервный маршрут при ухудшении основного.

Это все равно делает маршрутизацию KV-кэша актуальной. Если вы управляете собственной инфраструктурой вывода, это помогает задавать более точные вопросы о инфраструктуре. Если вы используете размещенные модели, это помогает оценить, почему два маршрута с похожими названиями моделей могут вести себя по-разному при реальных нагрузках.

Для разработчиков это также связано с ценообразованием. Приложение с длинными запросами, повторяющимся контекстом RAG или циклами агентов может создавать очень неравномерное использование ИИ. ShareAI Builder позволяет владельцам приложений направлять трафик вывода ИИ через ShareAI, устанавливать наценку или дополнительную плату, чтобы клиенты оплачивали использование через ShareAI, и получать ежемесячные выплаты на основе созданного использования. Само приложение остается построенным вне ShareAI.

Для выбора модели и оценки маршрутов начните с Маркетплейса моделей ShareAI. Для основ реализации используйте Справочник API ShareAI.

Контрольный список маршрутизации KV-кэша

• Сначала разместите стабильное содержимое запроса: системный запрос, правила инструментов, примеры и повторяющийся контекст.
• Переместите динамические поля позже: временные метки, идентификаторы запросов, пользовательские факты и одноразовые инструкции.
• Измерьте коэффициент попадания в кэш до и после изменений маршрутизации.
• Следите за временем до первого токена, пропускной способностью, глубиной очереди и нагрузкой на VRAM одновременно.
• Начните с маршрутизации на основе хэша префикса перед созданием маршрутизации с учетом событий кэша.
• Разделите правила маршрутизации по нагрузке вместо того, чтобы применять одну глобальную политику.
• Держите стоимость и задержку видимыми на уровне приложения, а не только внутри кластера вывода.

Часто задаваемые вопросы

Что такое маршрутизация KV-кэша?

Маршрутизация KV-кэша — это стратегия маршрутизации, которая отправляет запросы с повторяющимися префиксами подсказок на реплики, которые, вероятно, уже содержат соответствующий KV-кэш. Цель — уменьшить избыточные вычисления предварительного заполнения.

Чем маршрутизация KV-кэша отличается от кэширования префиксов?

Кэширование префиксов — это способность движка обслуживания модели повторно использовать кэшированное состояние для общих префиксов подсказок. Маршрутизация KV-кэша — это стратегия размещения трафика, которая помогает соответствующим запросам попадать туда, где это кэшированное состояние уже существует.

Почему маршрутизация по кругу мешает кэшированию префиксов?

Маршрутизация по кругу распределяет запросы между репликами, не зная, какая реплика содержит какой кэшированный префикс. Повторяющаяся подсказка может пропустить кэш просто потому, что она попадает на другую реплику.

Какие рабочие нагрузки получают наибольшую выгоду от маршрутизации KV-кэша?

Многотуровые чаты, RAG, агенты кодирования, агенты поддержки, подсказки с малым количеством примеров и приложения с длинными общими системными подсказками являются сильнейшими кандидатами, поскольку они повторно используют значительные префиксы подсказок.

Когда команде следует отказаться от маршрутизации KV-кэша?

Откажитесь от нее, если подсказки короткие, в основном уникальные или ориентированы на пакетную обработку с небольшой повторяющейся структурой. В таких случаях сложность маршрутизации может добавить мало пользы.

Поддерживают ли vLLM и SGLang кэширование префиксов?

Да. Документация vLLM описывает автоматическое кэширование префиксов, а документация SGLang описывает кэширование префиксов для общего KV-кэша через общие последовательности токенов. Движку обслуживания все еще требуется помощь в маршрутизации, когда задействованы несколько реплик.

Является ли маршрутизация KV-кэша тем же самым, что и семантическое кэширование?

Нет. Маршрутизация KV-кэша работает с точным или почти структурным повторным использованием префиксов внутри обслуживания вывода. Семантическое кэширование сохраняет и повторно использует ответы или промежуточные результаты на основе смысла, обычно с использованием эмбеддингов или порогов сходства.

Заменяет ли ShareAI балансировщик нагрузки, учитывающий KV-кэш?

Нет. ShareAI — это рынок ИИ и уровень API для доступа к моделям, маршрутизации, отказоустойчивости, использования и выставления счетов. Маршрутизация с учетом KV-кэша — это инфраструктура более низкого уровня для обслуживания моделей, предназначенная для команд, работающих с репликами вывода.

Как разработчикам следует думать о маршрутизации KV-кэша?

Разработчики должны рассматривать поведение кэша как один из факторов затрат в приложениях с интенсивным использованием ИИ. Если их приложение имеет неравномерное использование, ShareAI может помочь маршрутизировать и монетизировать этот ИИ-трафик, при этом приложение остается созданным и принадлежащим вне ShareAI.

Что команды должны измерить перед изменением маршрутизации?

Измерьте частоту попадания в кэш, время до первого токена, пропускную способность, глубину очереди, нагрузку на VRAM, стоимость за задачу и качество вывода. Изменения маршрутизации должны улучшать рабочую нагрузку, а не только панель мониторинга.

Может ли маршрутизация KV-кэша снизить затраты на API ИИ?

Она может снизить затраты на инфраструктуру для команд, которые сами обслуживают модели, поскольку уменьшение избыточной работы с предварительным заполнением может повысить эффективность GPU. Для размещенных API эффект зависит от того, предоставляет ли провайдер эти сбережения в цене или производительности.