Кэширование, fallback и rate limiting

Короткая версия

Устойчивый LLM stack обычно строится из трёх слоёв:

1. Caching
2. Fallback / graceful degradation
3. Rate limiting + queueing

Что стоит делать

• exact cache для идентичных запросов;
• semantic cache для low-risk FAQ и повторяющихся задач;
• provider-side prompt/context caching для длинного стабильного префикса;
• fallback только между совместимыми lanes;
• локальные лимиты ниже лимитов провайдера;
• очередь и backoff вместо спама повторными запросами.

Что не стоит делать

• кэшировать ответы с user-specific state без явного keying;
• слепо переключаться между несовместимыми моделями;
• использовать один cache policy для FAQ и high-stakes решений;
• ждать 429 от провайдера и только потом думать о throttling;
• считать, что fallback решает проблему качества, а не только доступности.

Сценарий:
1. Запрос FAQ сначала идёт в exact cache
2. Если miss — в semantic cache
3. Если miss — в основную cheap model
4. Если timeout — в совместимый fallback lane
5. Если все провайдеры недоступны — вернуть stale cache или controlled apology

Что это даёт?

1. Кэширование: это не один механизм, а несколько слоёв

В LLM-системах полезно различать минимум три типа кэша:

Это не взаимоисключающие техники. В хорошем production stack они работают вместе.

Exact cache

Exact cache хорош там, где вход можно считать детерминированным:

• fixed prompt + same user input;
• RAG without per-user private state;
• formatting/transformation tasks;
• repeated background jobs.

Плюсы:

• почти мгновенный hit;
• простая инфраструктура: Redis, Memcached, KV;
• нулевой риск ложного semantic match.

Минусы:

• низкий hit rate, если пользователи перефразируют запрос;
• легко сломать key design и получить wrong reuse.

Semantic cache

Semantic cache уместен только там, где цена ложного совпадения приемлема:

• support FAQ;
• internal assistants;
• low-risk knowledge lookup;
• repetitive triage/classification.

Не стоит без жёстких guardrails использовать его для:

• юридических ответов;
• медицинских рекомендаций;
• финансовых решений;
• user-specific reasoning.

Provider-side caching

Anthropic даёт prompt caching, OpenAI и другие провайдеры поддерживают cached input / stable prefix economics, а gateway-слой вроде Helicone может добавлять response caching над провайдерами.

Практически это значит:

• system prompt;
• policy blocks;
• tool specs;
• большие документы;
• повторяющийся retrieval prefix

лучше рассматривать как cacheable prefix, а не как обычный input на каждый запрос.

2. Ключевая проблема caching: инвалидация и ключи

Большинство production-багов в caching — не в самом Redis, а в плохом cache key design.

В cache key обычно должны попадать:

• model family или deployment;
• system prompt version;
• user locale;
• retrieval corpus version;
• safety / policy version;
• tenant or account scope;
• формат ответа или schema version.

Если этого не сделать, кэш может вернуть:

• ответ от старого system prompt;
• ответ из другого tenant;
• ответ в неправильном формате;
• устаревшую policy.

3. Fallback: цель не просто выжить, а сохранить контракт

Старая статья про fallback обычно говорит: “если Claude упал, переключись на OpenAI, потом на Gemini”. Но в 2026 это слишком упрощено.

Нужно различать три сценария:

1. Provider failover
2. Model downgrade
3. Graceful degradation

Provider failover

Подходит, когда у вас есть две модели с совместимым API-поведением и output contract.

Пример:

• основной lane: Claude Sonnet 4.6
• fallback lane: GPT-5.4 mini
• оба маршрута возвращают одинаковую JSON schema

Model downgrade

Это не аварийный failover, а контролируемый переход на более дешёвую или более быструю модель:

• GPT-5.4 -> GPT-5.4 mini
• Claude Sonnet 4.6 -> Claude Haiku 4.5
• Gemini 2.5 Flash -> Gemini 2.5 Flash-Lite

Чаще используется под load shedding и budget protection.

Graceful degradation

Если ни один совместимый provider path не доступен, лучше вернуть:

• stale cached answer;
• partial result;
• queued result;
• controlled apology with retry window;
• human handoff.

Это намного лучше, чем молча переключиться на несовместимую модель и сломать downstream workflow.

4. Как проектировать compatibility-safe fallback

Хорошая fallback-цепочка строится не по брендам, а по lanes:

Нужно, чтобы внутри lane совпадали:

• schema / output contract;
• max token expectations;
• safety posture;
• tool availability;
• context assumptions.

Именно поэтому fallback обычно проектируют не как один giant list моделей, а как несколько совместимых pools.

5. Rate limiting: думайте не как “ловим 429”, а как traffic shaping

OpenAI и другие провайдеры лимитируют доступ через RPM/TPM и usage tiers. В продакшене лучше держать локальный limiter ниже лимитов провайдера.

Практический baseline:

• локальный лимит = 70-85% от provider cap;
• очередь для всплесков;
• отдельные лимиты по tenant / endpoint / feature;
• backoff и cooldown на аварийные paths;
• observability по 429, queue delay, drop rate и retry rate.

Почему queue-first лучше

Если пользовательский трафик идёт прямо в API без буфера, вы получаете:

• bursty 429;
• каскад retries;
• рост latency;
• нестабильный UX.

Если есть queue, вы получаете:

• предсказуемую деградацию;
• controllable backlog;
• честный retry window;
• возможность shed low-priority workload.

6. Retry и backoff: не усугубляйте аварию

Повтор запроса полезен только если:

• ошибка временная;
• запрос idempotent;
• вы понимаете retry budget;
• не создаёте retry storm.

Правильный pattern:

• retry only for retryable errors;
• exponential backoff;
• jitter;
• circuit breaker после серии фейлов;
• separate policy для interactive и batch workload.

7. Что стоит мониторить

Без observability caching и fallback быстро превращаются в иллюзию устойчивости.

Минимальный набор метрик:

• cache hit rate: exact / semantic / provider-side;
• stale cache rate;
• fallback rate;
• fallback success rate;
• schema break rate after fallback;
• local queue depth;
• 429 rate;
• retry count;
• p95 / p99 latency.

Production-паттерны

Exact cache на Redis

import hashlib
import json
import redis

class LLMCache:
    def __init__(self, redis_url: str = "redis://localhost:6379", ttl: int = 3600):
        self.redis = redis.from_url(redis_url)
        self.ttl = ttl

    def _key(
        self,
        model: str,
        prompt_version: str,
        schema_version: str,
        tenant: str,
        payload: dict,
    ) -> str:
        raw = json.dumps(
            {
                "model": model,
                "prompt_version": prompt_version,
                "schema_version": schema_version,
                "tenant": tenant,
                "payload": payload,
            },
            sort_keys=True,
        )
        return hashlib.sha256(raw.encode()).hexdigest()

    def get(self, **kwargs):
        key = self._key(**kwargs)
        value = self.redis.get(key)
        return json.loads(value) if value else None

    def set(self, response: dict, **kwargs):
        key = self._key(**kwargs)
        self.redis.setex(key, self.ttl, json.dumps(response))

Compatibility-aware fallback

FALLBACK_POOLS = {
    "support_json": [
        "primary-support-model",
        "secondary-support-model",
    ],
    "cheap_faq": [
        "primary-cheap-faq-model",
        "secondary-cheap-faq-model",
    ],
}

def pick_pool(task_type: str) -> str:
    if task_type == "faq":
        return "cheap_faq"
    return "support_json"

LiteLLM router

from litellm import Router

router = Router(
    model_list=[
        {
            "model_name": "support-json",
            "litellm_params": {
                "model": "anthropic/YOUR_PRIMARY_MODEL_ID",
                "api_key": "env/ANTHROPIC_API_KEY",
            },
        },
        {
            "model_name": "support-json-fallback",
            "litellm_params": {
                "model": "openai/YOUR_SECONDARY_MODEL_ID",
                "api_key": "env/OPENAI_API_KEY",
            },
        },
    ],
    fallbacks=[
        {"support-json": ["support-json-fallback"]},
    ],
    num_retries=2,
    timeout=12,
)

Queue-first limiter

import asyncio
import time
from collections import deque

class RateLimiter:
    def __init__(self, rpm_limit: int, tpm_limit: int):
        self.rpm_limit = rpm_limit
        self.tpm_limit = tpm_limit
        self.request_times = deque()
        self.token_usage = deque()
        self.lock = asyncio.Lock()

    def _cleanup(self):
        cutoff = time.time() - 60
        while self.request_times and self.request_times[0] < cutoff:
            self.request_times.popleft()
        while self.token_usage and self.token_usage[0][0] < cutoff:
            self.token_usage.popleft()

    async def acquire(self, estimated_tokens: int):
        while True:
            async with self.lock:
                self._cleanup()
                current_rpm = len(self.request_times)
                current_tpm = sum(tokens for _, tokens in self.token_usage)
                if current_rpm < self.rpm_limit and current_tpm + estimated_tokens < self.tpm_limit:
                    now = time.time()
                    self.request_times.append(now)
                    self.token_usage.append((now, estimated_tokens))
                    return
            await asyncio.sleep(0.25)

Retry с jitter

import asyncio
import random

async def retry_with_backoff(fn, retries: int = 3, base_delay: float = 1.0):
    for attempt in range(retries + 1):
        try:
            return await fn()
        except Exception:
            if attempt == retries:
                raise
            delay = min(base_delay * (2 ** attempt), 20.0)
            delay += random.uniform(0, 0.3 * delay)
            await asyncio.sleep(delay)

Практический шаблон

У нас support assistant. 30% запросов повторяются, иногда ловим 429, а fallback с Claude на OpenAI ломает JSON parser. Что делать?

Проверьте себя