AI-тапсырмаларды кезекке беру: қашан async-пайплайнға көшіру керек

Тікелей веб-сұрау қай жерде сынады

Мәселе көбіне модельден емес, күту уақытынан басталады. Пайдаланушы батырманы басады, ал бет 8, 15 немесе 30 секунд бойы тұрып қалады — LLM мәтінді оқып, ойланып, жауап құрастырғанша. Чат үшін бұл кейде жарайды. Ал құжатты классификациялау, қоңырауды суммаризациялау немесе файлдан өрістерді шығару үшін — жоқ.

Кәдімгі веб-сұрау жауап бірден керек болғанда жақсы. AI-шақыруда жауап беру уақыты құбылып тұрады. Бір сұрау 2 секундта өтеді, келесісі — 18 секундта. Егер тізбекте файл жүктеу, OCR, бірнеше промпт және нәтижені қайта тексеру болса, кешігу одан әрі өседі. Пайдаланушы айналып тұрған белгішені көреді, соңында көбіне қате алады, ал тапсырманың өзі әбден қалыпты болатын.

Одан кейін таймауттар басталады. Браузер, балансировщик, nginx, backend және модель SDK-сы әрқайсысы өз лимитімен өмір сүреді. Сіздің функцияңыз бір минут күтуге дайын болса да, тізбектегі біреуі сұрауды ертерек үзеді. Ең жағымсыз жағдай қарапайым: модель жұмысты аяқтауға жақын, бірақ клиент байланысын үзіп үлгерді, сөйтіп бүкіл сценарий соңында-ақ үзіледі.

Тағы бір мәселе бар — трафиктің күрт өсуі. Он пайдаланушы бір уақытта үлкен құжаттарды суммаризацияға жіберсе, тек AI бөлігі ғана емес, бәрі баяулайды. Қарапайым беттер, логин, тапсырыс карточкалары мен іздеу де соққы алады. Бір ауыр синхронды жол қосымшаның воркерлерін оңай бітеп, connection pool-ды жеп қояды.

Мұны әдетте бірнеше белгі көрсетеді:

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

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

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

Қандай тапсырмаларды фонға жіберу керек

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

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

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

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

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

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

Жауап бірден керек болғанда

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

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

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

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

Кейде синхронды шақыру финалдық жауап үшін емес, келесі қадамды таңдау үшін керек болады. Жиі мысал — негізгі сұраудың алдындағы қысқа маршрутизация. Алдымен модельге 1-2 сөйлем бересіз: «бұл классификация ма, база бойынша іздеу ме, әлде суммаризация ма?» Содан кейін код басқа промптты, токен лимитін немесе модельдің өзін таңдайды. Мұндай бірінші шақыру жылдам болуы тиіс, әйтпесе бүкіл тізбек баяулайды.

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

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

Қарапайым async-пайплайнды қалай құруға болады

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

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

Ең аз қажет схема

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

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

Нәтиже мен мәртебені бөлек сақтаған дұрыс. Мәртебе «қазір не болып жатыр?» деген сұраққа жауап береді: queued, running, done, failed. Нәтижесі бөлек жазбада модель жауабын, өңдеу уақытын, ақау кезіндегі қатені және қажет болса аудитке арналған метадеректерді сақтайды. Бұл қайталап іске қосуды жеңілдетеді және қызметтік ақпаратты пайдалы дерекпен араластырмайды.

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

Тәжірибеде бұл былай көрінеді. Менеджер 500 клиент өтінішін суммаризацияға жүктейді. Интерфейс бірден пакеттің қабылданғанын көрсетеді және тапсырма нөмірін береді. Бірнеше минуттан кейін экран жаңарып, менеджер ілініп қалған сұранысты емес, дайын нәтижелік файлды көреді.

Кезек хабарламасына не салу керек

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

Алдымен объект ID-сін және мәтін көзін жіберіңіз. ID нәтижені кейін дұрыс жазбаға сақтауға керек, ал дерек көзі үлкен бөліктерді себепсіз кезекке тасымалдамауға көмектеседі. Хат, өтініш немесе тауар карточкасы үшін көбіне document_id=84521 және source=crm.ticket_body сияқты жұп жеткілікті. Егер мәтін қысқа әрі қауіпсіз болса, оны хабарламаның өзіне қоюға болады. Егер мәтін үлкен немесе жеке деректер бар болса, ішкі сақтауға сілтемені немесе жазба жолын берген дұрыс.

Келесі қадам — промпт нұсқасын және күтілетін жауап форматын қосу. Бұл кеше «қысқа қорытынды» сұрағаныңызбен, бүгін category, confidence және reason өрістері бар JSON күткен жағдайда шатасудан сақтайды. Хабарламада prompt_version=summary_v3 және response_schema=incident_extract_v2 сияқты нәрсені нақты жазған дұрыс. Сонда қайта өңдеу сол ережемен жүреді және нәтиже бұрынғы іске қосумен салыстырылады.

Аяқталу мерзімі де керек. Фондық тапсырманың көбінде дедлайн болады, тіпті ол аса қатаң көрінбесе де. Ішкі панельге арналған есепті суммаризациялау 10 минут күте алады, ал операторға арналған өтінішті өңдеу, мысалы, 30 секундтың ішінде бітуі керек. Жанына қайталау саны мен ағымдағы әрекет нөмірін сақтаңыз. Егер модель не провайдер қолжетімсіз болса, воркер тапсырманы шексіз айналдыра бермеуі тиіс.

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

Тағы бір өріс көп уақыт үнемдейді — дубльді кесуге арналған бірегей кілт. Бір құжат кездейсоқ кезекке екі рет түссе, жүйе оны түсінуі керек. Әдетте мұндай кілтті тапсырма түрінен, объект ID-сінен және промпт нұсқасынан құрайды, мысалы ticket-84521-classify-v2. Сонда воркер дубльді өткізіп жібереді немесе бұрыннан бар тапсырманы жаңартады да, екі бөлек нәтиже жасамайды.

Жақсы кезек хабарламасы тек LLM-ді іске қоспайды. Ол тапсырманы қайталанатын, мерзімі бойынша басқарылатын және ақша жағынан болжамды етеді.

Кәдімгі жұмыс ағынынан мысал

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

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

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

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

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

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

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

Неге кейде кезек те құтқармайды

AI-тапсырмалар кезек арқылы тек кезектің өзі қарапайым әрі болжамды болғанда жақсы жұмыс істейді. Ережелерді алдын ала қоймасаңыз, проблеманы веб-сұраудан фонға ауыстырып қана қоясыз: кідіріс өседі, жауаптар қайталанады, ал ескі тапсырмалар шексіз ілініп тұрады.

Тәжірибеде қай жері бұзылады

Жиі жіберілетін қате — хабарламаға файлға сілтемені емес, тұтас PDF, аудио не үлкен JSON салу. Бұдан кезек тез үлкейіп кетеді, қайта әрекеттер көбірек уақыт алады, ал воркерлер дерек тасымалдауға ресурс жұмсайды. Әдетте объектіге жолды, файл хэшін, өлшемін және бірнеше қызметтік өрісті беру анағұрлым дұрыс.

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

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

Ақаудан кейін тапсырма кейде тұрақты идентификаторсыз қайта іске қосылады. Нәтижесінде бір құжат екі суммаризация алады, CRM екі жазба жасайды, ал есеп бір кейсті екі рет санайды. Қайта іске қосу қауіпсіз болуы тиіс, әйтпесе кезек өзі қоқыс өндіреді.

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

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

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

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

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

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

Интерфейс мәртебені көрсете ме? Адам бос экранды емес, түсінікті күйлерді көруі тиіс: «кезекте», «өңделіп жатыр», «дайын», «қате». Команда модель қателессе немесе жауап бермесе, не істейтінін біле ме? Қарапайым ережелер керек: сұрауды қанша рет қайталау, тапсырманы қашан қолмен тексеруге жіберу, қашан сәтсіз деп белгілеу.

Сіз бір тапсырманың бағасын және қайталау бағасын есептейсіз бе? Онсыз кезек үнсіз бюджет жейтін қара жәшікке айналып кетеді.

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

Жақсы белгі — нәтиже оқиғадан кейін табиғи түрде келуі. Мысалы, менеджер 300 пікір жүктеді, жиналысқа кетті де, бірнеше минуттан кейін дайын тегтер мен қысқаша сводканы алды. Жаман белгі — контакт-орталық операторы LLM жауап бергенше жұмысты жалғастыра алмайды.

Қайталау құнын бөлек тексеріңіз. Бір сәтсіз әрекет әдетте қорқынышты емес. Үлкен құжатқа он рет автоматты қайталау — айқын шығын.

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

Артық қайта құрусыз неден бастау керек

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

Жақсы алғашқы кандидат — 10-20 бет құжатты суммаризациялау немесе одан өріс шығару. Пайдаланушы файл жүктейді, жүйе тапсырма қабылданғанын бірден айтады да, кейін өңдеуді фонға тыныш жібереді. Интерфейс 30-60 секундқа қатып қалмайды, ал сервер open web сұрауды босқа ұстамайды.

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

Интеграцияны екінші рет қайта жасамас үшін модель шақыруын бір OpenAI-совместимый қабаттың артына жасырыңыз. Сонда қосымша нақты провайдерге емес, бір ішкі клиентке жүгінеді. Кейін base_url-ды ауыстыра аласыз, резерв маршрут қоса аласыз немесе бизнес-логиканы қайта жазбай-ақ басқа модель класын таңдай аласыз.

Қазақстандағы командалар үшін бұл әсіресе ыңғайлы, егер бірден әртүрлі модельдерге бір болжамды жол және түсінікті операциялық ережелер керек болса. Мысалы, api.airouter.kz-дегі AI Router OpenAI-совместимый эндпоинт, теңгемен ай сайынғы B2B-инвойсинг және қажет болса ел ішінде деректерді сақтау, PII-ді маскалау, аудит логтары сияқты құралдарды береді.

Бастапқыда бес қадам жеткілікті:

• бір ұзақ және шұғыл емес процесті таңдау
• қысқа сұраулар үшін синхронды жолды қалдыру
• модель шақыруын біртұтас клиентке шығару
• task_id, мәртебе, өңдеу уақыты және құнын жазып отыру
• аяқталған соң нәтижені интерфейске немесе webhook арқылы қайтару

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