Бързо управление на кеша в мултимоделен API шлюз: стабилни префикси, изолация на клиента и анализ на кеширане

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

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

Тази статия описва референтна архитектура. Това не е проучване на клиентски случай и не претендира за сравнителни резултати. Фактите по-долу идват от документация на доставчика и публично проучване; препоръките за проектиране са насоки за работа на ниво шлюз.

Режимът на повреда: сглобяване на подкана за разбиване на кеша

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

Честите прекъсвачи на кеша включват:

• Метаданни за всяка заявка в горната част: времеви клейма, идентификатори на проследяване, идентификатори на сесии, идентификатори на внедряване или генерирани етикети на заявки.
• Специфични за потребителя данни в префикса: имена, атрибути на акаунти, разрешения или частни предпочитания, поставени преди многократно използвани правила или блокове на инструменти.
• Нестабилна сериализация на инструмента: схеми на инструмента, излъчвани в недетерминиран ред, с променящи се интервали или генерирани идентификатори.
• Фрагменти за извличане твърде рано: RAG контекстът е вмъкнат преди стабилни системни инструкции или споделен контекст на хранилище.
• Дрейф на шаблона: малки промени в текста, публикувани често без версия или диагностика на кеша.

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

Факти за доставчика, които да се използват за проектиране

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

• OpenAI: OpenAI е документирал кеширане на подкана за най-дългия предварително изчислен префикс на подкана. Започва от 1024 токена, увеличава се на стъпки от 128 токена и излага броя на кешираните токени в полетата за използване. OpenAI също така заявява, че кешовете за подкани обикновено се изчистват след 5-10 минути неактивност и винаги се премахват в рамките на един час от последното използване на кеша.
• Anthropic: Anthropic бързото кеширане може да бъде поискано с cache_control. Неговата документация описва съпоставяне на кеша върху компоненти за подкана като инструменти, системно съдържание и съобщения до блока, маркиран с контрол на кеша. Anthropic документира ефимерен кеш, включително 5-минутна продължителност и 1-часова опция срещу допълнително заплащане.
• Gemini: Контекстното кеширане на Google Gemini разкрива броя на токените за попадение в кеша чрез метаданни за употреба, като total_cached_tokens, а документацията му изброява минималния брой токени за въвеждане по модел.
• Последствия за контрол на данни: Документацията за контрол на данни на API на OpenAI отбелязва, че разширеното бързо кеширане изисква съхраняване на тензори ключ/стойност като състояние на приложението в локално хранилище на GPU. Дори когато доставчиците поддържат гаранции за изолация, шлюзовете трябва да третират поведението на кеша като чувствителна инфраструктура, а не като споделено хранилище за данни на приложения.
• Изследователски сигнал: Публичното изследване проучи дали архитектурите в стил шлюз могат да въведат уязвимости на бързото кеширане, които заобикалят предположенията за изолиране на кеша на ниво доставчик. Това не доказва, че конкретен шлюз е уязвим, но поддържа консервативен дизайн на изолация на наемателя.

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

Договор за бързо сглобяване в три региона

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

Регион 1: стабилен префикс

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

• основни системни инструкции;
• блокове за безопасност и правила;
• схеми на инструменти;
• статична продуктова документация;
• карти на хранилища за кодиращи агенти;
• фиксирани инструкции за изходен формат.

Този регион трябва да бъде детерминистичен. Шлюзът трябва да го изгради от шаблони с версии, канонизиран JSON и стабилни правила за подреждане. Ако е включен регистър на инструменти, сортирайте инструментите по стабилен ID на инструмента. Ако са включени JSON схеми, сериализирайте ги с детерминистично подреждане на ключовете и без генерирани времеви клейма.

Регион 2: полустабилен наемател или контекст на работното пространство

Полустабилният регион се променя по-рядко от отделните заявки, но не се споделя глобално. Примерите включват:

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

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

Регион 3: непостоянен суфикс

Променливият суфикс е частта за заявка:

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

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

Модел за внедряване: създатели на стабилен префикс

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

<пре><код>{ "template_id": "код-агент-v3", "tenant_id": "tenant_123", "маршрут": "кодиране-дълъг-контекст", "стабилен_префикс": { "system_policy_version": "2026-08-01", "toolset_version": "инструменти-v12", "repo_context_version": "repo-map-8491" }, "полустабилен_контекст": { "workspace_policy_version": "workspace-44-v6" }, "volatile_suffix": { "user_message": "Обяснете защо този тест е неуспешен...", "retrieval_context_ids": ["chunk_7", "chunk_19"], "trace_id": "not_inserted_into_prompt" } }

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

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

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

Слой на адаптера на доставчика: нормализиране на използването на кеша без скриване на разликите

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

Създайте нормализиран регистър на кеша с полета като:

<пре><код>{ "request_id": "req_abc", "tenant_id": "tenant_123", "app_id": "код-агент", "маршрут": "кодиране-дълъг-контекст", "доставчик": "име_на_доставчик", "model": "model_id", "template_id": "код-агент-v3", "stable_prefix_hash": "sha256:...", "semi_stable_hash": "sha256:...", "input_tokens_total": 58200, "input_tokens_uncached": 8200, "cache_write_tokens": 50000, "cache_read_tokens": 0, "изходни_токени": 1300, "cache_ttl_class": "ефемерен_5m", "provider_cache_fields": { "raw_field_names": "stored_or_redacted_provider_usage" } }

Адаптерът картографира използването на доставчика в нормализирани категории:

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

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

Наблюдаемост на кеша: табла за управление, които обясняват пропуските

Полезното табло за управление на кеша прави повече от това да показва общо кеширани токени. Това трябва да помогне на екипите да отговорят: „Кое работно натоварване нарушава префикса и какво се е променило?“

Проследявайте показателите на кеша по:

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

Полезните извлечени показатели включват:

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

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

Правила за изолиране на наематели: не проектирайте за повторно използване между наематели

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

Консервативната политика включва:

• Маршрутизиране, съобразено с клиента: маршрутизира трафик с възможност за кеширане, като използва границите на клиент, работно пространство и приложение.
• Без споделени префикси, носещи тайна: никога не поставяйте тайни на клиента, идентификационни данни, лични документи или специфични за потребителя данни в споделен префикс за многократна употреба.
• Отпечатъци с отделни префикси: изчислете пръстови отпечатъци с обхват на клиента, включен в главната книга на шлюза, дори ако изобразеният текст е идентичен.
• Контроли на ниво организация: позволяват на администраторите да деактивират функциите на кеша на доставчика за чувствителни натоварвания.
• Изолирането на доставчика не е продуктова функция за препродаване: третирайте изолирането на кеша на доставчика като основна защита, а не като разрешение за изграждане на обединяване на кеша между клиенти.

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

Приписване на таксуване: отделни четения, записи и нормални токени в кеша

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

1. некеширани токени за въвеждане;
2. кеш токени за запис;
3. кеш токени за четене;
4. изходни токени;
5. специфични за доставчика такси за TTL или контрол на кеша.

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

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

Контролен списък за линтинг на кеша

Преди да активирате принудителното прилагане на кеша, изпълнете шаблони за подкани през контролен списък на lint:

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

План за внедряване

1. Наблюдавайте, преди да промените подканите

Започнете със събиране на полета за използване на доставчика и нормализирани показатели на кеша за съществуващ трафик. Изчислете пръстови отпечатъци на префикс за първите N токена или за дефинирани от шлюза региони на подкана. Целта е да се намерят маршрути с голям обем и дълъг контекст с голямо оттегляне на префикса.

2. Класифицирайте натоварванията

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

3. Представете създателите на стабилен префикс

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

4. Canary one route

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

5. Налагайте постепенно

След канарчето, превърнете предупрежденията за мъх в проверки на правилата. Например, първо предупредете за нестабилен ред на инструментите, след което отхвърлете нови версии на шаблони, които включват непостоянни метаданни в стабилния префикс.

Компромиси

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

Изпълнимо заключение

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

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

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

• вграждане на категории, поддържащи кеша, в счетоводната книга
• обединяване на кеш показатели с безопасна наблюдаемост на LLM
• запазване на контекста на извличане в обхват на наемател в RAG работни натоварвания