Визначення ціни для механізму прийняття рішень на основі введеного тексту під час викликів Frontier LLM
Як моделювати очікувану вартість керування трафіком LLM за допомогою типової моделі прийняття рішень, такої як Jev, встановлювати пороги впевненості та перевіряти якість маршрутизації перед її впровадженням.
Джерела: Jev Is 100× Cheaper Than Claude — But Its Real Advantage Isn’t Price
Велика частина трафіку LLM у продакшені не потребує повернення детального відповіді. Вибір маршруту, позначення категорії політики чи вирішення питання про те, чи заслуговує запит на глибокі міркування, є обмеженими задачами, проте багато систем вирішують їх, звертаючись до моделі для декодування тексту. Цей посібник показує, як вирішити, чи слід розмістити шар прийняття рішень на основі введених даних, такий як Jev від TypeSafe, перед цими викликами, як створити для нього чесну модель очікуваної вартості та як перевірити маршрутизатор, щоб дешевший шлях не став ненароком гіршим.
Цікаве порівняння ніколи не є „дешева модель проти дорогої моделі“ окремо. Це один повний шлях обробки запиту проти іншого, обидва які мають дотримуватися одних і тих самих стандартів якості. Якщо ви хочете дізнатися більше про те, що таке Jev та як працюють його базові елементи, перегляньте наш огляд Jev як моделі без чатування для прийняття типових рішень; тут акцент робиться на економічних аспектах та інженерних рішеннях, пов’язаних з нею.
Коли для генерації тексту неправильний проміжний формат
У дизайні з однією моделлю кожен запит надсилається до основної моделі, від якої очікується визначення того, що слід зробити, зазвичай шляхом повернення структурованої відповіді. Ця модель читає вхідні дані, декодує токени вихідних даних по одному та повертає щось, з чим може працювати додаток. Такий підхід є гнучким, але витрачає ресурси на декодування там, де насправді йдеться про запитання з кількома варіантами відповідей.
API зі структурованим вихідним даними роблять ситуацію набагато безпечнішою: вони усувають більшість некоректних форматів JSON та порушень схеми. Твердження Джева є іншим та більш архітектурним – його природним вихідним результатом є обмежене рішення, а не вільний текст, примушено вписаний у схему через обмежене декодування.
Дизайн із контрольним етапом додає крок прийняття рішення перед виконанням будь-яких ресурсоємних операцій:
- Перевірити, чи справді запит потребує складних міркувань.
- Отримати ймовірність або варіант вибору з фіксованого набору.
Саме тут модель на кшталт Jev може знайти своє місце. У документації продукту TypeSafe йдеться про те, що вона створена для програмних рішень, а не для генерації тексту. Пам’ятайте, що цей інструмент не є безкоштовним: він має власну затримку, витрати, залежності та можливості виникнення помилок, навіть коли допомагає уникнути зайвих викликів.
Маршрутизатор, який є дешевим за один виклик, стає дуже дорогим у момент, коли він впевнено надсилає запити у неправильне місце.
Почніть з обсягу роботи, а не з цінової таблиці
Ціни за токен є вхідними даними для моделі оцінки витрат; вони самі по собі не є моделлю. Насправді вам потрібно аналізувати розподіл вашого трафіку.
Для кожної категорії запитів необхідно враховувати принаймні наступне:
- токени вхідних даних, які надсилаються до роутера та будь-якої генеративної моделі;
- токени вихідних даних, які, на вашу думку, має створити генеративна модель;
- частка трафіку, яка проходить кожним маршрутом;
- частка, яка переходить на резервний варіант, повторює спроби або потрапляє на перевірку людиною;
- знижки за кешовані вхідні дані, але лише ті, що справді стосуються ваших запитів;
- порог якості, який має дотримуватися система; та
- скільки коштує помилка маршрутизації, окрім рахунку від API.
За допомогою цих показників очікувану вартість одного запиту можна записати так:
E[cost] = C_router + P_frontier × C_frontier + P_fallback × C_fallback + C_ops (операції та перевірка людиною)
А кожен виклик, що вимірюється за кількістю токенів, розбивається на:
C_call = (tokens_in × rate_in + tokens_out × rate_out) ÷ 1,000,000, причому ставки вказані за мільйон токенів
Одна деталь бухгалтерського обліку має важливіше значення, ніж здається. Якщо просто додати ці показники, кожна ймовірність має бути безумовною, тобто становити частку від усього обсягу трафіку. Якщо ваш показник відхилень вимірюється лише серед запитів, які пройшли певний шлях, потрібно помножити його на ймовірність обрання саме цього шляху. Поєднання цих двох підходів — це простий спосіб подвоїти підрахунок одних і тих самих відхилень.
Також варто точно визначити цільову метрику. Мінімізація витрат на кожен спробований запит не є метою. Ви прагнете до найнижчих загальних витрат на кожен прийнятий результат, з урахуванням чітких вимог до якості. Система, яка є дешевою за один виклик, але призводить до більшої кількості відхилення чи необхідності переробки, може програти за цим показником.
Як виглядає межа негенеративного результату
Архітектуру легше зрозуміти, як тільки ви точно визначите, що повертає роутер. TypeSafe описує три типи запитань:
- Noul повертає ймовірність у діапазоні від 0 до 1 того, що дане твердження є істинним.
- Choice обирає один варіант із обмеженого набору та вказує ймовірності та значення впевненості.
- Score оцінює вхідні дані за певною шкалою, також з вказанням ймовірностей та рівня впевненості.
Точні поля відповідей та рекомендоване їх використання наведені у документації до примітивів. TypeSafe приписує калібрування ймовірностей моделі методу навчання під назвою RLCD — «Ринформоване навчання для каліброваних рішень».
Розглядайте цю калібрування як гіпотезу, яку потрібно перевірити на ваших даних. У власній документації System One виробника чітко зазначено, що калібрування — це характеристика, яка вимірюється на основі багатьох прогнозів; там нічого не сказано про те, чи є правильною будь-яка окрема відповідь. Модель може бути добре калібрувана в середньому, але все одно помилятися щодо конкретного запиту, який у вас є.
Це є ширшим уроком про безпеку типів у системах ШІ: вона виключає лише одну категорію помилок, а не всі. Вихідний результат може ідеально відповідати своєму оголошеному типу, проте все одно містити неправильне рішення.
Корисним кроком є визначення власного типу результату, нейтрального щодо постачальника, на межі додатку, щоб решта коду ніколи не залежала від формату відповіді конкретного постачальника. Наведений нижче скетч — це дискримінована унія з чотирма результатами: прийнятий маршрут із показником довіри, запасний варіант для завдань із низькою довірою або непідтримуваних типів, чіткий статус перевірки для ситуацій із високим рівнем неоднозначності та технічна помилка. Зверніть увагу, що «перевірка» та «запасний варіант» — це окремі випадки; вони зазвичай призводять до дуже різних наслідків та відповідальних осіб.
DecisionResult =
| { kind: "accepted"; route: KnownRoute; confidence: Score }
| { kind: "fallback"; reason: LowConfidence | UnsupportedTask }
| { kind: "review"; reason: HighImpactAmbiguity }
| { kind: "error"; reason: TechnicalFailure }
Усе, що несе справжню відповідальність, все ще знаходиться у вашому коді: схема, порогові значення, перевірки авторизації, запасні варіанти, можливості моніторингу та обробка наслідків некоректного маршруту. Типований роутер забезпечує цим елементам більш чіткий вхідний формат даних. Він не вирішує за вас політику обробки даних.
Паралельна оцінка проти декодування токен за токеном
Генеративні моделі створюють результати послідовно. Незалежно від того, наскільки оптимізована система обробки запитів, додаток отримує потік токенів, а його довжина впливає як на час завершення роботи, так і на вартість обробки даних.
TypeSafe стверджує, що Jev використовує паралельний семплер, який бере до уваги характеристики обладнання та може відповісти на кілька структурованих запитань у одному паралельному запиті. Згідно з оголошенням TypeSafe про цю модель, повний цикл обробки займає від 70 до 500 мілісекунд, причому швидкість обробки подібних запитів зростає в 40–200 разів. Ці цифри надані виробником; їх не підтверджували незалежно.
Розгляньмо ситуацію, коли потрібно перевірити матеріал на відповідність десяти категоріям правил. Два способи виконання цієї задачі відрізняються наступним чином:
- Паралельний шлях прийняття рішень: ви надсилаєте спільний контекст разом із десятьма обмеженими запитаннями та отримуєте десять введених значень, кожне з яких супроводжується інформацією про ймовірність.
- Генеративний шлях: ви надсилаєте контекст та чекаєте, поки серіалізована відповідь буде декодована токен за токеном; у результаті отримується структурований вихід, який все ще потребує семантичної перевірки.
Паралельний шлях ніколи не чекає на пояснення чи серіалізований текст, що робить можливими переваги у часі виконання та формуванні рахунку для обмежених оцінок. Однак це нічого не свідчить про однакову точність, глибину міркувань чи надійність. Форма виконання та якість завдання — це дві різні речі, і кожна з них потребує окремого вимірювання.
Проектування політики маршрутизації: пороги та альтернативи
Шар маршрутизації — це більше, ніж просто один виклик моделі, обгорнутий у if. Йому потрібна чітка політика роботи, яка охоплює кожен можливий результат.
У наведеному нижче псевдокоді від моделі прийняття рішень зазначеного типу просить обрати один із трьох варіантів: локальний робочий процес, модель „фронтиру“ чи людський огляд. У разі технічної несправності використовується безпечний запасний варіант; якщо рівень впевненості нижчий за заданий поріг, справа передається на людський огляд або до моделі „фронтиру“; лише рішення з високим рівнем впевненості використовується без змін. Кожне рішення перед відправкою фіксується разом із ідентифікатором запиту, маршрутом, рівнем впевненості, версією моделі та часом виконання. Цей підхід свідомо залишається універсальним та не претендує на те, що є Jev SDK.
decision = typed_decision_model.evaluate(
context=request,
schema=Choice(["local_workflow", "frontier_model", "human_review"])
)
if decision.failed:
route = safe_technical_fallback
elif decision.confidence < REVIEW_THRESHOLD:
route = human_review_or_frontier_fallback
else:
route = decision.value
log(request_id, route, decision.confidence, model_version, latency_ms)
dispatch(route, request)
Три інваріанти забезпечують безпеку роботи:
- Кожен можливий результат відповідає типу, який вже відомий додатку.
- Кожен стан з низьким рівнем впевненості чи неуспішний результат має визначений напрямок обробки.
Третій пункт — це той, який команди найчастіше ігнорують. Без поєднання рішень з результатами неможливо визначити, чи економить маршрутизатор гроші, чи тихо погіршує якість.
Вибір порогового значення
Порогове значення визначає вашу позицію на кривій компромісу між якістю та витратами. Консервативне порогове значення направляє більше трафіку до дорогого альтернативного рішення, що зменшує економію. Агресивне порогове значення автоматизує більше рішень, підвищуючи ризик виникнення „хибно простих“ помилок, коли запит класифікується як звичайний, хоча потребує більш глибокого аналізу.
Це робить вибір порогу проблемою оцінки, а не чимось, що потрібно налаштовувати інтуїтивно. Виберіть його на основі позначених результатів для вашої власної роботи, враховуючи те, що два типи помилок рідко мають однакову вартість. Для рішень із серйозними наслідками варіант людського перегляду може бути правильною відповіддю, навіть якщо це найдорожчий етап у моделі.
Нормалізація порівняння витрат
Ціни, наведені у цьому порівнянні, були перевірені на власних сторінках постачальників 17 вересня 2026 року, і вони можуть змінюватися. Розглядайте кожну цифру тут як моментальний знімок та підтверджуйте її на сторінці моделі OpenAI, сторінці Opus від Anthropic та на сторінці ціноутворення API Gemini від Google перед тим, як покладатися на неї.
Кілька факторів суттєво змінюють ці числа:
- Стандартні тарифи GPT-6 Astra діють лише до 272 тис. токенів вхідного тексту; довші запити оплачуються за вищими тарифами.
Навіть з урахуванням цих застережень таблиця цін є вражаючою та водночас оманливою. Jev та генеративні моделі пропонують різні продукти. У Jev фактично немає ціни на вихідний результат, оскільки його задокументовані межі не включають генерований текст. Моделі типу Frontier створюють пояснення, резюме, код та можливості відкритого міркування, яких Jev не пропонує.
Якщо враховувати лише ціну на вхідні дані, опублікована ставка Jev є приблизно у 119 разів нижчою за стандартну початкову ставку для Claude Opus 5. Тому вираз «приблизно у 100 разів дешевше» є адекватним скороченням для позначення ціни на вхідні дані. Це не означає, що Jev може виконати роботу Claude за один відсоток від загальної вартості.
Приклад із розрахунками, навмисно неповний
Візьмемо 10 000 запитів. Кожен з них надсилає 800 токенів до маршрутизатора. Тридцять відсотків запитів направляються до моделі Frontier – при цьому на кожен такий запит йде 1 200 токенів вхідних даних та 500 токенів результату. Крім того, безумовно 5% усіх запитів викликають додатковий запит як резервний варіант. Ігноруймо питання кешування, оплати праці, повторних спроб та витрат на якість.
Якщо підставити це у формули, стаття витрат від маршрутизатора є незначною, тоді як витрати на обробку запитів типу „фронтир“ становлять основну частину рахунку. Це є очікуваним результатом, і саме тому цей приклад нічого не доводить щодо економії. У ньому немає базової моделі з виміряною якістю, немає даних про розподіл маршрутів у реальному трафіку, а також немає оцінки витрат, пов’язаних із помилками маршрутизації.
Суттєве питання полягає не у тому, чи є ціна одного токена від маршрутизатора нижчою, ніж у моделі типу „фронтир“; очевидно, що так. Питання в тому, чи дозволяє ухвалення рішень на початковому етапі процесу уникнути достатньої кількості зайвих операцій, щоб це мало значення, не порушуючи при цьому порогу якості. Щоб дізнатися більше про те, де насправді накопичуються витрати LLM, перегляньте нашу модель витрат, засновану на архітектурі, для агентних ШІ.
Перевірка якості маршрутизації та загальних витрат
На момент написання цього тексту наявні публічні дані підтверджують документований інтерфейс Jev, його механізм, рекомендовану ціну та повідомлену TypeSafe затримку обробки. Однак поки що немає незалежних, масштабних доказів якості калібрування, надійності роботи чи стабільності цін. TypeSafe також публікує власні оцінки робочих процесів та рекомендації щодо рівня впевненості та порогових значень, які є корисними відправною точкою, але залишаються даними першої сторони.
Рання практична оцінка, опублікована Every, вказала на обнадійливу швидкість та вартість, проте чітко залишила загальну якість виконання завдань нерозв’язаною проблемою. Розглядайте її як ранній сигнал, а не як стандарт для продакшну.
Практичний цикл перевірки виглядає так:
- Візьміть частину справжнього трафіку з позначками.
- Пропустіть її через поточну систему обробки та через потенційну систему обробки з маршрутизацією.
Останній крок має велике значення, адже одне число точності може приховати найбільш серйозну проблему: складний запит було відхилено, не проаналізувавши шлях обробки, який був необхідний.
Дизайн з маршрутизацією є кращим лише тоді, коли він зберігає необхідну якість та водночас покращує те, що ви насправді оптимізуєте – чи то вартість, затримка, пропускна здатність чи їхня комбінація. Якщо він знижує витрати на токени, але збільшує кількість спроб чи необхідність ручного перегляду, витрати просто зміщуються, а не зникають.
Коли одна модель типу frontier все ще є кращим варіантом
Шар маршрутизації додає залежності, механізми формування політик та нові способи виникнення помилок. Надсилання всього до однієї моделі-фронтиру часто є кращим вибором у таких випадках:
- більшість запитів все одно потребують генерованого тексту;
- рішення не можна виразити у вигляді обмежених міток чи оцінок;
- неоднозначність вимагає відкритого міркування перед можливістю маршрутизації;
- обсяг трафіку занадто малий, щоб економія від маршрутизації компенсувала додану складність у роботі; або
- команда ще не може оцінювати та відстежувати помилки маршрутизації.
Типований маршрутизатор стає привабливим, коли рішення є повторюваними, обмеженими, вимірюваними та масовими, коли у додатку є безпечні альтернативи для кожного результату, та коли перевірений маршрутизатор значно зменшує обсяг подальшої генерації.
Ключові висновки
- Порівнюйте повні шляхи запитів у межах одного й того ж показника якості, а не ціни моделей окремо.
- Розраховуйте очікувану вартість моделі з урахуванням безумовних ймовірностей та оптимізуйте витрати за кожен прийнятий результат.
- Обгорніть будь-який маршрутизатор за своїм типом результату з чіткими параметрами резервного варіанту, перегляду та станів помилок.
- Вибирайте порогові значення на основі позначених даних та асиметричних витрат на помилки, а також фіксуйте кожне рішення, щоб його можна було поєднати з відповідним результатом.
- Розглядайте затримки постачальника, калібрування та твердження щодо цін як гіпотези; перевіряйте їх знову, коли змінюються ціни, обсяг трафіку чи витрати на помилки.
- Почніть з малого: оберіть один існуючий маршрут, запишіть його схему та порогове значення якості, а потім проведіть найменший експеримент, який міг би довести неправильність цього дизайну.