Как LLM API должны ограничивать запросы, токены и параллельную обработку?
Автоматический перевод
Эта статья была автоматически переведена с оригинальной английской версии.
LLM API нужны отдельные лимиты на число запросов, объём токенов и параллельную обработку. Одного ограничения запросов в минуту недостаточно для защиты сервиса, если длина промптов и генерируемых ответов меняется. Добавьте ограничения на вход и выход каждого запроса, затем проверьте лимиты приёма запросов относительно целевой латентности.
Почему числа запросов недостаточно
Промпт из 10 токенов и промпт из 100,000 токенов различаются по длине входа в 10,000 раз. Их полная стоимость также зависит от длины ответа, модели и кэширования. Лимит, который учитывает их одинаково, может допустить больше работы, чем сервис способен обработать.
Используйте несколько ограничений вместе:
| Лимит | Что он ограничивает |
|---|---|
| Запросы в минуту | Число вызовов, включая множество небольших запросов |
| Входные и выходные токены | Переменный объём обработки и расходы |
| Параллельные запросы | Активную работу, которая занимает ресурсы декодирования и KV-память |
| Токены на запрос | Отдельные промпты или ответы, превышающие проверенные границы |
Применяйте лимиты арендаторов перед общим лимитом сервиса, чтобы один арендатор не мог занять всю доступную мощность.
Как работает резервирование токенов
Один из вариантов политики приложения — при приёме запроса резервировать оценочное число входных токенов плюс максимально допустимый объём выхода. Запрос с 2,000 входных токенов и ограничением выхода в 1,000 резервирует 3,000 токенов. Если он генерирует 200 выходных токенов, фактический расход составляет 2,200; приложение возвращает 800.
Рассматривайте этот пример отдельно от учёта у провайдера. OpenAI описывает собственные оценки квот на запросы и токены. Anthropic описывает отдельные лимиты на входные и выходные токены. Локальное резервирование не позволяет предсказать, какую квоту провайдера расходует запрос. Уточняйте расход прерванных запросов, когда появятся данные об использовании, и ограничивайте резервы, для которых такой пересчёт невозможен.
Что проверять под нагрузкой
Сочетайте короткие и длинные промпты, короткие и длинные ответы и одновременную работу арендаторов. Записывайте время в очереди, отклонённые запросы, TTFT, TPOT и использование KV cache. Ограничивайте время ожидания в очереди; иначе отклоняйте запрос с понятными правилами повторной попытки. Бюджет токенов в минуту всё ещё может допустить резкий рост нагрузки, который превысит объём памяти для параллельных запросов.
Более общий подход описан в разделе об ограничении частоты запросов в руководстве по LLM-инжинирингу.