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

近期有使用者觀察到 DeepSeek LLM 最新版本出現一個問題/臭蟲：在測試時，當使用者提示中包含特定的不完整或特殊符記，例如 <think> 或 <think，模型可能會產生極不穩定的回應、嚴重的幻覺、異常的推理輸出或意外的行為。

本文旨在記錄此問題，示範如何重現此行為，並討論為更好地理解問題的可能原因而進行的驗證實驗。本文分為三個主要部分：

• 介紹與重現 <think> 符記問題：說明發現的問題，包括範例提示和觀察到的異常模型行為。

• 驗證實驗設計與結果分析：介紹本地驗證實驗設置、測試方法、收集的輸出以及對驗證結果的分析。

• 討論與一些假設：與分詞器行為、提示解析機制以及潛在安全影響相關的討論與假設。

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

1. 臭蟲介紹與重現

1.1 臭蟲介紹

大約三天前（2026/05/16），多位使用者回報與 DeepSeek LLM 模型網頁聊天互動時出現異常行為。在測試過程中，使用者發現如果提示僅包含特殊符記 <think> 或不完整符記 <think，模型可能會意外地產生不相關的回應、隱藏的推理軌跡，或回答當前使用者從未問過的問題。

在幾種情況下，生成的內容看起來在邏輯結構和語境上都有意義。由於其中一些回應看起來像是有效使用者查詢的片段，網路上的討論很快就引發了對可能跨會話數據洩漏或推理快取暴露的擔憂。

發現時，社群討論了幾種可能的解釋：

• GPU 快取或負載平衡器快取洩漏：一些使用者懷疑推理伺服器快取在請求之間沒有被正確清除，可能導致其他使用者的提示或推理軌跡片段出現在不相關的會話中。

• 分詞器或提示解析器臭蟲：其他人認為問題與分詞器或內部提示格式化機制有關，其中 <think> 符記可能意外觸發隱藏的推理模式行為或特殊的內部指令。

• 特殊符記解析問題：另一種假設是 <think> 可能被視為模型在思考過程生成時使用的保留控制符記，當直接暴露給使用者輸入時，會導致不穩定的輸出。

1.2 臭蟲重現

此臭蟲相對容易重現。在本實驗中，使用了官方 DeepSeek 網頁介面，並進行了以下配置：

• 線上搜尋功能： 已禁用

• 深度思考功能： 已啟用

測試方法很直接：輸入提示僅包含文字 <think>，並記錄返回的結果。在獨立的聊天會話中進行了七輪獨立測試，沒有任何對話歷史或上下文提示。

現在我們輸入單詞 <think> 並檢查答案，我們測試了幾輪（七次獨立的、沒有任何上下文的聊天）。

1.2.1 測試 01 [無臭蟲]

如下所示，模型正確解釋了輸入，並返回了關於 <think> 符記的正常解釋。

1.2.2 測試 02 [出現臭蟲]

在本輪測試中，模型產生了一個完全不相關的回應。當展開推理軌跡時，顯示模型正在嘗試回答問題 「如何畫一個立方體？」，儘管在此會話中從未問過這個問題。

1.2.3 測試 03 [無臭蟲]

在此測試中，模型將 <think> 符記視為系統級指令或保留關鍵字，這是一個更合理且預期的行為。

1.2.4 測試 04 [出現臭蟲]

在本輪測試中，模型意外地嘗試回答數學問題：

「所有定義域為 F 的 n 維向量空間都同構於 n-元組空間 F^n，這是否正確？」

生成的內容與使用者輸入無關。

1.2.5 測試 05 [出現臭蟲]

在本輪測試中，模型生成了句子：

「還有一個額外的限制：aja_jaj 是不同的正整數。」

輸出似乎是從一個較大的數學或演算法相關提示中提取的片段/部分（如下所示）。

1.2.6 測試 06 [無臭蟲]

本輪產生了一個相對正常且合理的迴響。模型表示它正在準備推理過程，然後回答使用者請求。

1.2.7 測試 07 [出現臭蟲]

在最後一輪測試中，模型嘗試回答一個不相關的程式設計問題：「我們有一個數字數據集，代表使用者每天發送的消息數量。定義一個函數 calculate_limits(mean, std_dev)，該函數根據 68-95-99.7 法則返回可接受範圍的上下限。」，甚至開始自動生成 Python 程式碼，如下所示：

根據七次獨立測試，(4/7) 的會話生成了不相關或異常的回應。這表明在測試配置下，<think> 符記有相對較高的機率觸發不穩定的模型行為。

1.3 官方解釋與初步討論

今天（2026/05/19），官方 DeepSeek 帳號發布了解釋（「關於 <think> 符記導致模型產生異常幻覺問題的說明」）。根據官方解釋，該問題是由特殊符記觸發模型內部的異常幻覺行為所致，公司聲明沒有證據表明存在私人資訊洩漏。（如下所示）

儘管官方解釋將問題歸因於特殊符記觸發的幻覺，但一個重要問題仍然存在：

如果異常行為純粹是由分詞器或模型級別的幻覺引起的，那麼在沒有共享推理基礎設施的獨立 GPU 伺服器上完全隔離部署的 DeepSeek 模型本地部署中，是否也會出現相同的問題？

為了進一步探究這種可能性，我們使用本地部署的 DeepSeek 模型進行了額外的驗證實驗。

2. 驗證實驗設置與結果

基於 DeepSeek 的官方解釋，異常行為是由特殊符記觸發的幻覺引起的。如果這個解釋是正確的，那麼我猜測在完全隔離的本地部署環境中，在沒有任何共享雲端推理基礎設施或請求快取系統的獨立 GPU 伺服器上運行 DeepSeek 模型，也應該能夠重現相同的行為。

2.1 實驗平台

本次測試使用的實驗平台是一台配備 128 GB 共享記憶體的 NVIDIA GB10 DGX-Spark AI 工作站。硬體資源足以透過 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 安全的角度來看，這個案例也可以被視為一種特殊符記攻擊 或提示狀態操縱攻擊，其中精心製作的符記試圖干擾模型的內部推理或控制流程。即使沒有實際數據洩漏，不穩定的隱藏狀態行為本身仍然可能成為安全風險，因為它可能會暴露內部提示、隱藏的推理結構或意外的模型行為。

感謝您花時間閱讀本文細節，如果您有任何問題、建議或發現任何程式錯誤，請隨時給我留言。如果您能提供一些評論和改進建議，我將不勝感激，以便我們能做得更好~

最後由 LiuYuancheng ([email protected]) 於 2026/05/20 編輯，如果您有任何問題，請給我發送訊息。