В этом материале
Общий deadline и таймаут между чтениями решают разные задачи. Бюджет нужно связывать с одной логической операцией и фактическими этапами.
У inference-запроса может быть несколько таймеров: установление соединения, ожидание upstream, пауза без данных и общий срок операции. Если их назвать одним словом timeout, диагностика станет неточной. Сервер может регулярно посылать служебные bytes и всё же превысить допустимое ожидание ответа. Или короткий idle timeout оборвёт запрос, который ещё укладывается в общий deadline. Проверка должна сначала определить смысл каждого ограничения.
Назовите начало и конец бюджета
RFC 9110 описывает HTTP-семантику, но не задаёт единую прикладную политику deadline для любой LLM-генерации. Собственный сервис должен определить, с какого момента начинается общий срок: принятие запроса, отправка клиентом либо другая документированная граница. Нельзя молча сменить начало отсчёта ради более красивой метрики.
Разделите логическую операцию и отдельную попытку. Если клиент выполняет повтор, суммарное ожидание пользователя может превысить timeout каждой попытки. Передача оставшегося бюджета между слоями — отдельное проектное решение. Не придумывайте универсальный заголовок, который якобы обязаны понимать все upstream-провайдеры.
Разведите idle и total timeout
NGINX описывает таймауты прокси с конкретной областью действия. Например, ограничение между чтениями не равно полному сроку ответа. Сохраните настройки исследуемого location и проверьте, какое событие обновляет соответствующий таймер. Полезный content и служебный heartbeat могут иметь разные роли в прикладной политике.
Если источник продолжает отправлять comments, транспортное ожидание может не закончиться, хотя продуктовый deadline уже исчерпан. Общий ограничитель должен работать независимо от наличия очередного служебного фрагмента. Иначе формально активное соединение способно удерживать ресурс неопределённо долго.
Разложите путь запроса
Для тестовой записи выделите очередь, подготовку входа и генерацию выхода, насколько эти стадии наблюдаются. Не вычисляйте скрытое время движка простым вычитанием несопоставимых часов разных машин. Python time описывает монотонные инструменты измерения длительностей внутри процесса.
Сохраните точки принятия, начала обработки, первого useful event и окончания. Если известна только клиентская трасса, так и укажите. Она полезна для пользовательского времени, но не доказывает точное распределение внутреннего GPU-времени. Подробность отчёта должна соответствовать реальному уровню наблюдения.
Проверьте отдельные задержки
Fake upstream может задержать headers, первое content или следующий event. Для каждого сценария задайте конечный срок и ожидаемую классификацию. AbortSignal.timeout показывает один клиентский механизм отмены, но его active-time семантика не должна без проверки приравниваться к серверному wall-clock deadline.
Используйте маленькие fixtures без реальных пользовательских данных. Остановив ожидание клиента, проверьте отдельно прекращение upstream-работы, если такая граница доступна. Закрывшийся reader не подтверждает автоматическое освобождение всей серверной цепочки и не определяет расчёт потреблённой работы.
Сохраните объяснимый итог
Результат должен называть сработавший бюджет, место наблюдения и судьбу логической операции. Формулировка «timeout на запросе» слишком широка для решения о настройке. Различайте отклонение в очереди, исчерпание общего срока и разрыв между чтениями, чтобы не менять все параметры одновременно.
Смежные темы — prefill и decode и throughput с задержками. Вместе они помогают обсуждать конкретный бюджет ожидания без универсальных порогов, выдуманного SLA или заявлений о готовой интеграции.