快速结论:该问题通常发生在使用 llama.cpp 加载 LFM2.5 1.2B Thinking 的 GGUF 模型并开启对话或推理时:模型输出中的 <think> 标签没有被聊天模板正确解析,而是直接出现在 content 字段里。优先排查 GGUF 文件内置的 chat template 是否已更新,而非推理后端或显卡问题。
适用环境:Issue 中确认的环境为 Windows x86_64、CUDA 后端、Nvidia T1000 显卡,llama.cpp 版本 0.4.0-dev(build 10883,commit 91f6a6cf3),使用 Clang 20.1.8 构建;模型为 LiquidAI/LFM2.5-1.2B-Thinking 的 GGUF。Issue 未提供 Python、PyTorch 版本信息,无需针对这些项排查。
最快修复方案:重新下载 LiquidAI 重新上传的修复版 GGUF 文件(LFM2.5-1.2B-Thinking-GGUF 仓库),替换本地旧的 GGUF 后再次测试。Issue 中报告者已确认替换后恢复正常。
注意事项:问题根因是 GGUF 内嵌的聊天模板有误,仅升级或降级 llama.cpp 版本并不能从根本上修复;报告者观察到 b9474 之后才出现异常、b9473 正常,但这更可能是当时使用的 GGUF 模板版本差异所致。issue 标签为 bug-unconfirmed,除该模型仓库外未验证其他 GGUF 来源是否同样受影响。
问题场景
用户在 llama.cpp 中加载 LFM2.5 1.2B Thinking 模型进行对话推理时,模型的思考过程没有被解析到独立的 reasoning/thinking 字段,而是连同 <think> 标签一起显示在正常的 content 字段中。用户对比发现 b9473 及更早版本表现正常,b9474 之后开始出现该现象。
报错原文
Eval bug: LFM2.5 1.2 Thinking - Think tags displayed in content
原因分析
Issue 讨论确认,原因是该模型 GGUF 内置的 chat template 有问题。上游 Hugging Face 模型仓库已修复模板,但对应的 GGUF 文件当时没有同步更新,导致 llama.cpp 按错误的模板处理输出,<think> 标签只能原样出现在 content 中。因此问题不在 CUDA 后端或显卡,而是模型文件元数据层面的问题。
环境排查
- 确认当前使用的 GGUF 文件来源与下载时间,是否来自 LiquidAI/LFM2.5-1.2B-Thinking-GGUF 仓库修复前的版本。
- 确认 llama.cpp 具体构建版本(Issue 中为 0.4.0-dev build 10883,commit 91f6a6cf3)。
- 确认运行平台与后端(Issue 中为 Windows x86_64 + CUDA),但这大概率与问题无关。
- 可对比检查模型元数据中的 chat template 是否包含正确的 thinking 标签处理逻辑。
解决步骤
- 前往 LiquidAI/LFM2.5-1.2B-Thinking-GGUF 仓库,重新下载官方重新上传的修复版 GGUF。
- 用新下载的 GGUF 替换本地旧文件,确保加载路径指向新文件。
- 重新启动 llama.cpp 对话,发送一个会触发思考过程的问题进行测试。
- 若仍异常,记录所用 GGUF 来源与 llama.cpp 构建版本,到对应仓库反馈。
验证方法
观察模型回复:思考内容应出现在独立的 reasoning/thinking 字段中,content 字段不再直接出现 <think> 标签。报告者按此方式验证后确认问题已修复。
参考来源
AI 工具推荐
想把多个 AI 模型放在一个入口?
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。
推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。
这个方案解决了吗?
可以继续搜索完整报错,或查看同一工具的其他排查指南。


![[Bug]: Security concern: `/invocations` endpoint is enabled by default and bypasses API key authentication](https://www.chat-gpts.plus/wp-content/uploads/2026/10/64391-4ea45fd5-768x403.jpg)