尝试使用双卡 P104-100 运行大语言模型

Introduction（bushi 鉴定为搞学术搞的
在我之前的文章，我说了我买了四张P104-100用于跑Blender Sheepit渲染积分，现在我想试试看开发出新的玩法——用P104-100通过Ollama运行大语言模型。因为大语言模型的话，显存大小很重要，很大程度上是显存即正义，一些比较大的模型，我的RTX2080Ti 11G显存还是力不从心。虽然说P104-100才8GB的显存，但是招架不住它便宜啊，79包邮的价格要什么自行车，买两张不就是16G了吗？虽然说不能这么算，但是Ollama支持把大语言模型拆分到不同的显卡进行运行，买都买了，不如试试看？

目前的硬件情况

目前的四张P104并不是安装在一起的，而是分别放在两个不同的机器上面。又因为我没有支持安装四卡的主板，所以想测试四卡并行跑比较大的模型还是算了。
还有一个比较蛋疼的问题是，因为我算是为了利用闲置硬件买的卡，所以是一块H61+E3-1220v2+两条8G内存。这样子做主要是为了满足Sheepit的需求，因为它不支持多GPU同时渲染，所以只能每个GPU开一个实例，分开渲染，占用双倍资源，所以显卡并没有全部安装在一起。也正因为是这样，第二张卡是通过PCIe X1的延长线转接出来的，啊对，就是挖矿用的那种延长线，因为Cycles渲染只需要一次性加载数据，所以即使是PCIe 1.0 X1也影响不大，无非就是加载慢一点。但是，如果是多卡并行跑LLM就是另一个故事了，会涉及频繁的数据交换，这样子即使是显卡原来就砍废的PCIe 1.0 X4都会造成严重瓶颈，更何况转接板的PCIe 1.0 X1。
虽然理论上跑起来的效果会非常难看，但是，实践是检验真理的唯一标准，不试试看怎么知道是什么情况呢？于是我打算尝试一下。

部署Ollama

这算是论文的 Approach 吗？（bushi 鉴定为搞学术搞的
因为目前Pascal架构的N卡驱动还是支持的，但是今年10月就正式抛弃，所以，现在还是可以使用最新的Ollama，也算是赶上末班车了。如果后面Ollama也抛弃这些老架构，那就真的寄了，但是跑当下的模型，未来也是可以跑的，只不过有可能新的模型就跑不了了。Pascal架构的显卡最后支持应该是CUDA 12.9了。
所以，直接打开Github下载最近版本的Ollama就行了，因为Ollama更新频繁，文章写作测试时用的是前不久的0.11.10版本，进行测试。如果你部署出现什么问题，建议切换到这篇文章使用的相同版本，也就是0.11.10。毕竟在0.11.11的What's Changed里面，增加了CUDA 13的支持，不知道会不会影响Pascal架构的最后CUDA 12.9版本，因为文章的重点不在这里，如果有需要请自行验证，也欢迎你在评论区说一下验证的结果。
部署的方式也很简单，在Github的Releases找到对应版本的Ollama下载就行了，有点大，慢慢下就行。
下完后解压即可使用：

mkdir ollama
mv ollama-linux-amd64.tgz ollama/
cd ollama/
tar -xzvf ollama-linux-amd64.tgz
rm ollama-linux-amd64.tgz

因为Ollama默认会把模型下载在用户文件夹的.ollama隐藏文件夹下，会占用大量空间。为了避免这种情况，我选择创建一个数据文件夹，并设置Ollama将模型文件放在那里。

mkdir data

然后指定创建的data文件夹为临时HOME目录后，启动Ollama。
下面是启动脚本run.sh，请放在刚刚创建的ollama文件夹里面。

export HOME=/home/rin/ollama/data/
./bin/ollama serve

/home/rin/ollama/data/请替换为你需要存放模型的实际路径。
然后直接启动Ollama:

./run.sh

进入ollama/bin/目录，执行以下命令运行LLM：

./ollama run qwen3:8b --verbose

这里的实例用的qwen3:8b，可以根据实际需需要替换为目标模型。--verbose是设置显示 Ollama 每秒生成的 Token 数量。
测试平台如图所示：

以下测试均在Ollama 0.11.10进行。
注意！数据为我本人实测结果，不同环境和提示词结果可能会有差异！

单卡P104-100跑常见模型速度测试

模型均使用最新模型进行测试，测试的提示词是：

请帮我写一段2000字的小故事，讲述两只猫娘 Chocola 和 Vanilla 的日常生活。

通义千问

测试通义千问的时候，在模型推理回答期间，显卡的PCIe I/O是上去的，在测试qwen3:0.6b的时候，大概会双向干到差不多100MB/s的双向传输速度，CPU其中一个核心跑满。而且我发现一个有趣的现象，也就是每秒生成Token数越多，带宽占用越高；每秒生成Token数越少，带宽占用越低。特别是qwen3:4b模型，一开始推理速度极快，到后面速度就降下来了，PCIe交换速率也随之下降。虽然PCIe 1.0 x1理论速度250MB/s，但是我发现在模型加载的时候，大概只能跑到200MB/s左右的速度。不过即使是这个速度，也满足了模型推理期间的数据交换需求。所以用这种矿渣卡跑LLM完全是可行的。
另外，我还发现了一个致命的问题，当在提示词中要求的字数太多时，例如要求写10000字的文章，通义千问就会变成复读机，一直在重复其中一段话，永远不停止，只能Ctrl+C强行停止。这个情况在我这边可以稳定复现，经过测试，qwen3:1.7b qwen3:4b这几个模型都有出现过这样的情况，不知道是硬件问题导致的还是模型缺陷，但是可以肯定的是，换另一张P104-100跑也是同样的结果。

DeepSeek

对比通义千问，deepseek-r1的三个不同的模型在单显卡的PCIe I/O速度上是类似的，并没有出现明显的随着每秒生成Token数越多，带宽占用越高，整体趋于稳定。
我也顺带测了一下DeepSeek在回答要求写10000字的文章这种问答时，会不会出现复读机的情况。进行了几轮测试下来，确实没有遇到或者说触发，相对而言通义千问更容易触发。

Gemma

Gemma再次出现了类似通义千问的复读机现象，尤其是gemma3:270m，是几乎稳定触发。gemma3:1b也有触发的现象，但是概率相比于通义千问要低。
另外，gemma3:270m因为模型比较小，回答速度突破了110 tokens/s，其返回占用带宽相比于前面两个模型要高得多，达到了180MB/s。
不过gemma3:4b的PCIe I/O的速度占用有点反常，Rx反而变高了。

Llama

由于Llama能塞进8G显存的模型只有一个，所以只测试了llama3.1:8b。

双卡P104-100跑常见模型速度测试

前面的测试只是前菜，现在才是重点——双卡P104-100运行LLM测试。
测试时采用和单卡测试时一样的提示词，但是选择模型大小在8G以上16G以下的模型，能让两张卡同时开跑。
由于这个大小的模型，大部分只有系列里面的其中一个合适，所以只是测试了这个模型系列里面对应大小的一个模型。

ChatGPT

虽然但是，加载gpt-oss:20b模型的过程是很慢的，差不多加载了5分钟。

但是实际测试下来，gpt-oss:20b的输出速度算是能用的水平了，两块79包邮的矿渣有这个表现已经不错了。并且，实际上哪怕是PCIe 1.0 x1也没有造成太严重的瓶颈，甚至影响不大。

通义千问

DeepSeek

Gemma

Conclusion（确信）

经过以上的实验，我们可以得出以下结论：

• 在多卡或者单卡并行跑大语言模型时，每秒生成Token数越高，运行期间PCIe I/O带宽的占用也就越高。
• 在Token生产速度低于100 tokens/s时，带宽占用普遍在100MB/s以下，因此即使是使用了PCIe x1矿卡转接板，矿渣显卡运行在PCIe 1.0 x1的通信速度下，对性能也没有较大的负面影响。因为PCIe 1.0 x1实际上最大速度可达200MB/s，高于实验测试得到的IO交换的速度。
• 对于采用P104-100多卡运行LLM的方案，我认为是有很高性价比的，79一张包邮的价格，买两张组合起来即可以大约25-28 tokens/s的速度运行ChatGPT-oss 20B的模型，已经达到了相当可用的水平，性价比非常的高。

Discussion（确信）

虽然这个实验较为完整的评估了两张P104-100的大语言模型运行效果，但是由于我本人硬件条件有限，没有能测试四张P104-100的大语言模型运行效果，这个有待他人进行相关实验进行补充。
另外，我还发现了一个有意思的现象，在双卡P104-100运行大语言模型的时候，gpt-oss:20b的输出token速度要远远快于其他14b或者12b的模型，甚至达到了两倍的速度差别。这与常见的模型参数越大，模型运行速度越慢的常见情况有所出入。