<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Intel on Tarragon</title><link>https://tarrragon.github.io/blog/tags/intel/</link><description>Recent content in Intel on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Tue, 12 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/intel/index.xml" rel="self" type="application/rss+xml"/><item><title>5.6 GPU 廠商差異</title><link>https://tarrragon.github.io/blog/llm/05-discrete-gpu/gpu-vendor-differences/</link><pubDate>Tue, 12 May 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/llm/05-discrete-gpu/gpu-vendor-differences/</guid><description>&lt;p>選 GPU 跑本地 LLM 不只看 &lt;a href="https://tarrragon.github.io/blog/llm/knowledge-cards/vram/" data-link-title="VRAM" data-link-desc="顯卡上的記憶體、跟系統 RAM 是兩塊獨立預算、決定能載入多大模型權重跟 KV cache">VRAM&lt;/a> 容量與 &lt;a href="https://tarrragon.github.io/blog/llm/knowledge-cards/memory-bandwidth/" data-link-title="Memory Bandwidth" data-link-desc="記憶體每秒能讀寫多少 bytes：決定本地 LLM 生字速度的真正瓶頸">memory bandwidth&lt;/a>、工具鏈支援度同樣重要。NVIDIA / AMD / Intel 三家廠商在 llama.cpp 生態的位置不同、&lt;a href="https://tarrragon.github.io/blog/llm/knowledge-cards/gpu-compute-backend/" data-link-title="GPU Compute Backend" data-link-desc="GPU 加速計算的底層 API 介面（CUDA / ROCm / Vulkan / Metal / SYCL）、決定推論軟體能否用 GPU 跑得快">GPU compute backend&lt;/a> 中 CUDA 之外的選項仍在演進。本章整理三家在 2026 年 5 月的相對位置、跟選卡時值得考慮的判讀軸；多卡互連的議題見 &lt;a href="https://tarrragon.github.io/blog/llm/knowledge-cards/nvlink/" data-link-title="NVLink" data-link-desc="NVIDIA 多 GPU 之間的高速互連介面、提供比 PCIe 更高的卡間頻寬、消費級 RTX 系列普遍不支援">NVLink&lt;/a> 跟 &lt;a href="https://tarrragon.github.io/blog/llm/knowledge-cards/pcie/" data-link-title="PCIe" data-link-desc="PC 上連接 GPU 跟主機板的高速序列匯流排、影響模型載入速度跟 MoE 卸載時的推論吞吐">PCIe&lt;/a>。本章不重複 &lt;a href="https://tarrragon.github.io/blog/llm/knowledge-cards/unified-memory/" data-link-title="Unified Memory Architecture" data-link-desc="Apple Silicon 讓 CPU / GPU / NE 共用同一塊記憶體：跑大模型的優勢來源">統一記憶體&lt;/a> 的 Mac 場景、改聚焦 PC 獨立 VRAM 的廠商工具鏈差異。&lt;/p>
&lt;blockquote>
&lt;p>&lt;strong>事實查核註&lt;/strong>：GPU 工具鏈的支援度依 driver 版本、llama.cpp release 與廠商策略快速演進、本章描述為 2026 年 5 月的社群常見回報、建議引用前查閱對應 backend 的官方文件、&lt;a href="https://github.com/ggml-org/llama.cpp/releases">llama.cpp release notes&lt;/a> 跟自己硬體的實測。&lt;/p>&lt;/blockquote>
&lt;h2 id="本章目標">本章目標&lt;/h2>
&lt;ol>
&lt;li>知道 NVIDIA CUDA、AMD ROCm、Intel SYCL、跨平台 Vulkan 各自的成熟度。&lt;/li>
&lt;li>認識「工具鏈支援度」相對「硬體規格」對本地 LLM 體驗的重要性。&lt;/li>
&lt;li>在選卡時、能用「工具鏈 × 規格 × 預算」三軸做判讀。&lt;/li>
&lt;li>認識常見的混合場景（雲端 + 本地）。&lt;/li>
&lt;/ol>
&lt;h2 id="nvidia-cuda當前生態預設">NVIDIA CUDA：當前生態預設&lt;/h2>
&lt;p>NVIDIA GPU + CUDA backend 是 2026 年本地 LLM 社群的事實預設。原因不是「規格最好」、而是「工具鏈最成熟」：&lt;/p>
&lt;ol>
&lt;li>&lt;strong>llama.cpp CUDA backend 開發最久、PR 跟 issue 數量最多&lt;/strong>：新功能（新量化、flash attention 改進、speculative decoding 等）通常先在 CUDA backend 落地。&lt;/li>
&lt;li>&lt;strong>driver 跟 CUDA toolkit 對齊明確&lt;/strong>：driver 版本對應 CUDA 版本的表清楚、出問題容易查。&lt;/li>
&lt;li>&lt;strong>社群實測案例多&lt;/strong>：Reddit、HuggingFace forum、GitHub issue 上、絕大多數 benchmark 跟調參討論基於 CUDA。&lt;/li>
&lt;li>&lt;strong>上層工具（Ollama、LM Studio）優先支援&lt;/strong>：新版本通常先 CUDA、再 Vulkan、再 ROCm。&lt;/li>
&lt;/ol>
&lt;p>社群常見回報的 NVIDIA 卡分級（依 VRAM 容量為主、寫 code 場景）：&lt;/p>
&lt;table>
 &lt;thead>
 &lt;tr>
 &lt;th>等級&lt;/th>
 &lt;th>代表卡型&lt;/th>
 &lt;th>適用情境&lt;/th>
 &lt;/tr>
 &lt;/thead>
 &lt;tbody>
 &lt;tr>
 &lt;td>入門&lt;/td>
 &lt;td>RTX 5060 8GB / RTX 4060 8GB&lt;/td>
 &lt;td>試水溫、跑 7B 級模型&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>主流（甜蜜點）&lt;/td>
 &lt;td>RTX 5060 Ti 16GB / RTX 5070 Ti 16GB&lt;/td>
 &lt;td>30B MoE 卸載、寫 code 場景社群常見起點&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>進階&lt;/td>
 &lt;td>RTX 4090 24GB / RTX 5080 16GB&lt;/td>
 &lt;td>32B Dense 全載 / 70B MoE 卸載&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>旗艦&lt;/td>
 &lt;td>RTX 5090 32GB&lt;/td>
 &lt;td>70B Dense Q4 全載、長 context、多模型併存&lt;/td>
 &lt;/tr>
 &lt;tr>
 &lt;td>上一代二手&lt;/td>
 &lt;td>RTX 3090 24GB&lt;/td>
 &lt;td>二手市場價格可能更友善、CUDA 支援度仍佳&lt;/td>
 &lt;/tr>
 &lt;/tbody>
&lt;/table>
&lt;p>&lt;strong>選卡時的常見軸&lt;/strong>：&lt;/p></description><content:encoded><![CDATA[<p>選 GPU 跑本地 LLM 不只看 <a href="/blog/llm/knowledge-cards/vram/" data-link-title="VRAM" data-link-desc="顯卡上的記憶體、跟系統 RAM 是兩塊獨立預算、決定能載入多大模型權重跟 KV cache">VRAM</a> 容量與 <a href="/blog/llm/knowledge-cards/memory-bandwidth/" data-link-title="Memory Bandwidth" data-link-desc="記憶體每秒能讀寫多少 bytes：決定本地 LLM 生字速度的真正瓶頸">memory bandwidth</a>、工具鏈支援度同樣重要。NVIDIA / AMD / Intel 三家廠商在 llama.cpp 生態的位置不同、<a href="/blog/llm/knowledge-cards/gpu-compute-backend/" data-link-title="GPU Compute Backend" data-link-desc="GPU 加速計算的底層 API 介面（CUDA / ROCm / Vulkan / Metal / SYCL）、決定推論軟體能否用 GPU 跑得快">GPU compute backend</a> 中 CUDA 之外的選項仍在演進。本章整理三家在 2026 年 5 月的相對位置、跟選卡時值得考慮的判讀軸；多卡互連的議題見 <a href="/blog/llm/knowledge-cards/nvlink/" data-link-title="NVLink" data-link-desc="NVIDIA 多 GPU 之間的高速互連介面、提供比 PCIe 更高的卡間頻寬、消費級 RTX 系列普遍不支援">NVLink</a> 跟 <a href="/blog/llm/knowledge-cards/pcie/" data-link-title="PCIe" data-link-desc="PC 上連接 GPU 跟主機板的高速序列匯流排、影響模型載入速度跟 MoE 卸載時的推論吞吐">PCIe</a>。本章不重複 <a href="/blog/llm/knowledge-cards/unified-memory/" data-link-title="Unified Memory Architecture" data-link-desc="Apple Silicon 讓 CPU / GPU / NE 共用同一塊記憶體：跑大模型的優勢來源">統一記憶體</a> 的 Mac 場景、改聚焦 PC 獨立 VRAM 的廠商工具鏈差異。</p>
<blockquote>
<p><strong>事實查核註</strong>：GPU 工具鏈的支援度依 driver 版本、llama.cpp release 與廠商策略快速演進、本章描述為 2026 年 5 月的社群常見回報、建議引用前查閱對應 backend 的官方文件、<a href="https://github.com/ggml-org/llama.cpp/releases">llama.cpp release notes</a> 跟自己硬體的實測。</p></blockquote>
<h2 id="本章目標">本章目標</h2>
<ol>
<li>知道 NVIDIA CUDA、AMD ROCm、Intel SYCL、跨平台 Vulkan 各自的成熟度。</li>
<li>認識「工具鏈支援度」相對「硬體規格」對本地 LLM 體驗的重要性。</li>
<li>在選卡時、能用「工具鏈 × 規格 × 預算」三軸做判讀。</li>
<li>認識常見的混合場景（雲端 + 本地）。</li>
</ol>
<h2 id="nvidia-cuda當前生態預設">NVIDIA CUDA：當前生態預設</h2>
<p>NVIDIA GPU + CUDA backend 是 2026 年本地 LLM 社群的事實預設。原因不是「規格最好」、而是「工具鏈最成熟」：</p>
<ol>
<li><strong>llama.cpp CUDA backend 開發最久、PR 跟 issue 數量最多</strong>：新功能（新量化、flash attention 改進、speculative decoding 等）通常先在 CUDA backend 落地。</li>
<li><strong>driver 跟 CUDA toolkit 對齊明確</strong>：driver 版本對應 CUDA 版本的表清楚、出問題容易查。</li>
<li><strong>社群實測案例多</strong>：Reddit、HuggingFace forum、GitHub issue 上、絕大多數 benchmark 跟調參討論基於 CUDA。</li>
<li><strong>上層工具（Ollama、LM Studio）優先支援</strong>：新版本通常先 CUDA、再 Vulkan、再 ROCm。</li>
</ol>
<p>社群常見回報的 NVIDIA 卡分級（依 VRAM 容量為主、寫 code 場景）：</p>
<table>
  <thead>
      <tr>
          <th>等級</th>
          <th>代表卡型</th>
          <th>適用情境</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>入門</td>
          <td>RTX 5060 8GB / RTX 4060 8GB</td>
          <td>試水溫、跑 7B 級模型</td>
      </tr>
      <tr>
          <td>主流（甜蜜點）</td>
          <td>RTX 5060 Ti 16GB / RTX 5070 Ti 16GB</td>
          <td>30B MoE 卸載、寫 code 場景社群常見起點</td>
      </tr>
      <tr>
          <td>進階</td>
          <td>RTX 4090 24GB / RTX 5080 16GB</td>
          <td>32B Dense 全載 / 70B MoE 卸載</td>
      </tr>
      <tr>
          <td>旗艦</td>
          <td>RTX 5090 32GB</td>
          <td>70B Dense Q4 全載、長 context、多模型併存</td>
      </tr>
      <tr>
          <td>上一代二手</td>
          <td>RTX 3090 24GB</td>
          <td>二手市場價格可能更友善、CUDA 支援度仍佳</td>
      </tr>
  </tbody>
</table>
<p><strong>選卡時的常見軸</strong>：</p>
<ol>
<li><strong>VRAM 容量決定模型上限</strong>：16GB 起步可跑 30B MoE 卸載、24GB 跑 32B Dense、32GB 跑 70B Dense。</li>
<li><strong>VRAM 頻寬決定生字速度上限</strong>：同 VRAM 容量下、頻寬接近兩倍的卡（如 5070 Ti 對 5060 Ti）生字速度通常顯著差。</li>
<li><strong>CUDA compute capability</strong>：影響某些優化能否啟用、新世代卡通常有額外指令支援。</li>
<li><strong>driver 長期支援</strong>：較新世代卡的 driver 支援週期通常較長、適合長時間用。</li>
</ol>
<h2 id="amd-rocm-與-radeon">AMD ROCm 與 Radeon</h2>
<p>AMD GPU 在 llama.cpp 生態的位置：ROCm backend 在演進、Vulkan backend 是跨平台 fallback。</p>
<h3 id="rocm-backend">ROCm backend</h3>
<p>ROCm（Radeon Open Compute）是 AMD 的 GPU 計算平台、定位類似 CUDA。社群常見回報的當前狀態：</p>
<ol>
<li><strong>Linux 支援度較 Windows 成熟</strong>：ROCm 在 Linux 上發展時間較長、Windows 版本相對年輕。</li>
<li><strong>支援 GPU 清單</strong>：ROCm 對「官方支援」的 GPU 清單有明確限制、清單外的卡也許能跑、但走 unsupported 路徑。</li>
<li><strong>llama.cpp ROCm build 跟 CUDA build 的功能差異</strong>：多數核心功能跨 backend 一致、新功能 cherry-pick 速度通常稍慢於 CUDA。</li>
<li><strong>效能對比</strong>：同價格段、AMD 卡的 VRAM 容量有時較大；但生字速度依模型跟設定變化、社群回報的 NVIDIA / AMD 對比結果不一致、需自己硬體實測。</li>
</ol>
<h3 id="vulkan-backend">Vulkan backend</h3>
<p>Vulkan 是跨平台 GPU API、llama.cpp 的 Vulkan backend 適合：</p>
<ol>
<li><strong>AMD GPU on Windows</strong>：ROCm Windows 不穩或不支援時的選項。</li>
<li><strong>Intel ARC</strong>：見下節。</li>
<li><strong>跨平台 fallback</strong>：希望同一份 binary 跑在多種 GPU 上。</li>
</ol>
<p>社群常見回報：Vulkan backend 的 throughput 通常較同硬體的 CUDA / ROCm backend 低、但通用性高。</p>
<h3 id="選-amd-卡的判讀">選 AMD 卡的判讀</h3>
<table>
  <thead>
      <tr>
          <th>情境</th>
          <th>建議</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>Linux 主力使用者、想避開 NVIDIA driver</td>
          <td>AMD + ROCm on Linux 是合理選擇、先確認卡型在 ROCm 支援清單</td>
      </tr>
      <tr>
          <td>Windows 主力使用者</td>
          <td>NVIDIA + CUDA 仍是社群預設較順的路徑</td>
      </tr>
      <tr>
          <td>同價格段、AMD VRAM 容量明顯較大</td>
          <td>評估「容量優勢 vs 工具鏈成本」、用自己工作流校準</td>
      </tr>
      <tr>
          <td>已有 AMD 卡、想試本地 LLM</td>
          <td>直接試 Vulkan / ROCm backend、看是否符合需求</td>
      </tr>
  </tbody>
</table>
<h2 id="intel-arc">Intel ARC</h2>
<p>Intel 的獨立 GPU 系列 ARC（A 系列、後續預期 B 系列）在 llama.cpp 生態仍處於相對年輕的階段：</p>
<ol>
<li><strong>可用 backend</strong>：Vulkan（通用）、SYCL / OpenVINO（Intel 特化）。</li>
<li><strong>VRAM 容量</strong>：ARC A770 16GB 的 VRAM 容量在價格段內競爭力較強。</li>
<li><strong>工具鏈成熟度</strong>：社群實測案例較 NVIDIA / AMD 少、預期需要較多自己摸索。</li>
<li><strong>driver 演進</strong>：Intel ARC driver 在 2026 年仍持續演進、不同版本的 throughput 可能差異較大。</li>
</ol>
<p>選 Intel ARC 的合理情境：</p>
<ol>
<li>想試「相對冷門但價格友善」的選項。</li>
<li>已有 Intel 平台、想保持廠商一致。</li>
<li>不介意花時間自己調工具鏈設定。</li>
</ol>
<p>對「想最快跑起來、最少調參」的使用者、ARC 不是最順的選擇。</p>
<h2 id="工具鏈--規格--預算的判讀框架">工具鏈 × 規格 × 預算的判讀框架</h2>
<p>選卡時的三軸框架：</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="ln">1</span><span class="cl">工具鏈支援度（CUDA &gt; ROCm &gt; Vulkan &gt; SYCL）
</span></span><span class="line"><span class="ln">2</span><span class="cl">  ×
</span></span><span class="line"><span class="ln">3</span><span class="cl">硬體規格（VRAM 容量 + VRAM 頻寬 + CUDA core / CU 數量）
</span></span><span class="line"><span class="ln">4</span><span class="cl">  ×
</span></span><span class="line"><span class="ln">5</span><span class="cl">預算（含後續電費、機殼散熱、電源升級）</span></span></code></pre></div><p>判讀順序：</p>
<ol>
<li><strong>先確認工具鏈支援度符合自己的折騰意願</strong>：怕折騰選 NVIDIA、樂於折騰可考慮 AMD / Intel。</li>
<li><strong>再依預算選 VRAM 容量級別</strong>：16GB 起步、24GB 進階、32GB 旗艦。</li>
<li><strong>同容量下選頻寬較高的卡</strong>：對生字速度影響直接。</li>
<li><strong>預留升級空間</strong>：機殼散熱、電源、PCIe lane 配置會影響後續多卡或換卡的選擇。</li>
</ol>
<h2 id="雲端--本地的混合場景">雲端 + 本地的混合場景</h2>
<p>本地 LLM 不必獨自解決所有任務、雲端 + 本地的混合是社群多數使用者的實際做法：</p>
<table>
  <thead>
      <tr>
          <th>任務類型</th>
          <th>適合本地</th>
          <th>適合雲端</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>補完、行內編輯（高頻、短回答）</td>
          <td>本地反應快、不消耗 API quota</td>
          <td>雲端 latency 較高、成本累積</td>
      </tr>
      <tr>
          <td>跨檔案重構、設計討論</td>
          <td>視本地模型能力</td>
          <td>旗艦模型（Claude、GPT-5）能力較強</td>
      </tr>
      <tr>
          <td>隱私敏感內容、未公開 codebase</td>
          <td>本地 prompt 不離開機器</td>
          <td>視服務的資料政策</td>
      </tr>
      <tr>
          <td>試新 prompt、調 prompt 工程</td>
          <td>本地快速迭代、無 quota 壓力</td>
          <td>雲端做最終驗證</td>
      </tr>
      <tr>
          <td>一次性 / 偶爾的複雜任務</td>
          <td>投資本地硬體可能不划算</td>
          <td>雲端按使用量付費較划算</td>
      </tr>
  </tbody>
</table>
<p>社群常見的混合做法：本地跑 30B 級 MoE 處理日常補完、跨檔案重構或設計討論切到雲端旗艦。Continue.dev 等工具支援同時設定多個 model、可以快速切換、見 <a href="/blog/llm/01-local-llm-services/vscode-continue-integration/" data-link-title="1.3 VS Code &#43; Continue.dev 整合" data-link-desc="安裝 Continue 擴充套件、config.json 設定、Cmd&#43;L 對話 / Cmd&#43;I 行內編輯快捷鍵">1.3 VS Code + Continue.dev 整合</a>。</p>
<h2 id="給讀者的選卡判讀">給讀者的選卡判讀</h2>
<p>整合本章與 <a href="/blog/llm/05-discrete-gpu/vram-ram-budget/" data-link-title="5.0 VRAM &#43; RAM 分層預算" data-link-desc="PC 獨立 GPU 場景的記憶體預算判讀：VRAM 是快的世界、RAM 是大的世界、PCIe 把兩個世界連起來">5.0 VRAM + RAM 分層預算</a> 的建議：</p>
<ol>
<li><strong>NVIDIA 是當前社群預設</strong>：怕折騰、想最大化「跑得起來」概率、選 NVIDIA。</li>
<li><strong>VRAM 16GB 是常見起點</strong>：16GB VRAM + 64GB RAM 配 30B MoE 卸載、是 2026 年寫 code 場景的常見配置。</li>
<li><strong>頻寬比容量更影響日常體感</strong>：同容量下、頻寬接近兩倍的卡（如 5070 Ti 對 5060 Ti）日常生字速度差異明顯。</li>
<li><strong>二手卡也是選項</strong>：RTX 3090 24GB 二手市場價格依在地市場變化、CUDA 支援度仍佳、適合預算敏感但想要 24GB VRAM 的使用者。</li>
<li><strong>多卡不是優先升級方向</strong>：單人寫 code 場景下、單卡 + 良好設定通常勝過雙卡入門配置。</li>
</ol>
<h2 id="下一步">下一步</h2>
<p>本章是模組五的最後一章。下一步可以回到 <a href="/blog/llm/05-discrete-gpu/" data-link-title="模組五：Windows / Linux &#43; 獨立 GPU" data-link-desc="消費級 PC（Windows / Linux &#43; NVIDIA / AMD 獨立 GPU）跑本地 LLM 的硬體判讀、MoE CPU 卸載、KV cache 量化與 llama.cpp 調參">模組五 _index</a> 看其他章節、或進入 <a href="/blog/llm/04-applications/" data-link-title="模組四：LLM 應用層原理" data-link-desc="Prompt 技術光譜、RAG、tool use、agent、應用層協議、人機協作、multi-agent、workflow 編排、eval 設計：跨工具不變的概念地圖">模組四 應用層原理</a> 看 LLM 作為系統元件的設計取捨。</p>
]]></content:encoded></item></channel></rss>