Кэш кэш кэш...
Есть одна история, которая сильно влияет на экономику и скорость llm в проде и при этом имеет, на первый взгляд одновременно супер простое применения. Как это модно называть «быстрая победа».

Я про префикс-кэш (prefix_cache).
Идея одним предложением: если начало вашего запроса к модели повторяется - вы перестаёте каждый раз заново “прогревать” модель этим началом. И внезапно улучшается и latency, и cost.

И я искренне удивляюсь, когда инженеры-строители ai-сервисов пренебрегают этим*
Это же не 3% оптимизации (хотя конечно 3% это тоже очень много), а жирная ручка, которая при правильной архитектуре запроса позволяет сэкономить десятки процентов костов.

Попадать в кэш (cache hit rate) настолько важно, что про это пишут уважаемые дяди и компании в своих статьях:
- В летней статье Manus, про опыт вынесенный с построения их агента, первое по важности о чем говорит автор - попадать в кэш.
- Тиктоки рассказывают как оптимизировали своего внутреннего ai-агента и получили 40–50% экономии "за считанные строки кода".

По факту все что нужно сделать это:
1. Следить за тем чтобы префикс был стабильным. Классика жанра - timestamp где-нибудь в начале. Дату указали, скидку отменили.
2. Контекст по возможности наращиваем (Append-only).
3. В случае с локальным хостингом чуть сложнее - нужно самим регулировать куда вести запросы так чтобы они лучше попадали в кэш (тут помогут всякие ray serve, или хотя бы разделение пулов с инстансами vllm).
4. В случае с maas - соблюдать условия кэша (напр. OpenAI кэширует автоматом одинаковый префикс больше 1к токенов в запросах чаще 5 минут), либо помечать блоки кэша насильно (Claude и один из вариантов кэшей Gemini).

*Ладно, еще удивляют 2 другие вещи по кэшу:
- Вендоры которые не предоставляют возможность использовать префикс кэш (у OpenAI, Anthropic и Гугла он есть)
- Люди которые считают стоимость модели по стоимости токенов без учета скидки за кэш у вендора