<?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>Ram on Tarragon</title><link>https://tarrragon.github.io/blog/tags/ram/</link><description>Recent content in Ram 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/ram/index.xml" rel="self" type="application/rss+xml"/><item><title>5.0 VRAM + RAM 分層預算</title><link>https://tarrragon.github.io/blog/llm/05-discrete-gpu/vram-ram-budget/</link><pubDate>Tue, 12 May 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/llm/05-discrete-gpu/vram-ram-budget/</guid><description>&lt;p>PC 場景跑本地 LLM 的判讀模型本質跟 &lt;a href="https://tarrragon.github.io/blog/llm/00-foundations/hardware-memory-budget/" data-link-title="0.5 Apple Silicon 記憶體預算" data-link-desc="記憶體決定能跑什麼，Q4 量化下的可運作模型對照與系統保留">Mac 統一記憶體&lt;/a> 不同：Mac 是一塊預算切系統 / 模型 / &lt;a href="https://tarrragon.github.io/blog/llm/knowledge-cards/kv-cache/" data-link-title="KV Cache" data-link-desc="已處理 token 的 attention 中間結果暫存：避免重算、加速後續生成">KV cache&lt;/a>、PC 是 &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> 跟系統 RAM 兩塊&lt;strong>分層預算&lt;/strong>、靠 &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> 連起來。本章把「16GB 5060 Ti 能跑 30B 嗎」這類含糊說法、換成可操作的兩塊預算判讀。生字速度上限主要受 &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> 影響、跟 &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 場景判讀軸不同。&lt;/p>
&lt;p>讀完本章後、你可以對自己這台 PC 直接回答：能跑哪些模型、要不要做 MoE 卸載、KV cache 該量化到哪一級、context 能開多大、系統 RAM 容量該不該升級。&lt;/p>
&lt;h2 id="本章目標">本章目標&lt;/h2>
&lt;p>讀完本章後、你應該能：&lt;/p>
&lt;ol>
&lt;li>看 PC 規格（VRAM + RAM）立刻知道能跑哪一級的模型、需不需要卸載。&lt;/li>
&lt;li>理解為什麼 16GB VRAM + 64GB RAM 跑 30B MoE 比跑 14B Dense 全載 VRAM 划算。&lt;/li>
&lt;li>判讀 KV cache 量化跟 context 長度的權衡。&lt;/li>
&lt;li>判斷自己這台 PC 適不適合跑本地 LLM、瓶頸在 VRAM 還是 RAM。&lt;/li>
&lt;/ol>
&lt;h2 id="pc-記憶體預算的基本算式">PC 記憶體預算的基本算式&lt;/h2>
&lt;p>PC 跑本地 LLM 的預算拆成兩塊、各有自己的容量上限：&lt;/p>





&lt;div class="highlight">&lt;pre tabindex="0" class="chroma">&lt;code class="language-text" data-lang="text">&lt;span class="line">&lt;span class="ln">1&lt;/span>&lt;span class="cl">VRAM = 顯卡記憶體（GDDR6/7）= 高頻寬區
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln">2&lt;/span>&lt;span class="cl"> └── 通常需放：當前活躍模型層 + KV cache + 推論中間結果
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln">3&lt;/span>&lt;span class="cl">
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln">4&lt;/span>&lt;span class="cl">系統 RAM = 主機板上的 DDR4/5 = 高容量區
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln">5&lt;/span>&lt;span class="cl"> └── 可以放：MoE 不活躍專家層（透過 --n-cpu-moe）、暫存權重、context cache
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln">6&lt;/span>&lt;span class="cl"> └── 通常需保留：作業系統 + 應用程式 + GPU driver pinned memory
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln">7&lt;/span>&lt;span class="cl">
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln">8&lt;/span>&lt;span class="cl">PCIe = 兩塊預算之間的橋
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln">9&lt;/span>&lt;span class="cl"> └── 5.0 x16 廠商標稱單向約 64 GB/s、模型載入時較常成為瓶頸、推論時通常較少&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>兩塊預算各自的估算原則（具體數值依硬體世代、廠商規格與驅動版本而變化、本章引用的數字以廠商規格表為主、實際吞吐受系統配置影響）：&lt;/p>
&lt;ol>
&lt;li>&lt;strong>VRAM 容量&lt;/strong>：決定能放多少模型層。Dense 模型若要生字快、所有層都該在 VRAM；MoE 模型可以只放「共用層 + 部分專家」、其餘走 RAM。&lt;/li>
&lt;li>&lt;strong>VRAM 頻寬&lt;/strong>：影響生字速度上限。常見消費級 NVIDIA 卡的廠商標稱頻寬（向廠商規格表查驗）大致落在數百 GB/s 到約 1 TB/s 級的區間（如 RTX 5060 Ti 16GB 標稱約 448 GB/s、RTX 5070 Ti 約 896 GB/s）；生字 t/s 約等於「VRAM 頻寬 ÷ 模型每 token 讀取的 bytes」、但實際吞吐還受 CUDA backend、量化方式與 batch size 影響。&lt;/li>
&lt;li>&lt;strong>系統 RAM 容量&lt;/strong>：影響 MoE 卸載與多模型併存的彈性。對 16GB VRAM 卡而言、64GB DDR5 通常足以支撐重度 MoE 卸載、128GB 對多模型併存或長 context cache 更從容、32GB 則會限縮可卸載的層數。&lt;/li>
&lt;li>&lt;strong>系統 RAM 頻寬&lt;/strong>：影響卸載到 CPU 的層走多快。DDR5 6000 雙通道的標稱頻寬約 96 GB/s（依主機板、CMK 模組與時序變動）、相對 VRAM 慢約一個量級、所以卸載層數要跟可接受的生字速度損失一起調。&lt;/li>
&lt;li>&lt;strong>PCIe 頻寬&lt;/strong>：模型載入時通常是瓶頸、單人推論時較少成為主要瓶頸（除非每 token 都需要把大量卸載權重拉回 VRAM）。&lt;/li>
&lt;/ol>
&lt;h2 id="pc-配置與可運作模型對照">PC 配置與可運作模型對照&lt;/h2>
&lt;p>下表整理 2026 年 5 月常見消費級 NVIDIA GPU 加上不同 RAM 容量、可運作模型的數量級對照。體感標籤是社群常見回報的相對描述、實際因 llama.cpp / Ollama 版本、CUDA backend、模型量化版本、&lt;code>--n-cpu-moe&lt;/code> 設定與工作流類型而變動、需自行實測校準。&lt;/p></description><content:encoded><![CDATA[<p>PC 場景跑本地 LLM 的判讀模型本質跟 <a href="/blog/llm/00-foundations/hardware-memory-budget/" data-link-title="0.5 Apple Silicon 記憶體預算" data-link-desc="記憶體決定能跑什麼，Q4 量化下的可運作模型對照與系統保留">Mac 統一記憶體</a> 不同：Mac 是一塊預算切系統 / 模型 / <a href="/blog/llm/knowledge-cards/kv-cache/" data-link-title="KV Cache" data-link-desc="已處理 token 的 attention 中間結果暫存：避免重算、加速後續生成">KV cache</a>、PC 是 <a href="/blog/llm/knowledge-cards/vram/" data-link-title="VRAM" data-link-desc="顯卡上的記憶體、跟系統 RAM 是兩塊獨立預算、決定能載入多大模型權重跟 KV cache">VRAM</a> 跟系統 RAM 兩塊<strong>分層預算</strong>、靠 <a href="/blog/llm/knowledge-cards/pcie/" data-link-title="PCIe" data-link-desc="PC 上連接 GPU 跟主機板的高速序列匯流排、影響模型載入速度跟 MoE 卸載時的推論吞吐">PCIe</a> 連起來。本章把「16GB 5060 Ti 能跑 30B 嗎」這類含糊說法、換成可操作的兩塊預算判讀。生字速度上限主要受 <a href="/blog/llm/knowledge-cards/memory-bandwidth/" data-link-title="Memory Bandwidth" data-link-desc="記憶體每秒能讀寫多少 bytes：決定本地 LLM 生字速度的真正瓶頸">memory bandwidth</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 場景判讀軸不同。</p>
<p>讀完本章後、你可以對自己這台 PC 直接回答：能跑哪些模型、要不要做 MoE 卸載、KV cache 該量化到哪一級、context 能開多大、系統 RAM 容量該不該升級。</p>
<h2 id="本章目標">本章目標</h2>
<p>讀完本章後、你應該能：</p>
<ol>
<li>看 PC 規格（VRAM + RAM）立刻知道能跑哪一級的模型、需不需要卸載。</li>
<li>理解為什麼 16GB VRAM + 64GB RAM 跑 30B MoE 比跑 14B Dense 全載 VRAM 划算。</li>
<li>判讀 KV cache 量化跟 context 長度的權衡。</li>
<li>判斷自己這台 PC 適不適合跑本地 LLM、瓶頸在 VRAM 還是 RAM。</li>
</ol>
<h2 id="pc-記憶體預算的基本算式">PC 記憶體預算的基本算式</h2>
<p>PC 跑本地 LLM 的預算拆成兩塊、各有自己的容量上限：</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">VRAM = 顯卡記憶體（GDDR6/7）= 高頻寬區
</span></span><span class="line"><span class="ln">2</span><span class="cl">  └── 通常需放：當前活躍模型層 + KV cache + 推論中間結果
</span></span><span class="line"><span class="ln">3</span><span class="cl">
</span></span><span class="line"><span class="ln">4</span><span class="cl">系統 RAM = 主機板上的 DDR4/5 = 高容量區
</span></span><span class="line"><span class="ln">5</span><span class="cl">  └── 可以放：MoE 不活躍專家層（透過 --n-cpu-moe）、暫存權重、context cache
</span></span><span class="line"><span class="ln">6</span><span class="cl">  └── 通常需保留：作業系統 + 應用程式 + GPU driver pinned memory
</span></span><span class="line"><span class="ln">7</span><span class="cl">
</span></span><span class="line"><span class="ln">8</span><span class="cl">PCIe = 兩塊預算之間的橋
</span></span><span class="line"><span class="ln">9</span><span class="cl">  └── 5.0 x16 廠商標稱單向約 64 GB/s、模型載入時較常成為瓶頸、推論時通常較少</span></span></code></pre></div><p>兩塊預算各自的估算原則（具體數值依硬體世代、廠商規格與驅動版本而變化、本章引用的數字以廠商規格表為主、實際吞吐受系統配置影響）：</p>
<ol>
<li><strong>VRAM 容量</strong>：決定能放多少模型層。Dense 模型若要生字快、所有層都該在 VRAM；MoE 模型可以只放「共用層 + 部分專家」、其餘走 RAM。</li>
<li><strong>VRAM 頻寬</strong>：影響生字速度上限。常見消費級 NVIDIA 卡的廠商標稱頻寬（向廠商規格表查驗）大致落在數百 GB/s 到約 1 TB/s 級的區間（如 RTX 5060 Ti 16GB 標稱約 448 GB/s、RTX 5070 Ti 約 896 GB/s）；生字 t/s 約等於「VRAM 頻寬 ÷ 模型每 token 讀取的 bytes」、但實際吞吐還受 CUDA backend、量化方式與 batch size 影響。</li>
<li><strong>系統 RAM 容量</strong>：影響 MoE 卸載與多模型併存的彈性。對 16GB VRAM 卡而言、64GB DDR5 通常足以支撐重度 MoE 卸載、128GB 對多模型併存或長 context cache 更從容、32GB 則會限縮可卸載的層數。</li>
<li><strong>系統 RAM 頻寬</strong>：影響卸載到 CPU 的層走多快。DDR5 6000 雙通道的標稱頻寬約 96 GB/s（依主機板、CMK 模組與時序變動）、相對 VRAM 慢約一個量級、所以卸載層數要跟可接受的生字速度損失一起調。</li>
<li><strong>PCIe 頻寬</strong>：模型載入時通常是瓶頸、單人推論時較少成為主要瓶頸（除非每 token 都需要把大量卸載權重拉回 VRAM）。</li>
</ol>
<h2 id="pc-配置與可運作模型對照">PC 配置與可運作模型對照</h2>
<p>下表整理 2026 年 5 月常見消費級 NVIDIA GPU 加上不同 RAM 容量、可運作模型的數量級對照。體感標籤是社群常見回報的相對描述、實際因 llama.cpp / Ollama 版本、CUDA backend、模型量化版本、<code>--n-cpu-moe</code> 設定與工作流類型而變動、需自行實測校準。</p>
<table>
  <thead>
      <tr>
          <th>GPU</th>
          <th>VRAM</th>
          <th>RAM 配置</th>
          <th>全載 VRAM 可跑 Dense</th>
          <th>配合 MoE 卸載可跑模型</th>
          <th>體感區段（社群回報）</th>
          <th>備註</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>RTX 4060 / 5060</td>
          <td>8GB</td>
          <td>16GB</td>
          <td>7B Q4</td>
          <td>14B MoE 卸載</td>
          <td>入門體驗</td>
          <td>對寫 code 的中大型任務通常仍須混用雲端</td>
      </tr>
      <tr>
          <td>RTX 4060 Ti / 5060 Ti</td>
          <td>16GB</td>
          <td>32GB</td>
          <td>14B Q4 / 20B Q3</td>
          <td>30B MoE 卸載部分專家層</td>
          <td>可日常使用</td>
          <td>MoE 卸載空間受 32GB RAM 限制</td>
      </tr>
      <tr>
          <td>RTX 4060 Ti / 5060 Ti</td>
          <td>16GB</td>
          <td>64GB</td>
          <td>14B Q4</td>
          <td>30B MoE Q4 + 重度卸載</td>
          <td>多數寫 code 任務流暢</td>
          <td>2026 年常被列為合理起點之一</td>
      </tr>
      <tr>
          <td>RTX 4070 Ti / 5070 Ti</td>
          <td>16GB</td>
          <td>64GB</td>
          <td>14B Q4</td>
          <td>30B MoE Q4 / 70B MoE Q3 卸載</td>
          <td>補完體感更接近即時</td>
          <td>VRAM 頻寬規格上接近 5060 Ti 兩倍</td>
      </tr>
      <tr>
          <td>RTX 4090</td>
          <td>24GB</td>
          <td>64GB</td>
          <td>32B Q4 / 70B Q3</td>
          <td>70B MoE Q4</td>
          <td>大型任務也流暢</td>
          <td>Dense 70B 可在 Q3 量化下全載</td>
      </tr>
      <tr>
          <td>RTX 5090</td>
          <td>32GB</td>
          <td>64GB ~ 128GB</td>
          <td>70B Q4</td>
          <td>100B+ MoE 卸載</td>
          <td>容量充裕</td>
          <td>適合 70B Dense 主力或多模型併存場景</td>
      </tr>
  </tbody>
</table>
<p>讀這張表要注意四件事：</p>
<ol>
<li><strong>「全載 VRAM」跟「卸載」是兩種選型</strong>。全載生字較快但模型較小、卸載生字較慢但能跑較大模型；MoE 結構讓兩者的速度差距小於 Dense 模型。</li>
<li><strong>量化等級可以調整</strong>。16GB VRAM 跑 30B MoE Q4 比跑 30B MoE Q5 留下更多 VRAM 餘量、給 KV cache 跟併發數使用。</li>
<li><strong>RAM 容量影響選型</strong>。32GB RAM 配 16GB VRAM 時、可卸載層數有限、能跑的最大 MoE 規模受限；64GB RAM 配 16GB VRAM 通常足以支撐 30B 級 MoE 的重度卸載。</li>
<li><strong>多卡升級建議在單卡跑穩後評估</strong>。雙 GPU 在 llama.cpp 上要設定 <a href="/blog/llm/knowledge-cards/llama-cpp-tensor-split/" data-link-title="llama.cpp Tensor Split" data-link-desc="llama.cpp 多 GPU 場景中把模型張量按比例切到多張卡上的權重分配機制">tensor split</a>、實際速度提升依模型與配置變化；消費級主機板的 PCIe lane 分配（常見一條 x16 + 一條 x4）也會影響多卡效益。建議先把單卡跑熟、再依瓶頸決定是否多卡。</li>
</ol>
<h2 id="為什麼-16gb-vram--64gb-ram-常被列為寫-code-場景的合理起點">為什麼 16GB VRAM + 64GB RAM 常被列為寫 code 場景的合理起點</h2>
<p>這個配置（RTX 5060 Ti 16GB / RTX 5070 Ti 16GB + 64GB DDR5）在 2026 年 5 月的 PC 本地 LLM 社群裡、常被作為「寫 code 用途」的價格效能比合理起點。對應的判讀軸有四條：</p>
<ol>
<li><strong>30B 級 MoE 模型在多數寫 code 任務已能勝任</strong>。Qwen3-30B-A3B 等 <a href="/blog/llm/knowledge-cards/moe/" data-link-title="Mixture of Experts (MoE)" data-link-desc="把 transformer 的 FFN 層拆成多個專家、每 token 只啟用少數、總參數大但每 token 計算量小的架構">MoE</a> 模型在公開 coding benchmark 上的回報（如 Qwen 官方技術報告、社群 SWE-bench 跑分）顯示表現接近大型 Dense 模型；具體分數依任務類型、prompt 設計與評測版本變動、需參考各模型官方文件或 <a href="/blog/llm/knowledge-cards/swe-bench/" data-link-title="SWE-bench" data-link-desc="用真實 GitHub issue 量化 LLM coding 能力的 benchmark">SWE-bench 卡片</a>。模型總參數與 <a href="/blog/llm/knowledge-cards/active-parameter/" data-link-title="Active Parameter" data-link-desc="MoE 模型每生成一個 token 實際參與計算的參數量、跟模型總參數量不同、影響推論速度上限">active parameter</a> 是兩個獨立軸、影響記憶體需求跟生字速度上限。</li>
<li><strong>MoE 卸載讓 16GB VRAM 能載入 30B 級模型</strong>。把約 30 層 MoE 專家權重留在 RAM、其餘放 VRAM、Qwen3-30B-A3B Q4 量化下整套模型總記憶體約落在 18 ~ 22GB 區間、其中常見約 12 ~ 14GB 在 VRAM（實際依模型結構與 <code>--n-cpu-moe</code> 設定變化）。</li>
<li><strong>KV cache 量化能在剩餘 VRAM 開大 context</strong>。模型權重放好後、剩餘 VRAM 配上 K=Q8 / V=Q4 的 KV cache 量化、社群常見回報能開到 128K ~ 256K 級 context（依模型 attention 配置變化）、寫 code 場景的長 prompt 較少需要截斷。</li>
<li><strong>零件可分次採購、後續可升級</strong>。相對 Apple Silicon 整機綁定配置、PC 零件（GPU、RAM、CPU、儲存）可分次採購與升級；具體零件價格依在地市場、世代與促銷波動、本文不引用具體幣值。</li>
</ol>
<p>下表是社群討論中常被提及的兩張同代 16GB 卡的相對對照、用意是「同樣 16GB VRAM 但頻寬不同對 throughput 的影響」、不是嚴格 benchmark：</p>
<table>
  <thead>
      <tr>
          <th>顯卡</th>
          <th>VRAM 頻寬（廠商標稱）</th>
          <th>Prefill 數量級</th>
          <th>生成數量級</th>
          <th>可開 context（量化 KV cache 下）</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>RTX 5060 Ti 16GB</td>
          <td>約 448 GB/s</td>
          <td>數百 t/s</td>
          <td>數十 t/s（較 5070 Ti 低約一半）</td>
          <td>128K ~ 256K 級</td>
      </tr>
      <tr>
          <td>RTX 5070 Ti 16GB</td>
          <td>約 896 GB/s</td>
          <td>約為 5060 Ti 的 2 倍</td>
          <td>約為 5060 Ti 的 2 倍</td>
          <td>128K ~ 256K 級</td>
      </tr>
  </tbody>
</table>
<p>兩張卡的差異主要在 VRAM 頻寬（廠商標稱接近 2 倍）、不在 VRAM 容量。對「同樣的模型能否載入」沒影響、對「生字多快」影響較大。實際 throughput 因驅動版本、模型量化方式、<code>--n-cpu-moe</code> 設定與 prompt 長度而變動、需自行用 <code>llama-bench</code> 或實際工作流校準。</p>
<blockquote>
<p><strong>事實查核註</strong>：表中 prefill / 生成的具體數字是社群討論中常見回報的相對數量級、不是經本文系統實測的 benchmark。VRAM 頻寬以 NVIDIA 廠商規格表為主、實作上會被 GDDR 模組廠商、PCIe 版本、CUDA backend 版本影響。引用前請以最新官方規格表跟 <a href="https://github.com/ggml-org/llama.cpp/discussions">llama.cpp 官方 benchmark</a> 為準。</p></blockquote>
<p>社群常見回報的三個觀察點（同樣需以自身配置實測校準）：</p>
<ol>
<li><code>--n-cpu-moe</code> 數值往上加（如從 20 加到 30）、單張卡的 VRAM 佔用降低、可開的 context 上限拉大、但生成速度也會下降；具體下降幅度依模型 active parameter 比例變化。</li>
<li>KV cache 量化（K=Q8 / V=Q4）相對 fp16 KV cache 體積大幅壓縮、能換取更大 context 上限；寫 code 場景的補完品質影響社群多數回報為小幅或不明顯、但會視 prompt 長度與任務類型而異。</li>
<li>系統 RAM 從 32GB 升到 64GB 後、可卸載的 MoE 層數上限明顯提高、能跑的最大模型規模也跟著拉開；具體層數依模型結構而定。</li>
</ol>
<p>對應的 PC 配置面向（2026 年 5 月、不引用具體幣值）：</p>
<ul>
<li><strong>價格優先</strong>：RTX 5060 Ti 16GB + 64GB DDR5 + 中階 CPU（如 AMD 9900X / Intel 14700K）+ 1TB NVMe。</li>
<li><strong>生字速度優先</strong>：RTX 5070 Ti 16GB + 64GB DDR5 + 中階 CPU。VRAM 容量跟 5060 Ti 相同、頻寬規格接近兩倍。</li>
<li><strong>跑得了 70B 級</strong>：RTX 4090 24GB / RTX 5090 32GB + 64GB ~ 128GB DDR5。</li>
</ul>
<p>若你正準備組新機主要為了跑本地 LLM 寫 code、16GB VRAM + 64GB RAM 是社群常見的合理起點；具體選哪張卡、視預算上限與對生字速度的要求而定。</p>
<h2 id="moe-卸載-vs-全載-dense-的選型差異">MoE 卸載 vs 全載 Dense 的選型差異</h2>
<p>PC 場景有 Mac 沒有的選型變數：<strong>同樣 16GB VRAM、要跑「全載 14B Dense」還是「卸載 30B MoE」？</strong></p>
<p>兩條路線的差異：</p>
<table>
  <thead>
      <tr>
          <th>維度</th>
          <th>全載 14B Dense</th>
          <th>卸載 30B MoE</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>生字速度</td>
          <td>相對較快</td>
          <td>相對較慢、視卸載層數而定</td>
      </tr>
      <tr>
          <td>模型能力</td>
          <td>14B 級、跨檔案重構任務的成功率較 30B 低</td>
          <td>30B 級、跨檔案重構任務社群回報成功率相對較高</td>
      </tr>
      <tr>
          <td>對 RAM 容量需求</td>
          <td>較低（32GB 通常足夠）</td>
          <td>較高（64GB 常見起點、128GB 對重度使用者更從容）</td>
      </tr>
      <tr>
          <td>context 上限</td>
          <td>KV cache 競 VRAM、上限受限</td>
          <td>配合 KV cache 量化、社群回報可開 128K 級以上</td>
      </tr>
      <tr>
          <td>系統熱度與功耗</td>
          <td>GPU 為主負載</td>
          <td>GPU 跟 CPU 同時負擔</td>
      </tr>
  </tbody>
</table>
<p><strong>判讀原則</strong>：寫 code 場景下、模型能力對任務成敗的影響通常比生字速度更顯著；30B 模型能完成的跨檔案任務、生字較慢仍可能勝過 14B 較快但解不出來的情況。若工作流以高頻短補完為主、對生字即時體感要求高、14B Dense 全載仍是合理選擇。實際取捨建議用一週實測校準。</p>
<h2 id="kv-cache-量化與-context-的權衡">KV cache 量化與 context 的權衡</h2>
<p>VRAM 預算扣掉模型權重後、剩下的空間主要給 KV cache。KV cache 跟 context 長度大致成正比、長 context 場景的 VRAM 限制跟 Mac 統一記憶體場景類似、但 PC 多了「量化 KV cache」這個工程選項。</p>
<p>下表為 KV cache 體積的數量級估算（依模型 attention head 數、hidden size、量化策略變化、實際值需用工具測量、本表用於說明量化前後的比例變化）：</p>
<table>
  <thead>
      <tr>
          <th>Context 長度</th>
          <th>KV cache 不量化（數量級）</th>
          <th>KV cache K=Q8 / V=Q4（數量級）</th>
          <th>16GB VRAM 餘量觀察</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>8K tokens</td>
          <td>1 GB 級</td>
          <td>&lt; 0.5 GB</td>
          <td>餘量寬鬆</td>
      </tr>
      <tr>
          <td>32K tokens</td>
          <td>數 GB 級</td>
          <td>1 ~ 2 GB</td>
          <td>量化後仍寬鬆</td>
      </tr>
      <tr>
          <td>128K tokens</td>
          <td>10 GB 級以上</td>
          <td>數 GB 級</td>
          <td>不量化時 VRAM 不足</td>
      </tr>
      <tr>
          <td>256K tokens</td>
          <td>數十 GB 級</td>
          <td>10 GB 級</td>
          <td>量化後接近 VRAM 上限</td>
      </tr>
  </tbody>
</table>
<p>KV cache 量化在寫 code 場景的體感判讀有三條社群常見回報的原則（具體影響因模型、量化版本與工作流而變、需自行實測校準）：</p>
<ol>
<li><strong>K（key）對量化容忍度通常較高</strong>：key 用來計算 attention score、本質是相對量級的比較。社群多數回報指出 K=Q8 相對 fp16 在補完品質上差異不明顯、可作為較安全的起手量化等級。</li>
<li><strong>V（value）對量化敏感度集中在長 context 末尾</strong>：value 是被加權平均的內容、量化誤差會累積進輸出。短 prompt（&lt; 32K）下 V=Q4 跟 fp16 的差異多為小幅；長 prompt（128K+）的對話末尾、社群回報偶爾觀察到「對前文細節記憶較模糊」的情形、但對跨檔案 code 補完任務影響社群多數回報為小。</li>
<li><strong>品質影響在 coding 跟自由創作場景不同</strong>：寫 code 的輸出空間受語法 / 型別 / 編譯限制、KV cache 量化的小幅誤差較容易被約束過濾；自由創作（小說、詩、長對話）對 V 量化較敏感、社群回報品質差異較明顯。</li>
</ol>
<p>實務上、K=Q8 / V=Q4 是 PC 場景開大 context 的常見組合；若觀察到長 prompt 末尾的回答品質下降、可考慮把 V 升回 Q8 或 fp16（代價是 VRAM 佔用上升、context 上限會縮短）。</p>
<p>具體調參邏輯詳見 <a href="/blog/llm/05-discrete-gpu/kv-cache-quantization-strategy/" data-link-title="5.2 KV cache 量化策略" data-link-desc="PC 場景用 K=Q8 / V=Q4 等量化把 KV cache 壓縮、騰出 VRAM 開大 context window 或加併發數的判讀">5.2 KV cache 量化策略</a>。</p>
<h2 id="系統-ram-容量在-pc-場景的角色">系統 RAM 容量在 PC 場景的角色</h2>
<p>Mac 統一記憶體只有一個容量數字、PC 多了「VRAM」跟「系統 RAM」兩個獨立數字。PC 場景的預算分配若全部投入 VRAM、可能忽略系統 RAM 對 MoE 卸載策略的支撐角色。</p>
<p>系統 RAM 在本地 LLM 場景的主要用途（具體佔用量依工作流變化）：</p>
<ol>
<li><strong>作業系統 + 開發工具</strong>：Windows / Linux + VS Code + 瀏覽器、常見佔用約 8 ~ 16GB。</li>
<li><strong>GPU driver pinned memory</strong>：NVIDIA driver 為了 PCIe DMA 會固定一塊系統 RAM、依驅動版本與配置常見約 1 ~ 2GB。</li>
<li><strong>MoE 卸載的專家權重</strong>：跑 30B MoE 卸載多數專家層、所需 RAM 落在 10 GB 級以上；跑 70B MoE 重度卸載通常需要數十 GB 級。具體數字依模型結構與 <code>--n-cpu-moe</code> 設定變化。</li>
<li><strong>多模型併存</strong>：同時跑 coding model + embedding model + 翻譯模型、每個各佔數 GB 級。</li>
<li><strong>page cache / 系統暫存</strong>：Linux 會把剩餘 RAM 用於 page cache、模型 reload 時可加速。</li>
</ol>
<p>對 16GB VRAM 配置而言、64GB RAM 通常足以支撐重度 MoE 卸載、是社群常見的起點容量。32GB RAM 配 16GB VRAM 在重度 MoE 卸載場景容易吃緊、可卸載層數會受限；視工作流類型、32GB 也可能足夠跑全載 Dense 模型。</p>
<h2 id="pcie-頻寬的角色">PCIe 頻寬的角色</h2>
<p>PCIe 在「載入模型」階段較常成為瓶頸、單人推論時通常不是、但 MoE 卸載會讓 PCIe 在推論時也參與資料流：</p>
<ol>
<li><strong>模型載入時</strong>：PCIe 5.0 x16 廠商標稱單向約 64 GB/s（PCIe 4.0 x16 約一半）、實際走完磁碟 → RAM → VRAM 整條路徑的吞吐通常較規格低、模型載入時間視 NVMe 讀取速度、檔案系統與量化格式變動。常見差異在啟動秒數、推論階段一般感受不到。</li>
<li><strong>MoE 卸載推論時</strong>：每 token 啟用的專家層權重需透過 PCIe 從 RAM 拉到 VRAM。以 Qwen3-30B-A3B 為例、每 token 啟用約 3B active parameter；若部分專家層在 RAM、每 token 需透過 PCIe 拉部分權重。單人推論場景下、相對 PCIe 5.0 x16 的可用頻寬佔比通常較小、社群多數回報不是主要瓶頸；併發數高或卸載比例極大時會逐漸顯現。</li>
<li><strong>多卡推論</strong>：多卡 tensor parallel 會密集走 PCIe / NVLink。消費級 GPU 普遍不支援 NVLink、訊息走 PCIe；多卡的吞吐縮放比社群回報相對單卡 + MoE 卸載的線性度差、需依工作流評估。</li>
</ol>
<p>實務上、單卡 + MoE 卸載場景下 PCIe 較少成為主要瓶頸；多卡或極端卸載比例下、PCIe lane 分配（如主機板的 x16 + x4 配置）會明顯影響可達吞吐。</p>
<h2 id="給讀者的決策表">給讀者的決策表</h2>
<p>看完上面的對照後、可以照下表做決策：</p>
<table>
  <thead>
      <tr>
          <th>情境</th>
          <th>建議</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>已有 8GB VRAM 卡、想試本地</td>
          <td>用 Qwen3 7B / Gemma 4 8B 試一週、評估是否值得升級、寫 code 主力可暫時保留雲端</td>
      </tr>
      <tr>
          <td>已有 12GB VRAM 卡（如 3060 / 4070）</td>
          <td>14B Dense Q4 全載 / 20B MoE Q4 卸載、依寫 code 場景速度需求選擇</td>
      </tr>
      <tr>
          <td>已有 16GB VRAM 卡、RAM 32GB</td>
          <td>先評估升級 RAM 到 64GB 再評估 MoE 卸載策略、32GB RAM 配 16GB VRAM 卸載空間有限</td>
      </tr>
      <tr>
          <td>已有 16GB VRAM 卡、RAM 64GB</td>
          <td>Qwen3-30B-A3B MoE Q4 + <code>--n-cpu-moe</code> 約 30 是社群常見起點配置</td>
      </tr>
      <tr>
          <td>已有 24GB VRAM 卡（如 4090）</td>
          <td>32B Dense Q4 全載 / 70B MoE Q4 卸載、依任務類型評估</td>
      </tr>
      <tr>
          <td>已有 32GB VRAM 卡（如 5090）</td>
          <td>70B Dense Q4 全載通常可行、依任務評估是否仍需 MoE 卸載</td>
      </tr>
      <tr>
          <td>正準備組新機、價格優先</td>
          <td>5060 Ti 16GB + 64GB DDR5 + 中階 CPU、整機可分次採購、具體預算依在地零件價格而定</td>
      </tr>
      <tr>
          <td>正準備組新機、追求生字速度</td>
          <td>5070 Ti 16GB + 64GB DDR5、VRAM 頻寬規格相對 5060 Ti 約 2 倍</td>
      </tr>
      <tr>
          <td>正準備組新機、要兼跑 70B</td>
          <td>4090 24GB / 5090 32GB + 64GB ~ 128GB DDR5</td>
      </tr>
  </tbody>
</table>
<h2 id="釐清需求類型個人使用-vs-服務多人">釐清需求類型：個人使用 vs 服務多人</h2>
<p>初次接觸本地 LLM 時、常見的疑問是「是不是要 H100 / H200 等資料中心級配置才能跑」。實際上資料中心級配置的設計目標是<strong>大規模並發推論服務</strong>（同時對許多 client 出 token）、跟單人寫 code 的需求側重不同。釐清需求類型後、硬體選擇會清楚很多。</p>
<p>三條判讀軸：</p>
<ol>
<li><strong>能載入的模型大小</strong>主要受 VRAM 容量影響、跟 GPU 算力等級沒有單一對應關係。16GB VRAM 配 MoE 卸載可載入 30B 級 MoE 模型；資料中心級 GPU 容量更大、能載入更大的 Dense 模型、但對個人寫 code 場景的能力提升不一定線性。</li>
<li><strong>生字速度上限</strong>主要由 VRAM 頻寬影響。消費級高階卡（如 RTX 5070 Ti、4090、5090）的頻寬已足以支撐單人寫 code 場景的補完即時體感、實際差異依模型量化、context 長度與 backend 變化。</li>
<li><strong>大量並發推論</strong>才需要資料中心級配置。單人開 VS Code 跟 LLM 對話、通常不會用到資料中心的並發優勢。</li>
</ol>
<p>對應的決策路徑：先確認需求是「個人寫 code」還是「服務多人」、再選 16GB VRAM + 64GB RAM 級的起點配置、實測一週觀察模型能力是否符合任務需求、再依痛點選擇升級方向（VRAM 容量、頻寬、或多卡）。</p>
<p>升級到能跑 70B 級之前、建議先確認痛點是「模型能力不夠」還是「生字速度不夠」。本地 30B MoE 在多數寫 code 任務上已能勝任、社群多數使用者回報不是每個工作流都需要 70B 級模型；具體判斷需用自己的任務實測。</p>
<h2 id="下一章">下一章</h2>
<p>下一章：<a href="/blog/llm/05-discrete-gpu/moe-cpu-offload-strategy/" data-link-title="5.1 MoE 模型與 CPU 卸載策略" data-link-desc="PC 場景把 MoE 不活躍專家層留在系統 RAM 的判讀：何時值得卸載、卸幾層、對 prefill 跟生成的影響各自不同">5.1 MoE 模型與 CPU 卸載策略</a>、深入 <code>--n-cpu-moe</code> 的判讀。</p>
]]></content:encoded></item></channel></rss>