說實話第一次看到這個標題我自己都愣了一下——養(yǎng)龍蝦和AI大模型有什么關系后來才反應過來原來是把硬核玩成了養(yǎng)龍蝦的諧音梗講的其實是Intel核顯UHD/Ultra/Arc跑大模型這件事。這個路子看起來很野但實測下來還真不是瞎折騰。先說結論用Intel核顯跑本地大模型完全可行只是很多人被核顯不行的固有印象勸退了。這篇就當作一次個人實測記錄從裝Ollama、拉取qwen3.5模型到接上Copaw做技能化改造我把完整過程、跑分數據、踩坑點全部捋一遍。如果你手上只有一臺集成顯卡的辦公本、輕薄本又不想花錢租云GPU這篇文章可以幫你少走不少彎路。1. 養(yǎng)龍蝦是什么梗Intel核顯跑大模型這件事的可行性1.1 硬核變養(yǎng)龍蝦一個標題引發(fā)的誤區(qū)澄清養(yǎng)龍蝦之因特爾UHD/Ultra/Arc核顯跑大模型拆開看就是在說用Intel集成顯卡跑大語言模型。這類裝機標題老玩家看一眼就懂但新朋友很容易被養(yǎng)龍蝦三個字搞蒙以為是什么養(yǎng)殖農業(yè)項目。其實養(yǎng)龍蝦是硬核的諧音調侃意思就是這件事做起來很硬核——要在集顯上跑LLM既考驗軟件棧的耐心也考驗硬件配置的兜底能力。我最初也認為沒有NVIDIA獨顯就別指望本地跑模型了但事實證明這個判斷過時了。關鍵變化有兩個一是Intel近幾代核顯的EU單元數量和頻率明顯提升Arc系列更是跨進了高性能核顯的陣營二是Ollama這類推理框架早就對Intel的 Level Zero 和 OpenCL 后端做了深度適配把核顯能不能跑這個問題的答案從不能變成了能但要看內存帶寬。1.2 為什么核顯能跑LLM內存帶寬與量化是關鍵很多人以為跑大模型最缺的是算力其實在集顯場景下最缺的是內存帶寬。核顯沒有獨立的顯存它用的是共享的系統內存。模型權重要從DDR4/DDR5內存或LPDDR5內存里搬運到GPU核心計算內存讀起來多快推理就能跑多快。大語言模型的推理分兩個階段prefill解析你輸入的一整段話和decode一個token一個token地生成答案。decode階段尤其吃帶寬因為每一步都要把全部權重重新讀一遍。舉個例子qwen3.5:0.8b按4bit量化后權重大約是0.5GB左右假設你的內存帶寬是50GB/s理論上每秒最多能掃過100次權重對應大概幾十個token每秒的生成速度。如果你的機器是DDR5雙通道帶寬上80-90GB/s那速度會更舒服如果還是老舊的單通道DDR4帶寬只有20多GB/s那速度就只剩個位數了。所以核顯跑大模型本質上不是顯卡行不行而是內存快不快。理解這一點后面所有實測數據你都能自己推出來。2. 環(huán)境準備與模型部署Ollama安裝、Intel核顯檢測與qwen3.5模型拉取2.1 檢查核顯是否滿足條件從驅動到共享內存如果你用的是Linux系統第一步不是裝Ollama而是確認核顯暴露出來的設備節(jié)點和驅動棧是否完整。打開終端先看核顯設備有沒有被系統識別ls /dev/dri/正常情況下你會看到card0和renderD128兩個設備。如果只有card0沒有renderD128說明渲染節(jié)點沒啟用核顯跑不了加速計算。接著確認OpenCL和Level Zero運行時是否就緒sudo apt update sudo apt install intel-opencl-icd intel-level-zero-gpu clinfo vainfo clinfo | grep Device Name vainfo | grep Driver versionclinfo能看到Intel核顯的OpenCL設備信息vainfo主要驗證視頻加速但也能旁證圖形驅動棧是否健康。這里有個經驗很多筆記本在Windows下核顯跑得好好的裝完Linux才發(fā)現驅動沒打全后面一堆問題都是從這里來的。內存方面建議至少16GB起步。qwen3.5:0.8b量完才1GB上下看起來8GB也夠但核顯默認會從共享內存里預分配一部分給圖形再加上系統本身占用8GB會很緊張。qwen3.5:9b更是直接吃5-6GB權重加上下文緩存內存不夠你就只能眼睜睜看著它OOM。2.2 安裝Ollama并啟用Intel核顯后端Ollama的安裝其實是最沒技術含量的一步官方支持Linux、macOS、Windows一行命令搞定curl -fsSL https://ollama.com/install.sh | sh裝完先別急著拉模型確認一下它到底用的什么后端。新版本的Ollama會自動做硬件探測但如果你的系統比較老或者之前裝過亂改環(huán)境的軟件最好手動指定一下Intel GPU后端。編輯Ollama服務配置加上環(huán)境變量sudo systemctl edit ollama.service在配置里加上[Service] EnvironmentOLLAMA_INTEL_GPU1 EnvironmentOLLAMA_LLM_LIBRARYintel保存后重啟服務sudo systemctl daemon-reload sudo systemctl restart ollama這里要補充一個背景Ollama在Intel核顯上走的是Level Zero API而Level Zero這套接口和NVIDIA的CUDA完全不是一個東西。如果你不顯式指定后端Ollama可能會老老實實退回CPU推理速度立刻垮一半以上。Windows用戶簡單得多安裝包雙擊完事Ollama會自動識別Intel核顯。但Windows下想復用上面的驗證命令你得裝Intel官方工具我建議直接在設備管理器里看有沒有Intel(R) Iris(R) Xe Graphics之類的顯示適配器有就行。2.3 拉取qwen3.5:0.8b和qwen3.5:9b不只是ollama pull那么簡單模型拉取命令看起來就是兩條ollama pull qwen3.5:0.8b ollama pull qwen3.5:9b但這里有個非常容易踩的坑默認拉取的是量化版本還是完整版本不是你想當然的那回事。Ollama會按標簽拉取合適格式但你最好在拉之前用ollama show看下模型文件結構。ollama show qwen3.5:0.8b關注輸出里顯存/內存需求那一行如果顯示的需求量大得離譜說明拉到的不是適合集顯跑的量化版得換帶特定后綴的標簽。說實話我一開始沒看結果0.8b的模型占了4GB內存我還以為是正常開銷后來才發(fā)現拉錯了標簽白白浪費半小時。正確的做法是先到模型倉庫頁確認你想要的量化精度比如Q4_K_M之類的QLoRA量化版本體積小、精度損失可控特別適合內存帶寬吃緊的核顯設備。0.8b這種迷你模型用Q4量化后大概0.5GB左右9b則要5.5GB這個量級參考下表模型量化格式權重體積推薦內存適合場景qwen3.5:0.8bQ4_K_M約0.5-0.8GB8GB日常對話、快捷總結qwen3.5:9bQ4_K_M約5.5-6.5GB16GB長文檔分析、復雜任務拉完模型別急著關終端先跑一下自檢命令ollama list ollama run qwen3.5:0.8b 你好請簡單介紹一下你自己如果回復正常說明Ollama本體已經通了。這時要看是不是真的在核顯上跑可以在另一個終端開htop或者用ollama ps看加載狀態(tài)。有些機器上Ollama顯示跑在GPU但GPU利用率是0%那就是后端沒切干凈回頭再查那個環(huán)境變量。3. 實測數據0.8b流暢到起飛9b夠用但別期待滿載3.1 0.8b的實測速度與內存占用先說結論qwen3.5:0.8b在Intel核顯上跑起來速度完全在可用范圍。我測試用的是一臺搭載Intel Iris Xe核顯、雙通道DDR4-3200內存的機器系統是Ubuntu 22.04Ollama后端明確切換到intel。實測生成一個200字的回復首token延遲大約1秒左右后續(xù)生成速度穩(wěn)定在45-55 token/s之間。這個速度是什么概念你正常讀文章的速度大約每分鐘300-400字0.8b的輸出速度已經比你讀得快了。日常用來寫摘要、寫標題、做文本分類這種輕量任務完全沒有任何拖沓感。內存占用情況模型加載后大約占1.2GB左右加上系統和其他應用8GB內存的機器勉強也能跑但如果你想同時開瀏覽器、編輯器建議還是16GB起步更穩(wěn)。核顯會動態(tài)劃走一部分系統內存所以你在任務管理器或htop里看到的內存數值會跳動這是正?，F象。有個小細節(jié)我在跑0.8b時把上下文窗口設成了8192結果首token延遲明顯變長了。后來發(fā)現是KV Cache在初始化時就要占掉不少內存核顯平臺本來內存帶寬就緊張窗口開太大反而拖慢速度。設成4096之后整體響應速度立刻回血。3.2 9b的實測表現與調參建議9b的數據就沒那么漂亮了。同樣在DDR4-3200雙通道環(huán)境下qwen3.5:9b的生成速度大約是7-10 token/s首token延遲在3秒左右。這個速度用來寫代碼注釋、做單輪問答、跑腳本任務是可以接受的但如果你習慣ChatGPT那種秒回節(jié)奏會有明顯的卡頓感。換了DDR5雙通道的機器測試速度能提升到15-20 token/s體感好不少。所以如果你的筆記本是近兩年的DDR5平臺9b其實可以當主力模型用。參數調優(yōu)方面我建議在Ollama的運行參數上做幾個保守設定ollama run qwen3.5:9b --num-ctx 4096 --temperature 0.6num-ctx控制在4096太大KV Cache吃內存decode速度會進一步下滑temperature調到0.6左右讓模型輸出更穩(wěn)定減少重復生成還有一點9b跑起來之后核顯溫度會明顯上升。我的機器在連續(xù)跑5分鐘后核顯溫度穩(wěn)定在80度左右CPU整體功耗也上了一個臺階。筆記本用戶如果散熱不好建議不要長會話掛著跑完一批任務就/bye退出讓模型釋放顯存。3.3 雙模型切換與Ollama常用運維命令手上有0.8b和9b兩個模型以后最常遇到的問題就是怎么切換。Ollama的運行參數里其實能把模型換著加載但如果你不想等重新加載可以把兩個模型都保持在后臺然后用ollama ps查看當前加載的模型列表。ollama ps這個命令會顯示當前正在運行的模型、顯存/內存占用、上下文大小、直到過期的時間。我用下來最順手的組合是0.8b常駐后臺處理快速任務9b用到一個專門的腳本臨時加載。需要9b時直接在命令行指定用完通過ollama stop qwen3.5:9b把它卸載把內存還給系統。如果你想把Ollama暴露給其他工具調用首先要保證服務在監(jiān)聽端口。默認情況下Ollama監(jiān)聽127.0.0.1:11434你可以先驗證curl http://127.0.0.1:11434/api/generate -d {model: qwen3.5:0.8b, prompt: 你好}這一步通了后面接入Copaw就非常輕松了。4. Copaw 1.0.1接入與技能配置從聊天玩具到動手干活4.1 Copaw如何對接本地Ollama API模型跑通了但如果只是開個終端對話那充其量是本地版ChatGPT離干活還差一步。Copaw就是專門用來做這一步銜接的工具它負責把大模型封裝成一個個可復用的技能每次執(zhí)行任務時自動選擇對應模型和提示詞。Copaw接Ollama的思路非常簡單Ollama本身就提供OpenAI兼容的API地址是http://127.0.0.1:11434/v1/chat/completions在Copaw的配置文件里把模型接口指到這個地址認證方式隨便填一個任意字符串本地服務不需要真密鑰然后模型名填你在Ollama里拉好的標簽比如qwen3.5:0.8b或qwen3.5:9b。我給Copaw配的第一個技能叫中文標題生成器思路是讓模型根據我給的正文內容輸出3個不同風格的標題。技能配置大致長這樣skill: name: 中文標題生成器 model: qwen3.5:0.8b system: | 你是一個資深新媒體編輯擅長為技術文章生成通俗有趣的中文標題。 要求 1. 標題必須包含核心關鍵詞 2. 適當使用諧音?；蚓W絡流行語 3. 長度控制在15-25字 4. 輸出3個候選標題每個一行 temperature: 0.8 max_tokens: 128保存好后在Copaw里選中這個技能輸入一段正文它就自動調Ollama的0.8b模型完成任務。我用它給上面的實測記錄生成了幾個標題有一個居然是養(yǎng)龍蝦之因特爾UHD/Ultra/Arc核顯跑大模型這讓我哭笑不得——模型自己學會了這個梗。4.2 技能配置實操用一條系統提示詞把模型改造成專職工具真正讓Copaw效果炸裂的是把技能拆細。很多人配技能就是把system prompt一改換個名字本質上還是聊天。核心玩法是把任務拆成多個技能讓模型各司其職。我做的第二套技能是文章段落總結器配給9b模型用skill: name: 文章段落總結器 model: qwen3.5:9b system: | 你是一個文檔分析助手。用戶會輸入一段技術文章。 請輸出 1. 段落編號和一句話主旨 2. 涉及的技術點列表 3. 可能的踩坑點如果有 要求輸出簡潔不超過300字。 temperature: 0.3 max_tokens: 512 stop: - 輸出結束這一套跑在核顯上速度雖然不如0.8b但質量高出一大截。9b在小參數模型里表現確實好長段落的主旨提取基本合理偶爾會漏掉小眾技術細節(jié)但作為初篩工具已經夠用。Copaw還支持把前一個技能的輸出作為后一個技能的輸入。比如我先用0.8b跑標題生成器把生成的標題作為素材再讓9b跑摘要總結器對候選標題逐一打分最終輸出最優(yōu)標題。這種串聯方式特別適合核顯平臺——0.8b先快速初篩9b再精加工速度和質量都能兼顧。4.3 問答延展技能編排、知識庫注入與多輪優(yōu)化配技能的過程中有幾個容易被忽略的細節(jié)值得單獨說說。第一系統提示詞里的角色設定不是越復雜越好。核顯平臺跑小模型系統提示詞寫太長會擠壓實際內容的生成空間我實測下來0.8b的system prompt限制在200字以內效果最好寫太多它就開始忘記前面的角色要求。9b可以放寬到400字左右但再多也會出現優(yōu)先級混亂。第二如果你想讓技能更有針對性可以把常用知識片段直接放進system prompt里。比如我有一個本地論壇體回帖風格技能就把論壇常用的語氣詞、句式樣例塞進提示詞。Copaw會自動把這段固定知識像文檔前綴一樣帶著效果比我預期好很多——相當于給模型做了一個微型知識庫注入。第三多輪對話場景下建議把歷史消息控制在4-6輪以內。因為核顯平臺的KV Cache會隨上下文長度線性增長對話輪數太多decode速度會斷崖式下降。我這臺機器上9b在10輪對話后生成速度掉了將近一半切到0.8b才好一點。5. 這波實測最容易被坑死的幾個細節(jié)5.1 核顯不工作的三大元兇驅動、組權限、環(huán)境變量整個流程里最折磨人的環(huán)節(jié)不是模型拉不下來而是模型明明在跑核顯GPU利用率卻始終是0%。我第一次遇到這問題ollama ps顯示模型加載在GPU但GPU利用率就1%速度全是CPU在扛。排查一圈發(fā)現是用戶沒加入video和render組Level Zero后端拿不到/dev/dri/renderD128的權限自動回退到CPU了。解決辦法sudo usermod -aG video,render $USER然后注銷重新登錄再用clinfo確認設備可訪問。這是Linux下跑Intel核顯推理最常見的坑沒有之一。第二個坑是Ollama退回了CPU后端。很多老教程讓你裝intel-opencl-icd但現在Ollama默認走Level Zero你只裝OpenCL驅動根本沒用。必須確認系統里有intel-level-zero-gpu并且在配置文件里顯式指定OLLAMA_LLM_LIBRARYintel。第三個坑出現在Windows平臺上——如果你用WSL跑Ollama核顯直通是做不到的WSL 2里的Ollama只能CPU你在WSL里裝Intel驅動純屬白費功夫。老老實實用Windows原生版或者在Linux實機上跑。5.2 顯存共享與內存容量為什么9b吃掉了你大半內存核顯模型推理不占獨立VRAM這既是好事也是壞事。好處是你不用擔心顯存溢出模型權重多大直接落到系統內存里壞處是它和系統搶內存而且一旦模型加載后不卸載內存就一直被占著。實測下來qwen3.5:9b加載完系統可用內存從16GB直接掉到7-8GB僅模型和上下文緩存就吃掉了6GB左右。如果再開瀏覽器、IDE隨時可能觸發(fā)內存交換硬盤I/O頂上后推理速度直接崩到1-2 token/s。那時候你會產生一個錯覺卡得像PPT。實際上不是顯卡的問題是內存被掏空了。我的做法是給Ollama設置內存上限或者干脆準備一個卸載腳本。Copaw配置里我也特意把9b技能的使用頻率控制住只有處理長文檔時才調用輕量任務一律走0.8b。如果你只有8GB內存強烈建議只保留0.8b。9b雖然能加載但加載完你連打開文檔都困難推理體驗會非常糟糕。5.3 別迷信數字token速度之外的體驗差異最后想聊點數字之外的東西。一開始我盯著token/s看總覺得9b速度只有個位數體驗肯定不行。但用了一段時間發(fā)現實際感受比數字好很多。因為大模型交互里首token延遲才是更影響體感的指標而小上下文場景下9b在核顯上首token延遲也就2-4秒完全在可接受范圍內。對比下來0.8b雖然快但邏輯能力明顯弱你問它復雜一點的因果推理它會一本正經地把因果關系倒過來。9b在這類任務上垮得沒那么厲害。所以我現在的實際使用策略是能派給0.8b的絕不動用9b但關鍵任務必須9b兜底。還有一個小技巧Copaw技能的temperature參數建議跟任務類型綁定。生成類任務標題、文案開到0.8-1.0效果靈活分析類任務總結、提取開到0.2-0.4輸出更穩(wěn)定。這個參數在0.8b和9b上都成立但在9b上作用更明顯。最后補一句跑完這套流程我對集顯跑大模型的認知徹底變了。以前覺得這是玩具現在覺得只要選對模型量級、搭配合適的技能編排它完全可以當一個安靜的本地AI工作臺來用。檔案經查全在本地不需要聯網數據都在你手邊這種安全感是云服務給不了的。如果你手頭正好有一臺帶Intel核顯的機器下一步建議從0.8b開始先把Ollama跑通配一個Copaw技能親手感受一次核顯干活的過程。實踐一下比我在這兒寫三千字管用。