Малий спеціалізований модель AI vs великий LLM

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

У цій статті систематизовано вибір. Тут немає однієї правильної відповіді. Але є рамка, завдяки якій ви ухвалите рішення на основі даних, а не передчуття.

Параметри моделі — це лише одна вісь. У 2026 році межі змістилися: модель 7B після агресивної квантизації Q4 вміщається в 4–5 ГБ VRAM і працює на ноутбуці. Модель 70B, квантизована до Q4, потребує ~40 ГБ VRAM. Модель класу GPT-4 — це сотні мільярдів параметрів, доступна виключно через хмарне API.

Важливішою за кількість параметрів є щільність спеціалізації: скільки доменних даних, якої якості та якою технікою увійшло у ваги. Модель 7B після якісного fine-tuningu на спеціалізованому медичному корпусі може перевершити загальну модель 70B у завданнях клінічної класифікації. Але не перевершить її у вільному міркуванні поза доменом.

Три виміри, які насправді визначають вибір:

• Вартість на токен: менша модель на власній інфраструктурі коштує частку вартості API великої хмарної моделі.
• Латентність: модель 7B відповідає в 3–10 разів швидше, ніж 70B на тому ж апаратному рівні.
• Якість на завданні: залежить від ступеня спеціалізації, а не від розміру параметрів як такого.

Вузькі, повторювані виробничі завдання. Класифікація намірів у обслуговуванні клієнтів, тегування документів, OCR post-processing, анонімізація PII: це завдання з обмеженим простором виходів. Модель 7B, натренована на ваших даних і ваших мітках, досягне F1 > 0,90 на цих завданнях, де загальна модель 70B досягне 0,85 при п’ятикратно вищій вартості.

Високий обсяг викликів. Коли система виконує 500 000 викликів на місяць на одному завданні, різниця у вартості на токен стає бюджетною лінією, а не абстракцією. Малий модель self-hosted на власному GPU окупається за кілька місяців. Порахуйте свій випадок у калькуляторі інференсу.

Вимоги data-residency та регуляції. AI Act, RODO та секторальні банківські регуляції часто вимагають, щоб дані не залишали ЄС або внутрішньої інфраструктури компанії. Малий модель self-hosted задовольняє цю вимогу структурно. Великі хмарні моделі потребують детальних угод DPA з постачальником та аудиту потоків даних.

Детерміновані вимоги до формату. Коли вихід має мати чітко визначену структуру (наприклад, JSON Schema, XML для ERP-системи) і модель має її підтримувати протягом десятків тисяч викликів, малий модель після fine-tuningu з structured output є більш передбачуваним, ніж велика загальна модель з промптом.

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

Багатоетапне міркування та агенти. Завдання, що потребують планування, декомпозиції на підзавдання, використання інструментів (tool-use) та оцінки власних результатів: тут великі моделі мають суттєву перевагу. Моделі 7B–13B у режимі агента часто втрачають контекст після кількох кроків або генерують некоректні виклики інструментів.

Багатомовність без додаткового тренування. Загальна модель класу 70B+ підтримує десятки мов з високою якістю. Малий модель, натренований на польських даних, обслуговуватиме польську добре, але англійську, німецьку та українську — вже не на тому ж рівні. Перевірте шаблон з багатомовним асистентом AI.

Швидкий старт без тренувальних даних. Пілот можна запустити за тижні з великою моделлю через RAG та промпт. Малий спеціалізований модель потребує збору даних, тренування та оцінки. Що це означає на практиці, описує стаття коли fine-tuning має сенс.

Більшості компаній не слід обирати один розмір моделі. Шаблон маршрутизатора моделей дозволяє спрямовувати трафік до відповідної моделі на основі складності запиту:

1. Класифікатор попередній оцінює запит: просте питання з каталогу FAQ, запит, що потребує міркування, чи запит поза доменом.
2. Простий, дешевий модель обслуговує повторювані запити (класифікація, екстракція даних, просте FAQ).
3. Великий модель отримує лише ті запити, які цього справді потребують: багатоетапне міркування, невідомі теми, ескалації.

Ефект: 60–80% трафіку потрапляє до дешевого моделі, а якість на складних запитах не знижується. Загальна вартість становить частку вартості спрямування всього до великого моделі.

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

Малі спеціалізовані моделі мають інші профілі ризику, ніж великі загальні моделі. Кілька фактів, які варто знати перед впровадженням:

Малий модель після агресивного fine-tuningu може бути менш стійким до prompt injection, ніж великий загальний модель, який бачив тисячі прикладів атак під час pretrainingu. Guardrails на стороні застосунку (фільтр входу, фільтр виходу, human-gate для незворотних дій) є обов’язковими незалежно від розміру моделі.

Малий модель може не розуміти команду «не знаю» так само добре, як великий. Якщо задано питання поза доменом тренування, модель може генерувати відповідь, що звучить переконливо, але є некоректною. Слід реалізувати human-handoff: коли впевненість відповіді падає нижче порогу, система ескалує до людини замість галюцинацій.

Для систем високого ризику згідно з AI Act (Додаток III: рекрутинг, кредитний скоринг, критична інфраструктура) потрібна документація моделі, обґрунтованість рішень та аудиторський слід, незалежно від розміру. Малі моделі не звільняють від цих обов’язків; іноді їх складніше виконати, якщо документація оригінальної базової моделі є менш детальною, ніж для великих хмарних моделей.

Малі моделі self-hosted мають природну регуляторну перевагу: дані не залишають вашої інфраструктури. Але self-hosting — це не лише сервер. Вимоги:

• Керування версіями моделі: кожен чекпоінт із міткою тренувальних даних та результатів оцінки.
• Шифрування в спокої та в транзиті: ваги моделі — це активи компанії, ставтеся до них як до вихідного коду.
• Аудит доступу: хто і коли запускав інференс, з якими вхідними даними.
• План оновлень: малий модель дрейфує відносно зростаючої бази фактів; встановіть політику перетренування або доповнення RAG.

Якщо вхідні дані містять персональні дані, виконайте DPIA перед впровадженням. Це стосується і малих моделей, що працюють локально. Той факт, що дані не виходять назовні, не звільняє від обов’язку оцінки ризиків.

Перед ухваленням рішення дайте відповідь на п’ять запитань:

1. Наскільки вузьке завдання? Одне завдання, узгоджений вихід: малий модель. Багато різних завдань: великий модель або маршрутизатор.

2. Який місячний обсяг викликів? Менше 50 000 викликів на місяць — різниця у вартості відносно невелика. Понад 200 000 — малий модель self-hosted починає окупатися фінансово.

3. Чи є у вас тренувальні дані? Без щонайменше 500 якісних пар вхід-вихід малий модель не розкриє потенціалу. Перевірте це в оцінці готовності.

4. Які вимоги до латентності? Голосова взаємодія або чат у реальному часі потребують < 500 мс. Обробка документів у фоновому режимі допускає 3–10 секунд.

5. Які регуляторні вимоги? Data-residency, AI Act high-risk, RODO: попередній аналіз цих вимог часто вирішує вибір швидше, ніж технічні метрики.

Шаблон відповіді на ці запитання знайдете у blueprint агента або обговоріть свій випадок через контакт.

Опишіть свій випадок використання. Модель оцінить, чи малий спеціалізований модель, великий загальний, чи маршрутизатор є правильним вибором (playground: PII масковані, нульове зберігання):

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

Модель 7B, квантизована до Q4, потребує 4–6 ГБ VRAM і працює на споживчій відеокарті RTX 3090 або RTX 4090. Модель 13B, квантизована, потребує 8–10 ГБ VRAM. Це робить self-hosting малих моделей фінансово доступним для середніх компаній. Детальні огляди обладнання містить стаття локальні LLM: яке обладнання та GPU.

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

Додайте guardrail на вході: класифікатор оцінює, чи запит належить до домену. Якщо ні — спрямовує до великого моделі або повертає повідомлення про відсутність компетенції та ескалує до людини (human-handoff). Ніколи не покладайтеся виключно на те, що модель «сама визнає, що не знає». Малі моделі не є надійними в цьому.

Почніть з пілота з великим моделлю через RAG — це тижні, а не місяці, і дозволяє зібрати реальні дані про обсяг, типи запитів та якість відповідей. Через 4–8 тижнів у вас будуть дані для рішення: чи трафік є достатньо однорідним, щоб виправдати малий модель, і чи обсяг виправдовує інвестиції в self-hosting. Інструмент калькулятор ROI дозволяє розрахувати сценарії перед стартом проєкту.