Әртүрлі провайдерлердегі токендерді бірізді есептеу, даусыз

Токендер бойынша дау қайдан шығады

Даулар сирек бір үлкен қателіктен туады. Әдетте мәселе есептегі ұсақ айырмашылықтардың жиналуынан шығады. Бір провайдер prompt_tokens пен completion_tokens деп жазады, екіншісі шығынды бірден кіріс, шығыс, кэш және қызметтік өрістерге бөледі, ал үшіншісі usage-ты тек стрим соңында немесе бөлек экспортта береді. Қаржы мен инженерлер бір сұрауларға қарайды, бірақ әртүрлі сандар көреді.

Тіпті бірдей промпт та бірдей есеп бермейді. Модельдерде токенизаторлар әртүрлі, жүйелік енгізулер мен JSON, tool calling және reasoning өңдеу ережелері де бөлек. Кейде провайдер өз қызметтік нұсқауларын қосады, ал команда оларды қолданба логынан көрмейді. Қағаз жүзінде сұрау біреу, ал токен саны әлдеқашан өсіп кеткен.

Көбіне мәселе төрт нәрсеге келіп тіреледі:

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

Кэште шатасу әсіресе жиі болады. Бір провайдерде кэштелген кіріс токендер бөлек өріспен келеді және арзанырақ тұрады. Екіншісінде олар жалпы input ішіне кіреді, ал жеңілдік тек шотта көрінеді. Үшіншісінде кэш бар, бірақ API жауабында ол анық байқалмайды. Сондықтан инженер: «біз 2 млн кіріс токен жібердік» дейді, ал қаржы маманы олардың бір бөлігі басқа тарифпен есептелгендей соманы көреді.

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

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

Бір жазбада нені есептеу керек

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

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

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

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

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

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

Әдетте мына өрістер жеткілікті:

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

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

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

Провайдер жауаптарын бір түрге қалай келтіруге болады

Әртүрлі LLM-провайдерлерде бірдей сандар әртүрлі атпен келеді. Біреуі input_tokens жазады, екіншісі prompt_tokens, үшіншісі тек жалпы соманы береді. Команда бәрін бір пішімге келтірмесе, биллинг тез арада терминдер туралы дауға айналады.

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

Ең қарапайым схема

Әдетте мына өрістер жеткілікті:

• request_id және attempt_id
• provider_id, model_id, tariff_version
• input_tokens, output_tokens, cache_read_tokens, cache_write_tokens
• service_tokens немесе қызметтік токендерге арналған бөлек өрістер
• is_stream, is_retry, is_fallback жалаушалары
• raw_response және normalized_at

Бұл схема проблемалардың жартысын алып тастайды. Қаржы барлық провайдер бойынша бірдей есептегіштерді көреді. Инженерлер бұл сандар қай жауаптан шыққанын көреді.

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

Нөл мен белгісіз мәнді араластырмаңыз. Егер провайдер 0 деп нақты қайтарса, 0 жазыңыз. Егер өрісті мүлде жібермесе, null қойып, себебін белгілеңіз. Әйтпесе есеп кэш немесе қызметтік токендер анық қолданылмағандай көрінеді, ал шын мәнінде провайдер оларды жай ғана ашпаған.

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

Stream, retry және fallback үшін қатаң тәртіп керек. Stream-де қорытындыны тек жауап аяқталғаннан кейін санаңыз. Retry үшін әр талпынысты бөлек сақтап, жалпы request_id арқылы байланыстырыңыз. Fallback үшін бастапқы маршрутты жазыңыз: қай модель жауап бермеді, сұрау қайсысына өтті және оның токендері шотқа қалай кірді.

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

Есепті қадамдап қалай енгізуге болады

Дашбордтан бастамаңыз, бір ортақ usage жазбасынан бастаңыз. Әр команданың өз өрістері мен атаулары болса, бірізді есеп болмайды. Алдымен ең аз жиынтықты келісіңіз: request_id, дата, провайдер, модель, input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, service_tokens, currency, unit_price, total_cost.

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

Бірінші аптада не істеу керек

1. Әр провайдер үшін өрістерді кестеде мапптаңыз, команданың басында емес. Мысалы, prompt_tokens-ті input_tokens-ке жіберіңіз, completion_tokens-ті output_tokens-ке, ал кэш пен қызметтік токендерді бөлек сақтаңыз.
2. Құнды әр сұрау деңгейінде есептеңіз. Күн соңын күтпеңіз және орташа бағаны жалпы көлемге көбейтпеңіз. Бір провайдердің өзінде баға модельге, токен түріне және кэш режиміне қарай өзгеше болуы мүмкін.
3. Жанында тек қорытынды соманы емес, есептеу формуласын да сақтаңыз. Сонда кез келген дау тез шешіледі: қай токендер шотқа кіргені және қандай тариф қолданылғаны көрініп тұрады.

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

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

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

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

Ақшаға қатысты қандай ережелерді бірден қабылдау керек

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

Бірінші ереже: бағаны сұрауға нақты жауап берген модель бойынша алыңыз. Алиас код үшін ыңғайлы, бірақ ақша үшін нашар бағдар. smart-default сияқты жазба қаржыға ештеңе айтпайды, егер шлюз осы сәтте трафикті нақты провайдердегі нақты модельге жіберсе. Оқиғада provider, model, тариф нұсқасы және сұрау уақыты болуы керек.

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

Кредиттер мен тегін квоталар бойынша бірінші инвойсқа дейін келісіп алыңыз. Оларды айлық жиынтықтан шегеруге болады. Оларды жеңілдік ретінде бөлек жолмен көрсетуге болады. Немесе квотаны алған команданың ішкі бюджетіне жатқызуға болады. Осылардың кез келгені жұмыс істейді. Жаман жері — түсіндіруді ай сайын өзгерту.

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

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

Ең аз ережелер мынандай көрінеді:

• бір сұрау немесе бір батч үшін бір есеп жазбасы
• әр жазбада нақты модель мен провайдер
• input, output, cache және қызметтік токендерге бөлек өрістер
• кредиттерге, квоталарға және дөңгелектеуге бір ереже
• ортаға арналған нақты белгі: test немесе prod

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

Командалар қай жерде жиі қателеседі

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

Егер команда сұрауларды бірнеше провайдер арқылы жіберсе, айырмашылық бірден көрінеді. Әсіресе бір жеткізуші cache read-ты бөлек жазса, екіншісі қызметтік токендерді input ішінде есептесе, ал үшіншісі usage-ты ретрайдан кейін ғана қайтарса.

Әдеттегі қателер былай көрінеді:

• кэштелген токендерді кәдімгі кіріспен қосып жібереді, сондықтан cache hit жеңілдігі жинақ кестесінде жоғалады
• timeout-тан кейінгі қайталама сұрауларды бөлек белгілемейді, сондықтан шығын екі есе үлкен сияқты көрінеді
• бағаны құжаттамадан алады, нақты шоттан емес
• usage-ты UTC бойынша салыстырады, ал қаржылық есепті жергілікті күнмен жасайды
• қызметтік токендерді пайдаланушы мәтінімен араластырады

Тәжірибеде бұл қарапайым көрінеді. Команда ай бойы 2 млн кіріс токен бар деп көреді де, бюджетті толық тарифпен есептейді. Кейін олардың 600 мыңы кэштен келгені және арзанырақ тұруы тиіс екені анықталады. Тағы 120 мыңы timeout-тен кейінгі қайталаулардан пайда болған. Ал шығынның бір бөлігі мүлде жауапқа зиян келтірмей қысқартуға болатын қызметтік қаптамаға тиесілі.

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

Қарапайым тексеріс кез келген даудан пайдалырақ: бір күнді алыңыз, барлық уақыт белгісін бір уақыт белдеуіне келтіріңіз, cache tokens, retries және қызметтік токендерді бөліңіз, содан кейін шоттағы нақты тарифпен соманы қайта есептеңіз. Әдетте содан кейін айырмашылық не жоғалады, не бірнеше минутта түсінікті болады.

Бір ай даусыз өткен мысал

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

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

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

Ай соңындағы бір қорытынды

Бұл суретте инженер, егер кіріс, кэшті кірістің бөлігі ретінде және шығысты қоссақ, 2 440 000 токен көреді. Қаржы 418 100 теңге көреді де, неге сома күткеннен жоғары деп сұрайды. Жауап бір жолда тұр: B провайдерінде 86 000 қызметтік токен бар, ал 570 000 кэш-токенді кәдімгі кіріс тарифімен есептеуге болмайды.

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

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

Ай жабар алдында тез тексерулер

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

Алдымен арифметиканы тексеріңіз. Күндер бойынша сұраулар сомасы айлық қорытындымен сәйкес келуі тиіс. Егер күндік сандар 3 842 190 токен болса, ал жиынтық есепте 3 861 000 тұрса, мәселе көбіне фильтрлерде, дубликаттарда немесе кеш жүктелген логтарда. База сәйкес келмей тұрып, тарифтен түсінік іздемеңіз.

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

Ретрайларды бөлек тексеріңіз. Сұраудың қайталанған жіберілімі жалпы есептегіштің ішінде жоғалып кетпеуі керек. Әйтпесе бір команда модель қымбаттап кетті деп ойлайды, ал екіншісі бұл тек timeout-тан болған қайталаулар саны артқанын біледі.

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

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

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

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

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

Raw деректерден бастаңыз. Барлық провайдерлердің usage-ын бір қоймаға сол күйінде жинаңыз, жолай «жақсартусыз». Алдымен жауапты қалай келсе, солай сақтаңыз, содан кейін ғана нормаланған жазба жасаңыз. Бұл жалықтыратын қадам, бірақ қаржы 12 430 000 токен неге есепте бір басқа сан болып тұр деп сұрағанда дәл осы құтқарады.

Ең аз жоспар мынадай:

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

Қаржы бөлімімен олардың қандай өрістерді есептің негізі деп санайтынын бөлек келісіңіз. Әдетте кезең, провайдер, модель, project немесе cost center, токен түрі, бірлік бағасы, валюта және жалпы сома жеткілікті. Егер бұл тізім болмаса, 2-3% ауытқу кезінде дау қайта басталады.

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

Провайдер көп болғанда, қолмен біріктіру тез жалықтырады. Мұндай жағдайда маршрутизация мен есепті AI Router арқылы airouter.kz-ке жинақтау ыңғайлы: бұл OpenAI-үйлесімді бір API-шлюз, онда үйреншікті SDK, код және промпттарды сақтап, кейін әр провайдер бойынша usage-ты орталықтандырылған түрде нормализациялауға болады. Қазақстан мен Орталық Азиядағы командалар үшін B2B-инвойстингтің ай сайын теңгемен жүруі де пайдалы.

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