【2026 最新】Intel Arc 本機 LLM 怎麼跑？Vulkan／SYCL 同檔部署與 GPU 驗收教學

Intel Arc 本機 LLM 已經能回答問題，風扇卻沒什麼動靜：到底是顯卡在算，還是 CPU 默默接手？網路上又有人說 Vulkan 快、有人說 SYCL 快。先別急著換模型；你需要的是能對上同一張卡、同一份檔案的執行紀錄。

這篇寫給第一次接觸本機模型、願意在終端貼指令的新手。用 Ubuntu Desktop 24.04 與 Arc A770 作為單卡練習範圍，教你建置兩條路線、確認實際 GPU，再分開量讀題、生成與完整任務時間。Windows 使用者可以先學驗收邏輯，建置步驟則回到對應作業系統文件。

以下依截至 2026 年 10 月 8 日的官方文件與固定原始碼整理。AlphaLab 本次主機沒有 Intel Arc，未執行這兩個後端；本文提供操作與判讀方法，不提供自稱實測的速度排名。你最後要交出的，是自己的裝置與測試紀錄。

先說結論：Intel Arc 本機 LLM 先驗裝置，再比速度

可用的 GPU 推論＝找到正確裝置＋確認工作載入＋通過自己的任務。找到裝置像找到廚房，offload 像把食材搬進去，最後還要確認菜有做出來。只看到回答，還不足以知道是哪間廚房完成。

• Vulkan 與 SYCL 都是 llama.cpp 可使用的 GPU 後端；它們是安排計算的路線，並不是兩個不同語言模型。
• 兩邊都用同一份 GGUF、相同 commit 與同一張 Arc；固定設定後，先做短任務，再做長輸入。
• 把 GPU 裝置、offload、主記憶體 fallback 和失敗放進紀錄。能穩定完成你的工作，才有比較速度的資格。

五個零件：先把模型、後端與記憶體分開

① GGUF：「同一份食材」

GGUF 是模型檔案格式，量化則讓權重用較少位元保存。兩份都叫 4-bit 的模型，仍可能是不同檔案。本文以 Qwen 官方 Qwen3-4B GGUF 的 Qwen3-4B-Q4_K_M.gguf 作練習；從這個固定 revision 取得檔案，放到 llama.cpp 的 models 目錄。已有該檔即可沿用，另存來源與 SHA-256。

4B 描述模型參數規模，並不是顯存需求。先選小檔，避免一開始把硬體上限、量化品質與後端差異混在一起；量化名稱可接著讀 GGUF 量化指南。

② llama.cpp：「同一家廚房的工作規則」

推論引擎負責載入模型並安排計算。Vulkan 是跨平台圖形與運算 API；SYCL 是 C++ 平行運算模型，本文的 SYCL 路線使用 Intel oneAPI 工具鏈。換後端，會換執行實作；模型檔仍保持不變。LLM 推論引擎入門 能補上這些層級，SYCL 的概念說明 則解釋它和語言模型的不同。

③ 裝置名稱：「哪位廚師真的接單」

桌機可能同時有 Arc 獨顯與 CPU 內建顯示晶片。Vulkan 的第 0 個裝置、Level Zero 的第 0 個裝置，不應憑編號認成同一張卡。先看完整名稱，再在各自的裝置清單選 Arc；重建或加上篩選器後，要重新列一次。

④ Offload：「搬到顯卡多少工作」

Offload 是把工作交到 GPU；-ngl 99 是要求載入最多 99 個模型層，不是 99% 使用率，也不是成功證明。讀取啟動紀錄中的實際 offloaded 層數、model buffer 與 KV buffer 所在位置；GPU 有工作不代表 CPU 使用率會歸零。

⑤ Context 與 KV cache：「桌面與讀過的筆記」

Context 是此次可用的 token 空間，KV cache 是保存已讀內容計算結果的快取。-c 8192 留出窗口容量，不會替你自動填入 8,192 個 tokens。要測長文，得真的送長輸入；要測已有上下文後的生成，則要設定 benchmark 的深度。容量與深度像桌子大小和桌上已放的資料，不能互換。

Intel Arc 本機 LLM 上手：固定環境，分開建置

第一步：先確認 Ubuntu 的兩張通行證

痛點是桌面能顯示，卻不代表兩種運算 API 都能看到 GPU。解法是分開查 Vulkan 與 SYCL。先依 Intel Ubuntu GPU 安裝文件 完成適合這張卡與系統的驅動／compute runtime；記下 uname -r、lspci -nnk 與安裝套件版本。不要照貼另一張卡的核心或驅動版本。

Vulkan 建置工具依 官方 Vulkan 文件 準備。Ubuntu 可執行 sudo apt-get install build-essential cmake git libvulkan-dev glslc spirv-headers vulkan-tools time，再跑 vulkaninfo --summary。清單應找到 Arc；若只見軟體渲染裝置，先停在驅動檢查，不把它算成 Arc 測試。

SYCL 需要 oneAPI 的編譯器與相應函式庫。依 官方 SYCL Linux 文件 安裝 Intel oneAPI Toolkit，再執行 source /opt/intel/oneapi/setvars.sh 與 sycl-ls。預設安裝路徑不同就替換路徑；保存顯示 Arc 的 Level Zero 項目。文件近期的 Linux 步驟已更新 Toolkit 套件分工，勿把舊教學的套件名稱視為同一安裝內容。

若因裝置權限看不到 GPU，依同份文件將你的帳號加入 render／video 群組，登出再登入；用 id 核對已生效。先修到一般帳號能列出裝置，再往下走，不以每次 sudo 執行模型掩蓋問題。

第二步：兩個 build 目錄，共用一個 commit

痛點是比較到不同版本，卻以為只換後端。解法是固定原始碼、隔離建置。在新的工作目錄依序執行 git clone https://github.com/ggml-org/llama.cpp.git、cd llama.cpp、git checkout --detach fc9ce6b9d52a8504edcb262abc92737c2289f96c，再用 git rev-parse HEAD 保存結果。這是本文查核的版本，不將它當成永遠最新。

建 Vulkan：cmake -S . -B build-vulkan -DCMAKE_BUILD_TYPE=Release -DGGML_VULKAN=ON -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++；成功後執行 cmake --build build-vulkan --config Release -j 4。

建 SYCL：在已 source oneAPI 的終端執行 cmake -S . -B build-sycl -DCMAKE_BUILD_TYPE=Release -DGGML_SYCL=ON -DCMAKE_C_COMPILER=icx -DCMAKE_CXX_COMPILER=icpx -DGGML_SYCL_F16=ON -DGGML_SYCL_HOST_MEM_FALLBACK=OFF，再跑 cmake --build build-sycl --config Release -j 4。此處刻意關掉特定 weight reorder 的 host fallback，先建立容量失敗可辨認的基線；它不等於關閉所有 CPU 工作。

保存兩邊 CMakeCache.txt、icpx --version、gcc --version 與 runtime／驅動版本。FP16 是 SYCL 的建置選項，不會把 GGUF 重新量化；兩種後端的內部 kernel 和編譯器仍不同，這次比較的是可部署組合，不是把硬體其他差異全部消去的實驗。

第三步：用清單選 Arc，再讀 offload 日誌

先執行 ./build-vulkan/bin/llama-completion --list-devices 與 ./build-sycl/bin/llama-completion --list-devices。把對應 Arc 的名稱填入 VK_DEV、SY_DEV；例如清單真的寫 Vulkan0、SYCL0，才執行 VK_DEV=Vulkan0 與 SY_DEV=SYCL0。這些名字是清單範例，不能直接假設你也是 0。

設定 MODEL=models/Qwen3-4B-Q4_K_M.gguf，跑 sha256sum "$MODEL"，再 mkdir -p logs。用同一小提示分別執行 ./build-vulkan/bin/llama-completion -m "$MODEL" --device "$VK_DEV" -sm none -ngl 99 -c 2048 -b 512 -ub 128 -t 4 -fa off --fit off -no-cnv -p "List three uses of a notebook." -n 64 > logs/vk-smoke.txt 2> logs/vk-smoke.log。

第二條把 build-vulkan 改成 build-sycl、"$VK_DEV" 改成 "$SY_DEV"，輸出改名 sy-smoke.txt／sy-smoke.log。檢查程序退出碼 echo $?，再打開兩份 log。此版本參數定義 說明裝置、窗口與 fit；關掉 fit 是為了避免未設定的參數因容量自動改動。

核對三件事：Arc 的實際裝置名稱；實際 offload 層數與 buffer 配置；輸出是否連貫。若未按預期載入，先處理錯誤，再談速度。需要 Level Zero 篩選時，依 sycl-ls 的實際索引設定 ONEAPI_DEVICE_SELECTOR；篩選後重列 llama.cpp 清單，因可見裝置可能重新編號。

短、長兩種深度：把讀題與生成分開量

痛點是空上下文的生成很快，讀入長文件卻卡住。解法是固定深度的 pp／tg 測試。以下的 512、128、0／4096、三次重複都是練習設定，不是成績。先看 llama-bench 參數與計時說明，再執行：./build-vulkan/bin/llama-bench -m "$MODEL" -dev "$VK_DEV" -sm none -ngl 99 -p 512 -n 128 -d 0,4096 -b 512 -ub 128 -t 4 -ctk f16 -ctv f16 -fa off -r 3 -o json > logs/vk-bench.json 2> logs/vk-bench.log。

SYCL 使用相同命令，替換路徑、裝置與輸出檔名。pp 是批次讀入 512 tokens，tg 是生成 128 tokens；-d 4096 先填入 4,096 tokens 再做該測項。pp 與 tg 是分開的測試，不要將同一次輸出的兩列認成一段真實對話。固定 f16 KV 與關閉 Flash Attention，先比較共同設定；之後兩邊各自開啟優化，要另列一組。

保留 JSON 中每次樣本、平均值與標準差；三次只用來找明顯問題，不做尾端延遲保證。讓兩個後端交錯順序，關閉其他 GPU 工作，另記第一次啟動。成功後再試 -pg 512,128 的讀題接生成測項，與真實文字任務分欄保存。

記憶體也有不同口徑：載入 log 的 model／KV／compute buffer 是配置資訊；Ubuntu 的 GNU time /usr/bin/time -v 的 Maximum resident set size 是程序主記憶體 RSS，並非顯存。顯卡總占用另外用已能讀取這張 Arc 的監測工具取樣，寫下工具、間隔與閒置基線。取不到的欄位填「未量測」，不拿 log buffer 加總冒充整張卡峰值。

完整任務怎麼量？用同一份文件走到底

llama-bench 的計時不包含分詞與取樣，所以再用一份不含私人資料的文件做端到端任務。將同一文本保存成 prompt.txt，末尾問一個能核對的問題，例如「生效日期是哪天？引用原句」。先寫答案，再要求兩邊回答。

執行 /usr/bin/time -v -o logs/vk-task.time ./build-vulkan/bin/llama-completion -m "$MODEL" --device "$VK_DEV" -sm none -ngl 99 -c 8192 -b 512 -ub 128 -t 4 -fa off --fit off -no-cnv --temp 0 -f prompt.txt -n 256 > logs/vk-task.txt 2> logs/vk-task.log；第二輪改成 SYCL 路徑、裝置與檔名。查看實際輸入與生成 token 數、是否提前停止，以及日誌有無截斷或容量錯誤。256 是輸出上限；若答案尚未完成，這一輪不能判成功。

time 的 elapsed 包含該程序啟動、載入與執行到退出，是這份 CLI 任務的完整耗時；它不是常駐 API 的首字等待。短文本用 2,048 窗口，長文本用 8,192 窗口，同一長度的兩邊設定相同，輸入要留出答案空間。每個長度都驗正確引用、漏答、亂補與退出碼；品質不過，最快的一筆也不入選。想延伸到常駐服務，先讀 同檔換 Runtime 的公平比較。

三種失敗演練：找到原因，也留下還原路線

① 找不到 Arc：從哪一層消失？

先比較 lspci -nnk、vulkaninfo --summary、sycl-ls 與兩個 --list-devices。作業系統看得到、某 API 看不到，就查該 API runtime；API 看得到、binary 看不到，就查建置設定與載入函式庫。遇到 libsycl.so 載入錯誤，先重新 source oneAPI 再列裝置。每次只修一層，保存修前修後結果。

② 顯存不足：把容量變更當成新設定

長文失敗時，先回到已通過的短窗口。再一次只減少窗口、batch 或 GPU 層數的一項，記下新值與 CPU／GPU 配置。不要為了演練故意下載更大的模型或把機器推到記憶體耗盡；現有長測項碰到上限，就足以記錄失敗邊界。權重之外還有 KV 與暫存，本機 LLM 顯存指南 能幫你理解差額。

③ 主記憶體 fallback：仍能回答，代價在哪裡？

此版本 SYCL 建置設定 列出 GGML_SYCL_HOST_MEM_FALLBACK：針對量化權重重排時的 device allocation 失敗，可改用 host memory，文件列 Linux 核心 6.8 以上條件；並不是通用的「所有顯存不足都會救回」。本文初始建置已關掉它。

若要比較這項行為，保留原 build-sycl，將同一組 CMake 指令的目錄改成 build-sycl-fallback，只把此旗標改為 ON，重新建置、列裝置，再跑相同任務。遇到該路徑時，官方實作 會記錄 using host memory fallback。保存這行、RAM 與任務時間；未觸發就記「本輪未觸發」，不要預填成功。

這和 CPU offload 是不同欄位：後者是部分工作留在 CPU，host memory fallback 則描述該配置路徑使用主記憶體。GPU 使用率上升，仍無法單獨證明所有資料留在顯存。另做純 CPU 對照時用 --device none，而非只用 -ngl 0；官方建置文件 明說後者仍可能讓 GPU 加速部分工作。

怎麼保留後端？照自己的用途做決定

• 只有一條能找到 Arc 並穩定交付：先保留這條；另一條留待定位錯誤，不給失敗跑次填速度。
• 兩條都過：短聊天看實際短任務時間，長文件看長深度、完整耗時與正確引用；優勢可能落在不同工作。
• 兩條都過，但差異小於重跑波動：優先維護簡單、版本容易固定的組合，之後用更多題目再判。
• 長文或 fallback 才能過：記成容量受限配置，保留已通過的短窗口作還原；不要把它與全顯存設定共用排名。

還原不需要移除整套驅動：先換回已保存的 build 路徑、CMakeCache、模型雜湊與啟動命令；在新終端 source 所需環境，再列裝置。若改過篩選器，用 unset ONEAPI_DEVICE_SELECTOR 清除本終端的設定。這只清除裝置篩選，不會卸載 Toolkit；最後重做小提示與品質驗收。

常見問題：八個新手快答

1. 可以看見回答，就代表 Arc 在工作嗎？

先看日誌。回答可能由不同配置產生；核對裝置、offload 與 buffer，再驗輸出。

2. SYCL 一定比 Vulkan 快嗎？

不預設冠軍。使用同檔、同機、同深度與相同測項比較，短文與長文也各自報告。

3. Vulkan0 和 SYCL0 是同一張卡嗎？

先看名稱。兩套列舉有自己的順序，篩選後也要重新核對。

4. -c 8192 就是在測 8K 長文嗎？

不是。那是窗口容量；輸入內容或 benchmark 深度要另外設定。

5. -ngl 99 代表 99% 都在 GPU 嗎？

不是。它是層數請求，實際配置要讀載入紀錄。

6. GGUF 檔小於顯存，就會放得下嗎？

還要算 KV 與暫存。用實際啟動與長任務檢查容量，保留失敗紀錄。

7. 主記憶體 fallback 等於 CPU 全接手嗎？

兩項分開記。先看是哪個 allocation 走 host memory，再看工作與 buffer 的分配。

8. 新手今天只做一件事，做什麼？

先保存兩份裝置清單與一份成功的小提示 log。確認是自己的 Arc，再增加長度與量測。

給新手的三個重點

• 先確認在哪裡算：裝置名稱與載入紀錄比風扇聲可靠。
• 先固定再變更：兩個 build、同一份模型，優化或 fallback 都另列配置。
• 先做對再做快：你的文件、你的答案規格、你的完整耗時，決定要留下哪條路線。