Агенттерді делегирлеу құны неге соншалық тез өседі?

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

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

Түбірлік сұрау бүкіл жұмыстан өтуі керек

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

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

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

Ішкі командаға арналған ең қарапайым конверт мынадай болуы мүмкін:

{
  "root_request_id": "rr_01JX8A7QK6B2",
  "traceparent": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01",
  "parent_work_id": "work_8c19",
  "delegation_depth": 2,
  "delegation_reason": "verify_sources",
  "budget_remaining_usd": "0.1840"
}

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

W3C Trace Context спецификациясы сервистер шекарасы арқылы трассировка контекстін тасымалдауды сипаттайды. OpenTelemetry құжаттамасы асинхронды хабарламалармен жұмыс істегенде өңдеудің жеке бірліктері жіберушімен байланысу мүмкіндігін сақтауы керек екенін бөлек атап өтеді. Агент шығынын есепке алуда бұл академиялық ұсақ-түйек емес: сақталған контекст болмаса, қымбат ұрпақ шақыруын жетім оқиға ретінде көресіз.

Түбір бағасы ата-ана спандарының емес, ұрпақтардың шығындарынан құралады

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

Екі түрлі өрісті сақтаңыз:

• cost_direct: дәл осы операцияның шығыны;
• cost_subtree: cost_direct және барлық ұрпақтардың шығындары;
• cost_root_total: ағаш аяқталғаннан кейін түбірге жазылатын қорытынды сома;
• cost_attributed: бір операцияны бірнеше түбір бөліскендегі шығын үлесі.

Іс жүзінде шатасу cost атауынан басталады. Инженер координатор спанына ішкі ағаштың сомасын жазады, аналитик сақтау қоймасындағы барлық жолдарды қосады, ал қаржы тобы провайдер шотынан екі-үш есе жоғары есеп алады. Бұл SQL қатесі емес. Бұл деректер моделінің қатесі.

Қалыпты ағаш үшін формула қарапайым:

cost_subtree(node) = cost_direct(node) + Σ cost_subtree(child)
cost_root_total(root) = cost_subtree(root)

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

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

Бір логикалық шақыру бірнеше физикалық әрекеттен тұруы мүмкін

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

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

Логикалық llm.generate операциясының ата-ана спанын жасаңыз, ал әр нақты жіберу үшін llm.attempt ұрпақ спанын құрыңыз. Әрекетте модельді, провайдерді, маршрутты, токендерді, тікелей құнды және аяқталу себебін белгілеңіз. Логикалық операцияда әрекеттер санын және оның қорытынды мәртебесін сақтаңыз.

{
  "span_name": "llm.attempt",
  "root_request_id": "rr_01JX8A7QK6B2",
  "logical_operation_id": "lop_4821",
  "attempt_number": 2,
  "attempt_reason": "retry_after_timeout",
  "model": "model-x",
  "provider": "provider-a",
  "input_tokens": 18420,
  "output_tokens": 912,
  "cached_input_tokens": 0,
  "cost_direct_usd": "0.071436",
  "status": "ok"
}

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

Тағы бір жағымсыз жағдай бар: провайдер генерацияны бастағаннан кейін қате қайтарды. Провайдер жұмыстың бір бөлігін есепке алса да, жүйеңіз usage деректерін алмауы мүмкін. Мұндай әрекетті нөл ретінде емес, cost_status=unknown деп белгілеңіз. Кейін оны биллинг деректерімен және провайдер ережелерімен салыстырыңыз. Есептегі нөл тыныштандыратын сияқты көрінеді, бірақ шығын болжамын бұзады.

Делегирлеу тереңдігі құрылымды түсіндіреді, бірақ себепті дәлелдемейді

Тереңдік дегеніміз түбірлік тапсырмадан ағымдағы жұмысқа дейінгі ауысулар саны. Түбір агенттің тереңдігі 0, оның подагентінікі 1, ал ол шақырған тексеруші агенттікі 2. Оны спандар атауларынан кейін қалпына келтірмей, жұмыс жасалған кезде есептеңіз.

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

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

Жиі кездесетін мысал. Координатор агент «үш провайдердің шарттарын салыстыр» деген сұрау алады. Ол үш зерттеушіні параллель шақырады. Әр зерттеуші бастапқы сұрауды, диалог тарихын және барлық провайдерлер тізімін тексеруші подагентке береді. Содан кейін тексеруші агент іздеу мен құжат талдауын шақырады. Құн тереңдік 2 болғандықтан өспейді. Ол үш тармақтың бірдей 20 мың кіріс токенін тасып, ортақ жұмысты қайталауынан өседі.

Әр делегирлеу карточкасында себепті сақтаңыз. Шектеулі мәндер жиыны бар delegation_reason еркін мәтіннен пайдалырақ: retrieve, verify, transform, review, execute_tool, fallback_model. Команда бұл өріске кез келген сөйлемді жазса, бір айдан кейін мыңдаған ұқсас мән пайда болып, қалыпты топтастыру мүмкін болмайды.

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

Есеп моделі модельді, құралды және оркестрацияны ажыратуы керек

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

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

Шығын жазбасында есептеу түрі болғаны дұрыс:

{
  "charge_type": "llm_tokens",
  "unit": "token",
  "quantity_input": 18420,
  "quantity_output": 912,
  "unit_price_version": "provider-a-2026-06",
  "currency": "USD",
  "amount": "0.071436",
  "pricing_source": "rate_card",
  "cost_status": "estimated"
}

Құрал үшін осы схема charge_type=search_request немесе charge_type=compute_second мәндерін қолдануы мүмкін. Барлығын токенге сыйғызуға тырыспаңыз. Іздеу сұрауы оны агент шақырғаны үшін токенге айналмайды.

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

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

Қымбат түбірді орташа чекпен емес, үлесімен іздейді

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

Трассалар қоймасына жіберілетін жұмыс сұрауы қымбат тапсырмалардың үздік тізімін ғана емес, олардың құрамын да қайтаруы керек:

SELECT
  root_request_id,
  route_version,
  root_type,
  max(delegation_depth) AS max_depth,
  count(*) FILTER (WHERE operation_kind = 'llm_attempt') AS llm_attempts,
  sum(cost_direct_usd) AS root_cost_usd,
  sum(input_tokens) AS input_tokens,
  sum(output_tokens) AS output_tokens
FROM agent_cost_events
WHERE finished_at >= :start
  AND finished_at < :end
GROUP BY root_request_id, route_version, root_type
ORDER BY root_cost_usd DESC
LIMIT 50;

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

1. Қай тармақ ең жоғары тікелей шығын берді?
2. Қай қадам қайталанды және қайталау себебі орынды болды ма?
3. Кіріс контекст қай жерде өсті: делегирлеуге дейін, құралдан кейін немесе соңғы жауапты жинағанда?
4. Параллель тармақтар бір-бірінен тәуелсіз болды ма, әлде бір нәрсені іздеп, бір нәрсені талдады ма?

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

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

Контекст көбіне модель таңдаудан гөрі шотты қатты өсіреді

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

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

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

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

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

Бюджет жаңа шығын пайда болмай тұрып тармақты тоқтатуы керек

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

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

available = root_budget
            - root_cost_committed
            - root_cost_reserved

if estimated_next_cost > available:
    return partial_result_or_escalate()

root_cost_committed аяқталған әрекеттерді қамтиды. root_cost_reserved үш қызметкер бір мезетте ақша әлі жеткілікті деп ойлайтын параллель жарыстан қорғайды. Резерв шақыру жіберілмей тұрып жасалады және usage алынғаннан кейін босатылады немесе нақтыланады.

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

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

Сақтау ережелері жоқ трассировка тез арада жаңа мәселеге айналады

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

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

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

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

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

Есепті инвойспен және пайдаланушы нәтижесімен салыстыру керек

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

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

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

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