Запуск LLM-ботов часто сопровождается эйфорией, которая длится ровно до получения первого счета от API-провайдера. Команды фокусируются на качестве системных промптов и задержке (latency), упуская из виду механику потребления ресурсов. Когда пользователь отправляет пятидесятое сообщение в чат, вы платите не за него. Вы платите за всю историю сессии, переотправленную заново. Если не внедрить жесткую обрезку контекста (truncation), безобидное «спасибо» в конце долгого диалога обходится проекту дороже, чем генерация объемной статьи.
Stateless-природа больших языковых моделей означает, что они не сохраняют состояние между запросами. Вся память диалога — это массив messages, который бэкенд формирует и передает при каждом HTTP-вызове. В этот момент запускается механизм квадратичного роста затрат.
Квадратичная ловушка токенов
Допустим, среднее сообщение пользователя и ответ модели суммарно занимают 100 токенов. На первом шаге в API улетает 100 токенов. На втором — история первого (100) + новое сообщение (100) = 200 токенов. На десятом шаге payload весит уже 1000 токенов.
Если пользователь делает 50 итераций в рамках одной сессии, общее количество обработанных токенов вычисляется как сумма арифметической прогрессии: (50 51 / 2) 100 = 127 500 токенов. Вместо ожидаемых 5000 токенов (50 сообщений по 100), мы сжигаем почти 130 тысяч. К этой цифре прибавляется системный промпт: если он весит 500 токенов, за 50 шагов он съест еще 25 000 токенов. Эта математика способна уничтожить юнит-экономику любого B2C-продукта на основе ИИ.
Когда проекты выходят на масштаб тысяч активных сессий, системе требуется бескомпромиссный механизм обрезки истории.
Эволюция алгоритмов Truncation
Уровень 1: Sliding Window (Окно скольжения)
Самый дешевый в реализации подход — жесткое ограничение глубины массива сообщений. Вы сохраняете только последние N пар запросов. Например, 5 реплик пользователя и 5 ответов ассистента.
Алгоритм пишется двумя строками кода через array_slice, но разрушается при столкновении с продакшеном. Пользователь вставляет в чат JSON-лог на 20 килобайт или копирует часть технической документации. Окно в 5 сообщений внезапно раздувается до 80 000 токенов. Модель падает с ошибкой context_length_exceeded, а провайдер выставляет счет за максимальный лимит контекста. Sliding Window применим исключительно в изолированных средах, где длина ввода строго валидируется на клиенте.
Уровень 2: Exact Token-based Truncation
Единственный надежный метод контроля истории — подсчет токенов перед сериализацией HTTP-запроса. Мы итерируем массив сообщений в обратном порядке (от самых свежих к самым старым) и аккумулируем счетчик токенов, пока не упремся в лимит, выделенный под историю.
В этом подходе инженеры сталкиваются с двумя препятствиями:
- Вычислительная сложность. Прогон Byte-Pair Encoding (BPE) токенизатора вроде
tiktokenна скриптовых языках (PHP, Python) в синхронном режиме создает неприемлемый overhead. Токенизация требует парсинга объемных словарей и замедляет Time-to-First-Token (TTFT). - Токены форматирования. Провайдеры применяют спецсимволы разметки под капотом. Каждое сообщение оборачивается в теги
user\n... Если посчитать исключительно полезный текст, алгоритм ошибется на 3-4 токена на каждом узле. В длинных диалогах эта погрешность накапливается, лимит пробивается, и запрос отбрасывается апстримом.
Корректная реализация подразумевает вынос токенизации в компилируемый микросервис (например, на Go). На уровне памяти фиксируется квота под системный промпт (он неприкосновенен), резервируется max_tokens для ответа модели, а на остаток «набираются» исторические сообщения. То, что не помещается в квоту, отбрасывается целиком (dropping) или обрезается на уровне строки.
Уровень 3: Саммаризация и семантическое сжатие
Для задач, где критично долгосрочное удержание контекста (например, ИИ-психолог или персональный ассистент), отбрасывание старых сообщений недопустимо. В таких системах внедряют саммаризацию. Устаревшие узлы диалога асинхронно прогоняются через компактную модель (уровня GPT-4o-mini), которая сжимает тысячи токенов текста в три информативных абзаца. Этот дайджест инжектируется в начало контекстного окна.
Основной риск этого метода — семантический распад (semantic decay). При регулярной саммаризации предыдущих саммари модель деградирует, стирая конкретные факты. Детали вроде "пользователь просил доставку на улицу Ленина, 5" превращаются в абстрактное "обсуждали логистику". Эффективное решение проблемы — построение иерархической памяти с выделением сущностей (Entity Extraction) в key-value хранилище, откуда факты подтягиваются в системный промпт лишь при релевантном контексте.
Контроль токенов в архитектуре RouterAPI
При проектировании RouterAPI задача финансовой предсказуемости стояла в приоритете. Оставлять контроль контекста на стороне клиентского кода — значит рисковать инфраструктурным бюджетом. Управление токенами и жесткая тарификация встроены в архитектуру платформы.
RouterAPI проверяет размер payload на стороне шлюза до отправки запроса к модели. Если размер messages превышает установленные инфраструктурные лимиты, соединение обрывается до проксирования к апстриму — вы не платите за заведомо слишком большой запрос. Это отсекает "мусорные" мегабайтные запросы.
Ключевой фокус сделан на финансовую прозрачность и нормализацию биллинга. В RouterAPI процесс тарификации опирается на компонент система тарификации RouterAPI, который адаптирует долларовую математику под рублевую экономику. В зависимости от маршрутизацию применяются разные стратегии маршрутизации:
Нормализатор выравнивает цены на клиентском уровне, гарантируя минимальный порог списания (floor rate) в 10 ₽ за миллион токенов. Это страхует систему от отрицательной юнит-экономики при резких скачках курсов валют или маршрутизации в сверхдешевые модели.
Каждая транзакция строго связывается с metadata.маршрутизацию. Для агрегации этой статистики в административных дашбордах используется аналитику RouterAPI. При обработке исторических финансовых массивов вскрылся важный архитектурный нюанс работы с базой данных: категорически запрещено оставлять открытыми небуферизованные MySQL-потоки (такие как cursor), пока PHP-процесс агрегирует логи токенов. Открытый cursor блокирует коннект; если параллельно выполняются другие запросы аналитики, система исчерпывает пул подключений, выбрасывает SQLSTATE[HY000]: 2014 и провоцирует резкие скачки потребления RAM (memory spikes). В RouterAPI агрегация токенов реализована через строго ограниченные чанки (пакетную обработку) и перенос математических вычислений на уровень SQL-запросов.
Главные KPI дашборда строятся исключительно на реальном cashflow — фактических пополнениях (клиентских депозитах), комиссиях эквайринга Т-Банка, уплаченных налогах и COGS апстримов. Учет идет в реальных деньгах, а не в "токенах в вакууме", что дает бизнесу подлинную картину рентабельности.
Резюме
Обрезка истории — не просто опциональный тюнинг, а фундаментальный предохранитель финансовой устойчивости ИИ-продукта. Отправляя массив messages к API, архитектура должна гарантировать точный контроль объема отправляемых данных, предсказуемость тарифа и четкое понимание узла, на котором диалог будет принудительно усечен.
Внедряйте строгий Token-based Truncation. Резервируйте жесткие лимиты на шлюзах, написанных на компилируемых языках. Откажитесь от тяжелых транзакций в базе при агрегации токенов. RouterAPI предоставляет эти механизмы из коробки, позволяя инженерам фокусироваться на бизнес-логике, а не на микроменеджменте контекстного окна и паническом аудите биллинга.