Лимиты LLM API по пользователям в SaaS-приложении

Короткий ответ: лимит принадлежит вашему продукту

У одного поставщика может быть общий технический лимит, а у SaaS — совершенно другая логика: бесплатному пользователю разрешено несколько коротких операций, рабочему пространству — общий бюджет, а административной роли — повышенный, но наблюдаемый порог. Не называйте внутренний порог «лимитом модели» и не обещайте, что он совпадает с ограничением RussiaAPI. Храните правило рядом с планом продукта: период, единицу учёта, допустимые операции, максимальную параллельность и действие при превышении. Тогда изменение тарифа или model ID не потребует переписывать пользовательский контракт вслепую.

Практичный ключ учёта состоит из tenant_id, user_id, класса операции и окна времени. Класс важен: генерация короткого текста, длинный анализ и асинхронная медиа-задача не должны конкурировать в одной безымянной корзине. До отправки в gateway backend проверяет аутентификацию, получает актуальное правило, резервирует небольшую единицу работы и только затем формирует запрос. Если правило не найдено или состояние счётчика нельзя надёжно определить, безопаснее вернуть временную понятную ошибку, чем пропустить неограниченный трафик.

Выберите измерение и не выдавайте оценку за счёт

Начните с измерения, которое можно объяснить пользователю и проверить в журнале: число завершённых запросов, зарезервированные единицы операции или внутренний денежный budget. Токены и стоимость полезны для аналитики, но их нельзя заранее представить как точный счёт без актуального тарифа, фактического ответа и правил округления. Для длинной операции сначала ставят консервативный резерв, а после завершения записывают безопасный агрегат. Не сохраняйте полный prompt, Authorization или чужой ключ ради биллинга: для разбора лимита достаточно идентификаторов, времени, типа операции и итогового состояния.

Разделите «отклонено до запуска», «зарезервировано», «завершено» и «компенсировано после технической ошибки». Без этих состояний повтор кнопки или timeout легко съедает лимит дважды. Каждой пользовательской попытке присваивайте request_id приложения и используйте его как идемпотентный ключ в собственной базе. Повтор того же действия должен вернуть ранее известный результат либо состояние обработки, а не создать новую бронь. Условия конкретного endpoint и поддержка идемпотентности проверяются по текущей документации; пример описывает защиту на стороне SaaS, а не скрытую возможность gateway.

Добавьте очередь и честный отказ вместо бесконечного ожидания

Лимит запросов не равен лимиту одновременности. Даже tenant с доступным budget способен занять все worker-потоки несколькими тяжёлыми задачами. Поэтому перед вызовом нужна отдельная очередь с максимумом активных операций на tenant и глобальным предохранителем для сервиса. Очередь хранит минимальные данные: идентификатор операции, класс, дедлайн и статус. Когда deadline истекает, операция не должна оставаться «работающей» навсегда; пользователь получает нейтральный статус и возможность проверить результат позже, если такой сценарий предусмотрен продуктом.

При превышении лимита отвечайте ясным кодом приложения, например quota_exceeded или queue_full, и указывайте безопасное время повторной проверки без раскрытия внутренних маршрутов. Не советуйте обходить правило созданием новых учётных записей и не скрывайте отказ за бесконечным spinner. Администратору tenant можно показать агрегаты: расход по классу операций, число отклонений и ближайшее окно пересмотра. Это помогает настроить продуктовую политику, не превращая интерфейс в обещание фиксированной пропускной способности внешнего провайдера.

Проверяйте изоляцию tenant и границы доступа

Все операции с лимитом выполняются после серверной аутентификации. Значение tenant_id нельзя принимать как доверенное поле из браузера: оно выводится из сессии или подписанного контекста и дополнительно проверяется в хранилище. Точно так же пользователь не должен выбирать base URL, provider или ключ. Backend использует только свой RUSSIAAPI_API_KEY из окружения, ограничивает поддерживаемые model ID allowlist-ом и передаёт gateway лишь данные, нужные для согласованной операции. Это снижает риск того, что один tenant расходует ресурс другого или извлекает служебную информацию из ошибок.

Тестовый набор должен содержать негативные случаи: чужой tenant, устаревшая сессия, повтор request_id, параллельные запросы на границе лимита, неизвестный model ID и недоступное хранилище счётчиков. Проверяйте, что ни один случай не выдаёт секрет, полный body или детали внутренней политики. Для спорных расходов предусмотрите журнал решений с версией правила и агрегированными единицами. Такой журнал полезнее необработанного текста запросов: он позволяет объяснить, почему операция не была запущена, и воспроизвести ошибку безопасно.

Запускайте политику постепенно и наблюдайте её эффект

Сначала включите правила для тестового tenant или небольшой доли пользователей. Смотрите на долю ранних отказов, глубину очереди, технические ошибки и жалобы на ложные блокировки, разделяя их по классу операции. Если новый порог ломает важный сценарий, откатите версию политики, а не меняйте счётчик вручную без следа. Отдельно сверяйте каталог и фактический тестовый вызов перед тем, как добавить новую модель: наличие названия в интерфейсе не доказывает права tenant, параметры или постоянную доступность.

RussiaAPI можно использовать как независимый gateway только в допустимых и документированных сценариях. Создайте собственный тестовый ключ в консоли, выполните обезличенный server-side smoke test и затем подключайте его к очереди. Не передавайте в сервис ключи upstream-поставщиков и не обещайте пользователю, что лимит обеспечивает юридическое, финансовое или техническое свойство внешней платформы. Хорошая политика честно показывает границы продукта: что сейчас разрешено, что отложено и какие данные нужны для следующей проверки.

Server-side пример

Пример показывает локальный контроллер на сервере. Ключи берутся только из окружения; до запуска подтвердите маршрут, model ID и параметры в текущем каталоге RussiaAPI.

const limits = new Map();

export function reserveOperation({ tenantId, userId, kind, requestId }) {
  const key = [tenantId, userId, kind].join(':');
  const current = limits.get(key) ?? { used: 0, requests: new Set() };
  if (current.requests.has(requestId)) return { state: 'duplicate' };
  if (current.used >= 20) return { state: 'quota_exceeded' }; // Application policy, not a provider quota.
  current.used += 1;
  current.requests.add(requestId);
  limits.set(key, current);
  return { state: 'reserved' };
}
// Call a documented RussiaAPI route only from your server with process.env.RUSSIAAPI_API_KEY.

Проверьте синтаксис через node --check, добавьте аутентификацию своего маршрута и негативные тесты. Не логируйте тело запроса или заголовки только ради отладки.