Prefix cache оқшаулауы әр арендаторға қажет

Prefix cache сұраулар бірдей басталғанда қымбат prefill кезеңін үнемдейді. Көп пайдаланушысы бар LLM сервисінде дәл осы оңтайландыру бақыланатын белгіге айналуы мүмкін: белгілі немесе болжанған префикс кэште бұрын болған, сондықтан жауап ертерек қалыптаса бастайды.

Бұл басқа адамның KV cache-ін оқу немесе GPU жадынан промптты тікелей шығару емес. Шабуылдаушы одан тар, бірақ бәрібір пайдалы ақпарат алады: белгілі бір префикс жақында қолжетімді кэш аймағында болған-болмағанын. Банк құжаты, медициналық қорытынды, ішкі нұсқаулық немесе жүйелік промпт үшін кейде осындай сәйкестіктің өзі артық ақпаратты ашады.

Prefix cache оқшаулауы клиенттік SDK-ге сенетін опция емес, сұрауларды бағыттау қасиеті болуы керек. Әр KV cache блогының сенім аймағы болуы тиіс. Басқа аймақтан келген сұрау барлық токендер сәйкес келсе де, hit ала алмауы керек.

Жылдам prefill бар-жоғы туралы оракулға айналады

Шабуылдаушы басқа адамның промптын толық білуі міндетті емес. Ол ықтимал бастаманы, мысалы жоба атауын, келісімшарт шаблонын, жүйелік нұсқаулық үзіндісін немесе хаттан табылған идентификаторды алады, блок шекарасына дейін жеткілікті токен қосып, бірқатар сұрау жібереді.

Егер бір нұсқа дерлік бірдей нұсқаларға қарағанда тұрақты түрде ертерек time to first token берсе, prefix cache hit болды деген болжам пайда болады. Содан кейін шабуылдаушы үзінділерді өзгертіп, жорамалын тарылтады. Мұндай тексерудің ең жағымсыз жері, оны автоматтандыру оңай және басқа пайдаланушының жауаптарына қолжетімділік қажет емес.

Қарапайым реттілік мынадай:

1. Жәбірленуші ұзын жеке контекст жібереді, ал қозғалтқыш толық KV блоктарын сақтайды.
2. Шабуылдаушы басы бірдей кандидаттарды жіберіп, TTFT мәнін көп рет өлшейді.
3. Сәйкес блоктары бар кандидат prefill бөлігін өткізіп, кідірістің басқа профилін береді.
4. Шабуылдаушы кезек пен жауап уақытының қалыпты ауытқуын ескеріп, нұсқаларды салыстырады.

Бір жылдам сұрау ештеңені дәлелдемейді. Кідіріске кезек, үздіксіз batching, суық жүктеу, блоктардың ығыстырылуы, шығару ұзындығы және желі әсер етеді. Бірақ бақылау және тексеру топтары арасындағы қайталанатын айырмашылық классификатор үшін жеткілікті болуы мүмкін. Желі шу қосады деп өзіңізді жұбатпаңыз. Шу экспериментті қиындатады, бірақ ақпарат ағуының түрін өзгертпейді.

vLLM құжаттамасы бұл тәуекелді тікелей сипаттайды: кэшті қайта пайдалану кідіріс айырмашылығынан анықталуы мүмкін, ал cache_salt қайта пайдалануды бірдей тұзы бар сұраулармен шектейді. Бұл KV cache процесс жадында орналасқан және пайдаланушыға көрінбейді деген әдеттегі тұжырымнан маңыздырақ. Арна сервис әрекеті арқылы өтеді.

Блок хеші мен арендатор шекарасы әртүрлі міндет атқарады

Инженерлер prefix cache кілттерінен SHA-256 көріп, мәселе шешілді деп ойлайды. Күшті хеш әртүрлі токендер тізбегінің кездейсоқ немесе әлсіз функция салдарынан бір кілт алуының алдын алады. Бірақ ол екі арендаторға бірдей мәтін үшін бір кілт алуға тыйым салмайды.

Бұл екі бөлек қорғаныс:

• Хеш нақты токендер мен алдыңғы блокты KV cache кілтімен байланыстырады.
• Кэш аймағы бұл кілтті кім қайта пайдалана алатынын анықтайды.
• Тұз әртүрлі аймақтардағы бірдей токендерді әртүрлі кілттерге айналдырады.

Hash-based іске асыруда блок әдетте ағымдағы блок токендеріне және ата-ана блогының хешіне тәуелді болады. Сондықтан тұзды қорғалатын бірінші блокқа қосу жеткілікті: ол оның хешін өзгертеді, ал тізбек кейінгі барлық блоктардың хешін өзгертеді. vLLM құжаттамасы cache_salt үшін дәл осы схеманы сипаттайды.

Бұдан практикалық ереже шығады: тұзды логқа немесе промпт мәтініне қоспаңыз. Ол модель дерегі емес. Тұз тек кэштің ішкі кілтіне кіреді. Оқшаулау үшін system prompt ішіне tenant ID енгізсеңіз, модельдің әрекетін өзгертесіз, токен жұмсайсыз және қозғалтқыштың бұл ID мәнін KV cache кілтінде қолданатынын әлі де дәлелдемейсіз.

Кэш аймағы клиент атауына емес, дерекке қарай таңдалуы керек

Tenant scope ұйымдағы барлық сұрауға бірдей жарамайды. Бір арендатордың құрамында ондаған бөлім, сыртқы клиент және құқықтары әртүрлі пайдаланушы болуы мүмкін. Егер олардың бәрі prefix cache-ті бөліссе, бір пайдаланушы сол компания ішіндегі басқа пайдаланушының контексті бар-жоғын тексере алады.

Мен бір әмбебап баптаудың орнына төрт аймақ қолданамын.

Саясат аймақты деректің шығу тегіне қарай таңдауы керек. Мысалы, барлық клиентке жарияланған ортақ ассистент нұсқаулығы global-public аймағында тұра алады. Жеке кабинеттен жүктелген тіркеме кемінде user аймағын алуы тиіс. Шот нөмірі, диагноз, кадр ақпараты немесе келісімшарт мәтіні бар контексті, пайдаланушы корпоративтік tenant ішінде жұмыс істесе де, әдетте бірден user не request аймағына жатқызамын.

Бұл айырмашылықты жиі былай көмескілейді: «клиент ішінде бәрін кэштеуге болады». Жоқ, клиентпен жасалған келісім барлық қызметкерге әріптестері жақында қандай құжаттарды өңдегенін білу құқығын бермейді. Дерекке қолжетімділік шекарасы мен prefix cache шекарасы мүмкіндігінше сәйкес болуы керек.

Тұзды шақырушы код емес, шлюз тағайындауы керек

Клиент параметрі жергілікті экспериментке ыңғайлы. Өндірісте пайдаланушы тұзды өзі таңдай алса, бұл қауіпті. Шабуылдаушы жәбірленушінің болжамды тұзын, tenant-a сияқты ортақ жолды жібере алады немесе өз сұрауларын әдейі кэштің кеңірек аймағына ауыстыра алады.

Шлюз идентификацияны тексерілген API кілтінен, JWT немесе mTLS сертификатынан алып, серверлік cache identity құруы керек. Оның құрамына әдетте tenant, таңдалған аймақ және саясат нұсқасы кіреді. Нұсқа саясат өзгергеннен кейін кэштің ескі және жаңа мағынасын араластырмау үшін қажет.

Төменде Python тіліндегі логика үлгісі берілген. Бұл дайын кітапхана емес, архитектураны тексеруге арналған ең аз шаблон.

import base64
import hashlib
import hmac

CACHE_SECRET = b"stored-outside-application-config"


def make_cache_salt(tenant_id: str, scope: str, principal_id: str | None) -> str:
    if scope not in {"tenant", "user", "request"}:
        raise ValueError("scope is not allowed for private content")

    subject = principal_id if scope == "user" else "-"
    material = f"cache-v3|{scope}|{tenant_id}|{subject}".encode()
    digest = hmac.new(CACHE_SECRET, material, hashlib.sha256).digest()
    return base64.urlsafe_b64encode(digest).decode().rstrip("=")

request үшін жоғарыдағы функцияны қосымша сұрау немесе дерек объектісі идентификаторынсыз қолданбаңыз. Әйтпесе tenant деңгейінде қайта пайдалану пайда болады, тек оның белгісі басқа болады. Сервер жасайтын және клиенттен қабылданбайтын кездейсоқ request_nonce қосқан қауіпсіздеу.

Аутентификациядан кейін шлюз клиент жіберген cache_salt өрісін алып тастап, өз мәнін орнатуы керек. Аудитке тұздың өзін емес, scope=user, саясат идентификаторы және тұз тағайындалғаны сияқты қауіпсіз өрістерді жазған дұрыс. Шикі тұзды трассировкаға жазу ішкі бөлгішті тасымалданатын құпияға айналдырады.

Тасымалданатын контекст тар шекараны талап етеді

Ақпарат ағуының көбі қарапайым чатта емес, қолданба бірнеше дерек көзінен ұзын промпт құратын бағыттарда пайда болады. RAG, құралдар, агенттік циклдер және жүйелік шаблондар жеке бөліктерден құралса да, ортақ сияқты көрінетін контекст жасайды.

Қозғалтқышқа түспей тұрып, промптты шығу тегіне қарай бөліңіз:

• жария әрі өзгермейтін нұсқаулық жеке тұзсыз қала алады;
• tenant құжаттары tenant тұзын алады;
• ACL бойынша табылған үзінділер мен чат тарихы user тұзын алады;
• бір операцияға жүктелген құпия request тұзын алады.

Бүкіл сұрауға бір cache_salt беру қарапайым әрі сенімді оқшаулауды қамтамасыз етеді, бірақ қайта пайдалануды тарылтады: жеке құжат ортақ нұсқаулықтан кейін келсе, бірінші блоктағы тұз ортақ бөлікті де жабады. Бұл алғашқы қауіпсіз релиз үшін орынды баға.

Күрделірек схема хабарлар немесе сегменттер шекарасына тұз тосқауылын қояды. Сонда ортақ system нұсқаулығы ортақ аймақта қала алады, ал алғашқы жеке хабардан кейін тек қажетті топқа қолжетімді тізбек басталады. vLLM-нің cache salting туралы RFC құжатында осындай иерархия сипатталған: ұйым өз құжатын tenant ішінде бөлісе алады, ал келесі тосқауыл қайта пайдалануды бір пайдаланушымен шектейді. Бұл тәсілді қозғалтқыш сегменттік тосқауылдарды шынымен қолдаса ғана пайдаланыңыз. Әйтпесе шлюз runtime орындамайтын әдемі саясат құрып қояды.

Арендатордың ортақ тұзы болжанатын болмауы керек

acme-prod жолы жөндеуге ыңғайлы, бірақ құпия материал ретінде нашар. Тұз белгілі болса немесе жария tenant ID мәнінен шығарылса, шлюз дұрыс жұмыс істегенде аймақтарды бәрібір бөледі. Бірақ бір жерде тұзды клиент басқаратын жол сақталып қалса, ол қосымша қорғаныс бермейді.

Серверлік құпиясы бар HMAC нәтижесін қолданған дұрыс. Оның бұл жерде қажет бірнеше қасиеті бар:

• клиент басқа арендатордың тұзын есептей алмайды;
• тұз кэш кілттерінің дампында tenant ID мәнін ашпайды;
• шлюз миллиондаған кездейсоқ мәні бар ортақ қоймасыз кез келген репликада тұзды қайта жасай алады;
• нұсқа немесе құпия өзгерсе, жаңа аймақ құрылады және ескі hit мәндері табиғи түрде жарамсыз болады.

HMAC-ты негізгі қорғаныспен шатастырмаңыз. Ең маңызды ереже сол күйінде қалады: scope-ты тек сенімді қабат таңдайды. HMAC тек іске асыруды төзімдірек етеді.

Бірнеше реплика үшін сыртқы немесе таратылған KV cache бөлісе алатын репликаларда бірдей құпия қажет. Кэш әр репликада физикалық түрде жергілікті болса, тұздың сәйкестігі дұрыс семантика үшін бәрібір пайдалы, бірақ оның өзі репликалар арасында қайта пайдалануды тудырмайды.

Арнаны hit rate графигімен емес, экспериментпен тексеріңіз

Hit үлесі баға мен өнімділікті көрсетеді, бірақ оқшаулауды дәлелдемейді. Бір субъект белгілі ұзын префиксті жылытып, екіншісі оны кідіріс арқылы анықтауға тырысатын бөлек тест қажет.

Тесті өндірістегі бағыттағы модель, контекст ұзындығы, generation параметрлері және batching схемасы бірдей стендте өткізіңіз. Бақылау және тексеру сұраулары тек кэш аймағымен ерекшеленуі керек. Әйтпесе арендатор шекарасын емес, шаблонның жанама әсерін өлшейсіз.

Практикалық хаттама мынадай:

1. red және blue атты екі tenant, red ішінде екі пайдаланушы және бөлек API кілттерін жасаңыз.
2. Бірнеше толық блокты қамтитын ұзын синтетикалық префиксті таңдап, оны red/user-1 арқылы жылытыңыз.
3. Сол префиксті red/user-1, red/user-2 және blue/user-1 атынан сериялармен жіберіңіз. Ұқсас, бірақ сәйкес келмейтін бақылау нұсқасын қосыңыз.
4. Әр сұрау үшін серверлік TTFT, промпт ұзындығы, таңдалған scope, кезек және префикс мәтінінсіз cache hit белгісін сақтаңыз.
5. Үлестірімдерді салыстырыңыз. Қайта пайдалану саясат ортақ аймаққа нақты рұқсат берген топтарда ғана болуы керек.

Күтілетін нәтиже қарапайым: red/user-1 user scope жылынғаннан кейін жылдамдауы мүмкін. red/user-2 және blue/user-1 бір контекстті қайталағаны үшін жеке жылдам топқа түспеуі керек. Егер red/user-2 жылдаса, сіз user scope күткен жерде tenant scope орнатқансыз немесе қозғалтқыш тұзды елемейді.

Орташа мәнге сүйенбеңіз. Бірнеше сұрау тыныш кезекке түсіп, орташа мәнді жасанды түрде жақсартуы мүмкін. Квантильдерді, іске қосу санын, іске қосу ретін және топтар реті өзгергендегі қайталануды қараңыз. Жылыту мен ығыстыру бір тест тобына сәйкес келмеуі үшін сұрауларды араластырылған кестемен жіберген дұрыс.

Жауап уақытын кездейсоқ кідіріспен теңестіруге болмайды

Кейде команда cache hit мәнін жасыру үшін жауапқа jitter қосуды ұсынады. Оны gateway-ге енгізу оңай болғандықтан, бұл танымал идея. Бірақ мәселені шешпейді.

Шабуылдаушы көбірек өлшемнің орташа мәнін алады, ал сіз әрбір адал пайдаланушының кідірісін арттырасыз. Сигнал жеткілікті күшті болса, кездейсоқ кідіріс дәлдікті төмендетеді, бірақ арендаторлар арасындағы сәйкестікке тыйым салмайды. Сіз жүйе ішіндегі себепті қалдырып, тек байқалуын емдейсіз.

Тұрақты ең аз кідіріс жақсырақ көрінеді, бірақ оның да бағасы бар: модель алғашқы токенді беруге дайын болса да, сервис күтуі керек. Сонымен бірге айырмашылық prefill ұзақтығында, кезек жүктемесінде, GPU тұтынуында немесе басқа интерфейс арқылы қолжетімді метрикаларда көрінуі мүмкін.

Кэш кілттерін оқшаулау сигнал тудыратын қайта пайдаланудың өзін жояды. Жүйенің басқа қасиеттеріне байланысты тәуекел жоғары болып қалса, таңдалған дерек санаты үшін prefix cache-ті өшіріңіз. Бірақ жасанды кідірісті қолжетімділікті бақылау деп көрсетпеңіз.

Ақпарат ағуы көбіне көрші сервистен басталады

Inference runtime ішіндегі мінсіз тұз басқа қабат деректерді саясаттан кеңірек қайта пайдаланса, көмектеспейді. GPU-дағы KV cache-пен ғана шектелмей тексеріңіз.

Embeddings кэштеріне, retrieval нәтижелеріне, дайын хабар шаблондарына, tool calling жауаптарына, тапсырмалар кезегіне және observability құбырларына ерекше назар аударыңыз. Мысалы, backend KV cache үшін user scope қолдануы мүмкін, бірақ іздеу нәтижесін tenant ID жоқ сұрау мәтінінен жасалған кілтпен сақтайды. Сонда пайдаланушы уақыттық сигналды ғана емес, бөтен үзіндіні тікелей алады.

Кэш identity құратын бірыңғай функция сәйкессіздік қаупін азайтады. Әр кэш өрістердің өз құрамын таңдайды, өйткені дерек пен өмір сүру мерзімі әртүрлі, бірақ tenant және ACL контексті жолда жоғалмауы керек. Кодта мұны ашық атаңыз: retrieval_scope, response_scope, kv_scope. Аймақ көрсетілмеген cache_key атауы қателерді ревью кезінде жасыруы мүмкін.

API шлюзі үшін жеке саясат әсіресе пайдалы. AI Router модельді бағыттамай тұрып cache scope тағайындап, қолданбаға бірыңғай OpenAI-үйлесімді интерфейс бере алады. Бірақ шлюз құжаттың tenant үшін ортақ не жеке екенін өзі болжай алмайды: қолданба дерек классификациясын сенімді серверлік келісім арқылы беруі керек, ал саясат қауіпті scope-тан бас тартуы тиіс.

Өнімділікті сенімді аймақты таңдағаннан кейін есептеңіз

Оқшаулау ықтимал hit санын азайтады, бұл қалыпты жағдай. Алдымен жалпы hit rate-ті барынша өсіріп, кейін салдарын бүркемелеуге болмайды. Мұндай тәртіп бөтен деректер туралы жасырын индикаторлар базасына тез айналатын жаһандық кэшке әкеледі.

Алдымен рұқсат етілген аймақтарды анықтап, содан кейін әрқайсысының ішіндегі қайта пайдалануды өлшеңіз. Көбіне жоғалту күткеннен аз болады: көптурлы диалогтар, бір құжатқа қайталанған сұраулар және бір tenant-тің ортақ нұсқаулықтары жергілікті қайта пайдалануды онсыз да көбейтеді. Tenant-wide қайта пайдалану қажет болмаса, әдемі метрика үшін аймақты кеңейтпеңіз.

Жақсы саясат нақты әрі қарапайым айтылады: жария префикстер тек тексерілгеннен кейін ортақ пайдаланылады; корпоративтік материалдар tenant шекарасынан шықпайды; жеке құжаттар user шекарасынан шықпайды; бір реттік құпиялар request шекарасынан аспайды. Команда бұл ережелерді тест түрінде жаза алмаса, кімнің не себепті жылдамдық алатынын әлі бақыламайды.

Бүгін бір ұзын сұраудың трассировкасын ашып, мына сұраққа жауап беріңіз: оған prefix cache аймағын нақты қай компонент тағайындады? Егер жауап кодта да, аудитте де жоқ болса, тұз әзірге арендаторларды қорғамайды. Ол тек конфигурацияның бір жерінде бар.