LLM сұранымдарын микробатчингтеу: SLA бұзбай құнын қалай азайтуға болады

Неліктен жеке шақырулар тез қымбаттайды

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

Мысалы, өтініштерге тег қоятын ішкі сервисті елестетіңіз. Бір мәтін ғана, 2–3 жол. Бір қысқа жауап. Пайдалы жұмыс аз, ал сұраным айналасындағы қосымша қабат ұзақ тапсырмадағыдай дерлік. Күніне осындай ұсақ шақырулар мыңдап жиналса, бюджет мағынаға емес, бірдей қызметтік қабатты қайта-қайта қайталауға кетеді.

Жұмыс уақыты кезінде мәселе одан әрі күшейеді. Таңғы 10-да қызметкерлер бір мезетте хаттарды қысқарту, кездесулерді талдау, құжаттарды жіктеу және CRM карточкаларын тексеруді іске қосады. Бұл тапсырмалардың көбі шұғыл емес, бірақ жүйе оларды бірден келіп тұрғандықтан шұғыл сияқты өңдейді. Кезек үлкейеді, rate limits үшін бәсеке артады, кейін 429, таймауттар және қайта жіберулер басталады.

Ішкі процестерде бұл әсіресе өкінішті, өйткені кейбір тапсырмалар 2–10 секундтық кідірісті толық көтере алады. Пайдаланушы чатта жауап күтпейді. Ол есепті ашады, басқа қойындыға өтеді немесе пакеттік тексеруді іске қосады. Бірақ қосымша бәрібір әр сұранымды жеке жібереді, уақыт жүздеген миллисекундпен өлшенетіндей көрінеді.

Ақша байқалмай қайда жоғалады

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

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

Шағын пакеттер қай жерде тиімді

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

Жақсы мысал — түскен сайын пікірлерді, тикеттерді және ішкі өтініштерді талдау. Айталық, 3 секунд ішінде қолдау кезегіне 12 жаңа хабарлама келді. 12 бөлек шақырудың орнына жүйе оларды бір шағын пакетке жинап, модельден тақырып, шұғылдық және қысқа қорытынды сұрайды, кейін жауаптарды карточкаларға қайта бөледі. Қызметкер тикетті кейінірек ашады, сондықтан қосымша кідіріс дерлік білінбейді.

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

Өтініштерді, лидтерді және сұрауларды жіктеу де жиі өзін ақтайды. Бұл — меткалары анық, қайталанатын жұмыс: "жаңа лид", "қайталанған", "шағым", "қоңырау керек", "спам". Жауап нұсқалары аз болып, ұзын мәтін қажет болмаса, пакеттер ішкі SLA-ға айтарлықтай зиян келтірмей бағаны төмендетеді.

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

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

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

Қай кезде жеке режимді қалдырған дұрыс

Микробатчинг бәріне бірдей жарамайды. Егер адам жауапты дәл қазір күтсе, пакет жинау үшін қосымша 300–800 мс жұмсау көбіне токен үнемінен қымбатқа түседі. Ішкі тапсырмаларда бұл әсіресе модель тірі интерфейсте жұмыс істегенде анық көрінеді.

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

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

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

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

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

Микробатчингті қалай іске қосуға болады

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

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

1. Кезекке күту шегін қойыңыз. Көбіне 1–3 секунд жеткілікті. Осы уақыт ішінде пакет толық жиналмаса, барын жіберіңіз.
2. 4–8 сұранымнан тұратын шағын пакеттерден бастаңыз. Бұл әдетте бағаны төмендетуге және жауапты тым созбауға жеткілікті.
3. Ұқсас тапсырмаларды бірге жинаңыз. Ұзындығы, промпт түрі және күтілетін жауап көлемі бойынша топтастыру жақсы жұмыс істейді. Қысқа және өте ұзын сұранымдарды араластырсаңыз, бүкіл пакет ең ауырын күте бастайды.
4. Қателер үшін бөлек ереже ұстаңыз. Егер пакеттегі бір сұраным таймаутқа немесе лимитке түссе, қалғандарын бөгемеңіз. Тек сәтсіз элементтерді қайталаңыз.
5. Орташа бағаға ғана емес, бәріне қараңыз. Бір пайдалы жауаптың құнын, p50, p95 және қателер үлесін салыстырыңыз. Әсіресе p95 жағдайдың жақсы болғанын, әлде мәселе тек кешігудің соңына ауысқанын көрсетеді.

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

Жақсы бастама жалықтыратындай көрінеді — бұл жақсы белгі: бір кезек, бір тапсырма түрі, 4 көлеміндегі батч, 2 секундтық таймер және бірнеше күндік өлшем. Егер p95 қалыпты деңгейде қалса әрі тапсырма бағасы төмендесе, батчты 6 немесе 8-ге дейін өсіріп көріңіз. Егер кезек сағат басында немесе түстен кейін ұлғайса, SLA төмендей бастағанша күтпей, батч өлшемін кішірейтіңіз.

SLA-ны қалай бұзбаймыз

SLA көбіне пакеттің өзінен емес, оған бәрін бір жерге салып, тым ұзақ күткеннен бұзылады. Егер сұранымға 2–3 секундта жауап беру керек болса, оны 20–30 секундтық тапсырмалармен бір кезекке қоюдың қажеті жоқ.

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

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

Жеке бір тұзақ — қысқа және өте ұзын промпттарды араластыру. Бір ауыр сұраным бүкіл пакетке салмақ салады да, p95 API шотына қарағанда тезірек өседі. Трафикті кемінде екі класқа бөлген дұрыс: жеңіл сұранымдар және ұзын сұранымдар. Бұл дөрекі ереже сияқты көрінеді, бірақ SLA-ны көбіне нәзік баптаудан жақсырақ сақтайды.

Срывтардың екінші көзі де бар: ретрайлар мен провайдердің лимиттері. Егер провайдер 429 немесе уақытша қате қайтарса, пакет қайта жіберіледі де, жауап уақыты бірден өседі. Сондықтан модельдің қалыпты кідірісіне ғана емес, қайталама әрекеттерге, олардың арасындағы паузаларға және RPM немесе TPM шектеулеріне де орын қалдырыңыз. Онсыз қағаздағы есеп әдемі көрінеді, ал жұмыс уақытында кезек кенеттен цемент сияқты қатып қалады.

Практикалық минимум мынадай: шұғыл және фондық тапсырмаларды араластырмау, пакет көлемі мен күту уақытын шектеу, қысқа және ұзын промпттарды бөлу, SLA-ны ретрайлар мен rate limits-ті ескеріп есептеу және p95 үнемнен жылдам өссе, пакеттерді өшіру. Егер үнем 8% болып, p95 40% өссе, сол сценарийде пакеттерді өшірген дұрыс.

Іске қоспас бұрын нені өлшеу керек

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

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

Қол астында бірнеше санды ұстаған пайдалы:

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

Орташа уақыттың өзі көп нәрсе айтпайды. Пайдаланушыға немесе ішкі сервиске орташа емес, ұзын құйрық әсер етеді. Егер орташа 2,1 секундтан 1,8 секундқа түсті, ал p95 4 секундтан 11 секундқа өссе, режим нашарлады, тіпті баға сәл төмендесе де.

Пакеттердің толуын да бөлек қараңыз. Егер батчты 8 тапсырмаға баптап, іс жүзінде көбіне 2 немесе 3 қана жинасаңыз, сіз күту үшін төлейсіз, бірақ толық пайда алмайсыз. Жұмыс уақыты ішінде көрініс жиі өзгереді: таңертең ағын тығыз, түстен кейін үзік-үзік, кешке пакеттер қайта жылдамырақ жиналады.

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

Егер трафик AI Router арқылы өтсе, аудит-журналдар мен кілт бойынша лимиттер үнемнің шын қайда екенін, ал қайда оны таймауттар, қайталама шақырулар немесе тым кішкентай ағын жеп қойғанын тез көрсетеді. Жақсы бағдар қарапайым: бір пайдалы тапсырманың құны төмендеуі керек, ал p95 SLA шегінде қалуы тиіс.

Ішкі кезекке арналған мысал

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

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

Мұндағы жұмыс схемасы қарапайым. Кезек жаңа тапсырмаларды жинайды, воркер не 6 диалог жиналғанша, не 30–45 секунд өткенше күтеді де, оларды бір пакетпен жібереді. Промптта ортақ нұсқау бір рет жазылады, одан кейін бірдей жауап құрылымы бар алты диалог келеді.

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

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

Шұғыл тексерулерді бөлек шығарған дұрыс. Клиенттің шағымы, инцидентті талдау немесе басшылықтың сұрауы күнделікті рутинемен бір пакетте тұруға тиіс емес. Олар үшін микробатчингсіз екінші кезек немесе бір ғана сұранымнан тұратын пакет жасалады.

Бұл мысал жақсы, өйткені ол процесті күрделендіріп қайта құруды талап етпейді. Сіз бағалау шаблонын өзгертпейсіз, қызметкерлерге жаңа логика үйретпейсіз және бірден жауап береміз деп уәде бермейсіз. Тек жүйеге 30–45 секунд шағын пакет жинауға уақыт бересіз де, 5 минуттық мерзімді бұзбай LLM құнын айтарлықтай төмендетесіз.

Жиі жіберілетін қателер

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

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

Пакет өлшемін "ең үлкені болсын" деп қою да аз қиындық әкелмейді. Стендте 32 сұранымдық пакет арзан көрінуі мүмкін. Жұмыс уақытында ол көбіне тым ұзақ жиналады. Ішкі тапсырмалар үшін әдетте екі шектеу керек: қанша сұраным жинауға болатыны және олардың қанша миллисекунд күте алатыны. Әйтпесе жүйе толық пакет қуып, SLA-ны жоғалтады.

Тағы бір тұзақ — тек орташа кідірісті қарау. Орташа сан әрдайым тыныштандырады, бірақ адамдар орташа мәнді емес, p95-ті сезеді. Егер сұранымдардың 80%-ы жылдам өтсе, ал қалғаны 4–6 секунд ілініп тұрса, есеп қалыпты көрінеді, ал қызметкерлер жүйені қолмен айналып өтеді. Сондықтан latency-ге ғана емес, кезек жасына, пакет өлшеміне және мерзімі өткен сұранымдар үлесіне де қарау керек.

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

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

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

Микробатчингті әдет бойынша қоса салуға болмайды. Ол тапсырма 2–5 секунд күте алатын және пайдаланушы мұны байқамайтын жерде жақсы жұмыс істейді. Ішкі таңбалау, хаттарды қысқарту, жауап нобайларын жасау және түнгі тексерулер үшін бұл жиі қалыпты. Нақты уақыттағы оператор чаты үшін — күмәнді.

Іске қосар алдында төрт нәрсені тексерген пайдалы. Бірнеше секундтық кідіріс процесті бұзбауы керек. Промпттар пішіні мен көлемі жағынан ұқсас болуы тиіс, әйтпесе пакеттер тез біркелкі емес мінез көрсете бастайды. Команда алдын ала "жылдам" сияқты бұлыңғыр сөзсіз рұқсат етілген p95-ті атауы керек. Ал одиночный режимге бір флагпен немесе маршруттау ережесімен бір минутта қайту мүмкін болуы тиіс.

Тағы бір практикалық тест бар. Әдеттегі жұмыс сағатынан 100–200 нақты сұраным алып, ұзындықтың таралуына қараңыз. Егер промпттардың бір бөлігі 300 токен, ал бір бөлігі 10 000 токен болса, бір ортақ пакет тез-ақ қолайсыз болады. Ондайда алдымен ағынды тапсырма түрлері бойынша бөлген дұрыс.

Жақсы бастама жалықтыратындай көрінеді, бірақ бұл — плюс. Бір ішкі кезек, шағын пакет өлшемі, қатаң күту лимиті және қарапайым кері қайту. Мысалы, команда тек қызметкерлер өтініштерінің қысқаша мазмұнын 1–2 секундтық тереземен батчтайды. Егер p95 келісілген шектен асып кетсе немесе қателер көбейсе, трафик бірден одиночный режимге қайтады. Мұндай іске қосу LLM құнының азаюы SLA тәуекелсіз бола ма, соны адал көрсетеді.

Келесі аптада не істеу керек

Ең көзге түсетін сценарийден бастамаңыз. Алғашқы пилот үшін қарапайым әрі түсінікті SLA бар бір ішкі процесті алған дұрыс: тикеттерді талдау, қоңыраулар бойынша қорытынды, саппортқа арналған нобай жауаптар немесе құжаттарды жіктеу. Егер тапсырма 10–60 секунд кідірісті көтере алса және клиентке тікелей әсер етпесе, ол ең қолайлы.

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

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

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

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