Rate limiting
и управление квотами

Проблема: провайдер считает твои запросы

Любой LLM-провайдер ставит лимиты на то, как быстро ты можешь к нему обращаться, — чтобы защитить свою инфраструктуру и справедливо поделить мощности между клиентами. Превысил — получаешь 429 Too Many Requests. У LLM лимиты обычно двумерные:

• RPM (requests per minute) — сколько запросов в минуту.
• TPM (tokens per minute) — сколько токенов в минуту (вход + выход). Часто именно TPM упирается первым, ведь один запрос агента может весить десятки тысяч токенов.
• Иногда — лимиты на параллельные запросы, дневные квоты, бюджет.

Специфика агентов делает лимиты особенно болезненными: агент на один запрос пользователя делает много вызовов LLM (reasoning-цикл, вызовы инструментов, суммаризация). Десять параллельных пользователей → десятки одновременных вызовов → мгновенно упёрлись в TPM. И тут — ключевая ошибка новичка:

Клиентский rate limiter

Идея: поставить ограничитель на своей стороне, который пропускает запросы к провайдеру не быстрее заданного темпа (чуть ниже лимита провайдера). Тогда 429 просто не возникает — запросы ждут своей очереди у тебя, а не отскакивают от провайдера.

Классический алгоритм — token bucket («корзина токенов»). Интуиция простая:

Корзина пополняется токенами с постоянной скоростью R (это твой целевой темп). Каждый запрос «забирает» токен: есть токен — проходит сразу; нет — ждёт, пока корзина пополнится. Ёмкость корзины задаёт допустимый всплеск (burst) — можно накопить и пропустить пачку разом. Средний темп при этом никогда не превышает R.

import time, threading

class TokenBucket:
    def __init__(self, rate: float, capacity: float):
        self.rate = rate            # токенов/сек (чуть НИЖЕ лимита провайдера!)
        self.capacity = capacity    # burst
        self.tokens = capacity
        self.updated = time.monotonic()
        self.lock = threading.Lock()

    def acquire(self, need: float = 1.0):
        while True:
            with self.lock:
                now = time.monotonic()
                self.tokens = min(self.capacity,
                                  self.tokens + (now - self.updated) * self.rate)
                self.updated = now
                if self.tokens >= need:
                    self.tokens -= need
                    return          # пропускаем запрос
                wait = (need - self.tokens) / self.rate
            time.sleep(wait)        # ждём, а НЕ бьёмся в 429

# для LLM держим ДВА лимитера: по запросам (RPM) и по токенам (TPM)
rpm = TokenBucket(rate=50/60, capacity=50)          # ~50 запросов/мин
tpm = TokenBucket(rate=100_000/60, capacity=100_000)  # ~100k токенов/мин

def call_llm(prompt: str):
    rpm.acquire(1)
    tpm.acquire(estimate_tokens(prompt))   # оцениваем токены ЗАРАНЕЕ
    return provider.generate(prompt)

Очереди и приоритеты

Раз запросы при нехватке токенов ждут, значит образуется очередь. И тут появляется вопрос: в каком порядке её обслуживать? По умолчанию FIFO (первым пришёл — первым ушёл), но у продукта часто есть приоритеты:

• Интерактивный vs фоновый. Запрос живого пользователя (ждёт ответа на экране) важнее фоновой batch-задачи (может подождать). Приоритетная очередь пропускает интерактивные вперёд.
• Платные vs бесплатные. Premium-пользователям — выше приоритет/своя квота.
• Дедлайны. Запросы с истекающим таймаутом (следующий урок) — вперёд, иначе они всё равно протухнут.

Управление квотами между пользователями

Твой общий лимит от провайдера — один, а пользователей — много. Без распределения возникает проблема «шумного соседа»: один пользователь с тяжёлыми запросами (или циклящийся агент) выжирает весь общий лимит, и все остальные получают отказы из-за него. Нужно справедливое распределение квот.

Типичные ошибки

Шпаргалка

429 = «ТЫ едешь слишком быстро» (не «сервер моргнул»)
  ретраить 429 в лоб = бьёшься в ту же стену, очередь растёт → ПРЕДОТВРАЩАТЬ, не реагировать

ЛИМИТЫ ПРОВАЙДЕРА (двумерные у LLM):
  RPM (запросы/мин) · TPM (токены/мин — часто упирается ПЕРВЫМ) · параллельные · дневные
  агент = МНОГО вызовов на 1 запрос юзера → лимиты болезненны

КЛИЕНТСКИЙ RATE LIMITER (ограничитель на СВОЕЙ стороне):
  token bucket: корзина пополняется R токенов/сек, запрос берёт токен;
    нет токена → ЖДЁТ (а не 429) · ёмкость = burst
  для LLM: ДВЕ корзины — RPM и TPM (оценивай токены ЗАРАНЕЕ)
  ✓ ставь R чуть НИЖЕ лимита провайдера (80–90%: неточность оценки, параллельные инстансы)
  limiter + backoff на 429 (страховка) = рабочая связка

ОЧЕРЕДИ + ПРИОРИТЕТЫ:
  интерактивный > фоновый · платный > free · горящий дедлайн — вперёд
  ⚠️ очередь НЕ бесконечна: лимит длины + времени ожидания → fail fast (backpressure)

КВОТЫ МЕЖДУ ЮЗЕРАМИ (общий лимит один, юзеров много):
  per-user лимит (изоляция от «шумного соседа») · tier'ы (free/pro) ·
  fair queuing · дневные/месячные бюджеты
  🔒 защита юзеров друг от друга + защита ТЕБЯ от абьюза/разорения (cost-контроль)
  растёшь → повышай usage tier у провайдера

ГРАБЛИ: ретрай 429 без лимитера · забыть TPM · безлимитная очередь · один пул без per-user

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

Что дальше

Мы научились не превышать темп. Но даже проходящий запрос может зависнуть: агент в цикле, инструмент не отвечает, генерация тянется минутами. Держать пользователя (и ресурсы) в бесконечном ожидании нельзя. Следующий урок — timeout management: как ставить и каскадировать таймауты для долгих задач, чтобы агент не завис навсегда.