Ускорение LLM: настройка KV-cache и Semantic Cache

Кэширование инференса LLM: где теряется скорость

Каждый новый запрос модель обрабатывает с нуля: заново считает внимание по всему контексту, хотя 80–90 % промпта не менялось с прошлого вызова. На длинных системных инструкциях и истории диалога доля повторного счёта доходит до девяноста процентов — и платится за неё временем до первого токена, а не логикой продукта.

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

Добавить ускорителей — самое дорогое и самое слабое решение: линейного роста пропускной способности не будет, пока каждый запрос пересчитывает одно и то же. Разбираем, как это закрывается: кэширование инференса LLM опирается на два механизма — переиспользование уже посчитанного префикса (как в vLLM) и кэш на уровне смысла запроса.

Что даёт переиспользование ответов и контекста

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

В сервисных движках актуальной ветки, например в vLLM, кэш ведётся блоками, а общие префиксы переиспользуются между сессиями — рост числа одновременных диалогов перестаёт линейно съедать память вычислителя. Время до первого ответа на длинном системном префиксе сокращается в 2–4 раза, полное время выдачи падает пропорционально доле переиспользованного контекста.

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

Оба механизма складываются в пропускную способность сервиса: при доле попаданий 30–50% на типовом потоке нагрузка на вычислители снижается почти пропорционально, пик проходит на том же парке, а хвост задержек перестаёт разъезжаться.

Режимы кэширования: точный, семантический, контекстный

Три режима кэширования решают разные задачи, и путать их — частая причина разочарования. Точный кэш ответов ловит повтор запроса символ в символ, семантический — перефразировки вроде «как оформить возврат» и «возврат товара как сделать», а контекстный держит кэш состояний внимания, чтобы не пересчитывать общий префикс промпта на каждом вызове.

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

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

Как мы внедряем: аудит, схема, замер, передача

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

1. Аудит нагрузки. Разбираем реальный трафик: доля дословно повторяющихся и перефразированных запросов, распределение длин контекста, доля системных подсказок.
2. Схема прохождения запроса. Рисуем путь от клиента до модели и обратно, отмечаем, где встаёт проверка кэша и что происходит при промахе.
3. Настройка KV-кэша. Подбираем объём буфера, политику вытеснения и разделение по сессиям, чтобы память не росла с каждым диалогом.
4. Семантический кэш. Задаём порог схожести, правила нормализации запроса и изоляцию по арендаторам — ответ одного пользователя не должен уйти другому.
5. Замер метрик. Сравниваем состояние до и после на сопоставимой выборке: время до первого токена, полное время ответа, доля попаданий, загрузка ускорителей.
6. Проверка на граничных режимах. Холодный старт, всплеск трафика, недоступность хранилища кэша, смена модели — система должна деградировать, а не падать.
7. Передача в эксплуатацию. Регламент обслуживания, панель мониторинга с ключевыми метриками, план отката и обучение вашей команды.

Что остаётся у вас: конфигурации, схемы, регламенты

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

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

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

Кейс: время отклика и доля попаданий до и после

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

Замеры до внедрения: медиана отклика держалась на 7 секундах, в пик доходила до 14, доля попаданий в кэш была нулевой. Главный класс отказов — обрыв по таймауту: очередь запросов росла, и часть обращений заканчивалась ошибкой вместо ответа.

Что меняли

Разделили неизменяемый префикс подсказки и переменную часть: блоки внимания для общей инструкции больше не считаются заново, кэш ключ-значение переиспользуется между диалогами. Поверх поставили семантический кэш — вопрос приводится к вектору, и при совпадении выше порога 0,92 готовый ответ отдаётся без обращения к модели. Записи разбиты по правам доступа, срок жизни привязан к версии базы знаний, поэтому при обновлении документации связанные ответы инвалидируются автоматически.

Метрики после внедрения: медиана отклика — 1,8 секунды, на повторных вопросах — 0,6; доля попаданий в кэш — 47% в среднем и 63% в пиковые окна. Таймауты как класс отказов ушли, нагрузка на инференс упала примерно вчетверо, а освободившийся запас ушёл на рост числа одновременных диалогов.

Замеры до и после снимали на одном наборе сценариев, поэтому цифры сопоставимы. Кейс с согласия заказчика мы разбирали на профильной конференции — Инференс LLM в продакшене.

Чем переиспользование контекста отличается от повтора ответов?

Разница — в уровне, на котором экономится работа. Переиспользование контекста живёт внутри одного обращения: модель не пересчитывает состояния внимания для уже прочитанной части запроса, а продолжает с сохранённой позиции. Это ускоряет выдачу первого токена на длинных системных инструкциях и в диалоге, но само обращение к модели всё равно происходит.

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

Выбор механизма — не «или-или». Переиспользование контекста включают всегда: оно не меняет ответ и снижает нагрузку на длинных входах. Семантический кэш ставят там, где поток запросов заметно повторяется, и обязательно с порогом близости, журналом попаданий и исключениями для персональных данных и транзакционных вопросов.

Слабо подобранный порог даёт худший класс отказа: система уверенно отдаёт похожий, но неверный ответ. Поэтому долю попаданий и точность сверяют на наборе эталонных пар «запрос — ожидаемый ответ», а спорные темы помечают как неподлежащие кэшированию.

Ограничения и типичные ошибки при настройке

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

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

Где граница ложных совпадений в семантическом поиске?

Порог близости подбираем по разметке: пары «запрос — ожидаемое попадание» и пары соседних, но разных по смыслу вопросов. Заниженный порог смешивает запросы про разные сущности, завышенный — обнуляет попадания. Запросы с числом, датой или именем помечаем как непригодные для кэша.

Что точно не стоит кэшировать?

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

Обсудим задачу: что нужно от вас для старта

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

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

В ответ присылаем оценку и план работ: инвентаризацию текущего инференса, схему KV-cache и семантического слоя с политикой инвалидации, порядок выкатки и набор замеров, по которым будем проверять эффект. Согласуем этапы — и старт проекта занимает дни, а не недели.