GPU顯存 on KnightLi的博客

消費級顯卡跑 Agent 成本怎麼算：電費、折舊與每任務成本

Sat, 11 Jul 2026 10:30:00 +0800

想知道一張消費級顯卡跑本地 Agent 值不值，不能只看“顯卡買了多少錢”，也不能只拿 API 的每百萬 token 單價對比。Agent 會反覆調用模型、工具和瀏覽器；長上下文、失敗重試、空閒待機都會改變實際成本。

最實用的做法是把成本拆成四項：電費、硬件折舊、配套設備與人工維護，然後同時按“每個成功任務”和“每百萬輸出 token”覈算。

先確定你要算哪一種成本

口徑	適合回答的問題	容易漏掉的項目
增量成本	已有遊戲主機，閒時跑 Agent 多花多少錢？	顯卡本來就有，是否計入折舊
全成本	爲本地 Agent 專門購買機器是否划算？	主機、內存、SSD、散熱和折舊
單任務成本	自動處理一份文檔、一次代碼任務要多少錢？	失敗、重試和人工複覈
吞吐成本	自建推理服務每百萬 token 的成本？	輸入 token、KV cache 和閒置時間

如果顯卡原本用於遊戲或其他工作，先算增量成本更誠實；只有爲了 Agent 新購整機時，才把整機折舊完整計入。

月度總成本公式

先用月度口徑，數據最容易獲得：

月度总成本 = 电费 + 硬件月折旧 + 配套服务费 + 人工维护成本

电费 = 实测整机平均功耗(kW) × 实际运行小时数 × 电价(元/kWh)
硬件月折旧 = (购入总价 - 预估残值) ÷ 使用月数
单次成功任务成本 = 月度总成本 ÷ 月成功任务数
每百万输出 token 成本 = 月度总成本 ÷ 月输出 token 数 × 1,000,000

“整機平均功耗”應儘量來自插座功率計或 UPS，而不是隻看顯卡標稱 TBP。Agent 運行時還有 CPU、內存、SSD、風扇和顯示器；只用 GPU 功耗會低估電費。反過來，機器待機但沒有處理任務的時段，也不應混進純推理成本，最好單獨記錄。

一個可替換參數的示例

假設一臺機器在實際 Agent 工作負載下，插座實測平均功耗爲 280W，每天運行 6 小時，每月運行 30 天；當地電價按 0.8 元/kWh 計算。專門爲此購入的硬件按 7,000 元、36 個月、殘值忽略來攤銷。

1
2
3

电费 = 0.28 × 6 × 30 × 0.8 = 40.32 元/月
硬件折旧 = 7,000 ÷ 36 = 194.44 元/月
月度基础成本 = 234.76 元/月

若這個月完成了 600 個經過驗收的任務，基礎成本約爲 0.39 元/任務。這裏的“完成”不能只算模型返回；應該以腳本執行成功、工單關閉、人工抽檢通過等業務結果爲準。

這只是演算示例，不是通用價格。把功耗、使用時長、電價、購機金額和任務量替換成自己的數據，纔有意義。

Agent 爲什麼比普通聊天更難估算

聊天模型常按 token 計費，而 Agent 的成本還受執行路徑影響：

一次任務可能包含計劃、檢索、調用工具、讀取結果和多輪修正。
上下文越長，KV cache 佔用越多；顯存不足時會降速、CPU/RAM 卸載，甚至觸發重試。
瀏覽器自動化、代碼測試和文件處理會拉長任務時間，即使 GPU 沒有持續滿載。
多 Agent 並行會提高吞吐，也可能讓顯存爭用、排隊和失敗率上升。
爲了降低首 token 延遲而常駐模型，會增加空閒功耗。

因此，不要用一次簡短問答的 tokens/s 代表 Agent 成本。至少選一組真實任務，連續跑一週，記錄輸入/輸出 token、成功率、重試次數、牆鍾時間和整機耗電量。

兩個必須同時看的單位

每個成功任務

這最貼近業務決策。適合比較“本地 Agent 自動處理 PR”“批量整理資料”“客服草稿生成”等固定流程。

`1`	`每个成功任务成本 = (本周期全部成本) ÷ 成功且验收通过的任务数`

失敗任務不能從分子中刪掉。它們消耗的電力、推理時間和人工排障，正是本地系統真實的運營成本。

每百萬 token

這適合對比本地推理服務和雲端 API，但要區分輸入與輸出。很多 Agent 的輸入包含長工具日誌和歷史上下文，輸入 token 遠多於輸出 token；若只除以輸出 token，數字會偏高。更穩妥的做法是同時記錄輸入、輸出和總 token，並保持同一統計口徑。

如何採集自己的數據

不需要一開始就搭建複雜的監控系統。先建立一個表格，每次運行記錄以下字段：

字段	記錄方式
開始與結束時間	Agent 日誌或任務隊列
整機耗電量	智能插座、功率計或 UPS
輸入/輸出 token	推理服務日誌或客戶端統計
成功、失敗、重試	任務狀態與錯誤日誌
人工複覈時間	工單、PR 或抽檢記錄
模型與量化版本	避免不同模型混在同一組數據裏

先用 20 到 50 個有代表性的任務做基線。隨後分別測試短上下文、長上下文、工具調用多和重試多的任務，才能看出顯存和模型選擇對成本的影響。顯存規劃可結合本地模型量化與顯存選擇一起判斷。

折舊該怎麼算纔不會誤導自己

折舊沒有唯一答案，但必須先把假設寫下來。

已有顯卡：可以只算電費和額外維護，作爲增量成本；也可以給顯卡設一個機會成本，作爲更保守的全成本。
新購設備：顯卡、主機、內存、SSD 和散熱器應一起納入；不要只攤顯卡價格。
使用壽命：用 24、36 或 48 個月都可以，關鍵是用同一假設比較本地與雲端。
殘值：預計設備能轉賣時，可從購入價中扣除預估殘值；不確定就設爲 0，結論更保守。

NAS 或小主機通常功耗較低，但顯存、散熱和擴展能力也會限制模型與併發。若考慮這條路線，可先看NAS 部署 Ollama 的性能判斷。

與雲端 API 比較時，不要只比單價

可以把雲端側也換算成每任務成本：

`1`	`云端每任务成本 = 模型 API 费用 + 工具/API 费用 + 必要的存储与网络费用 + 人工复核成本`

本地通常更適合這些情況：

每天有穩定、可預測的任務量，機器利用率較高。
數據不能或不希望發往外部服務。
已經擁有可用 GPU，增量成本主要是電費。
可接受自行維護模型、驅動、服務和故障恢復。

雲端通常更適合這些情況：

負載是偶發的，機器大部分時間會閒置。
任務需要遠超本地顯存的大模型、超長上下文或峯值併發。
團隊不願承擔驅動、模型升級、監控和故障排查。
任務結果價值高，優先需要最強模型或多模態能力。

本地部署也不是隻能二選一。穩定、隱私敏感的步驟放本地；複雜、低頻或需要更強模型的步驟調用雲端，往往更容易控制總成本。

一個實用的決策線

把本地每月固定成本記爲 F，每個任務的可變電力與維護成本記爲 v，雲端每任務成本記爲 c。當 c > v 時，本地達到收支平衡的大致任務量爲：

`1`	`每月盈亏平衡任务数 = F ÷ (c - v)`

如果 c 小於或接近 v，本地不會因爲規模而明顯更省錢；此時應更多考慮隱私、延遲、可控性和離線能力。這個公式只是財務篩選，仍要加入失敗率和人工複覈時間。

常見誤區

只看顯卡功耗：整機電力、待機和散熱同樣要付費。
把標稱 tokens/s 當吞吐：真實 Agent 會被上下文、工具、網絡和測試步驟拖慢。
忽略失敗任務：重試最頻繁的流程，往往纔是成本黑洞。
只計算模型費用：瀏覽器、搜索、向量庫、存儲和人工審覈也可能收費。
混用不同模型的數據：量化版本、上下文長度和併發不同，結果無法橫向比較。

總結

消費級顯卡跑 Agent 的成本，不應只回答“每小時幾度電”。先用實測整機功耗算電費，再按自己的折舊假設加入硬件成本，最後用成功任務數和 token 量分攤。連續記錄一段真實工作負載後，你就能清楚判斷：是繼續本地運行、擴容顯存，還是把部分步驟交給雲端 API。

NAS 部署 Ollama 性能夠不夠：CPU、內存和顯卡怎麼判斷

Sat, 11 Jul 2026 09:40:43 +0800

NAS 能部署 Ollama，但“能安裝”和“用起來夠快”是兩回事。

如果目標是偶爾做摘要、文件問答、家庭自動化和低頻 API 調用，x86 NAS 用 CPU 跑小模型可以成立；如果希望像聊天軟件一樣連續對話、跑 7B/8B 代碼模型，或者讓多個服務調用，關鍵就變成顯存、內存和散熱，而不是硬盤有多少 TB。

先給結論：

沒有可用 GPU 的 NAS，適合小模型和低頻任務；有被 Ollama 正確識別的 NVIDIA GPU，才更適合把 7B/8B 模型作爲日常服務。

先確認你的 NAS 屬於哪一類

不要只看產品宣傳頁上的“AI 芯片”“NPU”或“4K 轉碼”。Ollama 是否能加速，取決於系統、驅動、容器權限和硬件是否在實際運行環境中被識別。

NAS 狀態	適合程度	更現實的用途
ARM CPU、8GB 內存、無可用 GPU	有限	極小模型、簡單分類、離線任務
x86 CPU、8GB 內存、無可用 GPU	勉強可用	1B–3B 量化模型、低頻文本處理
x86 CPU、16GB–32GB 內存、無可用 GPU	可測試	3B–7B 低量化模型，但響應速度通常較慢
x86 NAS + 8GB NVIDIA 顯存	日常可用	7B/8B 量化聊天、輕量代碼輔助、單用戶 API
x86 NAS + 12GB 以上 NVIDIA 顯存	更合適	8B 模型較舒適，部分 14B 量化模型可按上下文取捨

表格是部署判斷起點，不是性能承諾。CPU 型號、內存通道、模型格式、上下文長度、併發數、NAS 系統限制和散熱都會改變實際結果。

先把“存儲”和“推理”分開看

NAS 的大硬盤主要解決模型文件存放問題：你可以保存很多 GGUF、Ollama 模型層和文檔庫。推理速度主要由下面幾項決定：

CPU 的核心性能與內存帶寬；
系統內存是否足夠裝下模型和運行時；
GPU 是否可用，以及顯存是否裝得下模型與上下文；
PCIe 通道、驅動和容器是否正確透傳；
上下文長度、模型量化、併發和輸出長度。

所以“NAS 有 40TB 硬盤，能不能跑 32B 模型”的答案通常是：文件當然能放，但未必能以可接受的速度推理。

CPU-only NAS：什麼時候值得部署

沒有 GPU 也可以運行 Ollama。官方 Docker 鏡像支持純 CPU 啓動：

docker run -d \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

CPU-only 適合：

夜間批量摘要、文檔分類、標籤提取；
家庭自動化中的低頻文本任務；
驗證 API 調用、RAG 管道和權限邏輯；
對首 token 延遲和生成速度不敏感的個人工具。

不太適合：

多人聊天服務；
長時間代碼 Agent；
大模型連續生成；
實時語音助手或高頻網頁問答。

CPU-only 的正確策略是先用小模型，短上下文，限制併發。不要先下載最大的模型再期待“靠 NAS 慢慢算”能獲得接近雲端的體驗。

內存至少要留多少

系統內存不只給模型權重使用，還要留給 NAS 本身、文件緩存、Docker、下載任務、照片索引、容器和 KV Cache。

一個實用原則：不要讓 Ollama 把 NAS 內存喫到開始大量 swap。 一旦 swap 頻繁介入，響應時間會明顯惡化，也會影響文件共享和其他服務。

內存	建議
8GB	只建議小模型與輕量測試；NAS 還跑多個服務時要更保守
16GB	可作爲 CPU-only 本地助手的起點，優先小模型或低量化版本
32GB	更適合 7B 級低量化模型、RAG 和多個輕量容器並存
64GB+	有利於更大模型的 CPU/混合卸載與長文檔，但不等於生成速度足夠快

模型文件大小隻是下限。模型加載、上下文與運行時會繼續佔用內存，因此不要按“文件 8GB、機器 8GB”來判斷可否運行。

有 NVIDIA GPU 時，體驗差異最大

若 NAS 是 x86 Linux，且有支持的 NVIDIA 顯卡，Ollama 可使用 GPU 加速。Ollama 官方列出 NVIDIA compute capability 5.0+、驅動 531+ 的支持範圍，其中 RTX 30 系列也在支持列表內。

Docker 方案需要主機先配置 NVIDIA Container Toolkit，隨後再用 GPU 參數啓動容器：

docker run -d \
  --gpus=all \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

容器啓動後，先驗證 GPU 透傳本身，而不是直接下載大模型：

`1`	`docker run --gpus all ubuntu nvidia-smi`

這條命令不能正常顯示顯卡時，Ollama 容器也無法使用 GPU。此時應先檢查驅動、Container Toolkit、Docker runtime 和 NAS 系統是否支持 PCIe GPU 透傳。

NAS 的核顯、NPU 和轉碼能力能直接用嗎

不能默認這麼認爲。

很多 NAS 的核顯主要用於視頻解碼、轉碼或圖形輸出；一些設備宣傳的 NPU 也可能只開放給廠商自帶應用。它們是否能被 Ollama 使用，取決於 Ollama 支持的後端、操作系統、驅動和設備權限。

部署前應看實際證據：

宿主機能否看到 GPU 設備；
容器內能否運行 nvidia-smi 或對應廠商檢測工具；
Ollama 日誌是否明確顯示使用 GPU；
相同 prompt 下，GPU 與 CPU 的速度差是否合理。

看不到這些證據時，就按 CPU-only 預期規劃，不要因爲設備有“轉碼引擎”就按獨顯性能採購模型。

模型怎麼選纔不會把 NAS拖垮

NAS 部署的核心不是追求最大的模型，而是先讓常用任務穩定完成。

場景	模型選擇思路
家庭文檔摘要、分類、簡單問答	先試 1B–4B 模型
中文聊天、輕量腳本、單用戶 API	有 8GB 顯存時可試 7B/8B 量化模型
長代碼、複雜 Agent	優先更大顯存主機或雲端，不建議只靠普通 NAS CPU
Embedding/RAG	Embedding 模型通常更輕，適合放 NAS；生成模型按需調用
多人同時調用	先做隊列和併發限制，不要讓所有請求直接並行加載大模型

模型一旦太大，NAS 常見的表現不是立刻失敗，而是加載很久、首 token 很慢、生成速度低、系統內存持續攀升，最後影響文件服務和容器穩定性。

建議的部署結構

對大多數家庭或小團隊，推薦把 NAS 當作“數據與輕推理節點”：

NAS
├─ Ollama：小模型、Embedding、低频 API
├─ 文档与向量库：私有文件、备份、RAG 数据
├─ 反向代理：局域网访问控制
└─ 监控：CPU、内存、GPU、容器日志

高显存主机或云端
└─ 大模型、长上下文、复杂 Agent、高并发推理

這種分工比強行把所有推理都塞進 NAS 更穩定：敏感文件仍留在本地，重任務再路由到更合適的設備。

部署前的五分鐘測試

不要先下載幾十 GB 模型。先按這個流程判斷：

確認 NAS 架構、Docker 支持和剩餘內存。
啓動 Ollama 容器，確認 http://NAS地址:11434 可訪問。
拉一個小模型，連續問 5 到 10 個固定問題。
觀察 CPU、內存、swap、磁盤 IO 和 GPU 佔用。
再換到接近真實需求的模型，逐步增加上下文和併發。

可以用下面命令查看容器資源：

`1`	`docker stats ollama`

如果有 NVIDIA GPU，再同時觀察：

`1`	`nvidia-smi`

只要模型運行時讓文件共享、照片服務或備份任務明顯變慢，就說明當前模型或併發對 NAS 不合適，應降低模型規模或把推理遷到其他機器。

網絡和安全不要忽略

Ollama 默認本地服務端口是 11434。如果要讓局域網其他設備調用，先在 NAS 防火牆或反向代理層做訪問控制，不要直接把無鑑權的推理端口暴露到公網。

尤其當 NAS 裏有家庭照片、備份、文檔和私有文件時，模型服務、文件服務和管理後臺應使用不同權限邊界。能在局域網完成的調用，就不需要開放公網端口。

總結

NAS 部署 Ollama 是否夠用，可以按下面方式判斷：

只做摘要、分类、Embedding
-> CPU-only NAS 可以尝试

想要 7B/8B 模型的日常交互体验
-> 需要可用 GPU，优先看显存

想做长上下文、复杂 Agent 或多人并发
-> 更适合高显存主机或云端推理

先用小模型驗證資源和穩定性，再決定是否加顯卡、擴內存或拆分推理節點。NAS 很適合承載私有數據和輕量模型服務，但它不是天然的大模型服務器。

參考：

vLLM KV Cache 內存不夠怎麼辦：顯存、上下文和併發排查

Sat, 11 Jul 2026 09:36:02 +0800

vLLM 啓動時出現下面這類報錯，通常不是模型權重下載壞了：

`1`	`The model's max seq len ... KV cache is needed, which is larger than the available KV cache memory`

它表示：模型權重、運行時開銷佔掉顯存後，剩下的空間不足以爲你設定的最大上下文長度準備 KV Cache。最直接的處理順序是：先降低 --max-model-len，再檢查併發，最後才考慮提高顯存利用率、量化 KV Cache 或擴容。

不要一上來就把 --gpu-memory-utilization 拉到 1。那樣可能讓 vLLM 通過初始化，卻在真實請求、CUDA graph 或其他進程搶顯存時更容易 OOM。

先理解：KV Cache 爲什麼會佔滿顯存

模型權重決定“模型能不能加載”，KV Cache 決定“模型能同時記住多少 token、服務多少請求”。每生成或讀取一個 token，注意力層都需要保存對應的 Key/Value 狀態。

因此 KV Cache 佔用會隨下面幾項增加：

max_model_len：允許的最大上下文越長，緩存需求越大。
併發請求數：每個併發會佔用自己的上下文空間。
模型結構：層數、KV head 數、hidden size 和數據類型都會影響緩存大小。
緩存精度：默認通常跟隨模型數據類型；FP8 等低精度緩存可節省空間，但有兼容性和質量邊界。

最容易忽略的是併發。即使每個請求只給 8K 上下文，多個請求同時運行時，KV Cache 的總需求仍會快速增長。

先從日誌判斷是哪一種問題

啓動日誌通常會給出三個關鍵信息：

模型聲明或你配置的最大序列長度。
KV Cache 需要多少 GiB。
當前可用於 KV Cache 的實際空間，以及 vLLM 估算出的可行最大長度。

如果日誌說“最大長度 32768 需要 10GiB KV Cache，但當前只有 4GiB”，不要先糾結模型是否支持 32K。模型支持不代表你的這張卡能在當前配置下服務 32K 請求。

先記下日誌提供的估算最大長度，把第一次測試設置在它的 60% 到 80% 左右，再逐步提高。

第一優先級：降低 `--max-model-len`

這是成功率最高、影響最可預測的調整。比如模型原生支持 32K，你的實際業務只處理普通對話、短代碼和小文檔，可以先從 8K 開始：

1
2

vllm serve Qwen/Qwen3-8B \
  --max-model-len 8192

如果仍然不足，再試：

1
2

vllm serve Qwen/Qwen3-8B \
  --max-model-len 4096

不要把模型卡標稱的 128K、256K 或更長上下文直接寫進服務參數。對於單卡部署，真實可用長度取決於權重、顯存、併發與緩存精度。

一個實用的起點：

顯存與用途	先試的上下文長度
12GB–16GB 單卡、8B 級模型	4096 或 8192
24GB 單卡、7B–14B 模型	8192 或 16384
24GB 單卡、30B 級量化模型	先從 4096 開始
長文檔/RAG/多用戶服務	根據日誌估算與壓測決定，不要照表硬套

這些數值是排障起點，不是顯存承諾。不同模型的 KV Cache 大小可能相差很大。

第二優先級：限制併發和批處理

服務能啓動，不代表高併發時一定穩定。先把併發控制在小值：

1
2
3

vllm serve Qwen/Qwen3-8B \
  --max-model-len 8192 \
  --max-num-seqs 4

--max-num-seqs 限制一次迭代可處理的序列數。數值越大，吞吐可能更高，但 KV Cache 和調度壓力也更大。

如果請求裏經常帶長 prompt，還要關注 --max-num-batched-tokens。它決定一次調度最多處理多少 token；過高可能讓 prefill 階段瞬間佔用更多資源。排障時先保持保守，確認穩定後再逐步放大。

建議按這個順序壓測：

單請求、4K 上下文，確認服務穩定。
單請求、8K 上下文，觀察首 token 延遲與顯存。
兩個併發請求，確認不會 OOM。
再逐步增加 max_num_seqs 或批處理 token 數。

不要同時調整上下文、併發、batch 和模型量化，否則很難定位哪一個參數造成爆顯存。

第三優先級：合理設置 `--gpu-memory-utilization`

--gpu-memory-utilization 指定當前 vLLM 實例可使用的 GPU 顯存比例，取值在 0 到 1 之間。vLLM 會根據這部分空間規劃權重、運行時和 KV Cache。

例如：

vllm serve Qwen/Qwen3-8B \
  --gpu-memory-utilization 0.90 \
  --max-model-len 8192 \
  --max-num-seqs 4

當報錯明確說“可用 KV Cache 太少”且 GPU 上沒有其他進程時，可以小步提高，例如從 0.90 試到 0.92 或 0.94。每次只加一點，並用真實請求測試。

以下情況不建議硬拉高：

同一張卡上還跑着桌面程序、另一個推理服務或訓練任務。
啓動後可用顯存會波動。
使用 CUDA graph、視覺模型或高併發 prefill 時容易出現峯值。
你已經遇到運行過程中的 CUDA OOM，而不只是初始化檢查失敗。

如果多實例共享同一張 GPU，應爲每個實例留出明確預算，而不是都設置成 0.9。

FP8 KV Cache：省顯存前先確認模型和版本

vLLM 支持通過 --kv-cache-dtype 改變緩存數據類型。CUDA 11.8+ 環境可使用 FP8 相關選項，例如：

1
2
3

vllm serve Qwen/Qwen3-8B \
  --kv-cache-dtype fp8 \
  --max-model-len 16384

FP8 KV Cache 可以顯著減少緩存佔用，但不要把它當成完全無代價的開關：

先確認當前 vLLM、CUDA 與硬件支持該數據類型。
模型檢查點是否提供合適的 KV scale，會影響結果；缺失時需要謹慎評估。
長上下文、複雜推理、工具調用和結構化輸出都應與默認緩存精度做對照測試。
如果只是爲了讓一個不合適的大模型塞進顯卡，先降低上下文或換更合適模型通常更穩。

所以更推薦的順序是：先用默認精度把 4K/8K 跑穩，再測試 FP8 是否真的能讓業務獲得所需的上下文或併發。

手動指定 KV Cache 大小時要知道優先級

較新的 vLLM 提供 kv_cache_memory_bytes，可按每張 GPU 的字節數精確指定 KV Cache 大小。它適合多服務共卡、需要固定顯存預算的場景。

要注意：顯式設置緩存字節數時，會覆蓋通過 gpu_memory_utilization 自動推算緩存大小的行爲。不要同時把兩者當作疊加增益；先決定是採用“比例預算”，還是採用“固定緩存預算”。

固定預算適合運維約束明確的服務器，單機排障則通常先用 --gpu-memory-utilization 和 --max-model-len 更直觀。

CPU offload 能解決什麼，不能解決什麼

新版 vLLM 支持把一部分 KV Cache offload 到 CPU，或結合 LMCache 等後端處理緩存層。這可以在 GPU 緩存不夠時擴展容量，但代價是 PCIe/內存傳輸和延遲。

它更適合：

偶爾出現超長上下文請求；
業務能接受更高首 token 延遲；
有充足系統內存，並已做真實壓測；
想爲長 prompt 做降級路徑，而不是追求最高吞吐。

它不適合拿來掩蓋“模型權重本來就放不下”的問題，也不能替代對併發和上下文上限的管理。若所有請求都頻繁換出換入，吞吐往往會明顯下降。

一個可複製的排障模板

先從保守配置啓動：

vllm serve Qwen/Qwen3-8B \
  --gpu-memory-utilization 0.90 \
  --max-model-len 4096 \
  --max-num-seqs 2

確認能穩定處理單請求後，按下面順序調整：

4096 上下文稳定
-> 8192 上下文稳定
-> max_num_seqs 从 2 调到 4
-> 调整 max_num_batched_tokens
-> 再测试 FP8 KV Cache 或 CPU offload

每輪記錄四項數據：可用 KV Cache token 數、首 token 延遲、生成 tokens/s、峯值顯存。這樣才能判斷某項優化是在提升吞吐，還是隻是把 OOM 推遲到更高併發時發生。

常見誤區

誤區一：模型支持長上下文，所以服務必須開滿

模型能力上限和你的顯卡可服務上限是兩回事。服務端的 max_model_len 應按硬件和業務上限設置。

誤區二：把 `gpu_memory_utilization` 設成 1 就能解決

這會減少安全餘量，不能減少 KV Cache 本身的需求。運行時峯值反而更容易觸發 CUDA OOM。

誤區三：只降低權重量化，不管併發

權重量化能騰出顯存，但併發與上下文仍會讓 KV Cache 迅速膨脹。服務配置必須同時限制長度和請求數量。

誤區四：CPU offload 一定比拒絕長請求好

如果延遲敏感，頻繁 offload 可能比明確把長請求路由到更大顯存節點更差。先定義業務的延遲和成本邊界。

總結

vLLM KV Cache 內存不夠，最可靠的處理優先級是：

降低 max_model_len
-> 限制 max_num_seqs 与 batch
-> 小步调整 gpu_memory_utilization
-> 验证 FP8 KV Cache
-> 最后考虑固定缓存预算或 CPU offload

先讓一個短上下文、低併發配置穩定工作，再按業務數據逐步擴大。只要把模型權重、KV Cache、併發和真實上下文長度分開看，大多數“內存不夠”問題都能更快定位。

參考：

Ollama 多模型切換怎麼配置：常駐、顯存和 Modelfile 教程

Sat, 11 Jul 2026 09:32:06 +0800

Ollama 裝了好幾個模型以後，很多人的第一個問題是：怎麼在聊天、代碼、翻譯和 Embedding 模型之間快速切換？第二個問題往往更實際：爲什麼剛切到另一個模型，前一個就從顯存裏消失了？

先說結論：Ollama 不需要爲每個模型單獨起服務。日常用 ollama run <模型名> 切換即可；用 ollama ps 看當前哪些模型還在內存；不需要的模型用 ollama stop <模型名> 釋放。是否能同時常駐多個模型，取決於它們能否一起放進可用顯存或內存，而不是本地磁盤裏下載了多少模型。

最常用的切換命令

先列出本機已經下載的模型：

`1`	`ollama ls`

啓動一個聊天或代碼模型：

`1`	`ollama run qwen3:8b`

需要換成另一個模型時，直接運行另一個名稱：

`1`	`ollama run qwen3:4b`

或者切到 Embedding 模型做測試：

`1`	`ollama run embeddinggemma "测试一段文本"`

模型文件保留在本地，切換不會重新下載。第一次加載模型時需要把權重放進顯存或系統內存，之後如果模型仍被保留在內存中，再次調用會更快。

`ollama ps`：先看誰佔着顯存

切換不順暢時，先執行：

`1`	`ollama ps`

它會列出正在運行或仍駐留內存的模型。這裏最值得看的是模型名、佔用大小、處理器位置和到期時間。

如果你只有一張中等顯存顯卡，先後啓動兩個大模型時，Ollama 可能會卸載前一個模型，爲後一個騰位置。這是正常的資源調度，不是模型丟了。模型仍然在磁盤裏，下次調用會重新加載。

不想等它自然過期，可以主動停止：

`1`	`ollama stop qwen3:8b`

再用 ollama ps 確認顯存已經釋放。

默認常駐多久：5 分鐘

Ollama 默認會在模型最後一次使用後保留約 5 分鐘。這個設計適合連續提問：第一次加載稍慢，後續請求不用反覆把同一個模型搬回顯存。

如果你在小顯存機器上輪流使用多個模型，5 分鐘反而可能造成“剛跑完一個，顯存還沒還回來”的感覺。這時有三種控制方式。

方法一：一次調用後立即卸載

通過 API 把 keep_alive 設爲 0：

curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "prompt": "用一句话解释 KV cache",
  "keep_alive": 0
}'

這適合模型很大、顯存很緊，而且每次任務都獨立的情況。

方法二：讓模型長時間常駐

如果你整天都在用同一個代碼模型，可以把 keep_alive 設爲負數：

curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "keep_alive": -1
}'

這樣模型會持續留在內存中，直到手動 ollama stop 或服務重啓。不要在顯存不夠時對多個大模型都這樣設置。

方法三：全局修改默認常駐時間

可以爲 Ollama 服務設置 OLLAMA_KEEP_ALIVE。例如希望所有模型默認保留 30 秒：

`1`	`OLLAMA_KEEP_ALIVE=30s`

Windows 下，Ollama 會繼承用戶或系統環境變量。設置完成後，需要退出托盤中的 Ollama，再從開始菜單重新啓動。Linux 上如果 Ollama 由 systemd 管理，則在服務環境變量中設置並重啓服務。

API 請求裏的 keep_alive 會覆蓋全局 OLLAMA_KEEP_ALIVE，所以更適合爲不同任務設置不同策略。

多模型常駐的關鍵：`OLLAMA_MAX_LOADED_MODELS`

OLLAMA_MAX_LOADED_MODELS 用於限制可同時加載的模型數量。例如只想讓服務最多保留一個模型：

`1`	`OLLAMA_MAX_LOADED_MODELS=1`

這個設置的意義是避免模型輪換時長期佔滿顯存，但它不是“強行讓一個大模型裝進顯卡”的辦法。GPU 推理時，新的模型只有在能夠完整放入可用顯存時，纔可能與其他模型併發常駐。否則 Ollama 會卸載舊模型，或把模型放到更慢的內存路徑。

對單張 8GB、12GB 或 16GB 顯卡，比較穩的策略通常是：

場景	建議
日常只用一個聊天模型	`OLLAMA_MAX_LOADED_MODELS=1`，保留 5 分鐘或更短
小模型聊天 + Embedding	先看兩者實際佔用，能同時放下再提高數量
代碼模型與通用模型輪流用	不強求雙常駐，按任務切換並主動 `ollama stop`
服務器多用戶調用	結合模型大小、顯存、請求量，再設置併發和隊列

不要忽略併發：上下文也會喫內存

多模型問題不只與模型權重有關。每個並行請求都會增加上下文和 KV cache 的資源消耗。

Ollama 還提供兩個相關環境變量：

1
2

OLLAMA_NUM_PARALLEL=1
OLLAMA_MAX_QUEUE=512

OLLAMA_NUM_PARALLEL 控制同一模型可並行處理的請求數。併發數提高時，所需資源會隨上下文長度增加。單卡本地使用時，先保留默認或明確設爲 1 往往更容易排查；不要一邊加載多個模型，一邊把併發拉高。

OLLAMA_MAX_QUEUE 則是繁忙時可排隊的請求數。它只解決排隊，不會增加顯存。

用 Modelfile 給不同用途創建固定別名

如果你總是對同一個底座模型重複設置系統提示詞、溫度或上下文策略，可以用 Modelfile 創建多個本地別名。它們不是複製一整份權重，而是基於一個模型定義不同配置。

例如創建一個偏代碼的配置文件 Modelfile.code：

1
2
3

FROM qwen3:8b
SYSTEM 你是一个中文编程助手。先说明修改思路，再给出可运行的最小代码。
PARAMETER temperature 0.2

創建模型別名：

`1`	`ollama create qwen3-code -f Modelfile.code`

之後直接運行：

`1`	`ollama run qwen3-code`

同樣可以做一個偏寫作的版本：

1
2
3

FROM qwen3:8b
SYSTEM 你是中文写作助手，回答前先给结论，再给必要的结构化说明。
PARAMETER temperature 0.7

1
2

ollama create qwen3-write -f Modelfile.write
ollama run qwen3-write

注意：qwen3-code 和 qwen3-write 雖然共享同一個底座方向，但對運行時來說仍是不同模型配置。顯存緊張時，不要假設它們可以無限同時常駐。

給腳本或 API 按任務切換模型

在 API 裏，模型名本身就是路由字段。腳本不需要重啓服務，只要按任務傳入不同 model：

curl http://localhost:11434/api/chat -d '{
  "model": "qwen3-code",
  "messages": [
    {"role": "user", "content": "解释这段 Python 的异常处理逻辑"}
  ],
  "stream": false,
  "keep_alive": "10m"
}'

一個常見分工是：

小模型：分類、改寫、摘要、簡單問答；
代碼模型：解釋倉庫、生成腳本、修復錯誤；
Embedding 模型：向量檢索，不承擔聊天；
較大模型：複雜問題，按需加載，用完釋放。

把“選哪個模型”寫在代碼的任務路由裏，比在一個大模型上硬塞所有工作更容易控制速度和顯存。

Windows 下的常見坑

環境變量改了但沒生效

Windows 上修改 OLLAMA_KEEP_ALIVE、OLLAMA_MAX_LOADED_MODELS 或 OLLAMA_MODELS 後，必須退出正在運行的 Ollama 托盤程序並重新啓動。只重開 PowerShell 通常不夠。

模型文件擠滿系統盤

可以設置 OLLAMA_MODELS 把模型目錄遷到其他磁盤，例如：

`1`	`OLLAMA_MODELS=D:\OllamaModels`

保存後重啓 Ollama。遷移已有模型前先確認磁盤空間和目錄權限，不要只改變量就刪除舊目錄。

以爲模型被刪了

切換後 ollama ps 看不到舊模型，只代表它已經從內存卸載；用 ollama ls 仍能看到下載的模型。只有執行下面的命令纔會刪除本地模型文件：

`1`	`ollama rm qwen3:8b`

一套適合單卡的默認策略

如果你只有一張消費級顯卡，又經常在多個模型間切換，可以從這套策略開始：

1
2
3

OLLAMA_MAX_LOADED_MODELS=1
OLLAMA_KEEP_ALIVE=2m
OLLAMA_NUM_PARALLEL=1

然後按任務調用 qwen3-code、qwen3-write 或 Embedding 模型。需要運行大模型時，先執行 ollama stop 停掉不需要的模型；遇到長上下文或大文件，再把併發和常駐數量壓低。

這套配置的目標不是讓顯卡同時加載越多模型越好，而是讓每次切換可預測、顯存不會長期被遺忘的模型佔滿。

總結

Ollama 多模型切換的核心命令只有四個：

ollama ls
ollama run <模型名>
ollama ps
ollama stop <模型名>

想讓不同用途的模型更好管理，就用 Modelfile 創建別名；想控制加載和釋放，就用 keep_alive、OLLAMA_KEEP_ALIVE 與 OLLAMA_MAX_LOADED_MODELS。先按顯存決定可同時常駐的數量，再考慮多模型路由和併發，配置會穩定得多。

參考：

GPU顯存 on KnightLi的博客

消費級顯卡跑 Agent 成本怎麼算：電費、折舊與每任務成本

先確定你要算哪一種成本

月度總成本公式

一個可替換參數的示例

Agent 爲什麼比普通聊天更難估算

兩個必須同時看的單位

每個成功任務

每百萬 token

如何採集自己的數據

折舊該怎麼算纔不會誤導自己

與雲端 API 比較時，不要只比單價

一個實用的決策線

常見誤區

總結

NAS 部署 Ollama 性能夠不夠：CPU、內存和顯卡怎麼判斷

先確認你的 NAS 屬於哪一類

先把“存儲”和“推理”分開看

CPU-only NAS：什麼時候值得部署

內存至少要留多少

有 NVIDIA GPU 時，體驗差異最大

NAS 的核顯、NPU 和轉碼能力能直接用嗎

模型怎麼選纔不會把 NAS拖垮

建議的部署結構

部署前的五分鐘測試

網絡和安全不要忽略

總結

vLLM KV Cache 內存不夠怎麼辦：顯存、上下文和併發排查

先理解：KV Cache 爲什麼會佔滿顯存

先從日誌判斷是哪一種問題

第一優先級：降低 --max-model-len

第二優先級：限制併發和批處理

第三優先級：合理設置 --gpu-memory-utilization

FP8 KV Cache：省顯存前先確認模型和版本

手動指定 KV Cache 大小時要知道優先級

CPU offload 能解決什麼，不能解決什麼

一個可複製的排障模板

常見誤區

誤區一：模型支持長上下文，所以服務必須開滿

誤區二：把 gpu_memory_utilization 設成 1 就能解決

誤區三：只降低權重量化，不管併發

誤區四：CPU offload 一定比拒絕長請求好

總結

Ollama 多模型切換怎麼配置：常駐、顯存和 Modelfile 教程

最常用的切換命令

ollama ps：先看誰佔着顯存

默認常駐多久：5 分鐘

方法一：一次調用後立即卸載

方法二：讓模型長時間常駐

方法三：全局修改默認常駐時間

多模型常駐的關鍵：OLLAMA_MAX_LOADED_MODELS

不要忽略併發：上下文也會喫內存

用 Modelfile 給不同用途創建固定別名

給腳本或 API 按任務切換模型

Windows 下的常見坑

環境變量改了但沒生效

模型文件擠滿系統盤

以爲模型被刪了

一套適合單卡的默認策略

總結

第一優先級：降低 `--max-model-len`

第三優先級：合理設置 `--gpu-memory-utilization`

誤區二：把 `gpu_memory_utilization` 設成 1 就能解決

`ollama ps`：先看誰佔着顯存

多模型常駐的關鍵：`OLLAMA_MAX_LOADED_MODELS`