Прихована вартість хмари

Розділ 5 — Прихована вартість хмари

Домінуюча розповідь останніх п’яти років полягає в тому, що хмара є економічною, масштабованою та простою. Для багатьох робочих навантажень це абсолютно вірно. Але для корпоративних RAG-систем це все частіше не так. І ви зазвичай дізнаєтесь про це в кінці першого кварталу, коли приходить рахунок.

Візьмемо найбільш недооцінену статтю витрат: API моделей комп’ютерного зору. Коли компанія завантажує свій фотоархів у сучасну RAG-систему, кожне фото має бути "описане" мультимодальною моделлю, яка витягує з нього вміст, об’єкти, контекст, будь-який текст, що накладений, настрій, композицію. Великий європейський постачальник моделей — поки що без назви — пропонував у 2025 році чудову модель сімейства Qwen з 32 мільярдами параметрів за цікавою ціною за зображення. Проблема, виявлена лише на практиці та після місяців виробництва: під навантаженням провайдер обрізав відповіді. Не завжди, не передбачувано, не коли поруч була команда тестування: випадково. Одна фотографія з десяти, іноді одна з п’яти, поверталася з JSON, обрізаним навпіл, неправильно розпарсеним, з частковими або відсутніми метаданими. Час зростав з десяти секунд до двохсот секунд на зображення, без закономірностей. Рахунок за повторні спроби — тому що повторні спроби оплачуються, кожен виклик, навіть той, який сервер обрізає — був вищим за очікуваний. База даних була неоднорідною: деякі фотографії багаті на метадані, інші — обрізані. І команда не могла відтворити проблему в тестових середовищах, тому що в тестах навантаження було низьким і все працювало.

Рішення прийшло у трьох частинах: більш компактний запит (коротші відповіді рідше обрізаються), розумна логіка повторних спроб (якщо відповідь займає більше п’ятдесяти секунд і повертається порожньою, спробуйте знову негайно) і — коли обсяг це виправдовує — можливість взагалі обійти хмару та запустити модель комп’ютерного зору на локальній GPU, повільнішій, але детермінованій. Правильна архітектура, з цього досвіду, — це не "завжди хмара" і не "завжди локально". Це "вибирайте для кожного запиту, виходячи з того, що потрібно в цей момент".

Потім є розділ запитів. Кожен пошук користувача в класичному RAG, розробленому для хмари, запускає каскад платних викликів API. Один для вбудовування запитання. Один для класифікації намірів (який тип запитання?). Один для повторного ранжування документів. Один для генерації остаточної відповіді. Кожен коштує частку цента. Для внутрішнього сервісу з п’ятдесятьма користувачами та десятьма тисячами запитів на день — що небагато, але й не величезна кількість для компанії середнього розміру — щомісячний рахунок досягає сум, які змусили б навіть лояльного фінансового директора нахмуритися. І зростання лінійне: подвоїте кількість користувачів, подвоїте рахунок. Немає економії масштабу у спожитих токенах, не для вас.

Існує також проблема, яка залишалася непоміченою у 2025 році, але стала центральною у 2026 році: кожен окремий запит надсилає фрагменти корпоративних документів — іноді конфіденційних, іноді захищених NDA, іноді підпорядкованих галузевим нормам — на сервери зовнішнього постачальника, в юрисдикції, які не завжди збігаються з вашою, з політиками зберігання журналів, які не завжди є прозорими. Більше однієї європейської компанії за останні вісімнадцять місяців виявила під час аудиту — зазвичай ініційованого занепокоєним клієнтом або перевіркою ISO — що їхні контракти, прайс-листи та технічні специфікації були оброблені (і потенційно залогіровані для "покращення послуги") інфраструктурою поза межами ЄС. Несподіванка, як правило, коштувала дорожче, ніж економія на локальному обладнанні, яке вони прагнули уникнути.

Альтернатива полягає не в протилежному догмі. "Хмара ні, локально так" є такою ж помилковою, як і "хмара завжди так". Альтернатива – це архітектура, яка дозволяє вам вибирати для кожної окремої частини конвеєра – вбудовування, класифікація, повторне ранжування, бачення, остаточна генерація – чи використовувати хмарну модель, чи локальну, і змінювати свою думку за день, а не за квартал. Це вимагає проєкту, в якому постачальники є взаємозамінними, де жодна частина не прикута до назви конкретної компанії, де перехід від Regolo до Ollama (або навпаки) є рядком конфігурації, а не переписуванням. І це, донедавна, було рідкістю. Популярні фреймворки, незважаючи на фасад "незалежності від постачальника", насправді були тісно пов'язані з кимось.