Как да проектираме съобразени с кеша LLM подкани за OpenAI, Anthropic и Gemini

Бързото кеширане помага само когато едни и същи токени се използват повторно на правилното място, за достатъчно дълго време и при семантиката на доставчика, който всъщност извиквате. Екипите често пропускат ползата, защото третират кеширането като моделна функция, вместо като проблем с архитектурата на заявката. Те поставят времеви клейма в горната част на всяка подкана, преплитат специфични за заявката резултати от извличане със схеми на инструменти за многократна употреба или оптимизират за един доставчик, докато тихо увеличават цената на друг.

Практическото решение е да направите бързото кеширане част от компилатора на заявки за шлюз. Шлюзът трябва да разделя стабилния материал за подкана от материала за променлива заявка, да компилира специфични за доставчика инструкции за кеширане и да измерва разходите и закъснението чрез кешируем префикс. Това има най-голямо значение в среда с няколко модела, където OpenAI, Anthropic и Gemini разкриват различно поведение на кеширане, счетоводни полета, TTL и разходи за настройка.

Започнете с единицата за кеширане, а не с доставчика

Единицата за многократна употреба обикновено не е цялата подкана. Това е префикс или контекстен обект, направен от подканващ материал, който споделят много заявки. В производствено предприятие LLM API този материал често включва политика на платформата, политика на организацията, инструкции за приложения, дефиниции на инструменти, правила за формат на отговор, инструкции за кодиращ агент или насоки за статичен корпус.

Нестабилната част е материалът, който се променя при заявка: текущата задача на потребителя, идентификатори на заявка, времеви отпечатъци, опашка на разговор, прясно извлечени RAG пасажи, данни, специфични за акаунта, и резултати от еднократни инструменти. Ако променливото съдържание се появи преди стабилно съдържание, то може да наруши повторното използване на префикса или да принуди доставчика да третира голяма подкана като нова.

Факт: внедряванията на доставчика се различават. OpenAI документи подканват кеширане като повторно използване на споделен префикс, с отчитане на кеширани токени. Неговата публична статия за бързо кеширане казва, че автоматичното кеширане започва от префикс от 1024 токена и нараства на стъпки от 128 токена и че записите в кеша обикновено се изчистват след 5 до 10 минути неактивност и в рамките на един час от последното използване. Anthropic документира изрични точки на прекъсване на кеша и препоръчва поставяне на cache_control в последния споделен блок, като системни подкани или дефиниции на инструменти. Gemini документира контекстното кеширане като платена функция с преброяване на кеширани токени, върнати в метаданни за използване за кеш операции и извиквания за генериране, които използват кеш.

Препоръка: проектирайте вашето вътрешно представяне на подкани около стабилни блокове и непостоянни блокове, преди да картографирате нещо към доставчика API.

Компилиране на заявки от най-стабилни към най-променливи

Компилаторът на заявки, поддържащ кеша, трябва да подрежда материала, така че най-голямата секция за многократна употреба да се показва преди секцията, специфична за заявката. Практичен ред по подразбиране е:

1. Правила за безопасност и съответствие на платформата.
2. Правила за организация или наемател.
3. Инструкции за роля и задачи на приложението.
4. Схеми на инструменти и правила за използване на инструменти.
5. Статично знание или дълготрайна справка материал.
6. История на разговорите, която се използва повторно в редовете.
7. Извлечени пасажи или друг специфичен за заявката контекст.
8. Текущата потребителска задача.
9. Ефимерни метаданни, необходими само за това повикване.

Този ред не е универсална истина. Някои доставчици или модели може да реагират по различен начин, когато инструкциите се преместят. Приоритетът на политиката и качеството на поведението все още имат значение.Отнасяйте се към подреждането, съобразено с кеша, като контролирана промяна: изпълнете бързи регресионни тестове преди и след промяна на оформлението.

Примерни блокове за вътрешни подкани

{
  "blocks": [
    {"id": "platform_policy:v7", "stability": "global", "kind": "system"},
    {"id": "org_policy:acme:v3", "stability": "tenant", "kind": "system"},
    {"id": "support_agent:v12", "stability": "app", "kind": "instructions"},
    {"id": "crm_tools:v5", "stability": "app", "kind": "tool_schema"},
    {"id": "kb_static:returns:v2", "stability": "workflow", "kind": "context"},
    {"id": "conversation_tail", "stability": "session", "kind": "history"},
    {"id": "retrieved_docs", "stability": "request", "kind": "rag"},
    {"id": "user_task", "stability": "request", "kind": "user"}
  ]
}

Компилаторът може да хешира стабилния префикс, след като го изобрази. Този хеш се превръща в ключ за присъединяване за анализ на кеша: модел, клиент, приложение, хеш на префикс с възможност за кеширане, подкана версия, TTL избор, некеширани входни токени, кеширани входни токени, кеш-записващи токени, когато има такива, изходни токени, латентност и крайна цена.

Използване на адаптери на доставчик вместо един кеш. Предположение

Единствен флаг за „активиране на кеша“ е твърде неясен за операции с множество доставчици. Шлюзът трябва да изложи една вътрешна политика за кеширане и да я компилира в поведение, специфично за доставчика.

OpenAI Адаптер

За OpenAI, оптимизирайте за повтарящи се споделени префикси и отчитане на използването. Компилаторът на заявки трябва да поддържа стабилен материал отпред и да избягва малки разлики вътре в първия кеширащ участък. Проследяване на кеширани входни токени от полетата за използване на доставчика. Където е налично, също така проследявайте токени за запис в кеша, така че регистърът на разходите да може да сравнява създаването и повторното използване на кеша.

Тъй като кеширането е ориентирано към префикс, важната оперативна задача е предотвратяването на отклонение на префикса. Две подкани, които изглеждат еднакви за хората, може да се различават, тъй като клеймо за време, ИД на компилация, рандомизиран ред на инструменти или персонализиране на клиента са изобразени в горната част.

Anthropic Адаптер

За Anthropic, компилирайте изрични точки на прекъсване на кеша. Поставете cache_control на последния блок, който трябва да бъде споделен с последващи заявки. Добри кандидати са големи системни инструкции, дефиниции на инструменти или стабилен референтен контекст. Лошите кандидати са еднократни потребителски съобщения, текущи полезни натоварвания на задачи или RAG фрагменти, специфични за заявка.

Факт: Anthropic документира продължителност на кеша от 5 минути по подразбиране и продължителност на кеша от 1 час, достъпна срещу допълнително заплащане. Това прави избора на TTL икономично решение. Дългият кеш може да има смисъл за интерактивни кодиращи агенти, многоетапен преглед на документи или помощни пилоти с паузи между завоите. Може да бъде разточително за еднократна задача с малко повторения.

Gemini Адаптер

За Gemini третирайте контекстното кеширане като решение за ресурс. Създайте кеширано съдържание, когато очакваното повторно използване оправдава разходите за настройка и съхранение, след което препратете този кеш от извиквания за генериране. Това е различно от разчитането само на автоматичен префиксен кеш. Адаптерът трябва да притежава жизнен цикъл на кеша, TTL, метаданни и правила за почистване.

Gemini контекстните кешове в стил често са най-добри за голям, стабилен контекст, който много заявки ще използват повторно: дълго ръководство за правила, извадка от статичен продуктов каталог, среда с фиксиран кодиращ агент или работен процес за преглед, който многократно задава въпроси върху един и същ документ set.

Измерете икономиката на кеша, а не само процента на попадения

Процентът на попадения в кеша е полезен, но не е достатъчен. Високият процент на попадение на малък префикс може да спести малко. По-нисък процент на попадения на много голям префикс за политики и инструменти може да има по-голямо значение.Някои доставчици излагат разходи за запис в кеша или за настройка и тези разходи могат да изтрият спестяванията, ако повторното използване е ниско.

Захващайте тези полета за всяка заявка, където доставчикът ги излага или шлюзът може да ги оцени:

• Доставчик и модел.
• Наемател, приложение, среда и API ключ идентичност.
• Версия на шаблона за подкана и хеш на префикс с възможност за кеширане.
• TTL политика или продължителност на кеша.
• Некеширани входни токени.
• Кеширани входни токени.
• Кеширани токени за запис или създаване на кеш, където налични.
• Изходни токени.
• Време до първия токен и общо забавяне.
• Версия на цената на доставчика, използвана за изчисляване на разходите.
• Дали заявката е била част от интерактивна сесия, групова работа, цикъл на агент или еднократно повикване.

След това изчислете стойността на кеша според натоварването, а не глобално. Вторият пилот за поддръжка, кодиращият агент, рецензентът на документи и еднократният обобщител имат различни модели на повторно използване. Сборните данни трябва да показват спестени долари, изразходвани долари за запис в кеша, промяна в латентността и процент на попадения по хеш на префикса.

Прост модел на ROI е достатъчен, за да започнете:

expected_savings =
  expected_reuses
  * cacheable_tokens
  * (uncached_input_price - cached_input_price)

net_value =
  expected_savings
  - cache_write_or_setup_cost
  - operational_overhead

Този модел е умишлено прост. Трябва да се използва като порта, преди да се активират дълготрайни или изрични кешове, а не като заместител на производственото измерване.

Добавяне на правила за разрушаване на кеша

Повечето грешки в кеша идват от навици за бързо изграждане, а не от грешки на доставчика. Добавете gateway lint правила, които се изпълняват преди заявките да достигнат до доставчика.

Отбележете времеви клейма в горната част на подканите. Ако моделът се нуждае от текущото време, поставете го след префикса за многократна употреба или го предайте като блок за късна заявка.

Отбелязване на произволни идентификатори в системни съобщения. Идентификаторите на корелация принадлежат към метаданните или регистрационните файлове, а не към префикса на стабилната подкана.

Поставяне на флаг на динамично подредени схеми на инструменти. Сортирайте инструментите и свойствата на схемата детерминистично преди рендиране. Списък с инструменти, който променя реда при всяка заявка, може да унищожи повторната употреба, дори когато наборът от инструменти е логически идентичен.

Поставяне на флаг на RAG за специфични заявки преди стабилни инструменти. Извлечените пасажи често са непостоянни. Първо поставете стабилни инструкции и схеми на инструменти, а след това извлечени пасажи, освен ако бързите тестове не докажат, че е необходима друга поръчка.

Поставете флаг за специфично за потребителя персонализиране в споделената политика. Политиката на клиента може да може да се кешира в един клиент, но потребителските предпочитания и текущото състояние на акаунта обикновено не са.

Отбелязване на изтичане на версията на шаблона. Ако всяко разгръщане променя интервали, коментари или неизползван текст на инструкция, кешираният хеш на префикса се променя. Шаблони за подкана за версия умишлено и избягвайте ненужни редакции на големи стабилни блокове.

Бравете внимателно с работните натоварвания на RAG

RAG е мястото, където екипите често кешират прекалено много. Инструкциите за стабилно извличане, правилата за цитиране, схемите на инструментите и описанията на корпуса могат да бъдат повторно използвани. Самите извлечени пасажи обикновено са специфични за заявката. Ако поставите извлечени пасажи преди стабилните инструкции, намалявате повторната употреба. Ако кеширате целия контекст, когато е малко вероятно пасажите да се повторят, може да платите разходи за писане или настройка без достатъчно бъдещи посещения.

Има изключения. Поток за правен преглед, работен поток за поддръжка или асистент за продуктови документи може многократно да прави заявки за един и същ пакет документи в една сесия. В такъв случай може да бъде полезен по-дълготраен кеш за контекста на документа.Решението трябва да зависи от очаквания брой повторно използване, продължителността на кеша, размера на контекста на документа и дали потребителите са склонни да задават няколко въпроса за един и същи материал.

Препоръка: класифицирайте контекста на RAG като един от трите типа: насоки за статичен корпус, контекст на сесия за многократна употреба или еднократно извлечени фрагменти. Кеширайте само първите две по подразбиране.

Проверка на поведението преди оптимизиране на разходите

Преместването на съдържание по-късно в подкана може да подобри повторното използване на кеша, но също така може да промени поведението на модела. Например преместването на правилата на инструмента след историята на разговорите може да намали тяхното влияние. Преместването на правилата под изтегленото съдържание може да отслаби приоритета на инструкциите. Нормализирането на схеми може да повлияе на избора на инструмент, ако описанията се променят.

Използвайте регресионни тестове, преди да пуснете оформления, поддържащи кеша. Тествайте най-малко:

• Приоритет на инструкциите за политика за безопасност и съответствие.
• Избор на инструменти за известни задачи.
• Валидност на структурирания изход, когато са включени схеми.
• Качество на отговора на представителни RAG примери.
• Забавяне и разходи при повтарящи се се превръща.
• Отчитане на употребата, специфично за доставчика.

За работни потоци с висок риск, изпълнете скрито сравнение: оригинално оформление на подканата спрямо оформление, съобразено с кеша, същия модел, същите входове, с човешки или автоматизирани проверки за неприемливи изходни промени. Спестяването на разходи не е полезно, ако компилаторът на заявки променя бизнес поведението по начини, които екипите не са одобрили.

Избирайте работни натоварвания избирателно

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

Слабите кандидати включват кратки еднократни подкани, силно персонализирани подкани, при които горната част на заявката се променя всеки път, редки администраторски задачи и работни потоци, при които изходът токените доминират общата цена. В тези случаи други оптимизации може да имат по-голямо значение: по-кратки подкани, по-добро извличане, маршрутизиране на модела, пакетна обработка или по-строги ограничения на изхода.

Прогноза: семантиката на кеширането на доставчика ще продължи да се различава. Автоматичното кеширане на префикса, изричните точки на прекъсване, платените контекстни ресурси, отчитането за писане в кеша и ценообразуването на TTL вероятно ще останат неравномерни в различните платформи.Екипите, които централизират компилирането на заявки и телеметрията в шлюза, ще могат да се адаптират по-бързо от екипите, които вграждат специфична за доставчика логика за кеширане в кода на приложението.

Контролен списък за внедряване

• Създайте вътрешен блоков модел с подкана с етикети за стабилност: глобален, клиент, приложение, работен поток, сесия и заявка.
• Рендиране на блокове детерминистично, включително ред на инструмента и ред на свойствата на схемата.
• Преместване на променливите полета извън стабилния префикс.
• Изчисляване на хеш на префикс с възможност за кеширане след изобразяване.
• Добавяне на адаптери на доставчик за OpenAI повторно използване на префикс, Anthropic точки на прекъсване на кеша и Gemini контекстен кеш ресурси.
• Записвайте некеширани входни токени, кеширани входни токени, кеш-записващи токени, когато има такива, изходни токени, латентност, модел, клиент, приложение, префикс хеш и TTL.
• Изграждане на табла за управление за нетни спестени долари, разходи за запис/настройка, честота на попадения и латентност от работно натоварване.
• Добавяне на правила за времеви отпечатъци, произволни идентификатори, променливо разположение на RAG, динамичен ред на инструменти и персонализиране в споделени блокове.
• Изпълнете бързи регресионни тестове на поведението, преди да промените производственото оформление.
• Активирайте кеширането първо за често повтарящи се работни натоварвания, след това разширете въз основа на измерените ROI.

Заключение

Дизайнът на подкани, съобразен с кеша, не е само бързо форматиране. Това е възможност за шлюз: детерминистично изобразяване, дизайн със стабилен префикс, компилация, специфична за доставчика, линтинг и телеметрия на разходите. Екипите, които ще се възползват най-много, ще бъдат тези, които могат да отговорят на три въпроса за всяко работно натоварване: каква част от заявката наистина може да се използва многократно, как този доставчик таксува повторното използване и дали кешът е подобрил цената или закъснението от край до край, без да променя поведението?

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

Свързано четене

• неутрална по отношение на доставчика LLM наблюдаемост