Ollama 在無 GPU 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 parameters、Q4_K_M quantisation，採用 Apache 2.0 licence。以下所有指令與數字，均使用 Ollama v0.32.5 上的此標籤；該版本發布於 27 July 2026。

簡短答案是：可以，但 VPS 必須具備 32 GB 以上記憶體，而且執行速度會很慢。Q4 下的 27B dense model，僅儲存 weights 就需要約 17 GB RAM，還未計入任何 context token。這表示 8 GB 與 16 GB 方案都完全不適用。在常見的雙通道 DDR4 VPS 上，速度上限約為 3 tokens per second，低於多數人的閱讀速度。

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

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

拉取不存在的 tag 時會顯示明確錯誤，因此可直接在該主機上快速確認。

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 會顯示你實際擁有之 tag 的架構、參數數量、context 長度與量化格式。如果參數列顯示 27.8B，且量化列顯示 Q4_K_M，表示你使用的是本指南所依據的版本。該 library 也提供相同權重、但精度較高的 qwen3.6:27b-q8_0 與 qwen3.6:27b-bf16，以及一組採用 MoE（mixture of experts）架構的 35b-a3b tag；這些模型在 CPU 上的行為截然不同。下文將進一步說明。

每個權重的參數數量與位元組數

[
  {
    "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 位元計算，27.8 billion 個參數會占用 13.9 GB。已發布的 Q4_K_M 標籤大小為 17 GB，換算後實際上是每個權重 4.89 位元。

這個差異不是錯誤。K-quant 格式不會讓每個 tensor 都使用標稱位寬。壓縮後品質損失最大的 tensor 會保留 5 或 6 位元，而 token embedding 與輸出層通常會維持 Q6_K 或 Q8_0。格式名稱代表的是平均值，實際平均值接近 4.9。尺度的另一端也有相同情況：BF16 的 56 GB，換算後是每個權重 16.1 位元，而不是固定的 16 位元，因為檔案也包含 metadata 與完整精度的 embedding table。

此模型沒有發布 Q5_K_M 標籤，因此 19.8 GB 這一列，是依該格式常見的每個權重 5.7 位元計算，而非實測值。Q8_0 幾乎是 Q4 的兩倍，大小為 30 GB。在僅使用 CPU 的主機上，這項倍增會讓每個 token 的記憶體流量增加一倍，因此每秒 token 數也大約減半。僅基於這個原因，Q4_K_M 就是這裡適合的預設選項。

內容長度增加時 KV cache 的成本

權重是固定成本。KV cache（key 與 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。不要只依照我的計算結果來評估自己的機器。載入 model，然後讀取 ollama ps 的 SIZE 欄位；該欄位會將權重、cache 與額外開銷合併顯示為單一數值。

因此，model card 上的 256K context 是標題數字，而不是實際規劃。若以 f16 填滿這個 context，除了權重之外還需要 64 GB 的 cache；而這台機器已經使用 17 GB 儲存權重。Ollama 預設不會提供完整的 window，而是載入小得多的 window；你必須透過 OLLAMA_CONTEXT_LENGTH 主動調高。請逐步提高數值，並在每次變更後檢查 ollama ps。

有兩個設定可將 cache 降至一半或更低。OLLAMA_KV_CACHE_TYPE=q8_0 會將 cache 改以 8 bits 而非 16 儲存，使 32k tokens 的需求從 8 GB 降至 4 GB。這需要 flash attention，因此也要設定 OLLAMA_FLASH_ATTENTION=1，並確認 ollama ps 中的數值確實下降，不要假設設定已生效。OLLAMA_NUM_PARALLEL=1 同樣重要。Ollama 可以同時處理多個請求，而每個 slot 都會取得自己的 context 區段，因此若將 parallelism 維持在預設值，會在未察覺的情況下，讓原本規劃的 cache 使用量成倍增加。如果這台機器會供多人使用，問題就會從這種倍增開始；self-hosted model 可服務的同時使用者數量，早在受到 core 數量影響之前，就已由 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 下，讓模型權重與上下文同時載入；環境是 headless 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 上下文 token。容量為 30 GB 的 Q8_0 權重則完全無法放入這一級。

64 GB 會寬裕許多。Q4 可留下約 128k 個上下文 token 的空間，而 Q8_0 權重載入後，還可容納約 64k 個 token。在為了使用 Q8 而購買 64 GB 之前，應先確認這項升級的實際代價：輸出品質略有提升，但速度減半，而且是在原本就很慢的機器上執行。對幾乎所有人而言，搭配較長上下文的 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 為主的指南通常完全略過這點，這也是同一個模型在 2 個 vCPU 數相同的 VPS 方案上，速度可能相差 3 倍的原因。

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

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

如果 dense 27B 的速度實在太慢，放棄 CPU 前先查看 qwen3.6:35b-a3b 標籤。這些標籤每個 token 約啟用 30 億個參數，而不是全部 278 億個參數。因此，即使磁碟上的檔案較大，每個 token 的記憶體資料傳輸量仍會降低接近一個數量級。你必須在 RAM 使用量與速度之間取捨。此處執行環境的選擇也很重要，因為 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。

還有第三個常被忽略的選項。讓 CPU 執行 27B 模型以處理批次工作，並在互動式請求路徑前方放置 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 的權重，所需時間會超過處理請求本身的時間。

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

ollama ps

SIZE 欄是包含 KV cache 在內的實際記憶體占用量，應接近權重大小加上 KV 圖表中對應內容長度的那一列。在 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 會在配置記憶體前先完成檢查，不會把問題交給 kernel 處理。請降低 context length、改用較小的 tag，或升級至記憶體更大的方案。

程序在回答過程中消失。 client 不會顯示有用資訊，而 journalctl -u ollama -n 50 會顯示服務正在重新啟動。執行 dmesg -T | tail；如果看到內容為 Out of memory: Killed process ... (ollama) 的一行，表示 kernel 的 OOM killer 已終止程序。這表示預先載入檢查雖然通過，但在長時間對話期間，cache 增長超過估算值。請縮短 context length。

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

一切都能運作，但速度慢得無法使用。 在 RAM 足夠的主機上，如果速度低於每秒 1 個 token，通常表示發生 paging，而不是 compute 能力不足。產生輸出時執行 vmstat 1。si 或 so 欄位只要不是 0，就表示 kernel 正在使用 swap；解決方式是減少 context，或減少已載入的模型。若 wa 持續偏高但沒有 swap 活動，表示 memory-mapped weights 正從磁碟重新讀取，也就是這些 weights 實際上無法完整放入記憶體。

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

純 CPU 27B 實際適合哪些用途

請根據數據設定預期，不要依賴希望。每秒產生 2 到 4 個 token 時，500 個 token 的回答需要 2 到 4 分鐘。這不適合聊天，但非常適合佇列處理。文件摘要、大量標記、從檔案待處理清單擷取欄位，以及無人值守的程式碼審查，都能接受這種速度，因為沒有使用者在等待回覆。程式碼輔助正好處於這條界線上，因此讓程式碼代理使用你託管的模型適合處理提交訊息與測試樣板等背景工作，不適合用於需要坐著等待的行內建議。

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

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

FAQ

Ollama 上有 Qwen 3.8 27B 模型嗎？

沒有。截至 2026 年 8 月 4 日，Ollama library 沒有 qwen3.8 namespace。現有的 27B tags 是 qwen3.5:27b 和 qwen3.6:27b，兩者都是 27.8 billion parameter dense model 的 Q4_K_M builds。搜尋詞中的 3.8 幾乎可以確定是把 27.8B parameter count 記成了版本號。請查看 https://ollama.com/library/qwen3.6/tags 取得目前清單；如果要使用最新發布的 27B，請執行 pull qwen3.6:27b。不存在的 tag 會因 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 的 context，約需再增加 1 GB。16 GB 方案完全無法容納權重。swap 也無法改善，因為檔案採用 memory-mapped，kernel 只會在每個 token 產生時重新從磁碟讀取。64 GB 可容納較長的 context，或 30 GB 的 Q8_0 權重。

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

將 memory bandwidth 除以權重大小，再取其 50% 至 70%。雙通道 DDR4-3200 VPS 的上限接近每秒 3 tokens，實際約可達 2。雙通道 DDR5-4800 主機的上限接近 4.5，實際約可達 3。更多通道的 server platform 在規格上看起來好得多，但主機上的所有 tenant 會共用 memory bandwidth，因此請使用 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 用於較長的 context，因為這會改變模型能處理的內容，而不只是改變措辭方式。

什麼情況下，租用 GPU 會比大型 RAM VPS 便宜？

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