Contents

1 前言
2 mac版ollama部署过程
- 2.1 安装ollama并下载运行llama3.2模型
- 2.2 使用”本机部署”的Lobechat进行调用
3 解决ollama跨域访问问题
- 3.1 其他部署模式跨域问题的解决方式
- 3.2 macos上源码部署ollama时解决跨域问题
4 高难度挑战
- 4.1 llama 3.2 vision模型介绍
- 4.2 实战测试
5 总结

前言

在之前的文章中，我已经写过如何基于ollama在本地运行llama3.2 3B 模型并使用 Lobechat进行调用(参见文章：家庭数据中心系列打造私有AI：基于Ollama在本地搭建开源大语言模型的详细教程)。只不过，当时由于硬件所限，我只能在inter CPU 的迷你主机上使用docker以仅CPU的方式进行部署。由于没有GPU的支持，使用i5 13400 CPU时候那一秒1-2个字的输出效果很让人抓狂，所以当时我就想着用m4的macmini来跑ollama不知道是什么感觉。

忍了2周，终于还是下单了，不过考虑到以后可能要经常跑本地大模型甚至还要学视频方面的一些操作，我咬咬牙下单了m4pro的最低配置版：

在运行本地大模型（如Llama 3.2）时，M4和M4 Pro的性能会有差别，尽管两者都配备了16核神经网络引擎，这主要是因为它们在CPU和GPU性能上有所不同：

1.CPU性能：M4和M4 Pro的CPU核数和性能有差异。M4 Pro会配备更多的高性能核心，而M4在核心数量或性能上有所限制。这意味着在需要多线程并行处理的任务（如深度学习推理时的数据预处理）上，M4 Pro的性能会比M4更强。

2.GPU性能：M4 Pro拥有更高的GPU核心数和更高的计算能力，在一些需要大量矩阵计算的AI模型推理过程中，M4 Pro的GPU可以提供更快的计算速度。因此，M4 Pro在执行大型深度学习模型的推理（如Llama 3.2）时通常会更快一些。

3.内存带宽：M4 Pro配备更大的内存带宽，这对运行大模型也很重要。带宽越大，数据在CPU、GPU和神经网络引擎之间传输的速度越快，从而减少模型加载和推理的延迟。

4.神经网络引擎的利用率：尽管M4和M4 Pro的神经网络引擎核数相同，但整体系统架构的优化和数据处理速度会影响它们的实际性能，因此，M4 Pro在执行复杂的AI推理任务时会更有优势。

所以总体来看，虽然两者的神经网络引擎相同，但M4 Pro的整体性能在执行大模型推理时会优于M4，尤其是在处理较复杂、需要较多资源的任务时，差异会更明显，也恰恰证明了我咬牙硬上M4 pro绝对不是乱花钱～。

到货之后，经过2天的折腾，常规生产力工具的初始化基本完成，终于可以开始验证使用ollama跑llama3.2的效果了。

我原本想的是，安装运行肯定非常简单，没什么必要新写一篇文章，直接弄好之后在我之前那篇关于ollama的文章里补个实际运行效果的动图即可。只不过，真开始弄的时候发现坑还真不少，最后想想，还是专门写一篇文章吧。

mac版ollama部署过程

安装ollama并下载运行llama3.2模型

我在之前的文章中提到过docker和源码部署两种方式的区别：

所以这次，我肯定是采用源码方式部署了，在ollama官方网站(https://ollama.com/download)下载macos的安装文件(我下载时是v0.4.1版本)：

其实就是一个直接运行的文件，双击就直接拷贝到应用程序文件夹里了，这里就懒得截图了。之后就使用以下命令下载llama3.2 3B模型并运行：

ollama pull llama3.2
ollama run llama3.2

运行成功之后已经可以在本地进行问答了：

注1：直接运行ollama run llama3.2命令时，ollama发现本地没有llama3.2的模型文件时也会自动进行pull，其实就是类似于docker run和docker pull。

注2：也可以下载其他模型，具体模型、版本、参数规模、大小以及命令参见下图：

注3：ollama中的模型默认都是采用的4bit量化(否则没法玩～)。

附加知识：模型的”量化”是一种通过降低模型权重和激活值的精度来减少模型计算和内存消耗的技术。传统上来说，深度学习模型的权重和激活值通常以 32 位浮点数（FP32）存储和计算，而量化则将这些数值的位数减少到 16 位、8 位、甚至 4 位或 2 位。量化后模型的内存需求和计算负载会大幅降低，使得原本难以运行的大模型能够在资源受限的硬件（如普通显卡或手机）上运行，同时，量化也会通过优化算法尽可能降低精度损失带来的影响。

使用”本机部署”的Lobechat进行调用

注1：这里所谓”本机部署”的Lobechat，是指部署ollama的设备、安装Lobechat的设备以及作为客户端使用浏览器进行访问的设备都是同一台设备，所以这里浏览器是使用的http://127.0.0.1:3210访问Lobechat。

注2：Lobechat的详细部署及设置参见我另外两篇文章：docker系列基于开源大语言模型UI框架:Lobechat的详细部署教程和家庭数据中心系列解锁Lobechat的全部潜能：从设置到实战的完整攻略，为了文章简洁，本文不详细展开，默认大家都是熟手。

使用如下docker run格式命令在部署ollama的设备上部署一个Lobechat本地版：

docker run --name lobe-chat  -d --restart=always \
  -p 3210:3210 \
  -e ACCESS_CODE=xxx \
  lobehub/lobe-chat

使用http://127.0.0.1:3210进行访问，在”语言模型”部分Ollama部分的”检查”是可以通过的：

由于我写文章时Lobechat还未更新Llama 3.2的模型ID，所以需要自建一个(这步不是必须的，如果在ollama里已经下载好模型并且在Lobechat里能够通过上图中的”获取模型列表”自动获取，也可以直接选择，只不过感觉这个自动获取有点”时灵时不灵”的感觉)：

配置新建的Llama 3.2 3B模型：

还是老规矩，让它生成一个简单的shell脚本来看看生成速度：

可以估计大概是5秒左右，而之前使用仅CPU方式的完成时间是1分41秒，这速度比之前的仅CPU模式可是快了不知道多少倍～。

注：本来想放个使用仅CPU时录屏转成GIF的动图，但是1分41秒的录屏视频转成GIF实在是太大了，就不放了，反正大概就是1秒钟2字左右的输出速度。

再看看llama3.2的知识库训练时间：

将近一年前，还行，毕竟是免费的，已经不错了。

到目前为止，对于一般要求不高的朋友而言，其实使用默认的http://127.0.0.1:3210地址通过Lobechat本地版来访问ollam已经足够了。

不过，这样也有非常大的限制：访问Lobechat时浏览器地址只有使用http://127.0.0.1:3210来访问时，Lobechat的语言模型ollama部分的检查才能通过；如果换个地址，比如我使用本机网卡真实IP地址，http://192.168.10.115:3210来访问Lobechat，检查就无法通过：

这是因为默认ollama为了安全而对跨域访问进行了限制，只允许来自”127.0.0.1″的调用，所以使用本机回环IP地址的方式访问本机的Lobechat时(http://127.0.0.1:3210)，对ollama的调用能通过检查；而使用本机物理网卡的IP地址访问本机的Lobechat时(http://192.168.10.130:3210)就不行。

这样导致的麻烦是：如果我的ollama想对局域网其他主机上部署的Lobechat提供服务默认是不行的。

对于一般的朋友而言这可能不算个问题，但是问题在于：我在家庭数据中心内部本来就部署了Lobechat的服务端数据库版，正常使用肯定会从那台设备上进行调用，所以对于我来说，跨域访问问题必须解决。

解决ollama跨域访问问题

其他部署模式跨域问题的解决方式

关于ollama允许跨域访问的问题，其实我在之前的文章中已经简单提到过了，只不过当时是用的docker方式部署做下测试，而且也没有实用价值，所以我没有深入研究，简单来说，docker部署方式只需要在部署时加上环境参数-e OLLAMA_ORIGINS="*"和-e OLLAMA_HOST="0.0.0.0"即可解决跨域问题。

而如果ollama是在linux下采用源码方式部署，则只需要按以下步骤即可允许跨域：

1、编辑ollama对应的service文件

sudo systemctl edit ollama.service

2、添加如下内容

[Service] 
Environment="OLLAMA_HOST=0.0.0.0"
Environment="OLLAMA_ORIGINS=*"

3、保存并退出

4、重载 systemd 并重启 Ollama

sudo systemctl daemon-reload
sudo systemctl restart ollama

windows上设置ollama的跨域和linux其实差不多，也简单，大概步骤如下：

macos上源码部署ollama时解决跨域问题

关键是mac上如何解决跨域的问题，其实官方到也说了，只需要运行以下命令，然后重启ollama应用程序即可：

launchctl setenv OLLAMA_ORIGINS "*"
launchctl setenv OLLAMA_HOST "0.0.0.0"

当然，如果只需要允许特定域名，则运行以下命令：

launchctl setenv Ollama_ORIGINS "google.com,apple.com"

不过，我实践后发现不生效，但是当我按以下步骤操作之后：

export OLLAMA_ORIGINS="*"
export OLLAMA_HOST=0.0.0.0
ollama serve

就可以通过检查了：

有点懵逼，让我先按顺序捋一捋。
1、这是在没有开启ollama app之前，理所当然的空白：

2、只开启ollama app，会有3个进程：

这个时候如果运行命令ollama run llama3.2，得到如下结果：

3、运行命令ollama serve之后：

再运行ollama run llama3.2，就可以成功：

而这时候的进程如下：

4、将所有ollama相关的进程杀掉重回空白了，只运行命令ollama serve：

再运行ollama run llama3.2，就可以成功：

所以，基本可以得出结论，现在Ollama的APP其实在第一次运行完成了安装任务之后就已经没什么作用了(之前一些版本似乎打开APP会自动运行命令ollama serve，那还是有意义的，但是我这里观察到的情况却不会自动运行)，后续运行本地大模型关键是ollama serve命令以及ollamm run这2个命令。

注：在使用ollama run命令运行本地大模型时，也会自动启动Ollama的APP，这时候，退出Ollama的APP，也会退出正在运行的大模型，所以要说之后Ollama的APP完全没用也不对～，至少可以当做大模型的快捷退出命令使用～。

附加知识：launchctl setenv 是 macOS 中用于设置系统级环境变量的命令。这些环境变量会对整个系统生效，包括所有用户进程，使用 launchctl setenv 设置的环境变量”理论上”可以被所有的应用程序和终端会话读取。

那为何之前的launchctl setenv OLLAMA_ORIGINS "*"和launchctl setenv OLLAMA_HOST "0.0.0.0"设置会失效呢？

在 macOS 上，使用 launchctl setenv 设置的环境变量不总是能被所有应用或命令行工具立即识别，这是因为在 macOS 的环境变量管理中，有一些特定的限制，特别是对于直接从终端运行的命令和服务：

1. 环境变量的范围

launchctl setenv 设置的环境变量只在launchd启动的进程中有效，但它不会直接传递给你从终端启动的命令。例如，使用 ollama serve 启动的 ollama 进程可能不会从 launchctl 获取环境变量，而是从当前终端的会话环境中获取。

所以如果之前启动ollama的app时会自动运行命令ollama serve，那使用 launchctl setenv的方式还有效，而现在变成启动ollama的app不会自动运行命令ollama serve，而只能自己去终端手动运行，那 launchctl setenv 的方式自然没用了(至少在我这里是)。

2. 终端会话的隔离

当在终端中运行export OLLAMA_ORIGINS="*"时，该变量被设置在当前终端会话的环境中。ollama 从终端启动时，可以直接获取到该环境变量，而不需要从 launchctl 中读取。因此，对于终端直接运行的命令，export 通常更有效。

注：使用launchctl setenv命令来设置ollama的环境变量也未必都不生效，还是要看不同的macos版本，所以大家可以先试下，如果可以成功，就不用折腾export命令了。

综上所述，如果只是临时启动ollama并且需要被跨域调用，那么只需要在一个终端里依次运行命令：

export OLLAMA_ORIGINS="*"
export OLLAMA_HOST=0.0.0.0
ollama serve
ollama run llama3.2

如果需要环境变量对所有终端和启动的进程生效，可以将export命令加入到你的 ~/.zshrc 或 ~/.bash_profile 配置文件中(取决于你使用的 shell 类型），这样每次打开新终端时该环境变量都会自动加载，则可以参考我的操作步骤。

macos默认使用的shell是zsh，当然，也可以通过如下命令确认：

echo $SHELL

比如我的mac输出如下：

确认使用的shell之后，就可以修改shell对应的的配置文件(zsh的配置文件是用户工作目录下的.zshrc)，可以使用大家自己熟悉的文本编辑工具，我习惯vim：

vim ~/.zshrc

然后在编辑界面添加如下内容之后保存退出：

export OLLAMA_ORIGINS="*"
export OLLAMA_HOST=0.0.0.0

最后重新加载配置：

source ~/.zshrc

之后每次打开终端运行ollama serve和ollama run命令且需要允许跨域时，就不需要重新运行export命令了。

另：如果需要开机自动运行大模型，只需要创建一个脚本，内容如下：

export OLLAMA_ORIGINS="*"
export OLLAMA_HOST=0.0.0.0
ollama serve
ollama run llama3.2

然后设置开机启动即可，不过一般mac也不关机，所以我觉得意义也不是很大。

虽然我觉得对于个人一般使用而言，llama3.2 3B(Llama 3.2的小型仅文本语言模型，有两种大小:1B 和 3B)应该足够了，不过，本着”有困难要上，没有困难创造困难也要上”的精神，我盯上了11月6号才出的llama 3.2 vision 11B模型：

高难度挑战

llama 3.2 vision模型介绍

Meta 发布的 Llama 3.2 Vision 是一款强大的开源多模态模型，兼具视觉理解和推理能力，可胜任视觉定位、文档问答以及图像-文本检索等任务。通过应用思维链（CoT）推理，这款模型在视觉推理方面表现出色。在架构上，Llama 3.2 Vision 其实由 Llama 3.1 LLM、视觉塔和图像适配器构成。

Llama 3.2 Vision 支持图像与文本的联合输入模式，也可以处理纯文本输入。在图像-文本模式下，模型接受英文输入；在纯文本模式下，它支持多语言处理，包括英语、德语、法语、意大利语、葡萄牙语、印地语、西班牙语和泰语。

实战测试

使用如下命令运行llama 3.2 vision模型并确保成功运行：

ollama run llama3.2-vision

然后在Lobechat里正确进行相关配置(文章前面介绍过，比如在Lobechat语言模型的ollama中新建模型并自定义模型配置)：

并在会话界面进行调用：

然后还是先试试先前测试llama3.2-3B时一样的要求，看看生成速度：

感觉和3B没啥区别啊，再来看看图片识别：

还不错。

注：中途我也在活动监视器关注了一下GPU的利用率，在收到指令到输出文字期间，GPU利用率在0-33%之间徘徊，由于利用率是动态的，不好截图，我就懒得去抓拍了，但是总的来说，负载还不算高(毕竟提出的问题也不难)，还大有潜力可挖。

总结

总的来说，ollama在m4pro上运行大模型的效率很让我满意，llama3.2-vision已经足够我使用了，以后有需要我再尝试下更高参数的模型，来看看m4pro的极限到底在哪里。

前言

mac版ollama部署过程

安装ollama并下载运行llama3.2模型

使用”本机部署”的Lobechat进行调用

解决ollama跨域访问问题

其他部署模式跨域问题的解决方式

macos上源码部署ollama时解决跨域问题

高难度挑战

llama 3.2 vision模型介绍

实战测试

总结

评论

发送评论编辑评论

前言

mac版ollama部署过程

安装ollama并下载运行llama3.2模型

使用”本机部署”的Lobechat进行调用

解决ollama跨域访问问题

其他部署模式跨域问题的解决方式

macos上源码部署ollama时解决跨域问题

高难度挑战

llama 3.2 vision模型介绍

实战测试

总结

评论

发送评论 编辑评论

推荐文章

发送评论编辑评论