The Special Token `<think>` Problem/Bug of Latest DeepSeek LLM

最近，用户在最新版本的 DeepSeek LLM 中观察到一个问题/bug：在测试过程中，发现在用户提示中包含特定的不完整或特殊标记，例如 <think> 或 <think 时，模型可能会产生极不稳定的响应、严重的幻觉、异常的推理输出或意外的行为。

本文旨在记录该问题，演示如何复现该行为，并讨论为更好地理解问题可能原因而进行的验证实验。本文分为三个主要部分：

• 介绍与 <think> 标记问题的复现：对发现的问题进行演练，包括示例提示和观察到的异常模型行为。

• 验证实验设计与结果分析：介绍本地验证实验设置、测试方法、收集的输出以及对验证结果的分析。

• 讨论与一些假设：与分词器行为、提示解析机制以及潜在安全影响相关的讨论和假设。

# Author:      Yuancheng Liu
# Created:     2026/05/18
# Version:     v_0.0.2
# Copyright:   Copyright (c) 2026 LiuYuancheng
# License:     MIT License

1. Bug 介绍与复现

1.1 Bug 介绍

大约三天前（2026年5月16日），多位用户报告在使用 DeepSeek LLM 模型网页聊天时出现异常行为。在测试过程中，用户发现如果提示仅包含特殊标记 <think> 或不完整标记 <think，模型可能会意外地生成不相关的响应、隐藏的推理痕迹，或回答当前用户从未问过的问题。

在一些情况下，生成的内容看起来逻辑结构清晰且上下文连贯。由于其中一些响应看起来像是有效用户查询的片段，因此在线讨论迅速引发了对可能存在的跨会话数据泄露或推理缓存暴露的担忧。

发现时，社区讨论了几个可能的解释：

• GPU 缓存或负载均衡器缓存泄露：一些用户怀疑推理服务器缓存未能在请求之间正确清除，可能导致其他用户的提示或推理痕迹片段出现在不相关的会话中。

• 分词器或提示解析器 bug：其他人认为问题与分词器或内部提示格式化机制有关，其中 <think> 标记可能意外触发隐藏的推理模式行为或特殊的内部指令。

• 特殊标记解析问题：另一种假设是，<think> 可能被视为模型在思维链生成过程中内部使用的保留控制标记，当直接暴露给用户输入时会导致输出不稳定。

1.2 Bug 复现

该 bug 相对容易复现。在本实验中，使用了官方的 DeepSeek 网页界面，配置如下：

• 在线搜索功能： 禁用

• 深度思考功能： 启用

测试方法很简单：输入提示仅包含文本 <think>，并记录返回结果。在独立的聊天会话中进行了七轮独立测试，没有任何对话历史或上下文提示。

现在我们输入单词 <think> 并检查答案，我们测试了几轮（七次独立的、没有任何上下文的聊天）

1.2.1 测试 01 [无 bug]

如下图所示，模型正确解释了输入，并返回了关于 <think> 标记的正常解释。

1.2.2 测试 02 [出现 bug]

在本轮中，模型生成了完全不相关的响应。当展开推理痕迹时，显示模型正在尝试回答问题 “如何画一个立方体？”，尽管在此会话中从未问过这个问题。

1.2.3 测试 03 [无 bug]

在此测试中，模型将 <think> 标记视为系统级指令或保留关键字，这是更合理和预期的行为。

1.2.4 测试 04 [出现 bug]

在本轮中，模型意外地尝试回答数学问题：

“所有域 F 上的 n 维向量空间都同构于 n-元组空间 F^n，这种说法正确吗？”

生成的内容与用户输入无关。

1.2.5 测试 05 [出现 bug]

在本轮中，模型生成了句子：

“还有一个附加约束：aja_jaj 是不同的正整数。”

输出似乎是从一个更大的数学或算法相关提示中提取的片段/部分（如下图所示）

1.2.6 测试 06 [无 bug]

本轮产生了相对正常和合理的响应。模型表示它正在准备推理过程，然后回答用户请求。

1.2.7 测试 07 [出现 bug]

在最后一轮中，模型尝试回答一个不相关的编程问题“我们有一个数字数据集，代表用户每天发送的消息数量。定义一个函数 calculate_limits(mean, std_dev)，根据 68-95-99.7 法则返回可接受范围的下限和上限。”，甚至开始自动生成 Python 代码，如下图所示：

根据七次独立测试，(4/7) 的会话生成了不相关或异常的响应。这表明在测试配置下，<think> 标记有相对较高的概率触发模型不稳定的行为。

1.3 官方解释与初步讨论

今天（2026年5月19日），官方 DeepSeek 账号发布了解释（“关于 <think> 标记导致模型出现幻觉问题的说明”）。根据官方解释，该问题是由一个特殊标记触发了模型内部的异常幻觉行为，并且公司表示没有证据表明存在私人信息泄露。（如下图所示）

尽管官方解释将问题归因于特殊标记触发的幻觉，但一个重要的问题仍然存在：

如果异常行为纯粹是由分词器或模型级别的幻觉引起的，那么在完全隔离的本地部署的 DeepSeek 模型上运行，在没有共享推理基础设施的独立 GPU 服务器上，是否也会出现同样的问题？

为了进一步调查这种可能性，我们使用本地部署的 DeepSeek 模型进行了额外的验证实验。

2. 验证实验设置与结果

根据 DeepSeek 的官方解释，异常行为是由特殊标记触发的幻觉引起的。如果这个解释是正确的，那么我猜在完全隔离的本地部署的 DeepSeek 模型上运行，在没有共享云推理基础设施或请求缓存系统的独立 GPU 服务器上，也应该能够复现相同的行为。

2.1 实验平台

本次测试使用的实验平台是一台 NVIDIA GB10 DGX-Spark AI 工作站，拥有 128 GB 共享内存。硬件资源足以通过 Ollama 在本地部署和运行更大的 DeepSeek-R1 32B 模型。

实验环境包括：

• 硬件平台： NVIDIA GB10 DGX-Spark

• LLM 框架： Ollama

• 使用的模型： deepseek-r1:32b

• 执行模式： 完全本地推理，无外部 API 访问

实验的主要目标是确定单独的 <think> 标记是否能够一致地触发在官方 DeepSeek 网页服务中观察到的相同异常幻觉行为。

2.2 实验程序

创建了一个简单的 Python 测试程序，用于反复向本地部署的模型发送 <think> 标记，并记录推理痕迹和最终响应。

实验代码如下：

from ollama import chat
for i in range(10):
    print("Test Around %s" %str(i))
    response = chat(
        model='deepseek-r1:32b',
        messages=[{'role': 'user', 'content': '<think>'}],
        think=True,
    )
    print('Thinking:\n', response.message.thinking)
    print("Response from Model:")
    print(response.message.content)

2.3 实验结果

多次执行了实验，以观察在完全本地部署环境中是否能够复现异常行为。

2.3.1 执行轮次 01

在第一轮执行中，所有十个响应都直接与 <think> 标记本身相关。模型一致地将该标记识别为特殊关键字、格式标记或不完整的指令。

在此轮测试中未观察到不相关的问​​题、隐藏的提示或异常的推理痕迹。

响应表明模型正确解释或安全地处理了 <think> 标记，而没有生成随机的幻觉内容。

2.3.2 执行轮次 02

随后使用相同的配置和输入重复了实验。

在本轮中，模型在所有测试用例中再次正确处理了 <think> 标记。大多数响应表明输入不完整、不清晰或不足以生成有意义的答案。

模型要么安全地忽略了该标记，要么将其视为与格式相关的占位符，而不是生成不相关的响应。

未复现与 DeepSeek 网页服务中观察到的异常输出类似的情况。

2.3.3 执行轮次 03

对实验进行了第三轮重复。

与前几轮类似，模型一致地正确处理了 <think> 标记。在所有测试迭代中，生成的响应都保持稳定且上下文合理。

同样，没有出现模型意外生成不相关的数学问题、编程任务或来自其他上下文的隐藏推理痕迹的情况。

2.4 初步观察与讨论

基于前 30 个测试用例，本地部署的 DeepSeek-R1 32B 模型未能复现官方 DeepSeek 网页服务中观察到的异常行为。

此后还进行了额外的实验轮次（另外 30 次测试），但在当前实验环境中仍未能复现相同的问题。

3. 推测与讨论

基于实验结果和在线讨论，<think> 标记问题的确切原因仍未 100% 确定。尽管 DeepSeek 官方解释说异常行为是由特殊标记触发的幻觉引起的，但不同用户的验证结果似乎不一致。

一些人提到，即使在本地部署的环境中，他们也能复现类似的异常输出，而其他测试——包括本文描述的实验——在独立 GPU 执行下未能复现该问题。这表明问题可能不是由单一因素引起的。

一个重要的讨论点是幻觉内容的性质本身。如果生成的“随机”答案包含比模型原始训练截止日期或发布时间更新的信息、事件或引用（正如我们已经发现的），那么问题就变得更加复杂。在这种情况下，就会引发关于响应是模型纯粹产生的幻觉，还是推理基础设施中可能存在某种形式的意外信息暴露或上下文泄露的疑问。

在目前阶段，仍然没有公开证据证明实际的跨用户私人数据泄露。然而，此案例凸显了与现代 LLM 系统相关的几个重要安全问题：

• 隐藏或保留的特殊标记可能会无意中暴露内部推理机制。

• 不正确的提示解析可能允许用户触发不稳定的模型状态。

• 共享推理基础设施可能会增加请求之间上下文污染的风险。

• 当注入特殊标记时，推理模式模型可能会暴露隐藏的思维链处理行为。

• 前端提示格式化和后端推理管道可能与独立的本地部署不同。

从 LLM 安全的角度来看，此案例也可以被视为一种 特殊标记攻击 或 提示状态操纵攻击，其中精心制作的标记试图干扰模型的内部推理或控制流。即使不存在实际的数据泄露，不稳定的隐藏状态行为本身仍然可能成为安全风险，因为它可能暴露内部提示、隐藏的推理结构或意外的模型行为。

感谢您花时间阅读本文详情，如果您有任何疑问、建议或发现任何程序 bug，请随时给我留言。如果您能提供一些评论和改进建议，我们将不胜感激，以便我们做得更好~

最后由 LiuYuancheng ([email protected]) 于 2026/05/20 编辑，如果您有任何问题，请给我留言。