Суперечка «локально чи хмара» рідко має одну відповідь, бо це не вибір технології, а профіль витрат. Хмара — це змінні витрати (OPEX), що зростають з навантаженням. Self-hosting — це здебільшого постійні витрати (CAPEX + обслуговування), майже незалежні від навантаження. Яка структура дешевша, залежить від того, скільки ти насправді використовуєш.
Два профілі витрат#
| Локально (self-hosted) | API у хмарі | |
|---|---|---|
| Вхідні витрати | Високі (обладнання, впровадження) | Майже нульові (ключ API) |
| Вартість одиниці | Низька, передбачувана | Змінна, зростає з навантаженням |
| Масштабування витрат | Плоске до ліміту обладнання | Лінійне з обсягом |
| Приватність даних | Дані залишаються у тебе | Дані передаються постачальнику |
| Найкраще при | Постійному, великому обсязі | Малому, нерегулярному навантаженні |
Як розрахувати точку перетину#
Розрахуй місячну вартість хмари (кількість запитів × вартість одного виклику) і порівняй її з місячною амортизацією власної інфраструктури (обладнання, розподілене в часі + електроенергія + обслуговування). Обсяг, при якому ці дві цифри зрівнюються, — це твоя точка перетину. Нижче залишайся в хмарі; вище self-hosting починає економити.
Порахуймо це на прикладі (ціни орієнтовні, звіряй з актуальним прайсом — тарифи API та обладнання змінюються швидко). Припустимо типове завдання: ~1 тис. токенів входу + ~0,5 тис. токенів виходу. За моделі середнього класу (порядок величини ~0,30 USD за 1 млн токенів входу і ~1,20 USD за 1 млн виходу) один виклик коштує ~0,0009 USD. З боку self-hosting візьми box з GPU, розподілений на 36 місяців, плюс електроенергія та обслуговування — реально це вкладається у вилку ~600–1200 USD на місяць, залежно від класу карти і того, чи обладнання ділиться з іншими завданнями.
| Обсяг / міс. | Вартість хмари (орієнтовно) | Вартість self-host (вилка) |
|---|---|---|
| 0,5 млн викликів | ~450 USD | ~600–1200 USD |
| 2 млн викликів | ~1800 USD | ~600–1200 USD |
| 5 млн викликів | ~4500 USD | ~600–1200 USD |
У цьому сценарії лінії перетинаються десь між 0,5 та 2 млн викликів на місяць — вище цього порогу постійна вартість обладнання починає окупатися. Це лише ілюстрація одного профілю: довші промпти, RAG і дорожчі моделі зсувають поріг униз (хмара дорожчає швидше), а дешевші завдання — вгору. Порахуй власний поріг у калькуляторі вартості інференсу — а коли твій обсяг його перевищить, наступним кроком є міграція з API на власну модель, яка квантифікує ту саму точку перетину на практиці.
Чому гібридна модель зазвичай перемагає#
Рідко все буває «малим» або «великим». Постійні, високооб’ємні завдання (класифікація, ембедінги, семантичний пошук на BGE-M3) дешево обробиш локально. Рідкісні, складні запити зручно купувати в хмарі. Роутер направляє кожне завдання туди, де воно найдешевше та найбезпечніше — і саме він, обираючи модель під завдання, є найбільшим важелем зниження витрат, незалежно від вибору локально/хмара.
Вартість — це не лише рахунок#
У розрахунках враховуй також ризик vendor lock-in (зміна цін постачальника), витрати на обслуговування (повний TCO: моніторинг, оновлення, чергування) та витрати на відповідність вимогам (персональні дані, що передаються в хмару, — це додаткові зобов’язання, див. self-hosted LLM та GDPR). Передбачуваність часто коштує більше, ніж кілька відсотків у рахунку.
FAQ#
Коли власна модель дешевша за API?#
Коли маєш постійний, великий обсяг. Високі вхідні витрати розподіляються на багато запитів, і вартість одиниці падає нижче ціни хмари. При малому або нерегулярному навантаженні API залишається дешевшим.
Чи потрібно обирати одне чи інше?#
Ні. Найчастіше оптимальною є гібридна модель: локально обробляєш дешеві, високооб’ємні завдання, а хмару резервуєш для рідкісних, складних запитів. Роутер з’єднує це в один потік.
Що найбільше знижує рахунок за LLM?#
Вибір моделі під завдання. Направлення простих запитів на малу, дешеву модель і резервування великої лише там, де потрібно, зазвичай дає більшу економію, ніж сам вибір локально vs хмара. Одразу за цим іде оптимізація вартості токенів — коротші промпти, кешування і контроль довжини контексту.