В этом материале
Потоковый ответ нужно проверять по последовательным событиям, а не только по появлению текста в конце запроса.
Чтобы проверить потоковый ответ vLLM, отправьте запрос с stream: true к подходящему endpoint и убедитесь, что клиент получает события по мере генерации. Если весь текст появляется сразу в конце, причиной может быть буферизация клиента или прокси. Это ещё не доказывает, что движок игнорирует потоковый режим.
Подготовьте обычный контрольный запрос
Сначала получите имя из /v1/models и проверьте непотоковую генерацию. Используйте короткое сообщение и небольшой предел ответа. Такой контроль отделяет ошибки модели, шаблона и адреса от особенностей чтения событий.
Интерфейсы перечислены в документации online serving. Настройки имени и сервера описаны в справочнике vLLM serve. Совместимость API относится к протоколу; она не превращает выбранный локальный checkpoint в модель другого поставщика.
Используйте клиент без лишней буферизации
Учебный пример для уже работающего локального сервера:
curl -N http://127.0.0.1:8000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{"model":"Qwen/Qwen3-0.6B","messages":[{"role":"user","content":"Назови три цвета."}],"max_tokens":64,"stream":true}'Идентификатор замените фактически объявленным сервером. Ключ -N отключает буферизацию вывода curl. Пример проверяет локальную цепочку, а не измеряет производительность модели: короткий ответ способен завершиться раньше, чем визуально заметны промежуточные события.
Разделите события и отображаемый текст
Поток содержит структурированные сообщения. Не каждое событие обязано приносить видимый фрагмент текста: возможны служебные поля и завершение. Клиент должен корректно обрабатывать последовательность, а не пытаться прочитать весь поток как один обычный JSON-документ.
Отдельно проверьте завершение ответа, ошибку и отмену. Если интерфейс продолжает показывать ожидание после последнего события, проблема может находиться в его обработчике. Если соединение закрыто пользователем, убедитесь, что оставшаяся работа не искажает следующий измерительный прогон и не создаёт скрытую нагрузку.
Найдите слой, задерживающий данные
Повторите один запрос напрямую к серверу и через используемый промежуточный маршрут. Если прямой поток виден постепенно, а через прокси приходит целиком, изучайте настройки буферизации и времени ожидания именно этого слоя. Не меняйте GPU ради проблемы передачи событий.
Для браузерного интерфейса отдельно проверьте разрешённый адрес и сетевой доступ. Соединение из контейнера и соединение из браузера могут использовать разные маршруты. Подробный разбор приведён в статье о localhost. Сохраняйте обезличенные статусы и время получения первых данных.
Для ручного опыта выберите ответ достаточно длинный, чтобы увидеть несколько содержательных событий, но не превращайте проверку протокола в нагрузочный тест. Сохраните время получения фрагментов на стороне клиента. Если оно резко отличается при прямом и промежуточном маршруте, сначала объясните этот сетевой эффект, затем переходите к оценке GPU и очереди.
Измеряйте ожидание пользователя корректно
Время до первого события, до первого содержательного токена и до полного ответа может различаться. У reasoning-модели добавляется собственная структура вывода. Поэтому сравнение двух конфигураций должно использовать одинаковый критерий и формат сообщений, иначе красивое раннее событие будет ошибочно принято за быстрый ответ.
Основной поток нагрузки проверяйте отдельно, как описано в руководстве bench serve. Владельцу оборудования полезно показать исправную передачу событий и измеренную задержку, а финансовому партнёру — понимать, что улучшение интерфейса и увеличение вычислительной мощности решают разные задачи.