我能自行託管哪些 AI 模型？RAM 容量估算

哪些因素決定你能自行託管的 AI 模型

你能自行託管哪些 AI 模型，取決於一個數字：伺服器的 RAM。相較之下，模型系列與框架的影響小得多。關鍵在於權重是否能放入記憶體，並保留足夠的餘裕。本文將說明如何計算。安裝 runtime 是另一項工作，請參閱在 VPS 上執行 Ollama 的指南。

答案取決於兩項成本。權重是固定成本，由參數數量與量化方式決定。context window 是執行期間的成本，也是人們常常忽略的部分，直到昨天還能載入的模型今天突然無法載入。

參數的位元數：容量估算

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

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。

為什麼 context length 比 weights 更耗用 RAM

KV cache（key value cache，也就是模型為目前對話中每個 token 保留的 attention state）是第二項成本。模型載入時會配置這塊記憶體，大小取決於要求的 context length，並且會隨該長度呈線性增加。

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

在 Ollama 的預設 context 下，該 8B model 會將半個 gigabyte 用於 cache。context 為 8192 tokens 時，會使用 1 GB。在 model card 宣稱的 128k context 下，會使用 16 GB，超過 weights 的 3 倍。70B 則相反：其 128k context 的 cache 為 40 GB，低於自身的 weights，因為 grouped query attention 讓每個 token 的成本不會隨 parameter count 以接近相同的速度增加。

在僅使用 CPU 的 server 上，Ollama 的預設 context length 是 4096 tokens。存在 GPU 時，Ollama 會改依 VRAM 選擇預設值：VRAM 為 24 至 48 GiB 時是 32k，VRAM 為 48 GiB 以上時是 256k。請在 server 上透過 OLLAMA_CONTEXT_LENGTH 變數提高此值，然後在執行中 model 的 ollama ps 中查看實際取得的 context，位置是 CONTEXT 欄。該設定背後的記憶體計算，詳見num_ctx 與 context length 的文章。

有兩種方式可以降低 cache 的用量。請求實際需要的 context，而不是 model card 宣稱的 context，因為大多數聊天與 coding 工作都能在 8k 至 32k 內完成。或者將 cache 本身量化為 8 bits，這會使其大小減半，但 long context recall 會付出一些代價。

常駐模型會持續占用 RAM，直到有程序將其卸載

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

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 minutes 後再次執行 ollama ps。模型仍會列在清單中，這正是重點：無論是否有人使用，模型都會持續占用該 RAM。固定的模型不是可用的剩餘容量。在 16 GB VPS 上，使用 8B 與 8k context 時，模型會在服務執行期間持續占用約 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 releases。這些僅供尺寸參考，不代表建議。模型名稱每隔幾個月就會更替，但計算方式不會。

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

這個級距最常見的失敗原因是 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。

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

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

32B 模型使用 4 bits 量化時，權重約占 19.2 GB，因此可搭配較短的 context 放入 32 GB 方案，在 48 GB 或 64 GB 上則有充足空間。70B 模型使用 4 bits 量化時，權重約占 42 GB，因此在完全加入任何 cache 之前，就需要 64 GB。

接著要如實看待速度。32B 模型在 CPU 上的速度約為每秒 0.6 至 1.5 個 tokens；70B 模型則約為每秒 0.2 至 0.5 個 tokens。這個 70B 模型產生 500 個 tokens 的回答，約需 20 分鐘。這類工具適合批次處理。讓它們在夜間依序處理文件時，速度並不重要。若將它們放在 chat 視窗後方，速度就會非常重要。

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

CPU 推論速度到底有多快？

產生 1 個 token 需要將所有啟用中的權重從記憶體讀取 1 次。這個步驟無法省略，因此 CPU 的生成速度取決於記憶體頻寬，而不是核心數量。理論上限是可用記憶體頻寬除以權重的位元組大小。小型共用 VPS 的所有 vCPU 合計通常可提供 10 到 25 GB/s，因此 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 數說明如何取得可供比較的數值。

這裡有 2 個結果經常讓人意外。增加 vCPU 很快就不再有幫助，因為超過約 8 個核心後，多出的核心是在等待記憶體，而不是進行運算。在共用方案上，同一個命令每小時可能得到不同數值；這是 高負載鄰近租戶造成的 CPU steal time，不是設定錯誤。

讀取提示詞與生成答案是不同的工作。提示詞處理受計算能力限制，因此會隨核心數增加而加速，也是 GPU 優勢最明顯的部分。CPU 讀取長文件需要數分鐘，GPU 則只需數秒。當你讓程式碼代理使用自行託管的模型時，首先會遇到這項限制，因為每一輪都會重新傳送檔案內容與工具定義，之後答案的第 1 個 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 cache。因此，10 個使用 8B 模型、上下文長度為 8k 的並行使用者，除了模型權重外，還需要 10 倍的 1 GB 快取。由單一自架模型服務並行使用者說明了這個上限的實際位置。

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

無法自行託管的項目

這裡有兩個不同的限制，先了解自己遇到的是哪一個會比較有幫助。

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

第二個是開放權重模型的規模過大。最大的開放模型通常採用混合專家設計，總參數量達數千億。相同的規則也適用於這些模型：一個總參數量為 400B、使用 4 bits 的模型，光是權重就需要約 240 GB，還不包括任何快取。這需要專用硬體，而按月租用的成本，通常遠高於大多數人一年用於 API token 的支出。自行託管 Kimi 級模型需要什麼條件會逐步說明實際需求。

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

選擇前先確認現有資源

free -h
nproc
lscpu | grep 'Model name'

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

FAQ

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

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 模型。在這種情境下，提示設計良好的小型模型通常能達到通用模型相近的效果。若需要前沿模型的品質，請先將 API 成本與硬體成本比較，再決定購買哪一種方案。