VPS 要不要 GPU？什麼情況 CPU 就夠用

需要配備 GPU 的 VPS，還是 CPU 就足夠？

配備 GPU 的 VPS 會改變自行執行模型時的兩件事：token 產生的速度，以及記憶體是否容納得下特定大小的模型。除此之外不會改變任何事情。如果您的工作負載是量化的 7B 至 27B 聊天模型，每次回答一位使用者；低流量的嵌入工作；或使用 Whisper small 進行語音轉錄，那麼只要 CPU VPS 具備足夠的 RAM，普通的 CPU VPS 就能完成工作。先從 CPU 開始，測量真正造成困擾的數值，再升級硬體。

原因在於記憶體頻寬。語言模型產生一個 token 時，會從記憶體讀取所需的所有權重。量化為 4 bits 的 8B 模型在磁碟上約占 4.7 GB，在記憶體中也大致相同，因此產生一個 token 就表示需要搬移約 4.7 GB 的資料。將機器的記憶體頻寬除以這個數值，就能得到每秒 token 數的上限。這個單一除法可以解釋您將讀到的幾乎所有 benchmark。

GPU 實際能帶來什麼

頻寬。 現代主機的伺服器 DDR5 每秒可傳輸數十 GB。GPU 記憶體（VRAM、video RAM）每秒可傳輸數百 GB，甚至超過 1,000 GB。兩者的比值就是加速幅度，而且差距很大。

兼具容量與速度。 配備 64 GB RAM 的 CPU 主機可以載入 70B 模型（使用 4 位元量化）。模型可以執行，但速度比較接近閱讀，而不是對話。只有在模型能容納於 VRAM 時，GPU 才能在這方面提供幫助。因為只要模型層溢出到系統 RAM，慢速路徑就會重新成為瓶頸。

批次處理吞吐量。 這是人們最容易低估的部分。GPU 為單一使用者生成內容時，大部分運算資源都處於閒置狀態，因為 GPU 正在等待記憶體。若同時處理 20 個要求，同一次權重讀取就能服務全部 20 個要求。整體每秒 token 數會提高數倍，而每位使用者的速度只會略微下降。CPU 無法做到這一點。CPU 主機上有 2 個並行使用者時，兩者的速度大致會互相減半。如果你要建立一個供許多用戶端呼叫的 API，批次處理就是使用 GPU 的主要理由，其重要性高於單一串流的原始速度。

提示處理。 讀取長提示屬於受運算能力限制，而非受記憶體頻寬限制；這也是 GPU 優勢最明顯的地方。CPU 需要 1 分鐘處理的 30,000 token context，在 GPU 上只需幾秒。會將文件填入每個要求的檢索系統，會持續受到這項差異影響。

約略數值與解讀方式

以下區塊列出截至 2026 年 7 月，8B 模型在 4-bit 量化下，單一串流的典型公開數據。這些數值僅供數量級參考，不代表保證值。量化方式、內容長度和推論引擎都會使數值變動。

[
  {
    "label": "8 vCPU, DDR4",
    "mem_bandwidth_gbs": 40,
    "tokens_per_sec": 6
  },
  {
    "label": "16 vCPU, DDR5",
    "mem_bandwidth_gbs": 75,
    "tokens_per_sec": 11
  },
  {
    "label": "24GB GPU",
    "mem_bandwidth_gbs": 300,
    "tokens_per_sec": 50
  },
  {
    "label": "40GB data-centre GPU",
    "mem_bandwidth_gbs": 1555,
    "tokens_per_sec": 130
  }
]

24 GB GPU 列顯示每秒 50 個 token；DDR5 CPU 主機則為 11 個。兩者約相差 5 倍，這反映的是記憶體頻寬比例，而不是原始運算能力的差異。實際吞吐量也會低於「頻寬除以模型大小」的結果，因為內容長度增加後，attention 會產生額外工作量，而簡單除法未將其納入。

作為比較，人類每秒約可閱讀 5 到 10 個單字。對單一讀者而言，每秒達到 15 個 token 以上，體感就已接近一般打字速度。因此，許多僅使用 CPU 的配置其實已足夠。

購買前估算 VRAM

模型檔案大小只是最低基準，不是實際需求。請預留權重所需的空間、KV cache（key-value cache，attention 保留的每個 token 記憶體），以及約 1 GB 的額外負載。

截至 2026 年 7 月，一項實用規則是：以模型檔案的 GB 大小為基準，針對一般 8k 至 16k 的 context 再增加 20%。4.7 GB 的 8B 模型約需要 6 GB 的 VRAM。使用 4 bits 的 27B 模型約為 16 GB，約需要 20 GB。使用 4 bits 的 70B 模型約為 40 GB，需要一張 48 GB 顯示卡，或兩張容量較小的顯示卡。

長 context 會使這項規則失準。KV cache 會隨 context length 線性增加，在 128k tokens 時可能超過權重本身的大小。如果計畫使用長 context，請先依 cache 需求估算，並確認所使用的引擎是否提供 cache quantization。

檢查機器實際具備的元件

在 GPU 執行個體上，先確認驅動程式能辨識顯示卡。

nvidia-smi

您應看到一個表格，其中列出 GPU 名稱、驅動程式版本，以及已使用的記憶體和總記憶體。若出現 NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver，表示缺少驅動程式，或核心升級後未重新建置核心模組。在標準 Ubuntu 映像檔上，通常執行 sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install 即可修復，接著重新啟動，讓新的模組載入。

對容器而言，只有驅動程式並不足夠。Docker 需要 NVIDIA Container Toolkit，才能將裝置傳遞至容器。

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

接著從容器內部確認裝置傳遞正常：

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

應再次看到相同的表格。若出現 docker: Error response from daemon: could not select device driver 行，並指出無法滿足的 GPU 能力，表示已安裝 Toolkit，但 Docker 尚未重新設定或重新啟動。因此請重新執行 nvidia-ctk 行及重新啟動指令。在 Compose 中，相等的設定是 deploy.resources.reservations.devices 項目，其 driver 為 nvidia，且 capabilities 清單包含 gpu。這項設定可加入 VPS 上的 Docker Compose 所說明的一般服務定義中。

升級前先測量

在現有的 CPU 主機上執行實際要使用的模型，並記錄數據。使用 Ollama 在 VPS 上自行託管 LLM 時，只需設定一個旗標：

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

輸出內容最後會列出執行時間。eval rate 是每秒生成的 token 數。prompt eval rate 是機器讀取輸入的速度。這兩個數值可協助判斷哪種升級最有效：eval rate 偏低表示記憶體頻寬不足，長輸入的 prompt eval rate 偏低則表示運算能力不足。

在配備 GPU 的機器上，確認模型確實載入 GPU：

ollama ps

PROCESSOR 欄位在模型完全容納時會顯示 100% GPU，未完全容納時則會顯示類似 43%/57% CPU/GPU 的內容。模型部分分割通常比預期更慢，因為每個 token 仍須等待較慢的部分。

成本問題

GPU 執行個體的成本是相當 CPU 執行個體的數倍，而且會按其存在的每個小時計費，不是按其產生的 token 數量計費。每天只處理少量請求、卻持續運作的 GPU，是最昂貴的推論執行方式。損益平衡點在於使用率：繁忙的 GPU 每個 token 的成本很低，閒置的 GPU 則完全是在浪費資源。

有 3 種務實方式可行。將穩定但低流量的工作維持在 CPU VPS 上。偶爾遇到複雜請求時，將其傳送至代管 API，按 token 數量付費。批次工作、微調或大量 embedding 作業則按小時租用 GPU，完成後將其刪除。混合使用這些方式很正常，此處同樣適用 持續運作 VPS 上的 AI 代理程式成本控管 所述的預算管理原則；不同之處在於，造成成本流失的是閒置時間，而不是 token 數量。

沒有 GPU 仍能順利執行的工作

低流量的嵌入。小型嵌入模型只使用幾個 CPU 核心，每分鐘即可處理數百份短文件。建立一次的索引不需要具備高速處理能力。

使用 Whisper small 和 base 進行轉錄。Faster-whisper 在 CPU 上使用 small 模型時，轉錄速度接近即時。這足以支援在夜間執行的管線。

適用於 1 或 2 位使用者、約 27B 以下的量化聊天模型。速度較慢，但文字清晰且可用。

任何可視為批次工作的處理。如果沒有人監看畫面，實際經過時間是排程細節，而非必要條件。

真正需要 GPU 的工作包括：超過小型 adapter 的訓練或微調、為許多並行使用者提供服務、影像與影片生成，以及以延遲為核心產品特性的即時語音處理。

FAQ

7B 或 8B 模型需要多少 VRAM？

在一般 8k 至 16k context 下，4-bit quantized 8B 模型約需 6 GB。weights 約為 4.7 GB，其餘空間用於 KV cache，以及約 1 GB 的額外開銷。12 GB 顯示卡可為更長的 context 留下充足空間。如果計畫使用 128k context，請另外為 cache 預留容量，因為 cache 可能比 weights 更大。

沒有 GPU 也能執行 Ollama 嗎？

可以。Ollama 會自動改用 CPU，RAM 只需足以容納模型即可。4-bit 8B 模型的速度約為每秒 5 至 12 個 tokens，實際速度取決於記憶體速度；對單一使用者而言，這接近閱讀速度。CPU 的主要瓶頸是較長的 prompt，因為讀取 30,000 個 tokens 的 context 受計算效能限制，所需時間遠高於產生回覆的時間。

為什麼我的 GPU 幾乎沒有比 CPU 快？

最常見的原因是模型無法完整放入 VRAM，因此部分 layers 會在 CPU 上執行，而每個 token 都必須等待較慢的部分。執行 ollama ps，並確認 PROCESSOR 欄顯示 100% GPU。如果顯示分割配置，請改用較小的 quantization 或較小的模型。另一個常見原因是 benchmark 時間過短，導致模型載入時間主導測量結果。

單一使用者使用 GPU VPS 是否值得？

通常不值得。單一使用者每秒閱讀 5 至 10 個 words，而 CPU 主機對約 13B 以下的模型已能以更快的速度產生 tokens。對單一使用者而言，較長的 prompts、image generation 和 fine-tuning 是足以合理化成本的情境。若要同時服務許多使用者，GPU 的效益最明顯，因為 batching 可讓單張 GPU 以接近處理 1 個 request 的成本回應 20 個 requests。

應按小時租用 GPU，還是讓 GPU 持續執行？

如果工作量集中在特定時段，請按小時租用，例如 fine-tuning、大量 embedding 工作或批次 transcription 工作。只有在 GPU 持續處於高使用率時，才適合讓它持續執行，因為 GPU instance 是按存在時間計費，而不是按產生的 tokens 計費。低流量的 assistant 使用 CPU VPS，或使用按 tokens 計費的 hosted API，都比讓閒置的 GPU 運作更便宜。