Як підібрати модель LLM під задачу: матриця розмір-витрати-затримка

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

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

• Розмір (якість) — більша модель краще справляється з неоднозначністю, багатоетапним міркуванням та довгим контекстом. Але «краще» не означає «потрібно краще» — для задачі, яка має одну правильну відповідь, надлишок потужності — це витрачений бюджет.
• Затримка — більша модель відповідає повільніше. У чаті наживо користувач відчуває кожну секунду; при пакетній обробці вночі затримка не має значення. Те, де працює задача, повністю змінює пріоритет цієї осі.
• Вартість інференсу — у хмарі зростає з кількістю токенів входу та виходу та класом моделі; при self-hostingu це амортизація обладнання, розподілена на обсяг. Маленька модель — це часто різниця на порядок у рахунку за одиницю.

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

Більшість бізнес-задач вкладається в кілька архетипів. Наведена нижче матриця — це відправна точка, а не догма — пороги залежать від ваших даних та необхідної точності. Діапазони вартості відносні (маленька модель = база 1×):

Практичне спостереження з впроваджень: перші два рядки — екстракція та класифікація — це часто 60–80% усіх викликів у типовий системі. Якщо все йде через велику модель, більша частина рахунку фінансує роботу, яка не потребує такої потужності.

Маленьку модель часто сприймають як гірший вибір «на бідність». Це непорозуміння. Маленька модель є правильним вибором, коли задача має вузько визначену мету та перевіряється результат:

• Результат має перевіряєму структуру. Якщо очікуємо JSON з відомою схемою, structured output плюс валідація ловить помилки незалежно від розміру моделі. Маленька модель + валідатор + одна корекція дає результат дешевший і часто такий же надійний, як велика модель без валідації.
• Домен вузький. Класифікація звернень до 8 категорій не вимагає знань про світ — потрібне розрізнення 8 патернів. Маленька модель, налаштована промптом, робить це чудово. Детальніше в статті про класифікацію та маршрутизацію звернень.
• Задача повторювана та пакетна. Обробка 50 тисяч записів маленькою моделлю замість великої — це різниця між рахунком, який можна прийняти, і таким, що вбиває проект.

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

Це питання економіки та даних, а не ідеології. Обидва варіанти мають сенс — за різних умов:

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

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

Замість жорсткого призначення моделі, всі виклики проходять через один роутер LLM. Це єдина точка входу до шару моделей, яка для кожного завдання вирішує, куди його направити — і дає три речі одночасно:

1. Підбір моделі під задачу. Класифікація йде до маленької моделі, аналіз договору — до великої. Рішення декларативне (матриця задача→модель), а не розпорошене по коду.
2. Фолбек та деградація. Коли цільова модель недоступна або перевантажена, роутер перемикається на резервну модель замість повертати помилку користувачеві.
3. Телеметрія та контроль витрат. Оскільки все проходить через одну точку, вимірюємо вартість та затримку на задачу, бачимо, куди реально йдуть гроші, і можемо встановлювати бюджети та ліміти перевантаження.

Роутер — це також природне місце для маскування персональних даних перед хмарою та для дотримання правила «structured output завжди валідований». Без цього шару кожна зміна моделі — це переписування коду в багатьох місцях; з ним — зміна одного правила. Саме тому роутер — це перше, що ставимо в кожній системі на базі кількох моделей, а не доповнення наприкінці.

Простіше на старті, дорожче в масштабі. Одна велика модель для кожної операції дає рахунок, що зростає лінійно з трафіком, та вищі затримки там, де вони не потрібні. Роутер, що підбирає модель під задачу, — це зазвичай найбільша окрема економія, бо переносить 60–80% викликів на модель на порядок дешевшу.

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

Ні. При малому або змінному обсязі хмара дешевша, бо немає вартості входу — обладнання для self-hosting має амортизуватися на трафіку. Self-hosting виграє при сталому великому навантаженні або коли дані не можуть залишати компанію. Точку перетину рахуємо на реальному обсязі, а не на максимальному обладнанні.

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

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