Друг на роботі поставив мені цілком незначне запитання, і я доручив агенту проаналізувати мої останні чати та документи. Він знайшов правильну відповідь, але це обійшлося мені у $38!!!. Це був поганий ROI (повернення інвестицій). Звісно, мій час цінний, але я б не витратив його на це завдання, і воно не потребувало дорогих можливостей планування.
Ми можемо зробити краще.
Google Cloud пропонує платформу Gemini Enterprise Agent Platform з Model Garden — зручним API-доступом до багатьох топових моделей, включаючи моделі від Google, Anthropic та навіть xAI. Насправді будь-яку модель з Huggingface можна розгорнути самостійно, але в цій статті ми зосередимося на новій Claude Fable 5.1 від Anthropic та новій Gemini 3.8 Flash від Google. Тепер у розробників є дві різні за структурою передові моделі, доступні через той самий корпоративний API.
Fable 5.1 пропонує автономне планування класу Mythos, контекстне вікно на 1 мільйон токенів та глибоке багатоетапне опрацювання. Gemini 3.8 Flash забезпечує майже передові міркування та неймовірну швидкість генерації токенів за цінами Flash ($0.75 за мільйон вхідних токенів, $3.75 за мільйон вихідних) з налаштовуваними параметрами «думок».
Можливо, спокусливо обрати одну модель і спрямовувати через неї все. Але це помилка.
Якщо ви проганяєте рутинні задачі розробника через глибокий планувальник, ви платите передові тарифи за токени просто для аналізу git diff. Якщо ж ви змусите швидку модель виконати незворотну міграцію бази даних без формального плану, вона діятиме навмання й зіпсує стан системи, перш ніж ви доп’єте каву.
Ми можемо значно покращити «токеноміку» дуже простим способом: використовуючи дві моделі та маршрутизуючи задачі між ними.
Автор: Алан Блант (@zeroasterisk
Ось повний посібник, який допоможе вам досягти цього:
- Налаштуйте обидві моделі в межах єдиної системи управління.
- Проведіть бенчмаркінг рутинних задач перед вибором моделі за замовчуванням.
- Використовуйте швидку модель як координатора першої лінії, а глибокий планувальник — коли потрібна додаткова потужність або коли швидка модель потребує ескалації.
- Сформуйте ментальну модель щодо ROI задач та цінності (а не лише вартості) ваших токенів.
1. Налаштуйте обидві моделі в межах єдиної системи управління
Вибір платформи для LLM-інференсу потребує врахування багатьох аспектів: вартість, потужність, безпека, вибір моделі, функціональність сервісу, складність для розробника, додаткові рівні безпеки (API-ключі несуть ризики). Платформа Gemini Enterprise Agent Platform (раніше Vertex AI) — комплексне рішення з унікальними можливостями. Оскільки вона надає доступ до моделей Gemini та Anthropic як керованих API, одна безпечна автентифікація покриває обидва навантаження.
Але будемо чесні: деякі процеси мають більше тертя, ніж мені б хотілося. Я жартую, що «неможливі речі робити легко, а легкі — важко». Саме тому я пишу цей пост.
Перш ніж працювати з моделями, увійдіть у gcloud, прочитайте документацію щодо варіацій.
1gcloud auth application-default login
Щоб отримати доступ до Claude Fable 5.1, потрібно увімкнути API, а потім активувати Claude Fable 5.1 та заповнити коротку форму про ваш кейс використання. Але це ще не все.
Тепер Fable підпадає під Додаток щодо безпеки просунутого ШІ (Advanced AI Safety Addendum) від Google Cloud. Перш ніж надіслати хоча б один запит до aiplatform.googleapis.com, ви повинні явно налаштувати спільне використання запитів-відповідей та прийняти умови видавця на рівні проєкту.
Ось точні інструкції для глобальної точки доступу; прочитайте документацію щодо варіацій.
Спочатку налаштуємо кілька змінних, які нам допоможуть. Зверніть увагу, що ім’я моделі в шляху URL — claude-fable-5-1 (через дефіси, а не крапки), переконайтеся, що ввели свій ID проєкту та локацію, і, можливо, змініть точку доступу залежно від регіону:
1export PROJECT_ID="YOUR_PROJECT_ID"2export LOCATION="global"3export MODEL="claude-fable-5-1"45# Глобальна точка доступу: aiplatform.googleapis.com (рекомендовано)6# Мультирегіональні точки доступу: aiplatform.eu.rep.googleapis.com7# Регіональні точки доступу: us-central1-aiplatform.googleapis.com8export ENDPOINT="https://aiplatform.googleapis.com"
Наступним кроком викличте API setPublisherModelConfig, встановивши dataSharingEnabledProvider у значення ANTHROPIC (зверніть увагу, що це великими літерами):
1curl -X POST \2 -H "Authorization: Bearer $(gcloud auth print-access-token)" \3 -H "Content-Type: application/json; charset=utf-8" \4 -d '{ "publisherModelConfig": { "dataSharingEnabledProvider": "ANTHROPIC" } }' \5"${ENDPOINT}/v1beta1/projects/${PROJECT_ID}/locations/${LOCATION}/publishers/anthropic/models/${MODEL}:setPublisherModelConfig"
Початковий виклик повертає об’єкт завершеної операції, що підтверджує активацію спільного використання даних:
1{2 "name": "projects/YOUR_PROJECT_NUMBER/locations/global/operations/1234567",3 "metadata": {4 "@type": "type.googleapis.com/google.cloud.aiplatform.v1beta1.SetPublisherModelConfigOperationMetadata",5 "genericMetadata": {6 "createTime": "...",7 "updateTime": "..."8 }9 },10 "done": true,11 "response": {12 "@type": "type.googleapis.com/google.cloud.aiplatform.v1beta1.PublisherModelConfig",13 "loggingConfig": {},14 "dataSharingEnabledProvider": "ANTHROPIC"15 }16}
Якщо ви вже зробили це раніше, отримаєте помилку HTTP 409 про те, що таке налаштування вже існує:
1409 ALREADY_EXISTS: The same PublisherModelConfig already exists.
Ця помилка 409 взагалі не є проблемою.
Протестуйте доступ до моделі, і ви маєте отримати відповідь:
1curl -X POST \2 -H "Authorization: Bearer $(gcloud auth print-access-token)" \3 -H "Content-Type: application/json; charset=utf-8" \4 -d '{"anthropic_version": "vertex-2023-10-16","messages": [{"role": "user", "content": "Hello world."}], "max_tokens": 1024, "stream": true}' \5"${ENDPOINT}/v1beta1/projects/${PROJECT_ID}/locations/${LOCATION}/publishers/anthropic/models/${MODEL}:streamRawPredict"
Якщо ви не виконали попередні кроки правильно, отримаєте помилку HTTP 403 такого вигляду:
1403 PERMISSION_DENIED: Access to this model requires data sharing to be enabled for publisher 'anthropic'. Please set `PublisherModelConfig.data_sharing_enabled_provider`2to 'anthropic' via the setPublisherModelConfig API to use this model.
Щоб отримати доступ до Gemini 3.8 Flash, переконайтеся, що бачите її як увімкнену картку моделі, і все має працювати автоматично:
1curl -X POST \2 -H "Authorization: Bearer $(gcloud auth print-access-token)" \3 -H "Content-Type: application/json; charset=utf-8" \4 -d '{"contents": [{"role": "user", "parts": [{"text": "Hello world"}]}],"generationConfig": {"thinkingConfig": {"thinkingLevel": "LOW"}}}' \5"${ENDPOINT}/v1beta1/projects/${PROJECT_ID}/locations/${LOCATION}/publishers/google/models/gemini-3.8-flash:streamGenerateContent"
… Фух. Ми впоралися 🎉!
Потрібно більше квоти? Ви можете керувати квотами для будь-якої моделі та оплачувати забезпечену пропускну здатність для деяких моделей.
2. Не довіряйте бенчмаркам, проводьте власні тести
Якщо запитати п’ятьох інженерів, яку модель використовувати для агента, ви почуєте більше п’яти суперечливих думок, заснованих на настроїях у Twitter та синтетичних рейтингах.
Публічні бенчмарки — чудовий ресурс, але вони тестують ізольовані запити або задачі в вакуумі. Виробничі сценарії чи ваші локальні агентні SDLC-інструменти ніколи не відповідають публічним бенчмаркам ідеально. Ваша робота сьогодні відрізняється від будь-якого бенчмарку.
Тому ви можете створити власні бенчмарки (Agent Ops та Evals FTW!) та автоматизувати це у масштабі, або ж просто порівняти виконання своїх простих задач пліч-о-пліч. Поки ви не змінюєте файли у своєму завданні, усе буде гаразд, і майже без зусиль ви отримаєте відчуття щодо ефективності.
Ось приклад використання promptfoo для того, щоб opencode виконав одні й ті самі 2 задачі з кожною моделлю. Вам потрібно буде змінити опис задачі та налаштувати середовище, але це не має бути занадто складно.
GIF
1# opencode.json2{3 "$schema": "https://opencode.ai/config.json",4 "provider": {5 "google-vertex": {6 "options": { "project": "alanblount-demo", "location": "global" },7 "models": {8 "gemini-3.8-flash": { "id": "gemini-3.8-flash", "name": "Gemini 3.8 Flash" }9 }10 },11 "google-vertex-anthropic": {12 "options": { "project": "alanblount-demo", "location": "global" },13 "models": {14 "claude-fable-5-1": { "id": "claude-fable-5-1", "name": "Claude Fable 5.1" }15 }16 }17 },18...
Налаштуйте Promptfoo для порівняння агентних виконань задач в opencode, а не лише одиночних запитів та моделей.
1# promptfooconfig.yaml2description: "Бенчмаркінг OpenCode Agent Harness: Gemini 3.8 Flash проти Claude Fable 5.1"34prompts:5 - "Резюме статусу гілки git одним реченням."6 - "Розробіть стратегію міграції бази даних без простоїв з Postgres на Spanner."78providers:9 - id: "exec:opencode run --auto -m google-vertex/gemini-3.8-flash"10 label: "Gemini 3.8 Flash (OpenCode Agent)"11 - id: "exec:opencode run --auto -m google-vertex-anthropic/claude-fable-5-1"12 label: "Claude Fable 5.1 (OpenCode Agent)"1314defaultTest:15 options:16 timeoutMs: 60000
Запустіть власне порівняння пліч-о-пліч за допомогою Promptfoo:
promptfoo eval -c promptfooconfig.yaml --no-cache
Ось мої результати після запуску цієї оцінки в чистому контейнері розробки:
При перевірці PR-гілки Claude Fable 5.1 провела кілька циклів мета-рефлексії, повторно перевіряючи хеші дерева, які не змінилися. Це зайняло майже 6 секунд і коштувало в 23 рази дорожче. Gemini 3.8 Flash миттєво розпізнала намір, викликала інструменти git і відповіла за 1.1 секунди менш ніж за десять центів.
У випадку зі складною міграцією бази даних картина змінилася. Gemini 3.8 Flash створила солідну, чисту лінійну послідовність за 3 секунди. Але Fable 5.1 витратила 12 секунд на генерацію повного формального орієнтованого ациклічного графа (DAG). Вона виявила ризики розсинхронізації годинників при подвійному записі, сформувала вимоги до ключів ідемпотентності та визначила реверсивний шлюз відкату.
Це лише один ілюстративний приклад; вам слід порівнювати моделі на своїх власних задачах.
3. Практичне використання в повсякденній роботі та продакшені
Незалежно від того, використовуєте ви готові інструменти для кодування чи будуєте власні агентні сервіси, виграшна патерна — асиметрична координація: дешевша швидкість для виконання задач першої лінії, поєднана з усвідомленою глибиною для архітектурних контрольних точок. Витрачайте дорогі токени на складні проблеми або планування, але за замовчуванням використовуйте дешевші токени для простіших задач.
Каркаси кодинг-агентів (OpenCode, Aider тощо)
Не змушуйте одну модель бути вашим універсальним стандартом. Налаштуйте спеціалізованих субагентів, прив’язаних до різних моделей. Використання одного уніфікованого провайдера дає переваги в безпеці та вартості. Використання різних сімейств моделей дозволяє їм перевіряти роботу одна одної.
Використовуйте агента глибокого мислення для визначення кореневої причини та планування рішення цієї проблеми, а потім використайте робочого агента для виконання кожної задачі та звітування про статус. Планувальник перевіряє їхню роботу і або підтверджує успіх, або перепризначає задачу.
1# opencode.json2{3 "$schema": "https://opencode.ai/config.json",4 "model": "google-vertex/gemini-flash-latest",5 "agent": {6 "plan": {7 "model": "google-vertex/gemini-flash-latest"8 },9 "build": {10 "model": "google-vertex/gemini-flash-latest"11 },12 "worker": {13 "model": "google-vertex/gemini-3.8-flash",14 "mode": "primary",15 "description": "General worker agent using gemini-3.8-flash"16 },17 "deep-thinker": {18 "model": "google-vertex-anthropic/claude-fable-5-1@default",19 "mode": "primary",20 "description": "Deep thinking agent using Claude Fable 5.1"21 }22 },23...
Кастомні агенти «як сервіс» (Google ADK, LangGraph, власний код тощо)
Коли ви будуєте власні каркаси агентів та агентні сервіси, у вас є повна архітектурна свобода.
- Перебудуйте каркас під модель: Надайте Gemini 3.8 Flash 3–5 фокусованих інструментів (read_file, write_file, run_tests) зі строгими JSON-схемами. Швидкі моделі чудово справляються з фокусованим виконанням, але каталог із 50 інструментів спричиняє плутанину з параметрами та марнування контексту. Для Claude Fable 5.1 надайте архітектурну документацію, схеми та рекомендації, але позбавте прямих дозволів на запис у файли.
- Грунтуйтеся на Oцінках (Evals): Не вгадуйте, яка модель підходить для якого вузла. Запускайте автоматизовані набори оцінок з детермінованими перевірками тверджень на задачах вашого репозиторію, щоб знайти, де менша модель забезпечує 95% якості за 10% вартості. Це легко сказати, але важко зробити, адже важко знати, які сценарії оцінювати. Перегляньте наші 5-денні курси на Kaggle (агенти, вайб-кодинг) для деталей.
- Використовуйте патерн ескалації «Попросити допомогу»: Починайте кожен вхідний запит на швидкому робочому агенті. Дайте йому явний інструмент: ask_for_help(reason, failed_attempts, context). Робочий агент обробляє 85–90% запитів напряму. Він ескалує задачу лише у випадках неоднозначності, незворотних дій або двох послідовних невдалих спроб виклику інструменту.
Реальність щодо автоматизованих «розумних» маршрутизаторів моделей
Розумні маршрутизатори мають довгу історію в предиктивному ML (адтех, антифрод). Багаторукие бандити (multi-armed bandits) та маршрутизатори «вартість-якість» є зрілими, оскільки ознаки табличні, входи обмежені, а зворотний зв’язок (кліки, чарджбеки) є миттєвим і вимірюваним на довгій дистанції.
У генеративному ШІ багатотурові агенти — це інша історія. Динамічні маршрутизатори можуть стикатися з трьома проблемами в продакшені:
- Контекст одного ходу може не містити достатньо сигналу про задачу для вибору.
- Метрики успіху не екстраполюються чітко на ознаки, тому маршрутизатор не може швидко «навчатися».
- Помилкові вибори повторюються на іншому шляху, з’їдаючи потенційну економію та додаючи затримки.
Вердикт: Тримайте це просто. Компонуйте своїх агентів явно та маршрутизуйте за межами задач. Визначте чіткі ролі, і нехай конкретні перевірки коду або людський намір контролюють передачу повноважень.
4. Рівняння ROI токенів: за що ви насправді платите?
Сирий прайс-лист ($/1M токенів) — це не гарна карта виробничої цінності. Розрахунок вартості — лише частина рівняння. Неможливо дати вам формулу, яка завжди працюватиме для кодування, продукту, виробництва та будь-якої іншої роботи, яку треба виконати.
Початковою точкою може бути думка про бізнес-цінність, яку ви отримуєте.
- Вартість зекономленого людського часу, більший обсяг роботи, виконаний співробітниками, та менше часу на рутину та автоматизовані задачі.
- Цінність швидшого випуску функцій у продакшн, підвищення задоволеності клієнтів та утримання завдяки цим функціям.
- Помилки, яких вдалося уникнути, та простої в продакшені, запобігання яким стало можливим завдяки покращеним захистам та інженерним практикам.
Відніміть вартість токенів та витрати на підвищення кваліфікації вашої команди для створення та управління їхніми агентами, і ви отримаєте приблизний розрахунок ROI.
Ви можете впливати на ці розрахунки, використовуючи менше та дешевші токени, але найбільший вплив матиме виконання більшої кількості роботи швидше. Обирайте задачі з високим важелем. Обирайте задачі, які призводять до економії накладних витрат або збільшення доходу, які можна верифікувати та які варто автоматизувати. І коли ви декомпозуєте ці задачі, можливо, ви захочете думати надзвичайно глибоко, планувати, бути готовими платити більше та чекати, або ж ви захочете виконувати швидко та надійно. Вам знадобиться і те, і інше.
Токеноміка — гаряча тема зараз, і є багато інших способів знизити витрати та максимізувати цінність. Головна думка цієї статті полягає в тому, що дуже просто налаштувати кілька різних агентів на двох моделях з різними профілями та самостійно маршрутизувати задачі. Це найлегша точка старту.
Якщо цей розбір був корисним, перегляньте нашу попередню статтю про 5 речей, які кожен AI-інженер має знати про пісочниці агентів. Підпишіться на @GoogleCloudTech та @zeroasterisk, щоб читати більше глибоких занурень від розробників із «поля бою».
