У подкасті Mixture of Experts від IBM Technology ведучий Тім Хван спілкується з інженерами та лідерами AI‑напряму про те, як компанії намагаються приборкати витрати на генеративний ШІ. На тлі нових великих моделей, здатних за лічені дні «спалити» бюджети на токени, дискусія зосереджується не стільки на швидкості чи якості, скільки на економіці: як проєктувати системи, які не розорять замовника — і при цьому не зламають робочий процес команди.
Дві школи економії: «дешевий спочатку» проти «одним пострілом»
У розмові прозвучала проста, але показова дихотомія: є дві базові стратегії використання LLM з погляду вартості.
Перша — будувати пайплайн так, щоби більшість запитів обробляла дешева, менш потужна модель. Якщо вона «застрягає» або потреба в якості вища, запит ескалується до більшої й дорожчої моделі. Це природно вписується в агентні архітектури: значна частина рутинних або низькоцінних задач не вимагає «фронтирного» інтелекту.
Друга — навпаки, одразу звертатися до потужної моделі й намагатися вирішити задачу за один прохід. Аргумент тут не про інфраструктуру, а про людей: час інженерів, аналітиків чи користувачів — теж гроші. Якщо економія на токенах призводить до багатьох невдалих спроб, додаткових уточнень, багфіксів чи повторного проєктування, загальні витрати можуть виявитися вищими, ніж при «дорогому, але точному» першому запуску.
Учасники дискусії підкреслюють: немає усталеної відповіді, яка з цих стратегій «правильна» завжди. Натомість формується третій підхід — свідоме поєднання обох через роутинг моделей.
Модельний роутинг як нова норма
«Хороший шматок» нинішнього консенсусу, як сформулювали гості подкасту, такий: варто будувати системи, які вміють маршрутизувати задачі між різними моделями. Використовувати «суміш моделей» для однієї бізнес‑функції стає радше правилом, ніж винятком.
Логіка тут доволі прагматична. Є цілий клас запитів і задач, які мають:
- низьку «цінність помилки»;
- невисоку складність;
- повторюваний характер.
Для них очевидно не потрібен найновіший «5.5‑каліберний» гігант. Їх цілком здатні закривати менші моделі — за значно нижчою ціною.
Роутинг у цьому контексті — не лише технічний патерн, а й управлінська стратегія. Він дозволяє:
- відсікати прості кейси й не «палити» токени там, де це не має сенсу;
- резервувати дорогі, «state‑of‑the‑art» моделі для вузької групи дійсно критичних задач;
- гнучко керувати бюджетом, змінюючи політику маршрутизації без повного перегляду всієї системи.
Це, на думку учасників, добре корелює з появою «середнього ринку» моделей — не найфронтирніших, але достатньо потужних і, головне, дешевших в експлуатації. І саме такі моделі природно вписуються в багаторівневі схеми роутингу.
Не все має бути «фронтиром»: де вистачає простіших моделей
Одна з ключових тез дискусії — «не все потребує модель рівня топового флагмана». У переважної більшості задач, із якими стикаються підприємства, вимоги до якості знаходяться нижче теоретичної стелі сучасних моделей.
Лише відносно невелика частина кейсів реально вимагає:
- максимальної точності перефразування чи аналізу;
- складного міркування з багатьма кроками;
- роботи з неоднозначними, рідкісними або чутливими даними.
Для всього іншого існує простіший (і значно дешевший) інструментарій. Це, своєю чергою, знімає нервову напругу навколо дилеми «або фронтир, або нічого»: компаніям не потрібно будувати свою економіку виключно навколо найдорожчих моделей.
Напрямок, який вимальовується, — мати у стосі кілька категорій моделей і бути чесними щодо їхнього призначення. Менші моделі стають «робочими конячками», тоді як великі — інструментами для вузьких, стратегічно важливих фрагментів процесу, де ціна помилки або перевиконання роботи особливо висока.
Рідко обговорюваний важіль: вартість не лише токенів, а й людей
На думку учасників, у професійних дискусіях про вартість AI надто багато уваги приділяється суто інфраструктурним метрикам — ціна токена, latency, кількість параметрів. Натомість майже не обговорюється інший, не менш важливий вимір: скільки насправді коштує робота людей навколо цих моделей.
Для ілюстрації один із спікерів згадав філософію мови Ruby: вона була спроєктована з установкою, що «неважливо, наскільки важко комп’ютеру, якщо розробнику легко». За тієї економіки програмісти були дорожчими за обчислення, тому мова без сорому перекладала складність на машину.
З генеративним ШІ картина змінюється. Великі моделі можуть «з’їдати» ресурси з такою швидкістю, що вартість обчислень більше не виглядає другорядною. Але й повертатися до парадигми, де вся складність лягає на людей — теж не вихід.
Звідси — ще один шар компромісів:
- де можна дозволити собі витратити більше токенів, аби не збільшувати когнітивне навантаження на інженерів і користувачів;
- у яких частинах процесу, навпаки, варто інвестувати в кращу підготовку, чіткіші специфікації та дизайн, щоб зменшити потребу в повторних проходах дорогою моделлю.
Саме тому, як зазначається в розмові, іноді варто свідомо «маршрутизувати» запит до максимально потужної моделі. Коли задача складна, а вартість повторної роботи висока, дешевше зробити «правильно з першого разу», ніж економити на токенах і потім витрачати години людей на переробки.
Стиснута розробка й «стіна рев’ю»: коли швидкість б’є по процесу
Генеративні AI‑інструменти радикально прискорюють етап будівництва — написання коду, створення концептів, прототипів. Але, як зауважують учасники, це призводить до небезпечної ілюзії: якщо будувати можна швидше, нібито можна скоротити й планування.
У класичній схемі розробки існують три фази:
- планування — що саме будуємо й навіщо;
- побудова — реалізація;
- рев’ю — перевірка, корекція, узгодження результату з очікуваннями.
Сьогодні build‑фаза завдяки AI стискається до мінімуму. І виникає спокуса різко зменшити й час на планування — адже «ми ж швидко ітератуємо». Наслідком стає роздутий, болючий етап перевірки, який один зі спікерів назвав просто «стіною».
Коли:
- різні люди й агенти мають несинхронізоване уявлення про результат;
- відсутня спільна мова очікувань;
- рішення приймалися ad hoc «по дорозі»,
фінальний рев’ю перетворюється на затяжне й виснажливе «перепакування» вже згенерованого. У сфері кодингу це означає години чистки згенерованого коду; у креативних індустріях — нескінченні цикли правок згенерованих відео чи текстів.
Висновок із цієї частини розмови: економія на плануванні в умовах швидких AI‑ітерацій часто лише пересуває витрати вперед — у рев’ю. А це найдратівливіший і, нерідко, найдорожчий для організації етап. Отже, справжня оптимізація — не в тому, щоб «усе стиснути», а в тому, щоб зберегти (або навіть посилити) увагу до спільного розуміння цілей між усіма людьми й агентами в системі.
Баланс попиту: коли потрібен «state‑of‑the‑art»
Попри загальну орієнтацію на економію, учасники розмови не пропонують фетишизувати дешевизну. Часом використання «state‑of‑the‑art» моделі — не примха, а раціональний вибір.
Є типи задач, де:
- щонайменша помилка обходиться дуже дорого;
- повторна робота фактично означає повний перезапуск процесу;
- втрата довіри користувачів через декілька «фейлів» коштує більше, ніж будь-який рахунок за токени.
У таких випадках модельний роутинг повинен не тільки щадити бюджет, а й «знати», де економія недоречна. І тут знову з’являється людський фактор: потрібна зріла оцінка ризиків і готовність свідомо платити більше там, де це дійсно виправдано.
Висновок: економіка AI — це не лише прайс лист на токени
З розмови на Mixture of Experts вимальовується інша оптика на вартість генеративного ШІ. Вона включає не тільки ціну виклику моделі, а й:
- дизайн системи з роутингом між кількома моделями;
- вартість часу розробників, аналітиків і кінцевих користувачів;
- ризики повторної роботи й ціною помилок;
- якість планування та узгодження очікувань до запуску.
У цьому ландшафті «зекономити на LLM» означає вже не вибрати одну «правильну» модель, а вибудувати збалансовану екосистему: дешева там, де це безпечно, потужна там, де це критично, і завжди з урахуванням того, як люди працюватимуть із цими інструментами.