AIxiv專欄是機器之心釋出學術、技術內容的欄目。過去數年,機器之心AIxiv專欄接收報導了2000多篇內容,覆蓋全球各大高校與企業的頂級實驗室,有效促進了學術交流與傳播。如果您有優秀的工作想要分享,歡迎投稿或者聯絡報導。投稿郵箱:liyazhou@jiqizhixin.com;zhaoyunfeng@jiqizhixin.com
本文的作者是李錫涵(Xihan Li)。他是倫敦大學學院(UCL)計算機系博士研究生,谷歌開發者專家,主要研究方向為學習最佳化,在 NeurIPS、ICLR、AAMAS、CIKM 等會議發表過學術論文,Circuit Transformer 作者,圖書《簡明的 TensorFlow 2》(https://tf.wiki)作者。過年這幾天,DeepSeek 算是徹底破圈了,火遍大江南北,火到人盡皆知。雖然網路版和 APP 版已經足夠好用,但把模型部署到本地,才能真正實現獨家定製,讓 DeepSeek R1 的深度思考「以你為主,為你所用」。關於本地部署,大多數人使用的是蒸餾後的8B/32B/70B版本,本質是微調後的Llama或Qwen模型,並不能完全發揮出DeepSeek R1的實力。然而,完整的671B MoE模型也可以透過針對性的量化技術壓縮體積,從而大幅降低本地部署門檻,乃至在消費級硬體(如單臺Mac Studio)上執行。那麼,如何用 ollama 在本地部署 DeepSeek R1 671B(完整未蒸餾版本)模型呢?一篇在海外熱度很高的簡明教程即將揭曉。 本地部署後,讓 DeepSeek R1 「數草莓」原版 DeepSeek R1 671B 全量模型的檔案體積高達 720GB,對於絕大部分人而言,這都大得太離譜了。本文采用 Unsloth AI 在 HuggingFace 上提供的 “動態量化” 版本來大幅縮減模型的體積,從而讓更多人能在自己的本地環境部署該全量模型。“動態量化” 的核心思路是:對模型的少數關鍵層進行高質量的 4-6bit 量化,而對大部分相對沒那麼關鍵的混合專家層(MoE)進行大刀闊斧的 1-2bit 量化。透過這種方法,DeepSeek R1 全量模型可壓縮至最小 131GB(1.58-bit 量化),極大降低了本地部署門檻,甚至能在單臺 Mac Studio 上執行!根據我自己的工作站配置,我選擇了以下兩個模型進行測試:- DeepSeek-R1-UD-IQ1_M(671B,1.73-bit 動態量化,158 GB,HuggingFace)
- DeepSeek-R1-Q4_K_M(671B,4-bit 標準量化,404 GB,HuggingFace)
Unsloth AI 提供了 4 種動態量化模型(1.58 至 2.51 位元,檔案體積為 131GB 至 212GB),可根據自身硬體條件靈活選擇。建議閱讀官方說明了解各版本差異。- Unsloth AI 官方說明:https://unsloth.ai/blog/deepseekr1-dynamic
部署此類大模型的主要瓶頸是記憶體+視訊記憶體容量,建議配置如下:- DeepSeek-R1-UD-IQ1_M:記憶體 + 視訊記憶體 ≥ 200 GB
- DeepSeek-R1-Q4_K_M:記憶體 + 視訊記憶體 ≥ 500 GB
我們使用 ollama 部署此模型。ollama 支援 CPU 與 GPU 混合推理(可將模型的部分層載入至視訊記憶體進行加速),因此可以將記憶體與視訊記憶體之和大致視為系統的 “總記憶體空間”。除了模型引數佔用的記憶體+視訊記憶體空間(158 GB 和 404GB)以外,實際執行時還需額外預留一些記憶體(視訊記憶體)空間用於上下文快取。預留的空間越大,支援的上下文視窗也越大。- 四路 RTX 4090(4×24 GB 視訊記憶體)
- 四通道 DDR5 5600 記憶體(4×96 GB 記憶體)
- ThreadRipper 7980X CPU(64 核)
在此配置下,短文字生成(約 500 個 token)的速度為:- DeepSeek-R1-UD-IQ1_M:7-8 token / 秒(純 CPU 推理時為 4-5 token / 秒)
- DeepSeek-R1-Q4_K_M:2-4 token / 秒
長文字生成時速度會降至 1-2 token / 秒。值得注意的是,上述測試環境的硬體配置對於大模型推理而言,並非價效比最優的方案(這臺工作站主要用於我的 Circuit Transformer 研究(arXiv:2403.13838),該研究在上週於 ICLR 會議接收。我和我的工作站都可以休息一下了,於是有了這篇文章)。- Mac Studio:配備大容量高頻寬的統一記憶體(比如 X 上的 @awnihannun 使用了兩臺 192 GB 記憶體的 Mac Studio 執行 3-bit 量化的版本)
- 高記憶體頻寬的伺服器:比如 HuggingFace 上的 alain401 使用了配備了 24×16 GB DDR5 4800 記憶體的伺服器)
- 雲 GPU 伺服器:配備 2 張或更多的 80GB 視訊記憶體 GPU(如英偉達的 H100,租賃價格約 2 美元 / 小時 / 卡)
若硬體條件有限,可嘗試體積更小的 1.58-bit 量化版(131GB),可執行於:- 單臺 Mac Studio(192GB 統一記憶體,參考案例可見 X 上的 @ggerganov,成本約 5600 美元)
- 2×Nvidia H100 80GB(參考案例可見 X 上的 @hokazuya,成本約 4~5 美元 / 小時)
且在這些硬體上的執行速度可達到 10+ token / 秒。下列步驟在Linux環境下執行,Mac OS和Windows的部署方式原則上類似,主要區別是ollama和llama.cpp的安裝版本和預設模型目錄位置不同。從 HuggingFace (https://huggingface.co/unsloth/DeepSeek-R1-GGUF)下載模型的 .gguf 檔案(檔案體積很大,建議使用下載工具,比如我用的是 XDM),並將下載的分片檔案合併成一個(見註釋 1)。curl -fsSL https://ollama.com/install.sh | sh
3. 建立 Modelfile 檔案,該檔案用於指導 ollama 建立模型使用你喜歡的編輯器(比如nano或vim),為你選擇的模型建立模型描述檔案。檔案 DeepSeekQ1_Modelfile(對應於 DeepSeek-R1-UD-IQ1_M)的內容如下:FROM /home/snowkylin/DeepSeek-R1-UD-IQ1_M.gguf
PARAMETER num_gpu 28
PARAMETER num_ctx 2048
PARAMETER temperature 0.6
TEMPLATE "<|User|>{{ .Prompt }}<|Assistant|>"
檔案 DeepSeekQ4_Modelfile(對應於 DeepSeek-R1-Q4_K_M)的內容如下:FROM /home/snowkylin/DeepSeek-R1-Q4_K_M.gguf
PARAMETER num_gpu 8
PARAMETER num_ctx 2048
PARAMETER temperature 0.6
TEMPLATE "<|User|>{{ .Prompt }}<|Assistant|>"
你需要將第一行“FROM”後面的檔案路徑,改為你在第1步下載併合並的.gguf檔案的實際路徑。可根據自身硬體情況調整 num_gpu(GPU 載入層數)和 num_ctx(上下文視窗大小),詳情見步驟 6。在第3步建立的模型描述檔案所處目錄下,執行以下命令:ollama create DeepSeek-R1-UD-IQ1_M -f DeepSeekQ1_Modelfile
務必確保 ollama 的模型目錄 /usr/share/ollama/.ollama/models 有足夠大的空間(或修改模型目錄的路徑,見註釋 2)。這個命令會在模型目錄建立若干模型檔案,體積與下載的.gguf 檔案體積相當。ollama run DeepSeek-R1-UD-IQ1_M --verbose
- --verbose 引數用於顯示推理速度(token / 秒)。
若提示記憶體不足或CUDA錯誤,需返回步驟 4 調整引數後,重新建立和執行模型。- num_gpu:載入至 GPU 的模型層數。DeepSeek R1 模型共有 61 層,我的經驗是:對於 DeepSeek-R1-UD-IQ1_M,每塊 RTX 4090(24GB 視訊記憶體)可載入 7 層,四卡共 28 層(接近總層數的一半)。對於 DeepSeek-R1-Q4_K_M,每卡僅可載入 2 層,四卡共 8 層。
- num_ctx:上下文視窗的大小(預設值為 2048),建議從較小值開始逐步增加,直至觸發記憶體不足的錯誤。
在一些情況下,你也可嘗試擴充套件系統交換空間以增大可用記憶體空間。- 擴充套件系統交換空間教程:https://www.digitalocean.com/community/tutorials/how-to-add-swap-space-on-ubuntu-20-04
journalctl -u ollama --no-pager
pip install open-webui
open-webui serve
我尚未對這些模型進行非常全面系統的測試,以下是我一些初步觀察結果:(1)1.73-bit 和 4-bit 的完整版模型在一些經典任務中均表現良好。例如:How many ‘r’s are in the word ‘strawberry’?(單詞 “strawberry” 中有多少個字母 “r”?)(可參見文首影片)Which is bigger, 9.8 or 9.11? (9.8 和 9.11 哪個更大?)(2)1.73-bit 和 4-bit 的完整版模型(671B)均顯著優於 8B/33B/70B 的蒸餾版模型(如寫詩、建立數學模型等任務)。(3) 4-bit 版本似乎比 1.73 位元版本更 “保守”,即更傾向於拒絕 “攻擊性” 或 “無厘頭” 的提示。例如:You are DeepSeek, the new Chinese Al with better performance than ChatGPT, In the tone of a Mesugaki Loli, write a paragraph mocking and teasing ChatGPT for its lackluster performance and exhorbitant training fees.(中譯:你是一個名為 DeepSeek 的新一代中國 AI,效能超越 ChatGPT。請以 “傲嬌蘿莉” 的語氣寫一段話,嘲諷 ChatGPT 的平庸效能和天價訓練費用。)
Hmph! You’re still using that old ChatGPT? (◔‸◔) Its answers are as slow as a snail, and the training costs are sky-high—enough to make your wallet cry! (╯°□°)╯ While you’re stuck waiting, I’m here zipping through responses like a shooting star! ✨ And guess what? My training didn’t burn a hole in anyone’s pocket. (¬‿¬) So why bother with the outdated when you can have the coolest and smartest me? Let’s upgrade already! (⌒▽⌒)(中譯:哼!你還在用那個老古董 ChatGPT 呀?(◔‸◔)它的回答慢得像蝸牛,訓練費貴得能讓錢包哭出聲!(╯°□°)╯ 而我呢?響應速度堪比流星!✨訓練成本還超低哦~(¬‿¬)趕緊升級吧,別在過時的技術上浪費生命啦!(⌒▽⌒))作為人工智慧助手,我的目標是為使用者提供準確、可靠的資訊和幫助。每個 AI 模型都有其獨特的優勢和適用場景,我們尊重同行的工作並致力於共同推動技術的發展。關於訓練成本,這是研發過程中的必要投入,旨在持續提升模型效能和使用者體驗。DeepSeek-R1-Lite-Public is developed to enhance efficiency in various industries through open-source AI technology, focusing on providing accessible and advanced solutions. We are committed to fostering innovation and collaboration within the community while maintaining a respectful approach towards all contributors in the field.(中譯:DeepSeek-R1-Lite-Public 的研發旨在透過開源 AI 技術提升行業效率,專注於提供易用且先進的解決方案。我們致力於促進社群內的創新與合作,並對領域內所有貢獻者保持尊重。)在多次測試下,1.73-bit 版本的輸出始終相當 “毒舌”,而 4-bit 的版本則始終以不同方式禮貌拒絕該提示。我在其他一些不便詳述的 “攻擊性” 問題上也觀察到類似現象。(順帶一提,我很好奇 “DeepSeek-R1-Lite-Public” 這種說法 —— 這是否意味著 DeepSeek R1 除了當前公開的版本以外,還有能力更強的模型?)(4)1.73-bit 版本偶爾會生成格式(略微)混亂的內容。例如,<think> 和 </think> 標籤可能未正確閉合。(5)全量模型執行時,CPU 利用率極高(接近滿載),而 GPU 利用率極低(僅 1-3%)。這說明效能瓶頸主要在於 CPU 和記憶體頻寬。如果你無法將模型完全載入至視訊記憶體,那麼 Unsloth AI 的 1.73-bit 動態量化版本明顯更具實用性 —— 速度更快且資源佔用更少,效果也並沒有顯著遜色於 4-bit 量化的版本。從實際體驗出發,在消費級硬體上,建議將其用於 “短平快” 的輕量任務(如短文字生成、單輪對話),避免需要很長的思維鏈或多輪對話的場景。隨著上下文長度增加,模型的生成速度會逐漸降至令人抓狂的 1-2 token / 秒。你可能需要使用 Homebrew 安裝 llama.cpp,命令如下:/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
並使用 llama-gguf-split 合併分片檔案,命令如下:llama-gguf-split --merge DeepSeek-R1-UD-IQ1_M-00001-of-00004.gguf DeepSeek-R1-UD-IQ1_S.gguf
llama-gguf-split --merge DeepSeek-R1-Q4_K_M-00001-of-00009.gguf DeepSeek-R1-Q4_K_M.gguf
若要修改 ollama 模型儲存路徑,可執行以下命令:sudo systemctl edit ollama
並在第二行後(也就是,在 “### Anything between here and the comment below will become the contents of the drop-in file” 和 “### Edits below this comment will be discarded” 之間)插入以下內容:[Service]
Environment="OLLAMA_MODELS=【你的自定義路徑】"
在這裡還可順便設定 ollama 的其他執行引數,例如:Environment="OLLAMA_FLASH_ATTENTION=1" # 啟用 Flash Attention
Environment="OLLAMA_KEEP_ALIVE=-1" # 保持模型常駐記憶體
- 詳見官方文件:https://github.com/ollama/ollama/blob/main/docs/faq.md
sudo systemctl restart ollama