先說實(shí)話我這臺電腦沒有獨(dú)立顯卡只有一塊不算新的 Intel 核顯。前陣子被“本地大模型”這幾個(gè)字撓得心癢想在自己機(jī)器上部署一套能離線對話、能接 API 的模型結(jié)果照著網(wǎng)上大量“默認(rèn)你有 N 卡”的教程一路硬踩翻車翻到懷疑人生。后來把 Ollama、llama.cpp、OpenVINO 這些方案挨個(gè)試了一遍總算把本地大模型部署這件事跑通了。這篇文章就把這段“Intel 核顯部署踩坑記”完整復(fù)盤一下。我不打算只講“我成功了”更想把無獨(dú)顯機(jī)器做本地大模型部署時(shí)會遇到的硬件瓶頸、工具選型、量化參數(shù)、上下文管理這些坑講清楚。適合誰看和我一樣手里只有核顯本、想低成本體驗(yàn)本地部署大模型或者想讓老電腦繼續(xù)發(fā)光的開發(fā)者這篇文章給你一條能直接落地的路徑。1. Intel核顯跑本地大模型的硬件畫像顯存與帶寬認(rèn)知1.1 核顯的性能瓶頸不在算力而在“省著用內(nèi)存”很多人第一次聽說核顯能跑大模型第一反應(yīng)是“核顯不是性能很弱嗎”其實(shí)這個(gè)印象只對了一半。以當(dāng)前 Intel 核顯的實(shí)際執(zhí)行單元規(guī)模來看做圖像渲染或視頻編碼確實(shí)吃力但它已經(jīng)把不少 AI 加速指令集和專用單元集成進(jìn)去了。真正讓核顯在本地大模型部署中受限的不是 GPU 計(jì)算單元有多弱而是它沒有獨(dú)立顯存。獨(dú)顯跑大模型模型權(quán)重會放進(jìn)顯存顯存帶寬動輒幾百 GB/s數(shù)據(jù)搬運(yùn)速度快推理就快。核顯不一樣它需要從系統(tǒng)內(nèi)存里劃一塊出來當(dāng)“共享顯存”也就是把 DDR4 或 DDR5 內(nèi)存同時(shí)留給 CPU 和 GPU 用。系統(tǒng)內(nèi)存的帶寬通常只有幾十 GB/s低一些的可能是 30~40GB/s好一點(diǎn)的也就 80~90GB/s 級別和獨(dú)顯的顯存帶寬差了一個(gè)數(shù)量級。這個(gè)差距直接決定了推理速度的上限。跑一個(gè) 7B 參數(shù)、4bit 量化的模型模型文件本身可能在 4~5GB 左右每生成一個(gè) token 都意味著大量權(quán)重?cái)?shù)據(jù)要被 GPU 從內(nèi)存里讀一遍。內(nèi)存帶寬不夠GPU 算得再快也只能等數(shù)據(jù)慢慢傳過來。這也是很多人在核顯機(jī)器上部署后第一感受是“能跑但快不起來”的根本原因。除了帶寬容量也得精打細(xì)算。Intel 核顯的“共享顯存”理論上可以吃系統(tǒng)內(nèi)存但實(shí)際操作最好別把內(nèi)存全塞給模型。系統(tǒng)本身要占 4~6GB瀏覽器、開發(fā)工具再占幾個(gè) GB連聊天 UI 一起算下來16GB 內(nèi)存的機(jī)器留給模型的空間其實(shí)沒想象中寬裕。所以要在正式動手前把這條路想清楚小參數(shù) 量化模型 控制上下文長度才是核顯本地部署的正確姿勢。1.2 這種配置到底適合干什么既然性能天花板擺在那就不要拿著核顯去追 32B、70B 這類大模型了。本地大模型部署圖的是數(shù)據(jù)不出本機(jī)、按需使用、不用排隊(duì)等外部服務(wù)這一點(diǎn)核顯機(jī)器依舊成立只是適合的任務(wù)需要降級。我自己測試下來比較合適的場景是給本地知識庫做語義檢索和摘要、寫代碼時(shí)的補(bǔ)全建議、日常文案潤色、 JSON 格式化、日志分析、離線小助手這類輕量任務(wù)。模型規(guī)模一般建議控制在 1B~8B 區(qū)間再多就超出核顯機(jī)器的舒適區(qū)了。如果需要跑更大的模型也不是完全不可行比如只讓 CPU 跑大模型核顯負(fù)責(zé)把部分層卸載過去但那樣速度會更慢。更務(wù)實(shí)的用法是把 8B 以內(nèi)的小模型調(diào)好量化、調(diào)佳上下文確保單任務(wù)能在幾秒內(nèi)返回結(jié)果。對于“偶爾問幾句話”的真實(shí)頻率核顯部署完全夠用。還有一點(diǎn)容易忽略核顯跑模型的功耗表現(xiàn)比獨(dú)顯友好。對辦公本和迷你主機(jī)來說長時(shí)間開著模型服務(wù)也不用擔(dān)心風(fēng)扇狂轉(zhuǎn)這點(diǎn)倒是意外之喜。1.3 動手前先做好兩件事第一件事是確認(rèn)內(nèi)存足夠并盡量用雙通道內(nèi)存。核顯跑大模型的帶寬瓶頸就擺在那里雙通道內(nèi)存帶來的帶寬提升是實(shí)打?qū)嵉摹Ｈ绻掷锸菃螚l內(nèi)存有條件的話優(yōu)先加一條組成雙通道效果比換壓縮更值得投入。系統(tǒng)內(nèi)存建議不低于 16GB想跑 7B 量化模型并留出日常使用余量最好到 32GB。第二件事是更新顯卡驅(qū)動和 OpenVINO 等運(yùn)行時(shí)。聽起來像廢話但很多“核顯不工作”“GPU 識別不了”的問題都是因?yàn)轵?qū)動版本太舊或者系統(tǒng)自帶的驅(qū)動不帶 OpenCL 支持。如果一次跑不起來先把驅(qū)動更新到最新再排查能省一多半時(shí)間。預(yù)期管理同樣要做好核顯部署畢竟不是獨(dú)顯那種流暢體驗(yàn)生成速度慢一些模型太大會有延遲偶爾爆內(nèi)存。把這些當(dāng)成正常現(xiàn)象小步快跑先能把 3B 模型穩(wěn)定跑起來再慢慢擴(kuò)大參數(shù)規(guī)模整個(gè)過程就不會那么勸退。2. 工具選型路線對比主推 Ollama關(guān)鍵是選對后端2.1 四條路線快速對照在 Intel 核顯上部署本地大模型網(wǎng)上主流的方案其實(shí)就那么幾個(gè)我先把它們拉出來做個(gè)快速對照。方案上手難度Intel核顯支持典型做法適合誰Ollama低中等自動選擇可用設(shè)備命令行拉模型、跑 API絕大多數(shù)新手想最快看到效果llama.cpp OpenVINO中好可精細(xì)控制設(shè)備編譯支持 OpenVINO 的版本手動指定 GPU 層數(shù)想深入調(diào)參、排查問題的人Intel OpenVINO中最好官方專門適配針對 Intel 設(shè)備做模型轉(zhuǎn)換和推理對性能要求高、能接受較多學(xué)習(xí)成本IPEX-LLM中高面向 Intel CPU/GPU 做優(yōu)化基于 PyTorch 加載模型并自動優(yōu)化熟悉 Python需要靈活加載各種模型這四類方案不是彼此替代的關(guān)系更像是不同需求下的不同接口。Ollama 負(fù)責(zé)“把模型下載、運(yùn)行、API 暴露”這幾件事變得足夠簡單很多前端工具也默認(rèn)帶 Ollama 支持。llama.cpp 則更適合做底層驗(yàn)證因?yàn)樗鼤衙恳粚拥男遁d情況、耗時(shí)統(tǒng)計(jì)都打出來排查問題時(shí)非常有幫助。Intel OpenVINO 是硬件廠商自己出的推理框架對自家核顯的適配自然最深入。不過它的使用流程需要先把模型轉(zhuǎn)換到 IR 格式或者借助工具鏈完成轉(zhuǎn)換對只想簡單跑個(gè)對話模型的人來說有點(diǎn)重。IPEX-LLM 則是更偏向 PyTorch 生態(tài)的一條路適合你已經(jīng)有一定代碼基礎(chǔ)、想用 HuggingFace Transformers 加載模型的場景。2.2 我的選型思路和最終組合我個(gè)人最后采用的是“Ollama 做服務(wù)器 llama.cpp/OpenVINO 做輔助排查”的組合。先用 Ollama 把模型跑起來確認(rèn)整體鏈路通不通如果發(fā)現(xiàn)核顯沒有真正被用起來或者生成速度異常再用支持 OpenVINO 后端的 llama.cpp 做對比排查。為什么這么選因?yàn)楹孙@本地部署最大的問題不是“模型跑不起來”而是“不知道卡在哪一步”。Ollama 的日志相對友好能判斷模型文件是否下載完整、設(shè)備選擇是否正確。等系統(tǒng)能穩(wěn)定跑起一個(gè)小模型后如果想壓榨更多性能再切到 OpenVINO 后端逐個(gè)調(diào)試這條路線最不容易讓新手心態(tài)崩潰。不過在實(shí)操時(shí)要注意不同版本的 Ollama 對核顯的默認(rèn)支持策略不完全一樣。有些較新的版本會自動優(yōu)先使用 GPU 資源但遇到 TensorFlow 等框架共存的環(huán)境也可能行為怪異。遇到怪問題時(shí)不要急著換工具先看日志再檢查設(shè)備選擇多數(shù)情況能解決。選擇工具時(shí)別只看網(wǎng)上推薦也要看自己會什么。會 Python 的人用 IPEX-LLM 很順手不會 Python 的人 Ollama 反而是唯一能一次跑通的選擇。技術(shù)方案沒有絕對優(yōu)劣能穩(wěn)定復(fù)現(xiàn)的方案才是適合自己的方案。3. 實(shí)操關(guān)鍵幀部署流程、量化選型與上下文控制3.1 端到端最小閉環(huán)怎么搭不論選哪條路一個(gè)本地部署的最小閉環(huán)都包含這幾步拉取模型、啟動推理服務(wù)、通過 API 發(fā)起請求。用 Ollama 來做的話流程非常簡單。先啟動 Ollama 服務(wù)然后拉一個(gè)參數(shù)量適中的模型。我當(dāng)時(shí)為了快速驗(yàn)證鏈路先拉了一個(gè) 7B 模型的小量化版本ollama pull qwen2.5:7b看到下載完成后可以直接在終端里測試ollama run qwen2.5:7b這一條命令會進(jìn)入交互式對話。能正?；卮鹫f明模型本身沒問題。想讓外部程序調(diào)用Ollama 默認(rèn)會暴露一個(gè)兼容 OpenAI 格式的本地接口ollama serve服務(wù)啟動后在另一個(gè)終端里用 curl 測一下curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [{role: user, content: 你好}], stream: false }能收到 JSON 格式的回復(fù)說明本地大模型的完整調(diào)用鏈路已經(jīng)通了。后面接 VSCode 插件、接知識庫工具本質(zhì)上都是往這個(gè) API 地址上做對接模型本體不再需要反復(fù)折騰。3.2 量化選型別盲目追求“最小”也別硬上“最高精度”模型量化這個(gè)概念剛接觸的人容易理解成“把模型壓縮一下”實(shí)際上量化的本質(zhì)是用更少的數(shù)據(jù)位去近似原本的浮點(diǎn)權(quán)重。好處是模型文件變小、內(nèi)存占用降低、推理速度提升壞處是精度會有損失。在核顯部署場景下量化不是“可選項(xiàng)”而是“必選項(xiàng)”。選擇量化格式時(shí)需要看模型在 Ollama 或 llama.cpp 生態(tài)里常提供的幾種版本。通常從 Q2_K、Q4_K_M、Q5_K_M 到 Q8_0 都有數(shù)字越低文件越小。具體到怎么選我建議遵循一個(gè)原則在內(nèi)存能裝下的前提下用盡可能高的量化精度但不要為了精度犧牲上下文長度。我個(gè)人的實(shí)測體會是在核顯機(jī)器上跑 7B 模型Q4_K_M 是一個(gè)比較平衡的點(diǎn)。它保留的理解能力足夠應(yīng)對大多數(shù)任務(wù)文件體積不至于把內(nèi)存塞爆生成速度也還能看。Q2 級別雖然更小但生成內(nèi)容經(jīng)常會出現(xiàn)常識性混亂尤其是中文場景感受非常明顯。如果機(jī)器內(nèi)存緊張到只能跑 Q2那不如直接換更小的模型參數(shù)量從 7B 降到 3B/4B 再上 Q5/Q6效果會更穩(wěn)。另外不要忽略量化版本之間的兼容性。Ollama 官方倉庫里的模型一般來說會自動選擇適合當(dāng)前平臺的量化版本。但如果你手動下載 GGUF 文件再通過 llama.cpp 加載就必須確保量化格式被后端支持。比如某些精簡版工具鏈只支持固定幾種量化方式加載 Q8 文件可能直接報(bào)錯(cuò)。3.3 上下文長度、KV Cache 和內(nèi)存的三角關(guān)系模型參數(shù)量只是決定內(nèi)存占用的一個(gè)因素另一個(gè)容易被忽略的大頭是上下文長度。上下文越長模型能“記住”的對話歷史越多但 KV Cache 的占用會隨之線性增長。在核顯這種內(nèi)存敏感的環(huán)境下上下文設(shè)得過大經(jīng)常會看到“內(nèi)存不足”或推理速度突然暴跌的情況。我的經(jīng)驗(yàn)是核顯跑 7B 模型上下文可以先從 2048 或 4096 起步。如果做日志分析、文檔摘要這類單輪長文本任務(wù)把上下文適當(dāng)調(diào)高到 8192但要提前算好模型權(quán)重加上 KV Cache 的總占用別把內(nèi)存占滿。如果只是聊天或者代碼補(bǔ)全2K 上下文完全夠用還能騰出資源讓每次生成更快一些。在 llama.cpp 這類后端中上下文長度、批處理大小這些參數(shù)都暴露在啟動命令里。我常用的一組參考參數(shù)如下./llama-server \ -m /models/qwen2.5-7b-instruct-q4_k_m.gguf \ -ngl 999 \ -c 4096 \ --host 127.0.0.1 \ --port 8080其中-ngl 999表示把盡可能多的層卸載到 GPU 上。這對 Intel 核顯尤其重要如果不指定或指定的層數(shù)偏少默認(rèn)會全部丟給 CPU 跑那就完全體會不到“加速”了。-c 4096是上下文長度后面可以根據(jù)內(nèi)存余量再調(diào)。Ollama 也支持類似的上下文設(shè)置一般通過環(huán)境變量控制比如OLLAMA_CONTEXT_LENGTH。同樣10 億參數(shù)的模型對上下文不太敏感但 7B 以上模型對上下文的消耗會很直觀地反映在內(nèi)存占用上。對于批處理大小如果后端提供了-b 512或-b 1024這樣的參數(shù)可以先從 512 開始。調(diào)大 batch 值有時(shí)候能提升核顯的吞吐但也不是越大越好過大的 batch 會一次性吃掉更多內(nèi)存。核心思路是先保證模型權(quán)重能完整駐留再往上調(diào)上下文和 batch遇到卡頓就回退一點(diǎn)。3.4 不要忽略“加載模型”這個(gè)動作很多人把精力全花在選模型、調(diào)參上忽略了模型加載過程其實(shí)加載階段最容易暴露環(huán)境問題。模型文件要經(jīng)過讀取、反序列化、權(quán)重搬運(yùn)這幾步在核顯機(jī)器上如果模型文件大于可用內(nèi)存或者驅(qū)動不支持某些內(nèi)存分配方式進(jìn)程可能直接崩潰也可能卡在某個(gè)百分比不動。一個(gè)折中的驗(yàn)證方法是先用 CPU-only 模式加載同一個(gè)模型如果 CPU 模式能正常啟動GPU 模式反而崩潰那問題基本出在核顯驅(qū)動或后端設(shè)備選擇上。如果 CPU 模式都加載不了那就先檢查內(nèi)存容量、模型文件完整性再考慮版本兼容性。按照這個(gè)順序排查能少走很多彎路。4. 核顯部署高頻報(bào)錯(cuò)與排查記錄4.1 三個(gè)真實(shí)翻車現(xiàn)場部署過程中百分之八十的時(shí)間都在跟報(bào)錯(cuò)搏斗。我把幾個(gè)最典型的現(xiàn)場整理成速查表遇到相似問題時(shí)可以對照排查。現(xiàn)象可能原因處理做法模型能下載ollama run后一直沒輸出或極慢權(quán)重落在了 CPU 上核顯沒參與檢查日志中有沒有 GPU offload 信息指定設(shè)備參數(shù)或更新后端版本加載模型時(shí)提示內(nèi)存不足 / 進(jìn)程被殺模型權(quán)重 上下文緩存超過可用內(nèi)存換更小參數(shù)模型或更低量化調(diào)小上下文長度關(guān)閉占用內(nèi)存的大程序Ollama 提示 “GPU 不可用” 或檢測不到核顯顯卡驅(qū)動太舊、OpenCL 運(yùn)行時(shí)缺失、后端不支持當(dāng)前 Intel GPU更新驅(qū)動安裝 OpenCL 運(yùn)行時(shí)換用 OpenVINO 后端重試生成過程中畫面卡頓、視頻播放異常核顯內(nèi)存被模型占用過大影響到桌面渲染降低上下文長度減少同時(shí)跑的任務(wù)模型加載完再開其他 GPU 應(yīng)用llama.cpp 啟動報(bào) “cannot load GGUF”模型文件損壞或量化格式不被當(dāng)前構(gòu)建支持重新下載模型換官方量化版本第一個(gè)場景最隱蔽因?yàn)槟Ｐ痛_實(shí)能跑你很難察覺核顯沒有真正“發(fā)力”。排查方法很簡單打開任務(wù)管理器之類的系統(tǒng)監(jiān)控看模型加載后 GPU 的利用率是不是上去了。如果 GPU 利用率始終接近 0只有 CPU 在忙基本可以斷定模型沒被卸載到核顯上。內(nèi)存不足這個(gè)問題也很有迷惑性。系統(tǒng)物理內(nèi)存明明還有兩三個(gè) GB 剩余但模型加載到一半就退出多半是沒能申請到足夠大的連續(xù)內(nèi)存塊。這時(shí)候與其硬試同一個(gè)模型不如直接降一檔參數(shù)量或量化精度。4.2 如何確認(rèn)核顯真的在跑模型既然確認(rèn)“有沒有加速”是排查的關(guān)鍵那就要學(xué)會看證據(jù)不能憑感覺。以 llama.cpp 為例啟動時(shí)加上日志輸出能看到每一層加載到了哪個(gè)設(shè)備./llama-server \ -m /models/qwen2.5-7b-instruct-q4_k_m.gguf \ -ngl 999 \ -c 4096 \ --verbose輸出日志里會有一行類似“offloaded 33/33 layers to GPU”的記錄看到這句話才算真正放心。如果顯示 0 層或者只卸載了幾層說明核顯沒有完全參與計(jì)算需要回頭檢查驅(qū)動和編譯選項(xiàng)。Ollama 模式下查看當(dāng)前加載模型狀態(tài)也可以用簡單的命令確認(rèn)ollama ps這一命令會列出當(dāng)前正在運(yùn)行的模型、加載的設(shè)備信息等。如果顯示模型已經(jīng)加載但設(shè)備看起來不對可以重啟 Ollama 服務(wù)后重新拉起模型。除了日志和命令最直接的感知還是生成速度。7B 量化模型在純 CPU 上跑每秒鐘也許只能生成幾個(gè)字如果切到核顯后速度有了明顯提升即使不怎么看日志也知道加速生效了。反過來如果切到 GPU 后速度還不如純 CPU那可能是模型太小、卸載帶來的開銷反而蓋過了收益這時(shí)用-ngl 0或 CPU-only 模式反而更實(shí)用。4.3 驅(qū)動、散熱與電源策略會被忽視的坑Intel 核顯跑模型時(shí)系統(tǒng)內(nèi)存會被大量占用內(nèi)存控制器和核顯的負(fù)載同時(shí)升高帶來的直接結(jié)果是整機(jī)溫度上漲、風(fēng)扇轉(zhuǎn)速提升。如果是筆記本一定要插上電源跑電池模式下不少系統(tǒng)會自動限制核顯功耗速度會明顯打折。散熱也很關(guān)鍵。核顯雖然沒有獨(dú)立顯存但 GPU 核心是實(shí)打?qū)嵲诠ぷ鞯拈L期滿負(fù)載運(yùn)行會讓機(jī)身發(fā)燙。我遇到過跑一段時(shí)間后生成速度越來越慢的情況后來發(fā)現(xiàn)是溫度墻觸發(fā)降頻了。把筆記本墊高、打開性能模式或者跑任務(wù)時(shí)讓風(fēng)扇策略調(diào)到更積極一些都能緩解降頻問題。另外驅(qū)動設(shè)置里的“圖形性能首選項(xiàng)”也可能影響結(jié)果。如果系統(tǒng)里同時(shí)存在核顯和獨(dú)顯的混合模式有些程序會默認(rèn)走獨(dú)立顯卡反而沒讓核顯發(fā)揮作用。反過來某些系統(tǒng)驅(qū)動版本默認(rèn)把 OpenCL 使用限制在特定應(yīng)用導(dǎo)致新裝的推理后端檢測不到 GPU。遇到這類問題不要急著重裝系統(tǒng)先從顯卡驅(qū)動面板的“應(yīng)用設(shè)置”里手動指定一下用哪個(gè)設(shè)備跑往往就解決了。5. 把本地模型接入日常工具從命令行到應(yīng)用生態(tài)5.1 OpenAI 兼容 API 是打通一切的關(guān)鍵本地部署大模型的最終目的不只是“在終端里聊天”而是要接到自己常用的工具里。目前大部分 AI 編程插件、聊天前端、知識庫工具都支持“自定義 OpenAI 兼容地址”這類配置而本地推理服務(wù)只要提供類似的 API 格式就能無縫頂替云端接口。我用 Ollama 時(shí)默認(rèn)的 API 地址是http://localhost:11434/v1。在前端工具的模型配置里填入這個(gè)地址再把模型名改成當(dāng)前正在跑的模型名就能讓工具調(diào)用本地模型。比如常見的 VS Code 編程助手插件 Continue在配置里新增一個(gè) provider選擇 Ollama 作為后端模型填 qwen2.5:7b請求就能從云端切到本地。這樣做還有一個(gè)好處代碼和對話文本不需要離開本機(jī)。對想保護(hù)私有代碼片段的人來說這比把內(nèi)容發(fā)到第三方服務(wù)要安心得多。雖然核顯跑大模型的代碼補(bǔ)全速度比不上云端大模型但勝在隱私可控和離線可用。如果機(jī)器性能實(shí)在有限建議在使用這類工具時(shí)把“自動補(bǔ)全”功能關(guān)掉或調(diào)低觸發(fā)頻率。因?yàn)樽詣友a(bǔ)全會在你敲代碼時(shí)頻繁發(fā)起推理請求核顯如果同時(shí)響應(yīng)多個(gè)并發(fā)請求很容易變卡。我把策略改成“手動觸發(fā)”比如快捷鍵讓模型解釋當(dāng)前選中代碼整體體驗(yàn)會好很多。5.2 搭配網(wǎng)頁聊天 UI 和輕量知識庫聊天場景同樣可以換一個(gè)更友好的頁面。Open WebUI 這種開源聊天前端能直接指向本地 Ollama 服務(wù)提供類似商業(yè)產(chǎn)品的對話界面還能管理多輪會話和模型切換。部署方式不算太復(fù)雜尤其是有 Docker 經(jīng)驗(yàn)的人。如果你的機(jī)器性能有限建議不要同時(shí)跑后端模型和 Docker 里那一堆額外組件分開部署能降低內(nèi)存爭搶。知識庫類應(yīng)用也可以試著接但預(yù)期要放低。文檔導(dǎo)入后需要做向量化向量化這一步如果用 CPU 或核顯來做會比較慢尤其是一次性導(dǎo)入大量文檔時(shí)可能要等很久。我的建議是先拿小批量文檔測試整套鏈路確認(rèn)“上傳文檔 - 切片向量化 - 檢索 - 拼接提示詞 - 調(diào)模型總結(jié)”整個(gè)過程都能跑通再考慮導(dǎo)入幾百份以上的文檔場景。在實(shí)際使用中強(qiáng)烈建議“一次只跑一個(gè)模型不要同時(shí)加載多個(gè)模型”。核顯機(jī)器內(nèi)存有限同時(shí)跑兩個(gè) 7B 量化模型會直接把內(nèi)存打滿。不同工具如果指向同一個(gè) Ollama 服務(wù)Ollama 默認(rèn)會加載最近使用的模型當(dāng)工具 A 請求模型 X、工具 B 請求模型 Y 頻繁切換時(shí)模型會被重復(fù)換入換出帶來額外延遲。如果非要多種模型切換盡量把工具調(diào)用頻率錯(cuò)開或者干脆都用同一個(gè)模型。5.3 一套低配機(jī)器也能舒服用的運(yùn)行配置把這幾天調(diào)出來的配置沉淀下來我通常這樣跑模型選 7B 量化版比如 qwen2.5:7b 或類似等級的中文模型。上下文設(shè) 4096不追求超長對話。前端用 Continue 或 Open WebUI按需手動觸發(fā)。模型常駐內(nèi)存不頻繁切換。物理內(nèi)存盡量留 4GB 以上余量給操作系統(tǒng)和其他應(yīng)用。這套配置在 Intel 核顯機(jī)器上雖然每秒鐘出字速度不算快但勝在穩(wěn)定日常問幾個(gè)問題、寫幾段代碼摘要完全能接受。如果覺得 7B 模型太慢就降到 4B 或 3B速度提升會非常明顯中文效果也依然可用。6. 最終經(jīng)驗(yàn)和幾條真誠的建議折騰到這一步感受最深的一句話是“核顯不是不能跑只是要用對地方?！比绻婚_始就把目標(biāo)定成“跑個(gè) 70B 模型秀肌肉”那注定失敗。但如果目標(biāo)改成“讓 7B 的小模型穩(wěn)定上線接到日常工具里”Intel 核顯完全夠用。我復(fù)盤整個(gè)項(xiàng)目覺得有幾個(gè)環(huán)節(jié)是后來者最容易踩的第一不更新驅(qū)動就直接跑遇到 GPU 檢測不到的問題第二不控制上下文長度內(nèi)存一被塞滿就各種詭異報(bào)錯(cuò)第三不確認(rèn)核顯是否真的參與只是在純 CPU 模式下自我安慰第四同時(shí)開多個(gè)服務(wù)把有限內(nèi)存硬生生搶光。如果讓我重新來一次我會先用一臺內(nèi)存 16GB 以上的機(jī)器裝上最新驅(qū)動用 Ollama 拉一個(gè) 4B 或 7B 的量化模型先把最小閉環(huán)跑通再逐步加上下文、加應(yīng)用層對接。整個(gè)部署過程看起來簡單但每一步背后都是硬件約束和軟件版本共同作用的結(jié)果。希望這篇踩坑記錄能讓你省下我當(dāng)初反復(fù)試錯(cuò)的時(shí)間。