本地 LLM 显存不足？用 gputaskman 查看权重与 KV 缓存

你的本地模型昨天还能正常加载，今天却在加载时崩溃或变得极慢，而你唯一改动过的就是上下文长度。常见的罪魁祸首是 KV 缓存，而一个名为 gputaskman 的免费终端工具可以让你直接看到它，而不是让你去猜。

典型的 GPU 监控工具只告诉你显存有多满。那是“是什么”，而不是“为什么”。gputaskman 的 README（2026 年 11 月 5 日查阅）自称“一个 htop，用于查看 GPU 内部有什么，而不只是它有多满。”这是一个早期的实验性项目，采用 MIT 许可证，所以请把它当作一个方便的观察视角，而不是最终结论。

究竟是什么占满了你的显存#

把显存想象成一个行李箱。里面装三样东西：

• 权重：模型本身。对于给定的模型和量化方式，大小固定。
• KV 缓存：模型对你对话的短期记忆。它随上下文增长而增长。
• 计算缓冲区：运行时在工作时需要的临时空间。

当人们说“模型放不下”时，他们通常是指权重放得下，但你额外要求的缓存放不下。这一区别决定了修复方法，而这正是普通监控工具所隐藏的。

安装 gputaskman 并按进程查看#

README 列出了三种安装方式：便携式 Windows ZIP、用 uv run --locked gputaskman 运行的克隆，或在 Python 3.11+ 虚拟环境中使用 pip。平台方面，按 README 的描述：

• Windows 10/11 64 位，配备 NVIDIA 或 AMD GPU（Releases 页面提供 x64 和 ARM64 ZIP）；
• Linux 和 WSL，配备 NVIDIA GPU（glibc 2.35+；WSL 可以读取 Windows 主机计数器）；
• macOS 仅支持 Apple Silicon，且只能从源码克隆运行，没有便携构建。

Windows ZIP 未签名。请只从官方仓库的 Releases 页面下载：github.com/shanselman/gputaskman。请从 README 复制准确的命令：该项目还很年轻，选项可能会变化。

运行起来后，有两个视图对这个问题很重要：

1. 设备视图：显存使用、GPU 活动、PCIe、温度、功耗、时钟和历史图表。适合回答“是不是有什么东西突然飙升了？”
2. 进程视图：每个进程的本地 GPU 内存、GPU 可访问的系统内存、引擎活动和检测到的运行时（CUDA、HIP、Vulkan、Direct3D、ggml、ONNX Runtime）。

在进程视图中，找到你的模型服务器（对于 Ollama，是它捆绑的 runner）。然后检查列表的其余部分。如果浏览器或游戏占用了几个 GB，你就找到了答案，而无需改动模型。

权重、KV 缓存、缓冲区：这些数字从哪来#

模型检查器会显示架构、量化方式和缓冲区大小（在可用时）。有一个重要的注意事项：根据 README，权重、KV 缓存和计算缓冲区来自运行时的加载日志（当启用了兼容的日志记录时）。对于 llama.cpp，用日志启动你自己的 llama-server（--log-file server.log -lv 4；README 说需要级别 4 才能获取缓冲区大小）。对于 Ollama，如果可用，gputaskman 使用 Ollama 的 server.log。否则，它们是根据 GGUF 元数据和上下文大小做出的估算，假设采用 llama.cpp 风格的放置方式。目前尚不支持在单个进程内按模型进行 KV 核算。

因此，把估算的拆分理解为“大致如此”，把基于日志的拆分理解为“运行时报告的内容”。对于 Ollama，README 说会检测捆绑的 runner，GGUF blob 根据 Ollama 的清单命名，并在可用时使用 server.log。对 LM Studio 的支持是部分的：模型根据其文件夹命名，并通过其本地 API 探测，但这是用固定响应测试的，而非端到端测试。

你还可以将两个快照保存为 JSON，并用 diff 命令进行比较。这是回答“当我从 4K 上下文切换到 16K 上下文时发生了什么变化？”的干净方法：拍一个快照，更改设置，重新加载，再拍一个。

该调哪个旋钮#

读取拆分结果给你的是一个决策，而不仅仅是一张图。

权重是大的那一块。 改用更小的量化或更小的模型。这是唯一能缩小权重的杠杆。如果你想了解背后的内存计算，请参阅一个 125B 模型能在 16 GB GPU 上运行吗？

KV 缓存是大的那一块。 缩短上下文。在 Ollama 中，你可以直接在会话中尝试：

ollama run <your-model>
>>> /set parameter num_ctx 8192

8192 只是一个示例值；选择你的任务真正需要的值（命令依据 Ollama 的文档，2026 年 11 月 5 日查阅）。

如果你之后在 llama.cpp 中使用量化缓存时，在提示处理上遇到奇怪的变慢，下一步请参阅这个针对 q5_1 KV 缓存的修复。至于上下文窗口本身能容纳什么，请阅读什么是上下文窗口？

另一个进程是大的那一块。 关闭它，或让它运行在集成 GPU 上。模型本身无需任何改动。

如果它不工作#

• 拆分看起来不对。 检查它是否是估算（没有兼容的加载日志）。对于 llama.cpp，用 --log-file server.log -lv 4 运行你的 llama-server 并重新加载模型。对于 Ollama，如果 server.log 存在，gputaskman 会使用它；在那里出现估算标签是正常的。
• LM Studio 显示的细节较少。 如上所述，支持是部分的。
• 没有 NVIDIA 或 AMD GPU。 该工具仅涵盖本地 GPU 工作负载；仅 CPU、仅 NPU 和云工作负载不在范围内。
• macOS。 从源码克隆运行；没有便携构建。

当托管模型是更简单的解决方案时#

假设你为一个任务需要长上下文，比如总结一份大文档，而你的 GPU 只能容纳短上下文的模型。你可以继续调优，或者把显存从画面中移除。对于这类任务，CheapTokens 提供 DeepSeek-V4-Flash：380K 上下文，每次回答最多 32,768 个输出 token，全天统一价格，通过 OpenAI 兼容 API 访问。GLM-5.3-Flash 有 390K 上下文和最多 8,192 个输出 token。

调用采用常见的 OpenAI 格式（将你的密钥放入环境变量）：

curl https://api.cheaptokens.dev/v1/chat/completions \
  -H "Authorization: Bearer $CHEAPTOKENS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "deepseek-ai/DeepSeek-V4-Flash-0731", "messages": [{"role": "user", "content": "Summarize this document: ..."}]}'

设置详情见文档。一个决策经验法则：如果一个任务持续需要更多上下文或比你的显卡能容纳的更大的模型，而进程视图显示你的显存已经使用得很充分，就把那个任务发送到 API，把小而快的任务留在本地。在本地运行 DeepSeek 还是使用 API？深入探讨了这一权衡。

假设你总结 100 份大文档，每份 60,000 个输入 token 和 1,000 个输出 token（完全在 380K 窗口内）。以下是今天的费用：

根据这些数字，每份文档 $0.001 是此类单次调用的实时价格，总计（输入和输出合计）低于 OpenRouter。