LLM кластеріндегі prefix cache ескерілетін маршрутизация

LLM кластерінің кәдімгі балансировкасы көбіне маңызды нәрсеге қарамайды. Ол бос жадты, кезек ұзындығын, белсенді тізбектер санын және GPU жүктемесін көреді. Бірақ нақты сұрау үшін орындалған prefill кезеңін көрмейді. Сондықтан ұзын құжатты дайын, бірақ суық воркерге оңай жібереді, ал көрші воркерде сол құжаттың дайын KV-кэші тұр.

Қайталанатын жүйелік промпттарда, үлкен саясат құжаттарында, шарттарда, медициналық қорытындыларда және RAG-контексттерде аз есептеу кейде босырақ видеокартадан маңыздырақ. Бұл бүкіл трафикті бір GPU-ға байлау керек деген сөз емес. Маршрутизация алдымен қайталама prefill құнын бағалап, содан кейін оны кезекпен және қолжетімді жадпен салыстыруы керек.

Бос GPU жылдам жауапқа кепіл емес

Бос GPU суық сұрауға жақсы, бірақ басқа воркер дәл сол құжаттың 30 000 токенін өңдеп қойғаны оған еш артықшылық бермейді. Ол бұл токендерді модель арқылы қайта өткізіп, барлық қабаттардың KV-күйлерін жасап, содан кейін ғана жауап генерациясына көшуі керек.

Қыздырылған воркерде жағдай басқаша. Жаңа сұрау сол токендерден басталса, қозғалтқыш KV-кэштің сәйкес блоктарын тауып, тек жалғасын есептейді: пайдаланушы сұрағын, жаңа хабарламаларды, құралдарды немесе өзгерген контексттің шағын бөлігін. Мұндайда бірінші токенге дейінгі уақыт құжаттың толық ұзындығына емес, жабылмаған жалғастың ұзындығына және воркер алдындағы кезекке тәуелді.

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

Бұл әсіресе жүктеменің үш түрінде байқалады:

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

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

Prefix cache мағынаны емес, токендерді салыстырады

Prefix cache сұраудың басындағы бірдей токендер тізбегіне арналған KV-күйлерді қайта пайдаланады. Ол екі абзацтың мағынасы бір екенін түсінбейді. Өрістерінің реті басқа JSON нысандарын тең деп санамайды. Жол ауыстыру алдындағы бос орын мағынаны өзгертпейтінін де білмейді.

vLLM құжаттамасында automatic prefix caching дәл осылай сипатталған: қозғалтқыш бұрын өңделген префикстің KV жұптарын қайта пайдаланып, оны қайта есептемейді. vLLM жобасының құжаттамасында блоктар блоктың өз токендерінің және алдыңғы префикстің хэштерімен байланысады. Бұл пайдалану кезіндегі дұрыс модель: сізге «ұқсас» кіріс емес, айырмашылық басталғанға дейінгі токенизацияланған тарихтың дәлме-дәл бірдей болуы керек.

Осыдан жағымсыз, бірақ пайдалы қорытынды шығады. Көп жүйеде кэшке түсудің басты жауы жоспарлаушы емес, қолданбалы код болады.

Мысалы, мына екі құрылым логикалық тұрғыдан бірдей, бірақ кэш үшін әртүрлі болуы мүмкін:

Системная инструкция\\n\nДокумент: ...\\n\nВопрос: Какой срок оплаты?

Системная инструкция\\n\nВремя запроса: 2026-07-23T10:15:00Z\\n\nДокумент: ...\\n\nВопрос: Какой срок оплаты?

Екінші нұсқада құжаттың алдына өзгермелі өріс қосылған. Уақыттан кейінгі барлық токен бірінші сұрауға қатысты жылжиды да, ұзын құжат ортақ префикс болудан қалады. Команда мәселені әдетте кеш байқайды: cache hit rate төмен, GPU prefill-мен босамай тұр, ал үлгі «дерлік бірдей».

Жиі араластырылатын екі нәрсені ажыратыңыз:

1. Құжаттың сәйкес келуі. Бұл пайдалы, бірақ құжаттың алдында өзгермелі деректер болса, prefix hit-ке кепілдік бермейді.
2. Префикстің сәйкес келуі. Дайын KV-кэшті алуға нақты мүмкіндік беретін нәрсе осы.

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

Кәдімгі балансировка кэш локалдылығын бұзады

Round robin, least connections және ең аз жүктелген GPU-ды таңдау сұрауларды біркелкі таратады. Веб-серверлер мен қысқа API қоңыраулары үшін бұл орынды. Ұзын әрі қайталанатын контексті бар LLM-инференсінде біркелкілік артық жұмыстың көзі болуы мүмкін.

Бір модельдің төрт репликасын елестетіңіз. Сізде 40 000 токендік бір регламентке арналған 200 сұрау бар. Қарапайым round robin кезінде әр реплика бұл құжатты белгілі бір сәтте қыздырады, бұл кэштің мүлдем болмағанынан жақсы. Бірақ кейін дәл сондай көлемдегі екінші, одан соң үшінші құжат келеді, ал KV-кэш жады шектеулі. Әр реплика префикстердің кездейсоқ қоспасын сақтай бастайды. Ығыстыру жиілейді, қажетті қыздырылған жиынға түсу ықтималдығы төмендейді.

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

Промпттарды үлестіріп жоспарлауға арналған Preble жұмысы кэш туралы көптеген маркетингтік сипаттамадан пайдалырақ түсіндіреді. Авторлар prefix cache-ке түскен сұрауды decode жүктемесіне, ал кэшке түспеген сұрауды prefill жүктемесіне жақын деп қарастырады. Айырмашылық ойлағаннан маңызды. Prefill ұзын кірісте есептеу ресурстарын тез алады. Decode ұзаққа созылғанымен, дайын күйлермен жұмыс істейді және жадты басқаша жүктейді.

Егер балансировщик бұл жұмыс түрлерін ажыратпаса, ол бір уақытта:

• суық ұзын сұрауды ауыр prefill жүріп жатқан жерге жібере алады;
• cache hit сұрауын бос GPU-ға жіберіп, оны cache miss-ке айналдырады;
• бір пулды ұзын құжаттармен толтырып, басқа пулда қыздырылған сәйкестіктер барын елемейді;
• кездейсоқ қысқа трафик үшін қайта жасау қымбат префиксті ығыстырады.

Кәдімгі балансировщик «нашар» емес. Оның орындалған жұмыстың құны туралы сигналы жоқ.

Қыздырылған префикс әрқашан жеңбеуі керек

«Әрқашан hit бар жерге бар» деген ереже бір GPU алдында кезектің тез жиналуына әкеледі. Prefix-aware маршрутизацияның алғашқы нұсқалары осылай бұзылады. Команда cache hit rate жоғары екенін көріп қуанады, ал пайдаланушылар күте береді, себебі роутер оларды бір қыздырылған воркерге тым ұзақ байлап қойған.

Екі нұсқаның күтілетін құнын салыстыру керек. Әр кандидат үшін роутер мынаны бағалайды:

ожидаемая задержка =\n  ожидание в очереди\n  + prefill для непокрытых токенов\n  + влияние на decode активных запросов\n  + риск нехватки KV-памяти

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

Практикалық ережені әдетте былай қоямын: қыздырылған воркерге басымдық беріледі, бірақ оның болжамды бірінші токенге дейінгі уақыты суық баламадан алдын ала таңдалған шектен артық нашар болмауы керек. Бұл шек қажет, өйткені кезек бағасы ешқашан мінсіз болмайды, ал cache hit келесі сұраулар үшін нақты құндылық береді.

Бір ғана «ең жақсы» воркердің орнына реттелген тізімді сақтаған пайдалы:

1. Қабылдауға болатын кезегі бар дәл hit.
2. Қабылдауға болатын кезегі бар ішінара hit.
3. Қыздырылған кандидаттар сұрауды тым ұзақ ұстаса, бос воркер.
4. Жұмыс репликалары қымбат ыстық префикстерді сақтап тұрса, бөлек cold-пул.

Ішінара hit маңызды. 30 000 токеннің алғашқы 24 000-ы сәйкес келсе, бұл сұрау құнын әлі де қатты өзгертеді. Бірақ сәйкестік ұзындығын сәйкестік үлесімен шатастырмаңыз. 2 100 токеннің 2 000-ы және 100 000 токеннің 2 000-ы prefill бойынша бірдей абсолют үнем береді, пайыздары мүлдем бөлек көрінгенімен.

Тұрақты промпт үлгісі айлакер роутерден пайдалырақ

Қолданба әр шақырғанда кездейсоқ өзгеретін промпттарды роутер түзете алмайды. Алдымен кірісті кэштеуге болатын пішінге келтіріңіз.

«Бір құжат, көп сұрақ» тапсырмалары үшін хабарлама реті мынадай болғаны жақсы:

{\n  \"model\": \"chosen-model\",\n  \"messages\": [\n    {\n      \"role\": \"system\",\n      \"content\": \"Ты отвечаешь только по приложенному документу. Если факта нет, так и скажи.\"\n    },\n    {\n      \"role\": \"user\",\n      \"content\": \"\u003cdocument id=contract-184\u003e...полный нормализованный текст документа...\u003c/document\u003e\\n\\nВопрос: Какой срок оплаты?\"\n    }\n  ]\n}

Пайдаланушы сұрағы құжаттан кейін тұр. Құжат идентификаторы тұрақты. Мәтін әрдайым бірдей нормализациядан өтеді. Жүйелік нұсқауда ағымдағы күн, кездейсоқ trace ID немесе пайдаланушы аты жоқ.

Нашар рет көбіне әзірлеушіге ыңғайлы болғандықтан пайда болады:

{\n  \"role\": \"user\",\n  \"content\": \"Пользователь=84721; запрос=af1e; время=...\\nВопрос: Какой срок оплаты?\\nДокумент: ...\"\n}

Мұнда өзгермелі деректер ұзын контекстің алдында тұр. Адам үшін бұл зиянсыз жол. Prefix cache үшін ортақ құжат енді ортақ болып саналмайтын шекара пайда болады.

Нормализация детерминирленген болуы керек. Мыналарды бекітіңіз:

• жол ауыстыру пішімі;
• сериализацияланған JSON-дегі кілттер реті;
• артық бос орындарды жою ережелері;
• жүйелік промпт үлгісінің нұсқасы;
• RAG-контекст фрагменттерінің реті.

Соңғы тармақ жиі талас тудырады. Әзірлеушілер табылған бөліктерді тек релеванттылық бойынша сұрыптағысы келеді де, бірдей сұрау неге hit бермейтінін түсінбей қалады. Екі фрагменттің релеванттылығы жақын болса, тұрақты tie-breaker қолданыңыз, мысалы дереккөз идентификаторы мен ондағы позиция. Нәтиже вариативтілігінің азаюы ұзын префиксті қайта пайдаланудан жиі өтеледі.

Трассировка үшін динамикалық өрістерді жүйелік промптқа қоспаңыз. trace ID мәнін тақырыптарда, шлюз метадеректерінде немесе жеке журналда жіберіңіз. Промпт токендері қызметтік шуға жұмсалатындай қымбат қабат.

Ұзын құжат пен RAG-контекстке әртүрлі ережелер керек

Бір толық құжатқа қайталанатын сұрақ prefix cache үшін өте қолайлы. Толық құжат тұрақты, сұрақтар соңында өзгереді, ал қайталама prefill құны сезіледі. Мұндай трафикте роутер нормализацияланған құжат хэшін префикс кілтінің бөлігі ретінде қолдана алады.

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

RAG үшін контексті екі деңгейге бөлгенді жөн көремін:

1. Тұрақты қабат: жүйелік нұсқау, жауап саясаты, терминдер анықтамалығы, өзгермейтін ережелер базасы, құрал профилі.
2. Өзгермелі қабат: табылған фрагменттер, сұрақ, нақты пайдаланушының тарихы, жаңа деректер.

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

Аралық жағдай да бар: пайдаланушы бір табылған құжаттар жиыны туралы диалог жүргізеді. Онда жиынды сессияда бекітіп, фрагменттер ретін сақтап, жаңа хабарламаларды соңына ғана қосқан пайдалы. Мұнда кэш «чаттың» өзінде сиқыр бар болғандықтан емес, әңгіме тарихы нөлден қайта жиналмай, префикс ретінде өскендіктен пайда болады.

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

Маршрутизация кілті тек мәтінді емес, үйлесімділікті көрсетуі керек

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

Кандидаттың ең аз кілтін былай сипаттар едім:

cache_namespace =\n  model_revision\n  + tokenizer_revision\n  + adapter_id\n  + prompt_template_version\n  + normalized_prefix_hash

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

Қолданба хэшін cache hit дәлелі деп санауға болмайды. Бұл ықтимал кандидатты табуға арналған индекс қана. Воркер таңдалғаннан кейін inference engine токендердің нақты сәйкес келуін растайды және метрикалары мүмкіндік берсе, табылған префикс ұзындығын хабарлайды.

Маршрутизация журналы мынадай болуы мүмкін:

{\n  \"request_id\": \"req_8f2c\",\n  \"model\": \"chosen-model\",\n  \"prefix_key\": \"pfx_4b19\",\n  \"selected_worker\": \"gpu-03\",\n  \"candidate_workers\": [\"gpu-03\", \"gpu-01\"],\n  \"predicted_cached_tokens\": 24576,\n  \"actual_cached_tokens\": 24320,\n  \"queue_wait_ms\": 38,\n  \"prefill_tokens\": 912,\n  \"decision\": \"prefer-warm-worker\"\n}

Мұнда predicted_cached_tokens және actual_cached_tokens жұбы маңызды. Егер олар үнемі алшақтаса, мәселе GPU-да емес, кірісті сәйкестендіруде екенін таптыңыз. Бұған уақыттың жасырын қосылуы, үлгінің өзгеруі, парк бөлігіндегі басқа токенизатор немесе екі сервисте әртүрлі жұмыс істейтін нормализатор себеп болуы мүмкін.

Multi-tenant ортада кілтке tenant немесе policy namespace қосыңыз. Егер оқшаулау ережелері нақты кэшті ортақ пайдалануға тыйым салса, тек мәтін сәйкестігі үшін сұрауды бағыттауға болмайды. KV блоктары техникалық тұрғыда бөлек болса да, маршруттың рұқсат етілгенін тексеру кідірісті оңтайландырудан бұрын жасалуы керек.

Роутерге суық жол және ашығудан қорғау керек

Ыстық префикс жоспарлаушыны оңай монополиялайды. Бір танымал шарт немесе жүйелік промпт үздіксіз ағын тудырса, роутер бір GPU-ды қайта-қайта таңдайды. Бір кезде басқа маңызды құжаты бар сұрау келеді де, басқа жерде бос ресурс болса да, тым ұзақ күтеді.

Кэш локалдылығы әділетсіздікке айналмауы үшін шектеулер қажет.

Біріншіден, warm preference үшін ең ұзақ күту уақытын белгілеңіз. Осы уақыттан кейін сұрау hit-тен айырылса да, қалыпты ереже бойынша жіберіледі. Бұл кэшке қарсы ымыра емес. Бұл пайдаланушы кідірісін қорғау, ол әрқашан әдемі орташа hit rate-тен маңызды.

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

Үшіншіден, генерация ұзындығын ескеріңіз. Үлкен құжаты бар қысқа сұрақ қыздырылған префикстен көп пайда көреді. Ұзын генерация decode слоттарын ұзақ уақыт алып қоюы мүмкін, сондықтан барлық ыстық трафикті соған жіберу қауіпті. Роутер output tokens шегін кемінде жуықтап көруі және қысқа жауаптар мен кеңейтілген генерацияларға әртүрлі шек қолдануы керек.

Соңында affinity-ді мерзімсіз жасамаңыз. Префикс ығыстырылуы, модель қайта іске қосылуы немесе жаңартудан кейін воркер жадынан айырылуы мүмкін. Болжамды қыздыру жазбасын өмір сүру уақытымен сақтап, промахтар болғанда оның сенімділігін төмендетіңіз. Болмаған кэшке сенетін роутер адал round robin-нен де нашар: ол есептеу үнемделмей, трафикті кезекке жібереді.

Метрикалар үнемделген prefill-ді көрсетуі керек

Cache hit rate жалғыз өзі оңай адастырады. Әр hit-ті бірдей санасаңыз, 64 токенге түсу 30 000 токенге түскендей жақсы көрінеді. Құн мен кідіріс үшін бұл екі түрлі оқиға.

Кемінде метриканың бес қатарын бақылаңыз:

• модель мен пул бойынша cached input tokens және uncached input tokens;
• warm hit, partial hit және cold miss үшін бірінші токенге дейінгі уақыт;
• маршрут таңдау себебі бойынша кезекте күтудің орташа уақыты;
• KV-кэш ығыстырулары және ығыстырылған префикстердің жасы;
• күту шегіне байланысты warm кандидаттан бас тартылған сұраулар үлесі.

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

Қарапайым есеп жүргізу де пайдалы. Әр сұрау үшін суық іске қосылғанда өңделетін токендер санын және prefill-ге іс жүзінде жіберілген токендер санын сақтаңыз. Айырмашылық GPU-секундтардың дәл санына тең емес, бірақ бағытты көрсетіп, үлгі өзгергеннен кейінгі регресті байқауға мүмкіндік береді.

Әсерді тек GPU-дың жалпы жүктемесінен шығаруға тырыспаңыз. Кэш қосылғаннан кейін жүктеме тіпті өсуі мүмкін, өйткені жүйе пайдалы жұмысты көбірек қабылдайды немесе decode кезеңіне жылдамырақ жетеді. Пайдаланушы метрикаларын тексеріңіз: бірінші токенге дейінгі уақыт, толық кідіріс, таймаут үлесі және өңделген кіріс токенінің құны.

Маршрутизацияны өлшенетін бір трафик класынан бастаңыз

«Компанияның барлық промптынан» бастау қажет емес. Қайталануы анық бір ағынды таңдаңыз: көп қызметкер талдайтын бір құжат, үлкен өзгермейтін нұсқауы бар көмекші немесе үлгілік сауалнамаларды өңдейтін сервис.

Енгізуді мына ретпен жасаңыз:

1. Бірнеше күн журнал жинап, тек мәтіндік сәйкестікті емес, ортақ токендік префикстердің ұзындығын есептеңіз.
2. Үлгіні бекітіп, өзгермелі өрістерді кэштелетін блоктан кейін орналастырыңыз.
3. Prefix cache-ті шектеулі пулда қосып, inference engine беретін нақты cached tokens мәндерін жинаңыз.
4. Қатаң күту шегі мен суық қосалқы маршруты бар warm preference қосыңыз.
5. Warm, partial және cold сұрауларын бірінші токенге дейінгі уақыт, кезек және ығыстыру бойынша салыстырыңыз.

Үшінші қадамда нақты кэшке түсу өте аз болса, GPU таңдау формулаларын күрделендірмеңіз. Промпт үлгісіне қайта оралыңыз. Нақты жүйелерде бұл скоринг функциясына тағы бір коэффициент қосудан жиі көбірек нәтиже береді.

AI Router мұндай эксперимент үшін ыңғайлы нүкте болуы мүмкін, өйткені ол OpenAI-үйлесімді сұрау пішімін сақтайды, ал пулды таңдау логикасы API-шлюзде қалады. Бірақ шлюздің өзі қайталануды жасамайды: оны қолданбаның контекст жинау тәртібіндегі тәртіп қалыптастырады.

Қайталану дәлелденгенде ғана аз есептеу бос жадтан маңызды

Prefix-aware маршрутизация жүктеме бойынша балансировканы жоймайды. Ол оған орындалып қойған prefill құнын қосады. Қайталанатын префикстері жоқ кластерде бұл артық күрделілік. Бір ұзын контексті қайта-қайта оқитын кластерде қыздырылған KV-кэшті елемеу бір жұмыстың ақысын бірнеше рет әдейі төлеумен тең.

Сәнді жоспарлаушыны таңдаудан емес, журналдарыңызға бір сұрақ қоюдан бастаңыз: пайдаланушылар алғашқы 10 000 токенді қайталап жібере ме? Егер жауапта жүйелік нұсқаулар, құжаттар, саясаттар немесе тұрақты RAG блоктары болса, маршрутизацияға арналған нысан дайын. Енді оны суық GPU-ларға шашыратуды тоқтату керек.