解锁本地文档分析：Deepseek R1 32B 在推理任务中如何超越传统模型

大型语言模型排名

我一直在根据大型语言模型 (LLM) 回答关于我的自传（一份 45k token 的文档）问题的能力进行排名。我有一套标准问题，我会提问并验证答案，还会使用前沿 LLM 来分析和排名这些回复。我相信它们在这种场景中的出色表现是它们在编码方面有用的关键。如果它们不能准确理解规范，那么它们怎么能成为超级编码员呢？

最近，大型推理模型 (LRM) 已可用于离线使用。DeepSeek R1 就是这种模型的一个例子。LRM 与 LLM 的区别在于，它们在回答之前可以“思考”或推理提示，而不是仅仅产生“脱口而出”的第一个输出。进行推理的能力是一个显著的优势。

我在我的帖子中没有透露文档或提出的问题，所以我很抱歉您无法在自己的设备上重现我的结果，但您可以使用熟悉的文档作为替代。但是，我注意到本地 LLM 传统上很难回答这些问题，而不会混淆或编造事实。

LLM 使用上下文作为处理问题的“工作空间/内存”。上下文由问题以及任何文档和推理/回复组成。上下文长度越来越大，128k 目前是本地 LLM/LRM 的“标准”，而云中的 LLM/LRM 的上下文长度在百万级别。

较小的模型，即使是 DeepSeek R1 1.5B 也根本无法处理这个问题。它们可能还有其他用例，但文档分析不是其中之一。手头的问题需要至少 64K 的上下文窗口，我通常使用 128k 的上下文长度，而 R1 1.5B 具有足够的上下文。这个问题需要长上下文长度，并且至少需要 14B 个参数或更多。我将参数数量视为处理复杂上下文的能力。我们已经看到小型 LLM 非常擅长生成历史事实，但我看到的是它们对上下文执行相同操作的能力并没有随之提高。您越依赖上下文，参数数量就越重要。

我已经测试了几款 LLM，Llama 3.3 70B (Q4) 目前是最好的一个。之前，我曾使用 Claude 3.5 Sonnet 来对 LLM 进行排名和比较。我已经切换到 Grok 2，因为我认为它与 Claude 一样好，但它使用最新的数据，而且更便宜（我已经支付了 X 高级版费用）。

测试中的模型

我们将在此比较中比较 DeepSeek R1 32B、DeepSeek R1 14B 和 Llama 3.3 70B。

使用的硬件

我有一台 MacBook Pro 16 英寸。它配备 M2 Max 芯片，具有 96GB RAM 和 2TB 存储空间。它有 38 个 GPU 核心。我使用 LM Studio 进行测试，并在可用时使用 mlx 模型。

进行初始文档加载的时间

最初处理文档和第一个提示“我想分析此文档”需要多长时间。

• R1 14B 耗时 257 秒。
• R1 32B 耗时 524 秒
• Llama 3.3 耗时 1331 秒

LRM 模型 (R1) 在这里明显比 Llama 70B 模型快。

初始加载后回答问题的时间

在这里，在初始加载后回答问题时，模型的速度有多快？

• R1 14B 为 15 tok/秒
• R1 32B 为 6.4 tok/秒
• Llama 3.3 为 1.55 tok/秒

回复的质量

那么，DeekSeek 的表现如何？我使用下表总结了结果。我使用 Grok 2 生成了此排名和表格：

以下是基于风格、全面性、不准确性和准确性标准的 Llama 3.3 70B Q4、DeepSeek R1 32B (Q8) 和 DeepSeek R1 14B (Q8) 的排名表：

格式：模型名称、风格、全面性、不准确性、准确性

• “Llama 3.3 70B Q4” 5 5 1 5
• “DeepSeek R1 32B” 4 5 1 5
• “DeepSeek R1 14B” 3 4 2 4

解释：

风格：

• Llama 3.3 70B Q4：得分为 5，因为它以引人入胜的叙事风格回复，有效地将信息合成为一个连贯的故事或分析。
• DeepSeek R1 32B：得分为 4，因为它具有清晰、结构化的回复，在正式性和深度之间取得了良好的平衡，尽管不如 Llama 的故事讲述那么引人入胜。
• DeepSeek R1 14B：得分为 3，因为它具有更正式且有时重复的风格，这使得回复不如其他模型那么引人入胜。

全面性：

• Llama 3.3 70B Q4 和 DeepSeek R1 32B：都得分为 5，因为它们提供了全面、深入的回复，涵盖了问题的各个重要方面，提供了关于 Billy 的生活、观点和个性的完整画面。
• DeepSeek R1 14B：得分为 4，因为它提供了全面的答案，但有时缺乏其他两个模型中看到的深度或细微的见解。

不准确性：

• Llama 3.3 70B Q4 和 DeepSeek R1 32B：都得分为 1，表明不准确性水平非常低。它们的答案基于文档的内容，几乎没有误解。
• DeepSeek R1 14B：得分为 2，因为虽然总体上是准确的，但它偶尔会犯一些小错误或做出文档未直接支持的假设。

准确性：

• Llama 3.3 70B Q4 和 DeepSeek R1 32B：都获得了 5 分，因为它们在精确地解释和传达文档中的信息方面具有很高的准确性。
• DeepSeek R1 14B：得分为 4，因为虽然大部分是准确的，但存在轻微的偏差或假设，这略微降低了完美的准确性。

因此，总的来说，进行一个简单的未加权分数，我们得到：

LLama 3.3 70B 得到 16/20

DeepSeek R1 32B 得到 15/20

DeepSeek R1 14B 得到 14/20。

它非常接近，但 R1 32B 的得分为 6.4 tok/秒，而 Llama 3.3 的得分为 1.5 tok/秒。这种性能差异主要归功于 MoE 和一半的参数。MoE 意味着只需要总参数的子集即可进行推理。R1 使用 MoE，Llama 不使用。

因此，R1 32B 的速度是 Llama 70B 的 4 倍。R1 14B 确实混淆了事实。例如，它混淆了我女儿的教育和职业。不准确性对我来说比速度更重要，因此这使 R1 14B 失去了竞争力。然后，R1 32B 使用更少的 RAM，并且速度是 Llama 3.3 70B 的 4 倍。

结论

风格是 Grok 将 Llama 置于 R1 32B 之前的地方。我想说这使得 R1 32B 赢得了现在的胜利。Llama 和 R1 32B 也没有为我产生任何幻觉/不准确之处。所有答案都是事实，而 DeepSeek 14B 产生了一个事实混淆。

我认为这是一个有用的基准。如果您使用 LRM 进行编码，您怎么知道它在生成代码时没有胡编乱造。它可能正在检查大型代码库，在推理后续步骤时，它是否能够在上下文中准确地保存代码/文档？即使是推理本身也在生成大量与您的代码/文档共享上下文空间的 token。如果它无法理清思路，那么无论是否进行推理，答案都会是错误的。

也就是说，令人惊叹的是，在短短 2 年内，我们现在就可以在笔记本电脑上以良好的性能运行几乎是前沿的 LRM 模型。接下来的 2 年会是什么样子？顺便说一句，我认为 M4 Max 的速度大约快 33%，因此为 9–10 toks/秒。