Как сократить расходы на LLM: техника prompt-pruning для длинных контекстов

Системы на больших языковых моделях ломаются не потому, что «забывают», а потому что помнят слишком много. Этот тезис инженер Emmimal P Alexander вынесла в статью для Towards Data Science от 11 июля 2026 года вместе с рабочим решением для оптимизации длинных контекстов: детерминированным слоем prompt-pruning, который срезает до 34% входных токенов у агентов с большим числом инструментов и укладывается в 50 мс даже на диалоге в 131 000 токенов. Так вы можете сократить расходы на LLM без потери качества.

Почему длинный контекст стоит денег на каждом ходу

Промпт в долгоживущей ИИ-системе устроен как append-only лог: диалог только растёт. К 50-му ходу в него натекает мусор, устаревшие выводы инструментов, дублирующиеся RAG-фрагменты, старые результаты SQL-запросов, разовые пользовательские настройки. И всё это пересылается модели заново на каждом запросе.

Счётом за API проблема не исчерпывается. Alexander ссылается на два исследования: качество рассуждений падает с ростом длины ввода даже когда добавленный текст нерелевантен, а модели хуже используют информацию, «зарытую» в середине длинного контекста, чем ту, что у краёв, это эффект lost in the middle. Раздутый промпт бьёт по стоимости, задержке и незаметно роняет качество ответов.

Большое окно не значит дешёвое

Иллюзию про гигантские контекстные окна стоит развеять. Да, топовые модели 2026 года принимают сотни тысяч и миллионы токенов. Но вы платите за каждый входной токен. Перекачивать 131k токенов на каждом ходу значит сжигать деньги на повторную отправку того, что модель уже видела. Оптимизация длинных контекстов напрямую влияет на то, удастся ли сократить расходы на LLM.

Почему обычное усечение: плохая идея

Самый популярный способ борьбы с раздутым контекстом, наивное усечение «оставить последние N сообщений», молча рвёт цепочки зависимостей.

Пример из статьи это показывает. На 3-м ходу пользователь просит формат CSV. На 47-м говорит «экспортируй результаты». При окне в 20 ходов инструкция про CSV уже выпала, и система не понимает, в каком формате экспортировать. Это была не устаревшая деталь, а жёсткая зависимость. Позиционное усечение смотрит только на порядковый номер сообщения, поэтому не отличает старый-ненужный контекст от старого-но-важного.

Три прохода prompt-pruning

Подход Alexander держится на детерминизме. Никаких вызовов LLM, эмбеддингов и внешних зависимостей, только стандартная библиотека. Каждое решение об обрезке воспроизводимо: одинаковый вход даёт одинаковый выход. Конвейер чистит состояние до отправки промпта модели и работает в три прохода.

1. Expired Context Elimination удаляет «протухший» контекст: то, что помечено как одноразовое или уже неактуальное.
2. Duplicate Context Elimination выкидывает дубликаты: повторяющиеся RAG-фрагменты, одинаковые выводы инструментов.
3. Dependency Restoration восстанавливает зависимости и гарантирует, что не будет удалено то, от чего зависит более позднее сообщение.

Третий проход и делает первые два безопасными. Он спасает инструкцию про CSV с 3-го хода, когда на 47-м всплывает запрос на экспорт. Без него агрессивная обрезка так же слепа, как и усечение.

Экономия токенов: где обрезка даёт 2%, а где 34%

Эффект зависит от типа нагрузки. Alexander прогнала 15 конфигураций (3 типа нагрузки × 5 размеров диалога) на двух разных машинах.

Логика понятна: в живом чате мало повторов и «протухших» данных, обрезать почти нечего. А RAG-система и tool-агент постоянно тянут дублирующиеся фрагменты и устаревшие выводы, там и прячется треть промпта, а с ней и основной резерв, чтобы сократить расходы на LLM.

По скорости: даже при 2000 ходов и 131 000 токенов препроцессинг занимал менее 50 мс. Для продакшена это шум на фоне сетевой задержки самого запроса к модели.

Почему слою prompt-pruning можно доверять в проде

Для боевой эксплуатации его делают пригодным два свойства. Идемпотентность: система достигает стабильной неподвижной точки за один проход, повторная обрезка уже обрезанного промпта ничего не меняет. И сохранность обязательных фактов: все размеченные required facts выжили во всех прогонах. К статье приложено 35 тестов, полный код и сырой вывод терминала.

Alexander честно рассказала про два бага, которые изменили дизайн. Первый корпус с фиксированным числом дублей давал падение процента сокращения по мере роста диалога, сценарий нереалистичный, и синтетику пришлось переделывать. А логику восстановления зависимостей поначалу вообще не тестировали: синтетические данные не создавали кейс, где действительно удаляется нужное сообщение. Тот случай, когда «зелёные тесты» ничего не проверяли.

Что это значит для self-hosted LLM на VPS

Техника особенно интересна тем, кто гоняет модели у себя. Если вы держите self-hosted LLM на арендованном VPS, обрезка на своей стороне снижает нагрузку на инференс и расход памяти под контекст: меньше токенов на вход, меньше вычислений на каждом шаге. Весь pruning идёт локально, без обращения к внешним сервисам. Это важно, если данные диалога чувствительные: ничего не утекает на сторонние API ради оптимизации.

Prompt-pruning не конкурирует с prompt caching у крупных провайдеров, а дополняет его. Кеширование экономит на повторной обработке одинакового префикса; обрезка уменьшает сам объём, который нужно отправлять и хранить. Комбинируйте их, чтобы сильнее сократить расходы на LLM.

Как попробовать prompt-pruning у себя

Репозиторий с реализацией открыт: github.com/Emmimal/prompt-pruning-layer. Логика строится вокруг тех же трёх проходов. Главный совет от автора: не верьте зелёным тестам на слово, отдельно проверьте dependency restoration на кейсе, где нужное сообщение реально удаляется и должно быть восстановлено. Этот проход отличает безопасную обрезку от порчи диалога.

FAQ по prompt-pruning и экономии токенов

Чем prompt-pruning отличается от обычного усечения?

Усечение отрезает старые сообщения по позиции и вслепую рвёт зависимости. Pruning удаляет только устаревшее и дублирующееся, а третий проход восстанавливает всё, от чего зависят поздние сообщения.

Нужны ли для этого эмбеддинги или отдельная модель?

Нет. Подход детерминированный: без вызовов LLM, без эмбеддингов и внешних зависимостей, только стандартная библиотека. Поэтому решения об обрезке воспроизводимы.

Насколько это замедляет запрос?

Почти незаметно: даже на 2000 ходов и 131 000 токенов препроцессинг занимал менее 50 мс.

Где эффект максимален?

У tool-агентов и RAG-ассистентов, 27-34% экономии токенов. В обычном чате всего 2-4%, там мало повторов и мусора.

Источники

Towards Data Science, Emmimal P Alexander о безопасном слое prompt-pruning для LLM-систем

GitHub, репозиторий prompt-pruning-layer с кодом и тестами