AI-платформадағы көпарендтілік артық сервистерсіз

Неге ортақ қолжетімділік тәртіпті тез бұзады

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

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

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

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

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

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

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

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

Бірінші күннен не бөлу керек

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

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

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

Бастапқыда қарапайым жиын жеткілікті. Әр командаға және әр сервиске бөлек кілт беріңіз. Тек сұрау санына емес, токендер мен ақшаға да лимит қойыңыз. Логтарда tenant_id, project_id және орта, мысалы prod немесе test, сақталсын. Күндік және айлық шығын есебін жинаңыз. Рөлдерден минимумын ғана қалдырыңыз: команда иесі және платформа админі.

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

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

Рөлдерде де артық схема керек емес. Команда иесі өз командасының кілттерін шығарады, шығынды көреді және бюджет шегінде лимитті өзгертеді. Платформа админі ортақ ережелерді, модельдерді, маршруттарды және арендаторлар арасындағы қолжетімділікті басқарады.

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

Арендатор шекарасын қалай таңдау керек

Нашар шекара есепті бірден бұзады. Кілттер адамдар арасында жүре бастайды, тест сұраулар prod-қа түседі, ал модельдерге кеткен шот бәріне бірдей келеді.

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

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

Жұмыс схемасы әдетте былай көрінеді: команда — есеп пен қолжетімділіктің жоғарғы деңгейі, жоба — өнім немесе сценарий деңгейі, орта — prod, test және sandbox болып бөлу, қызметтік аккаунт — әр ботқа, пайплайнға немесе интеграцияға жеке сущность. Ортақ ережелерді тек қауіпсіздікке қатысты жерде қалдырыңыз.

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

prod, test және sandbox-ты да анық бөлу керек. Модель бірдей болса да, жұмыс режимдері бөлек. prod үшін қатаң лимиттер, толық аудит және тұрақты баптаулар керек. test-те шектеулерді жұмсағырақ ұстауға болады. sandbox-те адамдар жаңа промпттар мен маршруттарды боевой ортаға қауіп төндірмей сынайды.

Ортақ ережелерді тек қауіпсіздік пен талаптарға сәйкестік үшін қалдырған жөн. Мысалы, PII-ді бүркемелеу, аудит-логтар, AI-мазмұн белгілері және базалық rate limit-терді бүкіл платформа деңгейінде қоюға болады. Қалғанын командаларға берген дұрыс. Мұндай тәсіл әсіресе бір ортақ шлюз бар кезде ыңғайлы, ал қолжетімділік, логтар және шығын шекарасын бөлек ұстау қажет болғанда тиімді.

Схеманы қадамдап қалай енгізуге болады

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

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

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

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

Кейін логтарды қолмен талдамау үшін әр сұрауға команда мен жоба тегін қосыңыз. team=search және project=faq-bot сияқты қарапайым схема жарайды. Егер шлюз кілт бойынша rate limit пен аудитті қолдаса, қосымша сервистердің үлкен жиынтығынсыз-ақ жеткілікті бөлу аласыз.

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

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

Үш командаға арналған мысал

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

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

Мұндай банк үшін баптау қарапайым болуы мүмкін. Чат-ботқа жеке кілт, күндік лимит және алдын ала болжанатын модельдер жиыны беріледі. Оның міндеті — бүкіл күн бойы тұрақты жауап беру. Антифрод өз контурымен, кідіріс бойынша қатаң шекпен жұмыс істейді. Егер модель жауабы шектен асып кетсе, платформа сұрауды қысқартады немесе оны тек жылдам модельдерге жібереді. Контакт-центр бөлек тест арендаторында өмір сүріп, чат-бот пен антифродтың боевой жүктемесіне қауіп төндірмей жаңа модельдер мен промпттарды сынай алады.

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

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

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

Қолмен салыстырмай-ақ шығынды қалай есептеу керек

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

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

Қай нәрсені бөлек жол деп санау керек

Сәтті жауап, қате және ретрай бір үйіндіде тұрмауы керек. Әйтпесе бір сәтсіз сұрау сериясы есепті ісіндіріп жібереді.

Жұмыс ережесі әдетте мынау: сәтті сұрау usage пен cost-қа түседі, модель жауабы жоқ қате тек technical log-та сақталады, ал ретрай өз request_id алады және бастапқы шақыруға байланысады, ал есептен тек провайдер шынымен ақша алған оқиға шығарылады.

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

Есепті қалай көрсету керек

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

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

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

Қандай логтар шын мәнінде керек

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

Жақсы журнал үш қарапайым сұраққа жауап береді: не жіберілді, кім жіберді және оның уақыты мен токені бойынша қаншаға түсті. Ол үшін әр жазбаға request_id, model, tenant_id және project_id қосу керек. Осысының өзі бір модель шақыруын нақты командамен, өніммен және инцидентпен байланыстыруға жеткілікті.

Әр жазбада не болуы керек

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

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

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

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

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

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

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

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

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

Қарапайым тегтердің жоқтығы да аз проблема емес. Егер сұраулар орта мен жоба бойынша белгіленбесе, dev пен prod тез арада бір үйіндіге айналады. Содан кейін тест трафигі боевой есептерге түседі, ал пилоттың шығыны продакшеннің шығыны сияқты көрінеді. Әдетте базалық жиын жеткілікті: tenant, team, project, environment, cost_center.

Тағы бір типтік қате — тек сәтті модель жауаптарын есептеу. Көрініс жинақы болып көрінеді, бірақ жалған болады. Шығын мен жүктемеде бәрі көрінуі керек: қателер, таймауттар, тоқтатылған сұраулар, rate limit іске қосылуы, қауіпсіздік саясаты бойынша бас тартулар. Әйтпесе команда дашбордта бір цифрды көреді де, инвойста басқа цифр алады.

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

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

Іске қоспай тұрып қысқа тексеріс

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

Әр команданың иесі болуы керек. Чаттағы топ емес, қолжетімділікті, лимиттерді және жаңа сервистерді растайтын нақты адам. Әр сервиске өз API-кілт қажет. Егер mobile backend, batch-job және ішкі бот бір кілтпен жұмыс істесе, сол күні-ақ бақылауды жоғалтасыз.

Әр кілт өз лимитіне тірелуі керек, prod, staging және dev үшін бөлек. Әйтпесе тест стенді продакшен бюджетін оңай жеп қояды. Логтарда кемінде үш тег болуы тиіс: команда, жоба және орта. Онсыз сіз тек сұрау ағынын көресіз, бірақ оның кімге тиесілі екенін түсінбейсіз.

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

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

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

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

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

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

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

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

Жеке өсімге орын қалдыруды да ұмытпаңыз. Жаңа командалар әдетте күткеннен бұрын пайда болады. Жаңа модельдер де солай. Сондықтан арендаторды бір провайдерге, бір модельге немесе бір биллинг тәсіліне байламаңыз. Арендатор қазіргі стекке төтеп бере алуы керек.

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

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