В этом материале
В decoupled режиме Triton завершение запроса нужно определять по протокольному признаку, а не по последнему непустому фрагменту текста.
В decoupled режиме Triton завершение запроса нужно определять по протокольному признаку, а не по последнему непустому фрагменту текста. Один запрос может порождать несколько ответов или не содержать обычного полезного ответа. При нескольких запросах возможен иной порядок доставки. Клиентский автомат должен учитывать эту семантику, иначе он преждевременно закроет запись, потеряет финальное событие либо будет ждать текст, который по контракту уже не обязан появляться.
Смысл decoupled transaction
Документация Triton описывает модели с независимым числом ответов и отдельным завершением. Это отличается от простого предположения «один request — один response». Backend и frontend должны поддерживать выбранный режим. Не переносите поведение обычного inference endpoint на любой streaming transport без проверки. Сначала определите конкретный протокол, endpoint и версию клиента, а затем связывайте его события с жизненным циклом запроса, не выводя полный контракт только из содержания текстовых chunks.
Отделите содержание от completion
Пустое финальное событие может иметь управляющее значение, хотя ничего не добавляет к отображаемому тексту. Поэтому сохраняйте события до фильтрации пустых chunks. Если клиент сначала удаляет их, а затем ищет признак конца, он рискует потерять необходимое подтверждение. При нескольких in-flight запросах ведите состояние по request identity. Порядок прихода ответов разных запросов не должен определять, к какой истории их добавлять. Эта задача протокольная и не решается изменением tokenizer или sampling параметров модели.
Пример клиентского автомата
Опишите состояния «отправлен», «получает ответы», «получен final» и «завершен с ошибкой». Для каждого сохраните допустимые события и переходы. Проверьте один ответ, несколько ответов, отсутствие полезного текста и перемежение двух запросов. Это синтетический тест транспорта, не результаты конкретной LLM. После final дальнейшая обработка должна соответствовать контракту клиента, а не создавать второй завершенный ответ по следующему служебному событию. Ошибка соединения должна оставаться отличимой от нормального пустого завершения.
Свяжите режим с TensorRT-LLM
В актуальном руководстве LLM deployment streaming связан с decoupled configuration и generate_stream. Не считайте обычный generate автоматически эквивалентным. Сохраните выбранный endpoint и model configuration вместе с тестом. Режим batching и режим доставки ответов — разные свойства: изменение одного не доказывает настройку другого. Если пример из старого deployment использует иной backend путь, сначала установите его границы, прежде чем переносить HTTP или gRPC клиентские предположения в новый LLM API.
Приемка потока
Сохраняйте сырые события, собранный текст, final condition и request identity. Отдельно проверяйте прерванное соединение и timeout: они не являются успешным completion даже при наличии читаемого ответа. Не запускайте повтор запроса автоматически только из-за пустого финального payload, если протокол уже подтвердил завершение. Полезный артефакт позволяет повторить клиентский автомат без модели, проиграв сохраненные синтетические события, а затем подтвердить его на выбранном backend. Он не обещает общую совместимость любого OpenAI streaming клиента с любым Triton endpoint: конкретные схемы и признаки завершения нужно сопоставлять явно. Такая проверка предотвращает потерю ответа на границе между моделью, транспортом и пользовательской сборкой текста, не подменяя протокольную корректность оценкой качества содержания.
Связанные материалы
vLLM OpenAI-совместимый API: как проверить потоковый ответ; Ошибка внутри потока OpenRouter: почему HTTP 200 недостаточно.