先说为什么本地跑

本地部署有三个核心理由。隐私：提示词与回答都不出本机，适合代码仓库、病历、内部文档等敏感材料。省钱：硬件是一次性投入，不再有随用量增长的按 token 计费。离线：断网也能工作，出差、飞行模式照常运行。

代价是需要一台性能足够的电脑，尤其是显卡与内存。

五款工具横评

逐个看

Ollama 是命令行优先的运行环境，一条命令完成安装、拉取、运行，提供 OpenAI 兼容的本地 API（端口 11434），跨 macOS、Linux、Windows，GitHub 星标超过 10 万，模型库丰富且精选。短板是并发与批处理较弱、没有图形界面、高级调参空间有限，适合开发者与快速验证。

LM Studio 是桌面应用，内置模型市场（对接 Hugging Face）、可视化参数调节、多标签页与本地服务器模式（OpenAI 兼容，端口 1234），并支持多模态模型。它是闭源桌面应用，个人免费（商用需确认许可），主要支持 macOS 与 Windows，适合不想碰命令行的用户。

vLLM 是生产级推理引擎，采用 PagedAttention 与连续批处理，吞吐较原生 Hugging Face 实现高 10 至 20 倍，支持多 GPU 张量并行与 OpenAI 兼容 API，偏 Linux。部署最复杂，适合服务大量并发用户。

GPT4All 针对 CPU 优化，无需独立显卡，默认模型仅 3 至 4GB，完全离线、无网络请求，开源免费。模型选择有限，不提供 API 服务，适合低配机与纯隐私场景。

Jan 是完全开源（AGPLv3）的 Electron 应用，提供 ChatGPT 式界面、本地 API 与插件扩展，跨平台。生态较新、推理性能不及 vLLM，适合重视可审计、可修改的开源偏好者。

硬件怎么配

模型大小决定显存需求。7B 参数模型做 4-bit 量化约需 4 至 6GB 显存或内存；13B 约 8GB；70B 约 40GB 以上。Apple M 系列芯片凭借统一内存架构，能跑比同价位独显更大的模型。

量化到 4-bit（如 Q4_K_M）可将显存需求减半，质量损失很小。中文场景推荐 Qwen、DeepSeek 系列；代码任务可选 CodeLlama、DeepSeek Coder。底层引擎 llama.cpp 支持把模型层卸载到 NVIDIA、AMD、Intel 显卡，也支持纯 CPU 推理。

选型建议

入门、想最快跑起来，选 Ollama；不喜欢命令行，选 LM Studio；没有独显、要纯离线，选 GPT4All；要服务多人并发，选 vLLM；要开源可审计，选 Jan。多数个人用户从 Ollama 起步最省心，熟悉后再视需要上 vLLM。

FAQ

没有显卡能跑吗？ 能。7B 以下小模型可纯 CPU 运行（GPT4All 专为此优化），但生成速度较慢；Apple M 系列统一内存也能跑较大模型。

Ollama 和 LM Studio 哪个好？ 没有绝对优劣。Ollama 生态兼容最广、占用小；LM Studio 对图形界面用户更友好。两者都能在几分钟内跑起来。

本地模型质量够用吗？ 对代码补全、文档摘要、分类等明确任务，开源权重模型差距很小；复杂推理仍落后于顶尖闭源模型。在敏感数据、固定高频、离线需求下，本地部署最具性价比。

来源：llama.cpp 项目文档、Ollama 与 vLLM 官方文档、SitePoint 2026 本地大模型指南等综合整理。

很多人以为跑本地大模型一定得配一张昂贵的独立显卡。这个说法有一半是对的——确实有不少任务离不开显卡。但模型世界里还藏着一大批体积小、却能把事情做漂亮的小模型。只要手边有一台近五年内生产的旧电脑或笔记本，内存不低于 8GB，就能跑起来，速度大约在每秒 10 个词元上下。这个速度听起来不起眼，可在不少实际场景里，原始速度根本不是关键。

第一行命令：用 Ollama 起一个本地服务

对于大多数想自己托管 AI 的人来说，Ollama 几乎成了默认选择。它内置模型库，提供一套兼容 OpenAI 的接口，能在本地直接拉起一个服务进程。基于开放权重模型搭建真正能执行任务的 AI、而非单纯对话，它再合适不过。

最大的好处是省心。硬件探测、量化版本选择这类琐碎活儿，Ollama 都替用户打理了。唯一要盯紧的是量化设置：选错格式的后果很严重，仅仅两比特的差别，就能让整机性能天差地别。选定模型后，执行 ollama pull 模型名 拉取，再 ollama run 模型名 就能对话。

要榨干性能：试试 llama.cpp

llama.cpp 是一套专门跑 GGUF 格式模型的推理引擎。它没有界面开销，把能用的 CPU 优化都用到了极致，适合那种「每一分性能都要抠」的场景，代价是上手更费劲。

它高度依赖命令行（不过也有网页界面可用），模型文件得自己管理，量化格式也得自己搞明白。起步方式是下载发布版或自行编译，再从 Hugging Face 取一份 GGUF 模型，用 llama-cli 或 llama-server 跑起来。有一项设置至关重要：把上下文长度封顶，别用默认值。KV 缓存吃掉内存的速度快得惊人，设太高整机立刻卡死。

给老旧硬件的礼物：Gemma 4 边缘模型

Gemma 4 家族里最小的两员——E2B 与 E4B——于 2026 年春天专为「边缘」硬件发布。名字里的「E」代表有效参数量，用更少的显存堆出更深的层次。举例来说，E4B 在 4 比特量化下大约只占 5GB 内存。

它们擅长摘要、起草、抽取结构化数据、翻译这类基础活儿，也能做一点推理，只是比不上更大的思考型模型。通过 Ollama 使用时，按内存选型号：有 8GB 就上 E4B，更少就退到 E2B。上下文也别拉太高，一样会挤占内存。

慢笔记本的绝配：给相册自动写说明

这篇文章里最受青睐的本地 AI 项目之一，是个给截图自动生成描述的小程序。这套配置跑在显卡上，但完全没有理由不能挪到 CPU 上，尤其是不要求实时的时候。批量给一整个文件夹的照片生成说明文字或替代文本，正是慢笔记本的理想任务——模型每秒吐三个词元，即便在无人值守时运行，慢一点也无妨。

可选方案有好几个：Moondream2（或 Moondream3，约 16 亿参数）专为边缘设计，4 比特量化下轻松塞进 3GB；SmolVLM 2B 是开放权重模型，擅长批处理；Gemma 4 E4B 每个版本都带视觉能力。要是想翻找过去十年的照片并让它们变得可搜索，这招极其实用。建议先用十几张差异很大的图试试水，再决定要不要丢进上万张的图库。

把文档搜索变聪明：私有语义检索

电脑自带搜索基本是「傻瓜式」的，只认敲进去的字面关键词。换上 AI，就能做语义搜索——用更自然的描述去找东西，不必字字对应。推荐先从 EmbeddingGemma 入手：它只有 3.08 亿参数，量化后内存占用不到 200MB，甚至能把输出向量从 768 维截到 128 维而几乎不损质量。把它接在 Ollama 服务后，配合 AnythingLLM 或 Open WebUI 就能用。只是要记住，在 CPU 上扫一遍庞大的文档库，动辄要等上几个小时。

怎么选：快用 llama.cpp，图省心用 Ollama

想要最快的搭建，选 llama.cpp；对其他人，作者强烈推荐 Ollama，那份省心简直是游戏规则的改变者。若一时没有特定模型目标，先从 Gemma 4 的边缘型号起步最稳妥——它们能做的事多到惊人，而且哪怕是一台「土豆机」也带得动。

来源：How-To Geek（作者 Nick Lewis，2026 年 8 月 11 日）

MakeUseOf 撰稿人 Yadullah Abidi 分享了一个反例。DeepReinforce 的 Ornith 1.0 家族中体积最小的 Ornith 9B，在他 16GB 内存的笔记本上给出了接近 35B 级别的回答，换个版本还能读图。要复现这个结果，第一步是把硬件账算清楚。

一、先分清内存和显存

1. 全精度 bf16 运行 Ornith 9B 大约需要 19GB 内存，官方建议用 80GB 显存的 GPU 做非量化部署，个人机器基本无缘。
2. 量化版本才是可行路径。Q4_K_M 量化后模型体积压到约 5.6GB，扣掉系统占用和一个合理的上下文窗口，16GB 内存放得下。
3. 这里的 16GB 指系统内存，不是苹果芯片 Mac 那种 GPU 可以直接调用的统一内存。Abidi 的机器是 16GB 内存搭配 RTX 4060，显存 8GB。
4. 在装了独立显卡的机器上，决定速度的是显存而非总内存。5.6GB 的量化模型若塞不进显存，Ollama 会把一部分交给 CPU 处理，速度立刻掉下来。这与显卡品牌无关，显存只有几 GB 就会撞上同一堵墙。Mac 的内存和 GPU 共用一个池子，在这件事上反而占便宜。

二、想要读图能力，别拉错版本

1. Ornith-1.0-9B 的官方模型卡把文本列为主要模态。直接拉默认的 GGUF 或标准权重，是没有图像能力的。
2. 视觉能力来自单独导出的版本，在 Ollama 上以社区标签 robit/ornith-vision:9b 分发，并非 DeepReinforce 官方发布，它在同一套推理骨干上叠加了视觉和工具调用。
3. 另有至少一个量化 MLX 版本在模型卡上同时标注了文本和图像两种模态。也就是说多模态是特定构建的附加项，并非所有 Ornith 9B 文件都具备。
4. 结论很直接：按命名空间拉带 vision 标签的那一个，别随手拉搜索结果里第一个 Ornith 9B 量化包。Ollama 和 LM Studio 目前对多模态模型的支持都已经比较顺畅。

三、它强在哪，弱在哪

这个家族的特别之处在训练方式。Ornith 1.0 以 Qwen 3.5 为底座做后训练，采用自我改进的强化学习配方，让模型自行搭建并打磨解题脚手架，而不是依赖人工写死的智能体流程。体积小却能打，靠的是这一点，不是参数量。家族里还有 31B 稠密版、35B 混合专家版和一个 397B 混合专家版。

成绩方面，Ornith 9B 在 SWE-bench Verified 拿到 69.4%，Terminal-Bench 2.1 得 43.1，对手是 Gemma 4-31B、Qwen 3.6-35B 这类三到四倍体积的模型。不过同门的 35B 混合专家版在相同基准上仍明显更强。

短板也很明确：面对很长的多步智能体任务，9B 版本容易打转或卡住，大一号的兄弟处理得从容得多；如果模型有一部分跑在 CPU 上，这种情况来得更早。它的优势集中在编程和终端类任务，通用推理不要按 35B 的水准去期待。

来源：MakeUseOf

XDA 撰稿人分享了自己的排查过程：元凶往往不是模型，而是设置面板里两个几乎没人动过的滑块——重复惩罚（repeat penalty）与出现惩罚（presence penalty）。二者功能相近却各司其职，网上大量教程把它们混为一谈，反而误导了调参方向。

一、默认值为什么不适合日常使用

本地模型的默认参数多为跑分评测调校，并非为日常对话设计。日常很少人每次都精心挑选示例、配上完整思维链指令。

LM Studio、Ollama、llama.cpp 基于同一核心引擎，但默认参数各自不同。

量化会把问题继续放大。多数人为了塞进显存跑 Q4 或 Q5 而非 FP16，精度一降最先冒头的就是重复和循环，小模型尤其明显。另外 Qwen 倾向过度解释，Gemma 长对话易啰嗦。

二、两个滑块分别管什么

重复惩罚是词元级别的控制，来自 2019 年的 CTRL 论文，作用是惩罚已出现过的具体词元。中性值 1.0，高于 1.0 开始抑制复用。甜区很窄，调到 1.05 或 1.1 通常就能清掉词语层面的循环；一旦推到 1.2，模型可能连「的」这类常用词都开始躲，输出反而古怪。命名上需留意：llama.cpp 称 repeat_penalty，OpenAI 接口最接近 frequency_penalty，Hugging Face 则名 repetition_penalty。

出现惩罚同样作用在词元层，算法却不同。重复惩罚随复用次数加重，出现惩罚是「出现过就扣一次固定分」，出现十次和一次扣得一样多，中性值 0，常见区间 -2.0 到 2.0。它把模型推离刚用过的那批词，换了词往往就换了话题——「同一个观点绕四遍」正源于此，并非模型真在做语义理解，只是好用的词元被耗尽后的副产品。

三、三组实测对照

这位撰稿人用同一条提示词跑了三轮，模型、温度、min-p、系统提示词全部固定，只改这两个参数：「用三种方式解释什么是 REST API：面向新手、懂 HTTP 的人、正在动手实现的人」。

1. 两项都保持中性：回答表面正常，但 Qwen 犯了老毛病，每个小节都要先把「REST API 是一套规则」重述一遍才进入正题。
2. 两项都拉满（重复 1.3、出现 1.8）：开头尚可，接近结尾时不再生成完整句子，退化成一串地理名词堆砌，只能手动中止。这就是过度矫正——惩罚把合理的高概率词元也饿死了。
3. 取中间值（重复 1.1、出现 0.6）：输出干净的三段式解释，三类读者各自拿到了不同角度。

注意事项

这两个滑块奖励微调、惩罚猛拉。上述数值是在 LM Studio 里跑 Qwen 9B 得出的，只能当起点。温度也会参与其中：处于 0 或 0.1 时模型本就趋于确定，惩罚几乎没有发挥空间，0.6 到 0.8 之间才留有余地。

按任务微调同样重要：写代码时重复惩罚应贴近中性，因为代码本就要重复语法；推理类模型需要更低的出现惩罚；Q3、Q4 这类低精度量化整体宜用更轻的惩罚。模型的 Hugging Face 页面若给了推荐配置，从那里开始最省事。

来源：XDA Developers

在 AI 相关的功能里，语音转写大概是被吹得最少、却最实用的一项。WIRED 撰稿人 Justin Pot 在最新一篇上手文章中写道，这项技术不只适合记者整理采访，用来处理会议同样合适。

问题在于价格和隐私。市面上被称作“会议助手”的服务承诺自动转写并总结会议内容，卖点很直白，但代价有两个：一是价格普遍落在每月 10 至 20 美元区间；二是使用它们通常意味着把会议录音上传到某个云端服务器，对涉密项目来说并不理想。

Pot 给出的答案是 Meetily——一款把开源模型打包成完整应用的会议助手。

装上就能用，不挑会议软件

Meetily 由 Zackriya Solutions 开发，社区版以 MIT 许可开源，可从 GitHub 免费下载，Windows 和 macOS 均有现成安装包，Linux 用户需要自行从源码构建。另有一个每月 10 美元的 Pro 版本，但开源社区版是完全免费的。

安装完成后，应用会主动提示下载所需的模型——真正干活的就是这些本地 AI 模型。转写环节使用本地运行的 Whisper 或 Parakeet 模型，摘要环节则可以接本地的 Ollama 模型，也可以自带密钥接入 Claude、Groq、OpenRouter 或其他兼容 OpenAI 接口的服务。

接下来需要授权 Meetily 同时录制麦克风声音和系统声音，这样才能把对话各方都收进来。这个设计带来一个关键好处：它直接抓取系统音频，因此不受具体会议软件限制——Zoom、Google Meet、Microsoft Teams 或者任何其他工具都能用。理论上线下会议也能凑合，前提是笔记本麦克风足以拾取整个房间的声音。

由于是直接录系统声音而非以参会者身份加入，Meetily 不需要往会议里派一个“记录机器人”，参会列表中不会多出一个陌生成员。

从转写到摘要

进入视频通话后点击录制按钮即可开始。会议进行中，用户可以近乎实时地看着转写文本生成，也可以把窗口最小化专心开会。

会议结束点停止，转写稿随即呈现。在此基础上可以要求 AI 生成摘要，并且能指定希望它重点关注哪些内容。

一项测试版功能支持处理此前录好的素材：把音频甚至视频文件拖进去，同样可以得到转写和摘要。用手机录下的线下谈话，回到电脑前再补一份文字稿，正是这个功能的典型用途。

Pot 也提醒了一句：和所有 AI 工具一样，这类系统并不完美，它关注的重点未必和使用者一致。他本人的做法是拿转写稿当参考、自己动手写会议纪要，而机器生成的摘要在某些场合仍有价值。

免费版的硬伤与几个替代品

免费版最明显的短板是转写稿不区分说话人，没有说话人标签——对不少人来说这直接构成硬伤。Pot 表示，他没能找到一款能稳定做到这一点的免费开源工具。

如果 Meetily 不合用，还有几个方向可以考虑：

• noScribe：完全免费，能识别说话人，但不支持实时录制会议，只能转换已有文件。
• Anarlog（前身为 Hyprnote）：界面观感更精致，可接入的 AI 模型也更多，但配置过程比 Meetily 繁琐一些。
• Quill：提供免费的本地转写，不过需要注册账号才能使用——这在一定程度上违背了离线工具的初衷，且推销信息偏多。

Pot 的结论是，免费选项这么多本身就是好事，而且参照语音输入软件的发展节奏，再过几个月大概率还会冒出更多。

来源：WIRED

开放权重模型一多，围观者就习惯把它们摆成一场赛马：谁排名靠前谁就该用，落后的那个自动被归为“慢”或者“不能用”。How-To Geek 编辑 Jorge A. Aguilar 在 8 月 9 日发表的一篇文章里指出，这套逻辑一旦落到真实使用场景中就会立刻散架——因为有些模型压根不是为同一份工作而生的。

谷歌 DeepMind 的 Gemma 4 和阿里巴巴的通义千问 3.6，恰好是最典型的一对例子。

一个装进设备，一个住在云上

Gemma 4 的设计目标是在尽可能多的终端上高效运行：手机、笔记本、台式机。它的 12B 变体可以直接吃进原始音频和图像数据，不需要额外挂载独立的编码器模型。

千问 3.6 则是奔着云端基础设施和长链条分析任务去的。它采用混合注意力结构，能在不撑爆内存的前提下吞下巨量文本。用一句话概括这组差异：前者想当一个快速、私密、跑在本机上的助手；后者想当一个坐在云端、有耐心跟难题死磕的工程师。

两个模型的档位划分也印证了各自的取向。Gemma 4 于 4 月 2 日发布，提供从端侧优化的 E2B、E4B，到 12B、26B 混合专家、31B 稠密模型在内的多个尺寸。千问 3.6 的开放权重版本走的是另一条路线：35B-A3B 混合专家模型每个词元只激活约 30 亿参数，另有一款 27B 稠密模型，原生上下文达到 262144 个词元。两个家族目前都采用 Apache 2.0 许可，这一项上并不构成差异。

上下文窗口决定了能干什么活

真正把两者拉开距离的，是上下文容量和推理方式。

云端的千问 3.6 Plus 拥有 100 万词元的上下文窗口，并且搭配一个常驻运行的推理模式——模型会先把问题想一遍再作答。在部分会话中它还会启用思考保留模式，记住此前几轮的推演过程，从上一次的结论继续往下走，而不是每次都从零开始、重复踩同一个坑。

这个能力在特定场景里价值极高。调试一个庞大的代码库时，100 万词元的窗口可以一次性装下整个仓库、接口文档和错误日志，让模型在几百个文件之间追踪同一个缺陷而不丢线索。

Gemma 4 的上下文上限则视变体而定，落在 128K 到 256K 之间，装不下那么多东西。在较长的会话里，它还容易丢失被指定的角色设定，陷入需要整段重启才能跳出的重复循环。

成本与隐私的账要分开算

许可与账单的差异同样值得留意。千问 3.6 的部分本地变体以免费开放许可发布，企业可以自行部署而无需申请授权；但更高端的云端版本跑在付费租用的算力上，用得越狠账单越长。

Gemma 4 走的是相反的路径：拿到一份副本部署在自己的硬件上，一次配置完成后没有持续开销，输入的任何内容都不必离开本机——对隐私敏感的场景，这一点的分量远大于跑分。想先试一试的用户可以在 AI Studio 上体验 Gemma 4，本地部署则通常经由 Ollama 完成。Gemma 早期版本曾附带较多使用限制，如今这一层顾虑已经解除，小团队和独立开发者不必再为许可条款专门请教律师。

别再评“史上最强”了

Aguilar 在文章结尾给出了一个明确判断：把 Gemma 4 和千问 3.6 当成争夺同一顶王冠的对手，本身就理解错了题目。依据排行榜名次或品牌认知度二选一，大概率会选错——因为它们要解决的根本是两类问题。同样的道理也适用于 ChatGPT、DeepSeek 背后的模型。

会不会有一天出现一个足够大的模型，把端侧任务和深度仓库分析统统吃下？他认为这个设想并不离谱，但短期内看不到。一个能在 100 万词元的代码里做推理的模型，放到本地跑必然带来明显延迟；能撑起这种上下文窗口的云端模型，背后需要真金白银的服务器集群，还要面对网络延迟、隐私顾虑和运维成本——对普通用户来说很难承受。

所以结论不是“哪个更好”，而是“哪个不适合当前这项任务”。把它们当成两把用途不同的工具对待，两者都会变得更好用。

来源：How-To Geek

How-To Geek 作者 Nick Lewis 用自己的经历给出了对照：8GB 显存大致只能跑 70 亿参数（7B）模型，12GB 能跑 140 亿（14B），到了 16GB 才够跑 240 亿（24B）量级；而一个 270 亿（27B）的 Q4_K_M 量化模型，单是权重就要吃掉约 16GB 显存。

这还没算注意力缓存（KV cache）。它是模型记住上下文的临时内存，会额外占用显存的 25%（在 8K 上下文下）到翻倍（32K 上下文）。很多工具的默认上下文很短，比如 Ollama 默认只有 4096，所以小测试里显得很省，一旦把上下文拉长，显存立刻见底。

更关键的是，真实场景往往是好几个模型一起跑：主对话模型、负责向量检索的嵌入模型、再做一遍重排序的模型……一条典型的自动化流水线里同时跑 4 到 5 个模型并不稀奇。

混合专家模型（MoE）是个出路。这类模型只在每次推理时激活其中一部分参数，一个 200 亿级量化模型配 6 万上下文，在 RTX 5070 Ti 这样的显卡上能跑出每秒 100 个词以上的速度。优化手段还包括：把注意力缓存量化到 8 位或 4 位（一行配置即可）、主动限制上下文长度、用 MoE 替代稠密模型、把放不下的层卸载到 32GB 或 64GB 的系统内存。

说白了，16GB 不是「过剩」，而是「刚好及格」。想同时舒服地跑多个模型、留足上下文，24GB 才是真正的甜点档。打算本地玩 AI 的人，买卡时显存容量比核心频率更该排在前头。

来源：How-To Geek（作者 Nick Lewis，2026-08-09）

流媒体服务器 Plex 和 Jellyfin 是第一个雷区。如果播放设备支持的音视频格式和片源一致，树莓派只需负责传文件，一切顺畅；可一旦需要转码——比如手机不支持某种编码、要烧录字幕或降码率——重活就全压在 CPU 上。树莓派的硬件转码能力有限，播放会卡顿、缓冲甚至失败。此时换成带英特尔 Quick Sync 硬件加速的廉价迷你主机就能解决。

照片备份服务 Immich 在少量文件测试时表现良好，但当你尝试把手机里几千张照片视频一次性导入，后台就要生成缩略图、转码视频、做人脸识别和建立搜索索引，这些 CPU 密集任务可能要跑上数小时甚至数天。Immich 官方建议在小板子上关掉部分机器学习功能或降低并发，但想长期用，迟早还是得升级硬件。

文件同步工具 Nextcloud 在小文件、少量文档时没问题，可一旦要从多台设备同步几百 GB 数据，同步变慢、预览生成滞后、多用户争抢，体验会迅速变得令人沮丧。

智能家居平台 Home Assistant 是作者最有发言权的部分。他用树莓派 3B+ 跑了两年基础智能家毫无问题，但当他加上摄像头系统 Scrypted、Frigate 以及语音助手管线后，设备数量一多，树莓派就拖了后腿，最后换成了迷你主机。

本地大模型服务 Ollama 同样如此：小模型在树莓派上能跑、能干活，但只要你对响应速度有要求，同样的模型在现代迷你主机上明显更快，大模型则要么超出内存，要么慢到没法用。

Davidson 的结论很实在：树莓派是绝佳的入门选择，但「玩腻了」只是时间问题。当服务从「能跑」走向「好用」，一块带硬件加速的迷你主机往往是更省心的下一步。

来源：How-To Geek

工具链是现成的。 Ollama 负责在本地跑模型，Open WebUI 当聊天界面；智能家居那头直接用 Home Assistant 自带的 MCP 服务器接进来；Docker、存储、备份这些动作交给自托管的 n8n，每个工作流只干一件事——列出不健康的容器、取最近日志、确认备份是否完成。

模型选的是 Qwen 3.5 4B。 它支持工具调用，体积小到能和 Ollama、Open WebUI 一起挤在一台 8GB 内存的笔记本上。日常问句就是大白话：”哪些服务不正常””NAS 还剩多少空间””昨晚的自动备份跑完没有”。它也能连着做：Jellyfin 打不开，先查容器状态，再拉日志，发现停了就调用重启工作流，然后回头复查一遍。

断网是刻意设计的。 Open WebUI 本身支持云端模型、外部搜索和在线嵌入服务，Singh 把这些连接全删了，只留本地 Ollama 端点，又关掉 Ollama 的云功能、禁掉相关服务的外网访问。这样提示词、容器日志、文件名、设备状态、备份记录都不会被送出去。

唯一的坑在工具描述上。 工作流名字起得太像，模型就容易叫错工具，所以要一个流程一件事、名字直说动作。

说白了，指望自家硬件上的小模型对标云端旗舰并不现实，但它在这套系统里的活儿只是”挑对工具、填对参数、把结果讲人话”——4B 完全够用。你家里的服务多到需要一个统一入口了吗？

来源：XDA Developers

组合其实很简单：Ollama 负责在本地跑模型，Vane 负责搜索和界面。Vane 就是原先的 Perplexica 改名而来，内部用 SearXNG 从多个搜索引擎抓结果，再把相关页面交给模型阅读，生成一段带引用的答案，每条结论都能点回原始网页核对。它还分三种模式：Speed 给快答，Balanced 多花点时间收集，Quality 会反复检索、读页、修正，慢一些，但适合一次搜不清楚的问题。

部署比想象中省事。先装好 Ollama、下载模型，Vane 本身跑在 Docker 里，官方推荐的镜像已经把 SearXNG 打包在内，不用单独配搜索引擎。容器起来后浏览器打开 localhost:3000，在初始界面连上 Ollama、选好模型即可。真正耗时的是下模型，配置本身只要几分钟；没有账号也没有订阅，搜索记录都留在本地的 Docker 卷里。

我的判断是，选模型别一味求大。检索回来的网页要占上下文，内存必须留够，一个勉强塞得下的大模型，一旦开始读好几个网页就会慢到让人想放弃，反而不如中等模型跑得顺。这意味着这套方案的门槛，比很多人想的要低。

月费省下来，数据也留在自己机器上，这笔交换你换不换？

来源：XDA Developers