# Reasoning parser в vLLM: как проверить границы рассуждения и ответа

Reasoning parser в vLLM разбирает сгенерированный текст на рассуждение и итоговый ответ.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/vllm-reasoning-parser-boundaries/
Language: ru

Reasoning parser в vLLM разбирает сгенерированный текст на рассуждение и итоговый ответ. Он не включает thinking режим модели автоматически. Для приемки нужно проверить границы этих частей на обычных и потоковых ответах, а также значения параметров, управляющих reasoning. Иначе клиент может принять служебный текст за ответ или потерять начало полезного содержимого при смене шаблона либо parser.

## Разделите генерацию и извлечение

Модель формирует последовательность токенов, а parser интерпретирует ее структуру. [Документация vLLM](https://docs.vllm.ai/en/stable/features/reasoning_outputs/) подчеркивает различие reasoning parsing и управления thinking. Поэтому отсутствие поля reasoning не всегда означает отсутствие внутренних рассуждений или неисправность GPU. Сначала проверьте, какой формат ожидает выбранный parser и что действительно выводит модель. Ручная вставка маркера в текст не заменяет совместимость архитектуры, chat template и настроек генерации, особенно для моделей с особым началом ответа.

## Зафиксируйте контракт клиента

Определите, какие поля клиент читает и что показывает пользователю. Укажите допустимость пустого reasoning, отсутствие явного стартового маркера и разделение потоковых событий. Выбор `reasoning-parser` описан в [справочнике serve](https://docs.vllm.ai/en/stable/cli/serve/). Сохраните имя parser и версию движка рядом с моделью. Если применяется plugin, его исходный код и revision тоже входят в контракт: публичное название API модели не описывает изменения такого компонента и не позволяет восстановить прежнее поведение самостоятельно.

## Пример проверки границы

Подготовьте короткий вопрос с ожидаемым итоговым ответом и сохраните сырой вывод, разобранный объект и собранный streaming результат. Это диагностическая тройка, а не доказательство правильности рассуждения. Проверьте, не исчезают ли первые символы content после закрывающего маркера и не попадает ли маркер в отображаемый текст. Затем повторите с ответом, где reasoning отсутствует или имеет минимальную длину. Ошибка только во второй ветви часто указывает на неверное предположение об обязательном префиксе.

## Проверьте effort отдельно

Значение `reasoning_effort` должно иметь понятное отображение на возможности конкретной модели. Не предполагайте, что любое принятое строковое значение изменило вычисление. Сверяйте поддерживаемые значения и настройки шаблона по документации выбранного parser. Сравните запрос без effort и с явно разрешенным значением, оставив остальные настройки неизменными. Если нужен бюджет thinking tokens, проверяйте его отдельным сценарием завершения, чтобы ограничение вывода не воспринималось как ошибка извлечения полей или случайно обрезанный streaming ответ.

## Сохраните тестовые артефакты

Включите fixtures с полным ответом, отсутствующим reasoning, streaming границей и продолжением диалога. Запишите ожидаемые поля, допустимые пустые значения и условия завершения. Не оценивайте приемку по содержательности скрытого текста: задача здесь состоит в корректной структуре API. После смены модели повторите проверку даже при сохранении parser name, поскольку контрольные токены и шаблоны могут различаться. Итог должен позволять найти слой сбоя: модель не вывела ожидаемую структуру, parser неверно разделил ее или клиент неправильно собрал события. Такая локализация экономит повторные генерации и не требует выдуманных выводов о качестве рассуждения по одному ответу.

## Связанные материалы

[vLLM OpenAI-совместимый API: как проверить потоковый ответ](/ru/journal/vllm-openai-streaming-test/); [Qwen3-8B: память, thinking-режим и первый локальный тест](/ru/journal/qwen3-8b-vram-requirements/).