Як зменшити витрати на LLM: кешування, маршрутизація моделей і скорочення промптів

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

Із чого складається рахунок

На вартість LLM впливають кілька чинників:

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

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

Спершу виміряйте, потім змінюйте

Оптимізація наосліп — це ворожіння. Для початку відстежуйте:

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

Реальні дані часто дивують. Може з’ясуватися, що 20% користувачів дають 70% витрат або що один RAG-процес запихає в кожен виклик гору непотрібного контексту. Поки хтось не подивиться, ні того, ні іншого не видно.

Кешуйте повторювану роботу

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

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

Семантичний кеш

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

• FAQ
• підтримки клієнтів
• внутрішніх асистентів із бази знань
• документації до продукту
• одноманітних корпоративних процесів

Поріг добирайте обережно. Надто м’який — і різні питання отримають однакову відповідь, надто жорсткий — і кеш майже не спрацьовує.

Маршрутизуйте за складністю

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

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

Скорочуйте промпт

Довгі промпти коштують грошей, особливо коли один великий системний промпт додається до кожного виклику. Припустімо, на кожен запит іде 3000 токенів інструкцій, 5000 токенів знайденого контексту і 500 токенів користувацького вводу. Навіть на крихітне питання модель обробляє близько 8500 токенів.

Перевірте промпти на:

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

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

У RAG надсилайте менше фрагментів, але точніше

RAG-конвеєри дорожчають, коли моделі передають забагато знайдених документів. Скажімо, пошук повертає 20 фрагментів по 1000 токенів. Це 20 000 токенів контексту на один запит, і більша їх частина моделі, найімовірніше, не потрібна.

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

Стисніть те, що залишилося

Навіть у релевантних документах повно зайвого тексту. Стиснення контексту витягує корисні частини до того, як їх побачить модель. Документ на 10 000 токенів може зменшитися до 1500 токенів по суті. Це окупається на:

• юридичних документах
• фінансових звітах
• технічній документації
• корпоративних базах знань
• довгій історії спілкування з клієнтом

Обмежте відповідь

Моделі здатні написати набагато більше, ніж хоче користувач. На питання на кшталт «Який статус мого замовлення?» відповідь на 1000 токенів не потрібна. Задайте розумні ліміти на вивід і формат відповіді. Для структурованих завдань компактний формат працює краще за прозу:

Status: Shipped
Expected Delivery: Friday
Tracking Available: Yes

Менше вихідних токенів — менший рахунок, а зазвичай іще й швидша відповідь.

Використовуйте звичайний код там, де його досить

Можливо, це найважливіше правило в AI-інженерії: деяким завданням LLM не потрібна взагалі. Перевірка, чи перевищує замовлення $1000, — це один рядок: if order_value > 1000. Звичайне ПЗ і так справляється з обчисленнями, сортуванням, фільтрацією, валідацією, роботою з датами, запитами до бази та детермінованими бізнес-правилами. Залиште модель для тих місць, де розуміння мови чи міркування справді щось додають.

Тримайте агентів на короткому повідку

Агентні системи здатні накрутити несподівано великі витрати на інференс. Одне завдання може викликати планування, вибір інструмента, пошук, аналіз, перевірку й формування підсумкової відповіді. Запустіть усі шість кроків на великій моделі — і вартість помножиться.

Продумана архітектура може:

• прибрати зайві цикли агента
• використовувати детерміновані інструменти, де це можливо
• обмежити максимальну кількість ітерацій
• віддати рутинні кроки меншим моделям
• кешувати проміжні результати
• уникати повторного пошуку
• об’єднувати сумісні операції

Мета не в тому, щоб скоротити корисні дії, а в тому, щоб прибрати непотрібні.

Нетермінове — пакетами

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

Обирайте модель як інженер

Вибір моделі — інженерне рішення, і оцінювати його варто за кількома питаннями:

• Якість: наскільки точним має бути результат?
• Вартість: яка ціна за запит прийнятна?
• Затримка: як швидко потрібна відповідь?
• Контекст: скільки інформації модель має прийняти?
• Міркування: наскільки складне завдання?
• Надійність: наскільки стабільними мають бути результати?

Замініть питання «Яка модель найкраща?» на «Якої моделі досить для цього завдання?». Така невелика зміна може переписати всю економіку продакшену.

Доведіть, що нічого не зламалося

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

Умовний приклад: вихідна версія дає 92% за $0.020 на запит, оптимізована — 91% за $0.009. Якщо бізнес готовий прийняти падіння якості на один пункт, другий варіант обходиться в рази дешевше.

Як скласти шари докупи

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

Якої економії чекати

Не сприймайте «мінус 60%» як обіцянку. Результат сильно залежить від навантаження. І все ж поєднання кількох оптимізацій може дати серйозне зниження. Візьмімо гіпотетичний щомісячний рахунок у $10 000 і подивімося, де його можна урізати:

• скоротити повторні запити на 20%
• перевести відповідні навантаження на дешевші моделі
• прибрати зайві вхідні токени
• шукати й надсилати лише релевантний контекст
• усунути непотрібні виклики інструментів і моделей
• припинити надмірно довгі відповіді

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

Чек-лист перед запуском

Перш ніж пускати LLM-застосунок під серйозне навантаження, поставте собі ці питання.

• Необхідність: чи кожному кроку потрібна LLM? Чи може детермінований код узяти частину роботи на себе? Чи обмежені цикли агентів?
• Промпти: чи не роздуті системні інструкції? Чи потрібні приклади? Чи не просочується нерелевантний контекст?
• Пошук: чи не забагато фрагментів витягується? Чи є реранкінг? Чи можна стиснути контекст?
• Моделі: чи не використовується найдорожча модель там, де вона не потрібна? Чи можна маршрутизувати запити за складністю?
• Кешування: чи кешуються повторні запити? Чи підійде семантичний кеш?
• Вивід: чи контролюється довжина відповідей? Чи є сенс у структурованому виводі?
• Моніторинг: чи відстежується витрата токенів? Чи відома вартість кожної функції? Чи стежать за метриками якості нарівні з вартістю?

Мета — стійкість, а не мінімальна ціна

«Зробити AI якомога дешевшим» — хибна мета. Правильніше — досягти потрібної для бізнесу якості за мінімальних стійких витрат. Застосунок підтримки може відповідати на прості FAQ маленькою моделлю, а заплутані скарги віддавати сильнішій. Асистентові для програмування на складних завданнях можуть знадобитися серйозні міркування. Конвеєр обробки документів може ставити на перше місце пропускну здатність і стабільність. Універсального рецепта немає, правильна архітектура залежить від навантаження.

Витрати на LLM не зобов’язані рости разом із використанням. Кешування, маршрутизація, компактні промпти, ощадний RAG, стиснення, ефективні агенти, ліміти на вивід і постійне оцінювання — усе це допомагає, а найбільший виграш зазвичай дає відмова від викликів, які взагалі не були потрібні. Якщо AI-застосунок стає дорогим в експлуатації, відповіддю може бути не урізання використання, а ретельніша інженерія системи.