Бірдей промпттардағы кэш-шторм: API шарықтауын қалай басуға болады

Мәселе қайдан басталады

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

Тиіп тұрған мысал — қолдау боты. Таңертең оған танымал сұрақ түседі: "Тапсырысым қайда?" Алғашқы жауап әлі құрастырылып жатқанда, сол сұраныс 20, 50 немесе 100 рет жіберіліп үлгереді. Егер жүйе бұл тапсырманың қазірдің өзінде есептеліп жатқанын түсінбесе, әр сұраныс үшін LLM-ге бірдей қоңырау жібереді.

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

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

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

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

Неге бірдей сұраныстар топ-тобымен келеді

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

Бұл ойлағаннан жиірек болады. Пайдаланушылар жұмыс күні басында сервиске кіреді, push-хабарламадан кейін қолдау чатын ашады немесе хат келген соң бір батырманы жаппай басады. Адам үшін бірнеше жүз миллисекунд айырмасы білінбейді, ал API үшін бұл бірден сезілетін пик.

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

Жоспарлаушы да жиі топ жасайды. Командалар тапсырмаларды дөңгелек уақытқа қоюды жақсы көреді: 09:00, 12:00, сағат басы, күн басы. Егер жүздеген тапсырма бір секундта басталып, бірдей промпт құрастырса, шарықтау іс жүзінде кепіл. Кейде бұл тірі трафиктен де қауіпті, өйткені кестеде табиғи шашырау болмайды.

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

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

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

Қайсысы бір тапсырма саналады

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

Сондықтан тапсырма идентификаторы нәтижеге әсер ететіннің бәрінен құралады. Әдетте оған модель мен оның нұсқасы, system prompt, temperature, top_p және токен шегі сияқты параметрлер, жауап форматы, тіл, тіркеме және сұраныс атынан келген клиент кіреді.

Тіпті шамалы баптау өзгерісі дедупликация мағынасын өзгертеді. temperature=0 бар сұраныс болжамды жауап үшін керек. temperature=0.8 бар сұраныс басқа міндет шешеді. Оларды біріктіру қауіпті: біреу күткен нәтижесін алмай қалуы мүмкін.

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

Бірақ мұнда шамадан тыс кету оңай. Кодта, SQL-де, файл атауларында және кейбір JSON-құрылымдарда регистр мен бос орын маңызды. Егер пайдаланушы PDF, кесте немесе сурет тіркесе, тапсырма отпечатогына файлдың өзін де, оның нұсқасын да қосу керек. Бір сұрақ екі түрлі құжатқа қатысты болса, ол дубль саналмайды.

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

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

Сұраныстарды қалай біріктіруге болады

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

Әдетте схема тапсырманың "отпечатогына" сүйенеді. Бұл — промпт, модель, system message және жауапқа әсер ететін параметрлерден жиналған қысқа жол немесе хэш. Егер отпечаток сәйкес келсе, жүйе жұмысты бірдей деп санайды.

Кейін бәрі қарапайым.

1. Жаңа отпечатокпен келген алғашқы сұраныс лидер болады.
2. Лидер тапсырманың қазір орындалып жатқанын білдіретін жазба жасайды да, провайдерге өтеді.
3. Сол отпечатокпен келген келесі сұраныстар модельді қайта шақырмайды, лидердің нәтижесін күтеді.
4. Жауап дайын болғанда лидер оны кэшке сақтап, күтіп тұрғандардың бәріне таратады.

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

Егер жауап сәтті келсе, тек мәтінді емес, пайдалы метадеректерді де сақтаған жөн: модель, жасалған уақыты, TTL, токен саны және статус. Сонда күтіп тұрған сұраныстар дайын нәтижені тез ала алады, ал команда кейін даулы жағдайларды талдап, үнемді есептей алады.

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

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

TTL мен күту терезесін қалай таңдау керек

Біріктіруге арналған TTL үлкен болмауы тиіс. Оның міндеті жауапты "қорда ұстау" емес, бірдей сұраныстардың қысқа толқынын өткізіп жіберу. Егер бірдей промпт 2-3 секунд ішінде ондаған рет түссе, көбіне 15-60 секунд жеткілікті.

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

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

Бастапқыда қарапайым бағдар жеткілікті. Сәтті жауапты 15-60 секунд сақтауға болады. 429 мен таймаут үшін көбіне 1-3 секунд жетеді. 500 немесе 502 сияқты уақытша провайдер қатесі үшін 5-15 секунд жеткілікті. Валидация қателерін, егер себеп нақты пайдаланушыға байланысты болса, кэштемеу керек.

Тағы бір пайдалы ұсақ нәрсе — TTL-ге кездейсоқ ауытқу қосу. Егер барлық жазба дәл 30 секундтан кейін бітсе, жүйе өзі жаңа пик жасайды. 30 секундқа қоса 0-5 секундтай аздап шашырау беру немесе 10-20% jitter қосу оңайырақ.

Күту терезесіне де сол логика жүреді. Мәңгі күтуге болмайды. Егер бірінші сұраныс тұрып қалса, оның артындағы кезек тек үлкейеді. Жылдам операциялар үшін 300-800 мс жиі жеткілікті. Егер генерация әдетте 1-2 секундқа созылса, күту терезесін 2-3 секундқа дейін көтеруге болады. Одан әрі пайдаланушы кешігу құйрығын сезе бастайды.

Егер қоңырауларды AI Router арқылы жүргізсеңіз, бұл мәндерді логтардан таңдау ыңғайлы. Тек орташа кідіріске емес, қайталанатын отпечатоктар үшін p95 және p99-ға да қараңыз. Әдетте TTL тым қысқа қай жерде, ал күту артық кезек жинаған қай жерде екенін тез көрсетеді.

Енгізу тәртібі

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

Алдымен сұраныс отпечатогын жинаңыз. Нақты жауапқа әсер ететін өрістерді ғана алыңыз: system prompt, user prompt, модель, температура, жауап форматы, тіл, генерацияға қатысса, тіркемелердің немесе құжаттардың ID-лері. Timestamp, request_id, IP және басқа шуды қоспаңыз. Әйтпесе бірдей тапсырмалар әртүрлі болып кетеді де, дедупликация жұмыс істемейді.

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

Одан кейін дубльдер үшін күту механизмін қосыңыз. Лидер сыртқы API-ге барып, осы жазбаны өзімен бірге ұстап тұрады. Дубльдер модельді қайта шақырмайды, сол отпечаток бойынша нәтижені күтеді. Егер лидер тұрып қалса немесе өліп қалса, жазба мерзімі бітеді де, күтушілердің бірі жұмысты өзіне алады. Жауап дайын болғанда сервис оны кэшке салып, орындалып жатқан тапсырма жазбасын өшіреді.

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

Тағы бір жиі ұмытылатын ереже: бұғаттауды әрдайым finally ішінде алып тастау керек. Модель қатесі, желілік таймаут немесе клиенттің сұранысты тоқтатуы ілулі жазба қалдырмауы тиіс. Әйтпесе бір ғана ақау пішіні тез арада шарықтаудан қорғайтын механизмді кептеліске айналдырады.

Қолдау ботының мысалы

Банктың қолдау боты көбіне ақаудан емес, кәдімгі хабарламадан пик ұстайды. Банк жаңа карта туралы push жіберді, бір минуттан кейін қолдауға жүздеген бірдей хабарлама түсті: "Бұл картаға лимит қандай?" Алғашқы 200 диалогтың арасында айырма шамалы ғана.

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

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

Біріктірумен бәрі оңайырақ. Жүйе сұраныс отпечатогын есептейді, дәл сондай есеп қазір жүріп жатқан-жатпағанын тексереді де, модельге тек бірінші қоңырауды жібереді. Қалған сессиялар сол нәтижені күтеді. Жауап келгенде, бот оны 30-60 секундтай қысқа TTL-мен кэшке салады да, күтушілердің бәріне бірден таратады. Егер осы терезеде тағы 20 адам дәл сол сұрақты қойса, бот сыртқа жаңа қоңырау жібермей-ақ кэштен жауап береді.

Айырмашылық өте анық болады. Дедупликациясыз банк 200 сыртқы қоңырау жасайды. Біріктірумен сыртқа біреуі ғана кетеді, ал қалған 199 дайын жауапты күту не кэш арқылы алады.

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

Шарықтауды қайтаратын қателер

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

Ең жиі қате — отпечатокқа кездейсоқ өрістерді қосу: request_id, timestamp, trace_id немесе nonce. Сонда екі бірдей промпт екі түрлі хэш алады да, схема мүлде жұмыс істемейді. Отпечатокқа тек жауапты нақты өзгертетін нәрсені ғана салу керек.

Тағы бір шеткі жағдай — TTL-ді тым ұзақ қою. Команда шарықтаудан қорғаныс жұмыс істегенін көреді де, бір сағаттан кейін пайдаланушылар өзгеріп кеткен сұраққа ескі жауап алады. Баға, қалдық, өтінім күйі сияқты деректер үшін бұл жаман нұсқа. Орындалып жатқан тапсырмаға қысқа күту терезесі мен дайын жауапқа бөлек TTL әдетте бәріне бір үлкен мерзімнен жақсырақ.

Келесі қымбат қате — провайдердің уақытша сәтсіздігін мүлде кэштемеу. Провайдер 500 қайтарды, воркер құлады, ал күтіп тұрғандардың бәрі бірден қайта сұрайды. Бір ақау API-ді бомбалауға айналады. Қысқа негативті кэш пен ретрайдағы шағын jitter бұл тәуекелді қатты азайтады.

Жалпы бұғаттау да қиындық тудырады. Егер бір ауыр тапсырма lock-ты алып қойса, қалғандары, тіпті мүлде басқа болса да, себепсіз күтіп қалады. Біріктіру бүкіл сервис бойынша емес, тапсырма отпечатогы бойынша жұмыс істеуі тиіс. Әйтпесе сіз шарықтауды азайтпайсыз, тек кідірісті барлық пайдаланушыға таратып жібересіз.

Тағы бір жиі бұзылатын нәрсе — воркер құлағаннан кейін орындалып жатқан тапсырма жазбасының қалып қоюы. Сұранысты енді ешкім өңдемейді, бірақ жалау ілініп тұр. Жаңа клиенттер не таймаутқа дейін күтеді, не кэшті айналып өтіп, қайта сыртқа барады. Мұндай жазбаларды TTL, heartbeat немесе процесс қайта қосылғанда нақты аяқтау арқылы тазарту керек.

Іске қоспас бұрын жылдам тексеру

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

Алдымен дубль үлесін есептеңіз. Бір күндік немесе кемі пик сағаттағы трафикті алып, сұраныстарды бірдейлік ережеңіз бойынша топтаңыз: промпт, модель, параметрлер, жүйелік контекст, тіл, тіркемелер. Егер дубль 1-2%-дан аз болса, схема күрделілігін ақтамауы мүмкін. Егер 10%, 20% және одан жоғары болса, әсері әдетте бірден байқалады.

Кейін бес нәрсеге қараңыз: бір дубль тобына қанша кіріс сұраныс түсті, олардың қаншасы лидер болып провайдерге шынымен кетті, қаншасы ортақ тапсырма не кэштен жауап алды, дубльдердің орташа күту уақыты қандай және оның p95-і қандай, сондай-ақ қате болғаннан кейін не болады — жаңа әрекет пе, жазбаны тастау ма, әлде ілініп қалған бұғаттау ма.

Бөлек есептеуге тұрарлық тағы бір көрсеткіш — кіріс сұраныстар саны мен нақты сыртқы қоңыраулар санының арақатынасы. Бұл ең түсінікті метрикалардың бірі. Егер 100 бірдей сұранысқа әлі де 70 сыртқы қоңырау кетсе, схема ештеңе үнемдемей отыр. Егер 1-5 қоңырау кетсе, демек логика дұрыс жұмыс істейді.

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

Продакшнда әрі қарай не істеу керек

Біріктіруді бірден барлық тізбекке қоспаңыз. Алдымен дубльдер бюджетке немесе кідіріске нақты әсер етіп тұрған бір ыстық сценарийді таңдаңыз. Көбіне бұл — қолдау чаты, білім базасын іздеу немесе хабарламадан кейінгі бірдей сұрақтар.

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

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

Бұл сандар есеп үшін емес. Олар схеманың қай жерде бұзылатынын көрсетеді: тым қысқа TTL-де ме, нашар кэш кілтінде ме, әлде күту терезесінің қате таңдалуында ма.

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

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

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