Як обрати модель ШІ під задачу: матриця, що не застаріє за квартал

Інженер у Сан-Франциско відкриває внутрішню вікі своєї команди й видаляє рядок. Рядок звучав так: «Стандартна модель для продакшну — GPT-5.4». Він написав його сам, чотири місяці тому, з тією ж упевненістю, з якою колись прибивав цвях у стіну. Тепер цей цвях стирчить у порожнечі: вийшла нова версія, з’явилася дешевша альтернатива на іншу задачу, маркетинг команди вже встиг надрукувати слайд із застарілою назвою. Він стирає рядок і на секунду застигає над курсором, який блимає в порожньому місці. Що написати замість назви?

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

За даними трекерів релізів, у 2023 році між випусками моделей від передових лабораторій минало в медіані 37,5 дня; до 2024-го інтервал стиснувся до 13,5 дня; у 2026-му за рік він упав до 11 днів — а якщо звести всі лабораторії в один потік, нова модель виходить приблизно кожні три дні (officechai.com). Подумайте про це з боку того інженера: документ, який він пише про «найкращу модель», застаріває швидше, ніж устигає пройти внутрішнє рев’ю. Він не пише інструкцію. Він пише некролог — наперед, для рядка, який сам щойно набрав.

Ця сцена не про вибір вендора. Вона про механізм когнітивної економії, який ми звемо алібі простоти: ми хапаємося за ім’я моделі, бо ім’я — це один токен пам’яті, а здатність — п’ять. Назва дає ілюзію, що рішення прийнято раз і назавжди. Але назва — це етикетка на банці, вміст якої перефасовують щокварталу. Розберу це через три оптики: оптику інженера, що платить за токени; оптику покупця, що тоне в брендах; і оптику архітектора, що будує систему на десять років. Теза-лезо: правильна одиниця вибору — не модель, а вісь здатності; рамка за осями переживе будь-який реліз, а рамка за іменами згниє до наступної п’ятниці.

Чому ім’я моделі — це здатність, що вже протухає

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

Механіка тут проста й безжальна. Лабораторія перенавчає модель, лишає ту саму назву або підвищує цифру на одиницю, і характеристики зсуваються: ціна падає, контекст росте, латентність змінюється, інструменти, яких учора не було, з’являються. Ваш документ «GPT-5.4 для всього» описує банку, вміст якої вже інший. А ваш конкурент, який записав «потрібна модель з сильним reasoning і латентністю до секунди», просто звіряє нові знімки з тими самими осями — і ніколи нічого не переписує.

Назвемо цю рамку прямо: Матриця п’яти осей. П’ять вимірів, уздовж яких будь-яка задача проєктується на будь-яку модель — reasoning (глибина міркування), context (обсяг пам’яті в одному запиті), latency (швидкість відповіді), cost (ціна за токен), tools (надійність виклику функцій). Ці п’ять осей не нові — вони фігурують у більшості серйозних селекційних фреймворків 2026 року як базові виміри оцінки (iternal.ai). Новим є дисциплінарне правило: спершу осі, потім імена. Спершу профіль задачі на п’яти шкалах, і лише потім — звірка, який знімок цьому профілю відповідає сьогодні.

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

Вісь reasoning: коли вам справді потрібен мозок, а не швидкий рот

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

Reasoning-моделі генерують внутрішні «токени мислення» перед тим, як видати видиму відповідь. Це дає глибину на складних задачах — багатокрокова математика, наукове міркування, аналіз коду — але платить за це часом. На бенчмарку швидкості reasoning-модель на найвищому рівні мислення показує час до першого токена близько 15 секунд (benchlm.ai), бо ці 15 секунд вона думає мовчки. Для аналітичного звіту, який читатимуть раз на тиждень, 15 секунд — це нічого. Для чат-бота, який відповідає клієнту в реальному часі, 15 секунд — це втрачений клієнт.

Оце і є сенс осі: reasoning — не «більше завжди краще». Це шкала, на якій ви ставите точку там, де задача справді вимагає глибини. Сортування тікетів за категоріями не вимагає reasoning взагалі. Доказ математичної леми вимагає його по максимуму. Між цими полюсами — весь ваш реальний продукт.

«Чи потрібен тут reasoning?» — питання, яке варто ставити до кожної задачі окремо, а не один раз до всього застосунку. Бо застосунок — це не одна задача. Це десяток задач із дуже різними профілями, які ви помилково обслуговуєте однією моделлю, бо так простіше тримати в голові одне ім’я.

Вісь cost: чому найдорожча — майже ніколи не найкраща під задачу

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

Подивіться на розкид цін. У 2026 році вартість мільйона вхідних токенів коливається від $0,10 у бюджетних моделей до $30 у флагманських reasoning-моделей — приблизно 300-кратний розрив у межах одного-єдиного провайдера (cloudzero.com). Перейдіть між провайдерами — і прірва ширшає: вихідні токени дешевої фронтир-моделі коштують близько $0,28 за мільйон проти $180 у флагмана, тобто за вихід ви платите в сотні разів менше за ту саму одиницю тексту (cloudzero.com). А на окремих задачах один опублікований аналіз зафіксував крайній випадок: однакова робота коштувала $0,04 на одному провайдері й $25 на іншому — різниця в 625 разів (cloudzero.com).

Сто разів — це не на 60%. Це інший порядок арифметики. А на гострих краях — і всі шістсот.

І тепер найцікавіше — продуктивність. Дотонко налаштована мала модель на вузькій задачі обганяє велику універсальну, працюючи при цьому в десятки разів дешевше: за оцінками 2026 року, заточена під конкретну роботу модель на 1–7 млрд параметрів дає вищу точність за загальний флагманський API, коштуючи близько 50 разів менше в продакшні (bentoml.com). Найгостріший приклад — на бенчмарку виклику інструментів: у профільному препринті дотонко налаштована мала модель показала 77,55% точності проти 26% у базової великої (arxiv.org). Менша модель. Майже втричі вища точність. Менша ціна. Бо її заточили під одну вісь, а не змусили бути добренькою на всіх.

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

Counter-pressure: а може, «беріть найрозумнішу» — це насправді правильно?

Тепер чесно вдарю по власній тезі, бо без цього вона — просто ще один впевнений рядок у чиїйсь вікі.

Найсильніший контраргумент звучить так: вся ця матриця — передчасна оптимізація. Поки ви профілюєте задачі на п’яти осях, малюєте таблиці й сперечаєтесь про латентність, ваш конкурент узяв найдорожчу модель, підключив її до всього й уже відвантажив продукт. Інженерний час коштує дорожче за токени. Якщо найдорожча модель «достатньо добра» скрізь, то рішення «беремо найкращу й не думаємо» економить найдорожчий ресурс — увагу команди. І ціни ж падають: за оцінками Epoch AI, вартість API на зіставленому рівні якості падає від 40 до 900 разів на рік залежно від задачі й бенчмарку (epoch.ai), тож завтра навіть флагман буде дешевим.

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

Що спростувало б мою тезу остаточно? Якби розкид цін був не стократним, а, скажімо, двократним — оптимізація не вартувала б зусиль. Якби велика модель не деградувала на довгому контексті (про це нижче) — не було б технічної причини шукати інше. Якби обсяги були малими назавжди. Але щойно ви виходите на масштаб, арифметика розвертається жорстко: середнє підприємство з 10 000 запитів на день платить мільйони на місяць через флагманський API, а самостійно розгорнута 7B-модель на одному GPU обходиться менш ніж у $1000 на місяць (iterathon.tech). На масштабі «не думати» — це не економія уваги. Це підписка на власне банкрутство. Матриця окуповується рівно в той момент, коли ваш продукт починає працювати.

Вісь context: мільйон токенів, які ви не зможете прочитати

Третя вісь — контекст, обсяг пам’яті в одному запиті. І тут ринок продає вам цифру, яка бреше.

У 2026 році контекстні вікна тягнуться від 128 тисяч до 10 мільйонів токенів (tokenmix.ai). Звучить так, ніби можна закинути в модель усю корпоративну базу й отримати ідеальну відповідь. Не можна. Існує явище, яке дослідники називають «загубленим у середині»: моделі помітно гірше дістають інформацію із середини довгого контексту, ніж із початку чи кінця, а ефективна місткість вікна, за вимірами, зазвичай складає 60–70% від рекламованого максимуму (morphllm.com). Це не одиничне спостереження. Незалежний бенчмарк RULER показує те саме на цифрах: GPT-4 падає з 96,6 бала при 4 тисячах токенів до 81,2 при 128 тисячах, а Llama 3.1-70B — з 96,5 аж до 66,6; майже всі моделі, ідеальні на «голці в копиці сіна», провалюють складніші задачі, щойно контекст довшає (medium.com).

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

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

Вісь latency: дзеркало, у якому ви — той, хто чекає

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

Ви відкрили застосунок, поставили запитання й чекаєте. Минула секунда. Дві. На третій ви вже клацнули в інший таб. Ось де живе вісь latency — не в дашборді метрик, а в тій самій секунді, коли ваше терпіння закінчується раніше за відповідь моделі.

Цифри тут конкретні. Найшвидші легкі моделі дають час до першого токена близько 600 мілісекунд (benchlm.ai). Найшвидші за пропускною здатністю генерують 146-173 токени на секунду (benchlm.ai). А reasoning-модель на повному мисленні — ті самі 15 секунд тиші до першого слова (benchlm.ai). І ось парадокс, який ловить навіть досвідчених: полегшена версія моделі може бути повільнішою за повну на коротких запитах — деякі «mini»-варіанти беруть понад 2 секунди до першого токена проти менш ніж 900 мс у повної версії (benchlm.ai). «Менша» не означає «швидша». Це треба міряти, а не вгадувати за назвою.

Антагоніст цієї історії має обличчя, і це не вендор. Це продакт-менеджер — назвемо його умовним іменем Максим, — який вимагає одночасно «найрозумнішу модель» і «миттєву відповідь», не помічаючи, що ці дві вимоги тягнуть осі latency й reasoning у протилежні боки. Максим хоче глибину reasoning і швидкість легкої моделі в одному дзвінку API. Фізики тут немає. Або модель довго думає й дає глибину, або відповідає миттєво й дає поверхню. Матриця не вирішує цей конфлікт за Максима — вона робить чесніше: показує йому компроміс у вічі, цифрами, до того, як він пообіцяє його клієнту.

Вісь tools: остання балка, на якій тримаються агенти

П’ята вісь — надійність виклику інструментів. Колись вона була екзотикою. У 2026-му, у світі агентів, вона несуча.

Якщо ваша система — це агент, що сам викликає функції, ходить у бази, запускає код, то здатність моделі коректно сформувати виклик інструменту важливіша за її ерудицію. Розумна модель, яка плутає формат виклику API, гірша за посередню, яка викликає його бездоганно. Саме на цій осі мали спеціалізовані моделі найгучніше б’ють великі універсальні: дотонко налаштована модель на бенчмарку tool-calling показала 77,55% проти 26% у базового (arxiv.org) — бо її натренували саме на цю вісь, а не на загальну балакучість.

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

Матриця: одна таблиця, яку варто роздрукувати

Ось рамка в дії. Зліва — типові класи задач. Зверху — п’ять осей. Усередині — куди ставити точку. Жодного імені моделі: імена ви підставите самі, звіривши сьогоднішні знімки з потрібним профілем. Завтра знімки зміняться — таблиця залишиться.

Клас задачі	Reasoning	Context	Latency	Cost	Tools
Класифікація / роутинг тікетів	низький	малий	критична (швидко)	мінімізувати	не потрібні
Чат-підтримка в реальному часі	середній	середній	критична	низький-середній	базові
Аналітичний звіт / дослідження	високий	великий	неважлива	можна високий	помірні
Кодовий агент / рефакторинг	високий	середній-великий	помірна	середній	критичні
Підсумовування довгого документа	середній	великий (з пошуком!)	помірна	середній	не потрібні
Автономний агент із інструментами	високий	середній	помірна	середній	критичні
Масова генерація шаблонного тексту	низький	малий	помірна	мінімізувати	не потрібні

Як цим користуватися. Крок перший: візьміть свою реальну задачу й чесно проставте точку на кожній з п’яти осей — не «хочу все на максимум», а де справді болить. Крок другий: відкиньте моделі, які провалюють хоч одну критичну для вас вісь (повільна — геть із реального часу; ненадійна на tools — геть із агента). Крок третій: серед тих, що лишилися, беріть найдешевшу, що проходить поріг. Не найдорожчу. Найдешевшу з тих, що проходять. Крок четвертий — і єдиний, який доведеться повторювати — щокварталу перезвіряйте знімки з профілем. Самі осі ви не чіпаєте роками. Міняються тільки імена в порожніх клітинках вашої голови.

Покажу на одній живій задачі, бо абстрактна таблиця нікого ще не врятувала. Уявіть бота, що сортує вхідні тікети підтримки за відділами — десятки тисяч штук на день. Проходимо осі. Reasoning: низький — це класифікація з кількох категорій, тут не треба доводити теорему. Context: малий — модель бачить один тікет, не всю історію клієнта. Latency: критична — тікети течуть рікою, кожна зайва секунда множиться на десятки тисяч. Cost: мінімізувати, з тієї ж причини. Tools: не потрібні — модель просто повертає мітку. Профіль зійшовся: вам потрібна найдешевша швидка легка модель, що бере поріг точності. Флагман за $30 за мільйон тут не просто зайвий — він був би жартом, від якого сміявся б ваш фінвідділ, дивлячись на рахунок. А тепер фокус: коли наступного місяця вийде нова дешева модель і ще наступного — ще одна, ви не переписуєте жодного рядка цього абзацу. Ви міняєте одне ім’я в одній клітинці. Профіль задачі не зрушив ні на піксель.

«Чому саме зараз?» — резонне питання, бо ще у 2018-му ця матриця була б безглуздою. Тоді була по суті одна вісь — «чи воно взагалі працює», — і одна-дві моделі, між якими нíчого було обирати. Reasoning як окремий режим, мільйонні контексти, надійний tool-calling, стократний розкид цін — усе це з’явилось у вікні 2023-2026. Матриця стала потрібною рівно тоді, коли осей стало п’ять, а знімків — сотні. Раніше ви обирали з меню на два рядки. Тепер ви обираєте координати в п’ятивимірному просторі, де меню переписують щотижня. Назва — погана навігація в такому просторі. Осі — єдина пристойна.

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

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

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

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

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

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