Сұраныс кэшінің өтелімділігі: формуласы және есептеу мысалдары

Неге өтелімділігі бірден көрінбейді

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

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

Айырмашылықты күнделікті сценарийлерден жақсы көруге болады. Қолдау бөлімінде тапсырыс мәртебесі, қайтарым және жұмыс уақыты туралы сұрақтар жиі қайталанады. Онда кэш орташа трафиктің өзінде-ақ айтарлықтай әсер беруі мүмкін. Іздеуде бәрі күрделірек: бір қолданушы «кроссовкалар 42» деп жазады, екіншісі «қара түсті ерлерге арналған жүгіру кедалары» дейді, ал формалды түрде бұл — басқа сұраныс. Хат генерациясында нәтиже шаблондарға байланысты. Егер команда ұқсас хаттарды бір үлгімен жіберсе, қайталану бар. Егер әр хат нөлден жиналса, пайдасы аз болады.

Сондықтан «кэш керек» немесе «кэш керек емес» деген талас көбіне ешқайда апармайды. Бір адам қолдаудағы біртекті өтініштер ағынын көреді, екіншісі іздеудегі сирек әрі ұзақ сұраныстарды көреді, екеуі де шынайы нәрсе айтып тұр. Тек деректері әртүрлі.

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

Есепке не кіреді

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

Алдымен кэшсіз қалыпты сұраныстың бағасын алыңыз. Іздеу үшін бұл модельді шақыру және дерекқордағы іздеу болуы мүмкін. Қолдау үшін — жүйелік промпт пен диалог тарихы бар модель жауабы. Хат генерациясы үшін — шаблон, тон және клиент деректері бар толық сұраныс.

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

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

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

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

Артық математикасыз қарапайым формула

Есептеуді күрделі статистикасыз да жүргізуге болады. Төрт сан керек:

• P — кэшсіз модельдің толық шақыру бағасы
• H — кэшке түскен кездегі сұраныс бағасы
• K — жауапты кэшке жазуға кететін бір реттік шығын
• R — бірдей сұраныстың шын мәнінде қанша рет қайталанатыны

Кэшсіз бір сұраныстың орташа бағасы әрдайым P-ге тең. Егер бірдей сұраныс 10 рет келсе, сіз 10 рет толық баға төлейсіз.

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

C_cache = P + K + (R - 1) * H

Бір өтініштің орташа бағасы мынадай болады:

Avg_cache = (P + K + (R - 1) * H) / R

Кэш орташа баға кэшсіз баға­дан төмен болғанда ақталады:

(P + K + (R - 1) * H) / R < P

Егер өрнекті ықшамдасақ, қайталану шегін аламыз:

R > (P + K - H) / (P - H)

Бұл — сұраныс кэшінің өтелімділігін тексерудің қарапайым жолы. Егер K нөлге жуық болса, кэш екінші бірдей сұраныстан-ақ үнем бере бастайды. Егер кэшке жазу, ұқсастықты тексеру немесе сақтау айтарлықтай қымбат болса, көбірек қайталану қажет.

Мысал. Айтайық, толық шақыру 0.10 тұрады, кэшке түсу 0.01, ал кэшке жазу 0.02 тұрады. Онда:

R > (0.10 + 0.02 - 0.01) / (0.10 - 0.01) = 1.22

Демек, екі қайталау-ақ жеткілікті.

Енді арзанырақ модельді алайық: P = 0.03, ал H пен K бұрынғыдай болсын. Нәтиже:

R > (0.03 + 0.02 - 0.01) / (0.03 - 0.01) = 2

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

Қадамдап қалай есептеу керек

Ең дұрысы — сезімге емес, жаңа дерекке сүйену. Соңғы 2-4 аптадағы логтардан үлгі алыңыз. Трафик көп болса, бірнеше мың сұраныс жеткілікті. Трафик аз болса, бар болғанының бәрін алыңыз.

Сосын сұраныстарды бір қалыпқа келтіріңіз. Регистрдегі айырманы, артық бос орындарды, көзге көрінетін қателерді және тапсырыс нөмірі сияқты ұсақ қосымшаларды, егер мағына өзгермесе, алып тастаңыз. Одан кейін тек бірдей тіркестерді емес, мағынасы өте жақын сұраныстарды да бірге жинаңыз. Қолдау үшін бұлар «тапсырысым қайда» және «тапсырыс қашан жеткізіледі» болуы мүмкін. Іздеу үшін — «nike кроссовкалар 42» және «nike кроссовкалар 42 өлшемі».

Әрі қарай схема қарапайым. Алдымен қанша сұраныс кемінде бір рет қайталанғанын санаңыз. Сосын қайталануларды уақыт терезелері бойынша бөліңіз: сол күні, 7 күн ішінде және 30 күн ішінде. Әр терезе үшін кэшке түсу үлесін табыңыз: hits / all requests. Одан кейін ақша мәндерін қойыңыз: модель жауабының бағасы, кэшке жазу құны және кэштен оқу құны. Соңғы тексеру былай көрінеді:

үнем = hits * (модель бағасы - кэштен оқу бағасы) - жазбалар * кэшке жазу бағасы

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

Есептен кейін кэшті бірден бүкіл ағынға қоспаңыз. Оны трафиктің шағын бөлігіне, мысалы 5-10%-ына қосып, екі нәрсені тексеріңіз: кэшке түсу үлесі есептелген мәнге сай келді ме және жауап сапасы төмендемеді ме. Кейде кэш ақша үнемдегендей көрінеді, бірақ ескірген деректерді бере бастайды. Қағазда жақсы, ал жұмыста тез бұзылады.

Егер LLM трафигін бір ортақ шлюз арқылы жүргізсеңіз, модельдің бағасын нақты провайдерге апаратын маршрут бойынша алған ыңғайлы, ал кэштің құнын өз инфрақұрылымыңызда бөлек есептеңіз. Сонда сұраныстардың қайталану жиілігіне қарай кэштің шынымен қашан ақталатынын оңайырақ көресіз.

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

Интернет-дүкен бір ғана сұраныс түрімен өмір сүрмейді. Бір жүйеде каталог бойынша іздеу, қолдау чаты және менеджерлер ұқсас себептермен сұрайтын хаттар қатар жүреді.

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

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

Егер тек жалпы ағынға қарасаңыз, мысалы 28% қайталану көріп, кэш күмәнді деп шешіп қоюыңыз мүмкін. Бірақ осы орташа санның ішінде іздеу түнде тек 12% қайталану бере алады, қолдау күндіз 40%, ал хаттар 65% болуы мүмкін, өйткені шаблондар әр сағат сайын дерлік қайталанады.

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

Іздеу үшін қалай есептеу керек

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

Негізгі есеп қарапайым:

кезең бойынша үнем = іздеу сұраныстарының саны * кэшке түсу үлесі * (іздеудің толық бағасы - кэштен оқу бағасы) - сол кезеңдегі кэштің өз құны

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

Іздеу сұранысын есептегенде әдетте нормаланған мәтіннің өзін, сүзгілер мен сұрыптауды, тілді немесе аймақты, сондай-ақ іздеу түрін — сайт бойынша ма, әлде каталог бойынша ма — қосады. Дәл осы өрістер екі сұранысты қауіпсіз түрде бірдей деп санауға бола ма, соны шешеді.

Кішкентай мысал. Айтайық, каталог бойынша іздеу аптасына 100 000 сұраныс алады. Толық іздеу 0,12 теңге, кэштен оқу 0,01 теңге, кэшті ұстап тұру 1 800 теңге аптасына тұрады. Егер нормалаудан кейін кэшке түсу үлесі 28%-ға жетсе, үнем мынадай болады:

100 000 * 0,28 * (0,12 - 0,01) = 3 080 теңге

1 800 теңгені шегергеннен кейін 1 280 теңге қалады. Демек, кэш қазірдің өзінде ақталады.

Сол сандарды нормалаусыз алып, кэшке түсу үлесі тек 12% болса, үнем 1 320 теңге болады. Бұл шығыннан төмен. Идея бірдей, ал нәтиже теріс.

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

Қолдау үшін қалай есептеу керек

Қолдаудағы кэшті бірдей фраза бойынша емес, бірдей мағына бойынша есептейді. Бір клиент «тапсырысым қайда» деп жазады, екіншісі — «қашан жеткізеді», үшіншісі — «неге жеткізу үнсіз» дейді. Есептеу үшін бұл — бір типтегі сұрақ. Егер тек жолдарды салыстырсаңыз, сұраныстардың қайталануы тым төмен болып көрінеді.

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

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

Формула мынадай:

үнем = қайталанулар * (толық жауап бағасы - кэш-хит бағасы - тексеру бағасы) - қате берулер * қате құны

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

Мысал. Команда айына 20 000 өтініш өңдейді. Топтастырғаннан кейін сұрақтардың 40%-ы қайталанатыны көрінеді. Модельдің толық жауабы 4 теңге тұрады, кэштен беру — 0,5, ал өзектілікті тексеру тағы 0,7 теңге. Бір қайталанудан үнем 2,8 теңге болады. Онда шамамен айлық үнем:

20 000 * 40% * 2,8 = 22 400 теңге

Енді тәуекелді қосайық. Егер кэштен берілген жауаптардың 1%-ы ескірсе, ал бір қате орташа есеппен қайталама өтініш пен қолмен өңдеуге 30 теңге әкелсе, шығын былай болады:

20 000 * 40% * 1% * 30 = 2 400 теңге

Таза үнем әлі де бар, бірақ 22 400 емес, 20 000 теңге шамасында.

Қарапайым тақырыптар үшін кэш әдетте тиімді. Төлемдер, медицина және құқықтық ережелер үшін алдымен қате тәуекелін азайтыңыз, содан кейін ғана токендерді есептеңіз.

Хаттар генерациясы үшін қалай есептеу керек

Хаттар үшін бүкіл сұранысты дәл кэштеу күткендей жиі жұмыс істемейді. Әдетте командада каркас қайталанады: модельдің рөлі, тон, бренд ережелері, хат құрылымы және стиль шектеулері. Ал клиенттің аты, тауар, күн, сома және тапсырыс тарихы бүкіл сұранысты бірегей етеді.

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

Қарапайым бағалау жарайды:

үнем = хат саны * ортақ бөліктің қайталану үлесі * кәдімгі және кэштелген енгізу арасындағы баға айырмасы

Мысал. Команда айына 6 000 хат жібереді. Әр хатта 2 000 токендік ортақ каркас және 400 токендік айнымалы дерек бар. Осы 2 000 токен үшін кәдімгі енгізу 2 теңге, кэштелгені 0,5 теңге тұрады. Егер бірдей ортақ бөлік хаттардың 65%-ында қайталанса, есеп мынадай:

• 6 000 * 0,65 = 3 900 кэшке түсу
• бір хаттағы үнем = 1,5 теңге
• айлық үнем = 3 900 * 1,5 = 5 850 теңге

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

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

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

Ең жиі қай жерде қателеседі

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

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

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

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

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

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

Іске қоспас бұрын тексеру

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

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

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

Іске қосар алдында команда қарапайым ережелерге келісуі керек: кэш үшін жауапты жеткілікті бірдей деп қашан санау керек, кім және қандай оқиғадан кейін жазбаларды өшіреді, нәтижені қанша уақыт сақтау керек және қандай метрикаларды күн сайын қарау керек. Әдетте екеуі жеткілікті: hit rate және қате үлесі. Тағы бір керек нәрсе — сапа төмендесе, кэштен оқуды тез өшірудің түсінікті жолы.

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

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

Әрі қарай не істеу керек

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

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

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

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

Егер сұраныстар бір OpenAI-үйлесімді шлюз арқылы өтсе, есептеу жеңілірек: маршруттар бойынша логтар мен тарифтерді бір жерге жинау оңай. Қазақстандағы командалар үшін мұндай сынақты AI Router арқылы airouter.kz сайтында тез тексеруге болады — тек base_url мәнін api.airouter.kz етіп ауыстырып, SDK, код және промпттарды сол күйі қалдыру жеткілікті.

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