Короткий промпт ≠ дешёвый промпт: как оптимизация ломает prefix cache в LLM-агентах

В сфере искусственного интеллекта произошло заметное событие. Ser_no 6 минут назад Короткий промпт ≠ дешёвый промпт: как оптимизация ломает prefix cache в LLM-агентах Средний 12 мин 15 Блог компании Битрикс24 Искусственный интеллект Машинное обучение * Привет, Хабр! Меня зовут Сергей Нотевский, я AI Platform Lead в Битрикс24. Это третья статья серии про prefix caching: первая - про экономику кэширования и особенности разных провайдеров, вторая - про антипаттерны в простых сценариях.

А здесь про то, как та же механика работает против вас в агентном цикле. TL;DRЕсли на каждом шаге менять tools, system prompt или ранние блоки context, prefix cache будет часто начинаться заново. Поэтому большой, но стабильный список tools иногда дешевле, чем маленький список, который постоянно пересобирается.

Технические детали

Для своего инференса часто работает схема «стабильные tools в промпте + masking / constrained decoding». Для API-провайдеров стоит смотреть на allowed_tools, tool_search, defer_loading или фиксированные наборы tools по маршрутам. Минимальный guardrail: логировать cached_tokens / cache_read_input_tokens, prefix_hash, tools_count и алертить при падении cache hit rate.

Если у агента 30+ tools, первое желание - не тащить их все в каждый запрос. Отобрать 5-7 релевантных на текущем шаге, убрать лишний шум, сделать промпт короче. На уровне одного запроса это выглядит как очевидный выигрыш по стоимости и скорости.

Проблема начинается там, где запрос перестает быть одиночным. В агентском цикле оптимизация работает уже на цепочке из 10, 20, 50 вызовов. И там внезапно оказывается, что короткий промпт может быть дороже длинного.

Отраслевые последствия

Под эффективной стоимостью дальше я имею в виду стоимость после учета cache hits и cache misses, а не просто сырое число входных токенов. Упрощённо симптом в логах выглядит так. Системный промпт не меняется, история растет append-only, но cached_tokens почти каждый раз начинаются заново:ШагToolsPrefix hashCached132a91f…0232a91f…41 80037c03b…1 200498aa1…90056f17c…1 100На бумаге все стало лучше: tools меньше, промпт короче.

В логах - наоборот: модель получала новый префикс почти на каждом шаге. Для человека это тот же агент с другим набором доступных действий. Для prefix cache - новый промпт.

А вот как выглядит та же сессия, если список tools оставить стабильным и ограничивать доступность отдельно:ШагToolsСтратегияPrefix hashCached132все toolsa91f…0232все toolsa91f…41 800332+ maskinga91f…45 200432+ maskinga91f…48 900532+ maskinga91f…52 100Tools стало больше. Эффективная стоимость - ниже. Почему короткий промпт проигралВ обычном одиночном запросе к модели все довольно просто: системный промпт, сообщение пользователя, ответ.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.