Кэширование промптов
Кэширование промптов (prompt caching) — механизм API языковых моделей, при котором повторяющаяся начальная часть контекста (инструкции, код, история диалога) сохраняется на стороне провайдера и при следующих обращениях не обрабатывается заново. Это снижает задержку и стоимость входных токенов и особенно заметно в агентных сценариях с длинным неизменным контекстом.
проверено по: platform.openai.com ↗
См. также
- Кэшированный вводЧасть входных токенов запроса к языковой модели, которую провайдер не обрабатывает заново: он берёт готовый результат из кэша, сохранённый при недавнем запросе с тем же началом. Обычно это длинная неизменная часть: системная инструкция, документ, описание инструментов. Такие токены (cached input) стоят заметно дешевле обычного ввода и обрабатываются быстрее. Подробнее см. «кэширование запросов».
- KV-кэшKV-кэш (key-value cache) — буфер, в котором трансформерная модель хранит вычисленные для уже обработанных токенов векторы «ключей» и «значений» механизма внимания, чтобы не пересчитывать их при генерации каждого следующего токена. Его размер растёт вместе с длиной контекста, поэтому на длинных диалогах и в работе агентов он занимает основную часть памяти ускорителя и во многом определяет стоимость и скорость обработки запроса.
- Контекстное окноМаксимальный объём текста в токенах, который языковая модель может обработать за один раз. В него входят запрос, приложенные документы, история диалога и сам ответ модели. Если текст не помещается, часть приходится обрезать или сжимать. От размера окна зависит, сколько кода или документов можно дать модели разом.
В новостях
OpenAI вывела из теста сервис Decisions API: до 400 вопросов к модели за запрос вместо 200
Повторное использование части запроса, которую модель уже обработала, например длинной инструкции. Такие повторы обрабатываются быстрее и стоят дешевле.
OpenAI добавила в API кэш промптов на 12 часов для агентов
Приём, при котором сервис модели сохраняет промежуточные вычисления для неизменного начала запроса и при повторе не считает его заново. Повторно использованная часть стоит дешевле и обрабатывается быстрее, но только если начало запроса совпадает с сохранённым целиком.