Өзін-өзі алдамай, репликалар арасында ортақ KV-cache қолдану

Ортақ KV-cache GPU уақытын бір жағдайда ғана үнемдейді: қашықтағы блок реплика сол префиксті қайта есептеп үлгергеннен бұрын келіп, attention үшін пайдалануға дайын болуы керек. Қалғанының бәрі, соның ішінде cache hit rate көрсетілген әдемі график те, екінші орында.

Іс жүзінде командалар көбіне тек қайта үнемделген токендерді санайды. Содан кейін ортақ қабатты қосып, fabric-ке түсетін қосымша жүктемеге, белсенді cache-тің ығыстырылуына және TTFT-тің ұзын құйрығына тап болады. Мәселе shared cache идеясында емес. Мәселе оны тегін дедупликация деп қабылдауда. Шын мәнінде бұл есептеуді байттарға, кезектерге және жадқа айырбастау.

Жергілікті prefix cache-ті ортақ cache-тен бөлек қарау керек. Жергілікті cache желіге дерлік шығын келтірмейді және бірінші қадам болуы тиіс. Ортақ қабат бір ұзын префикс әртүрлі репликаларға жүйелі түрде түссе, eviction-нен кейін немесе жаңадан іске қосылған экземплярда қажет болады. vLLM құжаттамасы KV-ді экземплярлар арасында KV connector арқылы тасымалдауды және жергілікті сақтауды бөлек сипаттайды. Жүктеу сәтсіз болса, қайта есептеуді немесе сұрау қатесін таңдауды ұсынады. Интерактивті сервис үшін жауаптан бас тартқаннан гөрі қайта есептеу әдетте қауіпсіз.

Алдымен қайталап пайдаланудың үш түрін ажыратыңыз

Ортақ KV-блоктар пулы, жергілікті prefix cache және prefill-ді decode-ке беру әртүрлі міндеттерді шешеді. Оларды бір hit rate метрикасына араластырсаңыз, өтелімділік есебі мәнсіз болады.

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

Ортақ қайталап пайдалану реплика дайын блоктарды басқа түйіннен немесе ортақ сақтау орнынан тапқанда іске қосылады. Ол қайталама prefill-ді жояды, бірақ оқу жолын қосады. Бұл жолға бастапқы көздегі GPU жады, RDMA немесе TCP, қабылдаушы жады, staging буферлері және GPU-ға жүктеу кіруі мүмкін.

Prefill-decode disaggregation бір сұрау үшін KV-ді prefill воркерінен decode воркеріне ауыстырады. Мұнда сұраулар арасында префиксті қайталау мүлде болмауы мүмкін. Күйді есептеу рөлдерін бөлгендіктен тасымалдайсыз. Мысалы, LMCache prefill пен decode арасында KV-ді NVLink, RDMA немесе TCP арқылы тасымалдауды, сондай-ақ экземплярлар арасында префикстерді бөлек қайталап пайдалануды сипаттайды. Бұл механизмдер байланысты болғанымен, бірдей емес.

Салдары қарапайым. Ортақ cache үшін алымда қайталама prefill-ден құтылған пайда тұрады. Disaggregation үшін алымда prefill мен decode-ті бөлек масштабтаудан түскен ұтыс тұрады. Бір архитектураның пайдасын екіншісінің формуласына қоймаңыз.

KV көлемін модель атауына емес, KV бастарына қарап есептеңіз

Префикске арналған KV көлемін attention архитектурасы, сақтау түрі және сұраудың сәйкес келген бөлігінің ұзындығы анықтайды. Модельдің миллиард параметрі бір KV-блоктың көлемі туралы дерлік ештеңе айтпайды.

Ерекше сығу схемалары жоқ dense transformer үшін мына бағалауды қолданыңыз:

байт_на_токен = 2 × L × Hkv × D × q
байт_префикса = байт_на_токен × Tсовпавших

Мұнда L - қабаттар саны, Hkv - KV бастарының саны, D - бір бастың өлшемі, q - KV элементіне кететін байт саны. 2 көбейткіші key мен value-ді есепке алады. FP16 және BF16 үшін q = 2, FP8 үшін әдетте q = 1, бірақ нақты формат пен қызметтік деректерді нақты engine конфигурациясынан алу керек.

GQA кезінде query бастары мен KV бастарының саны әртүрлі. Бұл ұсақ деталь емес. Формулаға барлық query бастарын қойсаңыз, желіге шын мәнінен бірнеше есе көп трафик жоспарлауыңыз мүмкін. Модель MLA, sliding window attention немесе cache-тің өзіндік көрінісін қолданса, стандартты формула да жарамайды. Қысқа және ұзын префиксте бөлінген cache-тің нақты көлемін өлшеп, содан кейін токендер бойынша көлбеуді есептеңіз.

Блоктар есепті өзгертеді. Егер engine cache-ті B токеннен тұратын блоктармен сақтаса, қашықтан тек толық сәйкес блоктар пайдалы болады. Tmatch токен сәйкес келген жағдайда мынаны алыңыз:

Tполезных = floor(Tmatch / B) × B
Sload = байт_на_токен × Tполезных

Толық емес блок ішіндегі соңғы бөлікті қайта есептеуге тура келеді. Жолдық префикс сәйкес келді деп оны remote hit деп атамаңыз.

Жобалауға дейін жасалатын ең аз өлшеу

Өзгермейтін префикстің бірнеше ұзындығымен бір сұрауды іске қосыңыз: мысалы, 4K, 16K, 32K және 64K токен. Нақты KV бөлінуін, prefill уақытын және суық іске қосудағы TTFT-ті жазып алыңыз. Өлшеуді жалғыз сұраумен емес, жұмыс параллельдігі жағдайында қайталаңыз.

Сізге мынадай кесте керек:

prefix_tokens,kv_bytes,cold_prefill_ms,local_hit_ttft_ms
4096,...,...,...
16384,...,...,...
32768,...,...,...
65536,...,...,...

Көршілес жолдардағы kv_bytes айырмасын токендер айырмасына бөлсеңіз, нақты байттық көлбеу шығады. cold_prefill_ms айырмасы сіздің GPU мен batch size жағдайында префиксті қайта оқудың нақты құнын көрсетеді. Бұл басқа кластердегі кез келген калькулятордан сенімдірек.

Қашықтан жүктеу қайта есептеуден айқын жылдамырақ болуы керек

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

Бір қашықтағы hit үшін мынаны қолданыңыз:

Tremote = Tlookup + Tqueue + Sload / Beff + Tstage + Tinstall
Trecompute = Tdispatch + Tprefill(Tполезных)

Tlookup хеш пен метадеректерді іздеуді қамтиды. Tqueue желі арнасын, staging буферін немесе қашықтағы серверді күтуді білдіреді. Beff - дәл сондай бәсекелестік жағдайындағы KV тасымалдаудың пайдалы өткізу қабілеті. Tstage жол тікелей болмаса, CPU жады арқылы өтетін аралық көшірмені есепке алады. Tinstall блоктарды қабылдаушы cache-ке орналастыруды және үйлесімділіктің кез келген тексерісін қамтиды.

Ұтыс шарты қарапайым болғанымен, қымбат қателерден қорғайды:

Tremote + Tinterference < Trecompute

Tinterference - қашықтағы жүктеу белсенді сұраулардан алып қойған уақыт. Ол бір сұраудың трассасында жиі көрінбейді. Мысалы, ұзын remote prefix жүктеуі DMA арнасын алуы немесе бос GPU блоктарын жұмсауы мүмкін. Соның салдарынан ағымдағы decode жад босауын күте бастайды. Формалды түрде remote hit сәтті болды. Бірақ пайдаланушы бәрібір нашар кідірісті көрді.

Желі картасының жылдамдығын спецификациядан алмаңыз. 100 GbE кезінде бірліктерді ауыстырғаннан кейінгі теориялық шек үлкен көрінеді, бірақ application-level ағынды PCIe, NUMA, TCP, pinned memory-ге көшіру, хабарлама өлшемі және бәсекелес тасымалдар оңай шектей алады. Multi-tier offloading кезінде vLLM екінші деңгейлер GPU-ға тікелей жүгінбейтінін ескертеді: тасымал CPU primary tier арқылы жүреді. Мұндай жолды бір желілік линк емес, екі бөлік ретінде өлшеу керек.

Практикалық ереже: remote load-ты мақсатты префикс ұзындығында оның p95 мәні суық prefill-дің p50 мәнінен айтарлықтай төмен болғанда ғана қосыңыз. Орташа мәндердің тең болуы жеткіліксіз. Кезек пен сирек болатын шарықтау кезінде желі ұзын құйрық бойынша дерлік әрдайым ұтылады.

Желінің құнын hit rate емес, байт ағыны анықтайды

Префикс өлшемі көрсетілмеген hit rate басты нәрсені жасырады. 256 токеннен тұратын мың hit пен 64K токеннен тұратын он hit мүлде әртүрлі жүктеме береді, бірақ панельде екеуі де «cache hit» болып көрінуі мүмкін.

Кіріс және шығыс ағындарын бөлек есептеңіз:

Rread = λ × hremote × E[Sload]
Rwrite = λ × hstore × E[Sstore]
Rtotal = Rread + Rwrite + Rreplica

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

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

Желілік бюджетті шарықтау кезіне де есептеу керек. Тәуліктік орташа мәнді емес, ең нашар он бес минуттық интервалды алыңыз. Содан кейін жүктеменің төрт көрінісін тексеріңіз:

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

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

Ығыстырылуды TTL емес, reuse distance арқылы өлшеңіз

Блок пулда TTL рұқсат ететін секундтар санына емес, оның салыстырмалы танымалдығы мен қолжетімді сыйымдылығына байланысты өмір сүреді. TTL өмірдің жоғарғы шегін береді. Ол cache қайталама сұрауға дейін сақталатынына кепілдік бермейді.

Әр префикс немесе бірдей префикстер тобы үшін reuse distance өлшеңіз: сол префикске жасалған екі қатынастың арасында жазылған немесе сұралған бірегей KV-блоктардың көлемі. Қатынастар арасында 300 GB бірегей жұмыс жиыны өтіп, резервтен кейін ортақ пулда нақты 120 GB ғана қолжетімді болса, LRU тәрізді саясатта қайталап оқу дерлік болмайды.

Тиімді сыйымдылық физикалық сыйымдылыққа тең емес:

Ceffective = Cphysical - Cactive_decode - Creserved - Cfragmentation

Cactive_decode-ті бос деп санауға болмайды. Ұзын белсенді генерациялар блоктарды ұстап тұрады. Оларды кенет ығыстыру болашақтағы гипотетикалық hit үшін ағымдағы сервис сапасын бұзуы мүмкін. Cfragmentation блок өлшемдерінен, шардтардың сәйкеспеуінен, толық емес беттерден және қызметтік құрылымдардан пайда болады.

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

«TTL-ді ұзартыңыз» деген кеңес қарапайым болғандықтан танымал. Әдетте ол дұрыс емес. Бірегей префикстерге қойылған үлкен TTL ортақ пулды бір рет қолданылатын деректер қоймасына айналдырады, шын мәнінде жиі қайталанатын блоктарды ығыстырады және каталогқа түсетін қысымды арттырады. TTL бір күні сол құжат қайта келеді деген үмітке емес, байқалған қайталану интервалына негізделуі тиіс.

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

Жаңа реплика сұрауды қабылдап, оны жаңа тар орынсыз өңдей алғанда ғана пайдалы. Бос жергілікті cache оны суық етеді. Ортақ KV-cache бұл суық кезеңді қысқартуы мүмкін, бірақ іске қосу саясаты сәтсіз болса, autoscaling-ті жаппай синхронды жүктеуге айналдырады.

Трафик шарықтағаннан кейін он жаңа decode репликасы пайда болды деп елестетіңіз. Олардың бәрі ұзын жүйелік нұсқауы және ортақ контекст базасы бар ұқсас сұраулар алады. Балансировщик сұрауларды біркелкі таратса, әр реплика бірдей блоктарды оқуға тырысады. Бір ескі жылы реплика бұл деректерді жергілікті ұстап тұрса да, сіз оқу fan-out-ын жасадыңыз.

Репликаның өмірінің алғашқы минуттарына бөлек ережелер қажет:

1. Жаңа репликадағы және ортақ пулдағы қатар жүретін remote load санын шектеңіз.
2. Жаңа реплика қажетті базалық жиынтықты алғанша, алғашқы қайталанатын сұрауларды жылы экземплярларға бағыттаңыз.
3. Кездейсоқ соңғы сұрауларды емес, өлшенген ыстық префикстерді ғана алдын ала қыздырыңыз.
4. Readiness-ті процестің іске қосылғанына емес, мақсатты профильді өңдеу қабілетіне қарап анықтаңыз.
5. Қашықтан жүктеу кезегі өссе, қайта есептеуді басқарылатын fallback ретінде қалдырыңыз.

«Cache-ті қыздыру» да есептеуді қажет етеді. W байтты N репликаға Δt терезесінде тасымалдасаңыз, тек осы қыздырудың өзіне қалыпты трафикті есептемегенде шамамен N × W / Δt пайдалы өткізу қабілеті керек. Арна көтермесе, жаңа репликалардың бір бөлігінде prefill жасау үйлестірілген жүктеуден арзанырақ әрі жылдамырақ болуы мүмкін.

Mooncake жұмысында бөлек prefill және decoding кластерлері мен өткізу қабілеті және SLO көрсеткіштерін ескеретін жоспарлаушысы бар KVCache-бағдарланған архитектура сипатталған. Бұдан кез келген ортақ cache-ті дәл солай құру керек деген қорытынды шықпайды. Басқа қорытынды шығады: cache қолданбаның астындағы мөлдір кітапхана емес, жоспарлаушының ресурсына айналады.

Дұрыс шекара болса, жартылай hit толық hit-тен жиі тиімді

Ұзын сұраудың барлық префиксі бірдей болмайды. Жүйелік нұсқау ортақ болуы мүмкін, одан кейін бірдей RAG жиыны, содан соң пайдаланушының жеке тарихы келеді. Engine алғашқы толық сәйкес блоктарды алып, tail бөлігін қайта есептей алса, partial hit prefill-дің басым бөлігін жояды.

Мұндай жағдайды былай есептеңіз:

Ttotal = Tremote(Tcommon) + Tprefill(Ttail) + Tdecode

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

Банк, healthcare немесе мемлекеттік секторда «бүкіл prompt-ты хештеп, барлық жерде сақтау» идеясы аса қауіпті. Хештің өзі KV-cache кіріс мәтінін өңдеу күйін кодтайтынын өзгертпейді. Cache namespace-ін модель, токенизатор нұсқасы, attention параметрлері, адаптер, tenant және деректер класы бойынша бөліңіз. Оқшаулаудың жоқтығын ұзын TTL немесе кілттің кездейсоқ префиксі арқылы өтеуге тырыспаңыз.

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

Пайданы іздемей тұрып үйлесімділікті тексеріңіз

KV-блоктар «ұқсас модель» үшін әмбебап нәтиже емес. Олар нақты модельге, салмақтарға, токенизаторға, токендердің позициясына, cache форматына, attention іске асырылуына және кейде қосылған адаптерге тәуелді. Модельдің маркетингтік атауы бірдей екі endpoint KV алмасуға үйлесімсіз болуы мүмкін.

Cache кілтінде кемінде модель мен ревизия идентификаторы, префикс токендерінің хеші, позицияны қалыптастыру параметрлері, KV форматы, блок өлшемі және tenant namespace болуы керек. LoRA немесе басқа адаптер қолданылса, оның нұсқасын да қосыңыз. Жүйелік prompt өзгерсе, мәтіндік ұқсастыққа сенбеңіз: басында өзгерген токен кейінгі бүкіл префиксті жылжытады.

Prompt құрастырудың детерминизмін де тексеріңіз. Команда cache-ті кінәлағанымен, miss себебі қарапайым болуы мүмкін: бір сервис күнді қосады, екіншісі құралдардың ретін өзгертеді, үшіншісі JSON-ды басқаша сериализациялайды. Промпттар көзге бірдей көрінеді. Токендер тізбегі бөлек, демек сәйкестік жоқ.

vLLM ішінде producer, consumer және both рөлдерінің коннекторлары мен конфигурациясы бар. Жүктеу қатесі саясаты recompute немесе fail болуы мүмкін. Бұл маңызды ескерту: тасымалдау жолы таймауты, лимиттері және бақыланатын fallback-ы бар сервис келісімінің бөлігі болуы керек. Ол генерация мен қашықтағы cache арасындағы міндетті тәуелділікке айналмауы тиіс.

Шешім сұраудың күтілетін құны бойынша қабылданады

Енгізуге дейін өлшеулерді бір модельге жинаңыз. Кластердің мінсіз симуляциясы қажет емес. Пайда таңбасы қай жерде өзгеретінін көрсететін адал баға жеткілікті.

i сұраулар класы үшін мынаны жазыңыз:

E[выгода_i] = hremote_i × (Trecompute_i - Tremote_i)
              - Pstall_i
              - Pwrite_i
              - Peviction_i

E[выгода_всего] = Σ λi × E[выгода_i]

Pstall-ды tail кідірісінің миллисекундтарымен немесе жоғалған өнімділіктің құнымен көрсетіңіз, бірақ оның жоқ екенін көрсетпеңіз. Pwrite кейін ешкім оқымаған блоктарды жариялауды қамтиды. Peviction пайдалырақ деректерді ығыстыру құнын көрсетеді. Соңғы екі мүшені бағалай алмасаңыз, кемінде шектеулі сыйымдылықпен және ұзын сұраулардың нақты қоспасымен жүктеме тестін өткізіңіз.

Пайдалы жұмыс эксперименті бірнеше айға созылмайды. Қайталанатын префикстердің бір класын алыңыз, жаңа tail бөліктерін жарияламайтын read-only shared cache қосыңыз, қашықтағы жүктеулерге қатаң лимит қойыңыз және төрт үлестірімді жинаңыз: суық prefill, local hit, remote hit және fallback recompute. Содан кейін желі зиян келтіре бастаған нүктені p95 TTFT пен throughput көрсеткенше remote reads-тің рұқсат етілген үлесін арттырыңыз.

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

Тағы бір сақтау қабатын сатып алудан бастамаңыз. Алдымен нақты префикстердің трассасын алыңыз, токенге кететін байттарды есептеңіз, пайдалы өткізу қабілетін өлшеңіз және miss себептерін бөліңіз. Осыдан кейін сізге ортақ KV-cache, жылы репликаларға ақылдырақ маршрутизация немесе жай ғана жеткілікті жергілікті cache қажет екені көрінеді.