В этом материале
Отмена генерации в Triton должна подтверждаться поддерживаемым протокольным действием и прекращением обработки, а не только закрытием клиентского окна.
Отмена генерации в Triton должна подтверждаться поддерживаемым протокольным действием и прекращением обработки, а не только закрытием клиентского окна. Disconnect, deadline и явный cancel не следует считать одинаковыми событиями. Для выбранного gRPC клиента проверьте доступные методы и поведение backend. Это конкретный контракт Triton, а не универсальная схема отмены любого HTTP inference сервиса или гарантия мгновенного прерывания уже запущенного GPU kernel.
Где обнаруживается отмена
Руководство Triton cancellation описывает проверки в core и ответственность backend после передачи запроса на исполнение. Отмена имеет несколько возможных точек наблюдения, поэтому инициирование не означает, что все ресурсы освободились в ту же наносекунду. Сохраните protocol, client version, backend и request identity. Если модель выполняется через Python backend, его обработчик должен учитывать соответствующие API: сам факт использования Triton не доказывает, что произвольный пользовательский код корректно прекращает работу при сигнале отмены.
Используйте конкретный client API
Документация клиентов показывает cancel для результата async_infer и stop_stream(cancel_requests=True) для streaming gRPC. Проверяйте, отменяется ли один запрос или все in-flight обращения данного потока. Это важное различие для multiplexed клиента. Не подставляйте такое поведение в обычное закрытие соединения без проверки. Также не путайте application request ID с объектом вызова библиотеки: способ адресации операции зависит от выбранного API, и ошибочное сопоставление может отменить другую работу либо не затронуть нужный запрос.
Пример контролируемого теста
Отправьте тестовый запрос с достаточно длинным допустимым выводом и инициируйте cancel после подтвержденного начала обработки. Рядом выполните второй независимый запрос, который должен продолжиться, если отмена адресована только первому. Это сценарий приемки без обещания конкретного времени освобождения. Сохраните момент действия клиента, ответ CANCELLED там, где он предусмотрен, серверные события и прекращение дальнейших фрагментов. Для stream-wide cancel явно ожидайте влияние на весь соответствующий набор, не объявляя такое поведение случайной потерей соседнего запроса.
Проверьте освобождение работы
Отсутствие новых client chunks недостаточно: клиент мог просто перестать читать. Сопоставьте наблюдения backend и последующее обслуживание очереди. Если отмененный запрос продолжает выполняться, исследуйте поддержку early termination и участок, где сигнал перестал учитываться. Не выводите результат только из общего падения GPU utilization: на устройстве могут работать другие запросы. Отдельно проверяйте queued и уже executing случаи, поскольку core и backend проходят разные ветви и один удачный сценарий не покрывает оба состояния.
Зафиксируйте гарантию по версии
Протокол приемки должен указывать выбранный client method, область отмены, backend, допустимые задержки наблюдения и способ измерения освобождения. Укажите непокрытые состояния, не обещая мгновенной preemption произвольной GPU операции. Повторите тест после обновления клиента или модели backend. При повторной отправке используйте явную политику приложения: canceled request не должен незаметно запускаться снова автоматическим retry transport. Полезный итог объясняет различие между прекращением доставки ответа и прекращением самой вычислительной работы. Такая проверка помогает избежать накопления ненужных запросов, сохраняя корректную обработку соседних потоков и не расширяя специфические возможности Triton gRPC до обещаний для любого endpoint, библиотеки или разорванного сетевого соединения.
Связанные материалы
Скорость потока и задержка: как выбрать рабочий режим GPU; vLLM OpenAI-совместимый API: как проверить потоковый ответ.