В этом материале
Проверяйте доставку событий на одном и том же synthetic stream. Настройка buffering относится к конкретному слою и не гарантирует отсутствие задержек всей цепочки.
Модель может генерировать постепенно, а клиент получать ответ большими порциями. Это не доказывает, что inference-движок игнорирует streaming. Между источником и читателем находятся буферы, транспортные слои и клиентская обработка. Для локализации нужно сравнить один и тот же controlled stream напрямую и через reverse proxy, сохранив моменты отправки и получения. По одному визуальному наблюдению в интерфейсе причину установить нельзя.
Начните с известного источника
Используйте небольшой fake upstream, который отправляет несколько SSE-событий с заранее заданными паузами. Содержимое и время событий известны, поэтому результат не зависит от очереди модели, GPU и случайного числа выходных токенов. Общую длительность и объём теста ограничьте заранее.
Стандарт SSE определяет framing событий, но не обещает конкретную частоту доставки каждого сетевого пакета. Тест должен измерять появление полных событий у клиента, а не требовать совпадения размеров read с размерами отправленных строк. Иначе нормальное транспортное объединение будет ошибочно считаться нарушением протокола.
Сохраните прямую контрольную трассу
Подключитесь к upstream в разрешённом тестовом контуре без исследуемого прокси. Запишите время отправки каждого события источником и время получения полного события клиентом. Сохраните client version и способ чтения. Буферизация самой библиотеки способна исказить сравнение ещё до появления NGINX в пути.
Если уже на прямом маршруте все данные появляются в конце, сначала исследуйте reader и источник. Добавление настроек прокси в этой ситуации может случайно изменить результат, но не даст объяснения исходной проблемы. Контрольная трасса нужна как основание, а не как формальность.
Проверьте реальные настройки NGINX
Документация proxy-модуля описывает proxy_buffering и влияние X-Accel-Buffering при соответствующей обработке заголовка. По умолчанию и в конкретном location возможны разные условия из-за наследования и дополнительных директив. Сохраните эффективную конфигурацию тестируемого маршрута без секретных сведений.
Не копируйте универсальный набор «выключить всё» до измерения. Изменяйте один существенный фактор и повторяйте ту же трассу. Если отправитель задаёт заголовок, проверьте, учитывает ли его прокси; наличие строки в ответе приложения ещё не доказывает действие настройки на промежуточном слое.
Сравните форму задержек
MDN о Streams API объясняет чтение chunks разного размера. Поэтому таблица должна содержать время готового события, его порядковый номер и общий путь запроса. Несколько событий в одном read сами по себе допустимы; подозрение возникает из повторяемой дополнительной задержки относительно контрольного маршрута.
Сравните интервалы между событиями и время первого полезного content. Не складывайте служебный comment с токенами ответа. Отдельно отметьте холодное соединение, потому что время установления транспорта не является тем же самым эффектом, что накопление уже отправленных событий.
Ограничьте вывод исследованным путём
Если изменение buffering устранило задержку на этом location, это объясняет конкретную конфигурацию, а не все будущие маршруты. Другой балансировщик, compression или клиентский reader может снова изменить доставку. Сохраняйте fixture рядом с настройками для повторной проверки после обновления.
Связанные темы — HTTP proxy Runpod и проверка streaming vLLM. Полученный артефакт связывает симптомы с transport path и не устанавливает универсальную скорость генерации или требования внешнего маршрутизатора.