Промптна контрола кеша у вишемоделном мрежном пролазу API: стабилни префикси, изолација станара и аналитика кеш-хитова

Брзо кеширање је лако потрошити. Тим може имати системски промпт од 40.000 токена, шему алата, блок политике, мапу спремишта или меморију агента која би требало да се може поново користити, а затим случајно ставити временску ознаку, ИД захтева, корисничко име, исечак за преузимање или насумични редослед алата при врху упита. Добављач види другачији префикс, кеш је пропуштен, кашњење расте, а рачун изгледа збуњујуће.

У апликацији једног добављача, ово можете поправити унутар шаблона апликације. У мрежном пролазу са више модела, проблем је већи: сваки провајдер излаже различите контроле кеш меморије, прагове токена, понашање времена до живота, поља коришћења и семантику обрачуна. Мрежном пролазу је потребан преносиви образац контролне равни за склапање безбедних упутстава за кеш, мерење понашања кеша, изоловање станара и приписивање трошкова.

Овај чланак описује референтну архитектуру. То није студија случаја корисника и не захтева резултате референтних вредности. Доле наведене чињенице потичу из документације добављача и јавног истраживања; препоруке за дизајн су упутства за рад на нивоу мрежног пролаза.

Режим грешке: склоп промпта за разбијање кеша

Кеширање промпта генерално награђује поновљене префиксе упита. Тачна механика варира у зависности од добављача, али практична импликација је доследна: ако се промени предњи део упита, пати поновна употреба.

Уобичајени разбијачи кеша укључују:

• Метаподаци по захтеву на врху: временске ознаке, ИД-ови праћења, ИД-ови сесије, ИД-ови примене или генерисане ознаке захтева.
• Подаци специфични за корисника у префиксу: имена, атрибути налога, дозволе или приватне поставке постављене пре вишекратних смерница или блокова алата.
• Нестабилна серијализација алата: шеме алата које се емитују у недетерминистичком редоследу, са променом размака или генерисаним ИД-овима.
• Преузимање исечака прерано: РАГ контекст је уметнут пре стабилних системских инструкција или контекста дељеног складишта.
• Промена шаблона: мале промене формулације које се често објављују без верзије или дијагностике кеша.

Гејтвеј не може магично да учини нестабилни префикс кешираним, али може да примени уговор о брзом склапању и учини видљивим пропусте у кешу.

Чињенице о добављачима за осмишљавање

Детаљи су важни јер мрежни пролаз мора да нормализује понашање без претварања да су добављачи идентични.

• OpenAI: OpenAI има документовано кеширање упита за најдужи претходно израчунати префикс упита. Почиње са 1.024 токена, повећава се у корацима од 128 токена и излаже кеширане бројеве токена у пољима коришћења. OpenAI такође наводи да се брзи кешови обично бришу након 5–10 минута неактивности и увек се уклањају у року од једног сата од последње употребе кеша.
• Anthropic: Anthropic Кеширање промпта се може захтевати са cache_control. Његова документација описује подударање кеш меморије преко промпт компоненти као што су алати, системски садржај и поруке до блока означеног контролом кеша. Anthropic документује ефемерну кеш меморију, укључујући трајање од 5 минута и опцију од 1 сата уз додатну цену.
• Gemini: Google Gemini Кеширање контекста излаже број погодака токена у кеш преко метаподатака о коришћењу као што је total_cached_tokens, а његова документација наводи минимални број улазних токена по моделу.
• Импликација контроле података: OpenAI API документација о контроли података напомиње да проширено кеширање упита захтева чување тензора кључ/вредност као стање апликације у локалној меморији ГПУ-а. Чак и када добављачи одржавају гаранције изолације, мрежни пролаз треба да третира понашање кеша као осетљиву инфраструктуру, а не као дељено складиште података апликације.
• Сигнал истраживања: Јавно истраживање је испитало да ли архитектуре у стилу мрежног пролаза могу да уведу рањивости брзог кеширања које заобилазе претпоставке о изолацији кеша на нивоу добављача. То не доказује да је одређени гејтвеј рањив, али подржава конзервативни дизајн изолације станара.

Препорука: имплементирајте контролу кеша као функцију мрежног пролаза са експлицитним смерницама, а не као случајни споредни ефекат поновљених упита.

Уговор о брзом склапању за три региона

Најважнија дизајнерска одлука је да се одвоји стабилан и променљив садржај пре него што захтев стигне до адаптера добављача.

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

Стабилни префикс је садржај за који се очекује да остане идентичан у многим захтевима за исту апликацију, руту модела и верзију шаблона упита. Примери укључују:

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

Овај регион би требало да буде детерминистички. Мрежни пролаз би требало да га направи од верзионисаних шаблона, канонизованог JSON и стабилних правила наручивања. Ако је укључен регистар алата, сортирајте алате према стабилном ИД-у алата. Ако су укључене шеме 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"
  }
}

Адаптер мапира употребу добављача у нормализоване категорије:

• Некеширани улазни токени: токени обрађени без попуста за читање кеша или обрачуна за читање кеша.
• Токени кеширања: токени који су креирали или освежили унос кеша на страни добављача када добављач пријави ову разлику.
• Токени за читање у кеш меморији: токени који се сервирају из кеша или се рачунају као кеширани од стране метаподатака о коришћењу добављача.
• Излазни токени: генерисани токени, који би требало да остану одвојени од економије брзе кеш меморије.
• ТТЛ опција: изабрана класа трајања кеша где добављач излаже избор.

Препорука: чувајте сирову употребу добављача у редигованом облику са верзијама шеме поред нормализованих поља. Нормализација је корисна за контролне табле; необрађена поља су неопходна за усаглашавање када се семантика добављача промени.

Уочљивост кеша: контролне табле које објашњавају пропусте

Корисна контролна табла кеша ради више од приказивања укупног броја кешираних токена. То би требало да помогне тимовима да одговоре: „Које оптерећење крши префикс и шта се променило?“

Прати метрику кеша према:

• станар;
• радни простор или апликација;
• модел роуте;
• провајдер и модел;
• промпт темплате версион;
• хеш стабилног префикса;
• полустабилан контекст хеш;
• API кључ или налог услуге, где је прикладно;
• временски прозор, посебно зато што су ТТЛ-ови кеша кратки за многа радна оптерећења.

Корисни изведени показатељи укључују:

• Брзина читања у кеш меморији: кеширани улазни токени подељени укупним улазним токенима који испуњавају услове за кеширање.
• Одлив префикса: број различитих стабилних хешева префикса по верзији шаблона на сат.
• Промена шаблона: промене кеширања након издавања шаблона.
• Цена хладног старта: потрошња кеширања или некешираних улазних података за први захтев у низу.
• Поређење рута: стопе погодака на рутама добављача за исто логичко оптерећење.

Немојте подразумевано чувати необрађене упите за отклањање грешака. Дајте предност хешовима, дужинама региона, ИД-овима шаблона, упозорењима о канокализацији и редигованим разликама. Ако је тиму потребно дубље отклањање грешака, захтевајте експлицитне контроле приступа и ограничења задржавања.

Смернице за изолацију закупца: немојте дизајнирати за поновну употребу међу закупцима

Претпоставка најсигурнијег мрежног пролаза је једноставна: понашање које се може кеширати треба да буде у опсегу закупца. Чак и ако два закупца деле идентичан блок јавне политике, мрежни пролаз не би требало намерно да усмерава или обликује саобраћај да би искористио поновну употребу кеш меморије међу закупцима.

Конзервативна политика укључује:

• Рутирање са свешћу корисника: усмерава саобраћај који се може кеширати користећи границе закупца, радног простора и апликације.
• Нема дељених префикса који садрже тајне: никада не стављајте тајне закупца, акредитиве, приватне документе или податке специфичне за корисника у дељени префикс који се може поново користити.
• Одвојени отисци прстију са префиксом: израчунајте отиске прстију са опсегом закупца укљученим у књигу приступника, чак и ако је приказани текст идентичан.
• Контроле на нивоу организације: дозвољавају администраторима да онемогуће функције кеширања добављача за осетљива оптерећења.
• Изолација добављача није функција производа за препродају: третирајте кеш изолацију добављача као основну заштиту, а не као дозволу за прављење обједињавања кеш меморије међу клијентима.

Предвиђање: како агенти са дугим контекстом постану све чешћи, понашање кеширања ће постати део безбедносних прегледа, а не само прегледа трошкова. Гатеваи-има који могу доказати политику кеша закупца биће лакше управљати.

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

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

1. некеширани улазни токени;
2. кеш за писање токена;
3. кеш читања токена;
4. излазни токени;
5. ТТЛ или накнаде за контролу кеш меморије специфичне за добављача.

Ово је важно када један добављач попусти на кеширано читање, други наплаћује другачије за уписивање у кеш, а други излаже дужу ТТЛ опцију. Фактура клијента би требало да може да објасни зашто су два захтева са сличним укупним улазним токенима имала различите трошкове.

За интерни повраћај средстава, припишите ефекте кеша закупцу и апликацији која је поднела захтев. Избегавајте доделу предности читања кеша од једног закупца другом. Ако заједнички тим интерне платформе поседује стабилан шаблон упита, извештавајте о перформансама кеша на нивоу шаблона одвојено од фактура закупца.

Контролна листа за кеширање

Пре него што омогућите примену кеша, покрените шаблоне упита кроз контролну листу длачица:

• Инструкције за стабилан систем се појављују пре несталног корисничког уноса.
• Шеме алата су сортиране према стабилном ИД-у или имену.
• JSON је серијализован детерминистички.
• У стабилном префиксу се не појављују временске ознаке, насумични ИД-ови, ИД-ови захтева или ИД-ови праћења.
• У дељеним блоковима за вишекратну употребу не појављују се никакве тајне специфичне за корисника.
• РАГ исечци се постављају после одељака смерница и алатки за вишекратну употребу осим ако не постоји намеран разлог да се то не учини.
• Шаблони упита имају експлицитне верзије.
• Издања шаблона могу бити повезана са променама у брзини погодака у кеш меморији.
• Контроле кеша добављача се користе само преко кода адаптера, а не кроз логику раштркане апликације.
• Евидентирање необрађених упита је подразумевано онемогућено или заштићено строгим правилима задржавања и приступа.

План представљања

1. Посматрајте пре него што промените упите

Започните прикупљањем поља за коришћење добављача и нормализованих метрика кеша за постојећи саобраћај. Израчунајте отиске прстију префикса за првих Н токена или за промптне регионе дефинисане мрежним пролазом. Циљ је пронаћи руте великог обима и дугог контекста са великим одливом префикса.

2. Класификујте радна оптерећења

Групирајте саобраћај у категорије: сесије агента, помоћници за кодирање, РАГ, аутоматизација подршке, анализа докумената, групни послови и кратко ћаскање. Брзи рад у кеш меморији обично обраћа највише пажње на радна оптерећења дугог контекста и поновљених префикса. Кратки упити испод граничних вредности добављача можда неће имати користи.

3. Представите програмере за прављење стабилних префикса

Преместите једно радно оптерећење са необрађене брзе конструкције на монтажу засновану на региону. Одржавајте рендеровани захтев добављача семантички еквивалентним. Немојте комбиновати ову промену са миграцијом модела, редизајнирањем алата или већим преписивањем обавештења или нећете знати шта је изазвало промене метрике.

4. Канарска једна рута

Омогућите контроле кеша за мали део једног станара или интерне апликације. Упоредите стопу читања кеша, одлив префикса, време до првог токена, стопу грешке и категорије трошкова. Избегавајте тражење уштеде док се рачуни добављача не помире са главним књигама пролаза.

5. Примените постепено

После канаринца, претворите упозорења о длачицама у провере смерница. На пример, прво упозорите на нестабилан редослед алата, а затим одбијте нове верзије шаблона које укључују променљиве метаподатке у стабилном префиксу.

Размишљања

• Већа стопа погодака у кеш меморији у односу на флексибилност промпта: стабилни префикси побољшавају поновну употребу, али тимови ће можда морати касније да преместе динамичка упутства или редизајнирају шаблоне.
• Кеширање код добављача у односу на преносивост: коришћење контрола кеша сваког добављача може побољшати економију, али се прагови, ТТЛ, поља и семантика цена разликују.
• Уочљивост наспрам осетљивог евидентирања: разлике у промпту помажу у отклањању грешака, али хеширање и редигована дијагностика су сигурније подразумеване вредности.
• Изолација станара у односу на максималну поновну употребу: широка поновна употреба може изгледати привлачно, али понашање закупца је безбедније и лакше за објашњење.
• Дуже задржавање у односу на цену и сложеност смерница: дуже ТТЛ опције могу помоћи сесијама агента, али могу да уведу различита разматрања цена и контроле података.

Закључак који се може применити

Третирајте кеширање промпта као проблем контролне равни мрежног пролаза, а не поље за потврду добављача. Практични образац је: дефинисати стабилне, полустабилне и променљиве промпт регионе; приказати их детерминистички; прилагодити контроле кеша специфичне за провајдере иза једног интерфејса; нормализовати употребу кеша у књигу; изложити дијагностику поготка у кеш меморији према верзији станара, апликације, руте и шаблона; и применити претпоставке закупца.

Први користан корак није поновно писање. Додајте видљивост кеша вашим најдужим упитима, идентификујте одлив префикса и ставите шаблоне који изазивају највише промашаја. Када објасните понашање кеша, можете га безбедно оптимизовати.

Повезано читање

• уградите категорије које су свесне кеш меморије у књигу обрачуна
• придружите се метрикама кеша помоћу безбедног ЛЛМ-а обсервабилити
• одржавајте контекст преузимања у опсегу закупца у РАГ радним оптерећењима