Під час живого запису подкасту Mixture of Experts в офісі IBM One Madison у Нью-Йорку, в межах New York Tech Week, керівники IBM обговорювали не лише майбутнє розробки ПЗ, а й те, як штучний інтелект змінює економіку ІТ. На тлі хвилі «tokenmaxxing» — коли компанії спалюють річні бюджети на AI за кілька місяців — IBM демонструє іншу стратегію: внутрішній асистент Bob, який не просто генерує код, а оркеструє цілий парк моделей, постійно балансуючи між вартістю, якістю та швидкістю.
Це не історія про ще одного «корпоративного Copilot’а». Це історія про те, як велика компанія намагається масштабувати AI відповідально — і що для цього доводиться міняти в самій інфраструктурі моделей та в організації роботи.
Від «tokenmaxxing» до тверезої економіки AI
Термін «tokenmaxxing» уже став своєрідним статусним символом у техно‑середовищі: хто більше прогнав токенів через GPT‑подібні моделі, той ніби «крутіший». У розмові це порівнюють із тим, скільки кілограмів ти піднімаєш у спортзалі: можна хизуватися цифрами, але не факт, що це веде до здоров’я, а не до «грижі».
На практиці tokenmaxxing означає, що компанії запускають безліч AI‑експериментів на дорогих фронтирних моделях, не маючи чіткої стратегії маршрутизації запитів, контролю якості чи оптимізації витрат. Результат — річні бюджети на AI зникають за кілька місяців, а керівництво починає ставити незручні запитання: що ми реально отримали в обмін на ці мільйони?
IBM намагається відповісти на це питання системно. Замість того, щоб «максимізувати токени», компанія будує інфраструктуру, де кожен запит до AI — це кероване рішення: яку модель використати, де її запустити, скільки це коштуватиме і чи виправдана ця ціна для конкретного завдання.
У центрі цієї стратегії — Bob, внутрішній AI‑асистент IBM, який починав як інструмент для розробників, а тепер виходить далеко за межі інженерних команд.
Bob як диспетчер моделей: один інтерфейс, багато «двигунів»
Формально Bob — це внутрішній AI‑асистент IBM для розробки ПЗ. Але під капотом він виглядає радше як диспетчер, що керує «парком» різних моделей. IBM не обмежується одним великим LLM: Bob оркеструє одразу кілька типів моделей — від фронтирних до невеликих власних.
У єдиному інтерфейсі ховається складна багатомодельна архітектура. Bob може підключати:
- великі фронтирні моделі (foundation / frontier models) з широкими знаннями;
- відкриті моделі з open‑source‑екосистеми;
- власні малі мовні моделі IBM, оптимізовані під конкретні задачі.
Користувач цього не бачить. Для нього Bob — це один асистент, до якого можна звернутися природною мовою. Яка саме модель відповідає — GPT‑подібна, відкрита чи внутрішня мала — залишається «за лаштунками». Вибір робить сам Bob, автоматично підбираючи модель під завдання.
Це принципово інший підхід, ніж у багатьох компаній, де кожна команда самостійно обирає «улюблену» модель і напряму інтегрує її в свій продукт. Така фрагментація часто й веде до tokenmaxxing: кожен оптимізує під свою локальну зручність, а не під глобальну економіку організації.
У випадку IBM логіка інша: централізований оркестратор, який бачить весь «зоопарк» моделей, їхню вартість, продуктивність і якість, і сам вирішує, що де запускати.
Pareto‑логіка: як Bob балансує ціну, якість і швидкість
Ключ до відповідального масштабування AI — не лише в тому, щоб мати багато моделей, а в тому, як між ними обирати. IBM описує підхід Bob як оптимізацію за принципом Парето: система шукає такі конфігурації, де не можна покращити один параметр (наприклад, знизити вартість), не погіршивши інші (якість або швидкість).
Фактично Bob постійно вирішує багатокритеріальну задачу:
- чи достатня якість відповіді малої моделі для цього завдання;
- чи критична тут швидкість інференсу;
- чи виправдана вартість фронтирної моделі, якщо є дешевший локальний варіант із прийнятною якістю.
Якщо завдання рутинне, добре структуроване і не потребує глибокого «загального знання світу», Bob може віддати його малій або локальній моделі. Якщо ж запит складний, вимагає широкого контексту або високої точності, у гру вступає фронтирна модель.
Ця логіка важлива не лише для економії. Вона дає змогу будувати більш передбачувані й керовані AI‑системи. Замість того, щоб «стріляти з гармати по горобцях» кожного разу, коли користувач ставить запитання, Bob намагається підібрати «інструмент за розміром задачі».
У світі, де токени напряму конвертуються в долари, така Pareto‑орієнтована маршрутизація стає не просто технічною оптимізацією, а елементом фінансової стратегії.
Чому IBM свідомо не «молиться» на фронтирні моделі
На ринку AI легко піддатися спокусі: якщо є модель із сотнями мільярдів параметрів, чому б не використовувати її всюди? IBM демонструє більш стриманий підхід. Компанія прямо наголошує: завдання потрібно по можливості маршрутизувати на менші або локальні моделі, а не завжди бігти до фронтирних.
Це рішення має кілька вимірів.
По‑перше, вартість. Фронтирні моделі дорогі в інференсі, особливо при великих обсягах запитів. Якщо кожен внутрішній процес — від генерації листів до аналізу логів — постійно звертається до таких моделей, бюджет на AI швидко виходить з‑під контролю.
По‑друге, ефективність. Малі моделі, розгорнуті локально або в оптимізованому середовищі, часто забезпечують меншу затримку й кращу інтеграцію з внутрішніми системами. Для багатьох бізнес‑процесів цього більш ніж достатньо.
По‑третє, керованість. Власні малі моделі IBM можна точніше налаштовувати під специфічні домени, політики безпеки та вимоги до приватності. Це особливо важливо в корпоративному середовищі, де дані не завжди можна вільно виводити за межі інфраструктури.
У підсумку фронтирні моделі в IBM — це не «дефолтний вибір», а радше «важка артилерія», яку Bob підключає тоді, коли інші варіанти не дають прийнятної якості. Така ієрархія дозволяє уникати tokenmaxxing за замовчуванням: дорога модель — це завжди усвідомлене рішення, а не інерційний стандарт.
Вихід за межі коду: Bob іде в інфраструктуру, фінанси та маркетинг
Спершу Bob позиціонувався як асистент для розробників, який допомагає на всіх етапах життєвого циклу ПЗ — від вимог до деплойменту. Але в IBM уже говорять про значно ширше застосування. Компанія використовує Bob не лише в інженерних командах, а й у низці нефункцій, які традиційно не асоціюються з AI‑кодерами.
Bob працює в:
- інфраструктурних підрозділах;
- консалтингу;
- операціях;
- фінансах;
- комунікаціях;
- маркетингу.
Це важливий сигнал: багатомодельна оркестрація перестає бути «фішкою для девелоперів» і стає загальнокорпоративною платформою. У кожному з цих напрямів діють свої обмеження щодо вартості, швидкості та якості. Наприклад, у фінансах критичною є точність і відтворюваність; у маркетингу — креативність і швидкість; в інфраструктурі — стабільність і інтеграція з існуючими системами.
Єдиний інтерфейс Bob дозволяє працівникам цих підрозділів працювати з AI без необхідності розуміти, яка саме модель стоїть за відповіддю. Водночас оркестратор під капотом може підбирати різні моделі для різних департаментів, враховуючи їхні специфічні вимоги й бюджети.
Це ще один аргумент проти tokenmaxxing: коли AI‑використання розповзається по всій організації, хаотичне підключення фронтирних моделей у кожному відділі стає фінансово небезпечним. Централізований оркестратор на кшталт Bob дозволяє масштабувати AI по всій компанії, не втрачаючи контролю над витратами.
Прихована складність: чому користувачам не показують, яка модель працює
Цікава деталь IBM‑підходу — Bob не розкриває кінцевим користувачам, яка саме модель обробляє їхній запит. Для співробітника це просто Bob, а не «Bob на GPT‑X» чи «Bob на внутрішній малій моделі».
Такий дизайн має кілька наслідків.
По‑перше, він зменшує когнітивне навантаження. Користувачам не потрібно розбиратися в зоопарку моделей, їхніх версіях і параметрах. Вони формулюють задачу, а вибір моделі — це технічна деталь, за яку відповідає платформа.
По‑друге, це запобігає «модельному снобізму». У багатьох організаціях співробітники починають вимагати «тільки найновішу модель», навіть якщо їхні задачі не потребують такої потужності. Приховуючи конкретні моделі, IBM зменшує спокусу «вибивати» собі дорожчі ресурси без об’єктивної потреби.
По‑третє, це дозволяє IBM гнучко оновлювати й замінювати моделі під капотом без зміни користувацького досвіду. Якщо з’являється нова відкрита модель, яка дає кращу якість за ті ж гроші, Bob може почати її використовувати, не змінюючи інтерфейс і не змушуючи тисячі співробітників адаптуватися до нового «бренду» моделі.
Усе це знову повертає до теми tokenmaxxing: коли користувачі не «грають» у вибір моделей, а просто формулюють задачі, легше будувати раціональну економіку AI на рівні всієї організації.
Від Software 2.0 до Software 4.0: де тут місце оркестрації
У дискусії IBM окреслює еволюцію програмного забезпечення в кілька хвиль. Software 2.0 — це епоха, коли «дані — це код», а машинне навчання замінює великі масиви правил. Software 3.0 — час foundation‑моделей і фронтирних LLM, які приносять у системи загальні знання й «квазі‑інтелект».
Наступний крок — Software 4.0, де системи складаються з агентних компонентів, які взаємодіють між собою та з людьми. У такому світі ключовим стає не стільки написання коду, скільки оркестрація агентів і моделей.
Bob — це ранній приклад такої оркестрації. Він уже сьогодні:
- сприймає завдання в людській мові;
- розкладає їх на підзадачі;
- обирає відповідні моделі;
- координує виконання;
- повертає результат у зрозумілому вигляді.
У міру того, як агентні системи ставатимуть складнішими, роль таких оркестраторів лише зростатиме. І саме тут економіка AI стає невіддільною від архітектури: якщо кожен агент бездумно тягне фронтирну модель, Software 4.0 перетворюється на фінансовий кошмар. Якщо ж оркестрація вбудована з самого початку, як у Bob, агентні системи можуть масштабуватися без вибуху витрат.
Tokenmaxxing як симптом відсутності стратегії
На тлі цієї картини tokenmaxxing виглядає не стільки технічною проблемою, скільки симптомом організаційної незрілості. Коли компанія:
- не має централізованого оркестратора моделей;
- дозволяє кожній команді самостійно обирати й оплачувати AI‑ресурси;
- не вимірює системно співвідношення «вартість — якість — швидкість»,
вона фактично запрошує tokenmaxxing у свій бюджет.
IBM намагається побудувати протилежну модель. Bob стає не просто інструментом для розробників, а платформою, яка:
- ховає складність модельного ландшафту від користувачів;
- централізує вибір моделей;
- оптимізує запити за Pareto‑логікою;
- свідомо віддає пріоритет меншим і локальним моделям там, де це можливо;
- поширюється на нефункції, де раніше AI майже не використовувався.
Усе це не гарантує відсутності помилок чи перевитрат, але задає інший вектор: від «максимізації токенів» до «максимізації цінності на токен».
Висновок: відповідальний AI — це інженерія, а не маркетинг
Дискусія в студії IBM під час New York Tech Week показує: ера «демо‑ефекту» в AI поступово минає. Вражаючі можливості фронтирних моделей уже нікого не дивують. Натомість на перший план виходять менш гламурні, але критично важливі питання — як це все інтегрувати, як цим керувати і скільки це коштує в реальному масштабі.
Bob — це спроба відповісти на ці питання через інженерний підхід: багатомодельна оркестрація, прихована від користувача, але чітко керована на рівні платформи; Pareto‑оптимізація замість «усюди найпотужнішу модель»; свідомий пріоритет менших і локальних моделей; вихід за межі розробки ПЗ в інші бізнес‑функції.
На тлі tokenmaxxing це виглядає як контркультура: не хизуватися кількістю прогнаних токенів, а будувати системи, де кожен токен працює на конкретну бізнес‑ціль. Якщо Software 4.0 справді стане епохою агентних систем, саме такі підходи можуть визначити, хто зможе масштабувати AI без фінансової «грижі».
Джерело
The future of software engineering, tokenmaxxing and AI in higher education — IBM Technology