В этом материале
Замедление чтения должно иметь ограниченный ресурсный эффект. Transport flow control не доказывает, что очередь приложения или вычисление тоже ограничены.
Быстрый потребитель скрывает проблемы потокового сервера: данные сразу уходят из очереди, и память кажется стабильной. Медленный клиент создаёт другой режим. Генерация может продолжаться, пока приложение накапливает непрочитанные фрагменты. Поэтому провайдеру нужен ограниченный тест чтения с задержками, который наблюдает очередь, память и завершение операции. Он проверяет transport path, а не производительность модели на максимальной нагрузке.
Найдите места накопления
MDN описывает backpressure как часть организации потоков и очередей. В цепочке inference существуют несколько буферов: движок, API-процесс, прокси и клиентский reader. Ограничение одного из них не устанавливает ограничение остальных. Составьте схему, где данные создаются, где ожидают отправки и кто может остановить источник.
Не называйте сетевое давление автоматической отменой генерации. Если API читает upstream максимально быстро и складывает всё в собственную очередь, транспортный механизм может не достигнуть движка. Такая архитектура требует отдельного ограничения памяти и политики завершения медленных соединений.
Разделите транспорт и приложение
RFC 9113 определяет flow control HTTP/2. Этот механизм управляет передачей данных в своих пределах, но не описывает число ожидающих задач модели и не задаёт политику приложения при заполненном буфере. Нельзя выводить безопасную ёмкость inference-сервиса только из наличия HTTP/2.
Определите наблюдаемые показатели каждого слоя. Для приложения полезны in-flight requests, объём очереди и длительность ожидания отправки. На клиенте сохраняют интервалы чтения и общий объём. Все значения относятся к выбранному тесту; они не превращаются в универсальные пределы для других моделей.
Постройте ограниченный медленный reader
Сначала выполните короткую контрольную трассу без задержек. Затем тот же synthetic stream читайте с заранее заданными паузами. Ограничьте число событий, общий размер и максимальный срок. Если тестовый upstream может работать без GPU, используйте его для первого разбора transport behavior.
Сохраняйте временной ряд памяти и очереди, а не только начальное и конечное значения. Короткий пик и непрерывный рост требуют разных действий. При достижении предела тест останавливается и помечается ограничением, а не продолжается ради поиска момента аварии машины.
Проверьте роль прокси
NGINX описывает buffering и условия передачи ответа клиенту. Включённая буферизация способна изменить место накопления данных; выключенная не отменяет все другие очереди. Запишите фактические настройки и отдельно сравните прямое соединение с маршрутом через прокси.
Если задержка клиента вызывает рост только на одном пути, локализуйте этот участок. Не отключайте защитные пределы, чтобы тест «прошёл». Цель — объяснимое ограниченное поведение, а не бесконечная поддержка потребителя, который перестал читать поток и не освобождает ресурсы.
Подтвердите освобождение после остановки
После закрытия клиента проверьте завершение соответствующей операции на доступных границах. Падение числа соединений ещё не доказывает остановку upstream-работы. Очереди и in-flight показатели должны вернуться к ожидаемому состоянию, либо отчёт фиксирует, где подтверждение отсутствует.
Связанные темы — continuous batching и планирование ёмкости. Они относятся к нагрузке модели; медленный reader проверяет другую зависимость и помогает не спутать свободную вычислительную мощность с безопасностью транспортного обслуживания.