У корпоративному світі штучного інтелекту назріває зсув: замість одного «чарівного» великого моделя, який нібито має вміти все, на перший план виходять системи, що вміють керувати багатьма різними моделями й сервісами. На цьому тлі IBM представила два пов’язані елементи своєї стратегії: нове покоління спеціалізованих моделей Granite 4.1 та IBM Bob — системного AI-партнера для розробників і агентного coding‑асистента.
У подкасті IBM Technology «Mixture of Experts» ведучий Тім Хван разом із дослідниками та архітекторами IBM обговорюють, як саме Bob і Granite 4.1 втілюють бачення компанії: enterprise‑AI як композиційної, а не монолітної інфраструктури. У центрі цієї картини — Bob як оркестратор, що розподіляє завдання між різними моделями за вартістю й можливостями, допомагає модернізувати легасі‑код і стримує вибух витрат на токени.
Від «одного великого мозку» до системного партнера
IBM позиціонує IBM Bob не як чергового чат‑асистента, а як системного AI‑партнера для розробників. Це агентний coding‑асистент, який вбудовується в ширший стек і працює поруч із людьми‑інженерами, а не просто відповідає на окремі запити.
Ключова відмінність — рівень, на якому Bob мислиться. Це не «ще один LLM», а компонент системної архітектури, що приймає рішення: яке завдання куди відправити, яку модель викликати, коли варто залучити дорогий «фронтирний» модель, а коли достатньо дешевого спеціалізованого. У цьому сенсі Bob ближчий до операційної системи для AI‑робочих процесів, ніж до класичного бота.
Ця логіка напряму пов’язана з тим, як IBM описує реальні навантаження в підприємствах. Вони не є монолітними. У межах однієї організації одночасно живуть десятки й сотні різних задач: від генерації тексту й аналізу таблиць до транскрипції дзвінків, перевірки безпеки коду й підтримки легасі‑систем. Спроба «загнати» все це в один гігантський модель неминуче впирається в вартість, масштабованість і керованість.
Саме тому Bob задуманий як партнер, який розуміє цю множинність і вміє працювати з нею як із нормою, а не винятком.
Мультимодальна оркестрація: як Bob розподіляє роботу між моделями
Один із центральних технічних мотивів IBM Bob — мультимодальна оркестрація. Йдеться не лише про вміння працювати з текстом, зображеннями чи аудіо, а про здатність маршрутизувати різні підзадачі до різних «хмар» моделей залежно від їхніх характеристик.
У розмові наводиться показовий приклад: для «важкого» міркування Bob може звернутися до потужних моделей на кшталт Mistral або Granite, тоді як для «дешевих» доповнень — до дрібніших, тонко налаштованих спеціалістів. Для безпекового рев’ю коду — до окремо натренованих моделей, оптимізованих саме під такі перевірки. Для розуміння таблиць і діаграм — до візуальних Granite‑моделей, які спеціально заточені під табличні структури, а не під генерацію «крутих sci‑fi картинок».
Bob у цій схемі не намагається «зробити все сам». Навпаки, його завдання — максимально розвантажити себе від вузьких задач, передаючи їх туди, де вони будуть виконані дешевше й ефективніше. Дорогий, потужний модель залишається ядром, що тримає загальну логіку, контекст і планування, тоді як рутинні операції виконуються периферійними спеціалізованими моделями.
Це радикально відрізняється від уявлення про «єдиний великий агент», який самостійно вирішує всі проблеми. IBM фактично каже: агент — це не один модель, а система, в якій один інтелектуальний компонент керує багатьма іншими.
Granite 4.1 як «робочі коні» для Bob і агентних систем
Щоби така оркестрація взагалі мала сенс, потрібен набір моделей, які добре працюють у вузьких, але масових сценаріях. Саме тут у гру входить Granite 4.1 — нове покоління спеціалізованих мультимодальних моделей, яке IBM запустила буквально за годину до запису подкасту.
Granite 4.1 — це не один модель, а сімейство: мовні, візуальні, мовленнєві та embedding‑моделі. Вони спроєктовані не як «демо для шоукейсу», а як інструменти для конкретних enterprise‑задач, які мають працювати в парі з агентами на кшталт Bob.
Мовні моделі Granite 4.1 виходять у трьох розмірах — від 3 до 30 мільярдів параметрів. Вони оптимізовані під інструкційне слідування й виклик інструментів, тобто під сценарії, де модель має не просто «балакати», а чітко виконувати кроки, викликати зовнішні сервіси, працювати в RAG‑ланцюжках як бекграунд‑дослідник. Це саме той тип роботи, який Bob може делегувати: «зроби мені пошук, підготуй витяги, поверни структурований результат».
Візуальні моделі Granite 4.1 сфокусовані на розумінні таблиць і графіків, зберігаючи при цьому загальні можливості комп’ютерного зору. Для бізнесу це принципово: корпоративні дані живуть у звітах, Excel‑таблицях, PDF‑презентаціях, а не в художніх зображеннях. Питання не в тому, чи може модель намалювати фантастичний пейзаж, а в тому, чи здатна вона коректно прочитати фінансову таблицю й інтерпретувати діаграму.
Мовленнєві моделі Granite 4.1 орієнтовані на транскрипцію й переклад, причому з акцентом на мінімізацію розміру. Ідея в тому, щоби зробити їх настільки компактними, наскільки це можливо без втрати якості, аби їх можна було розгортати на великій кількості пристроїв і сервісів. Знову ж таки, це ідеальні кандидати для делегування рутинних задач: перетворення дзвінків на текст, переклад внутрішніх дзвінків і зустрічей, попередня обробка аудіо.
Embedding‑моделі Granite 4.1 доповнюють картину, забезпечуючи основу для пошуку, кластеризації й побудови RAG‑систем. Усе разом це створює «модельний інструментарій», який Bob може викликати як окремі функції: «зроби транскрипцію», «розбери таблицю», «згенеруй embedding‑и для цього корпусу документів».
У підсумку Granite 4.1 і Bob утворюють дві сторони однієї стратегії: Granite — це спеціалізовані «робочі коні», Bob — диспетчер, який знає, коли й як їх залучити.
Плюралістичні навантаження й кінець епохи «одного гіганта»
Одна з найяскравіших тез дискусії — твердження, що enterprise‑AI за своєю природою плюралістичний, а не монолітний. Це не абстрактна філософія, а практичний висновок із того, як реально виглядає робота великих організацій.
У типовій компанії більшість задач — рутинні й повторювані. Формування звітів, перевірка контрактів, аналіз логів, оновлення документації, локалізація контенту, внутрішні запити до служби підтримки, нескінченні невеликі зміни в коді. Лише невелика частина потребує «глибокої» творчої або стратегічної роботи, де справді виправдано використання найдорожчих моделей.
Якщо намагатися вирішувати всі ці задачі одним «фронтирним» LLM, виникає дві проблеми. По‑перше, вартість: токени дорогих моделей швидко «з’їдають» бюджети. У подкасті згадують історії компаній, які встигли витратити річний ліміт токенів за квартал — явище, яке вже отримало іронічну назву «token maxing», коли хтось намагається довести свою «найбільшу AI‑просунутість» за рахунок безконтрольного використання моделей. По‑друге, неефективність: потужний модель змушений витрачати ресурси на дрібниці, які могли б виконуватися значно дешевше.
IBM протиставляє цьому підхід «композиційної системної архітектури». Замість того, щоби продавати «монолітний інтелект», компанія пропонує набір сервісів, які можна комбінувати. Учасники дискусії порівнюють це з еволюцією операційних систем у 1980‑х: від гігантських монолітних програм до наборів модульних сервісів, які можна підключати й відключати за потреби.
У цьому контексті Bob — це не просто ще один агент, а втілення цієї парадигми. Він спроєктований так, щоби жити в світі, де багато моделей співіснують, а не конкурують. Його завдання — не максимізувати кількість викликів до одного «супермоделя», а навпаки, мінімізувати непотрібні витрати, розкладаючи навантаження по спеціалізованих компонентах.
Токени, бюджети й «token squeezing»: економіка Bob‑підходу
Економічний вимір цієї архітектури — не менш важливий, ніж технічний. У корпоративному середовищі вартість токенів — не абстракція, а рядок у бюджеті, який може стати болючою статтею витрат.
Учасники подкасту прямо говорять про те, що нинішня модель споживання AI у стилі «підписка й забули» працює для споживачів, але погано масштабується для підприємств. Коли десятки команд починають масово використовувати дорогі моделі для будь‑яких задач — від написання листів до аналізу логів — витрати швидко виходять з‑під контролю.
На цьому тлі з’являється протилежний тренд — «token squeezing» або «right‑sizing» токенів. Ідея полягає не в тому, щоби «витратити якомога більше», а в тому, щоби кожен токен був витрачений там, де він справді потрібен, і за мінімально можливою ціною. Це означає:
використовувати дешевші, менші моделі для рутинних задач;
застосовувати спеціалізовані моделі там, де вони дають кращу якість на одиницю вартості;
залучати дорогі «фронтирні» моделі лише для тих частин робочого процесу, де без них не обійтися — наприклад, для складного планування, інтеграції контекстів, прийняття нетривіальних рішень.
Granite 4.1 і Bob якраз і позиціонуються як інструменти для такого «token squeezing». Granite надає набір менших, спеціалізованих моделей, які можна вставити в агентні пайплайни як окремі кроки: «зроби транскрипцію», «розбери таблицю», «виконай інструкцію». Bob, у свою чергу, вирішує, коли й як ці кроки викликати, щоби мінімізувати загальну вартість, не жертвуючи якістю.
Це не просто оптимізація «на рівні моделя», а оптимізація на рівні всієї системи. Bob не намагається зробити кожен окремий виклик максимально дешевим; він намагається зробити дешевим увесь ланцюжок, розуміючи, де можна зекономити, а де економія обернеться втратою якості або надійності.
Легасі як перевага: COBOL, мейнфрейми й модернізація через Bob
Окрема лінія, яку IBM підкреслює особливо, — це робота з легасі‑кодом. Для багатьох великих підприємств, особливо в банківському та фінансовому секторах, критично важливі системи досі працюють на COBOL і мейнфреймах IBM Z. Йдеться про трильйони рядків коду, написаних десятиліттями раніше, які сучасні coding‑агенти часто навіть не розпізнають як «повноцінні» мови.
У цьому контексті IBM стверджує, що Bob ставиться до таких мов як до «першокласних громадян». Це не екзотика, не «додатковий плагін», а повноцінна ціль для аналізу, розуміння й трансформації. У поєднанні з Granite це створює те, що в розмові називають «моатом» — конкурентною перевагою, яку складно відтворити іншим гравцям.
Для підприємств це означає, що AI‑асистент може не лише писати новий код на сучасних мовах, а й допомагати розбиратися в існуючих мейнфреймових системах, пропонувати шляхи модернізації, автоматизувати частину міграційних робіт. У світі, де більшість гучних AI‑демо показують генерацію нового коду «з нуля», IBM робить ставку на те, що реальний попит у великих компаній — це робота з тим, що вже є й що критично важливо не зламати.
Bob у цій картині виступає як системний партнер, який розуміє, що «enterprise‑код» — це не лише Python і JavaScript, а й COBOL, PL/I, JCL та інші мови, які визначають роботу глобальних фінансових і промислових систем. Модернізація тут — не маркетинговий слоган, а щоденна необхідність.
Чи справді нам потрібні «агенти, які роблять усе»?
На тлі всього цього виникає цікаве запитання: чи не виявиться так, що нинішній ажіотаж навколо «агентів, які вміють усе» — тимчасовий? У дискусії звучить думка, що, якщо подивитися на реальні задачі в більшості бізнесів, переважна їх частина — доволі передбачувана й рутинна. У такому світі «генералізована автентична поведінка» агента може виявитися не перевагою, а джерелом непередбачуваних витрат і ризиків.
IBM не відмовляється від агентної парадигми — навпаки, Bob є саме агентним coding‑асистентом. Але акцент зміщується з «агента як всесильного інтелекту» на «агента як диспетчера й інтегратора». У цій моделі 90% роботи виконують спеціалізовані моделі й сервіси, а агент відповідає за координацію, контроль і взаємодію з людиною.
Це більш «приземлений» погляд на агентів, який краще відповідає тому, як влаштовані великі організації: з чіткими процесами, регуляторними вимогами, обмеженими бюджетами й величезною кількістю легасі‑систем. У такому середовищі перемагатимуть не ті, хто збудує «найрозумнішого агента», а ті, хто зможе найкраще скомпонувати безліч різних можливостей у керовану, передбачувану й економічно стійку систему.
Висновок: AI як інфраструктура, а не як шоу
Запуск IBM Bob і Granite 4.1 демонструє, що корпоративний AI входить у фазу інфраструктурного мислення. Замість того, щоби гнатися за черговим «найбільшим» або «найкреативнішим» моделью, IBM робить ставку на архітектуру: як поєднати різні моделі, як оптимізувати витрати, як працювати з легасі, як перетворити AI з дорогого експерименту на передбачуваний компонент IT‑ландшафту.
Bob у цій історії — не герой‑одинак, а координатор складної екосистеми. Granite 4.1 — не «флагманський модель», а набір інструментів, які дозволяють цій екосистемі працювати ефективно. Разом вони втілюють бачення enterprise‑AI як чогось плюралістичного, складального й економічно виваженого.
Для компаній, які дивляться на AI не як на разову демонстрацію, а як на довгострокову інвестицію, саме така перспектива, схоже, стає вирішальною.
Джерело
Granite 4.1, IBM Bob & building a quantum ecosystem — IBM Technology