Пропускная способность (Throughput)

Пропускная способность (throughput) измеряет, сколько работы AI-система может обработать за единицу времени — обычно выражается в токенах в секунду (для скорости генерации одного запроса) или запросах в секунду/минуту (сколько одновременных пользователей может обслужить данная часть инфраструктуры). Пропускная способность и задержка связаны, но различны, и эта разница имеет практическое значение: задержка — это то, насколько быстро завершается один запрос, тогда как пропускная способность — это то, какой суммарный объём система способна выдерживать, и оптимизация одного иногда происходит за счёт другого. GPU, обслуживающий инференс LLM, часто может обрабатывать несколько запросов одновременно, "группируя" их в батчи (прогоняя промпты нескольких пользователей через модель за один прямой проход), что значительно увеличивает общую пропускную способность, но может слегка увеличить задержку, ощущаемую отдельным запросом, поскольку ему, возможно, придётся немного подождать, пока батч заполнится. Это важно для разработчиков SaaS, масштабирующих AI-функцию от прототипа (обработка горстки тестовых запросов) до продакшна (обработка тысяч одновременных пользователей): функция, которая нормально работает с 10 тестовыми пользователями, может упереться в потолок пропускной способности при масштабе — либо ваша собственная инфраструктура самостоятельного хостинга исчерпывает мощность GPU для достаточно быстрой обработки запросов, либо вы упираетесь в лимиты скорости на стороне провайдера (провайдеры API обычно устанавливают лимиты как запросов в минуту, так и токенов в минуту на аккаунт/тариф), которые ограничивают ваше приложение под нагрузкой. Конкретный пример: SaaS-компания запускает функцию суммаризации email на базе AI и изначально вызывает API топовой модели напрямую на каждый пользовательский запрос; при 50 одновременных пользователях это работает нормально, но при 5000 одновременных пользователях во время всплеска трафика при запуске продукта они начинают упираться в лимит токенов в минуту у провайдера API, из-за чего запросы встают в очередь или проваливаются. Решение включает несколько архитектурных изменений, ориентированных на пропускную способность: запрос более высокого тарифного уровня лимита скорости у провайдера, реализация очереди запросов с плавным обратным давлением (backpressure) (чтобы UI показывал "обрабатывается", а не ошибку), группировка запросов в батчи там, где это возможно, и, возможно, направление высокообъёмных/низкосложных запросов на меньший, более быстрый, более высокопроизводительный уровень модели, оставляя топовую модель для случаев, которые в ней действительно нуждаются. Понимание ожидаемых требований к пропускной способности — а не только задержки на запрос — необходимо перед выбором уровня модели, лимитов скорости провайдера и архитектуры самостоятельного хостинга против API. Планирование пропускной способности должно также учитывать, что разные типы задач имеют очень разные профили токенов и, следовательно, очень разную стоимость пропускной способности при одном и том же объёме запросов: простая задача классификации да/нет генерирует горстку выходных токенов на запрос, тогда как функция генерации развёрнутого отчёта может генерировать тысячи — то есть "запросов в секунду" само по себе является неполной метрикой ёмкости, и командам, определяющим размер инфраструктуры или ведущим переговоры о лимитах скорости с провайдером, следует моделировать ожидаемое количество токенов в минуту на основе реалистичных распределений длины вывода для их конкретного набора функций, а не только по сырому числу запросов.