本地大模型 on KnightLi的博客

llama.cpp b9196 更新：Windows 预编译版支持 CUDA 13.1、Vulkan、HIP 和 SYCL

Mon, 18 May 2026 23:20:00 +0800

llama.cpp 最近的 Windows 版本对本地大模型用户更友好了。以前在 Windows 上跑 GGUF 模型，很多人卡在环境问题上：CUDA 版本不匹配、DLL 缺失、驱动不兼容、CMake 编译失败、环境变量错误，或者 Vulkan / HIP / SYCL 配置太麻烦。

现在官方 Release 已经提供多种 Windows 预编译包。很多场景下，用户不再需要从源码编译，下载对应版本、解压、放入模型文件后，就可以直接启动本地推理服务。

llama.cpp 适合做什么

llama.cpp 是目前最常用的本地 GGUF 模型推理框架之一。它的特点是轻量、跨平台，既能跑 CPU，也能利用 GPU，并且围绕 GGUF 生态积累了大量模型资源。

常见模型路线包括：

Qwen
Llama
DeepSeek
Gemma
Mistral
Mixtral
Hermes

随着 GGUF 量化模型越来越普及，很多开源模型都会提供适合本地部署的 GGUF 版本。对普通用户来说，llama.cpp 的价值主要在于：不用搭一整套复杂推理框架，也能在本机跑一个可用的聊天服务。

Windows 预编译版本怎么选

目前 Windows 用户可以根据硬件选择不同构建版本：

Windows x64 CPU
Windows x64 CUDA 12.4
Windows x64 CUDA 13.1
Windows x64 Vulkan
Windows x64 HIP Radeon
Windows x64 SYCL
Windows ARM64 CPU

如果是 NVIDIA 显卡，通常优先考虑 CUDA 版本。RTX 3060、4060、4070、4080、4090 这类显卡都更适合走 CUDA 路线。

如果是 AMD 显卡，可以尝试 HIP 或 Vulkan。实际体验里，Vulkan 的兼容性有时比 HIP 更省心，尤其适合不想折腾完整 ROCm 环境的用户。

如果是 Intel 核显或 Arc 独显，可以尝试 SYCL 或 Vulkan。性能通常不如 NVIDIA CUDA 路线，但跑一些中小型 GGUF 模型已经足够测试。

CPU 版本适合没有独显、只是想验证模型或跑小参数模型的用户。速度不会太快，但部署最简单。

启动普通 GGUF 模型

假设你已经下载好 llama.cpp Windows 预编译包，并把模型放到 models 目录。进入 llama.cpp 解压目录后，可以用类似命令启动：

`1`	`llama-server.exe -m models\your-model.gguf -ngl 999`

这里的 -m 指向 GGUF 模型文件，-ngl 999 表示尽量把模型层加载到 GPU。实际能加载多少，取决于显存容量、模型大小和量化格式。

启动成功后，在浏览器打开：

`1`	`http://127.0.0.1:8080`

就可以进入本地网页聊天界面。

如果显存不足，可以换更小的模型，或者换更低量化版本，例如 Q4、Q5 这类 GGUF 文件。不要只看模型参数量，也要看量化格式和上下文长度设置。

启动多模态视觉模型

多模态视觉模型通常不只需要一个主模型文件，还需要一个 mmproj 视觉投影文件。启动时要同时指定主模型和 mmproj：

`1`	`llama-server.exe -m "models\main-model.gguf" --mmproj "models\mmproj-model.gguf" -ngl 999`

常见用途包括：

OCR 识别
截图理解
网页截图分析
图片问答
简单视觉内容判断

例如 Qwen2-VL / Qwen2.5-VL 这类视觉模型，在中文截图理解、OCR 和图文问答上比较实用。使用时要注意主模型和 mmproj 文件是否匹配，版本不匹配很容易导致加载失败或效果异常。

用 bat 脚本管理多个模型

如果本地同时放了多个模型，可以写一个简单的 .bat 脚本做菜单切换。下面是一个示例，路径和模型名需要改成你自己的：

@echo off
chcp 65001 >nul
cd /d C:\path\to\llama-b9196-bin-win-cuda-13.1-x64

echo 请选择模型：
echo 1. Gemma
echo 2. Qwen VL 多模态
echo 3. DeepSeek

set /p choice=输入数字：

if "%choice%"=="1" llama-server.exe -m "models\gemma.gguf" -ngl 999
if "%choice%"=="2" llama-server.exe -m "models\qwen-vl.gguf" --mmproj "models\mmproj.gguf" -ngl 999
if "%choice%"=="3" llama-server.exe -m "models\deepseek.gguf" -ngl 999

pause

保存时建议使用 UTF-8 编码，再把文件后缀改成 .bat。这样双击脚本后，就可以通过数字选择不同模型。

模型选择要看三件事

第一，看硬件。显存越大，能跑的模型越大；显存不足时，不要硬上大模型，可以先从 7B、8B 或更低量化版本开始。

第二，看用途。如果只是日常问答、总结、改写，小模型和中等量化通常够用。如果要做代码、长文档分析或多模态理解，就需要更强模型和更多显存。

第三，看许可证和安全边界。网上有很多社区改版模型，能力、限制和许可证都不一样。下载前要确认来源、授权、适用场景和风险，不建议把生产任务直接交给来源不明的模型。

常见问题

如果启动时报 DLL 缺失，先确认下载的包和显卡路线是否匹配。例如 NVIDIA 用户不要误下载 HIP 版本，AMD 用户也不要下载 CUDA 版本。

如果模型加载很慢，可能是模型太大、硬盘速度慢，或者显存不足导致部分层回落到 CPU。

如果网页打不开，先看命令行是否已经成功启动服务，再确认端口是不是 8080。如果端口被占用，可以查阅 llama-server 参数换端口。

如果多模态模型效果不对，优先检查 mmproj 文件是否和主模型配套，而不是只换提示词。

小结

这次 Windows 预编译包的价值在于降低了本地 AI 的入门门槛。以前很多用户卡在编译和依赖环境，现在可以更快进入“下载模型、启动服务、测试效果”的阶段。

对 Windows 用户来说，选择路线可以简单理解为：

NVIDIA：优先 CUDA。
AMD：优先尝试 Vulkan，再看 HIP。
Intel：尝试 SYCL 或 Vulkan。
没有独显：用 CPU 版本跑小模型。

真正使用前，仍然要确认模型来源、许可证、显存需求和实际效果。本地 AI 的好处是可控、离线、低延迟，但它不等于没有成本：模型管理、硬件资源和输出质量都需要自己负责。

参考来源：https://www.freedidi.com/24211.html

Claude Code + Ollama 本地部署教程：用 CC Switch 打造免费 AI 编程助手

Fri, 15 May 2026 23:27:50 +0800

最近 Claude Code 在 AI 开发工具圈很火，原因不难理解：它不像普通聊天机器人那样只回答问题，而是可以读取项目、修改代码、执行终端命令、安装依赖，并尝试自动修复报错。

真正的问题在成本。Claude 官方 API 在长上下文、大型项目、多轮 Agent 调用和自动修 Bug 场景下，Token 消耗会很快变大。于是出现了一种新的玩法：继续使用 Claude Code 的 Agent 外壳，但把模型请求转发给本地 Ollama。

这条链路的关键工具是 CC Switch。

这套方案解决什么问题

可以把它理解为：

1
2
3

Claude Code 桌面版
+ CC Switch API 转发层
+ Ollama 本地模型

Claude Code 继续负责项目操作、终端执行、文件修改和 Agent 流程；真正负责推理的大模型，则换成本地运行的 Qwen、DeepSeek、Gemma、GLM 等模型。

这样做的吸引力很直接：

不依赖 Claude 官方 API。
没有持续 Token 计费压力。
模型和数据可以留在本机。
小项目、脚本、网页、运维任务可以低成本反复试。

但它不是“免费获得 Claude Sonnet 能力”。本地模型的工程理解、长上下文稳定性和复杂任务规划，仍然会受模型能力、显存、量化版本和上下文长度限制。

基本准备

前置环境主要包括：

安装 Git。
安装 Claude Code 官方桌面版。
安装最新版 Ollama 客户端。
下载 CC Switch 开源工具。
在 Ollama 中准备合适的本地模型。

模型选择可以按显存来定。常见选择包括：

Qwen 3.6 / Qwen 3.5
Gemma4
DeepSeek R1
GLM

如果显存不大，优先选择较小参数或较低量化版本。不要一开始就用超大模型，否则很容易出现加载慢、上下文短、响应卡顿或直接显存不足。

CC Switch 关键配置

这套方案里最关键的配置项是下面几项。

请求地址：

`1`	`http://127.0.0.1:11434/v1`

API 格式：

`1`	`OpenAI Chat Completions`

认证字段选择：

`1`	`ANTHROPIC_API_KEY`

Claude Code 桌面版的自定义配置文件末尾，还需要加入注册表修改命令：

`1`	`"inferenceModels"="[\"haiku\",\"sonnet\",\"opus\"]"`

这一步的作用，是让 CC Switch 把模型名称注入到 Claude Code 里显示。Claude Code 以为自己在调用 Claude 模型，实际请求已经被 CC Switch 转发到了本地 Ollama。

Claude Code 强在哪里

很多人第一次接触 Claude Code，会把它当成高级聊天工具。但它和普通 AI 聊天客户端不太一样。

普通聊天式 AI 通常是：

1
2

你问一句
它答一句

Claude Code 更接近：

`1`	`AI + IDE + Terminal`

它可以读取项目结构，例如：

src/
components/
package.json
docker-compose.yml

然后尝试完成一串操作：

分析代码。
修改文件。
安装依赖。
执行命令。
查看报错。
再次修改。
重新运行项目。

这也是为什么很多开发者把它叫做 AI 开发 Agent。它的价值不只是“写一段代码”，而是能围绕项目状态连续行动。

Ollama 在这里扮演什么角色

Ollama 负责在本机运行模型。

这套组合的核心逻辑是：

Claude Code 负责 Agent 能力和项目操作。
CC Switch 负责把 Claude Code 的请求转成兼容本地模型的 API。
Ollama 负责实际推理。
本地模型返回结果后，再交给 Claude Code 继续执行。

所以，这不是把 Ollama 变成一个普通聊天窗口，而是把它接进 Claude Code 的工作流。

对于小型任务，这种组合会很有吸引力。比如：

生成一个 HTML 页面。
修改小型前端项目。
写自动化脚本。
处理 Docker 配置。
做 VPS 运维辅助。
生成简单工具或测试代码。

类似“帮我生成一个赛博朋克风格的个人主页网站”这类任务，本地模型可以完成项目创建、网页生成、动画和特效配置，并尝试自动运行。

体验边界在哪里

这套玩法很有意思，但边界也要说清楚。

目前本地模型仍然很难完全替代 Claude Sonnet，尤其在这些场景里：

长上下文理解。
大型工程结构分析。
多步骤推理。
复杂项目架构调整。
长时间连续修 Bug。

项目一复杂，本地模型更容易出现：

逻辑混乱。
修改错误文件。
反复修同一个 Bug。
忘记前文上下文。
对项目结构判断不稳定。

所以更合理的定位是：它适合低成本试验、小项目、脚本任务和局部代码修改；不适合一开始就把大型生产项目完全交给它自动改。

多模态兼容性还不稳定

这套链路还有一个明显问题：Vision 多模态兼容性。

虽然 Ollama 已经支持一些 Vision 模型，但 Claude Code + CC Switch + Ollama 这条链路对图片支持并不完整。常见情况是：用户上传了图片，但 AI 仍提示没有看到图片。

这并不一定是模型不支持 Vision，而是整条链路里：

Claude Code 更偏代码 Agent。
CC Switch 主要处理 API 转发。
Ollama 模型能力和请求格式还要匹配。
图片输入在不同客户端和模型之间并不总是无缝传递。

所以目前更适合的场景还是：

编程。
终端操作。
项目文件修改。
自动化脚本。

而不是：

图片理解。
OCR。
多模态聊天。
复杂视觉任务。

适合谁尝试

这套方案适合几类人：

想体验 Claude Code Agent 工作流，但不想持续消耗 Claude API 的用户。
已经在本机跑 Ollama 的本地大模型玩家。
做小项目、脚本、网页、运维工具的开发者。
想测试本地模型真实编程能力的人。
对数据本地化更敏感的用户。

不太适合：

完全不想折腾配置的人。
希望获得 Claude Sonnet 同等能力的人。
需要稳定处理大型生产代码库的人。
强依赖图片输入和多模态能力的人。

使用建议

如果要尝试，建议按低风险方式开始：

先用测试项目，不要直接接生产仓库。
选择中小模型，确认 Ollama 本身运行稳定。
先做 HTML、脚本、配置文件这类简单任务。
每次修改后自己检查 git diff。
不要让它在不确认的情况下批量删除或重构文件。
多模态任务暂时不要依赖这条链路。

如果项目比较复杂，最好把任务拆小：让它只改一个模块、一个函数、一个页面或一个配置文件。这样比“一句话让它重构整个项目”可靠得多。

小结

Claude Code + Ollama + CC Switch 的意义，不是让本地模型立刻变成 Claude Sonnet，而是把本地模型接进一个真正能操作项目的 Agent 外壳里。

这让本地 AI 开发助手第一次变得更接近真实生产力工具：它可以看项目、改文件、跑命令、修错误，而不是只在聊天框里给建议。

但它的能力上限仍然取决于本地模型本身。小项目和自动化任务会很有价值；大型工程、长上下文和复杂推理仍然需要更强模型。

如果你的目标是“零 API 成本、无 Token 焦虑、在本机反复试 AI 编程 Agent”，这套方案值得折腾。只是要记住：它是本地开发助手，不是万能自动程序员。

本地运行 DeepSeek 4：Antirez ds4 在 Apple Silicon Mac 上的尝试

Mon, 11 May 2026 08:51:37 +0800

Antirez 开源了一个新项目：ds4。它不是通用 LLM 框架，而是一个面向 DeepSeek V4 Flash 的本地推理引擎，重点放在 Apple Silicon 和 Metal 后端上。

项目地址：https://github.com/antirez/ds4

ds4 是什么

ds4 的目标很明确：在 Mac 上本地运行 DeepSeek V4 Flash。

它当前提供三种使用方式：

交互式 CLI。
HTTP server。
一个实验性的 Agent 模式。

从定位看，它更像是一个针对特定模型深度优化的推理项目，而不是要替代 llama.cpp、Ollama 或 vLLM 这类通用工具。

为什么值得关注

这类项目值得看，主要有三个原因。

第一，作者是 Redis 作者 Antirez。他长期关注底层系统、性能和简单工具，项目风格通常比较直接。

第二，DeepSeek V4 Flash 属于面向高效推理的模型方向。如果本地运行体验足够好，对 Mac 用户来说会很有吸引力。

第三，ds4 直接面向 Apple Metal。相比“先支持所有平台，再慢慢优化”的路线，它更像是先把一个明确场景做深。

适合谁用

ds4 更适合这几类用户：

使用 Apple Silicon Mac。
想在本地运行 DeepSeek V4 Flash。
关注 Metal 推理性能。
愿意尝试 alpha 阶段项目。
想研究轻量推理引擎和模型运行细节。

如果你的目标是稳定部署、跨平台运行、OpenAI API 兼容生态，现阶段它未必是首选。它更适合作为实验工具和技术观察对象。

使用方式

项目 README 给出的基本流程是先构建，再运行。

1
2
3

git clone https://github.com/antirez/ds4.git
cd ds4
make

交互式运行：

./ds4

启动 HTTP server：

`1`	`./ds4 --server`

Agent 模式：

`1`	`./ds4 --agent`

具体参数和模型文件准备方式，建议以仓库 README 为准，因为项目仍在快速变化。

目前的风险

ds4 还处在早期阶段，使用前要有预期：

功能可能不完整。
参数、模型格式和命令行行为可能变化。
兼容性主要围绕 Apple Silicon 和 Metal。
Agent 模式更偏实验，不适合直接用于生产流程。
遇到问题时，需要自己阅读 README、issue 或源码排查。

也就是说，它现在更像“值得动手试的开源实验”，还不是面向普通用户的一键工具。

和通用推理工具的区别

通用推理工具通常追求模型格式、平台、后端和 API 的广泛兼容。ds4 的方向更窄：围绕 DeepSeek V4 Flash 和 Metal 做本地运行。

这种选择有利有弊。

好处是实现可以更集中，性能和体验更容易围绕单一目标优化。代价是适用范围有限，不适合拿来运行各种不同模型，也不适合替代完整的部署平台。

如果你已经在用 llama.cpp 或 Ollama，ds4 可以作为补充测试工具，而不是马上替换现有工作流。

小结

ds4 的看点不在“又一个本地大模型工具”，而在于它把范围收得很窄：DeepSeek V4 Flash、Apple Silicon、Metal、本地推理。

如果你手上有合适的 Mac，并且愿意折腾早期项目，可以关注它后续的性能表现、模型支持方式和 server/agent 能力演进。对于生产环境，建议继续观望，等接口和使用方式稳定后再评估。

参考

GitHub 项目：https://github.com/antirez/ds4

llama.cpp 多 GPU 性能实测思路：2x V100 16GB 会比单卡 32GB 快吗？

Sat, 09 May 2026 15:05:41 +0800

大概结论：llama.cpp 多 GPU offload 不是“多一张卡就白捡一倍性能”。如果模型本来能完整放进一张 32GB 显卡，2x V100 16GB 通常不如单张 32GB 显卡省心，甚至可能更慢；如果模型单张 16GB 放不下，双卡的主要价值是“能把模型放进 GPU”，这时收益会很明显。

先分清 split mode

llama.cpp 的多 GPU 主要围绕 --split-mode 和 --tensor-split 使用。实际讨论性能时，先要区分几种模式：

layer：按层切分到不同 GPU，兼容性较好，也是多数人优先尝试的方式。
tensor：把张量计算拆到多张 GPU 上，更接近并行计算，但更依赖 GPU 之间的互联带宽和后端支持。
row：旧的行切分方式，在不少场景里仍能看到，但新部署通常不建议优先从它开始。

简单说，layer 更像“把不同楼层放在不同卡上”，单 token 生成时不一定能让两张卡同时满负载；tensor 更像“同一层两张卡一起算”，理论上更能并行，但跨卡通信会成为关键瓶颈。

单卡 32GB 能放下时：双 16GB 不一定更快

如果模型和 KV cache 能完整放进一张 32GB 显卡，那么单卡通常更稳，也常常更快。对 1x V100 32GB 和 2x V100 16GB 这类同代硬件来说，后者未必能赢。

比较保守的预期是：2x V100 16GB 可能比单张 V100 32GB 慢 10% 到 40%，尤其是单人聊天、Continue Agent、代码问答这类一次主要生成一个回答的场景。

原因不复杂：多 GPU 不是简单合并显存。按层切分时，推理会在不同 GPU 之间流转，单 token 生成阶段经常是部分 GPU 等另一部分 GPU；按张量切分时，两张卡可以一起算，但中间结果需要跨卡同步，互联带宽和延迟会直接影响吞吐。

所以如果你的选择是：

1x V100 32GB
2x V100 16GB

并且目标模型单张 32GB 已经能完整放下，那么单张 32GB 往往是更舒服的选择。

单卡 16GB 放不下时：双卡价值很大

另一种情况完全不同：模型单张 16GB 放不下，但两张 16GB 合起来可以放下。

这时双卡的价值就很直接：

单张 16GB：可能需要大量 CPU offload，速度明显变慢。
2x 16GB：权重尽量留在 GPU 上，速度可能比 CPU/GPU 混跑快很多。

这种场景下，2x V100 16GB 不一定比单张 32GB 快，但它可能比“单张 16GB 加大量系统内存 offload”快几倍。也就是说，双卡的第一价值不是加速，而是避免模型被迫落到更慢的系统内存里。

V100 PCIe 和 V100 SXM2 差别很大

多 GPU 推理最容易被忽略的是互联。

如果是 V100 SXM2，并且机器里有 NVLink，跨卡通信带宽高很多。NVIDIA 的 V100 资料里，NVLink 互联最高可到 300GB/s。这种环境下，tensor 或更高 batch 的场景才更有机会接近甚至超过单卡表现。

如果是 V100 PCIe，情况就保守得多。V100 PCIe 的互联主要走 PCIe Gen3，资料里标的 interconnect bandwidth 是 32GB/s。这个带宽和 NVLink 不是一个量级，所以双卡经常出现“显存够了，但速度没有翻倍”的情况。

因此判断 2x V100 16GB 值不值得，不能只看显存相加是 32GB，还要看它们是 PCIe 版还是 SXM2/NVLink 版。

怎么选更实际

如果模型能放进单张 32GB 显卡，优先选单卡。它的延迟、稳定性和调参成本通常更好。

如果模型单张 16GB 放不下，而两张 16GB 能放下，双卡值得用。此时重点是让权重尽量留在 GPU，而不是期待性能线性翻倍。

如果是 V100 PCIe 双卡，优先尝试 --split-mode layer，把目标放在“能稳定跑”和“少走 CPU”上。

如果是 V100 SXM2/NVLink，才更值得测试 tensor 相关模式，尤其是 prefill、大 batch 或并发请求场景。

什么时候买 2x16GB，什么时候买 1x32GB

如果你只服务一个人，主要做聊天、代码补全、Continue Agent、长上下文问答，并且目标模型能放进 32GB，那么 1x32GB 通常更值得。它少了跨卡调度，延迟更稳定，排查问题也简单。

如果你已经有一张 16GB 卡，想用较低成本扩到能跑 30B、32B 或更高量化模型，2x16GB 就有意义。它不一定让 token/s 翻倍，但可以把原本必须 CPU offload 的权重留在 GPU 上。

如果你准备重新采购，优先级可以这样排：

单模型、单用户、重视响应延迟：优先 1x32GB。
模型单卡放不下、预算有限：可以考虑 2x16GB。
有 NVLink 或 SXM2 机器：2x16GB 的可玩性明显高于普通 PCIe 双卡。
未来想跑更长上下文：不要只看权重大小，还要预留 KV cache 显存。

layer split 和 tensor split 怎么用

实用建议是：先用 layer，再测 tensor。

layer 适合作为默认起点。它按层分配模型，兼容性较好，对 PCIe 双卡更友好。缺点是生成阶段可能更像流水线，某些时刻只有一张卡在忙，另一张卡在等。

tensor 更适合互联带宽好的机器，例如 V100 SXM2/NVLink。它把同一层的部分计算拆到多张卡上，理论上更有并行空间，但跨卡同步更频繁。如果是 PCIe 双卡，tensor 可能会被通信开销吃掉收益。

实际测试时可以从这几组开始：

1
2
3

llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,1
llama-bench -m model.gguf -ngl 99 --split-mode tensor --tensor-split 1,1
llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,0

第三条不是为了长期使用，而是给单卡结果做一个参照。这样才能看出双卡到底是更快，还是只是把显存压力分摊出去了。

prefill 和 decode 为什么表现不同

本地大模型性能通常要分成两个阶段看：

prefill：处理输入 prompt，典型指标是 pp512 这类 prompt processing 吞吐。
decode：逐 token 生成回答，典型指标是 tg128 这类 token generation 吞吐。

prefill 更像大批量矩阵计算，batch 较大时更容易把 GPU 喂饱，也更可能从多 GPU 并行里受益。decode 是一个 token 接一个 token 生成，batch 小、同步频繁，跨卡通信和调度延迟更容易暴露出来。

所以你可能会看到一种结果：双卡的 pp512 更好，但 tg128 没明显提升，甚至更慢。对聊天和 Agent 来说，用户体感更接近 tg128；对长文档导入、批量预填充、并发服务来说，pp512 也很重要。

KV cache 会不会成为第二个显存瓶颈

会。很多人只算模型权重，忘了 KV cache。

模型权重决定“能不能加载模型”，KV cache 决定“能不能开足上下文”。上下文越长、并发越高、batch 越大，KV cache 占用越明显。你可能遇到这种情况：模型本体能放进 32GB，但一开 32K 或 64K 上下文，显存又不够了。

判断时至少要留出几块显存余量：

KV cache
CUDA graph 或后端运行时开销
prompt batch 和 ubatch
系统桌面、驱动和其它进程占用

如果你用的是 2x16GB，显存不是一个完全等价的 32GB 大池子。某些缓冲区、KV cache 或中间张量仍然会受单卡剩余显存影响。测试长上下文时，最好直接用目标 --ctx-size 和目标并发数测，而不是只看模型能不能启动。

用 llama-bench 做自己的双卡测试

llama-bench 比直接聊天更适合做硬件对比，因为它会把 prompt processing 和 token generation 拆成可比较的指标。官方 README 的默认示例就是：

`1`	`llama-bench -m model.gguf`

对双 V100，可以至少测这几组：

# 单卡基线
CUDA_VISIBLE_DEVICES=0 llama-bench -m model.gguf -ngl 99

# 双卡 layer split
CUDA_VISIBLE_DEVICES=0,1 llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,1

# 双卡 tensor split
CUDA_VISIBLE_DEVICES=0,1 llama-bench -m model.gguf -ngl 99 --split-mode tensor --tensor-split 1,1

重点看两列：

pp512：prompt processing，长输入和批量预填充更相关。
tg128：token generation，单人聊天和 Agent 体感更相关。

测试时尽量固定模型、量化格式、上下文、batch、驱动版本和 llama.cpp 版本。每组多跑几次，取中位数，比只看一次结果可靠。最后再用真实工作流跑一遍，例如 Continue Agent、OpenAI-compatible server 或你自己的 RAG 请求，因为 benchmark 好看不代表交互体验一定更好。

一句话结论

2x V100 16GB 的优势主要是显存容量，而不是必然的生成速度。模型单卡能放下时，单张 32GB 往往更快、更稳；模型单卡放不下时，双 16GB 的价值就很大，因为它能避免大量 CPU offload。至于能不能更快，关键看 split mode、batch、模型大小，以及两张 V100 之间到底是 PCIe 还是 NVLink。

参考资料：

RTX 5090 / 5080 AI 推理性能实测：本地大模型、4K 视频生成和实时 3D 怎么选

Fri, 08 May 2026 10:07:19 +0800

RTX 50 系列真正让本地 AI 用户兴奋的，不只是游戏帧率，而是 Blackwell 架构、GDDR7 显存和第五代 Tensor Core 带来的推理潜力。对跑本地大模型、图像生成、视频增强和实时 3D 工作流的人来说，显卡已经不只是渲染设备，而是桌面级 AI 工作站的核心。

但 RTX 5090 和 RTX 5080 的差距不能只看型号。它们都属于 Blackwell，都支持 DLSS 4、第五代 Tensor Core 和 FP4，但在本地 AI 推理里，真正决定体验的往往是显存容量、显存带宽、软件支持和具体模型适配。

简单结论是：RTX 5090 更像单卡本地 AI 的旗舰选择，适合大模型、长上下文、图像生成和视频 AI；RTX 5080 更适合预算有限、模型规模较小、以 16GB 显存可覆盖的工作流。两者都比上一代有进步，但不是所有 AI 应用都会立刻吃满 Blackwell 的新能力。

先看硬件差距

RTX 5090 的关键规格是 32GB GDDR7、512-bit 显存位宽、21760 个 CUDA Core 和 3352 AI TOPS。公开测试中，Puget Systems 也强调它的显存带宽达到约 1.79TB/s，相比 RTX 4090 的 24GB 和约 1.01TB/s 带宽，对 AI 工作负载很有意义。

RTX 5080 的规格则更克制：16GB GDDR7、256-bit 显存位宽、10752 个 CUDA Core 和 1801 AI TOPS。它的带宽约 960GB/s，比 RTX 4080 系列提升明显，但显存容量仍停在 16GB。

这意味着两张卡的定位非常清楚：

RTX 5090 的优势是 32GB 显存和高带宽，适合更大的模型、更长上下文和更重的多模态任务。
RTX 5080 的优势是价格和能耗相对可控，适合中小模型、图像生成、轻量视频处理和开发调试。
如果任务已经被显存卡住，RTX 5080 的计算能力再强也很难弥补 16GB 的限制。
如果任务主要受软件优化限制，RTX 5090 也未必总能比 RTX 4090 拉开理论规格对应的差距。

本地 AI 推理经常是“显存先决定能不能跑，带宽再决定跑得快不快”。这也是 RTX 5090 对本地大模型用户吸引力更强的原因。

本地大模型：32GB 显存更关键

跑 LLM 时，显存主要被三类东西占用：模型权重、KV cache 和运行时开销。模型越大、上下文越长、并发越高，显存压力越明显。

RTX 5080 的 16GB 显存可以覆盖不少 7B、8B、14B 级别模型，也能通过 4-bit 量化运行一部分更大的模型。但当用户想跑 30B 级别模型、提高上下文长度，或者同时开 WebUI、RAG、语音和工具调用时，16GB 很容易变成瓶颈。

RTX 5090 的 32GB 显存给了本地推理更多空间。它更适合：

运行 30B 左右的量化大模型。
在 7B、14B 模型上保留更长上下文。
做本地代码助手、知识库问答和 Agent 调试。
同时加载嵌入模型、重排模型或多模态组件。
在单机环境里减少频繁换模型和降上下文的麻烦。

不过，32GB 也不是万能。70B 级别模型即使用 4-bit 量化，也常常需要更谨慎地控制上下文、运行参数和显存碎片。想要高并发服务，多卡或服务器 GPU 仍然更合适。

如果只是个人使用，RTX 5090 的体验优势主要体现在“少折腾”：可选模型更多，长上下文更宽松，图形界面和周边工具也更容易同时运行。

FP4 是潜力，不是所有应用的即插即用加速

Blackwell 的重要变化之一是第五代 Tensor Core 支持 FP4。NVIDIA 在 TensorRT 相关资料中提到，FP4 可以降低模型的显存占用和数据搬运压力，并用于 FLUX 等生成式模型的本地推理优化。

这对图像生成和未来的大模型推理很重要。低精度不仅意味着更少显存，也意味着更低带宽压力。对于 RTX 5090 这种高带宽显卡，FP4 如果被框架和模型充分支持，理论上会进一步放大优势。

但现实是，FP4 的收益取决于软件链路：

模型是否有合适的 FP4 量化版本。
推理框架是否支持对应算子。
TensorRT、ComfyUI、PyTorch、ONNX 或插件是否完成适配。
精度损失是否能被具体任务接受。
用户是否愿意为了性能调整工作流。

所以现在评价 RTX 50 系列 AI 性能，不能只看 FP4 峰值。更稳妥的判断是：Blackwell 给了 FP4 硬件基础，但实际体验要看应用更新速度。早期使用者会先吃到部分收益，主流用户需要等待生态成熟。

图像生成和 4K 视频：带宽与显存一起决定体验

Stable Diffusion、FLUX、视频超分、插帧、去噪、抠像和生成式视频都对显存敏感。分辨率越高，显存占用越大；节点越多，运行时开销越高；同时启用 ControlNet、LoRA、高清修复和批量生成时，显存压力会继续上升。

RTX 5080 在 16GB 显存内可以完成很多图像生成任务。对 1024px 级别图像、轻量 LoRA、常规 ComfyUI 工作流来说，它已经足够快。问题出现在更大的画布、更复杂节点、更高 batch，或者视频生成这类长序列任务里。

RTX 5090 的优势在 4K 视频相关工作流里更明显：

32GB 显存更适合高分辨率帧、长序列和复杂节点图。
1.79TB/s 级别带宽有利于减少数据搬运瓶颈。
三个第九代 NVENC 编码器对视频导出、转码和创作流程更友好。
FP4 和 TensorRT 适配成熟后，图像生成模型可能获得更明显收益。

不过，公开视频 AI 实测也提醒了一点：应用优化还没完全跟上硬件。Puget Systems 在 DaVinci Resolve AI 和 Topaz Video AI 测试中发现，RTX 5090 并不是每个项目都能大幅领先 RTX 4090，RTX 5080 也没有总是拉开 RTX 4080 系列。这说明视频 AI 不是单纯堆规格，插件、驱动和模型实现同样重要。

换句话说，如果你的工作流已经明确支持 Blackwell、TensorRT 或 FP4，RTX 50 系列更值得期待；如果主要依赖还没优化的商业软件，升级收益要看具体版本。

实时 3D 和 AI 建模：RTX 5090 更适合重场景

实时 3D 建模、神经渲染、3D 资产生成和视口 AI 加速通常会同时消耗 CUDA、RT Core、Tensor Core 和显存。它和纯 LLM 不同，不只是 token 生成速度，还包括场景复杂度、材质、几何、光追、AI 降噪和视口帧率。

RTX 5080 可以胜任很多 4K 游戏、实时预览和中等规模创作项目。对独立创作者来说，它是比较现实的高性能选择。

RTX 5090 更适合下面几类场景：

复杂 3D 场景实时预览。
高分辨率材质和大规模资产。
AI 降噪、超分和生成式辅助建模同时开启。
D5 Render、Blender、Unreal Engine 等工具中的重负载工作。
需要边建模边运行本地 AI 助手或图像参考生成。

NVIDIA 宣称 RTX 50 系列在创作应用中可提升生成式 AI、视频编辑和 3D 渲染效率，但实际项目里仍要看软件是否调用到了新硬件路径。对生产环境来说，最可靠的办法仍然是用自己的项目文件测试，而不是只看宣传图表。

该怎么选

如果你的目标是本地大模型，优先看显存。16GB 的 RTX 5080 可以跑很多轻量模型，但更像“高性能入门本地 AI 卡”；32GB 的 RTX 5090 才更接近“单卡本地大模型工作站”。

如果你的目标是图像生成，RTX 5080 已经能覆盖很多日常工作流；如果你经常做高分辨率、多节点、批量生成、FLUX 或视频生成，RTX 5090 的显存余量更重要。

如果你的目标是 4K 视频 AI，RTX 5090 更稳，但要确认具体软件版本。Topaz、DaVinci Resolve、ComfyUI、TensorRT 插件和驱动版本都可能影响结果。

如果你的目标是实时 3D 建模，RTX 5080 可以满足很多创作需求；RTX 5090 更适合重场景、多应用并行和长时间生产。

如果你已经有 RTX 4090，升级要谨慎。RTX 5090 的显存和带宽更强，但部分现有 AI 软件还未完全释放 Blackwell 优势。除非你明确需要 32GB 显存、更高带宽或新编码器，否则可以等软件生态再成熟一些。

如果你还在使用 RTX 30 系列或更老显卡，RTX 50 系列的升级感会明显很多。尤其是从 8GB、10GB、12GB 显存升级到 16GB 或 32GB，本地 AI 的可用范围会直接扩大。

小结

RTX 5090 和 RTX 5080 都把消费级显卡推向了更强的本地 AI 时代，但它们适合的人并不一样。

RTX 5090 的价值在于 32GB GDDR7、超高显存带宽和更完整的创作硬件配置。它适合想在单机上跑更大模型、更复杂图像生成、更重视频 AI 和实时 3D 工作流的人。

RTX 5080 的价值在于用相对低的成本进入 Blackwell 平台。它适合 16GB 显存能覆盖的中小模型、日常图像生成、开发测试和高性能创作。

真正的选购原则很简单：先看你的模型和项目能不能放进显存，再看软件是否已经优化 Blackwell，最后才看理论 AI TOPS。对本地 AI 来说，能稳定跑完，比峰值数字更重要。

参考资料

DeepSeek V4 本地私有化部署方案：国产芯片与消费级显卡集群怎么选

Fri, 08 May 2026 09:39:35 +0800

DeepSeek V4 发布后，很多企业开始关注一个问题：能不能不走外部 API，把模型部署在自己的机房、私有云或专有集群里？

这个需求很现实。金融、医疗、政企、制造、法律和研发团队往往不能把内部文档、代码、合同、工单、客户数据直接发到公有云模型。对这些场景来说，DeepSeek V4 的吸引力不只是模型能力，而是它给了企业一个更接近“可控大模型基础设施”的选择。

不过，DeepSeek V4 本地部署不是下载模型、找几张显卡就能跑起来。尤其是 Pro 这类超大 MoE 模型，总参数规模、激活参数、上下文长度、KV cache、并发量和推理框架都会直接决定硬件成本。企业真正要做的不是盲目追求满血版本，而是先确认业务需要哪种部署形态。

先明确部署目标

企业做本地私有化部署，常见目标有三类：

数据不出域：内部文档、代码、客户资料、日志和知识库不离开企业环境。
稳定可控：模型服务、权限、审计、日志和升级节奏由企业自己掌握。
降低长期成本：高频调用时，本地推理可能比长期购买外部 API 更可控。

如果只是少量员工偶尔问答，本地部署不一定划算。真正适合私有化的是高频、稳定、数据敏感、流程明确的场景，例如：

内部知识库问答。
代码审查和研发助手。
客服工单总结。
合同、病历、报告等文档分析。
数据库查询助手。
Agent 工作流自动化。

这些场景的共同点是：数据敏感、调用稳定、可通过权限和日志纳入企业治理。

不要一上来就追求满血 Pro

DeepSeek V4 常见版本包括 Pro 和 Flash。公开资料中，Pro 面向更强推理和复杂 Agent 任务，Flash 更强调成本和响应速度。企业选型时，不应默认所有业务都上 Pro。

可以按任务复杂度分层：

简单问答、摘要、分类、标签生成：优先考虑 Flash 或更小模型。
内部知识库检索增强：Flash 足够覆盖大量场景，重点反而是 RAG、权限和检索质量。
代码 Agent、复杂推理、长上下文分析：再评估 Pro。
高价值低频任务：可以使用 Pro，但不一定需要高并发。
普通办公助手：没有必要长期占用最贵的推理资源。

MoE 模型的优势在于每次推理只激活部分参数，但它并不等于硬件压力很小。权重存储、专家并行、网络通信、上下文缓存和并发调度仍然很重。尤其是 1M token 级别长上下文，真正吃掉资源的往往不是单次回答，而是长上下文、多用户并发和持续会话。

国产芯片路线：适合企业级私有云

如果企业已经有国产算力池，或者有信创、合规、供应链要求，可以优先评估昇腾、寒武纪等国产芯片路线。

这条路线的优势是：

更符合国产化和供应链可控要求。
适合进入企业机房、专有云和政企项目。
便于统一做权限、审计、资源隔离和运维。
对长期稳定服务更友好。

但国产芯片路线也要看三个现实问题。

第一，框架适配。模型能不能跑，不只取决于芯片算力，还取决于推理框架、算子、通信库、量化格式、MoE 专家并行和长上下文优化是否成熟。

第二，工程经验。企业需要的不只是“启动成功”，而是稳定服务：多租户、限流、监控、失败恢复、灰度升级、日志审计、权限隔离都要补齐。

第三，生态差异。同一套模型在 NVIDIA、昇腾、寒武纪等平台上的性能、精度、量化支持和部署工具不会完全一致。上线前必须做实际压测，而不是只看标称算力。

因此，国产芯片更适合预算明确、合规要求高、愿意投入平台工程的企业。它不是最省事的路线，但可能是最符合长期治理要求的路线。

消费级显卡集群：适合试点和中小团队

如果目标是先验证业务价值，消费级显卡集群更容易起步。RTX 4090、RTX 5090、RTX 3090、RTX 3060 12GB 这类显卡在社区工具、量化模型和本地推理框架上资料更多，试错成本更低。

消费级显卡路线适合：

研发团队做内部试点。
中小企业做知识库问答。
低并发代码助手。
离线文档处理。
对 SLA 要求不高的内部工具。

但它也有明显限制：

显存小，难以直接承载完整大模型。
多卡通信能力弱，跨机器通信更麻烦。
消费级硬件长期满载稳定性不如服务器方案。
机箱、电源、散热、驱动和运维会变成隐性成本。
不适合一开始就承诺企业级高可用。

更现实的做法是：消费级显卡先跑 Flash、蒸馏版、量化版或小模型，把业务流程跑通；等调用量、效果和数据治理都验证后，再决定是否迁移到服务器 GPU 或国产算力平台。

可能的部署架构

一个比较稳的企业私有化架构可以分成六层：

模型层：DeepSeek V4 Pro、V4 Flash，或根据任务选择更小的蒸馏模型。
推理层：SGLang、vLLM、llama.cpp、厂商 NPU 推理栈或企业自研服务。
网关层：统一鉴权、限流、审计、模型路由和调用日志。
知识层：向量库、全文检索、文档解析、权限过滤和 RAG。
应用层：客服、代码助手、文档分析、报表问答、Agent 工作流。
运维层：监控、告警、成本统计、灰度发布、回滚和安全审计。

这里最容易被低估的是网关层和知识层。很多项目失败，不是模型完全不能用，而是权限、检索、日志、上下文管理、提示词模板和业务流程没有做好。

企业内部部署大模型时，应该把模型当作基础能力，而不是一个孤立聊天页面。真正产生价值的是模型进入流程后，能不能稳定处理企业自己的数据和任务。

硬件选型思路

硬件不要只看“能不能跑”，还要看“能不能稳定服务”。

可以按阶段选：

验证阶段

目标是证明业务是否值得做。

使用 1-4 张消费级显卡。
优先跑 Flash、小模型、蒸馏模型或量化模型。
并发要求低，重点看任务完成率。
不承诺高可用。

这个阶段不要过早采购大规模硬件。先确认员工是否真的用、业务是否真的省时间、回答是否能进入流程。

试点阶段

目标是让一个部门或一个业务线稳定使用。

使用 4-16 张 GPU 或一组国产 NPU 节点。
加入统一网关、日志和权限控制。
做 RAG、文档解析、模型路由和缓存。
开始统计 token、并发、延迟和失败率。

这个阶段要开始关注运维。模型效果只是其中一部分，稳定性、成本和数据治理同样重要。

生产阶段

目标是进入企业级服务。

使用服务器 GPU、国产算力集群或私有云资源池。
建立多副本、限流、故障转移和容量规划。
按任务路由模型：简单任务走轻量模型，复杂任务走 Pro。
接入企业身份系统、审计系统和安全策略。

生产阶段不建议所有请求都打到最强模型。合理的模型路由通常比堆硬件更省钱。

推理框架怎么选

DeepSeek V4 这类模型对推理框架要求较高，尤其涉及 MoE、长上下文、稀疏注意力、量化和多卡并行时，框架成熟度会直接影响速度和稳定性。

常见选择可以这样理解：

SGLang：适合关注高性能推理、Agent、多轮工具调用和复杂服务编排的团队。
vLLM：生态成熟，适合通用 LLM 服务，但具体支持要看版本和模型适配进度。
llama.cpp：更适合小模型、量化模型和边缘部署，不适合直接承载满血超大 MoE。
国产 NPU 推理栈：适合信创和国产算力环境，但要重点验证算子、量化和长上下文支持。

框架选择不要只看 benchmark。企业更应该测试自己的真实输入：内部文档长度、并发数、平均输出长度、RAG 命中率、Agent 工具调用次数、失败重试次数。

数据安全要做在模型外面

私有化部署不等于自动安全。模型跑在本地，只是解决了“数据是否离开企业”的一部分问题。

还需要补齐：

账号和权限：不同部门只能访问自己的知识库。
日志审计：谁问了什么、调用了哪个模型、访问了哪些文档。
数据脱敏：客户信息、身份证号、手机号、合同金额等敏感字段要处理。
提示词安全：避免用户通过提示词绕过权限或泄露系统提示。
输出审查：重要场景要有人审或规则审。
数据生命周期：上传文档、向量索引、缓存和会话记录要能删除。

企业做本地大模型，不能只找算法团队。安全、法务、运维、业务负责人都要参与，否则上线后风险会被集中暴露。

成本不要只算显卡

本地部署的成本通常被低估。除了显卡或 NPU，还要算：

服务器、机柜、电源、散热和网络。
存储和备份。
推理框架适配和工程开发。
运维监控和故障处理。
模型升级、回滚和兼容性测试。
安全审计和权限系统。
业务侧提示词、RAG 和工作流建设。

如果调用量很低，外部 API 可能更便宜。如果调用量高、数据敏感、流程稳定，本地部署才更容易摊薄成本。

比较合理的策略是混合部署：

高敏感数据走本地模型。
低敏感通用任务可以走外部 API。
简单任务走小模型。
复杂任务走 DeepSeek V4 Pro。
高频任务优先优化缓存、检索和模型路由。

小结

DeepSeek V4 让企业本地私有化部署有了更强的想象空间，但它不是一个简单的“本地版 ChatGPT”。真正的难点在工程：硬件、框架、模型路由、权限、RAG、审计、监控和成本控制都要一起考虑。

国产芯片路线更适合合规要求高、长期建设私有云的企业；消费级显卡集群更适合试点和中小团队快速验证。Pro 适合复杂推理和 Agent，Flash 或小模型更适合大量普通任务。

如果只记住一句话：DeepSeek V4 私有化部署不要从硬件采购开始，而要从业务场景、数据边界和调用规模开始。先把场景跑通，再决定要不要上大模型、上多大模型、上哪种算力。

参考资料

适合 RTX 3060 显卡运行的本地 LLM 模型推荐

Fri, 08 May 2026 09:25:24 +0800

RTX 3060 最常见的是 12GB 显存版本。它不是顶级 AI 显卡，但用来跑本地 LLM 很合适，尤其适合 7B、8B、9B、12B 级别模型。

如果只想快速选型，可以先记住一句话：

RTX 3060 12GB 优先选 8B 左右模型的 Q4_K_M 或 Q5_K_M 量化；想要更稳就选 Q4，想要更好质量再试 Q5。

不要一上来就追 32B、70B。它们即使用低比特量化和 CPU offload 能跑，速度和体验通常也不适合日常使用。

先看显存边界

RTX 3060 12GB 跑本地 LLM，真正限制是显存。

大致可以这样理解：

模型规模	推荐量化	3060 12GB 体验
3B / 4B	Q4、Q5、Q8	很轻松，速度快
7B / 8B / 9B	Q4_K_M、Q5_K_M	最推荐，质量和速度平衡好
12B / 14B	Q4_K_M	可以尝试，注意上下文不要太大
30B 以上	Q2 / Q3 或部分 offload	能折腾，但不推荐日常使用
70B 以上	极低量化或大量 CPU/RAM 参与	更像实验，不适合普通使用

本地 LLM 不只是模型文件大小占显存。上下文长度、KV cache、批处理大小、推理框架和显卡驱动都会占资源。

所以 12GB 显存并不等于可以直接加载 12GB 模型文件。更稳的做法是给系统和上下文留余量。

推荐一：Qwen3 8B

如果你主要用中文，Qwen3 8B 是 RTX 3060 上很值得优先尝试的模型。

适合场景：

中文问答。
摘要和改写。
日常知识助手。
简单代码解释。
本地 RAG。
轻量 Agent 流程。

建议选择：

1
2
3

Qwen3 8B GGUF
Q4_K_M：优先推荐
Q5_K_M：质量更好，但显存压力更高

Qwen 系列对中文更友好，日常写作、资料整理和中文指令理解通常比较顺。如果你不知道第一款本地中文模型选什么，可以先从它开始。

推荐二：Llama 3.1 8B Instruct

Llama 3.1 8B Instruct 是一个很稳的通用模型，英文能力和工具生态都比较成熟。

适合场景：

英文问答。
轻量代码辅助。
通用聊天。
文档摘要。
提示词测试。
对比不同推理工具。

建议选择：

1
2
3

Llama 3.1 8B Instruct GGUF
Q4_K_M：速度和显存更稳
Q5_K_M：回答质量更好

如果你主要处理英文资料，或者想要一个生态成熟、教程多、兼容性好的模型，Llama 3.1 8B 仍然是很好的基准选择。

推荐三：Gemma 3 12B

Gemma 3 12B 更接近 3060 12GB 的上限选择。

它比 8B 模型更吃显存，但在 Q4 量化下仍然有机会在 3060 12GB 上跑起来。适合想在单卡上尝试更大一点模型的人。

适合场景：

更高质量的通用问答。
英文内容处理。
较复杂的总结和分析。
对 8B 模型不满意时的升级尝试。

建议选择：

1
2
3

Gemma 3 12B GGUF
Q4_K_M 或官方 QAT Q4
上下文不要开太大

如果运行时爆显存，可以先降低上下文长度，或者换回 8B 模型。对 3060 来说，12B 是“能试”，不是“无脑推荐”。

推荐四：DeepSeek R1 Distill Qwen 8B

如果你想在本地体验推理风格模型，可以试 DeepSeek R1 Distill Qwen 8B 一类 8B 蒸馏模型。

适合场景：

简单推理题。
分步骤分析。
学习推理模型输出风格。
本地低成本实验。

建议选择：

1
2

DeepSeek R1 Distill Qwen 8B GGUF
Q4_K_M

需要注意，这类模型有时会输出更长的推理过程，速度和上下文占用可能比普通指令模型更明显。日常聊天不一定比 Qwen3 8B 更舒服，但用来做推理实验很合适。

推荐五：Phi / MiniCPM / 小尺寸模型

如果你的 3060 不是 12GB 版本，而是 8GB 版本，或者电脑内存也比较小，可以优先考虑 3B、4B 级别模型。

适合场景：

快速问答。
简单摘要。
嵌入到本地小工具。
低延迟聊天。
老电脑测试。

这类模型质量不一定能和 8B、12B 相比，但胜在轻、快、部署简单。

量化怎么选

本地模型常见格式是 GGUF，常见量化包括 Q4、Q5、Q6、Q8。

简单选择：

量化	特点	适合谁
Q4_K_M	体积小，速度好，质量够用	3060 首选
Q5_K_M	质量更好，占用更高	8B 模型可以试
Q6 / Q8	更接近原始质量，占用更大	小模型或显存宽裕时
Q2 / Q3	很省显存，但质量下降明显	大模型折腾用

对 RTX 3060 12GB 来说，最实用的是：

1
2
3

8B 模型：Q4_K_M 或 Q5_K_M
12B 模型：优先 Q4_K_M
更大模型：不建议作为日常主力

用什么工具运行

新手可以从 Ollama 开始，优点是安装和运行简单。

常见命令形式：

1
2

ollama run qwen3:8b
ollama run llama3.1:8b

如果想更细地控制 GGUF 文件、GPU layers、上下文长度，可以用 llama.cpp 或基于 llama.cpp 的图形工具。

常见选择：

Ollama：最省心，适合新手。
LM Studio：图形界面友好，适合手动下载和切换模型。
llama.cpp：控制最细，适合折腾性能。
text-generation-webui：功能多，适合测试不同后端。

如果只是本地聊天和简单问答，Ollama 或 LM Studio 就够了。

上下文不要开太大

很多模型宣传支持很长上下文，但 RTX 3060 运行时不要盲目开到最大。

上下文越长，KV cache 占用越高，显存压力也越大。即使模型能加载，长上下文也可能导致速度下降。

建议：

1
2
3

普通聊天：4K 到 8K
文档摘要：8K 到 16K
长文档 RAG：优先切片，不要硬塞全文

3060 更适合“中等上下文 + 好模型 + 好检索”，不适合把几十万 token 一次性塞进去。

不同用途怎么选

如果你主要写中文：

1
2

优先：Qwen3 8B Q4_K_M
备选：DeepSeek R1 Distill Qwen 8B

如果你主要写英文：

1
2

优先：Llama 3.1 8B Instruct Q4_K_M
备选：Gemma 3 12B Q4_K_M

如果你想跑得快：

1
2
3

3B / 4B 模型
8B Q4_K_M
上下文控制在 4K 到 8K

如果你想质量更好：

1
2
3

8B Q5_K_M
12B Q4_K_M
接受速度变慢

如果你想写代码：

1
2

8B 代码模型可以辅助解释和小改动
复杂工程任务仍建议用云端强模型

本地 3060 模型适合做代码解释、函数补全、小脚本生成和离线辅助；大型项目重构、复杂 bug、跨文件 Agent 任务，不要期待它达到 Claude Sonnet 或 GPT-5 级别。

3060 本地 LLM 的合理预期

RTX 3060 12GB 的定位很清楚：它适合把本地 LLM 从“玩具”变成“日常可用工具”，但不是让你在家里复刻顶级云端模型。

它的优势是：

成本低。
显存比 8GB 卡宽裕。
8B 模型体验不错。
可以离线使用。
适合隐私敏感资料的本地处理。

它的限制是：

大模型很难流畅。
长上下文会吃显存。
推理速度不如高端卡。
本地小模型复杂推理能力有限。
多模态和 Agent 工作流会更吃资源。

所以最稳的路线是：用 8B 模型做日常本地助手，用 12B 模型做质量尝试，复杂任务交给云端模型。

小结

RTX 3060 12GB 最推荐的本地 LLM 选择是：

中文通用：Qwen3 8B Q4_K_M
英文通用：Llama 3.1 8B Instruct Q4_K_M
更高质量尝试：Gemma 3 12B Q4_K_M
推理实验：DeepSeek R1 Distill Qwen 8B Q4_K_M
低显存快速体验：3B / 4B 小模型

量化优先选 Q4_K_M，8B 模型可以尝试 Q5_K_M。工具优先从 Ollama 或 LM Studio 开始。

不要把 3060 当成大模型服务器。把它当成本地知识助手、隐私文档处理器、轻量代码助手和模型实验卡，会更符合它的实际能力。

参考链接

Qwen3 8B GGUF：https://huggingface.co/Qwen/Qwen3-8B-GGUF
Llama 3.1 8B GGUF：https://huggingface.co/macandchiz/Llama-3.1-8B-Instruct-GGUF
Gemma 3 12B GGUF：https://huggingface.co/unsloth/gemma-3-12b-it-GGUF
llama.cpp：https://github.com/ggml-org/llama.cpp
Ollama：https://ollama.com

Hermes + Qwen3.6：本地 Agent 的一套低成本部署方案

Mon, 04 May 2026 06:40:30 +0800

用 llama.cpp 在 WSL2 中运行 Qwen3.6 GGUF 模型，再把 Hermes Agent 接到本地 OpenAI-compatible API。这样可以在自己的电脑上获得一个可长期在线的本地 AI 助手，不再按在线服务的 Token 额度计费。

这套方案适合想体验本地 AI Agent、又希望保留数据隐私和长期可控性的用户。它可以用于日常问答、写作、代码辅助、资料整理和简单自动化任务。需要注意的是，模型规模越大，对显存要求越高；原文示例使用的是 Qwen3.6-27B，显存 24GB 更稳。如果显存较小，应选择更小尺寸或更低量化的模型。

方案结构

整体链路很简单：

Windows 上安装 WSL2 和 Ubuntu 24.04。
在 WSL2 中安装 CUDA Toolkit、编译 llama.cpp。
下载 Qwen3.6 GGUF 模型。
用 llama-server 启动本地模型服务。
安装 Hermes Agent，并把它配置到 http://localhost:8080/v1。
可选：写启动脚本，让 WSL2 打开时自动启动模型服务。

Hermes 负责 Agent 能力，Qwen3.6 负责本地大模型能力。两者组合后，可以把电脑变成一个本地私有 AI 助理。

安装 WSL2 和 Ubuntu

在 Windows PowerShell 管理员窗口中执行：

1
2

wsl --install
wsl --set-default-version 2

重启后安装 Ubuntu 24.04：

`1`	`wsl --install -d Ubuntu-24.04`

安装完成后，Ubuntu 会提示设置用户名和密码。进入 Ubuntu 后，先检查 NVIDIA GPU 是否能在 WSL2 中正常识别：

`1`	`nvidia-smi`

如果无法识别 GPU，通常需要先更新 Windows 端的 NVIDIA 显卡驱动。WSL2 会继承 Windows 驱动，但 CUDA Toolkit 仍需要在 WSL2 内单独安装。

安装 Python 和基础工具

`1`	`sudo apt update && sudo apt install -y python3-pip python3-venv`

后续还需要编译工具、Git 和 CMake：

`1`	`sudo apt install -y cmake build-essential git`

编译 llama.cpp

先拉取源码：

1
2

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

如果 WSL2 中已经有可用 CUDA 环境，可以直接编译：

1
2

cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

CMAKE_CUDA_ARCHITECTURES=89 适合 Ada 架构显卡，例如 RTX 40 系列。其他显卡应按实际架构调整。

如果编译时报 CUDA Toolkit 缺失，先在 WSL2 中安装 CUDA Toolkit：

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit-12-8

安装完成后配置环境变量：

export PATH=/usr/local/cuda-12.8/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH
echo 'export PATH=/usr/local/cuda-12.8/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc

然后重新编译：

cd ~/llama.cpp
rm -rf build
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

下载 Qwen3.6 GGUF 模型

原文示例使用 unsloth/Qwen3.6-27B-GGUF 中的 Qwen3.6-27B-UD-Q4_K_XL.gguf：

1
2
3

hf download unsloth/Qwen3.6-27B-GGUF \
Qwen3.6-27B-UD-Q4_K_XL.gguf \
--local-dir ~/models/

这个文件约 17GB。如果 Hugging Face 下载慢，可以换 ModelScope 等国内镜像。显存不足时不要硬上 27B，可以换更小模型或更低量化版本。

启动本地模型服务

根据自己的模型文件名启动 llama-server：

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080

启动成功后，在 Windows 浏览器访问：

`1`	`http://localhost:8080`

如果要让 Hermes Agent 或其他 OpenAI-compatible 客户端调用，API 地址通常是：

`1`	`http://localhost:8080/v1`

Thinking 模式取舍

Qwen3.6 默认可能启用 Thinking 模式。它适合复杂推理、复杂代码问题、多步骤分析，但速度会慢一些。

如果想关闭 Thinking 模式，可以停止服务后增加 --chat-template-kwargs 参数：

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--chat-template-kwargs '{"enable_thinking":false}' \
--port 8080

关闭 Thinking 后，简单问答、写作、代码补全和解释代码会更快；但复杂算法设计、疑难 Debug 和架构分析仍建议开启 Thinking。

安装 Hermes Agent

保持 llama-server 运行，再新开一个 WSL2 终端安装 Hermes Agent：

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

安装脚本会处理 Python、Node.js、ripgrep、ffmpeg 等依赖。配置模型端点时选择自定义 endpoint：

1
2
3

URL: http://localhost:8080/v1
API Key: 12345678
Model: 自动识别

API Key 对本地 llama-server 来说可以随便填一个占位值。配置完成后，可以继续接 Telegram、微信、QQ、Discord 等聊天工具，让 Hermes Agent 通过这些入口调用本地模型并执行任务。

自动启动模型服务

可以写一个启动脚本，让 WSL2 终端打开时自动启动模型服务。

创建脚本：

cat > ~/start-llm.sh << 'EOF'
#!/bin/bash
echo "Starting Qwen3.6-27B llama-server..."
~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 65536 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080 \
--host 0.0.0.0 &
echo "llama-server started, PID: $!"
echo "API: http://localhost:8080/v1"
echo "Chat UI: http://localhost:8080"
EOF
chmod +x ~/start-llm.sh

写入 .bashrc：

echo '# Auto-start llama-server' >> ~/.bashrc
echo 'if ! pgrep -f "llama-server" > /dev/null 2>&1; then' >> ~/.bashrc
echo '    ~/start-llm.sh' >> ~/.bashrc
echo 'fi' >> ~/.bashrc

这样每次打开 WSL2 终端时，如果 llama-server 没有运行，就会自动启动；如果已经在运行，就会跳过，避免重复启动。

注意事项

27B 模型对显存要求较高，24GB 显存体验更稳；显存较小时应换小模型。
--ctx-size 65536 会显著增加显存和内存压力，不稳定时先降到 32768 或更低。
WSL2 中 CUDA Toolkit 和 Windows 显卡驱动都要正常，缺一边都可能导致 CUDA 编译或运行失败。
Hermes Agent 接本地服务时，本质上是调用 OpenAI-compatible API，关键是 http://localhost:8080/v1 能正常响应。
如果要从手机或其他设备访问，需要额外处理 Windows 防火墙、局域网地址和安全隔离，不要把本地模型服务直接暴露到公网。

NVIDIA 发布 Nemotron 3 Nano Omni：面向智能体的开放全模态推理模型

Fri, 01 May 2026 12:07:15 +0800

NVIDIA 发布了 Nemotron 3 Nano Omni，这是一款面向智能体工作流的开放式全模态推理模型。它的重点不是只做文字问答，而是把语言、视觉、音频放进同一个推理框架里，让模型能够处理更接近真实工作流的输入。

从定位看，Nemotron 3 Nano Omni 更像是给 AI Agent 准备的底层模型。它可以理解屏幕、文档、图片、语音和视频中的信息，并把这些信息转成可执行的推理结果。这类能力适合计算机操作、文档智能、视频理解、语音交互、客服、教育和企业流程自动化。

模型规格

Nemotron 3 Nano Omni 采用 MoE 架构。 NVIDIA 给出的核心规格是：

项目	信息
模型名称	`Nemotron 3 Nano Omni`
架构	MoE
参数规模	30B total / 3B active
模态	文本、图像、音频、视频
上下文长度	256K token
许可	Apache 2.0
主要部署方向	AI Agent、多模态推理、企业智能体

这里最值得注意的是 30B-A3B。它代表模型总参数规模约 30B，但每次推理只激活约 3B 参数。这能在能力和推理成本之间做一个折中：模型保留较大的专家容量，同时运行时只使用其中一部分。

不过，MoE 的 active params 不等于显存只按 3B 模型估算。完整部署仍然要考虑专家权重、KV cache、视觉/音频编码模块、上下文长度和推理框架开销。

它解决的不是单一模态问题

传统大语言模型主要处理文字。多模态模型进一步支持图片理解。而 Nemotron 3 Nano Omni 的目标更宽：它强调全模态输入，也就是把文本、图像、音频和视频统一纳入推理。

这对 Agent 很关键。真正的智能体任务往往不是“给一段文字，生成一段文字”，而是：

看屏幕上的按钮、表格和窗口；
读 PDF、截图、图表和网页；
听语音说明或会议录音；
理解视频中的动作、场景和时序；
把这些信息综合成下一步操作。

如果模型只能处理单一模态，Agent 就需要额外拼接多个专用模型。全模态模型的价值在于减少这种拼接成本，让同一个模型直接处理更复杂的环境输入。

面向计算机操作和文档智能

NVIDIA 特别提到，Nemotron 3 Nano Omni 可用于计算机操作相关任务。这类任务通常要求模型理解用户界面：

屏幕上有哪些控件；
当前窗口处于什么状态；
哪个按钮或菜单是下一步目标；
表格、弹窗、输入框中的内容意味着什么。

这也是现在 AI Agent 落地时很难绕开的能力。如果智能体要帮人操作办公软件、浏览器、企业后台或开发工具，它必须能看懂界面，而不是只读 API 文档。

文档智能也是类似逻辑。企业资料经常混合文本、表格、图像、扫描页和图表。全模态模型可以把这些内容放在同一个上下文里理解，适合做合同审阅、报表分析、票据处理、知识库问答和流程自动化。

音频和视频让 Agent 更接近真实场景

音频和视频输入会让 Agent 的应用范围明显扩大。

音频场景包括：

会议录音总结；
客服通话分析；
语音指令理解；
教育和培训内容整理。

视频场景包括：

教学视频理解；
安防和工业巡检；
屏幕录制分析；
操作流程复盘；
多步骤任务中的时序判断。

这些任务如果只靠文字转写，会丢掉很多视觉和时序信息。全模态模型可以直接把声音、画面和文字线索结合起来，给 Agent 更完整的环境感知。

部署与生态

NVIDIA 将 Nemotron 3 Nano Omni 放进开放生态里，模型采用 Apache 2.0 许可。这对开发者和企业很重要，因为它降低了试验、集成和二次开发的许可门槛。

从 NVIDIA 的介绍看，这个模型也和其推理生态绑定紧密。对企业用户来说，真正部署时通常会关注这些问题：

是否能在 NVIDIA GPU 上高效推理；
是否支持长上下文和多模态输入；
是否能接入现有 Agent 框架；
是否能处理企业内部文档、音视频和界面截图；
是否可以在私有环境里部署。

NVIDIA 强调该模型在吞吐方面有明显优势，并称其最高可达到同类开放全模态推理模型的 9 倍。这个数字的实际价值，还要结合具体硬件、上下文长度、输入模态和推理框架来看。但方向很明确：NVIDIA 想把开放多模态模型和自己的推理基础设施一起推向企业 Agent 场景。

适合哪些场景

Nemotron 3 Nano Omni 更适合下面这些任务：

需要同时理解文本、图片、音频和视频的 Agent；
企业内部文档智能和知识库问答；
基于屏幕截图或网页界面的计算机操作；
会议、客服、教学内容的多模态分析；
视频理解、流程复盘和时序判断；
对开放许可和私有化部署有要求的团队。

它不一定适合所有普通用户。如果只是本地聊天、代码补全或简单问答，单模态语言模型可能更轻、更快、更省资源。 Nemotron 3 Nano Omni 的价值主要体现在复杂输入和多模态 Agent 工作流里。

这对 AI Agent 意味着什么

AI Agent 要真正进入工作场景，不能只会写文字。它需要看得懂界面，听得懂语音，读得懂文档，理解视频里的变化，还要把这些信息转成下一步行动。

Nemotron 3 Nano Omni 的意义就在这里。它不是单纯把模型参数做大，而是把 Agent 需要面对的多种输入统一到一个推理模型里。这会让开发者更容易构建面向真实任务的智能体，而不是只围绕聊天窗口做应用。

从这个角度看，NVIDIA 发布这款模型的重点不只是“又一个多模态模型”，而是继续把开放模型、GPU 推理、企业 Agent 和私有部署连接起来。未来真正值得关注的是，它在具体 Agent 框架、企业工作流和本地部署中的实际表现。

参考来源：

NVIDIA 技术博客：NVIDIA Nemotron 3 Nano Omni

本地部署 Qwen3.6：27B 与 35B-A3B 各量化版本需要多少显存

Fri, 01 May 2026 12:02:00 +0800

Qwen3.6 目前最适合本地部署讨论的开放权重版本，主要是两类：

Qwen3.6-27B：27B 稠密模型。
Qwen3.6-35B-A3B：35B total / 3B active 的 MoE 模型。

还有一些线上产品名或 API 模型名，例如 Qwen3.6-Plus、Qwen3.6-Max。这类模型如果没有公开完整权重和稳定量化文件，就不适合列入本地显存表。本文只整理可以围绕 Hugging Face 权重与 GGUF 量化文件部署的版本。

和 /05/10 的 Gemma 4 表一样，这里也要先区分两个概念：

GGUF 文件体积：模型权重文件本身有多大。
实际显存占用：模型权重、KV cache、上下文长度、运行后端、多模态模块、批大小共同决定。

Qwen3.6 的默认上下文很长，官方模型卡里写到原生支持 262,144 tokens，并可扩展到 1,010,000 tokens。所以表格里的“最低显存”只适合短上下文或中等上下文。如果你真的要跑 128K、256K 或更长上下文，必须额外给 KV cache 留大量空间。

先看结论

显存	比较合适的选择	不建议硬上
8GB	27B / 35B-A3B 的 2-bit 极限尝试，质量风险较高	Q4 以上
12GB	27B Q2/Q3，35B-A3B Q2/Q3 短上下文	27B Q4 长上下文
16GB	27B Q3/Q4，35B-A3B Q3/IQ4_XS	35B-A3B Q4 长上下文
24GB	27B Q4/Q5/Q6，35B-A3B Q4	35B-A3B Q8、BF16
32GB	27B Q8，35B-A3B Q5/Q6	BF16
48GB	35B-A3B Q8，27B 长上下文更从容	35B-A3B BF16
80GB+	27B / 35B-A3B BF16	没有必要为普通本地聊天追 BF16

如果你是 24GB 显卡，重点看：

Qwen3.6-27B Q4_K_M
Qwen3.6-27B Q5_K_M
Qwen3.6-35B-A3B UD-Q4_K_M

如果你只有 16GB 显存，优先从低位宽版本开始，不要一上来就开超长上下文。

官方权重体积

以下是官方 Hugging Face 仓库中 model.safetensors.index.json 统计到的 BF16 权重体积。它可以作为原始权重规模参考。

模型	架构	官方 BF16 权重体积	官方上下文
`Qwen3.6-27B`	27B dense	55.56GB	262K 原生，可扩展到 1,010K
`Qwen3.6-35B-A3B`	35B total / 3B active MoE	71.90GB	262K 原生，可扩展到 1,010K

35B-A3B 虽然每次只激活约 3B 参数，但它仍然需要加载完整 MoE 权重。所以它不能按 3B 小模型来估算显存。

Qwen3.6-27B 显存表

Qwen3.6-27B 是稠密模型，优点是能力稳定，缺点是推理成本更接近传统 27B 模型。从本地部署角度看，它比 35B-A3B 更吃计算，但显存需求更容易预估。

量化版本	GGUF 文件体积	最低显存	更稳妥显存	适合场景
`UD-IQ2_XXS`	9.39GB	12GB	16GB	极限低显存尝试
`UD-IQ2_M`	10.85GB	12GB	16GB	低显存可用性优先
`UD-Q2_K_XL`	11.85GB	14GB	18GB	低位宽折中
`UD-IQ3_XXS`	11.99GB	14GB	18GB	省显存的 3-bit
`Q3_K_S`	12.36GB	16GB	20GB	3-bit 入门
`Q3_K_M`	13.59GB	16GB	20GB	3-bit 常用折中
`IQ4_XS`	15.44GB	20GB	24GB	接近 Q4 的省显存选择
`IQ4_NL`	16.07GB	20GB	24GB	质量和体积折中
`Q4_K_M`	16.82GB	20GB	24GB	27B 常用推荐
`Q5_K_M`	19.51GB	24GB	32GB	更稳的高质量量化
`Q6_K`	22.52GB	28GB	32GB	质量优先
`Q8_0`	28.60GB	32GB	40GB	接近原始精度
`BF16`	53.80GB	64GB	80GB	研究、评测、精度对比

如果只是普通本地编码和聊天，Q4_K_M 是最容易推荐的起点。 24GB 显卡可以比较舒服地跑 Q4_K_M，但如果要长上下文，最好降低量化位宽或减少上下文长度。

Qwen3.6-35B-A3B 显存表

Qwen3.6-35B-A3B 是 MoE 模型，35B total，但每次激活约 3B 参数。它的优势是速度和能力之间的平衡很好，尤其适合本地 Agent、工具调用、代码协作。

但要注意：MoE 的 3B active 主要影响计算量，不代表显存只需要 3B 模型级别。完整运行仍要加载专家权重。

量化版本	GGUF 文件体积	最低显存	更稳妥显存	适合场景
`UD-IQ2_XXS`	10.76GB	12GB	16GB	极限低显存尝试
`UD-IQ2_M`	11.52GB	14GB	16GB	低显存可用性优先
`UD-Q2_K_XL`	12.29GB	14GB	18GB	低位宽折中
`UD-IQ3_XXS`	13.21GB	16GB	20GB	省显存的 3-bit
`UD-Q3_K_S`	15.36GB	18GB	24GB	3-bit 入门
`UD-Q3_K_M`	16.60GB	20GB	24GB	3-bit 常用折中
`UD-IQ4_XS`	17.73GB	20GB	24GB	质量和体积折中
`UD-IQ4_NL`	18.04GB	20GB	24GB	接近 Q4 的推荐选择
`UD-Q4_K_M`	22.13GB	24GB	32GB	35B-A3B 常用推荐
`UD-Q5_K_M`	26.46GB	32GB	40GB	更稳的高质量量化
`UD-Q6_K`	29.31GB	32GB	48GB	质量优先
`Q8_0`	36.90GB	48GB	64GB	接近原始精度
`BF16`	69.37GB	80GB	96GB	研究、评测、精度对比

24GB 显存可以把 UD-Q4_K_M 作为重点选择，但上下文不要开得太夸张。如果想给 128K 以上上下文留空间，UD-IQ4_XS、UD-IQ4_NL 或 3-bit 版本会更现实。

27B 和 35B-A3B 怎么选

需求	更推荐
稳定稠密模型表现	`Qwen3.6-27B`
更快响应、Agent 和工具调用	`Qwen3.6-35B-A3B`
24GB 显存日常本地用	`35B-A3B UD-Q4_K_M` 或 `27B Q4_K_M`
16GB 显存尝试	两者都选 2-bit/3-bit，不建议长上下文
长上下文优先	降低量化位宽，留更多 KV cache 空间
质量优先且有 32GB+ 显存	`27B Q5/Q6` 或 `35B-A3B Q5/Q6`

如果你主要写代码、跑 Agent、做工具调用，35B-A3B 更值得先试。如果你更在意稠密模型的稳定性和一致性，27B 更直观。

为什么长上下文会吃掉大量显存

Qwen3.6 的模型卡建议在复杂任务中保持较长上下文，甚至提到 128K 以上上下文对思考能力有帮助。但对本地部署来说，长上下文意味着更大的 KV cache。

影响实际显存的因素包括：

KV cache：上下文越长，占用越高。
是否启用视觉输入：Qwen3.6 是带视觉编码器的模型，多模态场景会增加额外开销。
是否使用 --language-model-only：在 vLLM 等运行时里，跳过视觉部分可以释放一部分内存给 KV cache。
批大小和并发：并发越高，显存需求越高。
KV cache 量化：q8_0、q4_0 等设置可以省显存，但可能影响细节。
运行时差异：llama.cpp、vLLM、SGLang、KTransformers、LM Studio 的占用不完全一样。

所以不要只看 GGUF 文件大小。如果文件已经接近显存上限，模型即使能加载，也可能在生成长文本或长上下文时 OOM。

怎么选

如果你只是想本地体验 Qwen3.6：

12GB 显存：尝试 27B UD-IQ2_M 或 35B-A3B UD-IQ2_M，上下文要短。
16GB 显存：尝试 27B Q3_K_M 或 35B-A3B UD-IQ3_XXS。
24GB 显存：优先看 27B Q4_K_M、35B-A3B UD-IQ4_NL、35B-A3B UD-Q4_K_M。
32GB 显存：可以考虑 27B Q5/Q6 或 35B-A3B Q5/Q6。
48GB 以上：可以尝试 Q8_0，或者给长上下文留更多空间。

一般用户不需要追 BF16。 Qwen3.6 的本地部署重点不是“文件越大越好”，而是在显存、上下文长度、速度和输出质量之间找到平衡。

参考来源

本地部署 DeepSeek V4：Pro、Flash 与 Base 版本显存占用估算表

Fri, 01 May 2026 11:55:25 +0800

DeepSeek V4 和 Gemma 4 的本地部署不是一个量级。 Gemma 4 的 26B、31B 还能讨论 24GB、32GB 显卡怎么选量化版；DeepSeek V4 则是超大 MoE 模型，真正完整本地部署时，显存需求会直接进入多卡工作站或服务器级别。

官方发布的 DeepSeek V4 Preview 主要包含两个推理版本：

DeepSeek-V4-Pro：1.6T total / 49B active params
DeepSeek-V4-Flash：284B total / 13B active params

Hugging Face 官方 collection 里还包含两个 Base 版本：

DeepSeek-V4-Pro-Base
DeepSeek-V4-Flash-Base

这篇只讨论完整加载模型权重时的大致显存门槛。 MoE 的 active params 主要影响每个 token 的计算量，不等于只需要加载这部分参数。如果没有专家按需加载、CPU/NVMe offload、分布式推理或专门运行时优化，显存仍然要按完整权重来估。

先看结论

显存规模	能比较现实地尝试什么	不建议期待什么
24GB	不能完整跑 DeepSeek V4；只能跑小型蒸馏模型或 API	V4-Flash / V4-Pro 完整本地加载
48GB	仍不适合完整加载；可做小模型或远程 API 客户端	V4-Flash Q4 稳定运行
80GB	理论上可尝试 V4-Flash Q2/Q3 或强 offload	V4-Pro
128GB	V4-Flash Q4 比较现实；Q5/Q6 仍紧	V4-Pro Q4
192GB	V4-Flash FP8/Q6 更从容；Pro Q2 勉强进入讨论	V4-Pro Q4
256GB	V4-Flash FP8 比较稳；Pro Q2/Q3 可实验	V4-Pro Q5 以上
512GB	V4-Pro Q4 开始进入可讨论范围	V4-Pro FP8
1TB+	V4-Pro FP8、Pro-Base 低位宽更现实	单机低成本部署
2TB+	Pro-Base FP8 级别	普通工作站部署

如果你的目标是个人电脑本地运行，DeepSeek V4 并不是合适对象。更现实的路线是：

用 DeepSeek 官方 API 或兼容服务；
等社区稳定的 GGUF/EXL2/MLX 量化和推理支持；
使用更小的 DeepSeek 蒸馏模型；
或者把本地模型换成 Qwen、Gemma、Llama 等 7B 到 70B 级别模型。

官方权重体积

以下是 Hugging Face 官方仓库的 model.safetensors.index.json 中统计到的权重总量。它反映的是当前公开权重文件大小，不等于长上下文运行时的完整显存占用。

模型	参数规模	官方权重体积	说明
`DeepSeek-V4-Flash`	284B total / 13B active	159.61GB	推理版，体积相对最小
`DeepSeek-V4-Pro`	1.6T total / 49B active	864.70GB	推理版，能力更强，体积巨大
`DeepSeek-V4-Flash-Base`	284B total	294.67GB	Base 版，更接近全量 FP8 权重体积
`DeepSeek-V4-Pro-Base`	1.6T total	1606.03GB	Base 版，约 1.6TB 级别

可以看到，即使是最小的 V4-Flash，官方权重也已经接近 160GB。这就是为什么它不能按“13B active params”理解成 13B 小模型。

DeepSeek V4 Flash 显存估算

V4-Flash 是 DeepSeek V4 里最适合本地尝试的一档。但“最适合”只是相对 Pro 而言，它仍然不是消费级单卡模型。

下面按官方 159.61GB 权重体积做折算。其中 Q4/Q3/Q2 是按位宽估算，不代表当前已经有稳定可用的官方 GGUF 版本。

版本/量化	估算权重体积	最低显存	更稳妥显存	适合场景
`FP8 / 官方权重`	159.61GB	192GB	256GB	多卡服务器、推理服务
`Q6`	120GB	160GB	192GB	质量优先的量化尝试
`Q5`	100GB	128GB	160GB	质量和体积折中
`Q4`	80GB	96GB	128GB	Flash 本地化较现实的起点
`Q3`	60GB	80GB	96GB	大显存单卡或多卡实验
`Q2`	40GB	48GB	64GB	极限低位宽实验，质量风险明显

如果未来社区出现成熟的 V4-Flash Q4，它大概率也不是 24GB 显卡的模型。更现实的硬件起点是 96GB 到 128GB 级别的总显存，或者依赖 CPU 内存/offload 换速度。

DeepSeek V4 Pro 显存估算

V4-Pro 是旗舰推理版，官方权重体积约 864.70GB。即使做 4-bit 量化，完整权重也仍然是数百 GB 级别。

版本/量化	估算权重体积	最低显存	更稳妥显存	适合场景
`FP8 / 官方权重`	864.70GB	1TB	1.2TB+	多机多卡推理服务
`Q6`	648GB	768GB	1TB	高质量量化服务
`Q5`	540GB	640GB	768GB	高质量与成本折中
`Q4`	432GB	512GB	640GB	Pro 本地化较现实的最低质量线
`Q3`	324GB	384GB	512GB	低位宽实验
`Q2`	216GB	256GB	320GB	极限实验，质量和稳定性风险高

对个人用户来说，V4-Pro 更适合通过 API 使用。如果目标是完整本地部署，至少要把它当成多卡服务器模型，而不是 4090、5090、RTX PRO 单卡模型。

DeepSeek V4 Flash-Base 显存估算

Base 版通常用于研究、微调或继续训练，不是普通聊天部署的首选。 V4-Flash-Base 官方权重体积约 294.67GB。

版本/量化	估算权重体积	最低显存	更稳妥显存	适合场景
`FP8 / 官方权重`	294.67GB	384GB	512GB	研究、训练前处理、评测
`Q6`	221GB	256GB	320GB	高质量量化研究
`Q5`	184GB	224GB	256GB	质量和体积折中
`Q4`	147GB	192GB	224GB	Base 版低成本实验
`Q3`	111GB	128GB	160GB	低位宽实验
`Q2`	74GB	96GB	128GB	极限实验

如果只是要使用 DeepSeek V4 能力，不建议从 Base 版开始。 Base 版的部署和调优成本更高，普通应用更适合推理版或 API。

DeepSeek V4 Pro-Base 显存估算

V4-Pro-Base 是最重的一档，官方权重体积约 1606.03GB。这已经是 1.6TB 级别的模型文件。

版本/量化	估算权重体积	最低显存	更稳妥显存	适合场景
`FP8 / 官方权重`	1606.03GB	2TB	2.4TB+	大规模研究集群
`Q6`	1205GB	1.5TB	2TB	高质量量化研究
`Q5`	1004GB	1.2TB	1.5TB	研究与评测
`Q4`	803GB	1TB	1.2TB	低位宽研究
`Q3`	602GB	768GB	1TB	极限低位宽研究
`Q2`	402GB	512GB	640GB	极限实验

这类模型不适合被放进“家用显卡能不能跑”的框架里讨论。哪怕是 Q4，也已经超过绝大多数单机工作站的舒适范围。

为什么不能只看 active params

DeepSeek V4 是 MoE 模型。 MoE 的特点是每个 token 只激活一部分专家，因此计算量会明显低于总参数量。但这不等于显存只需要放 active params。

完整本地推理通常还要考虑：

所有专家权重是否需要常驻 GPU；
是否支持按需专家加载；
CPU 内存与 GPU 显存之间的数据搬运成本；
NVMe offload 的延迟；
KV cache 在长上下文下的增长；
1M context 场景下的额外运行时开销；
多机多卡通信成本。

所以，49B active 的 V4-Pro 不能当成 49B 模型来部署。 13B active 的 V4-Flash 也不能当成 13B 小模型来部署。

怎么选

如果你只是普通个人用户：

不建议完整本地部署 DeepSeek V4。
需要 DeepSeek V4 能力时，优先用官方 API。
需要本地私有化时，优先看是否有成熟推理服务商或内部多卡服务器。
只有 24GB 到 48GB 显存时，转向 7B、14B、32B、70B 级别量化模型更实际。

如果你有 128GB 到 256GB 总显存：

可以关注 V4-Flash Q4/Q5 是否有稳定社区实现。
不建议把 V4-Pro 当成主力本地模型。

如果你有 512GB 以上总显存：

V4-Pro Q4 才开始进入工程验证范围。
仍然要关注推理框架、专家调度、KV cache、吞吐和并发。

DeepSeek V4 的本地部署重点不是“下载哪个量化文件”，而是“有没有足够的系统级推理能力”。它更接近一个服务器模型，而不是普通桌面模型。

参考来源

本地部署 Gemma 4：E2B、E4B、26B、31B 各量化版本需要多少显存

Fri, 01 May 2026 11:42:34 +0800

Gemma 4 现在主要有四个本地部署尺寸：E2B、E4B、26B A4B 和 31B。其中 E2B、E4B 面向轻量和边缘设备，26B A4B 是 MoE 架构，31B 是更大的稠密模型。

本地运行时，最容易混淆的是两个数字：

GGUF 文件体积：模型权重文件本身有多大。
实际显存占用：模型权重、KV cache、运行时开销、上下文长度、是否加载多模态投影文件共同决定。

下面的表格按 GGUF 文件体积估算显存需求。默认假设是 llama.cpp、LM Studio、Ollama 这类本地推理场景，主要跑文本，使用中短上下文。如果要开长上下文、视觉/音频输入、并发请求，显存要继续往上留余量。

先看结论

显存	比较合适的选择	不建议硬上
4GB	E2B 的低比特量化	E4B 以上
6GB	E2B Q4/Q5，E4B 低比特量化	26B、31B
8GB	E2B Q8，E4B Q4/Q5	26B Q4、31B Q4
12GB	E4B Q8，26B/31B 的 2-bit/3-bit 低质量尝试	26B Q4 长上下文、31B Q4
16GB	26B 低比特量化，31B 低比特量化	31B Q4 长上下文、26B Q5 以上
24GB	26B Q4/Q5，31B Q4	31B Q8、BF16
32GB	26B Q6/Q8，31B Q5/Q6	BF16
48GB	31B Q8 更从容，26B Q8 长上下文	31B BF16
80GB+	26B/31B BF16	普通消费卡单卡部署

如果只是想本地可用，优先从 E4B Q4_K_M 或 E2B Q4_K_M 开始。如果有 24GB 显存，26B A4B Q4_K_M 和 31B Q4_K_M 才开始进入比较舒服的范围。

Gemma 4 E2B 显存表

E2B 是最轻量的版本，适合笔记本、迷你主机、移动端和低显存测试。它的优势是容易跑，缺点是复杂推理、代码和长任务稳定性有限。

量化版本	GGUF 文件体积	最低显存	更稳妥显存	适合场景
`UD-IQ2_M`	2.29GB	4GB	6GB	极限低显存测试
`UD-Q2_K_XL`	2.40GB	4GB	6GB	低显存可用性优先
`Q3_K_M`	2.54GB	4GB	6GB	轻量聊天、摘要
`IQ4_XS`	2.98GB	6GB	8GB	质量和体积折中
`Q4_K_M`	3.11GB	6GB	8GB	E2B 常用推荐
`Q5_K_M`	3.36GB	6GB	8GB	比 Q4 更稳一点
`Q6_K`	4.50GB	8GB	10GB	小模型高质量量化
`Q8_0`	5.05GB	8GB	10GB	接近原始精度的轻量部署
`BF16`	9.31GB	12GB	16GB	调试、对比、研究

E2B 的 Q4_K_M 已经够日常体验。如果只有 4GB 显存，可以尝试 2-bit 或 3-bit，但输出质量会更容易波动。

Gemma 4 E4B 显存表

E4B 是更实用的轻量版本。它比 E2B 更适合日常写作、资料总结、轻量代码辅助和本地助手。

量化版本	GGUF 文件体积	最低显存	更稳妥显存	适合场景
`UD-IQ2_M`	3.53GB	6GB	8GB	低显存尝试
`UD-Q2_K_XL`	3.74GB	6GB	8GB	低显存可用性优先
`Q3_K_M`	4.06GB	6GB	10GB	轻量本地助手
`IQ4_XS`	4.72GB	8GB	12GB	质量和速度折中
`Q4_K_M`	4.98GB	8GB	12GB	E4B 常用推荐
`Q5_K_M`	5.48GB	8GB	12GB	更稳的日常使用
`Q6_K`	7.07GB	10GB	16GB	质量优先
`Q8_0`	8.19GB	12GB	16GB	接近原始精度
`BF16`	15.05GB	20GB	24GB	研究、评测、精度对比

如果你的显卡是 8GB，E4B Q4_K_M 是很现实的起点。如果是 12GB 或 16GB，E4B Q8_0 也可以考虑。

Gemma 4 26B A4B 显存表

26B A4B 是 MoE 版本，参数规模更大，但每次推理只激活其中一部分专家。它适合更复杂的问答、代码、工具调用和 Agent 工作流。

量化版本	GGUF 文件体积	最低显存	更稳妥显存	适合场景
`UD-IQ2_M`	9.97GB	14GB	16GB	16GB 显卡极限尝试
`UD-Q2_K_XL`	10.55GB	14GB	16GB	低显存跑 26B
`UD-Q3_K_M`	12.53GB	16GB	20GB	质量略好，仍偏省显存
`UD-IQ4_XS`	13.42GB	16GB	24GB	质量和体积折中
`UD-Q4_K_M`	16.87GB	20GB	24GB	26B 常用推荐
`UD-Q5_K_M`	21.15GB	24GB	32GB	更稳的高质量量化
`UD-Q6_K`	23.17GB	28GB	32GB	质量优先
`Q8_0`	26.86GB	32GB	40GB	接近原始精度
`BF16`	50.51GB	64GB	80GB	单卡消费级不现实

24GB 显存是 26B A4B 比较舒服的分界线。 16GB 显卡可以尝试低比特版本，但上下文长度、并发和多模态都要收敛。

Gemma 4 31B 显存表

31B 是更大的稠密模型。它的优点是综合能力更强，缺点是显存压力比 26B A4B 更直接。

量化版本	GGUF 文件体积	最低显存	更稳妥显存	适合场景
`UD-IQ2_XXS`	8.53GB	12GB	16GB	极限低显存尝试，质量牺牲明显
`UD-IQ2_M`	10.75GB	14GB	18GB	低显存尝试
`UD-Q2_K_XL`	11.77GB	16GB	20GB	16GB 显卡可尝试
`Q3_K_S`	13.21GB	16GB	24GB	更省显存的 3-bit
`Q3_K_M`	14.74GB	20GB	24GB	3-bit 常用折中
`IQ4_XS`	16.37GB	20GB	24GB	接近 Q4 的折中
`Q4_K_M`	18.32GB	24GB	32GB	31B 常用推荐
`Q5_K_M`	21.66GB	28GB	32GB	更稳的高质量量化
`Q6_K`	25.20GB	32GB	40GB	质量优先
`Q8_0`	32.64GB	40GB	48GB	接近原始精度
`BF16`	61.41GB	80GB	96GB	服务器或大显存工作站

31B 的低比特版本可以在 16GB 显卡上做实验，但如果想日常使用，最好从 24GB 显存起步。 Q4_K_M 是比较平衡的选择，Q5_K_M 往上更适合 32GB 以上显存。

为什么实际占用会比文件体积更高

GGUF 文件体积只是权重大小。真正运行时还会增加这些开销：

KV cache：上下文越长，占用越高。
批大小和并发：一次处理更多 token 或多用户并发，会增加显存。
多模态组件：图片、音频、视频输入通常还要加载 mmproj 或额外处理模块。
运行时后端：CUDA、Metal、ROCm、CPU/GPU 分层加载的占用不同。
KV cache 量化：开启 q8_0、q4_0 等 KV cache 量化可以省显存，但可能影响细节。

所以表格里的“最低显存”只能理解为“能启动并短上下文运行”的门槛。如果你要 32K、64K、128K 甚至 256K 上下文，显存需求会明显增加。

怎么选

如果只是想在本地体验 Gemma 4：

4GB 到 6GB 显存：选 E2B Q3_K_M 或 E2B Q4_K_M。
8GB 显存：优先选 E4B Q4_K_M，也可以跑 E2B Q8_0。
12GB 显存：选 E4B Q8_0，或者尝试 26B/31B 的低比特版本。
16GB 显存：可以尝试 26B A4B UD-Q3_K_M 或 31B Q3_K_S，但不要期待长上下文很舒服。
24GB 显存：26B A4B UD-Q4_K_M 和 31B Q4_K_M 是重点选择。
32GB 以上：可以考虑 Q5_K_M、Q6_K，或者更长上下文。

一般用户不需要追 BF16。本地部署的核心不是文件越大越好，而是在显存、速度、上下文和输出质量之间找到平衡。

参考来源

8G 显存跑 llama.cpp 怎么调：32K 更稳，64K 要开 KV Cache 量化

Thu, 23 Apr 2026 12:13:04 +0800

8G 显存到底还能不能把本地大模型跑顺，尤其是在长上下文场景下还能不能保住速度，这是很多人在折腾 llama.cpp 时都会遇到的问题。

核心结论可以先记住三条：

对 8G 显存来说，32K 上下文通常是更稳的平衡点
如果一定要跑 64K，KV Cache 量化基本是必选项
在全显卡运行场景里，盲目拉高 CPU 线程数，反而可能让速度明显下降

一、先解释清楚：32K、64K 和 KV Cache 是什么

很多人第一次看这类调优文章，最容易卡住的就是这三个词。

32K 和 64K 说的是上下文长度，也就是模型一次最多能处理多少 token。这里的 K 就是千，32K 大约是 32000 token，64K 大约是 64000 token。上下文越长，模型一次能看到的历史内容越多，适合长文档问答、长对话和多轮分析。

KV Cache 则是模型为了加速连续生成而保留的一份中间结果缓存。你可以把它理解成：模型已经读过、算过的一部分内容，不会每次都从头重算，而是把关键结果先存起来，后面继续接着用。这里的 K 和 V，来自 Transformer 里的 Key 和 Value。

为什么这三个词总是一起出现？因为：

32K、64K 决定你想让模型一次记住多长内容
KV Cache 决定为了维持这段记忆，要额外占多少显存
上下文越长，KV Cache 通常越大，显存压力也越高

所以很多长上下文变慢的问题，本质上并不是模型“不会算”，而是缓存太大，把显存挤到了临界点。

二、为什么 32K 和 64K 的速度会差这么多

这里用《三体》大约 3 万字的文本做压力测试，对比 32K 和 64K 两种上下文设置。结果很夸张：在文档长度接近的情况下，64K 模式的速度显著下降，总耗时也明显拉长。

问题不在模型突然变笨，而在显存边界被撞到了。

当 32K 模式下，模型权重加缓存还能基本塞进 8G 显存里，数据大多走显卡显存带宽，速度还能维持在比较可用的区间。但一旦切到 64K，缓存体积继续上涨，总占用逼近甚至超过显存上限，系统就会把部分数据挤到内存里。

这时候真正掉下去的，不是算力，而是带宽。

也就是说，很多人看到的是“上下文翻倍后速度暴跌”，本质上其实是数据路径从显存掉到了共享内存或系统内存，推理链路不再跑在高速通道上。

三、64K 还能不能跑，关键在 KV Cache 量化

第二个很关键的结论，是 KV Cache 量化对 8G 显存用户特别重要。

如果不改变模型本身，只针对缓存做量化，长上下文下最直接的收益就是把缓存占用压缩下来，让原本已经溢出的那部分重新回到显存里。这样一来，64K 模式虽然依然比 32K 更吃资源，但至少不会直接跌进最慢的区间。

换句话说：

32K 更像是 8G 显存的默认推荐区间
64K 不是完全不能跑
但如果不上缓存量化，性能很容易从“能用”直接掉到“很难用”

如果你的目标是尽量稳定地跑长上下文，那优先级通常应该是：

先确认显存是否已经逼近上限
再决定是否开启 KV Cache 量化
最后才去继续尝试更激进的吞吐量参数

四、GPU 占用不高，不代表显卡没干活

这是一个很容易打破直觉的点。

很多人看到任务管理器里 GPU 使用率只有二三十，就会怀疑：

是不是参数没设对
是不是模型没真正跑到显卡上
是不是显卡根本没吃满

但这组测试给出的判断是，llama.cpp 这类推理很多时候首先卡的不是核心算力，而是显存读写速度。

也就是说，显卡核心可能很快就把一批计算做完了，但后面还得等下一批权重和缓存数据搬过来。于是你看到的现象就会变成：

核心占用不算高
但整体速度还是上不去

这不是显卡在偷懒，而是数据通路太窄。

所以看本地大模型速度时，不能只盯着 GPU Usage。显存容量、显存带宽、缓存是否溢出，往往更影响最终体验。

五、调大吞吐量参数，确实可能再快一截

这里还做了一个思路很清晰的测试：既然显卡核心并没有完全忙满，那能不能通过调大吞吐量相关参数，让显卡一次处理更多数据，把并行能力进一步压出来。

测试结果表明，这种做法确实有机会把速度再往上拉一段。

但这里也有一个前提：显存还得扛得住。

因为吞吐量相关参数调大之后，往往会带来额外显存占用。如果你本来就在 64K、高缓存、显存见底的状态下继续往上推，就很容易出现两种情况：

直接崩溃
没崩，但被迫进入更慢的共享内存模式

所以更稳妥的顺序通常不是“先把参数拉满”，而是：

先守住显存边界
再考虑吞吐量优化
每调一步都重新看速度和稳定性

六、CPU 线程不是越多越好

这也是整篇内容里最值得记住的坑点之一。

很多人做本地推理调优时，容易下意识觉得线程越多越快，既然机器有那么多线程，不用满就像浪费。但实测给出的结果恰恰相反：在模型已经主要跑在显卡上的情况下，强行把 CPU 线程拉高，性能反而会明显变差。

原因不复杂。

在全显卡运行时，CPU 更像是调度者和预处理协作者，而不是主力计算单元。这时候如果开太多线程，CPU 端的线程竞争、调度切换和上下文切换开销都会变重，最终把本来应该更流畅的数据流打乱。

结果就是：

CPU 更忙了
但整体速度变慢了

所以在这种场景下，默认设置或者较低线程数，往往比一味拉满更靠谱。

七、对 8G 显存用户更实用的一套思路

如果把上面的结论压成一套更容易执行的思路，大概可以整理成这样：

1. 先把 32K 当成默认目标

如果你用的是 8G 显存显卡，先别急着追 64K。32K 往往是速度、稳定性和显存占用之间更现实的平衡点。

2. 想上 64K，先处理缓存问题

不要先想“还能不能再榨一点速度”，而是先确认 KV Cache 有没有量化、显存是不是已经压线。

3. 不要用 GPU 占用率判断一切

低占用不一定代表设置错了，也可能只是显存带宽在拖后腿。

4. 吞吐量优化可以做，但别越过显存边界

这类参数确实能带来收益，但前提是显存还有余量。

5. CPU 线程先保守，再逐步测试

如果模型已经基本跑在显卡上，CPU 线程并不是越高越好。先用默认值或低线程值测试，再看是否值得继续调整。

结语

这组内容最有价值的地方，不只是给出几个测试数字，而是把一个经常被忽略的事实讲清楚了：

本地大模型调优，很多时候拼的不是“有没有把所有参数开到最大”，而是你有没有搞清楚瓶颈到底在算力、显存容量、显存带宽，还是在 CPU 调度。

对 8G 显存用户来说，真正更稳的思路通常不是硬冲最长上下文，而是先守住显存边界，再决定要不要继续往上加。

如果只记一句话，那就是：

32K 往往是 8G 显存更稳的工作区间；64K 不是不能跑，但前提是你已经把 KV Cache 和显存占用管住了。

16G 显卡也能跑 35B 模型：LM Studio 下 MoE 模型的显存压缩思路

Wed, 22 Apr 2026 21:47:34 +0800

很多人对 16G 显存的印象是：本地部署大模型时，差不多也就跑到 12B 到 14B，量化之后再往上就很吃力了。这个判断不算离谱，但也不是 16G 显卡的真正上限。

如果模型选型和参数设置都合适，16G 显卡并不只能停留在“小参数量模型”这一档。围绕这件事，一套比较有代表性的思路是：在 LM Studio 里利用 MoE 模型和合理的卸载策略，把 35B 级模型跑到比较可用的速度。

01 为什么 16G 显卡不一定只能跑 12B 到 14B

这里的核心观点很直接：显存大小固然重要，但模型架构同样重要。

如果你拿一个标准稠密模型去硬塞进 16G 显卡，确实很快就会遇到瓶颈。因为这类模型在推理时通常要参与全部参数计算，显存压力和带宽压力都会直接上来。

但 MoE 模型不一样。它的总参数量可以很大，可是在单次推理时，只会激活其中一部分专家参数。以 35B 级模型为例，虽然总参数规模不小，但单次推理实际参与计算的参数量要小得多，所以它对显存的实际要求没有想象中那么夸张。

也正因为这样，16G 显卡在面对这类模型时，并不是完全没有操作空间。

02 实测重点：35B MoE 模型可以跑得很快

一个重点案例，是 Qwen 3.5 35B A3B 一类的 MoE 模型量化版本。在 16G 显卡配合 LM Studio 做参数调整后，Q6 量化大约能跑到 30 多 tokens/s，此前 Q4 量化甚至能测到更高的速度。

这个结果之所以有参考价值，不只是因为“能跑”，而是因为速度已经进入了“明显可用”的区间。

作为对比，同类大参数量但不是 MoE 的模型，在 16G 显卡上如果直接硬跑，往往会出现爆显存、速度明显掉下来的情况。换句话说，决定结果的不是单纯看参数总量，还要看模型在推理时到底怎么用这些参数。

03 在 LM Studio 里，重点不只一个参数

想在 16G 显卡上把这类模型跑顺，关键不是“碰运气”，而是调对两个参数：

GPU Offload
强制把部分专家层加载到 CPU 内存的参数

第一项比较好理解，GPU Offload 基本就是能拉多高就拉多高，让模型尽量优先使用显卡计算。

第二项才是这里的关键。它的作用不是传统意义上那种“显存爆了以后再借系统内存”，而是主动把一部分专家层放到 CPU 内存里，提前降低显存占用。因为 MoE 模型本来就不是每次都要把所有专家都激活，所以把一部分专家放到内存里，对整体推理速度的影响没有很多人想象中那么夸张。

更稳妥的做法，是先在一个区间里尝试，再根据自己的机器慢慢调：

可以先把相关参数设到 20 到 35 之间
然后结合显存占用和内存压力，逐步微调

本质上，这套方法就是用系统内存去换显存空间。

04 128K 上下文下也能跑，缩小上下文还能继续压显存

还有一个比较有意思的点：测试时把上下文长度拉到了 128K，在这种偏激进的设置下，35B 级 MoE 模型依然能跑出比较高的速度。

这说明一个问题，16G 显卡的瓶颈没有想象中那么死板。尤其在 LM Studio 这种本地推理工具里，很多时候不是“能不能运行”的二选一，而是：

你愿不愿意拿更多内存换显存
你愿不愿意缩短上下文长度
你愿不愿意接受不同量化版本之间的能力差异

如果把上下文从 128K 进一步收缩到 64K 或 32K，显存压力还可以继续下降。也就是说，某些 35B 级 MoE 模型甚至可能在更小显存的显卡上勉强跑起来，只是速度和内存压力要重新权衡。

05 这种方法的代价：对系统内存和虚拟内存要求更高

这类方案并不是白送性能。

需要注意的是，当显存压力被进一步压缩时，系统内存占用会明显上升，虚拟内存的压力也会变大。换句话说，你省下来的不是成本，只是把压力从显卡挪到了内存和磁盘交换空间上。

所以如果你也想照着试，最好先确认几件事：

你的系统内存是否足够
虚拟内存是否留得够大
机器后台是否还有很多占资源的软件在运行

如果这些条件跟不上，最终看到的可能不是“35B 也能飞快跑”，而是整体系统都被拖慢。

06 量化版本也不是越激进越好

这里还有一个实际选择：虽然更低位数的量化通常能进一步节省显存，但不一定是最合适的方案。

作者给出的经验是，某些模型在 Q4 下速度确实更高，但对原始能力的影响也更明显；相对来说，Q6 在速度和能力保留之间更平衡。所以最终不一定要无脑追求最小体积，而是要看你更在意什么：

如果你主要追求速度和塞进显存
或者你更在意模型原有能力的保留

这两种取向，对应的量化选择可能并不一样。

07 哪些模型思路值得试

从这个思路来看，最值得尝试的并不是“盲目追大参数量”，而是优先找适合这种玩法的模型：

MoE 架构模型
在 LM Studio 里支持较好、量化版本较全的模型
对长上下文或指令跟随有明确优势的模型

除了主讲的 35B MoE 模型，这类方案也适合延伸到一些其他方向，比如偏长上下文记忆、指令遵循表现更好的实验性模型，以及一些速度表现不错的轻量量化版本。

这类推荐背后的逻辑其实很统一：先找架构上适合“内存换显存”的模型，再谈参数调优，而不是先看参数量再决定能不能跑。

08 简单总结

如果你手里正好是一张 16G 显卡，觉得本地大模型最多只能玩 12B 到 14B，这种想法可以稍微更新一下。

更准确的说法应该是：

16G 显卡跑大模型并不是完全没戏
稠密模型和 MoE 模型要分开看
LM Studio 里的 GPU Offload 和专家层转移到 CPU 内存的参数，能明显改变显存占用情况
你实际上是在用更高的内存压力，换更大的模型规模和更高的可用速度

这套思路不一定适合所有机器，但它至少说明了一点：本地部署大模型时，显存上限不是唯一限制，模型架构和推理配置同样重要。

Ollama 多显卡使用笔记：显存叠加、GPU 选择和常见误区

Sun, 19 Apr 2026 00:18:00 +0800

折腾 Ollama 本地推理时，经常会遇到类似问题：我现在有一张显卡，主板还有空 PCIe 槽，再加几张 GPU 对 Ollama 有帮助吗？多显卡是否必须同型号？显存能不能叠加？会不会像训练框架那样多卡并行加速？

这篇整理一下 Ollama 多显卡的实际行为。重点先说结论：

Ollama 支持多 GPU。
多 GPU 最大价值通常是让更大的模型放进总显存，而不是线性提升 token/s。
默认策略下，如果模型能完整放进某一张 GPU，Ollama 倾向于放在单卡上。
如果模型无法完整放进单张 GPU，Ollama 会把模型分布到可用 GPU 上。
不同型号 GPU 可以被 Ollama 看到并使用，但性能和分配效果不一定理想。
不需要 SLI / NVLink 才能用多卡。
想限制 Ollama 使用哪些 GPU，需要用 CUDA_VISIBLE_DEVICES、ROCR_VISIBLE_DEVICES 或 GGML_VK_VISIBLE_DEVICES。

官方行为：先单卡，放不下再多卡

Ollama FAQ 里对多 GPU 加载逻辑说得比较直接：加载新模型时，Ollama 会估算模型所需 VRAM，并和当前可用显存比较。如果模型能完整放进某一张 GPU，它会加载到那张 GPU 上；如果单张 GPU 放不下，才会分布到所有可用 GPU 上。

这个策略的原因是性能。单卡加载通常能减少推理时跨 PCIe 总线的数据传输，因此往往更快。

所以不要把 Ollama 的多 GPU 理解成“有几张卡就自动几倍加速”。更准确的理解是：

小模型能进单卡：通常单卡跑。
大模型单卡放不下：跨多卡分层加载。
显存仍不够：一部分会落到系统内存，速度会明显下降。

可以用下面命令确认模型到底加载到了哪里：

`1`	`ollama ps`

输出里的 PROCESSOR 会显示类似：

1
2
3

100% GPU
48%/52% CPU/GPU
100% CPU

如果看到 48%/52% CPU/GPU，说明已经有一部分在系统内存里了。此时多加 GPU 或换更大显存的卡，通常比继续依赖 CPU/RAM 更有意义。

多 GPU 不是简单叠算力

本地大模型推理和游戏里的 SLI 不是一回事。Ollama 多卡时，更常见的是把模型的不同层或张量放到不同设备上。这样可以用多张卡的显存装下更大的模型，但推理过程中仍然可能需要设备之间传递数据。

因此，多 GPU 带来的收益通常分两种：

显存收益：更容易装下大模型，或者避免落到 CPU/RAM。
性能收益：只有在原本单卡装不下或严重混 CPU 时，提升才会很明显。

如果一个 8B 或 14B 模型本来就能完整放进单张 3090，强行拆到两张卡不一定更快，甚至可能因为跨卡传输变慢。Ollama 官方默认“能单卡就单卡”的策略，就是为了避免这类不必要的跨 PCIe 开销。

不需要 SLI 或 NVLink

Ollama 多 GPU 不依赖 SLI。多张普通 PCIe GPU 只要驱动和 Ollama 能识别，就可以被调度。

NVLink 或更高 PCIe 带宽可能对某些跨卡场景有帮助，但它不是 Ollama 多 GPU 的前提条件。很多二手 GPU 服务器或工作站，靠普通 PCIe 多卡也能跑。

真正要注意的是 PCIe 带宽。x1、x4、x8、x16 的差异会影响模型加载到显存的速度；如果频繁切换大模型，PCIe 链路会更容易成为瓶颈。模型加载完成后，生成阶段受 PCIe 的影响通常会小一些，但跨卡分层仍然可能带来额外开销。

比较稳的建议是：

能用 x16 / x8 就不要用矿卡 x1 转接。
大模型频繁切换时，PCIe 带宽更重要。
如果模型长期常驻显存，PCIe 带宽瓶颈会相对不明显。
多卡机器要重点看主板 PCIe 拓扑和 CPU 直连通道。

如何限制 Ollama 使用哪些 NVIDIA GPU

NVIDIA 多卡环境下，用 CUDA_VISIBLE_DEVICES 控制 Ollama 能看到哪些卡。

临时运行：

`1`	`CUDA_VISIBLE_DEVICES=0,1 ollama serve`

只让 Ollama 用第二张卡：

`1`	`CUDA_VISIBLE_DEVICES=1 ollama serve`

强制不用 NVIDIA GPU，可以给一个无效 ID：

`1`	`CUDA_VISIBLE_DEVICES=-1 ollama serve`

官方文档提醒，数字 ID 的顺序可能变化，更可靠的是用 GPU UUID。先查看 UUID：

`1`	`nvidia-smi -L`

输出类似：

1
2

GPU 0: NVIDIA GeForce RTX 3090 (UUID: GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
GPU 1: NVIDIA GeForce RTX 3070 (UUID: GPU-yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy)

然后指定 UUID：

`1`	`CUDA_VISIBLE_DEVICES=GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ollama serve`

如果 Ollama 是 Linux systemd 服务安装的，需要写到服务环境变量里：

`1`	`sudo systemctl edit ollama.service`

加入：

1
2

[Service]
Environment="CUDA_VISIBLE_DEVICES=0,1"

然后重载并重启：

1
2

sudo systemctl daemon-reload
sudo systemctl restart ollama

AMD 和 Vulkan 的选择变量

AMD ROCm 环境下，用 ROCR_VISIBLE_DEVICES 控制可见 GPU：

`1`	`ROCR_VISIBLE_DEVICES=0,1 ollama serve`

如果要强制不用 ROCm GPU，也可以用无效 ID：

`1`	`ROCR_VISIBLE_DEVICES=-1 ollama serve`

Ollama 官方 GPU 文档还提到，如果用实验性的 Vulkan 支持，可以通过 GGML_VK_VISIBLE_DEVICES 选择 Vulkan GPU：

`1`	`OLLAMA_VULKAN=1 GGML_VK_VISIBLE_DEVICES=0 ollama serve`

如果 Vulkan 设备有问题，可以禁用：

`1`	`GGML_VK_VISIBLE_DEVICES=-1 ollama serve`

AMD 多卡比 NVIDIA 更容易遇到驱动、ROCm 版本、GFX 版本支持的问题。官方文档中也提到 Linux 下 ROCm 驱动版本、HSA_OVERRIDE_GFX_VERSION 等兼容性处理。多张不同代 AMD 卡混用时，先确认每张卡是否单独可用，再考虑多卡。

Docker 里怎么暴露多张 GPU

如果用 Docker 跑 Ollama，NVIDIA 环境通常需要先安装 nvidia-container-toolkit，然后用 --gpus 暴露设备。

暴露全部 GPU：

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

只暴露指定 GPU：

docker run -d \
  --gpus '"device=0,1"' \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

也可以结合环境变量：

docker run -d \
  --gpus=all \
  -e CUDA_VISIBLE_DEVICES=0,1 \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

如果容器里 nvidia-smi 看不到卡，Ollama 也不可能用到 GPU。先排查 Docker GPU passthrough，再排查 Ollama。

`OLLAMA_SCHED_SPREAD` 是什么

在一些多 GPU 配置讨论里，会看到 OLLAMA_SCHED_SPREAD=1 或 OLLAMA_SCHED_SPREAD=true。它和 Ollama 的调度策略有关，常被用于希望模型或请求更分散地利用多张 GPU 的场景。

可以这样设置：

`1`	`OLLAMA_SCHED_SPREAD=1 ollama serve`

或者 systemd：

1
2

[Service]
Environment="OLLAMA_SCHED_SPREAD=true"

不过它不是万能开关。开启后并不等于 token/s 线性增长，也可能因为多个模型同时加载、显存估算、上下文长度和 KV cache 增长导致 OOM。官方 FAQ 的核心策略仍然是：如果单 GPU 能完整容纳模型，单 GPU 通常更高效；单 GPU 放不下时才跨多 GPU。

所以建议把 OLLAMA_SCHED_SPREAD 当成高级调度实验项，而不是多卡必开项。先理解默认行为，再根据实际 ollama ps、日志和 nvidia-smi 观察结果调整。

怎么观察多卡是否真的用上

常用观察命令：

`1`	`ollama ps`

`1`	`watch -n 0.5 nvidia-smi`

查看 Ollama 服务日志：

`1`	`journalctl -u ollama -f`

如果使用 Docker：

`1`	`docker logs -f ollama`

你需要关注：

Ollama 是否发现兼容 GPU。
模型是否显示 100% GPU 或 CPU/GPU 混合。
每张卡显存是否有占用。
加载模型时是否多卡显存同时增长。
生成时 token/s 是否比 CPU/RAM 混跑明显改善。
是否频繁 OOM 或卸载模型。

如果只看 GPU 利用率，很容易误判。LLM 推理时 GPU 利用率不一定长期满载，尤其是多卡、低 batch、小上下文、慢 CPU 或慢 PCIe 环境下。

常见误区

误区 1：两张 12GB 显卡等于一张 24GB 显卡

不完全等价。多卡可以让模型跨设备放置，但跨卡访问有额外开销。它能解决“放不下”的问题，不一定等价于单张大显存卡的速度和稳定性。

误区 2：不同型号显卡不能混用

不一定。只要驱动、计算能力和运行库都支持，Ollama 可以看到多张 GPU。但混用时，速度通常受较慢卡、较小显存和 PCIe 拓扑影响。最稳的多卡配置仍然是同型号、同显存、同代驱动支持良好的卡。

误区 3：多卡一定比单卡快

不一定。如果模型能完整放进单张快卡，单卡可能更快。多卡主要适合大模型、长上下文、单卡显存不够的情况。

误区 4：必须有 NVLink / SLI

不需要。普通 PCIe 多卡也能被 Ollama 使用。NVLink 不是前提。

误区 5：加 GPU 后不用重启服务

不一定。Linux systemd 服务、Windows 后台应用、Docker 容器都可能需要重启，才能重新识别设备和环境变量。

选卡建议

如果目标是 Ollama 本地推理，优先级大致是：

单卡显存越大越省心。
同型号多卡比混合多卡更容易排错。
PCIe 通道越完整，加载大模型越舒服。
老卡要先确认 CUDA compute capability 或 ROCm 支持。
多卡电源、散热和机箱风道要提前算清楚。

对于预算有限的二手平台：

双 3090 仍然是很常见的大显存方案。
P40 / M40 这类老 Tesla 显存大，但功耗、散热、驱动和性能都要权衡。
4070 / 4070 Ti 这类新卡能效好，但单卡显存容量限制更明显。
多张 8GB 老卡能折腾，但不建议为了大模型长期使用。

小结

Ollama 多显卡支持可以理解成“显存扩展优先，性能加速其次”。如果模型能完整放进一张 GPU，默认单卡通常更快；如果单卡放不下，多卡可以把模型分布到多张 GPU 上，避免大量落到 CPU/RAM，从而让大模型变得可用。

实际配置时，先用 ollama ps 看模型加载位置，再用 nvidia-smi 或 ROCm 工具观察显存占用。需要限制 GPU 时，NVIDIA 用 CUDA_VISIBLE_DEVICES，AMD ROCm 用 ROCR_VISIBLE_DEVICES，Vulkan 用 GGML_VK_VISIBLE_DEVICES。如果在 Docker 中运行，先确保容器层面能看到 GPU。

多卡不是魔法。它能帮你装下更大的模型，但不保证线性加速。真正稳定好用的路线，仍然是尽量选大显存单卡或同型号多卡，并把驱动、PCIe、电源、散热和模型量化一起考虑。

参考链接

Ollama FAQ：How does Ollama load models on multiple GPUs?：https://github.com/ollama/ollama/blob/main/docs/faq.mdx
Ollama GPU 文档：Hardware support / GPU Selection：https://github.com/ollama/ollama/blob/main/docs/gpu.mdx
Ollama Docker Hub：https://hub.docker.com/r/ollama/ollama
NVIDIA Container Toolkit：https://github.com/NVIDIA/nvidia-container-toolkit

Gemma 4 E4B 越狱版和官方普通版有什么区别

Sat, 18 Apr 2026 10:20:00 +0800

如果你看到 HauhauCS/Gemma-4-E4B-Uncensored-HauhauCS-Aggressive 这种模型，最关键的一点是：它不是 Google 新发的另一套 Gemma 4，而是建立在官方 google/gemma-4-E4B-it 之上的一个非官方衍生版本，重点是把模型行为调到“更少拒答”。

所以它和普通版真正拉开的，通常不是底层架构，而是对齐策略和输出风格。

这个衍生版模型卡自己说了什么

Hugging Face 模型卡里，这个 HauhauCS 版本明确写了几件事：

它基于 google/gemma-4-E4B-it
它声称“没有改数据集或能力”
它声称变化只是“去掉拒答”
Aggressive 版本被描述为“完全解锁，不会拒绝提示词”

这些是作者自己的表述，不是独立第三方测评结果。但从定位上已经很清楚：这就是一个以“减少安全拒答”为目标的非官方衍生版。

官方版 vs 所谓“越狱版”

维度	官方 `google/gemma-4-E4B-it`	`Gemma-4-E4B-Uncensored-HauhauCS-Aggressive`
来源	Google 官方发布	Hugging Face 第三方衍生版
基础模型	Gemma 4 E4B 指令微调版	同一模型家族，且模型卡明确写明基于 `google/gemma-4-E4B-it`
核心目标	通用助理能力 + 负责任使用框架	尽量减少拒答，让模型继续输出
安全取向	与 Gemma 家族的安全文档、禁止用途政策一致	明确削弱拒答与护栏行为
回答风格	更可能拒绝、转向或保守回答敏感请求	更可能直接继续回答原本会被拦下的问题
风险水平	默认风险更低，但仍不代表绝对安全	默认风险更高，更容易输出不安全或不合规内容
用于产品/团队	更容易通过评审和落地	更难用于公开产品、企业环境或合规场景
额外防护需求	仍需要应用层防护	更依赖你自己做额外的审核、过滤和限制

核心区别是“对齐方式”变了，不是“能力等级”突然变高

很多人会把“uncensored”理解成“更强”，这个判断通常并不准确。

对这种衍生版来说，最先变化的是：

拒答频率
对敏感请求的服从程度
最终答案里剩下多少安全过滤

而不会因为名字里写了 Uncensored，就自动意味着下面这些也一起升级：

模型架构突然更强
上下文窗口突然更大
多模态能力突然更完整
推理上限明显更高

更准确的理解是：它通常只是同一模型家族里，行为调校不同的一版，而不是更高档的新模型。

为什么官方普通版会更保守

Google 的 Gemma 官方资料一直把这个系列放在“负责任 AI 开发”的框架里。Gemma 模型卡会明确谈到误用、有害内容、隐私和偏见等风险；Gemma Prohibited Use Policy 也明确禁止把 Gemma 或其衍生模型用于：

危险、违法或恶意活动
生成有害、误导、欺骗性内容
覆盖或绕过安全过滤

所以官方版并不是“碰巧更保守”，而是它从文档、许可和部署定位上，本来就是那样设计的。

什么情况下普通版更合适

如果你更在意下面这些，优先用官方 google/gemma-4-E4B-it：

产品部署
团队协作
企业或对外场景
较低的政策与法律风险
更容易解释和审查的输出行为

对大多数正常应用来说，这通常才是默认优先项。

什么情况下有人会去试越狱版

选择这类 uncensored 衍生版的人，常见目的通常是：

本地私人实验
测试官方版是否“过早拒答”
角色扮演或更开放的创作场景
对比不同对齐版本的行为差异

但对应的代价也很明确：模型提供方少做的那部分安全约束，需要你自己补回来。

结论

所谓 Gemma 4 E4B “越狱版”和官方普通版，最本质的区别其实是：

官方版追求的是“有护栏的可用能力”
越狱版追求的是“更少拒答的可输出性”

它不自动等于更强，更多只是更放开。

如果你的目标是稳定、可解释、适合部署，先用官方版更合理。
如果你的目标是本地实验，并且你清楚知道安全、合规和输出风险都要自己承担，那这类 uncensored 衍生版可以当成“行为差异版本”来测试，但不应该直接理解成普通版的全面升级替代品。

参考来源

Hugging Face: HauhauCS/Gemma-4-E4B-Uncensored-HauhauCS-Aggressive
Hugging Face: google/gemma-4-E4B-it
Google AI for Developers: Gemma Prohibited Use Policy
Google AI for Developers: Gemma model card

llama-quantize 怎么用：GGUF 模型量化入门

Sun, 12 Apr 2026 09:42:36 +0800

llama-quantize 是 llama.cpp 里的量化工具，用来把高精度的 GGUF 模型转换成更小的量化版本。

它最常见的用途，是把类似 F32、BF16 或 FP16 这样的高精度模型，转换成 Q4_K_M、Q5_K_M、Q8_0 等更适合本地运行的格式。量化后模型体积会明显变小，推理通常也会更快，但精度会有一定损失。

基本用法

一个典型流程通常是先准备原始模型，再转换为 GGUF，最后执行量化。

# install Python dependencies
python3 -m pip install -r requirements.txt

# convert the model to ggml FP16 format
python3 convert_hf_to_gguf.py ./models/mymodel/

# quantize the model to 4-bits (using Q4_K_M method)
./llama-quantize ./models/mymodel/ggml-model-f16.gguf ./models/mymodel/ggml-model-Q4_K_M.gguf Q4_K_M

量化完成后，就可以直接用 llama-cli 加载新的 GGUF 文件：

1
2

# start inference on a gguf model
./llama-cli -m ./models/mymodel/ggml-model-Q4_K_M.gguf -cnv -p "You are a helpful assistant"

常见参数

--allow-requantize：允许对已经量化过的模型再次量化，但通常不推荐，质量可能掉得比较明显
--leave-output-tensor：保留输出层不量化，体积会更大，但有时能换来更好的质量
--pure：关闭混合量化，让更多张量使用同一量化类型
--imatrix：使用重要性矩阵优化量化效果，通常值得优先考虑
--keep-split：保留输入模型的分片结构，而不是合并成单个文件

如果只是想先跑起来，最实用的起点还是：

`1`	`./llama-quantize ./models/mymodel/ggml-model-f16.gguf ./models/mymodel/ggml-model-Q4_K_M.gguf Q4_K_M`

量化怎么选

可以先把不同量化等级理解成“体积、速度和质量之间的交换”：

Q8_0：体积较大，但质量通常更稳
Q6_K / Q5_K_M：常见的平衡型选择
Q4_K_M：很常见的默认档，体积和效果通常比较均衡
Q3 / Q2：适合资源非常紧张的场景，但质量下降会更明显

从给出的示例数据看，量化等级越低，模型通常越小；而在实际推理里，更高精度并不一定总是更快，所以选型重点通常不是“越大越好”，而是“在你的硬件上够稳、够省、效果也能接受”。

实用建议

优先从 Q4_K_M 或 Q5_K_M 开始试
如果更看重质量，再往 Q6_K 或 Q8_0 提升
如果机器资源比较紧，再尝试 Q3 或 Q2
最好始终用同一批测试问题比较不同量化版本

一句话总结：llama-quantize 的核心价值，不是单纯把模型变小，而是让 GGUF 模型在本地设备上更容易跑起来。

llama.cpp 如何从 Hugging Face 获取 GGUF 模型

Sun, 12 Apr 2026 09:31:38 +0800

llama.cpp 可以直接配合 Hugging Face 上的 GGUF 模型使用，不一定要先手动把文件下载到本地。

如果模型仓库本身已经提供了 GGUF 文件，可以直接在命令行里使用 -hf 参数，例如：

`1`	`llama-cli -hf ggml-org/gemma-3-1b-it-GGUF`

默认情况下，这个参数会从 Hugging Face 下载模型。
如果你使用的是其他兼容 Hugging Face API 的模型托管服务，也可以通过环境变量 MODEL_ENDPOINT 切换下载端点。

需要注意的是，llama.cpp 只能直接使用 GGUF 格式。
如果拿到的是其他格式的模型文件，就需要先用仓库里的 convert_*.py 脚本转换成 GGUF。

Hugging Face 还提供了一些和 llama.cpp 相关的在线工具，常见用途包括：

把模型转换为 GGUF
对模型做量化，减小体积
转换 LoRA 适配器
在线编辑 GGUF 元数据
直接托管 llama.cpp 推理服务

如果只想记住一个最实用的结论：优先找已经提供 GGUF 的模型仓库，然后直接用 llama-cli -hf <user>/<model>，通常是最省事的做法。

Gemma-4-31B-it 里的 it 是什么意思

Sat, 11 Apr 2026 20:45:34 +0800

在 gemma-4-31B-it 这个名字里，it 是 Instruction Tuned 的缩写，也就是“指令微调”版本。

对多数人来说，可以把它理解成：这个模型更适合聊天、问答、写代码和执行明确任务。

`it` 是什么

模型通常会有两类常见版本：

Base / Pre-trained：基础模型，更接近原始文本预测器。
it：经过指令微调，更擅长理解“请帮我做什么”这类输入。

如果你输入“请翻译这段话”或“帮我写一段 Python 代码”，it 版本通常会更稳定，也更符合对话式使用习惯。

`31B` 是什么

31B 表示这个模型大约有 310 亿参数。

一般来说：

参数量越大，模型能力和知识覆盖往往更强
同时对显存或内存的要求也会更高

所以 31B 属于比较大的模型，运行门槛也会更高。

`Gemma-4` 又表示什么

Gemma-4 表示模型系列与代际：

Gemma：Google 的开源模型系列
4：该系列的第 4 代版本

怎么选

如果你的目标是聊天、问答、翻译、写代码，通常优先选择带 -it 的版本。

如果你做的是更底层的研究、微调或自定义训练任务，才更可能去看基础版。

一句话总结

gemma-4-31B-it 可以直接理解成：Gemma 4 系列、310 亿参数、适合对话和指令任务的版本。

Hugging Face 选择 Llama 的 GGUF 模型时，量化怎么选：从 Q8 到 Q2 的实用建议

Sat, 11 Apr 2026 20:07:29 +0800

在 Hugging Face 选择 Llama 的 GGUF 模型时，可以先把量化等级理解成“分辨率”。分辨率越低，占用的 VRAM/RAM 越少，但质量也会逐步下降。

先理解 32、16 和 Q 系列

32：可理解为原始未压缩版本，质量最高，但硬件要求非常高。
16：仍接近原始质量，体积约为 32 的一半，实用性更高。
Q8：从这里开始进入量化版本，通常写作 Q8_0 或 Q8。
Q6、Q5、Q4、Q3、Q2：数字越小，资源占用越低，质量也越容易出现可见损失。

`K_M` / `K_S` 是什么

K_M 和 K_S 表示混合量化策略：

大部分权重使用当前量化等级
一些关键部分保留更高精度

因此同级别下，Qx_K_M 或 Qx_K_S 通常会比纯 Qx 略好。

实用选型建议

硬件足够：优先 Q8。
显存或内存紧张：逐级下调到 Q6 / Q5 / Q4。
下限建议：尽量不要低于 Q4，优先 Q4_K_M。
Q3 及以下：质量下降会越来越明显。

质量梯度（高到低）

32
16

– 在这一点之上，质量是一样的，但是硬件要求太疯狂了 –

Q8
Q6_K_M
Q6_K_S
Q6
Q5_K_M
Q5_K_S
Q5

– 这是典型的甜蜜点 –

Q4_K_M
Q4_K_S
Q4

– 在这一点之下，质量下降变得可见 –

Q3_K_M
Q3_K_S
Q3
Q2_K_M
Q2_K_S
Q2

如果你只想要一个简单结论：多数场景从 Q8 或 Q6_K_M 起步，不够再降到 Q5 或 Q4_K_M，通常更稳妥。

Windows 局域网访问 Ollama API 设置指南

Sat, 11 Apr 2026 16:43:52 +0800

如果你希望局域网内其他设备访问本机 Ollama API，可以按下面步骤配置。

设置监听端口

先将 Ollama 监听地址改为所有网卡：

OLLAMA_HOST=0.0.0.0:11434

打开防火墙

打开防火墙高级设置后，新建一条入站规则并放行目标端口（例如 8080）：

按下 Win + S，搜索并打开“Windows Defender 防火墙”。
点击“高级设置”。
选择“入站规则” -> “新建规则…”。
规则类型选“端口”，点击“下一步”。
选择协议（通常是 TCP），在“特定本地端口”输入要开放的端口号（例如 8080），点击“下一步”。
选择“允许连接”，点击“下一步”。
在“配置文件”中勾选“域”“专用”“公用”，点击“下一步”。
为规则命名（例如 OpenPort8080），点击“完成”。

运行 Ollama

Ollama run 模型

通过 API 访问模型

curl http://192.168.x.xxx:11434/api/generate -d '{
  "model": "gemma4",
  "prompt": "这个是什么模型?"
}'

Gemma 4 本地调用指南：从一键运行到开发集成

Fri, 10 Apr 2026 22:54:17 +0800

如果你想在本地调用 Gemma 4（Google 2026 年发布的新一代开源模型），可以按需求从这四类方案里选。

1) 最快上手：Ollama（推荐）

这是门槛最低的方式，适合快速测试、日常对话和本地 API 调用。

`1`	`ollama run gemma4`

特点：

Win/Mac/Linux 都可用
自动处理硬件加速
提供兼容 OpenAI 风格的本地 API

2) 图形界面：LM Studio / Unsloth Studio

如果你更习惯桌面 GUI（类似 ChatGPT），这两类工具更顺手。

LM Studio：可直接搜索和下载 Hugging Face 上的 Gemma 4 量化模型（如 4-bit、8-bit），并查看资源占用。
Unsloth Studio：除了推理，也支持低显存微调。对 6GB-8GB 显存机器更友好。

3) 低配与极致控制：llama.cpp

适合老机器、纯 CPU 场景，或希望深度控制推理参数的用户。

你可以使用 .gguf 模型文件配合量化版本，在更低硬件门槛下运行 Gemma 4。

4) 开发集成：Transformers / vLLM

如果你要把 Gemma 4 接进自己的应用：

Transformers：适合 Python 项目内直接加载模型
vLLM：适合高性能 GPU 场景和高吞吐推理服务

快速选型

需求	推荐工具	硬件门槛
我只想马上跑起来	Ollama	低（自动适配）
我更喜欢图形界面	LM Studio	中
显存很紧张（6GB-8GB）	Unsloth / llama.cpp	低
我要做本地 AI 应用开发	Ollama / Transformers / vLLM	中到高
我要做微调训练	Unsloth Studio	中到高

模型尺寸建议

Gemma 4 有多种尺寸（如 E2B、E4B、31B）。

普通办公本优先选量化后的 E2B / E4B
显存更充足时再尝试更大版本

Ollama 云模型是什么，怎么用

Thu, 09 Apr 2026 18:42:32 +0800

如果你平时用 Ollama 跑本地模型，应该很容易理解云模型。

区别只有一个核心点：
本地模型是在你的电脑上推理，云模型是在 Ollama 的云端推理，再把结果返回给你。

云模型是什么

Ollama 云模型保留了 Ollama 的调用方式，但把计算位置从本地换到了云端。

这样做的好处是：

本地硬件压力更小
更容易使用本地机器跑不动的大模型
仍然可以沿用熟悉的 Ollama 工作流

和本地模型的区别

对比项	本地模型	云模型
运行位置	本机	云端
硬件要求	高	低
延迟	更低	受网络影响
隐私性	更强	请求会发送到云端

如果你更在意隐私、低延迟和离线使用，本地模型更合适。
如果你本地硬件不够，但又想体验更大的模型，云模型更方便。

怎么识别云模型

当前 Ollama 的云模型一般会带 -cloud 后缀，例如：

`1`	`gpt-oss:120b-cloud`

可用模型列表可能会变化，实际以 Ollama 官方页面为准。

怎么用

先登录：

`1`	`ollama signin`

登录完成后，直接运行云模型：

`1`	`ollama run gpt-oss:120b-cloud`

如果你是在代码里调用，也可以配置 API Key：

`1`	`export OLLAMA_API_KEY=your_api_key`

Python 示例：

import os
from ollama import Client

client = Client(
    host="https://ollama.com",
    headers={"Authorization": "Bearer " + os.environ["OLLAMA_API_KEY"]},
)

messages = [
    {"role": "user", "content": "为什么天空是蓝色的？"}
]

for part in client.chat("gpt-oss:120b-cloud", messages=messages, stream=True):
    print(part["message"]["content"], end="", flush=True)

小结

Ollama 云模型可以理解成一句话：

命令基本没变，只是模型不在你本地跑了。

如果你的电脑带不动大模型，但你又想继续用 Ollama 的方式调用模型，云模型就是一个很直接的方案。

从 Hugging Face 下载 GGUF 模型并导入 Ollama

Thu, 09 Apr 2026 11:00:07 +0800

如果某个模型在 Ollama 官方库里没有现成版本，或者你想使用 Hugging Face 上的特定 GGUF 文件，可以手动下载后再导入 Ollama。

第 1 步：从 Hugging Face 下载 GGUF 文件

先在 Hugging Face 上找到目标模型对应的 GGUF 文件。通常会看到多个量化版本，例如：

Q4_K_M
Q5_K_M
Q8_0

选择哪个版本，取决于你的显存、内存和你对速度、质量的取舍。下载后把 .gguf 文件放到固定目录，后面在 Modelfile 里直接引用。

第 2 步：编写 Modelfile

在模型文件同目录新建一个 Modelfile。最基本的写法如下：

`1`	`FROM ./model.gguf`

如果文件名不同，就改成实际文件名，例如：

`1`	`FROM ./gemma-3-12b-it-q4_k_m.gguf`

如果只是先跑起来，通常这一行 FROM 就够了。

第 3 步：导入到 Ollama

然后执行：

`1`	`ollama create myModelName -f Modelfile`

myModelName 是你希望在 Ollama 里使用的本地模型名
-f Modelfile 表示从这个配置文件创建模型

创建成功后，这个 GGUF 文件就会成为一个可直接调用的本地模型。

第 4 步：运行模型

创建完成后直接运行：

`1`	`ollama run myModelName`

之后它的使用方式就和 ollama pull 下来的模型基本一致。

如何查看现有模型的 Modelfile

如果你不确定 Modelfile 应该怎么写，可以直接查看现有模型的配置：

`1`	`ollama show --modelfile llama3.2`

这条命令会输出 llama3.2 的 Modelfile 内容，适合拿来参考：

FROM 应该怎么写
模板和 system prompt 是怎么组织的
参数是如何声明的

什么时候适合用这条路线

下面这些场景适合从 Hugging Face 手动导入：

Ollama 官方库里还没有你要的模型
你想使用某个特定量化版本
你已经手动下载好了 GGUF 文件
你想更精细地控制模型封装方式

如果官方库里已经有现成版本，直接 pull 通常更省事；但当你需要特定量化或自定义封装时，GGUF + Modelfile 会更灵活。

常见注意点

FROM 后面的路径必须和实际 .gguf 文件位置一致。
文件名里如果有空格或特殊字符，建议先改成更简单的名字。
不同 GGUF 量化版本对内存和速度影响很大，导入成功不代表运行一定流畅。
如果模型是聊天模型，后续通常还需要根据其格式调整 prompt 模板，效果才会更稳定。

结论

从 Hugging Face 下载 GGUF 文件再导入 Ollama 并不复杂。准备好模型文件，写一个最小可用的 Modelfile，再执行 ollama create，就可以把第三方 GGUF 模型接入 Ollama。

Ollama 下载模型 pull 速度很慢的排查和解决办法

Thu, 09 Apr 2026 10:42:39 +0800

ollama pull model_name:tag 在有些地区下载速度会很慢，而且过程并不稳定。

如果你遇到的是大模型下载到一半反复中断、报错 TLS handshake timeout 或 unexpected EOF，那么问题很可能不只是 registry.ollama.ai 本身，而是后续跳转到的实际下载链路。

这篇文章记录一次简单直接的排查思路：先拿到模型文件的真实下载地址，再确认最终流量落到哪里，最后只针对关键域名做网络优化。

获取模型文件的下载地址

可以借助下面这个项目，把 Ollama 模型对应的 manifest 和 blob 下载地址直接提取出来：

https://github.com/Gholamrezadar/ollama-direct-downloader

以 gemma4:latest 为例，可以提取出类似下面这些链接。

Manifest 地址

`1`	`https://registry.ollama.ai/v2/library/gemma4/manifests/latest`

Blob 地址

https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:56380ca2ab89f1f68c283f4d50863c0bcab52ae3f1b9a88e4ab5617b176f71a3

如果你只是想快速验证，也可以直接用 curl 下载 manifest 和 blob：

curl -L "https://registry.ollama.ai/v2/library/gemma4/manifests/latest" -o "latest"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11" -o "sha256-f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a" -o "sha256-4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2" -o "sha256-7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2"

跳转后的真实下载地址

尝试用 wget 下载其中一个 blob，会发现请求并不是一直停留在 registry.ollama.ai，而是会继续跳转到一个 Cloudflare R2 对象存储地址：

wget https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
--2026-04-09 09:22:04--  https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
Resolving registry.ollama.ai (registry.ollama.ai)... 104.21.75.227, 172.67.182.229, 2606:4700:3034::ac43:b6e5, ...
Connecting to registry.ollama.ai (registry.ollama.ai)|104.21.75.227|:443... connected.
HTTP request sent, awaiting response... 307 Temporary Redirect
Location: https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/4c/4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a/data?... [following]
--2026-04-09 09:22:05--  https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/4c/4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a/data?...
Resolving dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com (dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com)... 172.64.66.1, 2606:4700:2ff9::1
Connecting to dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com|172.64.66.1|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9608338848 (8.9G) [application/octet-stream]

从日志里可以看到几个关键信息：

registry.ollama.ai 返回了 307 Temporary Redirect
最终下载地址落在 *.r2.cloudflarestorage.com
真正承载大文件传输的，实际上是后面的对象存储域名

这一步很重要，因为它说明如果你的代理或分流规则只覆盖了 registry.ollama.ai，但没有处理 *.r2.cloudflarestorage.com，那下载仍然可能很慢，甚至反复中断。

调整网络设置

确认真实下载链路之后，排查方向就会清晰很多。

如果你正在使用代理、分流或自定义 DNS，建议优先检查下面几件事：

registry.ollama.ai 和 *.r2.cloudflarestorage.com 是否走了同一条稳定线路
代理规则是否只覆盖了前者，而漏掉了后者
当前出口是否适合持续下载数 GB 到数十 GB 的大文件

这类问题的关键并不是“能不能打开官网”，而是“跳转后的对象存储链路是否稳定、是否能长时间持续传输”。很多时候，真正需要优化的是 Cloudflare R2 这一层，而不是前面的 registry 域名。

调整前后的对比

下面是一次实际下载 gemma4:31b-it-q8_0 时的表现。

调整前，下载速度较慢，而且会在中途报错：

PS C:\Users\knightli> ollama run gemma4:31b-it-q8_0
pulling manifest
pulling a0feadb736f5:  38% ▕██████████████████████                                    ▏  12 GB/ 33 GB  1.2 MB/s   4h40m
Error: max retries exceeded: unexpected EOF

调整后，再次下载同一个模型时，速度和稳定性都有明显改善：

1
2
3

PS C:\Users\knightli> ollama run gemma4:31b-it-q8_0
pulling manifest
pulling a0feadb736f5:  46% ▕████████████████████████████████████████████████████████████████▏ 15 GB/ 33 GB  8.5 MB/s  35m23s

这并不意味着所有网络环境都能得到同样结果，但至少说明了一点：瓶颈很可能不在 Ollama 客户端本身，而在实际的大文件下载链路。

树莓派 5 跑 Gemma 4 实测：可行，但响应较慢

Wed, 08 Apr 2026 18:42:00 +0800

一次偏极限的尝试：在 Raspberry Pi 5（8GB RAM） 上运行 Gemma 4。目标不是大模型版本，而是最小体量的 E2B。

结论先说：能跑、能用，但更适合低交互频率场景，不适合高实时要求的对话体验。

测试环境

设备：Raspberry Pi 5（4 核 CPU，8GB RAM）
系统：Ubuntu Server（无图形界面）
访问方式：SSH
模型运行方式：LM Studio CLI（仅命令行模式）
模型：Gemma 4 E2B（约 4.5GB）

第 1 步：安装并启动 LM Studio CLI

安装 LM Studio 的 CLI 版本，然后启动服务并查看可用命令。

由于是纯命令行环境，这种仅命令行部署方式非常适合树莓派。

第 2 步：把模型存储切到 SSD

为了避免频繁读写 SD 卡，我将模型下载目录改到了外接 SSD。

树莓派 5 接 SSD 的体验明显比早期机型更实用，长期运行本地模型建议优先使用 SSD。

第 3 步：下载并加载 Gemma 4 E2B

下载完成后，模型可以正常加载进内存。

按官方信息，Gemma 4 系列具备：

面向 Agent 场景的工具调用能力（function calling）
多模态能力（含图像/视频；小模型也具备语音相关能力）
128K 上下文窗口
Apache 2.0 许可（可商用）

从树莓派的硬件条件看，E2B 这一档更适合先试起来。

第 4 步：启动 API 并开放局域网访问

模型加载后，我先在本机端口启动 API（4000），并通过 HTTP 请求确认模型列表可返回。

问题在于：默认只监听本机，局域网其他设备无法直接访问。

因为启动参数里不能直接设置 host，我用了 socat 做端口转发，把树莓派外部端口请求桥接到 LM Studio 内部端口，实现局域网访问。

结果是可行的：我在同一局域网的 MacBook 上能成功请求并拿到模型列表。

第 5 步：接入编辑器（Zed）

LM Studio 的本地服务兼容 OpenAI API 形态，因此多数支持自定义 base_url 的工具都可以直接接入。

我在 Zed 里新增了一个 LLM provider，指向树莓派上的 Gemma 4 实例，随后在编辑器内聊天测试通过。

实际可用性判断

这套方案适合：

本地自动化脚本
低并发、低实时性要求的辅助任务
个人学习和边缘设备实验

不太适合：

高频交互聊天
对响应延迟敏感的开发协作场景

结论

在 Raspberry Pi 5 上运行 Gemma 4（E2B）是可行的，而且实际效果比预期更好。

如果你的目标是“能离线跑、能接工具、能完成轻中量任务”，这条路线值得尝试；如果目标是流畅实时交互，仍建议上更强硬件。

OpenClaw 对接本地 Gemma 4：完整配置指南

Wed, 08 Apr 2026 18:18:00 +0800

这篇文章演示如何把 OpenClaw 对接到本地 Gemma 4 模型（通过 Ollama 提供接口）。

如果你还没完成本地部署，可先参考：

如何在笔记本电脑上运行 Gemma 4：5 分钟本地部署指南

第 1 步：启动 Ollama API 服务

先启动 Ollama 服务：

`1`	`ollama serve`

你可以用下面的命令快速测试 API 是否正常：

curl http://localhost:11434/api/generate -d '{
  "model": "gemma4:12b",
  "prompt": "你好"
}'

如果能返回模型输出，说明本地 API 已可用。

第 2 步：配置 OpenClaw 接入 Ollama

OpenClaw 配置文件路径通常为：

`1`	`~/.openclaw/config.yaml`

编辑 config.yaml，在 models 中新增一个本地模型条目：

models:
  # 你已有的模型配置...

  gemma4-local:
    provider: ollama
    base_url: http://localhost:11434
    model: gemma4:12b
    timeout: 120s

第 3 步：设置默认模型（可选）

如果你希望默认走 Gemma 4，可添加：

`1`	`default_model: gemma4-local`

第 4 步：重启并验证 OpenClaw

重启 OpenClaw：

`1`	`openclaw restart`

查看模型列表：

`1`	`openclaw models list`

发起一次对话测试：

`1`	`openclaw chat --model gemma4-local "你好"`

如果对话返回正常，说明 OpenClaw 已成功接入本地 Gemma 4。

常见排查

connection refused：先确认 ollama serve 是否在运行。
模型找不到：检查模型名是否与 ollama list 一致（例如 gemma4:12b）。
响应超时：可适当提高 timeout，并优先测试较小模型。

如何在笔记本电脑上运行 Gemma 4：5 分钟本地部署指南

Wed, 08 Apr 2026 18:06:00 +0800

如果你想在笔记本上本地运行 Gemma 4，Ollama 是目前最省事的方式之一。即使不折腾复杂环境，通常 5 分钟左右也能跑起来。

第 1 步：安装 Ollama

打开 https://ollama.com，下载对应系统的安装包。
按系统完成安装：

macOS：拖到 Applications。
Windows：运行 .exe 安装程序。
Linux：使用官网提供的安装脚本。

安装完成后，Ollama 会以后台服务形式运行。除初次安装外，日常可以只用简单命令。

第 2 步：下载 Gemma 4 模型

打开终端，执行：

`1`	`ollama pull gemma4:4b`

如果你的机器性能更强，可以改成 12b 或 27b。下载完成后，模型会保存在本地。

查看已下载模型：

`1`	`ollama list`

第 3 步：启动模型

`1`	`ollama run gemma4:4b`

这会在终端打开交互式对话。输入问题后回车即可；结束会话可输入：

/bye

如果你更喜欢网页聊天界面，可以配合 Open WebUI 使用。它可以把 Ollama 包装成浏览器端 UI，通常通过 Docker 几分钟即可完成配置。

笔记本性能优化建议

Apple Silicon（M2/M3/M4）：默认走 Metal，加速效果通常很好，12B 也有不错体验。
NVIDIA 显卡：检测到兼容 GPU 时会自动使用 CUDA，建议提前更新驱动。
仅 CPU 推理：可以运行，但大模型会明显变慢；多数 CPU-only 场景建议优先 4B。
释放内存：加载大模型前尽量关闭占内存应用。经验上每 10 亿参数大约需要 0.5GB 到 1GB 内存。

模型怎么选

Gemma 4 1B：适合轻量问答、基础摘要、快速查询；复杂推理能力有限。
Gemma 4 4B：适合多数日常任务（写作辅助、代码辅助、资料总结），速度和质量平衡较好。
Gemma 4 12B：适合更长上下文和更复杂任务，在代码与推理场景更稳。
Gemma 4 27B：适合高要求任务，效果更接近云端大模型，但对硬件要求明显更高。

Android 上安装并运行 Gemma 4：完整上手指南

Wed, 08 Apr 2026 17:55:53 +0800

如果你想在手机上离线体验 Gemma 4，这篇文章会带你从安装到实用功能一步步跑通。

第 1 步：获取应用

Google AI Edge Gallery 目前不在 Google Play 上架，需要通过 APK 侧载安装。

在 Android 设备上依次进入：

设置 -> 应用 -> 特殊应用权限 -> 安装未知应用

然后：

找到你使用的浏览器（例如 Chrome 或 Firefox），开启“允许来自此来源”。
在手机浏览器打开 Google AI Edge Gallery 的 GitHub Releases 页面。

地址：https://github.com/google-ai-edge/gallery/releases

下载最新的 .apk 安装包。
下载完成后，在通知栏或文件管理器中点开安装包，按提示完成安装。

网络正常时，这一步通常约 2 分钟可完成。

第 2 步：首次打开并授权

首次打开 AI Edge Gallery 时，应用会请求存储权限，用于保存模型文件。建议直接允许，否则应用无法下载或加载模型。

首页一般会看到这些入口：

Ask Image：图像理解任务（描述图片、回答图片相关问题）
AI Chat：常规文本对话
Summarize：粘贴文本并生成摘要
Smart Reply：生成回复建议

大多数用户最常用的是 AI Chat。

第 3 步：下载 Gemma 4 模型

进入 AI Chat。
按提示点击 Get Models。
在模型列表中选择 Gemma 4 版本（会显示对应体积）。
按设备性能选择模型；如果手机是 8GB RAM，可先从 Gemma 4 4B 开始。
点击 Download，后台开始下载。

注意：模型越大，下载时间越长。你也可以下载多个模型，后续按需切换，已下载模型会保存在本机，不必重复下载。

第 4 步：开始对话

模型下载完成后：

点击模型名称进行加载（首次加载通常需要 10 到 30 秒，取决于模型大小和设备性能）。
在聊天框输入问题并发送。
模型会在本地生成回复，数据不会上传到云端。

一般第一条回复会稍慢，这是模型预热的正常现象；同一会话后续回复通常更快。

第 5 步：体验视觉能力（Gemma 4 多模态）

如果你下载的是 Gemma 4 多模态版本：

返回主菜单，进入 Ask Image。
选择一张图片，或直接拍照。
输入你想问的问题（例如“这张图里有什么？”或“图里有哪些文字需要注意？”）。
等待模型在本地分析并返回结果。

这项功能可以离线使用，图片内容也不会发送到外部服务器。

谷歌 Gemma 4 模型对比：2B/4B/26B/31B 怎么选？

Sun, 05 Apr 2026 08:30:00 +0800

Gemma 4 主打 多模态 与 本地离线运行，并提供从轻量端到高性能端的完整模型梯度。对大多数本地部署用户来说，关键不是“选最大”，而是“选最匹配硬件与任务的版本”。

Gemma 4 各模型对比

下表用于快速选型参考；具体性能与资源占用请以实际部署环境测试为准。

模型	参数规模	定位	主要优势	主要限制	推荐场景
Gemma 4 2B	20 亿	超轻量	延迟低、资源占用小、部署门槛最低	复杂推理与长链路任务能力有限	移动端、IoT、轻量问答、简单自动化
Gemma 4 4B	40 亿	轻量增强	比 2B 更稳的理解与生成能力，仍易本地部署	高强度编码/复杂 Agent 任务上限有限	本地助手、基础文档处理、多语言日常任务
Gemma 4 26B	260 亿	高性能（专家混合）	推理和工具调用能力明显提升，适合生产工作流	显存需求显著上升，硬件门槛更高	编程助手、复杂工作流、企业内部 Agent
Gemma 4 31B	310 亿	高性能（稠密）	综合能力最强，复杂任务稳定性更好	资源消耗最高，部署与调优成本最大	高要求推理、复杂代码任务、重度自动化

怎么选：按硬件和任务倒推

如果你主要看“能不能跑、跑得顺不顺”，可以按下面选：

8GB 显存：优先 2B/4B。
12GB 显存：优先 4B 或更高模型的量化版本。
24GB 显存：可重点考虑 26B，并按任务评估 31B 量化版。
更高显存或多卡：可尝试 31B 的高精度配置。

建议优先保证稳定性和推理速度，再逐步提升模型规模。

四类典型使用场景

1) 本地通用助手

优先模型：4B
原因：成本和效果平衡好，适合长期常驻运行。

2) 代码与自动化

优先模型：26B
原因：在多步骤任务、工具调用、脚本生成上更稳。

3) 高难度推理与复杂 Agent

优先模型：31B
原因：复杂上下文下的稳定性更高，容错更好。

4) 边缘设备与轻量离线

优先模型：2B
原因：最容易在资源受限设备落地。

部署建议（Ollama 方向）

最实用的做法是“小步快跑”：

先用 4B 建立可运行基线（速度、内存、效果）。
把你的真实任务做成固定测试集（例如 20 条常见问题 + 10 个自动化任务）。
再升级到 26B/31B 对比准确率、时延和显存成本。
只在“收益明显”时升级大模型。

这样可以避免一上来就追求大参数，结果出现卡顿、吞吐低、维护复杂的问题。

结论

Gemma 4 的真正价值，不是单纯“参数更大”，而是给了从轻量到高性能的一整套可落地梯度：

想低成本快速上线：从 2B/4B 开始。
想把本地 AI 真正接入生产流程：优先 26B。
想冲复杂推理与重度自动化：再上 31B。

Gemma 4 的最佳选择通常不是参数最大，而是与硬件条件和任务目标匹配度最高的版本。

本地大模型 on KnightLi的博客

llama.cpp b9196 更新：Windows 预编译版支持 CUDA 13.1、Vulkan、HIP 和 SYCL

llama.cpp 适合做什么

Windows 预编译版本怎么选

启动普通 GGUF 模型

启动多模态视觉模型

用 bat 脚本管理多个模型

模型选择要看三件事

常见问题

小结

Claude Code + Ollama 本地部署教程：用 CC Switch 打造免费 AI 编程助手

这套方案解决什么问题

基本准备

CC Switch 关键配置

Claude Code 强在哪里

Ollama 在这里扮演什么角色

体验边界在哪里

多模态兼容性还不稳定

适合谁尝试

使用建议

小结

本地运行 DeepSeek 4：Antirez ds4 在 Apple Silicon Mac 上的尝试

ds4 是什么

为什么值得关注

适合谁用

使用方式

目前的风险

和通用推理工具的区别

小结

参考

llama.cpp 多 GPU 性能实测思路：2x V100 16GB 会比单卡 32GB 快吗？

先分清 split mode

单卡 32GB 能放下时：双 16GB 不一定更快

单卡 16GB 放不下时：双卡价值很大

V100 PCIe 和 V100 SXM2 差别很大

怎么选更实际

什么时候买 2x16GB，什么时候买 1x32GB

layer split 和 tensor split 怎么用

prefill 和 decode 为什么表现不同

KV cache 会不会成为第二个显存瓶颈

用 llama-bench 做自己的双卡测试

一句话结论

RTX 5090 / 5080 AI 推理性能实测：本地大模型、4K 视频生成和实时 3D 怎么选

先看硬件差距

本地大模型：32GB 显存更关键

FP4 是潜力，不是所有应用的即插即用加速

图像生成和 4K 视频：带宽与显存一起决定体验

实时 3D 和 AI 建模：RTX 5090 更适合重场景

该怎么选

小结

参考资料

DeepSeek V4 本地私有化部署方案：国产芯片与消费级显卡集群怎么选

先明确部署目标

不要一上来就追求满血 Pro

国产芯片路线：适合企业级私有云

消费级显卡集群：适合试点和中小团队

可能的部署架构

硬件选型思路

验证阶段

试点阶段

生产阶段

推理框架怎么选

数据安全要做在模型外面

成本不要只算显卡

推荐落地路径

小结

参考资料

适合 RTX 3060 显卡运行的本地 LLM 模型推荐

先看显存边界

推荐一：Qwen3 8B

推荐二：Llama 3.1 8B Instruct

推荐三：Gemma 3 12B

推荐四：DeepSeek R1 Distill Qwen 8B

推荐五：Phi / MiniCPM / 小尺寸模型

量化怎么选

用什么工具运行

上下文不要开太大

不同用途怎么选

3060 本地 LLM 的合理预期

小结