Кэш кэш кэш... Есть одна история, которая сильно влияет на экономику и скорость 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 и Гугла он есть) - Люди которые считают стоимость модели по стоимости токенов без учета скидки за кэш у вендора