用ktransformers跑671b的DeepSeek R1

最近这两天，在折腾拿一台4块V100的GPU卡，来跑个671b准满血的DeepSeek R1，遇到了很多问题，也解决了很多问题，当然估计还留下很多问题。这期间遇到一个个的挑战，搞定一个后又遇到下一个，突然有点十多年前折腾linux的时候的意思了，觉得挺好玩的，就也像以前一样，稍微记录一下吧。

先说下背景，我这台机器的配置是比较古老的数据中心版的GPU机器，显卡上面说了是4块V100，每块16G显存，cpu只有20核、内存256GB、数据盘1.5T，系统是ubuntu 20.04。这硬件拿来跑671b确实是有点捉襟见肘，最终的结果也只是1 token/s 左右，并不具备生产价值，只是研究而已。

我最先遇到的问题，就是由于这个机器很多人有权限，而是最恐怖的公用一个linux账号，环境被搞得想当乱，python都是各种版很多套。所以我最先做的就是梳理环境，用了Miniconda搞了一套干净的python-3.12的运行时，后续的各种包都独立维护。
另外，原先的Nvidia驱动也有两个版本，我也顺手给升级并统一了一下，查了各种资料后，发现这个架构比较旧的显卡最好还是不要安装最新的（12.8）驱动，所以我安装了12.6的版本。
然后，我的思路是，在本机直接编译一个ktransformers，这样才有最大的自由度，我感觉这是最终能跑起来的关键，因为到最后还需要现场修改一些代码才能跑起来。
从源码编译安装的过程主要参照官网文档，但在执行 bash install.sh 之前，还需要干两件事：

• 一个是export TORCH_CUDA_ARCH_LIST="7.0"，这个7.0的值，就是V100的硬件架构。
• 另一个是 pip3 install flash-attn，这个模块虽然在V100下最终没有用到，但不装会报依赖错误

现在，按照官方文档的说法，应该是要可以跑起来了，然而你跑 python -m ktransformers.local_chat --model_path ./DeepSeek-R1 --gguf_path ./DeepSeek-R1-Q4_K_M的时候，大概率会在load很久之后，报一个错：

RuntimeError: CUDA error: invalid device function
CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.
For debugging consider passing CUDA_LAUNCH_BLOCKING=1
Compile with TORCH_USE_CUDA_DSA to enable device-side assertions

这个问题，我折腾了很久，简单来说大概就是因为过程中会调用flash-attn，而flash-attn其实并不支持V100，在官方的issue列表里搜了一圈后我发现还真有人遇到类似的问题了，而且也贴了一些解决方案，评估了一下，我最终是按这个办法来做的，这里我感觉大概是刻意避开了对flash-attn的调用，可能会影响效率但不会报错了。其中第五步，对ktransformers/ktransformers/operators/attention.py的修改，是用了这个据说更快的方案。。。
改完再运行，还是会报内存不足的错误（可能是显存不足），因为默认只会用单块V100，16G的内存显然是不够的，这时候需要加 optimize_rule_path 参数，给一些优化规则，实测可以这样：python -m ktransformers.local_chat --model_path ./DeepSeek-R1 --gguf_path ./DeepSeek-R1-Q4_K_M --cpu_infer 20 --optimize_rule_path ktransformers/ktransformers/optimize/optimize_rules/DeepSeek-V3-Chat-multi-gpu-4.yaml这个DeepSeek-V3的4卡规则，对于R1也同样有效。
加了这个规则以后，加载过程应该就可以看到会加载到不同的GPU去了，nvidia-smi也能看到4块卡的显存都用起来了。
最终应该就可以响应你的问题了！虽然大概只能到1 token/s 左右。。。

至此大致结束，后面又折腾了一下web的配置，大概也是根据官方文档来的，这个没啥特殊就不展开了。
最后，感谢朋友发的这篇文章，就是这篇公众号文章让我开始有动力折腾这个事情的，哈哈！