GPU VPS 何時真的需要？CPU 夠不夠用

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

GPU VPS 會改變自行執行模型時的兩件事：token 產生的速度，以及模型是否能完整載入記憶體。其他方面不受影響。如果您的工作負載是量化後的 7B 至 27B 聊天模型，且一次只回答一位使用者；或是低流量的 embedding 工作；或是使用 Whisper small 進行語音轉錄，那麼只要 CPU VPS 具備足夠的 RAM，一般就能完成工作。先從 CPU 開始，量測真正造成困擾的指標，再升級硬體。

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

GPU 實際能帶來什麼

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

兼具容量與速度。 配備 64 GB RAM 的 CPU 主機，可以用 4 bits 載入 70B 模型。它仍可執行，但速度更接近閱讀，而不是對話。只有在模型能完整放入 VRAM 時，GPU 才能在這裡發揮作用，因為只要部分 layer 溢出到系統 RAM，速度就會再次受到慢速路徑限制。

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

Prompt 處理。 讀取長 prompt 受運算能力限制，而不是受記憶體頻寬限制；這也是 GPU 優勢最明顯的地方。CPU 需要 1 分鐘處理的 30,000 token context，在 GPU 上只需幾秒。每個請求都會塞入文件的 retrieval 架構，會持續感受到這項差異。

概略數據與解讀方式

以下區塊列出截至 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 個 token。兩者約相差 5 倍，這主要反映記憶體頻寬的比例，而不是原始運算能力的差異。實際吞吐量也會低於「頻寬除以模型大小」的結果，因為隨著上下文增長，attention 會增加額外工作量，而簡單除法未將其納入。

作為比較，人類閱讀速度約為每秒 5 到 10 個單字。對單一讀者而言，每秒 15 個 token 以上通常就會接近正常打字速度。因此，許多僅使用 CPU 的配置其實已足以應付需求。

購買前先估算 VRAM

模型檔案大小只是最低需求，不是完整需求。請將權重、KV cache（key-value cache，即 attention 維持的逐 token 記憶體），以及約 1 GB 的額外開銷納入計算。

截至 July 2026，一項實用規則是：以 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 顯示卡，或兩張較小的顯示卡。這套計算方式在更大規模的模型上仍然適用，而 Kimi K3 這類 2.8 trillion parameter 模型的 VRAM 計算則說明，到了某個規模後，問題已不再是選擇哪張顯示卡。

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

確認機器實際具備的項目

在 GPU instance 上，先確認 driver 能辨識顯示卡，再進行其他操作。

nvidia-smi

您應看到列出 GPU 名稱、driver 版本，以及已使用記憶體與總記憶體的表格。NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver 表示 driver 遺失，或 kernel module 在 kernel 升級後未重新建置。在標準 Ubuntu image 上，通常執行 sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install 即可修正，然後重新開機，讓新的 module 載入。

對 container 而言，只有 driver 並不足夠。Docker 需要 NVIDIA Container Toolkit，才能將裝置傳入 container。

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

接著從 container 內確認裝置傳遞正常：

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

相同的表格應會出現。若出現 docker: Error response from daemon: could not select device driver 行，並指出無法滿足的 GPU capability，表示 toolkit 已安裝，但 Docker 尚未重新設定或重新啟動。因此請重新執行 nvidia-ctk 行，並執行 restart。在 Compose 中，相當於使用 deploy.resources.reservations.devices 項目，其 driver 為 nvidia，且 capabilities 清單包含 gpu。這可插入 VPS 上的 Docker Compose 所介紹的一般 service 定義中。

升級前先測量

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

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 agent 成本中說明的預算管理原則同樣適用，差別在於此處的成本漏洞是閒置時間，而不是 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。權重約占 4.7 GB，其餘空間用於 KV cache 及約 1 GB 的額外負載。12 GB 顯示卡可為較長的 context 留下充裕空間。若預計使用 128k context，請另外估算 cache 所需空間，因為其容量可能超過權重。

Ollama 可以不使用 GPU 執行嗎？

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

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

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

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

通常不值得。單一使用者每秒閱讀 5 到 10 個 words，而 CPU 主機對約 13B 以下的模型，產生 tokens 的速度已經高於此速度。對單一使用者而言，長 prompt、影像生成及 fine-tuning 是較可能足以合理化成本的情境。若要同時服務多位使用者，理由最充分，因為 batching 能讓單張 GPU 以接近處理 1 個請求的成本，回應 20 個請求。

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

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