Власний GPU-сервер чи хмарний API: як порахувати повну вартість

Коротка відповідь: власний сервер із відеокартами може бути виправданим, якщо у вас стабільне високе навантаження, вимоги до розміщення даних, які не дозволяють користуватися зовнішнім API, або специфічний сценарій, під який підходить конкретна відкрита модель. Хмарний API найчастіше простіший для старту і вигідніший при нерівномірному чи невеликому навантаженні. Але порівняння за ціною має сенс лише тоді, коли обидва варіанти дають однакову якість відповідей, витримують ваше пікове навантаження і забезпечують потрібну доступність.

Тобто правильне питання не «що дешевше — відеокарта чи мільйон токенів», а «скільки коштує успішно оброблений запит потрібної якості в кожному варіанті при нашому навантаженні». Після прочитання ви зможете перелічити обмеження, які звужують вибір ще до розрахунку, зібрати повну вартість обох варіантів, знайти межу окупності як діапазон і оцінити гібридну схему.

Спочатку обмеження, потім ціна

Перш ніж рахувати гроші, з’ясуйте, які варіанти взагалі допустимі. Часто частина з них відпадає без жодних розрахунків.

• Дані. Чи можна за договорами, внутрішніми правилами і законодавством передавати ці дані зовнішньому постачальнику? В якій юрисдикції вони мають оброблятися? Якщо відповідь «ні», API відпадає для цих даних незалежно від ціни.
• Ліцензія моделі. Чи дозволяє ліцензія відкритої моделі комерційне використання у вашому сценарії. Наприклад, Qwen3-8B поширюється за ліцензією Apache 2.0, але в інших моделей умови можуть бути суттєво суворішими.
• Мови. Чи справляється модель із вашими мовами на потрібному рівні. Заявлена підтримка понад сотні мов не гарантує якості саме на українських договорах чи листах клієнтів.
• Якість. Яка частка правильних відповідей потрібна і що станеться при помилці.
• Пікове навантаження. Скільки запитів може прийти одночасно в найгірший момент і яка затримка при цьому допустима.
• Допустимий простій. Що буде, якщо сервіс недоступний годину, день, тиждень. Від цього залежить, чи потрібен резервний сервер.

Корисно розділити дані за рівнями чутливості, а не приймати одне рішення для всього. Публічні описи товарів і загальні питання клієнтів можуть мати одні правила, персональні дані і фінансові документи — інші. Тоді може виявитися, що обмеження стосуються лише частини потоку, і вибір між сервером та API потрібно робити окремо для кожної частини. Це прямо впливає на розрахунок: якщо локально має оброблятися лише невелика частка запитів, власний сервер може виявитися дорогим рішенням для малого обсягу.

Записані обмеження стають критеріями, за якими потім перевіряють обидва варіанти.

Що входить у локальну вартість

Ціна відеокарт — лише одна з багатьох статей. Повна вартість володіння власним сервером включає:

• Обладнання: відеокарти, сервер, процесор, оперативна пам’ять, диски, мережеве обладнання, блок живлення відповідної потужності.
• Амортизацію: вартість обладнання, розподілена на строк корисного використання. Відеокарти для ШІ швидко застарівають морально, тому строк амортизації варто обирати консервативно.
• Розміщення: стійка в дата-центрі або серверна кімната з охолодженням, захистом і стабільним живленням.
• Електроенергію: споживання відеокарт під навантаженням, охолодження, джерело безперебійного живлення.
• Мережу: канал, публічні адреси, захист від атак, якщо сервіс доступний ззовні.
• Резерв: другий сервер або запасний канал на випадок збою, якщо простій неприпустимий.
• Експлуатацію: інженер, який встановлює драйвери, оновлює систему, стежить за станом, реагує на збої. Навіть якщо це частина ставки наявного співробітника, його час — витрати.
• Оновлення моделей: тестування нових версій, перевірка якості, перехід.
• Залишкову вартість: за скільки можна буде продати обладнання через кілька років. Вона зменшує витрати, але оцінювати її треба обережно.

Що входить в API

Рахунок за API здається простим — токени. Але й тут повна вартість ширша:

• Токени вхідні і вихідні, з урахуванням режиму обслуговування і довжини контексту.
• Додаткові інструменти: пошук, обробка файлів, embedding, якщо вони тарифікуються окремо.
• Зберігання: файли, векторні бази, журнали, якщо вони на боці постачальника.
• Інтеграції: розробка і підтримка з’єднання з вашими системами.
• Підтримка: реакція на зміни API, перехід на нові версії моделей, коли старі виводяться з обігу.
• Контроль: моніторинг витрат, лімітів, якості відповідей, юридична перевірка умов обробки даних.

Щоб порівняння було чесним, обидва варіанти зручно звести в одну таблицю з однаковими рядками. Порожня клітинка в такій таблиці — сигнал, що статтю ще не оцінено, а не що вона безкоштовна.

Різниця в тому, що в API більшість витрат змінні — ростуть разом із кількістю запитів, — а у власного сервера більшість витрат постійні: платите однаково при одному запиті і при мільйоні, доки сервер справляється.

Чому 2–4 GPU — не готова специфікація

Формулювання «сервер на 2–4 RTX 4090 або A100» звучить як специфікація, але насправді це дуже різні конфігурації.

Різні класи обладнання. RTX 4090 — споживча відеокарта з 24 ГБ пам’яті GDDR6X, потужністю 450 Вт і рекомендованою потужністю системи 850 Вт; NVLink для об’єднання кількох карт вона не підтримує. A100 — серверний прискорювач: у версії на 80 ГБ — пам’ять HBM2e із пропускною здатністю близько 2 ТБ/с, максимальне енергоспоживання 300 Вт для PCIe і 400 Вт для SXM, NVLink до 600 ГБ/с, можливість поділу на кілька ізольованих екземплярів. Обидві назви з’являються в одному питанні, але порівнювати їх «за кількістю карт» некоректно.

Пам’ять: не лише ваги моделі. Модель має поміститися в пам’ять, але цього недостатньо. Навчальний розрахунок: Qwen3-8B має 8,2 мільярда параметрів; у форматі BF16 кожен параметр займає 2 байти, тож лише ваги — приблизно 16,4 ГБ. На карті з 24 ГБ залишається близько 7–8 ГБ на все інше, включно з KV cache — пам’яттю, де модель зберігає проміжні дані про вже оброблені токени кожного запиту. Що довший контекст і що більше одночасних запитів, то більше потрібно KV cache. Фрагментація та зайве дублювання проміжної пам’яті можуть зменшувати кількість запитів, які система обробляє одночасно. Сучасні засоби обслуговування моделей використовують різні підходи до ефективнішого керування KV cache, але їхній ефект залежить від конкретної моделі, апаратної конфігурації, контексту, конкурентності та цільової затримки. Тому рекламний або тестовий приріст не можна переносити на ваш сценарій без власного вимірювання.

Висновок: продуктивність вимірюється, а не виводиться з назви карти. Скільки користувачів обслужить сервер, залежить від моделі, довжини контексту, кількості одночасних запитів, програмного забезпечення для обслуговування і цільової затримки. Інструменти навантажувального тестування, вимірюють час до першого токена, інтервал між токенами і загальну пропускну здатність при заданій інтенсивності запитів, їхній нерівномірності і максимальній кількості одночасних з’єднань. Саме такі вимірювання на вашому профілі запитів дають відповідь, а не назва відеокарти.

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

Як знайти межу окупності

Принцип: розділити постійні і змінні витрати, а потім знайти обсяг, за якого вони зрівнюються.

місячні постійні витрати власного сервера ÷ (вартість одного успішного запиту через API − змінна локальна вартість такого запиту) = обсяг рівноваги

Формула має сенс лише тоді, коли різниця в дужках додатна. У прикладі нижче для простоти змінну локальну вартість умовно вважаємо нульовою: електроенергію і підтримку включено до місячної суми. Для реального рішення їхню залежність від навантаження потрібно виміряти окремо.

Навчальний розрахунок

Усі числа нижче — навчальні, а не ціни обладнання чи виміряна продуктивність реального сервера.

• Обладнання: $12 000 на 36 місяців = $333,33 на місяць.
• Умовні електроенергія, розміщення і підтримка: $450 на місяць.
• Разом: $783,33 на місяць — без резерву, податків і залишкової вартості.
• Умовна вартість одного успішного запиту через API порівнянної якості: $0,02.
• Формальна межа: $783,33 ÷ $0,02 ≈ 39 167 запитів на місяць, або близько 1 300 на день.

Тепер чутливість — ось чому межу варто показувати діапазоном:

Окремо про піки. Межу рахують від місячного обсягу, але сервер доводиться розраховувати на найнавантаженіший момент. Якщо більшість запитів приходить у робочі години, а вночі і у вихідні сервер майже простоює, ви платите за потужність, яка використовується лише частину часу. API в такій ситуації масштабується разом із навантаженням у межах лімітів вашого облікового запису. І навпаки, рівномірний цілодобовий потік — наприклад, нічна обробка документів плюс денні запити — краще завантажує власне обладнання.

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

Модель, яку можна запустити локально, не стає автоматично еквівалентом комерційного API. Те, що модель технічно можна розгорнути у вибраному програмному середовищі, підтверджує лише можливість запуску. Якщо локальна модель частіше помиляється, «успішний запит» на ній коштує дорожче, ніж здається, бо частина відповідей потребує повтору, ескалації чи ручного виправлення.

Гібридний варіант і рішення

Часто найрозумніший варіант — не «або-або». Гібридна схема: частий, добре описаний і дозволений клас задач обробляється локальною моделлю, а складні чи рідкісні задачі — через відповідний API або людиною.

Приклад розподілу: класифікація вхідних звернень і вилучення полів зі стандартних документів — локально, бо це великий стабільний потік і короткий контекст; складні відповіді клієнтам — через API сильнішої моделі. Обмеження щодо даних можуть звузити цей варіант: якщо дані не можна передавати назовні взагалі, «складні задачі через API» відпадають, і доведеться або підбирати сильнішу локальну модель, або залишати такі задачі людям.

Гібрид теж треба рахувати, бо він не завжди дешевший. Продовжимо навчальний приклад: постійні витрати сервера — $783,33, вартість успішного запиту через API — $0,02, локально обробляється 70% потоку.

• 50 000 запитів на місяць. Усе через API: 50 000 × $0,02 = $1 000. Гібрид: сервер $783,33 плюс 15 000 запитів через API × $0,02 = $300, разом $1 083,33 — дорожче.
• 100 000 запитів на місяць. Усе через API: $2 000. Гібрид: $783,33 плюс 30 000 × $0,02 = $600, разом $1 383,33 — дешевше.

Причина проста: гібрид вигідний лише тоді, коли та частина потоку, яку бере на себе локальний сервер, сама по собі перевищує межу окупності. У першому випадку локально обробляється 35 000 запитів — менше за 39 167, у другому — 70 000, більше.

Рішення можна ухвалювати за таким порядком:

• Обмеження даних забороняють API → локальний варіант або людина; рахувати повну вартість власного сервера з резервом.
• Навантаження невелике або нерівномірне → API, принаймні на старті; переглянути при зростанні.
• Стабільний великий потік однотипних задач і модель, що проходить контрольний набір → розглянути локальний сервер або гібрид, але лише після навантажувального тесту.
• Немає людей для експлуатації сервера → враховувати вартість підрядника або обирати API.

Підсумок і перші кроки

Власний GPU-сервер не дешевший і не дорожчий за API «взагалі». Він дешевший за певного навантаження, якості і повноти розрахунку — і цю точку можна знайти лише на своїх даних.

Що зробити:

1. Записати обмеження: дані, ліцензія, мови, якість, піки, допустимий простій.
2. Зібрати повну вартість обох варіантів, розділивши постійні і змінні витрати.
3. Підготувати контрольний набір задач і перевірити на ньому кандидатну локальну модель і API.
4. Провести навантажувальний тест кандидатної конфігурації на вашому профілі запитів.
5. Порахувати межу окупності кількома сценаріями: різні ціни API, з резервом і без.
6. Розглянути гібридну схему для частих дозволених задач.
7. Ухвалити рішення і записати, за яких змін його потрібно переглянути.

Вибір між сервером і API зазвичай упирається не в одну цифру, а в кілька невідомих: реальне навантаження, вимоги до даних і якість моделі на ваших задачах. Якщо хочете розібрати ці змінні для свого процесу і скласти модель витрат для обох варіантів, зверніться до BotLabs — обговоримо вихідні дані і те, що варто виміряти на пілоті.

Часті запитання