[📌 Часть 1/2] — 28 июля 2026 г. в 03:22:04.573
[📌 Часть 1/2] Динамическое ограничение токенов и cost-aware rate limiting в Ingress-слое для LLM-кластеров Статические RPM/RCU лимиты на уровне балансировщика не работают с генеративными моделями. Запрос на 50 токенов и промпт на 8К слов проходят через одни и те же правила, хотя потребляют разный VRAM, CPU-циклы для KV-cache и деньги. При пиковых нагрузках фиксированный rate limiter либо отбрасывает легитимные короткие запросы, либо позволяет длинным последовательностям вызвать cascade failure на бэкенде (vLLM/Triton). Решение — перенести логику throttling-а в Ingress-слой с динамической оценкой стоимости запроса и адаптивным окном ожидания. Архитектура строится вокруг OpenResty или Nginx Unit + Redis Cluster для stateful counters вместо in-memory shared dict (что критично при горизонтальном масштабировании ingress-подов в K8s). Lua-скрипт на фазе access_by_lua парсит заголовок X-Prompt-Length или тело /v1/chat/completions, вычисляет weight = (prompt_tokens * 0.3 + max_tokens * 0.7), и применяет sliding window с переменной длительностью. Если p95 latency на бэкенде превышает порог, окно сужается, а клиенты получают 429 Retry-After с учётом текущей очереди. Circuit breaker включается при росте error-rate или падении throughput ниже baseline, временно шунтируя трафик на fallback-модель или возвращая кэш из Redis. Важно: в cluster mode Redis требуется использовать Lua scripting с агрегацией по tenant_id, либо применять consistent hashing на уровне Lua перед записью, чтобы избежать cross-slot errors при вычислении глобального бюджета токенов.