自架 AI 模型需要多少 RAM？4GB、16GB、64GB VPS 選擇

決定可自架哪些 AI 模型的因素

決定可自架哪些 AI 模型的因素只有一個：主機上的 RAM。模型系列與框架的重要性遠低於模型權重是否能在記憶體中容納，且還保留足夠的餘裕。本文將透過算式說明如何判斷。安裝執行環境是另一項工作，請參閱在 VPS 上執行 Ollama 的指南。

答案取決於兩項成本。模型權重是固定成本，由參數數量與量化方式決定。上下文視窗則是執行成本，也是最容易被忽略的一項，直到昨天還能載入的模型今天突然無法載入。

參數的位元數：容量計算

模型檔案幾乎全部都是權重。每個權重會以特定位元數儲存。量化是指以低於訓練時精度的位元數儲存權重。這會略微降低準確度，但能大幅節省記憶體。容量可直接依下式計算：

weights in GB = (parameters in billions x bits per weight) / 8

模型通常以 16 位元發布，也就是每 1 billion 個參數需要 2 GB。因此，幾乎沒有人會在 VPS 上使用發布時的精度。以下是實際使用時會遇到的量化格式，以及每個權重的實際平均位元數：

• Q8_0 每個權重約使用 8.5 位元，因此每 1 billion 個參數約需 1.1 GB。
• Q6_K 約使用 6.6 位元，因此每 1 billion 個參數約需 0.83 GB。
• Q5_K_M 約使用 5.7 位元，因此每 1 billion 個參數約需 0.71 GB。
• Q4_K_M 約使用 4.8 位元，因此每 1 billion 個參數約需 0.6 GB。

請將每 1 billion 個參數 0.6 GB 作為估算值。在記憶體受限的主機上，Q4_K_M 是合理的預設選擇：相較於 8 位元，這對大多數工作只有些微的品質損失，而檔案大小接近減半。低於 4 位元後，品質損失會快速增加。因此，同一世代中，壓縮至 2 位元的 70B 通常不如 4 位元的 32B。記憶體不足時，應先降低模型大小級距，再考慮降至 4 位元以下。

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

上方的權重欄位是套用每 1 billion 個參數 0.6 GB 的規則計算而得。實際的 GGUF 檔案通常會落在該數值的幾個百分點內，因為 embedding 與 output layer 會以高於其餘部分的精度保留。4 位元的 3B 模型約為 1.8 GB。8B 模型為 4.8 GB。32B 模型為 19.2 GB，70B 模型則為 42 GB。

為什麼上下文長度比權重更耗用 RAM

KV cache（key value cache，也就是模型為目前對話中每個 token 保留的 attention 狀態）是第二項成本。模型載入時會配置這項快取，大小取決於指定的上下文長度，並會隨長度呈線性增加。

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

在 Ollama 的預設上下文長度下，該 8B 模型會為快取耗用半個 gigabyte。上下文長度為 8192 tokens 時，會耗用 1 GB。在模型卡宣稱的 128k 上下文長度下，會耗用 16 GB，超過權重的三倍。70B 則相反：其 128k 上下文的快取為 40 GB，少於自身的權重，因為 grouped query attention 讓每個 token 的成本不會接近參數數量的成長速度。

Ollama 在僅使用 CPU 的伺服器上，預設上下文長度為 4096 tokens。存在 GPU 時，則會依 VRAM 選擇預設值：24 至 48 GiB 時為 32k，48 GiB 以上時為 256k。請在伺服器上使用 OLLAMA_CONTEXT_LENGTH 變數提高此值，然後在 ollama ps 的 CONTEXT 欄位中確認執行中的模型實際取得的值。這項設定背後的記憶體計算，詳見num_ctx 與上下文長度的文章。

有兩種方式可以降低快取用量。請求實際需要的上下文長度，而不是模型卡宣稱的長度，因為大多數聊天與程式碼工作都能在 8k 至 32k 內完成。或者將快取本身量化為 8 bits，這會使其大小減半，但可能降低長上下文的回憶能力。

常駐模型會持續佔用 RAM，直到某個程序將其卸載

Ollama 會在最後一次請求後將模型保留在記憶體中 5 分鐘，之後才卸載。這個預設值適合筆記型電腦，但不適合伺服器，因為每次閒置後收到第一個請求時，都必須再次支付載入時間。

ollama ps
ollama stop qwen3:4b

ollama ps會列出目前常駐的模型，其中 SIZE 欄顯示模型佔用的記憶體，UNTIL 欄顯示模型的到期時間。若要永久固定模型，請在服務上設定 OLLAMA_KEEP_ALIVE=-1。將值設為 0，可在每次回應完成後立即卸載模型。

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

先傳送一個提示，再於 10 分鐘後再次執行 ollama ps。模型仍會列在清單中，這正是重點：無論目前是否有人使用，它都會持續佔用該 RAM。固定模型並不代表這些容量可供其他用途使用。在 16 GB VPS 上，具備 8k context 的 8B 模型只要服務持續執行，就大約會佔用 6 GB，因此應依模型加上應用程式的需求規劃主機容量，而不是只依模型需求規劃。將模型固定在記憶體中說明這項設定與冷啟動延遲之間的取捨。

4 GB VPS 上可執行的服務

作業系統與模型伺服器約需保留 1 GB，因此剩下約 3 GB。以預設的 4096 token context 計算，這相當於使用 4 bits 的 1B 至 4B 模型。截至 August 2026，這類模型包括 3B 的 Llama 3.2、1.7B 與 4B 的 Qwen 3，以及小型的 Gemma 和 Phi 版本。這些名稱僅供大小比較，不代表推薦。模型名稱每幾個月就會更替，但計算方式不會。

預期速度約為每秒 6 至 14 個 token。這類小型模型適合處理範圍狹窄的工作，例如分類、擷取標籤、撰寫短摘要，以及將段落改寫成指定的文件風格。它們不擅長多步驟推理，也不擅長處理跨越多個檔案的程式碼；再多 prompt 也無法解決這個限制。

這個層級的主要故障原因是 swap。如果模型無法完整放入記憶體，Linux 不會拒絕載入，而是將記憶體分頁移出至磁碟。由於產生單一 token 時必須讀取每個權重，產生速度會降至每個 token 需數秒。模型回應時，請監控 free -h 以及 vmstat 1 的 si 和 so 欄位。產生內容期間若 swap in 與 swap out 不為 0，表示模型對這個方案而言過大。

8 至 16 GB VPS 能執行的模型

這是自架模型開始具備一般實用性的配置。在 8 GB 記憶體上，可以使用 4 bits 的 7B 或 8B 模型，權重約占 4.8 GB，並搭配 8k context。在 16 GB 記憶體上，可以使用 4 bits 的 13B 或 14B 模型，權重約占 8.4 GB；如果希望將記憶體用於提升精度，而不是增加參數量，也可以讓 8B 模型使用 8 bits。

限制在於速度。CPU 上的 8B 模型每秒約產生 3 至 7 個 tokens，14B 模型則約為每秒 1.5 至 3.5 個 tokens。人類閱讀速度約為每秒 5 至 10 個 tokens，因此在 CPU VPS 上執行 8B 模型，就像觀看打字速度緩慢的人員輸入內容。這適合背景工作，但用於互動式聊天時會令人感到疲累。Qwen 3 在 VPS 上執行 8B 及更大型模型的實測結果可呈現實際使用情況。

在 32 至 64 GB VPS 上執行的模型

32B 模型使用 4 bits 時約需 19.2 GB，因此搭配較短的 context 時可安裝在 32 GB 方案上；使用 48 GB 或 64 GB 則有充足空間。70B 模型使用 4 bits 時約需 42 GB，因此在尚未加入任何快取前，就需要 64 GB。

接著，誠實評估速度。32B 模型在 CPU 上的速度約為每秒 0.6 到 1.5 個 token，70B 模型則約為每秒 0.2 到 0.5 個 token。70B 模型產生 500 個 token 的回答約需 20 分鐘。以這個速度執行時，請求通常會在模型完成前失敗，因為 Ollama 前方的某個用戶端或 proxy timeout 會先觸發；這就是 context deadline exceeded 錯誤 的來源。這些工具適合批次處理。讓它們在夜間處理文件佇列時，速度並不重要。若將它們放在聊天視窗後方，速度就會非常重要。

Mixture of experts routing 會改變上述計算方式，這也是唯一值得了解的架構細節。MoE 模型只會讓每個 token 通過部分權重。總參數為 30B、每個 token 啟用 3B 參數的模型，需要 30B 模型的記憶體，但生成速度接近密集型 3B 模型，因為每個 token 只會讀取啟用的 experts。在 32 GB 主機上，這種架構的 MoE 比密集型 30B 模型實用得多。應記住的規則是：總參數決定記憶體需求，啟用的參數決定速度。

CPU 推論速度實際上有多快？

生成每個 token 都需要將所有作用中的權重從記憶體讀取一次。這個步驟無法省略，因此 CPU 上的生成速度取決於記憶體頻寬，而不是核心數量。速度上限是用可用記憶體頻寬除以權重的位元組大小。小型共用 VPS 的所有 vCPU 合計通常可提供 10 到 25 GB/秒，因此 4.8 GB 的模型最高約為每秒 2 到 5 個 token。

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

這些數值是一般 VPS 硬體常見的回報範圍，不是單一機器的基準測試結果。實際數值取決於記憶體世代、主機上的記憶體通道數，以及同一主機上競爭記憶體頻寬的鄰近租戶數量。請使用你已有的任一模型標籤測量自己的數值：

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

回答結束後列印的摘要會有一行顯示 eval rate: ... tokens/s。這就是生成速度。請忽略工作階段的第一次執行，因為同一份摘要中的 load duration 還包含從磁碟讀取權重所需的時間。正確測量每秒 token 數說明如何取得可供比較的數值。

這裡有兩個結果常讓人意外。增加 vCPU 很快就不再有幫助，因為超過約 8 個核心後，額外核心是在等待記憶體，而不是進行算術運算。共用方案上的同一個命令在不同時段可能回傳不同數值；這是來自繁忙鄰近租戶的 CPU steal time，不是你的設定有誤。

讀取提示與生成回答是不同的工作。提示處理受計算能力限制，因此會隨核心數量增加而擴展，也是 GPU 拉開最大差距的部分。CPU 需要幾分鐘才能讀取長文件，GPU 則只需幾秒。當你讓你託管的模型處理程式碼代理時，這就是首先遇到的瓶頸，因為每一輪都會重新傳送檔案內容與工具定義，之後才會收到回答的第一個 token。

新增 GPU 後會有什麼變化

算式不變，只有適用的資源池不同。VRAM 是硬性限制，因此租用前先估算能容納的模型：

• 8 GB VRAM 可在 4 bits 量化下容納 7B 或 8B，並搭配較短的上下文。
• 16 GB 可在 4 bits 量化下容納 14B 並使用實際上下文，或在 8 bits 下容納 8B。
• 24 GB 可在 4 bits 量化下容納 32B，但上下文必須維持較短。
• 48 GB 以上可在 4 bits 量化下容納 70B，並保留快取與並行處理所需的空間。

模型無法完整放入時，Ollama 會將模型分割：部分層放在 GPU，其餘放在 CPU。ollama ps 會在 PROCESSOR 欄中回報分割結果，例如 78%/22% CPU/GPU。這應視為警告，而不是功能。CPU 上的部分會決定處理速度，因為每個 token 仍須等待這些層完成。因此，若模型有四分之一的層在 CPU 上執行，其速度會更接近 CPU，而不是 GPU。若看到非預期的分割，先降低上下文長度。通常是快取使模型超出限制。

並行處理是增加資源規模的另一個原因。同時處理的請求會共用權重，但每個作用中的請求都需要自己的 KV 快取。因此，10 個並行使用者以 8k 上下文使用 8B 模型時，除了模型權重外，還需要 1 GB 快取的 10 倍容量。由一個自架模型服務並行使用者會說明這個上限如何影響實際配置。

是否值得租用 GPU 也是一個算術問題，關鍵在於你每月實際產生多少 token。GPU VPS 與 API token 的損益平衡點列出了相關數據。

無法自行託管的內容

這裡有兩道不同的限制。先確認自己遇到的是哪一道，會比較容易判斷。

第一道限制是封閉權重。前沿商用模型不會公開發行，因此沒有可下載的檔案，增加 RAM 也無法改變這點。你可以自行託管周邊的所有元件：介面、檢索層、代理迴圈與日誌。模型本身仍會是遠端 API。是否能自行託管 Claude會完整說明這個問題。

第二道限制是開放權重，但模型本身過大。最大的開放模型通常採用混合專家架構，總參數量達數千億。這些模型同樣受限於硬體需求：一個總參數量為 400B、使用 4 bits 的模型，光是權重就需要約 240 GB，還未計入快取。這需要專用硬體，而按月租用的費用，遠高於多數人一年在 API token 上的支出。自行託管 Kimi 等級模型需要什麼會逐步說明實際需求。Ollama 自有函式庫中也能看到相同的區分：GLM 5.2 僅列為雲端模型，而真正能下載到 VPS 上的是尺寸小得多的同系列模型。

兩者之間的實際判斷標準是：負載穩定，且資料不應離開伺服器時，適合自行託管。負載具有突發性，或你真正需要的是前沿模型的回答品質時，則應購買 token。

選擇前先確認現有資源

free -h
nproc
lscpu | grep 'Model name'

請根據 free -h 的 available 欄規劃，不要使用 total 欄，因為 total 已包含系統目前正在使用的記憶體。先扣除約 1 GB，供作業系統與模型伺服器使用。將剩餘容量除以 0.6，即可得出在 4 bits 下可容納的最大參數量（以十億為單位）。接著扣除實際所需內容長度的 KV cache。剩餘容量就是答案；這不像模型名稱清單一樣會過時。

FAQ

我需要多少 RAM 才能執行 8B 模型？

4 bit 量化時，權重約需 4.8 GB，此外還要計入符合內容長度的 KV cache，以及作業系統和模型伺服器約 1 GB 的需求。若內容長度為 8192 token，cache 約增加 1 GB，因此 8 GB 方案可以運作，4 GB 方案則不行。若要使用模型卡所標示的完整 128k context，光是 cache 就需要 16 GB，此時需要考慮 32 GB 方案。

為什麼 VPS 有充足的 vCPU，模型執行速度仍然很慢？

因為生成速度受記憶體頻寬限制，而不是受核心數量限制。每生成一個 token，都必須從 RAM 載入整組作用中的權重；因此幾個核心使記憶體通道達到飽和後，其餘核心只能等待。另一個常見原因是 swap。如果模型回應期間 vmstat 1 顯示非零的 si 和 so，表示權重無法完整放入 RAM，每個 token 的部分運算都必須從磁碟載入，成本遠高於表面上看起來的程度。

較長的 context window 真的需要更多記憶體嗎？

需要，而且記憶體用量會隨 token 數量線性增加。一般 8B 模型每個 token 約需 128 KiB 的 KV cache，因此 8192 token 需要 1 GB，131072 token 則需要 16 GB。模型載入時就會配置 cache，不會等到對話內容增加後才配置。因此，即使每次送出的 prompt 只有 200 token，要求 128k context 仍會立即保留這些記憶體。

我應該以 2 bit 執行大型模型，還是以 4 bit 執行較小的模型？

選擇以 4 bit 執行較小的模型。品質從 8 bit 降至 4 bit 時下降較慢，低於 4 bit 後則會快速下降；因此，壓縮至 2 bit 的 70B 通常會比同一模型世代中以 4 bit 執行的 32B 產生更差的回答。高強度量化通常會造成重複內容和遺漏指令，而不是顯示錯誤訊息，因此很容易誤以為是 prompt 的問題。將 4 bit 視為最低限度，並改用調整參數數量的方式。

我可以自行託管與大型商用模型同等能力的模型嗎？

在一般 VPS 上無法做到。最強的開放權重模型可達數千億個參數；以 4 bit 計算，在尚未加入任何 KV cache 前就需要超過 200 GB RAM，而最強的商用模型則根本不會公開分發。一般硬體適合執行 8B 至 32B、專注於特定工作的優良模型；在這種情況下，範圍狹窄且 prompt 撰寫完善的小型模型，往往能達到通用模型的效果。如果需要前沿模型的品質，請先將 API 費用與硬體成本比較，再決定購買哪一種。