Comments 9
Самое, я думаю, главное — Ии не заинтересован оптимизировать свою работу при оплате за токен. Это ваша боль...
Да, экономика у провайдера тут действительно забавная: чем толще мы собрали запрос, тем больше заплатили 🙂
Но я бы не перекладывал всё на модель. API обрабатывает ровно то, что в него отправил агентский рантайм. Если клиент каждый раз прикладывает старые логи, файлы и двадцать ненужных схем инструментов, провайдер честно всё это посчитает.
Поэтому контролировать мусор должен тот, кто собирает контекст. Собственно, из этой боли Trim и вырос.
Длинный контекст плох не только ценой: качество ответа деградирует
И оптимальный размер кеша далеко от предлагаемого миллиона. Я сбрасываю гораздо раньше когда задача кончается
Да. И качество обычно начинает деградировать раньше, чем приходит страшный счёт: нужный факт просто тонет в старых логах, повторных чтениях и закрытых тупиках.
И уточню: миллион в статье — не предлагаемый размер кеша, а как раз антипример. До чего способна раздуться сессия, если позволить ей жить без границ.
Живой тест показал ещё неприятнее: универсальный архив тоже не решение. На короткой сессии служебный слой съел больше, чем сэкономил. Поэтому сейчас логика ближе к вашей: закончился смысловой этап — старое сворачиваем; понадобилась конкретная деталь — агент дочитывает локальный оригинал.
А по какому сигналу вы сбрасываете: завершение задачи, смена ветки или порог по токенам?
И то и другое, что наступит раньше.
Для длинных задач модель пишет handover, я иногда читаю, потом сжимаю контекст когда завершен пункт или хотя бы подпункт плана.
Держу объём контекста между 150 и 500 тыщ в зависимости от длины рассуждений и длины жизни контекста.
А длина сессии бесконечная, на всю жизнь проекта. Ухудшения не заметил.
Да это вроде общепринятая практика. Антропик так и рекомендует
Спасибо, это полезная деталь. Забрал себе как отдельную гипотезу: handover на границе пункта плана против сжатия по порогу и нового чистого окна Прогоню A / B по стоимости, cache hit и потере фактов.
А handover у вас свободным текстом пишется или есть фиксированная структура - цель, сделанное, решения, открытые вопросы и следующие шаги?
Интересный вопрос.
Не часто туда смотрел.
Модель туда пишет обычно как в лог append only кратко какие задачи были, что он сделал и что не сделано - дальнейший план. Поэтому, форматирование так себе. Каждое 10 примерно сжатие я прошу его самого сжать, убрав неактуальное, остальное сжав и отформатировав.
цель, сделанное, решения, открытые вопросы и следующие шаги
Да, по факту он сам так и сделал
если не секрет какой у вас провайдер и какая модель?
я в своё время, работая в hermes задался целью создать некий оптимизатор огромных сессий
но в процессе экспериментов выяснил, что даже огромный контекст у провайдера на 95% ложится в кэш а кэш считается по очень низкой цене.
а если править контекст, если изменится хоть что то в контексте, то весь измененный контекст промахнется мимо кэша и посчитается по цене новых токенов.
и получается, что ничего не трогать и полагаться на кэш провайдера получается дешевле.
И проблемы начинаются только когда контекст растёт за пределы размера окна модели. но в гермес для этого есть инструмент "compress", который если поднастроить работает очень неплохо. он отправляет модели запрос суммаризировать по определенным правилам весь предыдущий диалог, не трогая N последних сообщений. после отработки компресса с точки зрения провайдера это кэш мисс и новая сессия но это происходит редко, у меня настроено на 75% заполнения окна модели. а окно - миллион
ну и само собой правило - одна задача одна сессия. тянуть бесконечные сессии смысла не имеет
Модель gpt-5-6-sol, провайдера не раскрываю. Я развиваю API сервис доступа к моделям, поэтому здесь как раз упёрся в экономику маршрута KV кеш у поставщика работает, cached tokens мы видим, но скидки за cache hit в закупочном списании нет. Повтор с 91% попаданием стоил практически столько же, сколько холодный запрос. Передать клиенту скидку, которой сам не получил, я не могу поэтому уменьшаю именно физически отправляемый контекст: на шлюзе и локально рядом с агентом.
Небольшое уточнение: изменение контекста не всегда сбрасывает кеш целиком обычно сохраняется неизменный префикс, а промах начинается после первой изменённой части. Но при удалении старой истории из начала действительно можно потерять почти весь hit. Поэтому сейчас проверяю cache-aware правило: когда выгоднее ничего не трогать, а когда физическое сокращение уже окупает потерю префикса.
А ваши 95% подтверждались одновременно полями usage и фактическим списанием баланса?
Почему ИИ-агент сжигает токены: как я снизил стоимость сессии с 48 до 8 рублей