Бързо управление на кеша в мултимоделен 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, а неговата документация изброява минималния брой токени за въвеждане по модел.
• Последствие за контрол на данни: Документацията за контрол на данни на OpenAI API отбелязва, че разширеното кеширане на подкани изисква съхраняване на тензори ключ/стойност като състояние на приложението в локално хранилище на GPU. Дори когато доставчиците поддържат гаранции за изолация, шлюзовете трябва да третират поведението на кеша като чувствителна инфраструктура, а не като споделено хранилище за данни на приложения.
• Изследователски сигнал: Публичното изследване проучи дали архитектурите в стил шлюз могат да въведат уязвимости на бързото кеширане, които заобикалят предположенията за изолиране на кеша на ниво доставчик. Това не доказва, че конкретен шлюз е уязвим, но поддържа консервативен дизайн на изолация на клиента.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{
  "template_id": "code-agent-v3",
  "tenant_id": "tenant_123",
  "route": "coding-long-context",
  "stable_prefix": {
    "system_policy_version": "2026-08-01",
    "toolset_version": "tools-v12",
    "repo_context_version": "repo-map-8491"
  },
  "semi_stable_context": {
    "workspace_policy_version": "workspace-44-v6"
  },
  "volatile_suffix": {
    "user_message": "Explain why this test fails...",
    "retrieval_context_ids": ["chunk_7", "chunk_19"],
    "trace_id": "not_inserted_into_prompt"
  }
}

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

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

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

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

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

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

{
  "request_id": "req_abc",
  "tenant_id": "tenant_123",
  "app_id": "code-agent",
  "route": "coding-long-context",
  "provider": "provider_name",
  "model": "model_id",
  "template_id": "code-agent-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,
  "output_tokens": 1300,
  "cache_ttl_class": "ephemeral_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 работни натоварвания