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

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

自行執行模型時，GPU VPS 會改變兩件事：token 產生的速度，以及模型是否能完整裝入記憶體。除此之外沒有其他改變。如果工作負載是量化的 7B 至 27B 聊天模型，每次只回答一名使用者、低流量的 embedding 工作，或使用 Whisper small 進行語音轉錄，只要 RAM 足夠，一般 CPU VPS 就能完成。先使用 CPU，測量真正造成困擾的數值，再升級。

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

GPU 實際能帶來什麼

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

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

批次吞吐量。 這是最容易被低估的部分。GPU 為單一使用者生成內容時，大部分運算資源都處於閒置狀態，因為 GPU 正在等待記憶體。若同時處理 20 個請求，同一輪權重讀取就能服務全部 20 個請求。整體每秒產生的 token 數量會增加數倍，而每位使用者的速度只會略微下降。llama.cpp 等 CPU 推論引擎也支援批次處理，實際增益取決於硬體與工作負載。如果你正在建置供許多用戶端呼叫的 API，批次處理才是採用 GPU 的主要理由，其重要性高於單一串流的原始速度。

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

粗略數字，以及如何解讀

實際吞吐量也會低於以頻寬除以模型大小所得的數值，因為隨著上下文增長，attention 需要額外運算；簡單除法並未計入這項成本。

作為比較，成人以英文默讀的速度平均約為每秒 4.0 到 4.3 個單字：非小說類每分鐘 238 個單字，小說類每分鐘 260 個單字。對單一讀者而言，每秒 15 個 token 以上的速度，已經接近日常打字的速度。因此，許多僅使用 CPU 的配置其實已經足夠。

購買前先估算 VRAM

模型檔案大小只是下限，不是實際需求。請配置模型權重、KV cache（key-value cache，也就是 attention 維持的每 token 記憶體），以及約 1 GB 的額外開銷。

不要直接加上一個固定百分比，應該實際估算 cache，因為權重量化不會量化 cache。對每個 token 而言，完整 attention 模型會為每一層及每個 KV head 儲存一個 key 和一個 value；FP16 中每個數值佔 2 bytes，這是 Ollama 的預設 cache 類型。Ollama 的模型 metadata 於 2026-10-27 查得，Llama 3.1 8B 有 32 層，以及 8 個 KV head，每個 head 為 128 維，因此每個 token 需要 128 KiB：8k context 約為 1.07 GB，16k 約為 2.15 GB。因此，4.9 GB 的 8B 模型在 8k context 約需要 7 GB VRAM，在 16k 約需要 8 GB。使用 4 bits 的 27B 模型約為 17 GB（Ollama library 中的 Gemma 3 27B）。Gemma 3 的 metadata 列出 1,024-token sliding window，可避免其大部分 cache 持續增長，因此請規劃 20 GB 以上。使用 4 bits 的 70B 模型約為 43 GB（Llama 3.3 70B）。它有 80 層，FP16 cache 在 8k 約增加 2.7 GB，在 16k 約增加 5.4 GB，因此需要一張幾乎沒有餘裕的 48 GB 顯示卡，或兩張較小的顯示卡。同樣的計算方式可延伸到更大的模型，而 2.8 trillion parameter 模型（例如 Kimi K3）的 VRAM 計算方式會說明何時選擇顯示卡已經不再是問題本身。

長 context 最能看出這項差異。在 Llama 3.1 等完整 attention 模型中，KV cache 會隨 context 長度線性成長；在 128k tokens 時，可能超過模型權重本身。使用 sliding-window 或 chunked attention 的模型則不同：Hugging Face 的 Transformers 文件以 Mistral、Gemma 2 和 Llama 4 為例，指出這些層的 cache 達到 window 或 chunk 大小後便不再增長，因此總需求成長較慢。如果計畫使用長 context，請先按照 cache 估算，並確認引擎提供哪些 cache quantization 選項。在 Ollama 中，OLLAMA_KV_CACHE_TYPE=q8_0 的記憶體用量約為預設 f16 的一半，而且只有啟用 Flash Attention 時，cache quantization 才會生效。也請明確設定 context length。Ollama 會依 VRAM 選擇預設值：低於 24 GiB 時為 4k，24 至 48 GiB 時為 32k，48 GiB 以上時為 256k。在 48 GB 顯示卡上執行 70B 模型時，這個預設值需要的 cache 遠超過顯示卡容量。

確認機器實際具備的元件

在 GPU 執行個體上，先確認驅動程式能辨識顯示卡，再進行其他操作。

nvidia-smi

輸出結果應列出 GPU 名稱、驅動程式版本，以及已使用記憶體／總記憶體。若出現 NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver，表示 NVIDIA-SMI 無法連線到驅動程式；請確認驅動程式已安裝，且其 kernel module 已載入。在標準 Ubuntu 映像檔上，通常執行 sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install 即可修正，接著重新開機，讓新的 module 載入。對於運算機器，Ubuntu 的 server 文件建議使用 sudo ubuntu-drivers install --gpgpu，此命令會選擇 server 驅動程式分支。

對於容器，只安裝驅動程式還不夠。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 capability，表示 Docker 找不到符合要求的 device driver；請確認 toolkit 已安裝，然後重新執行 nvidia-ctk 行並重啟服務。在 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 執行個體是依配置的運算時間計費，而不是依 token 計費；費率與停止執行個體後是否繼續收費，則由供應商決定。全天開啟、每天只處理少量請求的 GPU，大部分付費時間都處於閒置狀態。損益平衡點在於使用率：忙碌的 GPU 每個 token 的成本很低，閒置的 GPU 則完全是在浪費資源。

有 3 種可行且務實的模式。將穩定但低流量的工作留在 CPU VPS。偶爾將複雜請求交給代管 API，按 token 付費。批次工作、微調或大量 embedding 作業則按小時租用 GPU，完成後將其刪除。混合使用這些模式很正常；always-on VPS 上的 AI agent 成本控管所述的預算管理原則同樣適用，不同之處在於這裡造成浪費的是閒置時間，而不是 token 數量。

沒有 GPU 仍能正常執行的工作

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

使用 Whisper small 和 base 進行轉錄。Faster-whisper 在 CPU 上使用 small 模型時，轉錄速度接近即時。對於可在夜間執行的處理流程，這已經足夠。

供 1 或 2 位使用者使用的量化聊天模型，規模最高約 27B。速度較慢，但輸出仍具可讀性，也能實際使用。

任何可視為批次工作的任務。如果沒有人盯著畫面，實際經過時間只是排程細節，不是必要條件。

真正需要 GPU 的工作包括：超出小型 adapter 範圍的訓練或微調、服務多名同時使用的使用者、影像與影片生成，以及以延遲為核心需求的即時語音處理。

FAQ

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

在 8k context 下，採用 4-bit 量化的 8B 模型約需 7 GB；在 16k 下約需 8 GB，這是使用 Ollama 預設 FP16 cache 的情況。權重約為 4.9 GB，KV cache 在 8k 下約增加 1.07 GB，在 16k 下約增加 2.15 GB，其餘約 1 GB 為額外開銷。8 GB 顯示卡可在 8k 下容納模型，但在 16k 下空間非常緊迫；12 GB 顯示卡則能為較長的 context 留下充足空間。將 cache 切換為 q8_0 後，cache 佔用量約可減半。如果計畫使用 128k context，請另外為 cache 預留空間，因為它可能成長到大於權重的大小。

可以不使用 GPU 執行 Ollama 嗎？

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

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

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

單一使用者使用 GPU VPS 值得嗎？

通常不值得。成人以英文默讀時，平均速度約為每秒 4.0 至 4.3 個 words；比較 CPU 主機與此速度前，必須先將每秒 tokens 轉換為每秒 words。對單一使用者而言，較長的 prompt、影像生成與 fine-tuning 是可能足以支撐成本的情境。一次服務多名使用者是最有力的理由，因為 batching 能讓單張 GPU 在多個請求之間共用權重讀取。

應按小時計費租用 GPU，還是持續開啟一台 GPU？

工作負載具有突發性時，請按小時租用，例如 fine-tuning、大量 embedding 作業或批次轉錄工作。只有在顯示卡持續處於高使用率時，才適合長時間開啟，因為配置好的 GPU 運算資源是按使用時間計費，而不是按產生的 tokens 計費。低流量的助理使用 CPU VPS，或採用按 token 計費的代管 API，通常都比讓 GPU 閒置更便宜。