vllm - 💡(How to fix) Fix [Bug]: DeepSeek reasoning parser can emit reasoning_content and content in the same streaming chunk [1 pull requests]

Your current environment

Verified against vLLM upstream/main:
  bf18d7e0b45353cef43f3455e9a8b4262377636e
  [Misc][NUMA] Auto-bind to PCT priority cores on DGX B300 + widen EngineCore across shard NUMA nodes (#43270)

This is a parser-level repro and does not require model weights or a GPU.
The repro was run with PYTHONPATH pointing at an upstream/main worktree.

Relevant collect_env.py summary:
  OS: Ubuntu 22.04.5 LTS (aarch64)
  Python: 3.11.15
  PyTorch: 2.10.0+cpu
  transformers: 5.5.3

🐛 Describe the bug

DeepSeekR1ReasoningParser.extract_reasoning_streaming() can return a single streaming delta with both reasoning and content populated when </think> and the first answer tokens are produced in the same decode delta.

That becomes a Chat Completions streaming chunk where the same choices[0].delta may contain both reasoning_content and content. This can break DeepSeek-compatible clients that follow DeepSeek's official thinking-mode streaming example, because the example treats reasoning_content and content as mutually exclusive per chunk:

DeepSeek official docs: https://api-docs.deepseek.com/guides/thinking_mode

if chunk.choices[0].delta.reasoning_content:
    reasoning_content += chunk.choices[0].delta.reasoning_content
else:
    content += chunk.choices[0].delta.content

With a mixed chunk, that client takes the reasoning_content branch and drops delta.content.

For comparison, Z.ai's official GLM streaming tool-call docs use independent checks for reasoning, content, and tool calls, so a GLM client following that example can tolerate a mixed chunk:

Z.ai official docs: https://docs.z.ai/guides/tools/stream-tool

if hasattr(delta, 'reasoning_content') and delta.reasoning_content:
    ...
if hasattr(delta, 'content') and delta.content:
    ...
if delta.tool_calls:
    ...

This matters in vLLM because glm45 is currently registered to DeepSeekV3ReasoningWithThinkingParser, which delegates to DeepSeekR1ReasoningParser in thinking mode. However, the compatibility issue is not GLM-specific: it is caused by the DeepSeek thinking parser behavior and affects deepseek_r1 directly, deepseek_v3/deepseek_v4 when thinking mode is enabled, and parsers that reuse DeepSeekV3ReasoningWithThinkingParser.

Relevant code on upstream/main:

# vllm/reasoning/deepseek_r1_reasoning_parser.py
if self.end_token_id in delta_token_ids:
    end_index = delta_text.find(self.end_token)
    reasoning = delta_text[:end_index]
    content = delta_text[end_index + len(self.end_token) :]
    return DeltaMessage(
        reasoning=reasoning,
        content=content if content else None,
    )

Minimal repro:

from vllm.reasoning.deepseek_r1_reasoning_parser import DeepSeekR1ReasoningParser
from vllm.reasoning.deepseek_v3_reasoning_parser import (
    DeepSeekV3ReasoningWithThinkingParser,
)


class FakeTokenizer:
    def get_vocab(self):
        return {"<think>": 1, "</think>": 2}


for cls in (DeepSeekR1ReasoningParser, DeepSeekV3ReasoningWithThinkingParser):
    parser = cls(FakeTokenizer())
    delta = parser.extract_reasoning_streaming(
        previous_text="服务的",
        current_text="服务的诚意。</think>我是",
        delta_text="诚意。</think>我是",
        previous_token_ids=[101],
        current_token_ids=[101, 102, 2, 103],
        delta_token_ids=[102, 2, 103],
    )
    print(cls.__name__, delta.model_dump(exclude_none=True))

Actual output:

DeepSeekR1ReasoningParser {'content': '我是', 'reasoning': '诚意。', 'tool_calls': []}
DeepSeekV3ReasoningWithThinkingParser {'content': '我是', 'reasoning': '诚意。', 'tool_calls': []}

Expected behavior for DeepSeek-compatible Chat Completions streaming:

A streaming choices[0].delta should not have both reasoning_content and content populated at the same time. When the raw decode delta crosses the </think> boundary, vLLM should either split the boundary into two streamed chunks, for example:

chunk 1: delta.reasoning_content = "诚意。"
chunk 2: delta.content = "我是"

or otherwise preserve compatibility with clients following DeepSeek's documented if reasoning_content ... else content streaming pattern.

Closest related issues I found were #12683 and #43221, but they cover different/closed problems: field omission vs content: null, and reasoning truncation when </think> and a tool-call token share a delta.

Before submitting a new issue...

• Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.