Налаштувати детально чи використовувати API? Витрати на пайплайн вилучення документів

Лідери інженерних відділів постійно ставлять одне й те саме запитання, зазвичай відразу після отримання першого великого рахунку від OpenAI чи Anthropic: чи варто команді налаштовувати власну модель чи продовжувати користуватися API? Очікувана відповідь полягає у тому, що налаштування моделі є дешевшим варіантом. Іноді це справді так, але зазвичай з причин, які відрізняються від тих, які припускають люди, і для багатьох команд це просто неправильно. У цій статті детально розглядається реалістична ситуація з високими витратами на систему, оцінена з обох точок зору, з використанням цін за вересень 2026 року, щоб ви могли побачити, звідки насправді походять економії, коли доцільно володіти моделлю та як приймати рішення, не ставлячи на кон вісім тижнів роботи інженерів на основі припущень.

Варіант, який люди уявляли, більше не існує

Одна зміна тихо змінила всю дискусію: на момент написання цього тексту неможливо налаштовувати сучасні передові моделі.

Згідно з сторінкою ціноутворення OpenAI, їхня платформа для фін-налаштувань поступово виходить з експлуатації: нові клієнти не можуть зареєструватися, а o4-mini є єдиним залишеним моделлю, яку можна налаштовувати, з вартістю 100 доларів за годину навчання. Власний API Anthropic зовсім не дозволяє виконувати фін-налаштування. Єдиним історичним способом було кероване фін-налаштування Claude 3 Haiku на Amazon Bedrock, причому Haiku 3 з того часу було видалено з усіх платформ, крім Bedrock та Google Cloud.

Отже, наприкінці 2026 року термін «точна налаштуваність проти передових технологій» означає щось конкретніше: береться модель з відкритими параметрами, така як Qwen, Llama, варіант Nemotron чи gpt-oss, на основі цих даних тренується адаптер LoRA, після чого він розміщується на власній інфраструктурі або у провайдера, наприклад Fireworks чи Together. Ризики такого вибору не є тими, які уявляють багато хто — вони стосуються вибору моделі, її оцінки та обслуговування, яким зазвичай займається API-сервіс. Обов’язково будьте точні щодо цього перед представленням раді директорів.

Система для порівняння: платформа доказів для аудиту

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

1. Прийом даних. Клієнти завантажують файли через портал, переважно у вигляді сканованих PDF-файлів. Типовими документами є рахунки-фактури, замовлення на постачання, акти приймання товарів, банківські виписки, договори оренди та протоколи засідань правління.
2. Класифікація. Кожному документу присвоюється тип, після чого він надсилається на відповідну перевірку.
3. Витягування даних. Структуровані поля вводяться у фіксовану схему, що включає інформацію про постачальника, дату, чисту суму, ПДВ, номер замовлення, особу, яка схвалила документ, валюту та центр витрат. Результат має бути коректним JSON-файлом, який у кожному випадку повністю відповідає схемі.
4. Перевірка контролю. Багатостороння зіставлення перевіряє, чи відповідає рахунок-фактура замовленню на постачання та акту приймання товарів, а також чи мала особа, яка схвалила документ, відповідні повноваження. Більша частина цього процесу полягає у звичайному коді, а не у моделі.

Класифікація винятків. Усе, що не пройшло тестування, оцінюється та ранжується.

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

Запитання та відповіді аудитора. Аудитори запитують про всю інформацію з файлу проекту та отримують обґрунтовані відповіді з посиланнями на джерельні документи.

Етапи 2 та 3 споживають майже всі токени, і вони також є найбільш повторюваними, механічними та обмеженими схемою частинами системи. На етапах 6 та 7 відбувається справжнє оцінювання, проте їхня частка у обсязі роботи є незначною. Пам’ятайте про цей розподіл, адже решта аналізу ґрунтується на ньому.

Оцінка обсягу токенів

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

Кожен документ проходить через три етапи обробки (класифікація, вилучення даних та самоперевірка), що в сумі становить приблизно:

• 5 200 вхідних токенів, які включають текст документа, схему та кілька прикладів
• 600 вихідних токенів для структурованого результату

Моделюються два рівні обсягу обробки:

• Pilot: 100 000 документів на місяць, що відповідає одній компанії під час напруженого сезону.
• Scale: 2 000 000 документів на місяць, що відповідає одному й тому ж продукту, який продається п’ятдесяти компаніям.

Це означає приблизно 580 мільйонів токенів на місяць при рівні Pilot та 11,6 мільярда токенів при рівні Scale.

Як виглядає рахунок

У наведених нижче цифрах використані стандартні ціни з глобальним маршрутизуванням без знижок за оптові партії чи кешування, як вони були опубліковані на сторінках цін кожного постачальника у вересні 2026 року. Ціни часто змінюються, тому сприймайте їх як моментальний знімок та перевіряйте їх перед складанням бюджету.

При невеликому обсязі роботи необхідність налаштування моделі втрачає сенс. Запуск усього процесу обробки даних на Claude Sonnet 5 коштує приблизно 1 640 доларів на місяць, Haiku 4.5 — близько 820 доларів, а налаштована модель об’ємом 8 мільярдів параметрів — приблизно 116 доларів. Економія близько 1 500 доларів на місяць ніколи не компенсує зусиль, пов’язаних із налаштуванням моделі. На цьому етапі краще використовувати API.

При великому обсязі роботи вибір стає справді значущим:

• Claude Opus 5: приблизно 82 000 доларів на місяць
• GPT-5.6 Sol: приблизно 65 600 доларів на місяць
• Claude Sonnet 5: приблизно 32 800 доларів на місяць
• Claude Haiku 4.5: приблизно 16 400 доларів на місяць
• GPT-5.6 Luna: приблизно 3 520 доларів на місяць

Тонко налаштований 8B, що працює без серверів: приблизно 2 320 доларів на місяць

Хочеться стверджувати про економію понад 90% завдяки тонкому налаштуванню, і з точки зору арифметики це підтверджується порівняно з преміум-тарифами: вартість тонкого налаштування становить близько 7% від вартості Sonnet 5 та менше 3% від вартості Opus 5. Але жодна команда не повинна взагалі використовувати преміум-моделі для масового отримання рахунків. Порівнювати оптимізовану конструкцію з навмисно неефективною — це маркетинг, а не аналіз.

Маршрутизація, а не тонке налаштування, забезпечує значну економію

Порівняйте останні два пункти цього списку: 3 520 доларів за GPT-5.6 Luna проти 2 320 доларів за тонко налаштовану модель 8B. Різниця становить 1 200 доларів на місяць, або близько 14 400 доларів на рік.

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

Більш корисний висновок полягає у тому, що найбільше скорочення витрат досягається завдяки маршрутизації. Перенесення процедур класифікації та вилучення даних з основного рівня обробки на найдешевший рівень, який все ще відповідає вашим критеріям оцінки, дозволяє знизити місячні витрати з $82,000 до $3,520, що становить скорочення приблизно на 96%. За допомогою маршрутизатора та надійного набору даних для оцінки цю зміну можна впровадити протягом одного дня. Додаткова налаштування дозволяють заощадити ще близько 34%. Той самий принцип — підбір розміру моделі під кожен запит — детальніше розглядається у статті про правильний вибір розміру LLM за допомогою маршрутизації, пошуку та оцінки.

Сам процес навчання майже безкоштовний. Fireworks пропонує функцію посиленого налаштування LoRA для моделей з кількістю параметрів до 16 млрд за ціною 0,50 долара за мільйон токенів навчання. Двадцять тисяч міткованих прикладів по 2 500 токенів кожен, навчених протягом трьох епох, становлять 150 мільйонів токенів навчання, або приблизно 75 доларів за один запуск. Вісім запусків під час розробки дають загалом близько 600 доларів. Обчислення ніколи не були найдорожчою частиною; дорого коштують підготовка даних та оцінка. Будь-яка ціна на посилене налаштування, яка ґрунтується переважно на витратах на GPU, належить людині, яка цього не робила.

Чому взагалі проводити посилене налаштування

Якщо витрати на токени не є обґрунтуванням, то можуть бути два інші фактори.

Перший привід: суворе дотримання схеми

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

Моделі типу Frontier є універсалами. Якщо попросити їх вибрати з 51 фіксованої підкатегорії, іноді вони створюють 52-гу, адже метою їх навчання є генерація тексту, який звучить правдоподібно. Для чат-асистента такі помилки майже не мають значення. Однак у документі, який підтримує підписану аудиторську думку, це є недоліком.

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

• Предпринт-версія 2026 року щодо класифікації документів з питань безпеки оцінювала моделі за 51 заздалегідь визначеною підкатегоріями, вимагаючи відповідей у суворому форматі JSON. У цьому дослідженні локально розміщена налаштована модель перевершила моделі типу Frontier на 15–20 відсоткових пунктів, а дослідники спостерегли, як GPT-5 створює назви підкатегорій, яких не було в таксономії. Їхнє тлумачення є найважливішим: моделі типу Frontier добре справляються з вилученням інформації у неформально структурованому форматі, але за суворих обмежень схеми калібрування має більше значення, ніж здатність до міркувань.

Ще один препринт описує доопрацьовану версію Qwen2.5-0.5B — модель із півмільярда параметрів, яка поміщається на одну споживчу GPU та досягає середнього показника 0.83 мікро-F1 у завданнях на вилучення взаємозв’язків у загальнодоменних даних. За допомогою лише мінімальних підказок типу zero-shot модель GPT-5.4 досягла показника 0.69 за цим критерієм, а Claude Sonnet 4.6 — 0.66. Автори наголошують, що це не означає, ніби малі моделі за своєю природою є сильнішими; це демонструє, що адаптація моделі під вузьке, фіксоване завдання може переважити її первинні можливості. Вилучення інформації з аудиту — саме такий тип завдання.

Власні опубліковані результати компанії Anthropic щодо доопрацювання Claude 3 Haiku показали, що точність класифікації у завданнях модерування коментарів піднялась з 81.5% до 99.6%, причому кількість токенів на запит зменшилась на 85%. Домен відрізняється, але закономірність залишається такою ж.

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

Друга причина: точне знання місця зберігання даних

У Європі саме це часто вирішує долю угоди.

Файли аудиту бухгалтерських фірм у Великобританії чи ЄС містять фінансову інформацію клієнтів, дані працівників та іноді особисті дані третіх сторін. Місце обробки даних не є другорядним питанням; зазвичай це друге запитання, яке ставлять під час закупівель.

Нинішні варіанти, станом на вересень 2026 року, дивують багато команд:

• API від Anthropic не має опції розташування в ЄС. Параметр inference_geo приймає значення global або us; обробка лише в США коштує у 1,1 раза більше за стандартну ціну. Щоб тримати Claude в межах ЄС, потрібно використовувати регіон AWS Bedrock або Google Vertex в ЄС, де регіональні кінцеві точки коштують на 10% дорожче, ніж глобальні. На момент написання у Microsoft Foundry не було регіону з обробкою даних в ЄС.
• OpenAI підтримує регіональну обробку, додаючи 10% до ціни для моделей, запущених з 5 березня 2026 року та пізніше.
• Fireworks застосовує множник 1,5, коли спеціалізоване розгортання обмежене певним регіоном.

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

Якщо вартість розраховується з урахуванням обсягу роботи, ситуація змінюється. Два спеціалізовані пристрої H100, які використовують налаштовану 8B-модель, працюють у певному регіоні та цілодобово, коштують приблизно 17 520 доларів на місяць. Виконання тієї ж роботи за допомогою Claude Sonnet 5 на EU Bedrock-екземплярі обійдеться приблизно у 36 080 доларів, а з Opus 5 — близько 90 200 доларів.

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

Не купуйте спеціалізовані GPU занадто рано

Фіксована щомісячна вартість GPU здається привабливою та обманює багато команд, адже вона окуповується лише при обсягах, яких досягають дуже мало продуктів. Якщо взяти за основу пару спеціалізованих пристроїв H100 за світовими цінами — приблизно 11 680 доларів на місяць — то точки переходу знаходяться приблизно так:

• 700 000 документів на місяць для Claude Sonnet 5; нижчий обсяг робить API дешевшим
• 1,4 мільйона на місяць для Claude Haiku 4.5
• 6,6 мільйона на місяць для GPT-5.6 Luna

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

Чотири запитання, які допоможуть ухвалити рішення

1. Який у вас справжній щомісячний обсяг токенів? Якщо ви обробляєте менше приблизно мільярда токенів на місяць, оберіть найдешевший рівень Frontier, який дозволить пройти оцінку, та інвестуйте вісім робочих тижнів інженерів у щось більш корисне. Налаштування моделі на рівні пілотного обсягу — це театральні дії, а не інженерна робота.

2. Наскільки вузько та обмежено завдання? Фіксований формат вихідних даних, фіксований набір міток та тисячі майже ідентичних прикладів щодня вказують на необхідність налаштування моделі. Відкритий мислення, суб’єктивні рішення та складання текстувань для підпису партнера потребують моделей типу Frontier та, ймовірно, залишатимуться саме там.

3. Де мають знаходитися дані? Умова договору, яка вимагає обробки даних у межах ЄЕЗ, змінює перелік можливих варіантів ще до того, як почнеться обговорення витрат. Слід включити кошти, пов’язані з розміщенням даних, у початкову оцінку, а не виявляти їх під час перевірки архітектури.

4. Чи можна отримати принаймні 10 000 позначених прикладів? У документі NVIDIA Research про невеликі мовні моделі в агентних системах пропонується діапазон від десяти тисяч до ста тисяч прикладів як оптимальний для налаштування невеликої моделі. Якщо цього немає, першим кроком має бути створення системи для запису власних даних навчання під час роботи з моделлю.

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

У тій самій статті NVIDIA також оцінили частку викликів LLM, які малі моделі могли б взяти на себе у трьох проектах з відкритим кодом: приблизно 60% для MetaGPT, 40% для Open Operator та 70% для Cradle. Це не всі, але й не жодні з них. Правильна відповідь — це поєднання, і лише записи показують, які виклики належать до кого.

Найсильніший аргумент проти

Дані щодо впровадження цих технологій у корпоративних середовищах вказують на протилежне. Згідно з опитуванням корпорацій, проведеним Menlo Ventures, частка робочих навантажень, що використовують відкритий код, знизилась з 19% до 11%, тоді як витрати сконцентрувалися на закритих API: Anthropic становить 40% від загальних витрат корпорацій на ШІ, OpenAI — 27%, а Google — 21%. (Menlo є інвестором Anthropic, що варто враховувати під час аналізу цих цифр.)

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

Коротка інформація про регулювання в ЄС

Команди з Великої Британії та ЄС будуть ставити запитання щодо Закону про ШІ, тому корисним буде короткий огляд. Розглядайте його як інформаційний матеріал, а не юридичну пораду, та підтверджуйте актуальний текст перед тим, як покладатися на будь-які дати.

Цифровий омнібус щодо ШІ, формально Регламент (ЄС) 2026/1744, був опублікований у Офіційному віснику 24 липня 2026 року та набув чинності через три дні, 27 липня. Він відклав обов’язки щодо систем з високим ризиком із періоду 2 серпня 2026 року на 2 грудня 2027 року для самостійних систем з Прилегача III. Для ШІ, вбудованих у продукти, що підпадають під Прилегач I, новою датою є 2 серпня 2028 року.

Обов’язки щодо прозорості згідно зі статтею 50 не були відкладені та діють з 2 серпня 2026 року, як і планувалося спочатку. Для систем, випущених на ринок раніше, обов’язок маркування згідно зі статтею 50(2) починає діяти 2 грудня 2026 року.

Інструменти, які підтримують аудиторів та передбачають крок людського схвалення, зазвичай не належать до Додатку III, але оцініть власний кейс використання: якщо будь-який компонент впливає на рішення щодо найму чи кредитоспроможності, він потрапляє під дію цих правил. Це ніяк не впливає на GDPR, який регулює дані клієнтів, що проходять через систему, незалежно від того, як Закон про ШІ класифікує цю систему.

Попит справжній. У опитуванні Wolters Kluwer 39% з 4 214 фахівців з внутрішнього аудиту зазначили, що вже використовують ШІ, а ще 41% планують почати це робити протягом року.

Етапний план створення такої системи

Для команди, яка починає розробку подібної системи, рекомендована послідовність є такою:

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

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

Налаштовуйте тільки ці запити. Спочатку розмістіть їх на інфраструктурі без серверів, залиште функції сортування, підготовки та відповідей на запитання на моделі Frontier, а перед обома додайте маршрутизатор.

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

Три з цих чотирьох етапів коштують менше, ніж те, що витрачають багато команд вже з першого дня.

Ключові висновки

• Сучасні моделі Frontier зазвичай не піддаються детальній налаштуванню, тому справжнім вибором є модель з відкритими вагами та адаптером LoRA проти API, що розміщується на сервері.

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

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

Нафінтунінг знаходить своє застосування завдяки суворому дотриманню схеми та резиденції даних, а не через рахунок за токени.

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

З самого початку фіксуйте записи викликів, щоб майбутній нафінтунінг починався на основі доказів.

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

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

Пов’язана література

• Mapping RAG: Етапи пайплайну, основні компоненти та ландшафт варіантів — Дізнайтеся, як працює технологія retrieval-augmented generation від початку до кінця, які компоненти потрібні системі RAG та як багато різних варіантів RAG укладаються в єдину структуру.

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