Как кэшировать запросы к LLM — prompt caching и семантический кэш?

Question

Accepted Answer

Prompt caching (на стороне провайдера или сервера инференса) переиспользует обработку одинакового префикса промпта — системные инструкции, документы, историю: повторные запросы дешевле и быстрее до первого токена. Точный кэш ответов — по хешу запроса. Семантический кэш — по близости эмбеддингов: «похожий» вопрос получает сохранённый ответ; экономит больше, но рискует ответить не на тот вопрос. Для prompt caching неизменная часть промпта должна идти в начале, переменная — в конце Семантический кэш требует порога близости и проверки на реальных запросах Персональные ответы кэшировать нельзя — утечка между пользователями Температура выше нуля — повторный запрос и так даёт другой ответ; кэш меняет поведение продукта Prompt caching. Модель обрабатывает промпт слева направо; если начало совпадает с недавним запросом, его KV-кэш можно переиспользовать. Провайдеры API дают на кэшированные токены большую скидку и заметное сокращение TTFT. Практика: структура промпта «стабильные инструкции → стабильные документы → история → новый вопрос»; изменение одного символа в начале ломает кэш. Кэш ответов: - точный — ключ = хеш (модель, параметры, сообщения). Безопасно, полезно для повторяющихся системных вызовов (классификация, извлечение из одного и того же документа); - семантический — ищем ранее заданный вопрос с близким эмбеддингом. Подходит для FAQ-подобных потоков. Риски: «как отменить заказ» и «как не отменять заказ» близки по эмбеддингу; нужен высокий порог и оценка ложных попаданий. Правила: учитывать версию модели и промпта в ключе; задавать срок жизни; не кэшировать ответы, зависящие от пользователя и…

Как кэшировать запросы к LLM — prompt caching и семантический кэш?

Подробно

Что хотят услышать

Связанные вопросы

Подсказки на собеседовании — в реальном времени