Что хотят услышать интервьюеры:

Нужно показать умение спроектировать изолированный multi-tenant сервис для LLM с учетом справедливого распределения ресурсов, ограничений по подписке и защиты от noisy neighbor. Важно, чтобы архитектура поддерживала аутентификацию, авторизацию, биллинг, rate limiting, квоты и наблюдаемость. Хороший ответ должен явно разделять глобальные лимиты платформы и лимиты конкретного tenant'а.

Определение:

Multi-tenant LLM-сервис — это платформа, где один и тот же backend обслуживает несколько клиентов, но данные, лимиты и доступ каждого клиента изолированы на логическом уровне. Rate limit ограничивает частоту запросов, а quota ограничивает объем потребления за период, например токены, запросы или деньги в рамках подписки. Для LLM-сервиса обычно нужно учитывать несколько метрик одновременно: запросы в секунду, количество токенов, длину контекста, число параллельных генераций и месячный бюджет.

Пример использования:

Допустим, у компании есть три тарифа: Free, Pro и Enterprise. Free получает 20 запросов в минуту и 100k токенов в месяц, Pro — 200 запросов в минуту и 5M токенов, Enterprise — индивидуальные лимиты и приоритетную очередь. При всплеске нагрузки система пропускает запросы в пределах лимита, а сверх него возвращает 429 или переводит часть запросов в деградированный режим, например с меньшим приоритетом или меньшей длиной ответа.

Client -> API Gateway -> AuthN/AuthZ -> Tenant Context
                              -> Rate Limit Check
                              -> Quota Check
                              -> Request Queue / Scheduler
                              -> LLM Inference Service
                              -> Usage Metering -> Billing / Analytics

Пояснение кода:

Код не требуется: это задача системного дизайна. Логика работы выглядит так по шагам: сначала запрос аутентифицируется, затем по API key или JWT определяется tenant и его план подписки. После этого сервис проверяет два уровня ограничений: краткосрочный rate limit и долговременную quota. Если обе проверки успешны, запрос попадает в очередь или напрямую в inference-пайплайн; после завершения выполнения фиксируется фактическое потребление токенов и обновляется usage ledger.

Ключевые моменты:

Изоляция tenant'ов должна быть на уровне данных, лимитов, логов и биллинга.
Rate limit и quota — разные механизмы: первый защищает от всплесков, второй ограничивает общий расход за период.
Для LLM важно учитывать не только число запросов, но и токены, контекст, параллелизм и стоимость генерации.
Нужен centralized usage metering, чтобы списывать фактическое потребление и не полагаться только на оценку до выполнения.
Система должна быть устойчива к noisy neighbor: приоритеты, очереди, backpressure и fair scheduling помогают сохранить SLA.
Для надежности полезны idempotency keys, circuit breakers, fallback-модели и observability по tenant'ам, планам и метрикам нагрузки.

Спроектируйте multi-tenant LLM-сервис с rate limit и квотами по подписке.