Два слоя кэша у AI gateway: как автор на Dev.to связывает L1, L2 и счёт за LLM
В материале tokenmixai на Dev.to речь идёт о двух слоях кэша у AI gateway — L1 и L2. Автор связывает их с темой счёта за LLM: до 90% расходов можно срезать именно за счёт кэширования, а не за счёт смены модели.
В анонсе к тексту он добавляет более приземлённый тезис: многие, кто гоняет трафик через OpenRouter или Portkey, по его словам используют лишь часть потенциальной экономии на кэше, а двухслойная схема в production якобы уводит «реальные» расходы на LLM примерно на 50–60%.
Ниже — пересказ того, как в полном тексте статьи разведены уровни кэша, чем типичные шлюзы отличаются от «результатного» слоя и какие оговорки автор закладывает в цифры и риски.
L1 и L2: кэш ответа и кэш префикса у вендора
По разбору на Dev.to L1 (result cache) — это кэш результата: при попадании запроса шлюз не вызывает upstream-модель. В кратком резюме у автора фигурирует формулировка про «100% savings per hit» при таком попадании.
L2 (prompt cache) — вендорский кэш промпта (в статье перечислены в том числе Claude, OpenAI, DeepSeek): снижение стоимости cached input tokens автор оценивает диапазоном 50–90%, но подчёркивает, что модель при этом всё ещё вызывается.
Отдельно он предупреждает, что разные подходы — semantic cache (в т.ч. в духе Helicone), vendor prompt caching и «Redis перед API» — дают разный профиль экономии и разный риск устаревания, и их нельзя смешивать в одну кучу.
Почему OpenRouter и Portkey часто оставляют «половину» экономии на кэше
В теле статьи прямо сказано: OpenRouter и Portkey по умолчанию не дают L1 — это pass-through gateways; многие команды получают в основном L2. Добавление L1 (в примере — Helicone или self-hosted Redis) накладывается на L2.
Это совпадает с мыслью из анонса: интеграция через популярные шлюзы не исчерпывает архитектуру кэша, если не выстроить второй слой поверх «прозрачного» маршрута к модели.
«Реальная» арифметика в примере на 10 млн запросов в месяц
В блоке про стоимость автор задаёт допущения (в том числе средние токены входа и выхода и модель Claude Sonnet 4.6 в этом сценарии) и считает вариант 10M запросов/месяц.
Без кэширования (baseline) в таблице получается $195 000/мес. Только L2 при указанной в статье доле попаданий в prefix cache (80%) даёт $119 700/мес, в тексте отмечено как −39% к baseline. L1 + L2 при 25% L1 hit и оставшемся потоке через L2 сводится к итогу порядка $90 050/мес (−54%) — как в посте.
Эти цифры автор подаёт как отдельный численный пример с явными допущениями; они не отменяют проценты из заголовка и анонса (90% и 50–60%) — это разные уровни утверждения в одном материале.
Риски: устаревшие ответы, нестабильный префикс и semantic cache
Автор отдельно выносит ограничения. Для L1 при динамическом контенте (новости, цены, персональные данные) риск — устаревший ответ из кэша. Для L2 нестабильный префикс промпта ломает попадания в кэш; рекомендуется смотреть метаданные провайдера по cached-токенам.
Для semantic cache — риск ложных срабатываний; как ориентир по порогу similarity в тексте названо 0.95+. В блоке про типичные ошибки для Claude упомянут короткий TTL кэша (5 минут) и влияние на повторную оплату write premium при паузах между запросами.
В конце поста на Dev.to также есть ссылка на более развёрнутый гайд на сайте автора; содержание той страницы отдельно не проверялось (переход по ссылке для самостоятельной верификации не выполнялся).
В подвале той же публикации TokenMix описан как gateway с OpenAI-совместимым доступом к «150+ LLMs» — это формулировка из первоисточника, а не независимый аудит каталога моделей.
Источники
-
tokenmixai. AI Gateway Caching Explained — Why L1 + L2 Cache Layers Cut 90% of Your LLM Bill — DEV Community, опубликовано 2026-04-21T03:25:42Z. Полный текст: Dev.to (дата доступа: 2026-04-21, 09:04:49 UTC).
-
В футере той же статьи на Dev.to приведена ссылка на дополнительный материал: https://tokenmix.ai/blog/ai-gateway-caching-l1-l2-guide-2026 — переход по ней для отдельной проверки содержимого не выполнялся; утверждения выше не опираются на эту страницу.