DeepSeek本地性能调优

技术背景

大模型性能调优是一个很复杂的工程，涉及到很多细节，如果真要对模型动刀子，还需要对模型和数据集本身有非常好的理解。这里我们仅仅考虑模型加载过程中，可以优化的一些参数配置。关于DeepSeek在本地的部署，以及PageAssist插件的使用，可以参考DeepSeek合集。

调优思路

一句话总结一下调优思路，如果你已经尝试过了，那么可以略过本文：

GPU内存 > 多GPU内存 > CPU > 共享内存

遵循这个逻辑，对模型的加载层数进行配置，从而达到本地性能优化的目的。

DeepSeek-R1-32B-Q4_0测试

首先尝试用命令行启动，作为一个基线：

PS A:\DeepSeek\models> ollama run deepseek-r1-32B-Q4:latest --verbose
>>> 简述拉格朗日乘子法在生物学中的应用场景。

</think>

拉格朗日乘子法是一种优化技术，用于在有约束条件下寻找函数的极值。在生物学中，该方法可以应用于以下场景：

1. **生态模型**：在研究生态系统时，可能需要在资源有限的情况下最大化物种数量或最小化灭绝风险。拉格朗日乘子法可以帮助
找到这些条件下的最优解。

2. **基因表达分析**：在基因调控网络中，优化基因表达水平以满足特定的生物目标（如蛋白质产量最大化）时，可以使用拉格朗
日乘子法来处理约束条件。

3. **资源分配问题**：例如，在种群动态模型中，如何在有限的食物资源下分配给不同物种以达到某种平衡状态，拉格朗日乘子法
可以帮助找到最优的资源分配方案。

4. **进化生物学中的适应性优化**：研究生物体在环境压力下的最佳适应策略时，可以利用拉格朗日乘子法来求解在特定约束条件
下的最优适应度。

总之，拉格朗日乘子法为生物学中涉及优化和约束的问题提供了一种有力的工具。

total duration:       54.8643183s
load duration:        16.1375ms
prompt eval count:    21 token(s)
prompt eval duration: 5.23s
prompt eval rate:     4.02 tokens/s
eval count:           241 token(s)
eval duration:        49.611s
eval rate:            4.86 tokens/s

速度大约是4.86t。默认参数下的内存占用情况如下：

PS C:\Users\dechin> ollama ps
NAME                         ID              SIZE     PROCESSOR          UNTIL
deepseek-r1-32B-Q4:latest    d4a2da196dc7    19 GB    23%/77% CPU/GPU    4 minutes from now

Windows平台还可以用任务管理器查看资源占用：

这里我们发现一个问题：Ollama默认的加载配置是GPU > CPU的策略。也就是说：

GPU内存 > 多GPU内存 > 共享内存 > CPU

如果说，你的本地有众多的显卡，可以完全的把模型加载到显存里面，那么毫无疑问这个策略是对的。问题就在于，现在是大语言模型有小型化、本地化的趋势，所以如何让大模型在本地有限的硬件条件下跑起来，能用，才是最关键的。我们尝试去修改参数num_gpu:

这里使用的是PageAssist来进行加载了，可以用终端查看一下资源分配的情况：

PS C:\Users\dechin> ollama ps
NAME                         ID              SIZE     PROCESSOR          UNTIL
deepseek-r1-32B-Q4:latest    d4a2da196dc7    20 GB    23%/77% CPU/GPU    4 minutes from now

需要提醒的是，不论是内存还是共享内存，在Ollama这里就是属于CPU那一列。虽然跟默认配置都是23%/77% CPU/GPU，但是如果我们用系统资源管理器来查看，就会发现此时没有占用共享内存：

tokens表现：

在这个配置下，tokens速度达到了6.45t，比默认配置的速度4.86t要优化了一些。再者考虑到这里显存并没有占满，所以还有优化的空间，可以再把层数拉大：

再次运行起来，我们可以看到显存资源基本上是占满了，再加大有可能报OOM错误：

tokens表现：

此时tokens速度来到了7.54，进一步优化了模型的性能。此时模型加载的比例有一点点变化：

PS C:\Users\dechin> ollama ps
NAME                         ID              SIZE     PROCESSOR          UNTIL
deepseek-r1-32B-Q4:latest    d4a2da196dc7    20 GB    22%/78% CPU/GPU    4 minutes from now

虽然CPU的比例只是降了1%，但是因为不涉及到共享内存的使用，性能反而得到了优化。

DeepSeek-R1-70B-Q2_K测试

其实原本以为70B-Q2K已经是我的本地可以运行的模型的极限了，所以甚至没有使用Q4_0。首先我们使用70B num_gpu=64进行测试：

此时资源的占用比例为：

PS C:\Users\dechi> ollama ps
NAME                          ID              SIZE     PROCESSOR          UNTIL
deepseek-r1-70B-Q2K:latest    eb199ae0e147    28 GB    45%/55% CPU/GPU    4 minutes from now

tokens表现：

这里tokens速度仅有0.28，说实话已经是一个不太能接受的性能了，不如直接用API。不过我们这里以优化性能为主要考量，继续考虑调参方向。如果设置num_gpu=56：

PS C:\Users\dechi> ollama ps
NAME                          ID              SIZE     PROCESSOR          UNTIL
deepseek-r1-70B-Q2K:latest    eb199ae0e147    29 GB    46%/54% CPU/GPU    4 minutes from now

比例有一点点微小的变化，但是主要还是得从资源管理器里面去查看共享内存的使用情况：

可以看到GPU内存基本占满，共享内存接近于0，这里把CPU也拉起来了：

tokens表现：

这里我们优化后的tokens性能在3.09t，说实话吐字速度勉强是可以接受的，比默认配置优化了10倍的性能。不过这里Q2_K模型的语言能力实在是有点一言难尽，建议还是使用Q4_0以上的模型。

总结概要

对于本地模型的加载来说，除了使用KTransformer等工具进行指令集层面的优化之外，还可以调整模型加载层数，做一个简单的优化。这里提供了一个num_gpu和num_ctx参数调整的策略，实测Tokens性能最大可优化10倍左右。

版权声明

本文首发链接为：https://www.cnblogs.com/dechinphy/p/share-memory.html

作者ID：DechinPhy

更多原著文章：https://www.cnblogs.com/dechinphy/

请博主喝咖啡：https://www.cnblogs.com/dechinphy/gallery/image/379634.html