自己電腦搭建AI大模型這事兒現(xiàn)在真沒那么玄乎。前兩年說起本地跑大模型大家第一反應(yīng)都是“得幾萬塊的顯卡吧”實(shí)際上現(xiàn)在一臺(tái)主流配置的游戲本甚至臺(tái)式機(jī)就能把通義千問Qwen和Llama3這類主流開源模型跑起來而且還能提供標(biāo)準(zhǔn)的接口給其他程序調(diào)用。我去年開始折騰這個(gè)踩了不少坑也總結(jié)了一套從零到一的完整路徑。這篇就詳細(xì)聊聊如何用自己的電腦搭一個(gè)AI大模型運(yùn)行環(huán)境支持通義千問、Llama3并且通過接口對外提供服務(wù)。1. 為什么要在本地電腦搭建AI大模型1.1 本地部署的核心需求與場景先說需求很多人覺得“我直接用網(wǎng)頁版不就行了嗎干嘛非得在自己電腦上折騰”。這個(gè)想法沒錯(cuò)但本地部署解決的是幾個(gè)很實(shí)際的痛點(diǎn)。一是數(shù)據(jù)隱私。我自己做項(xiàng)目的時(shí)候經(jīng)常要把一些代碼片段、文檔內(nèi)容交給AI分析而這些內(nèi)容直接粘貼到云端服務(wù)里心里總不踏實(shí)。本地部署之后所有推理都在自己電腦上完成數(shù)據(jù)不出機(jī)器這就解決了隱私顧慮。二是離線可用。出差坐高鐵、去信號(hào)差的地方或者公司內(nèi)網(wǎng)環(huán)境不允許訪問外網(wǎng)這時(shí)候本地模型就是唯一的選擇。我試過在完全沒有網(wǎng)絡(luò)的情況下依然可以對話、幫我寫代碼片段體驗(yàn)相當(dāng)不錯(cuò)。三是接口調(diào)用需求。個(gè)人開發(fā)、自動(dòng)化腳本、小工具集成都需要一個(gè)穩(wěn)定的大模型API端點(diǎn)。用云端服務(wù)要考慮配額、計(jì)費(fèi)、限流而本地跑一個(gè)模型接口隨便調(diào)不需要考慮費(fèi)用問題雖然速度可能不如云端但穩(wěn)定性自己可控。四是學(xué)習(xí)價(jià)值。把大模型本地跑起來你才會(huì)真正理解模型的顯存占用、推理延遲、量化概念、上下文窗口限制這些細(xì)節(jié)這些純用網(wǎng)頁版是感受不到的。1.2 硬件門檻與選型思路先給結(jié)論跑7B級(jí)別70億參數(shù)的模型最低8GB顯存能跑16GB顯存能比較舒服32GB顯存基本隨便玩。如果是70B級(jí)別的大模型基本得上48GB顯存的專業(yè)卡了這個(gè)不在消費(fèi)級(jí)的范圍內(nèi)。顯存是第一位的關(guān)鍵硬件。大模型推理的時(shí)候模型權(quán)重文件需要全部加載到顯存里顯存不夠就只能在內(nèi)存里跑速度會(huì)慢很多。以 Llama3 8B 為例fp16半精度權(quán)重大概16GBq4量化后縮到4.5GB左右。所以8GB顯存的顯卡跑q4量化版本的7B模型是可行的。內(nèi)存建議32GB起步尤其是當(dāng)你的顯卡顯存不夠、需要CPU參與計(jì)算的時(shí)候內(nèi)存就變成主要瓶頸。我自己早期的機(jī)器是16GB內(nèi)存 6GB顯存跑Qwen 7B遇到大段對話直接爆內(nèi)存后來升級(jí)到32GB才解決。CPU方面現(xiàn)代的多核處理器基本都能勝任因?yàn)橥评碛?jì)算主要在GPU完成CPU主要負(fù)責(zé)數(shù)據(jù)調(diào)度和預(yù)處理。硬盤建議留出50GB以上空間一個(gè)7B模型量化文件大概4-6GB不用的時(shí)候可以刪掉但多個(gè)模型累計(jì)占空間也挺可觀的。如果預(yù)算有限優(yōu)先升級(jí)顯卡顯存這是最核心的一條經(jīng)驗(yàn)。NVIDIA顯卡優(yōu)先因?yàn)镃UDA生態(tài)的支持還是最完善。AMD顯卡也能跑但踩坑概率大得多尤其是一些算子不同導(dǎo)致的速度異常。2. 環(huán)境搭建與依賴準(zhǔn)備2.1 操作系統(tǒng)與基礎(chǔ)環(huán)境選擇操作系統(tǒng)方面Windows 10/11、Ubuntu、macOS的M系列芯片版本我都實(shí)測過。Windows用起來最省心驅(qū)動(dòng)和管理工具方便大多數(shù)用戶在Windows上操作沒有學(xué)習(xí)成本。Ubuntu的優(yōu)勢是顯存管理更高效、后臺(tái)運(yùn)行更穩(wěn)定適合長期掛在后臺(tái)提供API服務(wù)的場景。macOS M1/M2芯片的MacBook其實(shí)也能跑統(tǒng)一內(nèi)存架構(gòu)讓嵌入式的推理效率不錯(cuò)但可選的模型參數(shù)規(guī)模更受限。Python環(huán)境需要一個(gè)干凈的最好用虛擬環(huán)境隔離。Windows用戶建議安裝Anaconda創(chuàng)建專用環(huán)境conda create -n llm python3.10 conda activate llm使用Anaconda的好處是包管理方便、不太會(huì)和系統(tǒng)Python沖突。GPU驅(qū)動(dòng)的安裝是重點(diǎn)以NVIDIA顯卡為例需要安裝顯卡驅(qū)動(dòng)和CUDA Toolkit?，F(xiàn)代版本的Pytorch已經(jīng)內(nèi)置了CUDA支持所以只要顯卡驅(qū)動(dòng)能正常識(shí)別就可以通過Pytorch的預(yù)編譯包來使用GPU。查看顯卡驅(qū)動(dòng)是否正常的命令是nvidia-smi正確輸出的結(jié)果是顯示GPU型號(hào)、驅(qū)動(dòng)版本和顯存信息。驅(qū)動(dòng)不正常會(huì)非常頭疼最常見的報(bào)錯(cuò)就是“CUDA error: no kernel image is available for execution on the device”。我踩過的坑是早期安裝了最新的Pytorch版本但顯卡驅(qū)動(dòng)版本太舊導(dǎo)致CUDA版本不匹配而報(bào)錯(cuò)。后來學(xué)會(huì)了看版本對應(yīng)關(guān)系Pytorch的每個(gè)版本對應(yīng)一個(gè)CUDA版本比如Pytorch 2.1對應(yīng)CUDA 11.8和12.1只需要把驅(qū)動(dòng)升級(jí)到最低支持的版本剩下的由Pytorch內(nèi)部處理即可。2.2 模型運(yùn)行框架選擇本地部署大模型現(xiàn)在主流的選擇是Ollama。它最大的優(yōu)勢是“開箱即用”安裝完通過一條命令就能下載指定模型并啟動(dòng)服務(wù)底層用的是llama.cpp作為推理后端專門針對CPU和Apple Silicon做了優(yōu)化也能調(diào)用NVIDIA顯卡的CUDA加速。為什么我不推薦直接部署原生的transformersPyTorch環(huán)境因?yàn)槟切枰约禾幚砟Ｐ拖螺d、格式轉(zhuǎn)換、量化、推理腳本、API網(wǎng)關(guān)一系列事情對于只想跑通流程、快速上手的人來說復(fù)雜度太高。Ollama做了一個(gè)很好的封裝把模型管理、推理、API服務(wù)整合在一起大大降低了門檻。但Ollama的缺點(diǎn)是自定義能力有限如果需要自己寫推理邏輯、定制采樣策略、接入特殊的后處理邏輯還是得回到原生部署。我個(gè)人的策略是如果只是想體驗(yàn)、測試用Ollama如果要做研究、開發(fā)完整應(yīng)用建議兩種方案都了解。Ollama的安裝非常簡單Windows版本直接下載安裝包即可Linux用一條命令curl -fsSL https://ollama.com/install.sh | sh安裝完成后命令行輸入ollama --version可以驗(yàn)證安裝是否成功。3. 模型下載、部署與運(yùn)行3.1 通義千問Qwen系列部署實(shí)操通義千問是阿里開源的大模型系列目前有多個(gè)版本參數(shù)規(guī)模從0.5B到72B不等。在我的實(shí)際使用中Qwen系列的中文理解能力是最好的之一代碼生成和邏輯推理也比較靠譜搭配自己的業(yè)務(wù)會(huì)很順手。我在本地部署的直接命令如下ollama pull qwen2.5:7b這個(gè)命令會(huì)從模型庫下載Qwen2.5 7B模型的量化版本默認(rèn)是q4_0量化大小約4.7GB。下載速度取決于網(wǎng)絡(luò)環(huán)境我這里實(shí)際測速大概是5-10MB/s大約需要10-20分鐘。下載完成后運(yùn)行ollama run qwen2.5:7b看到如下輸出后就可以直接對話了 你好請介紹一下你自己 你好我是通義千問一個(gè)由阿里云開發(fā)的人工智能助手...退出交互模式按/bye如果想看清提供了哪些參數(shù)輸入/show即可。如果需要更大的模型可以拉取qwen2.5:14b大約9GB顯存16GB以上的機(jī)器建議直接上14B效果提升非常明顯。14B和7B我覺得差距最直觀的體現(xiàn)就是長文本推理的連貫性14B模型回答長篇問題不太容易跑偏。3.2 Llama3系列部署實(shí)操Llama3是Meta開源的模型系列8B版本是消費(fèi)級(jí)硬件能跑得動(dòng)的最大性價(jià)比選擇。英文能力、代碼能力、數(shù)學(xué)推理表現(xiàn)都非常出色中文能力比Qwen稍弱但已經(jīng)足夠日常使用了。Llama3 8B 的下載命令ollama pull llama3.1這里llama3.1指的是8B版本的默認(rèn)量化下載完成后直接ollama run llama3.1即可進(jìn)入對話。Llama3系列從發(fā)布開始就一直迭代8B版本已經(jīng)相當(dāng)成熟。我的經(jīng)驗(yàn)是中文業(yè)務(wù)場景優(yōu)先選Qwen英文、代碼、推理優(yōu)先選Llama3兩個(gè)模型可以同時(shí)留在本地用完隨時(shí)切換非常方便。3.3 模型存儲(chǔ)管理與自定義模型導(dǎo)入模型文件默認(rèn)存儲(chǔ)在用戶目錄下的.ollama/models目錄中。如果C盤空間緊張可以通過設(shè)置環(huán)境變量OLLAMA_MODELS來改變模型存儲(chǔ)路徑。我個(gè)人的習(xí)慣是放到專門的數(shù)據(jù)盤里setx OLLAMA_MODELS D:\ollama_models # Windows export OLLAMA_MODELS/data/ollama_models # Linux修改后重啟Ollama服務(wù)生效。如果從Hugging Face下載了GGUF格式的模型文件也可以導(dǎo)入到Ollama里運(yùn)行。在模型目錄創(chuàng)建一個(gè)Modelfile文件FROM ./my-model.gguf # 系統(tǒng)提示詞 SYSTEM 你是一個(gè)有幫助的AI助手 # 設(shè)置溫度參數(shù) PARAMETER temperature 0.7 # 設(shè)置上下文窗口大小 PARAMETER num_ctx 4096然后執(zhí)行ollama create mymodel -f Modelfile ollama run mymodel這里的上下文窗口大小設(shè)置尤其重要。默認(rèn)的Ollama上下文窗口只有2048 token對于長對話場景遠(yuǎn)遠(yuǎn)不夠。num_ctx參數(shù)設(shè)置得越大模型能“記住”的對話內(nèi)容就越多但會(huì)占用更多的顯存。我實(shí)測下來7B模型在16GB顯存下設(shè)置4096最穩(wěn)妥設(shè)置到8192雖然能跑但生成速度會(huì)明顯下降。3.4 推理參數(shù)調(diào)節(jié)的實(shí)用經(jīng)驗(yàn)運(yùn)行模型時(shí)的溫度temperature和top_p是影響回答質(zhì)量的關(guān)鍵參數(shù)。溫度控制輸出的隨機(jī)性值越高回答越發(fā)散值越低回答越發(fā)確定。我的調(diào)試經(jīng)驗(yàn)是需要嚴(yán)謹(jǐn)?shù)氖聦?shí)回答比如代碼、數(shù)據(jù)解析temperature設(shè)為0.1-0.3一般對話temperature設(shè)為0.5-0.7創(chuàng)意寫作temperature設(shè)為0.8-1.0top_p是核采樣參數(shù)一般固定為0.9即可主要影響輸出的多樣性。代碼生成任務(wù)里把top_p調(diào)低到0.8能減少一些不穩(wěn)定的輸出概率。另外還可以設(shè)置repeat_penalty重復(fù)懲罰在長對話里能有效避免模型出現(xiàn)復(fù)讀機(jī)的現(xiàn)象。默認(rèn)值1.1基本夠用如果發(fā)現(xiàn)模型開始重復(fù)說過的話可以提高到1.2-1.3。這些參數(shù)在交互模式里可以直接調(diào)整 /set parameter temperature 0.6 /set parameter top_p 0.94. 接口調(diào)用與對外服務(wù)4.1 Ollama原生API調(diào)用Ollama自帶一個(gè)HTTP服務(wù)端口默認(rèn)11434支持完整的API接口。啟動(dòng)服務(wù)的方式是ollama serve它會(huì)在本地監(jiān)聽端口。最簡單的請求方式是調(diào)用/api/generate接口生成一次性的響應(yīng)curl -X POST http://localhost:11434/api/generate -d { model: qwen2.5:7b, prompt: 講一個(gè)關(guān)于程序員的小笑話, stream: false }返回結(jié)果中response字段就是模型生成的文本。stream參數(shù)設(shè)置為false會(huì)等待完整結(jié)果返回設(shè)置true則會(huì)逐字地通過SSE模式流式返回對長文本生成體驗(yàn)更好用戶感知到的首字延遲更低。聊天接口/api/chat支持多輪對話和歷史記錄維護(hù)curl -X POST http://localhost:11434/api/chat -d { model: llama3.1, messages: [ {role: system, content: 你是一個(gè)Python專家}, {role: user, content: 編寫一個(gè)快速排序函數(shù)} ], stream: false }這里的messages數(shù)組會(huì)作為對話上下文傳入實(shí)現(xiàn)多輪對話能力而無需額外處理歷史記錄拼接。4.2 OpenAI兼容接口對接這個(gè)接口兼容性的意義在于大量現(xiàn)有工具和代碼都是為OpenAI API設(shè)計(jì)的如果能直接復(fù)用這些生態(tài)就能節(jié)省很多對接成本。目前Ollama支持OpenAI格式的接口在本地啟動(dòng)服務(wù)后默認(rèn)也會(huì)同時(shí)提供/v1/chat/completions端點(diǎn)。像一些開源應(yīng)用比如ChatGPT-Next-Web、Lobe Chat等只要把接口配置改為http://127.0.0.1:11434/v1就能直接接入本地的Qwen和Llama3。用Python調(diào)用OpenAI兼容接口的示例from openai import OpenAI client OpenAI( api_keyollama, base_urlhttp://127.0.0.1:11434/v1 ) chat_completion client.chat.completions.create( modelqwen2.5:7b, messages[ {role: system, content: 用中文回答保持簡潔}, {role: user, content: 解釋一下什么是RAG} ], temperature0.7, max_tokens1024 ) print(chat_completion.choices[0].message.content)這里有一個(gè)注意點(diǎn)api_key字段是必須的參數(shù)Ollama本地服務(wù)不校驗(yàn)它的內(nèi)容隨意填寫一個(gè)值即可。如果不想額外依賴openai庫直接用requests庫調(diào)用也可以import requests import json url http://127.0.0.1:11434/v1/chat/completions payload { model: qwen2.5:7b, messages: [ {role: user, content: 寫一首關(guān)于秋天的詩} ], temperature: 0.8, max_tokens: 512 } headers {Content-Type: application/json} response requests.post(url, jsonpayload, headersheaders) result response.json() print(result[choices][0][message][content])4.3 接口性能優(yōu)化與并發(fā)處理本地API的并發(fā)處理能力是有限度的。Ollama在GPU顯存充足的情況下能處理少量并發(fā)請求但如果多個(gè)請求同時(shí)到來推理任務(wù)會(huì)排隊(duì)執(zhí)行導(dǎo)致請求延遲增加。我自己壓測過7B模型在16GB顯卡上能穩(wěn)定處理2-3個(gè)并發(fā)請求超過5個(gè)并發(fā)會(huì)導(dǎo)致每個(gè)請求的響應(yīng)時(shí)間明顯拉長。如果業(yè)務(wù)需要更高的并發(fā)有兩種優(yōu)化思路。第一種是在Ollama前面加一個(gè)消息隊(duì)列或負(fù)載均衡將請求排隊(duì)處理。最簡單的實(shí)現(xiàn)是用fastapi寫一個(gè)中間層把請求放入隊(duì)列依次調(diào)用Ollama的API。第二種思路是同時(shí)運(yùn)行多個(gè)模型副本實(shí)例比如兩個(gè)qwen2.5:7b實(shí)例每個(gè)實(shí)例獨(dú)立占用一塊GPU然后用負(fù)載均衡分配請求。另外Ollama在API調(diào)用時(shí)支持“預(yù)加載模型”功能在請求中設(shè)置keep_alive參數(shù)控制模型在內(nèi)存中停留的時(shí)間默認(rèn)是5分鐘。如果API調(diào)用頻繁建議調(diào)大這個(gè)值curl -X POST http://localhost:11434/api/generate -d { model: qwen2.5:7b, prompt: 你好, keep_alive: 30m }將keep_alive設(shè)為30分鐘可以避免短時(shí)間內(nèi)多次加載模型帶來的額外延時(shí)。5. 實(shí)操過程中遇到的高頻問題與排查思路5.1 顯存不足OOM與推理速度慢顯存不足是最常見的問題表現(xiàn)是運(yùn)行中報(bào)錯(cuò)CUDA out of memory。解決思路有幾種換更小的模型從7B降到4B甚至3B。但目前4B級(jí)別的模型質(zhì)量比7B差不少如果機(jī)器顯存真的低于6GB這個(gè)選擇比較無奈。降低量化級(jí)別。Ollama默認(rèn)使用q4_0量化如果顯存吃緊可以拉取專門的q2_k量化版本體積會(huì)更小但精度損失也比較明顯。我實(shí)測過q2_k版本在代碼任務(wù)上錯(cuò)誤率明顯提升除非迫不得已不建議用。減小上下文窗口。默認(rèn)的2048其實(shí)不算大如果設(shè)置了更高的num_ctx會(huì)占用額外的顯存。把上下文窗口從8192降到4096大概能省出2-3GB顯存。推理速度慢的問題在多發(fā)生在CPU推理場景。在純CPU上跑7B模型生成速度大概只有2-4 token/秒一個(gè)字大概要等0.5秒體驗(yàn)很差。優(yōu)化方式依然是優(yōu)先讓推理走GPU確認(rèn)Ollama確實(shí)調(diào)用到了GPU可以用以下命令ollama ps輸出中如果顯示PROCESSOR 100% GPU就說明GPU已經(jīng)正常參與推理。如果顯示有CPU的百分比說明模型部分加載在CPU上效果會(huì)打折扣這時(shí)候可以考慮加內(nèi)存或換一個(gè)小一點(diǎn)的模型。5.2 上下文不夠用與知識(shí)缺失上下文窗口限制是所有本地模型的通病。7B模型通常上下文限制在8K-32K但實(shí)際運(yùn)行中為了性能多半會(huì)限制在4K-8K。當(dāng)對話變長或輸入文本超長時(shí)模型只能記住最后一段內(nèi)容前面的信息會(huì)丟失。解決辦法是編寫應(yīng)用時(shí)控制歷史消息條數(shù)只保留最近幾輪用向量化檢索RAG的方式把外部知識(shí)切片后檢索而不是一股腦喂給模型合理設(shè)置num_ctx參數(shù)但要從顯存預(yù)算出發(fā)。還有一個(gè)“幻覺”問題也值得注意。模型在回答超出它知識(shí)范圍的問題時(shí)會(huì)一本正經(jīng)地編造內(nèi)容這個(gè)在本地部署場景尤其明顯。我習(xí)慣的做法是讓模型在不確定時(shí)明確說“不確定”并且限定它只用提供的上下文回答。在系統(tǒng)提示詞里加一句只依據(jù)提供的文本進(jìn)行回答如果文本中不包含相關(guān)信息直接回答“無法回答”對減少幻覺確實(shí)有效。5.3 API調(diào)用常見報(bào)錯(cuò)與解決速查我整理了實(shí)踐中遇到的最多的幾種報(bào)錯(cuò)情況報(bào)錯(cuò)現(xiàn)象可能原因解決方法connect to 127.0.0.1:11434 failedOllama服務(wù)沒有啟動(dòng)或已崩潰檢查進(jìn)程重新運(yùn)行ollama servemodel not found模型名稱錯(cuò)誤或還沒拉取完成運(yùn)行ollama list查看已安裝模型確認(rèn)名字拼寫CUDA out of memory顯存不足換小模型、調(diào)低量化級(jí)別、縮小上下文窗口14B model requires more memory內(nèi)存不足升級(jí)內(nèi)存或更換更小的模型invalid character o looking for beginning of value向API發(fā)送了無效的JSON檢查請求體是否為合法的JSON格式connection reset請求太大或超時(shí)縮短輸入文本調(diào)大客戶端超時(shí)時(shí)間另外有一個(gè)我踩了好幾次的坑在Windows PowerShell下使用curl命令時(shí)雙引號(hào)和單引號(hào)的處理和Linux bash不同經(jīng)常導(dǎo)致JSON數(shù)據(jù)無法正確傳參。建議直接用--data-raw參數(shù)并注意引號(hào)轉(zhuǎn)義或者干脆用Python/Postman來測試API省去很多煩惱。5.4 優(yōu)化生成質(zhì)量的實(shí)際調(diào)整心得模型同一個(gè)問題回答得時(shí)好時(shí)壞這種情況很常見。影響回答質(zhì)量的因素在我實(shí)操下來排前三的分別是系統(tǒng)提示詞、溫度參數(shù)、上下文是否包含足夠信息。系統(tǒng)提示詞要具體、有明確格式要求。例如你是一個(gè)中文技術(shù)博客寫作助理。用戶會(huì)給你一個(gè)技術(shù)主題你需要輸出 1. 中文標(biāo)題 2. 核心技術(shù)要點(diǎn)至少3條 3. 實(shí)操步驟分步驟列出 4. 注意事項(xiàng)至少2條 用通俗易懂的語言結(jié)構(gòu)化輸出。有了這個(gè)提示詞輸出質(zhì)量比直接甩一句“幫我寫博客”穩(wěn)定得多。溫度參數(shù)代碼和事實(shí)類任務(wù)調(diào)低到0.2-0.3寫作翻譯類可以調(diào)制0.7。需要不偏離用戶意圖的內(nèi)容時(shí)temperature0.2是最穩(wěn)的。關(guān)于max_tokens也很關(guān)鍵。如果生成被打斷出現(xiàn)明顯的不完整句子很可能是因?yàn)樯傻膖oken數(shù)達(dá)到了上限。根據(jù)內(nèi)容長度需求設(shè)置合理的max_tokens值長文寫作至少設(shè)置1024以上。7B模型的單次生成上限取決于上下文窗口并不是設(shè)置得越大越好。6. 實(shí)際使用經(jīng)驗(yàn)與展望我已經(jīng)把通義千問和Llama3部署在本機(jī)大半年了平時(shí)主要用它做代碼輔助、文本處理、接口測試數(shù)據(jù)的生成。最常用的是Qwen 7B處理中文文檔和自動(dòng)寫郵件Llama3.1處理英文閱讀總結(jié)和代碼補(bǔ)全兩者各有擅長。如果讓我重新走一遍部署流程我會(huì)告訴自己不要一開始就折騰復(fù)雜的環(huán)境和最全的模型先用Ollama跑通一個(gè)最小流程拉取7B模型、對話、調(diào)接口再去折騰自定義參數(shù)、換更大的模型、做并發(fā)優(yōu)化。這個(gè)循序漸進(jìn)的方式省去了很多不必要的彎路。接下來這個(gè)方向還可以怎么擴(kuò)展一是嘗試多模態(tài)模型也就是能看圖、識(shí)圖的模型比如LLaVA系列本地部署也很方便。二是把本地的多個(gè)模型統(tǒng)一接入口罩成一個(gè)服務(wù)根據(jù)不同的任務(wù)自動(dòng)路由到不同的模型。三是研究知識(shí)庫RAG方案為本地模型擴(kuò)展更強(qiáng)的專業(yè)能力。這些方向我后續(xù)也會(huì)繼續(xù)輸出實(shí)操文章。自己在電腦上搭一套AI大模型這件事本身已經(jīng)不難難的是把它用得順手、用出價(jià)值。希望這篇文章能幫你邁過最初的環(huán)境搭建這道坎體會(huì)到本地大模型帶來的自由度和掌控感。