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`