Міграція з API на власну модель AI: коли і як

Компанія SaaS із 40 000 активних користувачів отримує рахунок за API LLM, що перевищує 30 000 злотих на місяць. Юридичний відділ сигналізує, що дані, які обробляються зовнішнім API, потребують аудиту згідно з RODO. CTO запитує: чи не дешевше було б запустити власну модель? Це питання, яке у 2026 році ми чуємо щотижня. Відповідь не проста — але її можна порахувати.

Нижче описано, як виглядає така міграція з точки зору рішень, архітектури та ризиків. Без обіцянок «після міграції заощадите X%». З конкретними порогами, типовими пастками та тим, що насправді потрібно перепроєктувати.

Міграція на власну модель — це інфраструктурний проєкт, а не оптимізація. Перед ухваленням рішення варто поставити чотири питання:

Чи є вартість токенів домінуючою витратою? Зовнішнє API розраховує кожен запит. При великому обсязі це десятки тисяч злотих на місяць. Але якщо генеративний AI — це маргінальний елемент продукту (наприклад, кількасот запитів на день), операційні витрати на сервер власної моделі легко перевищать економію на токенах.

Чи дані не можуть залишати інфраструктуру? Медичні, фінансові, юридичні, кадрові дані — усі категорії, що потребують особливого захисту згідно з RODO або професійною таємницею, свідчать на користь self-hosting навіть при низькому обсязі. Тут рішення є юридичним, а не лише економічним.

Чи достатньо загальної моделі, чи потрібна спеціалізація? Власна модель, розгорнута прямо з репозиторію (наприклад, Mistral, Llama, Qwen), все ще залишається загальною моделлю. Якщо завдання потребує знання вашої домену, самої міграції недостатньо — потрібен fine-tuning або архітектура RAG на вашій базі знань.

Чи маєте компетенції для підтримки інфраструктури? Власна модель — це сервер, моніторинг, оновлення безпеки та реагування на збої. API-first знімає цей тягар з вашої команди. Якщо у вас немає досвіду роботи з GPU infrastructure, міграція без зовнішньої підтримки є операційним ризиком.

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

Розгортання open-weight з hugging face / репозиторію. Ви завантажуєте ваги моделі (Mistral, Llama 3, Qwen 2.5, Gemma) та запускаєте на власному GPU через Ollama, vLLM або llama.cpp. Модель є публічно доступною, але інференс відбувається на вашій інфраструктурі. Жодні дані не виходять назовні.

Fine-tuning на ваших даних. Ви берете open-weight модель і налаштовуєте її на вашому наборі даних (QLoRA, LoRA). Результат: модель, яка знає ваш стиль, термінологію та формат відповідей. Коли це має сенс і коли замість цього достатньо RAG, описано в статті коли fine-tuning має сенс.

Дистиляція з великої моделі до малої. Ви генеруєте синтетичні тренувальні дані з великої моделі (API) і тренуєте меншу модель на цих даних. Результат: компактна спеціалізована модель, недорога в обслуговуванні. Вимагає ретельного проєктування набору даних та валідації якості.

У кожному випадку це не «заміна URL», а зміна архітектури. Router, guardrails, формат промптів, обробка помилок, моніторинг — усе має бути адаптовано до нових характеристик моделі.

Зовнішнє API та локальна модель — це не той самий інтерфейс з іншою адресою. Відмінності є фундаментальними:

Детермінізм та версіонування. API може змінити поведінку моделі без попередження (оновлення бекенду). Локальна модель має фіксовані ваги — поведінка стабільна до моменту, поки ви самі не зміните версію. Для продакшн-систем це суттєва різниця: клієнт помітить, якщо асистент почав відповідати інакше.

Затримка та пропускна здатність. Зовнішнє API має мережеву затримку та ділить пропускну здатність між клієнтами. Локальна модель має затримку inference, що залежить від GPU, і є виділеною для вашого трафіку. При низькому трафіку API швидше. При великому, сконцентрованому трафіку власна модель виграє за затримкою.

Контекстне вікно та пам'ять. Великі моделі в API пропонують контекстні вікна до 128K–200K токенів. Open-weight моделі мають різні обмеження (зазвичай 8K–128K залежно від версії). Якщо ваша система покладається на дуже довгі контексти, перевірте обмеження конкретної моделі перед міграцією.

Формат відповіді та structured output. Зовнішнє API часто пропонує нативне примусове форматування JSON. У випадку локальної моделі вам потрібно реалізувати це на стороні застосунку: парсер з виправленням, валідація схемою, повторні спроби при помилці структури.

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

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

Роутер моделей. Зовнішнє API — це зазвичай одна модель. Після міграції на self-hosting у вас є флот моделей різного розміру та вартості. Router LLM класифікує запити за складністю та направляє прості запити до малої моделі (швидкої та дешевої), а складні — до великої. Без роутера ви втрачаєте економію масштабу власної інфраструктури.

Guardrails та фільтрація. Зовнішнє API має вбудоване модерування контенту. Локальна модель його не має. Guardrails потрібно реалізувати самостійно: фільтрація вхідних даних (injection, prompt attack, конфіденційні дані), фільтрація вихідних даних (PII у відповіді, тематичний діапазон), пастки для ескалації до людини. Без цього шару локальна модель менш безпечна, ніж API.

PII та маскування. Парадокс: власна модель обробляє дані локально, тому ризик передачі даних назовні відсутній. Але це не звільняє від обов'язку маскування персональних даних перед моделлю — відповідно до принципу мінімізації даних з RODO. Дані мають надходити до моделі з замаскованими ідентифікаторами та розкриватися лише у відповіді.

Observability та моніторинг. Зовнішнє API логує запити та метрики на своїй стороні — часто невидимі для вас. Власна модель потребує власного стеку observability: логи запитів (без PII), метрики продуктивності, алерти на дрейф якості. Детальніше про те, що і як вимірювати, у статті про моніторинг якості агента AI.

Fallback та деградація. API має резервування на стороні постачальника. Власна інфраструктура потребує планування fallback: що відбувається, коли GPU недоступний? Сервіс має деградувати gracefully — переключитися на меншу модель або повідомити користувача про недоступність, замість того, щоб мовчати.

Практичний графік для компанії, що мігрує з зовнішнього API на self-hosting:

Крок 1: Аудит поточного використання (тиждень 1). Зберіть логи з API: розподіл довжини промптів, розподіл довжини відповідей, типи завдань (класифікація, генерація, екстракція, резюмування), розподіл помилок. Це вхідні дані для вибору моделі. Використайте калькулятор ROI для попереднього аналізу доцільності.

Крок 2: Вибір та бенчмарк моделі (тиждень 1–2). Оберіть 2–3 open-weight моделі-кандидати відповідного розміру для ваших завдань. Запустіть бенчмарк на наборі 50–100 реальних запитів з продакшену. Вимірюйте: якість відповідей, затримку, відсоток коректних structured outputs. Не конфігуруйте на основі загальних бенчмарків — вимірюйте на ваших даних.

Крок 3: Підготовка інфраструктури (тиждень 2–3). Сервер з GPU, конфігурація Ollama або vLLM, мережа, бекап. Детальний вибір обладнання описано в статті про локальні LLM та GPU. На цьому етапі також впроваджуйте роутер, guardrails та шар observability.

Крок 4: Пілот паралельно — shadow mode (тиждень 3–4). Протягом щонайменше тижня направляйте трафік паралельно до API та до власної моделі. Порівнюйте відповіді. Не вимикайте API — воно є fallback. Shadow mode виявляє відмінності в якості, які бенчмарк пропускає.

Крок 5: Поетапне перемикання трафіку (тиждень 4–6). 10% трафіку на власну модель, моніторинг, 25%, моніторинг, 50%, моніторинг, 100%. На кожному етапі зупиняйтеся на 48 годин і перевіряйте метрики: error rate, затримка, оцінки якості (якщо є feedback loop).

Крок 6: Вимкнення API (після тижня 6+). Тільки після того, як shadow mode та ramp-up підтвердять стабільність. Збережіть доступ до API як emergency fallback на наступні 30 днів.

Міграція на self-hosting має приховані витрати, які не видно в порівнянні «вартість токенів vs. вартість сервера»:

Вартість людей. Інфраструктура GPU потребує обслуговування. Оновлення, моніторинг, інциденти, ротація моделей після депрекації версій. Зазвичай це 0,2–0,5 ставки інженера. Для невеликої команди це домінуюча витрата.

Вартість запуску. Обладнання (GPU сервер) — це разовий видаток або лізинг. Амортизація 3–4 роки при витратах від 15 000 до 60 000 злотих (залежно від GPU) має бути врахована в розрахунках. Перед ухваленням рішення порахуйте це в калькуляторі inference.

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

Ризик AI Act. Системи AI, класифіковані як високого ризику, потребують технічної документації, реєстру системи та відповідності вимогам прозорості. Self-hosting не звільняє від цих обов'язків — навпаки, збільшує обсяг вашої відповідальності як деплоєра. Перш ніж переходити на власну модель у high-risk системах, проконсультуйте DPIA та технічну документацію з юристом.

Міграція з API на власну модель — це рішення, яке обґрунтовується цифрами, а не інтуїцією. Точку входу описано в статті про з-чого-почати-впровадження-AI — там пояснюється, як правильно сформулювати питання перед вибором інструменту.

Опишіть свій поточний стек (модель, обсяг, тип завдань), і модель покаже вам пороги міграції та скелет архітектури self-hosted з роутером та guardrails — як відправну точку, а не готовий проєкт (playground: PII маскуються, нульова ретенція):

Поріг доцільності залежить від обраної моделі та довжини контексту. Орієнтовно: при коротких промптах та відповідях (клас 200–500 токенів) поріг становить 50 000–80 000 запитів на місяць. При довгих контекстах (RAG, резюмування документів) поріг знижується до 20 000–40 000 запитів, оскільки вартість токенів зростає нелінійно. Порахуйте це конкретно в калькуляторі ROI перед ухваленням рішення.

Self-hosting усуває передачу даних зовнішньому постачальнику, що спрощує комплаєнс — не потрібно укладати DPA з постачальником API чи турбуватися про data-residency. Але RODO все одно діє: принцип мінімізації даних, маскування PII перед моделлю, логи без персональних даних, право на видалення даних з історії розмов. Власна модель не є автоматично відповідною до RODO — вона потребує тих самих механізмів, тільки за іншою адресою.

У 2026 році провідні open-weight моделі (Llama 3.3 70B, Qwen 2.5 72B, Mistral Large) досягають порівнянної якості з GPT-4-class на більшості бізнес-завдань: класифікація, екстракція, резюмування, генерація структурованого тексту. Різниця помітна при завданнях, що потребують складного багатоетапного міркування та знань про дуже актуальні події. Для більшості корпоративних систем ця різниця є прийнятною або несуттєвою. Перевірте це бенчмарком на ваших власних даних.

Промпти, написані під конкретну модель API, не є переносимими один до одного. Open-weight моделі мають різні chat templates і реагують інакше на системні інструкції. Зазвичай достатньо кількох ітерацій: адаптація формату (ролі system/user/assistant), видалення інструкцій, які модель ігнорує, додавання прикладів (few-shot) у місцях, де модель API їх не потребувала. Допомагає також structured output з валідацією схеми замість покладання на стандартний формат відповіді.

Так, і часто це найпростіша міграція. В архітектурі RAG модель є лише генератором відповідей на основі отриманих фрагментів — якість результатів більше залежить від якості індексу та ембедінгів, ніж від розміру моделі. Менша, локальна модель (7B–13B) добре справляється з цим завданням, а ембедінги — як BGE-M3 — працюють виключно локально за своєю природою. Вартість токенів для RAG висока (довгий контекст з фрагментами), тому поріг доцільності self-hosting тут нижчий, ніж для генерації без контексту.