Как сократить расходы на LLM: компрессия логов и данных снижает токены на 60-95%

Я — Денис Шохирев, архитектор Enterprise AI из Эрлангена. В DennisCraft AI Studio я внедряю AI-системы для заказчиков из DACH (логистика, финтех, индустриальная автоматизация) на стеке Claude, Supabase, n8n, Doppler, self-hosted Postgres и защищённых пайплайнах. На одном из недавних проектов бюджет на inference вырос на 60% за месяц — выяснилось, что LLM-подсистемы "едят" токены не из-за промптов, а на логи и внутренние данные. Решаем на практике: компрессия логов и данных до 95% экономит бюджет без потерь в контроле.

Почему логи и данные становятся главным пожирателем токенов

Когда вы запускаете production-агентов на базе LLM, расходы на токены быстро уходят за пределы демо-уровня. В системах с traceability (например, для финтеха или индустриального контроля) в prompt часто добавляются логи событий, истории транзакций, данные пользовательских сессий. На практике — ядро prompt может занимать 200-400 токенов, а "контекст" (логи, события, цепочки состояний) — 3-10 тысяч. На одном проекте агент, который обрабатывает запросы к IoT-парку, генерировал до 12К токенов на один inference, из них 10К — только на trace-данные. Причина — неструктурированные JSON-логи, длинные stack traces, дублирование данных между шагами.

Методы компрессии: что реально работает

1. Семантическая агрегация логов

Вместо хранения и передачи "сырых" логов (JSON, stack traces) — собираю события в агрегированные блоки. Пример: из 100 событий за 10 минут делаю 3-5 ключевых state transitions, описанных коротко (на уровне "User X changed Y to Z, status: OK"). В среднем это уменьшает объём токенов на 60-75%. Для автоматизации — использую n8n-workflow, который парсит и резюмирует логи по ключевым событиям, а не по строкам.

2. Использование специализированных инструментов сжатия

Стандартные JSON- или plain-text-логи легко ужимаются через LZ-string, Brotli или zlib — но перед подачей в LLM данные надо декодировать. Для production-агентов использую следующий паттерн:

import brotli
import json

def compress_log(log_dict):
    json_str = json.dumps(log_dict, ensure_ascii=False)
    return brotli.compress(json_str.encode('utf-8'))

def decompress_log(compressed):
    return json.loads(brotli.decompress(compressed).decode('utf-8'))

Такой подход полезен для хранения, но для передачи в LLM важнее — убрать избыточные поля и сокращать ключи на этапе сериализации. Реальное сокращение — до 85% в среднем, если ключи короткие и удалены пустые значения.

3. Синтаксическое и лексическое сжатие

В больших цепочках событий часто встречаются одинаковые шаблоны ("user_id": "123", "event": "clicked", "timestamp": "…"). Использую короткие ключи ("u": "123", "e": "c", "t": "…") и уплотнение по типу RLE (run-length encoding) для повторяющихся однотипных событий.

def rle_events(events):
    compressed = []
    prev = None
    count = 1
    for ev in events:
        if ev == prev:
            count += 1
        else:
            if prev is not None:
                compressed.append({'event': prev, 'count': count})
            prev = ev
            count = 1
    if prev:
        compressed.append({'event': prev, 'count': count})
    return compressed

На реальных workflow этот метод уменьшает длину event-цепочек на 70-90% без потерь для LLM-контекста.

Как внедрять компрессию в production-пайплайн

Стадии пайплайна

В Supabase и self-hosted Postgres храню только сжатые версии логов, а для передачи в prompt — декомпрессия и агрегация.

Автоматизация через n8n и Supabase

В n8n собираю workflow: после каждого шага лог проходит через custom Python-узел (как выше), затем сохраняется в Supabase. Для сложных агентов, где traceability критична (финтех, regulated markets), компрессия обязательна для прохождения аудита.

Сравнение: что дают разные методы на практике

FAQ

Что делать, если требуется полный trace для аудита?

Сохранять полные логи в Postgres, но для LLM-подсистемы использовать только агрегированные и сжатые куски. При необходимости восстанавливать цепочку для аудита — по ID событий.

Какие риски при агрегации логов?

Можно потерять детали, критичные для расследования инцидентов. Поэтому агрегирую только повторяющиеся и рутинные события, а ключевые ошибки оставляю полностью.

Как автоматизировать компрессию на пайплайне?

n8n + custom Python-узлы для сжатия и агрегации, Supabase для хранения. Workflow строится за день-два для типовых сценариев.

Есть ли минусы у сжатия Brotli/zlib?

Дополнительное время на декомпрессию (10-50 мс на событие), но в production-нагрузке это некритично.

Как интегрировать компрессию с Claude Code и другими LLM?

Ключевой этап — сериализация данных до передачи в prompt. Важно — не передавать бинарник Brotli напрямую в prompt, а только декомпрессированные и агрегированные данные.

В каких частях вашего пайплайна логи становятся главным источником расхода токенов — на этапе передачи в prompt, или при хранении? Интересно сравнить с вашими кейсами. Я делаю бесплатный 30-мин аудит AI-стека для DACH-фаундеров — пишите в LinkedIn или @ger_dennis_ai.