Ollama 在 VPS 執行 Qwen 27B 需要多少記憶體？

您可以在沒有 GPU 的 VPS 上執行 Qwen 3.8 27B 嗎？

若要在 VPS 上執行 Qwen 3.8 27B，首先需要確認存在對應的模型標籤。截至 4 August 2026，Ollama library 完全沒有 qwen3.8 項目。最近發布的 27B 標籤是 qwen3.6:27b：包含 27.8 billion 個參數，採用 Q4_K_M 量化，授權為 Apache 2.0。以下每個指令與數字，都是以 Ollama v0.32.5 搭配該標籤為準；此版本發布於 27 July 2026。

簡短答案是：可以，但 VPS 至少需要 32 GB 記憶體，而且執行速度很慢。27B dense model 使用 Q4 量化時，僅模型權重就需要約 17 GB RAM，還未計入任何 context token。這表示 8 GB 與 16 GB 方案都完全不適用。在常見的雙通道 DDR4 VPS 上，效能上限約為 3 tokens per second，速度低於多數人的閱讀速度。

3.8 從何而來？最可能是參數數量造成的誤記。Ollama 的 qwen3.6:27b 頁面顯示 27.8B 個參數，而 27.8 之後很容易被記成 3.8。此外還有 qwen3.5:27b，這是上一個版本發布的相同 Q4_K_M build。複製任何指令前，請先查看即時清單： Ollama qwen3.6 標籤頁面。如果之後發布真正的 qwen3.8，這裡的計算仍然適用，因為計算依據是參數數量與每個權重的位元數，而不是版本號。

要拉取哪個 Ollama 標籤，以及如何檢查

拉取不存在的標籤時，系統會顯示明確錯誤，因此可直接在該主機上快速確認。存在的標籤仍可能無法在本機執行，這正是使用者遇到 資料庫中列出但只能從 Ollama 雲端提供服務的 GLM 5.2 時容易混淆的地方。

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show會列印您實際取得之標籤的架構、參數數量、內容長度與量化格式。如果參數列顯示 27.8B，且量化列顯示 Q4_K_M，表示您使用的是本指南所依據的組建。該資料庫也提供相同權重、但精度較高的 qwen3.6:27b-q8_0 與 qwen3.6:27b-bf16，以及一組採用 MoE（混合專家）模型、在 CPU 上的行為大不相同的 35b-a3b 標籤。下文會進一步說明這些內容。

參數數量乘以每個權重的位元數

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

公式只有一行：權重大小 = 參數數量 * 每個權重的位元數 / 8。若每個權重固定為 4 bits，27.8 billion 個參數會占用 13.9 GB。已發布的 Q4_K_M 標籤大小為 17 GB，換算後實際上是每個權重 4.89 bits。

這個差距不是錯誤。K-quant 格式不會以名目位寬儲存每個 tensor。在壓縮後品質損失最大的 tensor 會保留為 5 或 6 bits，而 token embedding 和輸出層通常會維持 Q6_K 或 Q8_0。格式名稱代表的是平均值，而實際平均值接近 4.9。相同情況也會出現在尺度的另一端：BF16 的 56 GB 等於每個權重 16.1 bits，而不是固定的 16，因為檔案還包含中繼資料和完整精度的 embedding table。

此模型沒有 Q5_K_M 的已發布標籤，因此 19.8 GB 這一列是按照該格式通常使用的每個權重 5.7 bits 計算，而不是實測值。Q8_0 幾乎讓 Q4 的大小加倍，達到 30 GB。在僅使用 CPU 的主機上，這會讓每個 token 的記憶體流量增加一倍，因此每秒 token 數也大致減半。單憑這個原因，Q4_K_M 就是這裡適合的預設選項。如果你想了解這項決策對品質而非記憶體的影響，Q4、Q8 與 fp16 的詳細比較會說明輸出品質實際從何處開始下降。

隨著上下文增長，KV cache 的成本

權重是固定成本。KV cache（key and value cache，也就是模型為已看過的每個 token 保留的 attention 狀態）會隨上下文長度線性增加，而這通常是大多數人實際耗盡 RAM 的地方。

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

這些數值假設採用 Qwen 近期同級距 dense model 使用的架構：64 層、GQA（grouped-query attention）下的 8 個 key/value heads，以及 128 的 head dimension。在 f16 下，每個 token 會佔用 256 KiB，因此 32k tokens 需要 8 GB，128k 則需要 32 GB。不要直接套用這些算術結果到自己的主機。請載入模型，查看 ollama ps 的 SIZE 欄位；該欄位會將權重、cache 與額外開銷合併顯示為單一數值。

這就是為什麼 model card 上的 256K context 是宣傳數字，而不是實際規劃。若以 f16 填滿，除了權重外還需要 64 GB 的 cache；而這台機器光是權重就已經佔用 17 GB。Ollama 預設不會直接提供完整的上下文視窗。它會載入小得多的視窗，之後再透過 OLLAMA_CONTEXT_LENGTH 主動調高。這個全伺服器層級的變數並不是唯一可調整的設定；在個別請求設定 num_ctx，則可為其他請求保留較低的預設值，同時讓單一長時間工作取得較大的視窗。請逐步調高，並在每次變更後檢查 ollama ps。

有兩項設定可將 cache 降至一半或更低。OLLAMA_KV_CACHE_TYPE=q8_0 會將 cache 改以 8 bits 而非 16 bits 儲存，使 32k tokens 所需容量從 8 GB 降至 4 GB。這需要 flash attention，因此也要設定 OLLAMA_FLASH_ATTENTION=1，並確認 ollama ps 中的容量確實下降，不要假設設定已生效。OLLAMA_NUM_PARALLEL=1 同樣重要。Ollama 可以同時處理多個請求，而每個 slot 都會取得自己的上下文區段，因此將 parallelism 保持在預設值，會在不知不覺中倍增原本規劃的 cache 容量。若這台主機會由多人使用，問題通常就從這種倍增開始；自架模型可服務的同時使用者數量，早在取決於 core count 之前，就已由 cache slots 與 queue depth 決定。

8、16、32 與 64 GB RAM 能容納的內容

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

將這兩個數字視為可在權重旁容納的上下文 token 數量，單位為千；條件是在使用 f16 cache 的無頭 Linux VPS 上，並預留約 1.5 GB 給作業系統及少量額外餘裕。數字為 0 表示權重本身就無法容納，因此沒有任何上下文可用。

8 GB 與 16 GB 並不是接近臨界值的情況。17 GB 的權重無法放入 16 GB RAM，調整上下文設定也無法改變這點。增加 swap 也無法解決問題。Ollama 會以 memory-map 方式載入 GGUF 檔案，因此常駐頁面超過 RAM 後，核心會開始不斷驅逐並重新讀取這些頁面，導致每個 token 都要從磁碟讀取數 GB 的資料。主機會長時間處於高 iowait，產出速度也會低於每秒 1 個 token。

32 GB 是最低可行配置。權重占用 17 GB，約剩下 13 GB，可在保留餘裕的情況下容納約 32k 個 f16 context token。容量為 30 GB 的 Q8_0 權重則完全無法在此配置中容納。

64 GB 的餘裕較充足。Q4 約可留下 128k 個 context token 的空間，Q8_0 權重也能在其後容納約 64k 個 token。在為了使用 Q8 而購買 64 GB RAM 前，應先確認實際換得的效益：輸出品質略好，但速度只有一半，而且是在原本就已經很慢的機器上。對幾乎所有人而言，使用 Q4 並搭配較長的上下文是更好的取捨。

VPS 上的 CPU 推論速度有多快？

從 dense model 產生 1 個 token，代表每次都要從記憶體讀取所有權重。不是其中一部分，而是全部權重。因此，速度上限不是核心數，而是記憶體頻寬除以權重大小。使用 Q4 時，每個 token 需要 17 GB 的記憶體流量。

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

這些是理論上限，不是實測值。實際輸出速度約為顯示數值的 50 到 70%，因為記憶體延遲與預取效率不完整，無法達到理論峰值。雙通道 DDR4-3200 VPS 的上限為每秒 3 個 token，因此預期約為 2。雙通道 DDR5-4800 主機的上限為 4.5，因此預期約為 3。

大型伺服器的資料列需要特別注意。12 通道 EPYC 平台具備 460.8 GB/s 的記憶體頻寬，上限為每秒 27.1 個 token，但你租用的不是整台 EPYC。記憶體頻寬是整台主機共用的資源，會由該主機上的所有租戶共同使用，因此 8 vCPU 的切片不會提供 12 個專用記憶體通道。以 GPU 為主的指南通常完全略過這點，而這正是同一模型上，兩個 vCPU 數量相同的 VPS 方案速度可能相差 3 倍的原因。

基於相同原因，增加 vCPU 很快就不再有幫助。核心要求資料的速度一旦超過記憶體控制器的供應能力，額外執行緒只會增加排程負擔，不會帶來其他效益。將 OLLAMA_NUM_THREAD 設為實體核心數，進行測試，再嘗試使用該數值的一半。在許多共用方案中，較低的設定反而更快。

Prompt processing 的行為不同。Prefill 是在第一個 token 出現前處理輸入內容的階段，主要受計算能力限制，而不是受記憶體頻寬限制，因此會隨核心數增加而提升。實際上，大型 prompt 會先造成一段較長的輸出前等待，接著以相對穩定但較慢的速度產生輸出。使用 --verbose 分別測量這兩個階段；該指令會針對每個請求輸出 prompt eval rate 與 eval rate。

如果 dense 27B 的速度實在太慢，先查看 qwen3.6:35b-a3b 標籤，再決定是否放棄 CPU。這些標籤每個 token 約啟用 3 billion 個參數，而不是全部 27.8 billion 個參數，因此每個 token 的記憶體流量會減少接近一個數量級，即使磁碟上的檔案更大。這是以 RAM 使用量換取速度。此處的 runtime 選擇也很重要，因為 Ollama 與 llama.cpp 對相同的底層推論程式碼提供不同的 CPU 調校控制項。

何時改為租用 GPU 小時

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

將相同公式套用到已公布的 GPU 記憶體頻寬後，答案會落在不同的類別。24 GB 消費級顯示卡在這些權重上的上限為 59 tokens per second。目前的資料中心級顯示卡可達 197。這不是調整執行緒數量就能彌補的差距。該顯示卡的記憶體頻寬為 1008 GB/s，而 VPS 只有數十 GB/s。

因此，應依工作負載而不是個人偏好劃定界線。當工作是非同步執行，且沒有人需要等待結果時，CPU 推論才是正確選擇，例如在夜間摘要一批文件，或在你睡覺時執行每晚一次的分類工作。只要有人正在等待輸出，或請求到達的速度快於每 30 秒 1 次，就應租用 GPU，因為僅使用 CPU 的主機沒有足夠的批次處理餘裕，佇列只會持續增長。

成本比較不像表面上那麼簡單。無論模型是否載入，64 GB VPS 都會按整個月份的每個小時計費；GPU instance 則只會計費實際啟動的時數。如果你的實際使用量是每天 2 小時，租用 GPU 可能同時更快且更便宜。先算出使用率，再估算成本。選擇搭載 GPU 的 VPS 說明 instance 本身需要檢查的項目，而在 GPU 上提供並行請求時，vLLM 會在 Ollama 之後超前，因為它能正確進行批次處理。

還有第三個常被忽略的選項。讓 27B 模型留在 CPU 上處理批次工作，並在互動式路徑前方放置 hosted API model。沒有任何要求規定同一個模型必須同時處理這兩類工作。

安裝 Ollama 並測量本機效能

安裝指令碼是官方版本，並會建立以專用 ollama 使用者執行的 systemd 服務。

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

ollama --version 應輸出 0.32.5 或更新版本。下載任何內容前，先檢查 free -g。如果 Mem 列的 total 欄低於 32，請停在這裡並選擇較小的模型，因為下載 17 GB 卻無法執行的模型會浪費一小時與大量磁碟空間。

請在 systemd override 中設定執行選項，不要在 shell 中設定。模型會在服務內執行，因此看不到互動式環境的設定。

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

--verbose 輸出就是要取得的測量結果。eval rate 是生成期間每秒處理的 tokens 數。prompt eval rate 是 prefill 速度。load duration 是從磁碟讀取權重所需的時間，因此要設定 OLLAMA_KEEP_ALIVE=60m：在 CPU 上，每次請求都從磁碟重新載入 17 GB 的權重，所需時間可能比處理請求本身更長。預設閒置逾時為 5 分鐘；批次佇列的項目之間若有間隔，就會反覆支付這次載入成本，而讓模型常駐的選項涵蓋每次請求的 keep_alive 欄位，也能讓設定在重新開機後保留。

模型載入期間，請在第二個終端機檢查記憶體使用量。

ollama ps

SIZE 欄是包含 KV cache 在內的實際記憶體使用量，應接近權重大小加上 KV 圖表中與 context length 對應的列。在 8192 tokens 且使用 8-bit cache 時，預期會比權重額外使用約 1 GB；如果 cache 維持 f16，則為 2 GB。PROCESSOR 欄應顯示 100% CPU。如果顯示其他內容，表示某個程序已占用 GPU，本指南中的速度數據不適用於你的本機。

失敗模式與實際顯示的字串

模型拒絕載入。 Ollama 會輸出同時列出兩個數值的行，格式為 model requires more system memory (18.6 GiB) than is available (15.2 GiB)。這是較理想的失敗情況，因為 Ollama 在配置記憶體前就完成檢查，而不是交由核心處理。請降低 context length、改用較小的 tag，或升級至更大的方案。

處理程序在回答途中消失。 client 沒有顯示有用資訊，而 journalctl -u ollama -n 50 會顯示服務正在重新啟動。執行 dmesg -T | tail；若看到內容為 Out of memory: Killed process ... (ollama) 的行，表示核心的 OOM killer 終止了該程序。這通常是因為預先載入檢查通過，但在長時間對話期間，快取成長超過估算值。請降低 context length。

pull 立即失敗。 Error: pull model manifest: file does not exist 表示該 tag 不在 library 中。輸入 qwen3.8:27b 會精確產生這個結果，版本號有任何拼寫錯誤時也一樣。請先在 library 頁面確認 tag，再檢查網路。

一切正常，但速度慢得無法使用。 如果主機 RAM 充足，生成速度卻低於每秒 1 個 token，通常表示發生分頁，而不是計算能力不足。生成內容時執行 vmstat 1。si 或 so 欄位出現非零值，表示核心正在使用 swap；解決方式是減少 context length，或減少已載入的模型。若 wa 持續偏高且沒有 swap 活動，表示記憶體映射的權重正在從磁碟重新讀取，也就是實際上無法完整放入記憶體。

第一個 token 需要 30 秒，之後輸出速度加快。 這是 prefill，屬於正常現象。長 system prompt 在每次未命中快取的請求中都必須重新處理，因此應先縮短 system prompt，再調整其他設定。

CPU-only 27B 實際適合處理的工作

請根據數據而非期待設定預期。在每秒 2 到 4 個 token 的速度下，產生 500 個 token 的回答需要 2 到 4 分鐘。這對聊天而言無法使用，但非常適合佇列處理。模型在回答前會先進行推理，因此情況會更慢：隱藏的推理 token 會以與回答相同的低速產生。讓推理強度符合工作需求是無須更換模型就能縮短回答時間的少數方法之一。文件摘要、批次標記、從待處理檔案中擷取欄位，以及無人值守的程式碼審查，都能容忍這種速度，因為不必等待回答。程式碼輔助正好處於臨界點，因此讓程式碼代理使用你自行託管的模型適合處理提交訊息與測試樣板等背景工作，不適合需要坐著等待的行內建議。

真正重要的是隱私。模型在你租用並控制的硬體上執行，沒有請求會離開該主機，也沒有按 token 計費。即使速度只有每秒 3 個 token，這對受監管資料仍然很有價值。但應誠實地與替代方案比較：自行託管 frontier-scale 模型需要多一個數量級的硬體資源；在這條曲線上，CPU 執行 27B 是成本最低、且輸出仍值得閱讀的方案。

若要對上述任一用途進行基準測試，就需要真實的結構化輸入，而大多數公開資料 API 在你測量吞吐量前，便要求先建立帳戶。Strasmore 的示範端點（由我們執行）提供 22 年美國市場資料的唯讀 SQL 查詢，不需要 key 或註冊：對 https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 發送 GET 即可取得 JSON，直接串接到 prompt 迴圈中；回應也會附上產生資料的完整 SQL，讓模型有可供摘要、且能獨立核對的內容。每次呼叫限制為 500 列與 20 秒，對每秒處理 2 個 token 的主機而言綽綽有餘。完整欄位清單位於 https://api.strasmore.com/v1/schema。

如果這是你第一次安裝 Ollama，在 VPS 上執行 Ollama 的完整教學涵蓋本指南假設你已具備的服務設定、HTTP API 與防火牆規則。請勿將連接埠 11434 暴露到網際網路。Ollama 本身不提供驗證機制，因此任何能連線到該連接埠的主機都能使用你的模型並讀取你的 prompt。

FAQ

Ollama 上有 Qwen 3.8 27B 模型嗎？

沒有。截至 4 August 2026，Ollama 程式庫中沒有 qwen3.8 命名空間。現有的 27B 標籤是 qwen3.5:27b 和 qwen3.6:27b，兩者都是 27.8 billion 參數 dense model 的 Q4_K_M 建置版本。搜尋詞中的 3.8 幾乎可以確定是把 27.8B 參數數量記成了版本號。請查看 https://ollama.com/library/qwen3.6/tags 取得目前清單；如果要使用最新發布的 27B，請執行 pull qwen3.6:27b。不存在的標籤會因 Error: pull model manifest: file does not exist 而失敗。

在 VPS 上執行 Qwen 27B 模型需要多少 RAM？

Q4_K_M 實際上至少需要 32 GB。權重大小為 17 GB，作業系統約需 1.5 GB；在 f16 下，KV cache 每增加 4000 tokens 的上下文，大約還會增加 1 GB。16 GB 方案完全無法容納權重。swap 也沒有幫助，因為檔案會以 memory-mapped 方式載入，kernel 只會在每個 token 重新從磁碟讀取。64 GB 可提供較長上下文的空間，或容納大小為 30 GB 的 Q8_0 權重。

27B 模型在 CPU 上每秒能產生多少 tokens？

將記憶體頻寬除以權重大小，再取其中的 50 到 70%。雙通道 DDR4-3200 VPS 的上限約為每秒 3 tokens，實際約可達 2。雙通道 DDR5-4800 主機的上限約為 4.5，實際約可達 3。更多通道的伺服器平台在規格上看起來好得多，但主機上的所有租戶會共用記憶體頻寬。因此，請使用 ollama run qwen3.6:27b --verbose 測量自己的效能，並查看 eval rate 行。

僅使用 CPU 的 VPS 應該選 Q4 還是 Q8？

幾乎在所有情況下都選 Q4_K_M。Q8_0 為 30 GB，而 Q4_K_M 為 17 GB，因此需要 64 GB 方案；此外，每個 token 傳輸的記憶體幾乎是兩倍，會讓每秒 tokens 大約減半。對多數工作而言，27B 模型的 Q4_K_M 與 Q8_0 在品質上的差異很小。建議將 RAM 用於更長的上下文，因為這會改變模型能完成的工作，而不只是改變措辭方式。

什麼時候租用 GPU 會比大型 RAM VPS 便宜？

當使用率低，或有人正在等待結果時。具備 24 GB 記憶體的 GPU 使用這些權重時，每秒約可達 59 tokens；典型 VPS 則只有 2 或 3，而且 GPU 只會按照實際執行的時數計費。64 GB VPS 則無論模型是否已載入，都會整月計費。請計算每天實際產生 tokens 的時數。若少於 2 或 3 小時，按時租用 GPU 通常在速度與成本上都較有利。持續執行低優先級批次工作時，常駐 VPS 才具有優勢。