В этом материале
GOAWAY относится к соединению и границам обработки streams. Он не гарантирует прозрачного повторения или продолжения любой LLM-генерации.
Одно HTTP/2-соединение может обслуживать несколько потоков. Поэтому его закрытие при rollout нельзя анализировать как завершение ровно одного inference-запроса. GOAWAY сообщает о прекращении использования соединения в определённых границах, но прикладной результат каждой генерации требует собственного учёта. Для провайдера полезен небольшой тест draining, который связывает транспортный сигнал, допуск новых запросов и судьбу уже открытых ответов.
Разделите соединение и stream
RFC 9113 описывает HTTP/2 streams и GOAWAY, включая last-stream-ID. Этот идентификатор помогает определить границу обработки на конкретном соединении. Он не является model request ID и не должен подменять прикладной идентификатор генерации в журнале сервиса.
Сохраните карту соответствий между клиентской операцией и транспортным stream, если тестовая инфраструктура позволяет её наблюдать. Не делайте вывод о судьбе всех запросов по одному закрывшемуся socket. Некоторые операции могли уже завершиться, другие продолжать обработку, а новые больше не должны приниматься через уходящий путь.
Опишите поведение при rollout
Kubernetes документирует termination flow, в котором readiness и состояние endpoints участвуют в выводе экземпляра из обслуживания. Это отдельный механизм от HTTP/2 GOAWAY. Наличие одного не доказывает, что другой настроен или вообще используется на рассматриваемом участке.
До теста нарисуйте цепочку: клиент, балансировщик, API-процесс, движок. Укажите, кто завершает HTTP/2 и где происходит graceful shutdown. Если прокси преобразует протокол, downstream-сигнал может не описывать внутреннее соединение с движком. Именно эту границу следует сохранить в выводе.
Создайте ограниченный эксперимент
Откройте небольшое число synthetic streams с известным сроком и размером. Во время их работы инициируйте согласованное завершение тестового экземпляра. Отдельно отправьте новый короткий запрос после начала draining. Наблюдайте, какие операции приняты, завершены, отклонены либо остались с неоднозначным исходом.
Тест не требует реальной клиентской нагрузки. Установите верхний срок ожидания и условия остановки, чтобы не создавать бесконечные соединения. Сохраните timeline событий для каждого запроса, а не только общее число успехов после завершения. Иначе редкий обрыв будет трудно связать с конкретной фазой обновления.
Не обещайте безопасный replay POST
RFC 9110 различает идемпотентные методы и осторожность при повторении неидемпотентных запросов. Генерация через POST не становится автоматически безопасной для повтора от появления GOAWAY. Нужны сведения о принятии операции либо отдельно определённая прикладная политика.
Проверьте поведение используемой библиотеки: открывает ли она новое соединение, повторяет ли запрос и что сообщает вызывающему коду. Нельзя считать отсутствие видимой ошибки доказательством единственного выполнения. Для диагностической записи важны число попыток и связь с одной логической операцией.
Сохраните границы результата
Успешный draining-тест подтверждает выбранный путь и версию компонентов. Он не устанавливает отказоустойчивость на любом балансировщике или при аварийном завершении процесса. Особенно отдельно проверяют сценарий, где grace period закончился до завершения длинной генерации.
Связанные темы — резервная маршрутизация и canary обновления. Они помогают описать прикладную стратегию, а GOAWAY-трасса подтверждает конкретные транспортные границы без заявления об универсальной поддержке сторонней платформой.