使用llama2模型查询/generate
API的效果如预期。我在查询字符串中追加了keep_alive=0
,以便将模型保留在RAM中,从iotop
中我可以立即看到它在RAM中加载模型(我处于CPU单核模式)。加载似乎也在单个子进程或线程中进行 - 由于我不知道底层设计,因此不确定是哪个,但它看起来像是一个子进程。
然而,当切换到llama2:70b模型时,情况发生了变化。它执行相同的单一进程加载模型,并且由于模型本身更大,所以耗时更长,但此后16个ollama进程不断从磁盘读取,速度约为140MB/s,结果生成速度非常慢。我有一台7950x,所以16个进程是有道理的,但我确实有64GB RAM,这对于模型来说应该是足够的。top
显示RAM使用率为34GB,但由于幕后存在内存Map,虚拟内存达到了预期的约46GB。
我找不到阻止ollama不断用llama2:70b模型敲打磁盘的方法。不幸的是,我不了解Golang,但这是否是由于内存Map在进程之间没有正确共享而导致的问题?
5条答案
按热度按时间7xllpg7q1#
在发现https://github.com/ollama/ollama/blob/main/docs/api.md后,回答自己的问题。在API调用中传递"use_mmap": false作为选项。这解决了所有问题。
798qvoo82#
你好,@hedleyroos,感谢你提出这个问题。这确实是因为llama2:70b相当大,可能会被分页到磁盘上。我已经更新了,如果模型太大而无法放入内存中,我们可能可以禁用mmap。你的机器上有多少RAM?
z18hc3ub3#
你好,@jmorganca 。我有64 GB。
lb3vh1jj4#
如何禁用模型完全加载到RAM中?我在具有巨大RAM的CPU仅型号的机器上测试此功能。我看到API有一些选项,但是否有CLI的方法?
h6my8fg25#
我从ollama CLI设置了
/set parameter use_mmap 0
(以及仅用于CPU推理的/set parameter num_gpu 0
),从系统监视器来看,似乎模型已加载到内存中。