Як зменшити затрати токенів в LLM системах: гайд по оптимізації довгих контекстів

Якщо ваш додаток на базі GPT-4o або Claude 3.5 щомісяця “з’їдає” бюджет на API-виклики — ця стаття для вас. Проблема довгих контекстів реальна: розробники часто передають моделі зайві дані, платять за токени, які не впливають на якість відповіді, і навіть не підозрюють про це. Цей туторіал покаже п’ять конкретних технік скорочення токенів на 40–70% без втрати якості результату. На опрацювання знадобиться приблизно 45–60 хвилин і базове розуміння того, як працюють API-запити до LLM.

🛠️ Що знадобиться

• OpenAI Platform або Anthropic Console — для відстеження реального використання токенів у розрізі кожного запиту; обидва сервіси мають безкоштовний tier для тестування
• tiktoken (Python-бібліотека) — офіційний токенізатор від OpenAI для точного підрахунку токенів до відправки запиту; безкоштовний, встановлюється через pip
• LangChain або LlamaIndex — фреймворки для побудови RAG-пайплайнів з вбудованими інструментами чанкінгу та компресії контексту; є безкоштовні open-source версії
• Redis або Upstash — для кешування семантично схожих запитів і повторного використання вже оплачених відповідей; Upstash має безкоштовний план до 10 000 команд на день
• Векторна база даних (Qdrant або Weaviate) — для реалізації семантичного пошуку і передачі моделі лише релевантних фрагментів тексту; Qdrant має безкоштовний self-hosted варіант

📋 Покрокова інструкція

Крок 1: Виміряйте реальне споживання токенів і знайдіть “жирні місця”

Перш ніж оптимізувати — потрібно знати, що саме оптимізувати. Встановіть tiktoken командою pip install tiktoken, потім напишіть простий скрипт: завантажте свій типовий промпт у змінну, викличте tiktoken.encoding_for_model("gpt-4o"), потім len(encoding.encode(your_prompt)) — і ви побачите точну кількість токенів. Відкрийте OpenAI Platform → розділ Usage → Logs і відфільтруйте запити за останні 7 днів: знайдіть топ-10 найдорожчих викликів і збережіть їхні промпти — це і буде ваш список для оптимізації. Типова картина: 60–70% токенів займає системний промпт і контекст, а не реальне запитання користувача.

Крок 2: Стисніть системний промпт за допомогою LLMLingua

LLMLingua — це безкоштовна бібліотека від Microsoft, яка стискає промпти, зберігаючи їхній смисл. Встановіть її: pip install llmlingua. Далі в коді: імпортуйте PromptCompressor, створіть екземпляр compressor = PromptCompressor(model_name="microsoft/llmlingua-2-bert-base-multilingual-cased-meetingbank"), потім викличте compressor.compress_prompt(your_long_prompt, rate=0.5) — параметр rate=0.5 означає скорочення вдвічі. Підводний камінь: не використовуйте rate нижче 0.3 для промптів із числами, датами або кодом — модель може втратити критичні деталі. Для технічних промптів безпечний діапазон — 0.4–0.6, для описових текстів — 0.3–0.5.

Крок 3: Впровадьте RAG замість передачі повного документа

Якщо ви зараз передаєте в контекст цілий PDF або довгий документ — це головний “пожирач” токенів. Замість цього побудуйте RAG-пайплайн: у LlamaIndex відкрийте термінал і виконайте pip install llama-index-vector-stores-qdrant. Завантажте документ через SimpleDirectoryReader, розбийте на чанки через SentenceSplitter(chunk_size=512, chunk_overlap=50) — це дасть фрагменти по ~512 токенів із перекриттям 50 токенів для збереження контексту між чанками. Збережіть індекс у Qdrant, а при кожному запиті користувача витягуйте лише топ-3 релевантні чанки через index.as_query_engine(similarity_top_k=3). Результат: замість передачі документа на 50 000 токенів ви передаєте 1 500 токенів найрелевантнішого тексту.

Крок 4: Налаштуйте семантичне кешування через GPTCache

Встановіть GPTCache: pip install gptcache. Ідея проста: якщо два запити семантично схожі (наприклад, “яка столиця Франції?” і “назви столицю Франції”), система повертає вже збережену відповідь, не витрачаючи токени. Налаштуйте кеш у коді: викличте from gptcache import cache, потім cache.init(similarity_evaluation=SearchDistanceEvaluation(), similarity_threshold=0.85) — поріг 0.85 означає, що запити зі схожістю вище 85% вважаються однаковими. Підключіть Redis як бекенд через cache.init(..., data_manager=get_data_manager(data_path="redis://localhost:6379")). За статистикою реальних проєктів, у продуктах із FAQ або повторюваними запитами кешування закриває 30–45% трафіку без жодного токена.

Крок 5: Реалізуйте динамічне скорочення історії діалогу

У чат-ботах головна проблема — необмежена передача всієї історії розмови. Впровадьте стратегію “ковзного вікна з резюмуванням”: зберігайте повними лише останні 6 повідомлень (3 пари user/assistant), а всі попередні замінюйте автоматичним резюме. У LangChain це робиться через ConversationSummaryBufferMemory(llm=llm, max_token_limit=600) — параметр max_token_limit=600 означає, що як тільки буфер перевищить 600 токенів, LangChain автоматично стисне старі повідомлення в короткий summary і передасть його замість повного тексту. Фінальний результат усього пайплайну: система, яка автоматично вимірює токени, стискає промпти, витягує лише релевантний контекст, кешує повторні запити і керує пам’яттю діалогу — в сукупності це дає економію 50–70% від початкових витрат.

⚠️ Типові помилки та як їх уникнути

• Чанки занадто малі (менше 256 токенів) — модель отримує фрагменти без достатнього контексту і генерує неточні відповіді; оптимальний розмір чанка — 512–1024 токени з overlap 10–15%
• Стиснення промптів із інструкціями щодо форматування — LLMLingua може видалити частину інструкцій типу “відповідай у форматі JSON” і модель перестане дотримуватися потрібного формату; виносьте структурні інструкції в окремий блок і позначайте їх як некомпресовані через параметр instruction_pos="compress_last"
• Кешування персоналізованих відповідей — якщо ваші запити містять ім’я користувача або його персональні дані, кеш може повернути чужу відповідь іншому користувачу; завжди додавайте user_id до ключа кешу і ніколи не кешуйте відповіді, що містять PII
• Ігнорування output-токенів — більшість розробників оптимізують лише input, але output коштує в 2–3 рази дорожче у більшості моделей; явно обмежуйте довжину відповіді через параметр max_tokens у кожному запиті

💡 Поради для кращого результату

Використовуйте prompt caching від Anthropic (префікс-кешування): якщо у вас великий незмінний системний промпт, додайте до нього тег cache_control: {"type": "ephemeral"} — Anthropic кешує цей блок на 5 хвилин і стягує лише 10% від звичайної ціни за кешовані токени при повторних запитах. Для підрахунку реальної вартості встановіть LangSmith (pip install langsmith) і підключіть до свого пайплайну через змінну середовища LANGCHAIN_TRACING_V2=true — він покаже точну вартість кожного кроку ланцюга в реальному часі. Замінюйте дорогі моделі на дешевші для простих задач: маршрутизуйте короткі класифікаційні запити на GPT-4o-mini (в 30 разів дешевше), а складні аналітичні — на GPT-4o. Зберігайте часто використовувані блоки контексту (наприклад, інструкції про продукт) у стисненому вигляді Base64 у векторній базі і розпаковуйте їх лише при потребі — це зменшує розмір зберігання і прискорює пошук.

❓ Часті запитання (FAQ)

1. Чи не погіршиться якість відповідей після стиснення промптів?
При правильному налаштуванні (rate 0.4–0.6) якість знижується незначно — дослідження Microsoft показують падіння на 1–3% за метриками точності. Якщо якість критична — тестуйте стиснені промпти на benchmark-наборі ваших реальних запитів перед деплоєм у продакшн.

2. Скільки реально можна зекономити на практиці?
Залежить від типу додатку: для чат-ботів із довгою історією — 40–60%, для документ-аналізу з RAG — 60–80%, для простих Q&A з кешуванням — до 50%. Найбільший ефект дає комбінація RAG + кешування + скорочення системного промпту одночасно.

3. Чи працюють ці техніки з локальними моделями (Ollama, LM Studio)?
Так, більшість технік не залежить від провайдера. RAG, стиснення промптів і управління пам’яттю діалогу однаково корисні для локальних моделей — там ви економите не гроші, а час виконання запиту і RAM.

4. Як часто потрібно оновлювати векторний індекс при зміні документів?
Використовуйте інкрементальне індексування: у LlamaIndex є RefreshSimpleIndexCommand, який перевіряє hash документів і переіндексує лише змінені файли. Для більшості продуктів достатньо запускати оновлення раз на добу через cron-задачу.

5. Що краще — зменшувати input чи output токени?
Output-токени зазвичай коштують у 2–4 рази дорожче, тому їхнє скорочення дає більший фінансовий ефект. Почніть із додавання явного обмеження max_tokens і чітких інструкцій про бажану довжину відповіді в промпті — це найшвидший спосіб зменшити витрати без складного технічного впровадження.

🏁 Підсумок

Після проходження цього туторіалу ви маєте робочий пайплайн із п’яти шарів захисту від зайвих витрат: вимірювання через tiktoken, стиснення промптів через LLMLingua, RAG замість повних документів, семантичне кешування через GPTCache і динамічне управління пам’яттю діалогу через LangChain. У сукупності ці техніки дають 50–70% економії токенів при мінімальних втратах якості.

Починайте прямо зараз із найпростішого: встановіть tiktoken і виміряйте топ-10 найдорожчих запитів у вашій системі — це займе 15 хвилин і одразу покаже, куди йдуть гроші. Після того як побачите реальні цифри, впровадьте RAG для найважчих документів — саме ця техніка в більшості проєктів дає найбільшу економію за найменших зусиль.