前言

在之前的文章中，我已經寫過如何基於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的極限到底在哪裡。