Объяснение ограничений скорости API и пропускной способности

Что такое ограничение скорости на самом деле

А предел скорости — это ограничение скорости использования API. Провайдеры навязывают их, чтобы обеспечить справедливость и стабильность обслуживания: без них один-единственный ошибочный цикл или всплеск трафика от одного клиента может привести к голоданию всех остальных, поэтому ограничения защищают пропускную способность, обеспечивают соблюдение уровней плана и сдерживают злоупотребления и атаки типа «отказ в обслуживании». Когда вы пересекаете лимит, API на мгновение перестает обслуживать вас и возвращает сообщение HTTP 429 «Слишком много запросов» ответ вместо того, чтобы делать работу.

Ограничения имеют несколько общих единиц, и вы можете сначала достичь любого из них:

В API LLM чаще всего кусаются два об/мин и ТРМ, и они независимы. Пятьдесят крошечных вызовов классификации могут превысить RPM, едва касаясь TPM; одно обобщение документов объемом 100 000 токенов может обойти TPM за один запрос. Проектируйте с учетом того потолка, которого достигнет ваша рабочая нагрузка в первую очередь.

Превратить ограничение TPM в «сколько пользователей я могу обслуживать?»

Планирование мощностей — это всего лишь арифметика. Начните с жетонов один пользователь потребляет в минуту, затем разделите на это свой лимит.

• Токены за запрос = токены ввода (подсказка + системное сообщение + контекст) плюс выходные токены, которые генерирует модель. Оба учитываются в отношении TPM.
• Запросов на пользователя в минуту = насколько болтлив активный пользователь.
• Токенов на пользователя в минуту = токены на запрос × количество запросов на пользователя в минуту.

Пример: каждый ход чата использует ~1500 входных данных + ~500 выходных данных = 2000 жетонов, а активный пользователь отправляет ~1,5 оборота в минуту → 3000 токенов/пользователь/минута. С 300 000 транзакций в минуту лимит, который вы можете служить примерно 300 000 ÷ 3 000 = 100 одновременно активных пользователей. Сделайте то же самое деление против вашего предела оборотов в минуту и ​​возьмите меньше из двух ответов — это ваш настоящий потолок. Примечание. «активный» означает активную отправку; продукт со 100 одновременно работающими пользователями обычно имеет тысячи зарегистрированных учетных записей.

Уровни: если тратить больше, ваши лимиты повышаются.

Большинство провайдеров работают уровни использования. Новые учетные записи начинаются с низких значений RPM/TPM/RPD; по мере того, как вы тратите больше и ваш аккаунт устаревает, вы автоматически переходите на более высокие уровни с гораздо большими потолками — иногда в 10 или 100 раз превышающими начальные цифры. Если вы достигли лимита, первый вопрос: на каком я уровне нахожусь и имею ли я право на следующий? Соглашения Enterprise и обязательства по расходам могут еще больше снять ограничения или добавить выделенные мощности.

Техники, которые увеличивают вашу эффективную производительность

• Пакетирование — объедините множество элементов в меньшее количество более крупных запросов, чтобы снизить нагрузку на RPM. Выделенные пакетные API поставщиков также работают со скидкой для несрочных работ.
• Потоковое вещание — обратная потоковая передача токенов не увеличивает ваш бюджет токенов, но сокращает воспринимаемую задержку и быстрее освобождает клиентские ресурсы, поэтому перекрывающиеся запросы очищаются быстрее.
• Откат и темп - равномерное распределение вызовов в течение минуты вместо того, чтобы отправлять их все одновременно, удерживает вас под разрывающимся потолком, о котором в противном случае вы бы споткнулись.
• Обрезка жетонов — более короткие запросы, кэширование запросов и жесткие ограничения на выходные данные напрямую увеличивают количество запросов, вписывающихся в фиксированный бюджет TPM.

Обработка ошибок 429: отсрочка, повторные попытки и постановка в очередь

Достижение предела — это нормально. Вопрос в том, корректно ли восстанавливается ваше приложение. Стандартный шаблон экспоненциальная задержка с джиттером: на 429 подождите небольшую задержку, затем повторите попытку; если снова произойдет сбой, каждый раз примерно удваивайте задержку (например, 1 с, 2 с, 4 с, 8 с) и добавьте небольшое случайное смещение, чтобы многие клиенты не повторяли попытку синхронно. Всегда уважайте Повторить попытку после заголовок, если провайдер его отправляет — он точно сообщает вам, как долго ждать.

Жесткий лимит против мягкого/пакетного лимита

А жесткий предел является абсолютным пределом — превысьте его, и каждый запрос будет отклонен до перезагрузки окна. А мягкий или взрывной предел допускает короткие всплески выше вашей постоянной скорости (часто через корзину жетонов, которая пополняется со временем), поэтому короткие всплески проходят, но устойчивая перегрузка все равно ограничивается. Знание того, с чем вы сталкиваетесь, меняет вашу стратегию: увеличение лимитов вознаграждает за сглаживание трафика в окне; жесткие ограничения требуют реального очередь что счетчики отправляют запросы с безопасной скоростью.

• Очередь несрочных работ поэтому он истощается в контролируемом темпе, а не забивает API.
• Распределенная нагрузка равномерно, а не разрываться в начале каждой минуты.
• Ограничить общее количество повторов поэтому обреченный запрос завершается с ошибкой, а не зацикливается навсегда.

С точки зрения затрат: ограничения формируют архитектуру, а не счет.

Ограничения по ставкам не требуют прямых затрат — с вас никогда не взимается плата за 429. Но они сильно влияют на то, как вы строите, и на ваш выбор. делать иметь стоимость. Когда один ключ не может обеспечить необходимую вам пропускную способность, команды обычно обращаются к резервная цепочка (переключение на вторую модель или поставщика при регулировании основного), несколько ключей или поставщиков объединить мощности и пакетный API переместить несрочные задания на более дешевые полосы с более высокими лимитами. Каждый из них добавляет устойчивости и запаса мощности, но также усложняет интеграцию и иногда повышает цену за токен в резервном варианте. Самый здоровый подход — сначала повысить уровень и сократить количество токенов, а затем добавлять избыточность только там, где вас действительно блокирует жесткий лимит.

Часто задаваемые вопросы

В чем разница между RPM и TPM?

RPM (запросов в минуту) ограничивает количество вызовов API, которые вы можете совершать каждую минуту, а TPM (токены в минуту) ограничивает объем текста, который эти вызовы могут переместить. Сначала вы можете достичь любого потолка: многие небольшие вызовы исчерпывают RPM, а несколько вызовов с большим контекстом исчерпывают TPM.

Как превратить ограничение TPM в количество пользователей, которых я могу обслуживать?

Оцените количество токенов, потребляемых одним пользователем в минуту (токены на запрос, умноженные на количество запросов на пользователя в минуту, считая как входные, так и выходные данные), а затем разделите лимит TPM на эту цифру. Если пользователю требуется 3000 токенов в минуту, а ваш лимит составляет 300 000 TPM, вы можете обслуживать около 100 одновременно активных пользователей.

Как мне справиться с ошибкой 429 Too Many Requests?

Повторите попытку с экспоненциальной отсрочкой и джиттером — постепенно увеличивайте время ожидания между попытками и учитывайте любой заголовок Retry-After, возвращаемый поставщиком. Ставьте несрочную работу в очередь, равномерно распределяйте нагрузку, а не разрывайте ее, и ограничивайте общее количество повторов, чтобы запрос в конечном итоге завершался полным сбоем, а не зацикливался навсегда.