很多人以为跑本地大模型一定得配一张昂贵的独立显卡。这个说法有一半是对的——确实有不少任务离不开显卡。但模型世界里还藏着一大批体积小、却能把事情做漂亮的小模型。只要手边有一台近五年内生产的旧电脑或笔记本，内存不低于 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 日）

该项目由 Antigma Labs 开发，以 Apache 2.0 协议开源，近日出现在 Hacker News 首页并获得 90 分推荐。开发方给它的定位相当直白：功能对标 Claude Code 与 Codex，但不带这两者的依赖负担和模型限制。

跑分公开可查，资源占用只有零头

多数智能体项目都会自称性能优秀，Ante 的做法是把评测过程直接摊开。项目在官方排行榜约束条件下持续运行 Terminal-Bench 2.1 基准测试——89 项任务，每项跑 5 次。最新一轮完整测试的成绩为 82.7%，共 368 次通过、总计 445 次试验，使用的模型是开源权重的 DeepSeek V4 Flash 0731，对应版本为 Ante 0.preview.71，整轮推理开销约 68 美元。作为交叉印证，DeepSeek 官方用其尚未公开的 Harness 在最简模式下测试同一模型，给出的分数同样是 82.7。

每条评测结果都会锁定可下载的具体构建版本，并附上原始运行记录的链接，供外部独立复核，而不是只丢出一个数字。

资源开销的差距更为直观。在 Docker 环境中执行同样的 20 项并行任务，Ante 的峰值内存占用约为 Claude Code 的七分之一，平均 CPU 占用约为九分之一，磁盘读写量约为五分之一。

这套数字背后是一个具体的工程取舍：整个程序用 Rust 手写，把 Grep（经过完全重写和定制）与 git 这类高频组件直接嵌进同一个二进制、同一个进程内运行，不再向外调起子进程，也就不存在资源泄漏的问题。本地推理则交给一个版本固定、由项目自行管理的 llama.cpp。

断网跑完整流程，不需要 API 密钥

原生离线是 Ante 最有辨识度的一点。内置推理引擎让整个工作循环可以完全留在本地：指向一个 GGUF 格式的模型文件，不需要 API 密钥，不需要注册账号，也不需要网络连接。

ante --offline-model ~/.ante/models/Qwen3.5-9B-Q4_K_M.gguf \
  -p "add error handling to src/main.rs"

联网使用时，Ante 开箱支持 12 家以上的模型供应商，包括 Anthropic 的 Claude Sonnet 4.5 与 Opus 4.6、OpenAI 的 GPT-5 系列、谷歌 Gemini 3 系列、xAI 的 Grok 4、OpenRouter，以及 Vertex AI 等兼容 OpenAI 接口的服务。切换供应商没有绑定成本，自带密钥、订阅账号或本地模型均可，官方明确表示不要求注册任何账号。

运行方式分为四种：ante 进入交互式终端界面处理日常工作；ante -p 以无头模式执行一次性任务，适合脚本与持续集成流程；ante serve 通过 JSONL 协议对外提供服务，供编辑器插件调用；ante gateway 则可以把它挂成 Slack 或 Discord 机器人。多智能体编排、自定义技能、MCP 支持与跨会话记忆也都在功能清单内。

开源了哪些部分，又有哪些没开

需要说清楚的是，Ante 目前处于 Alpha 预览阶段，官方提示会有破坏性变更和功能缺失，且仅支持 macOS 与 Linux，Windows 用户建议通过 WSL 使用。

仓库开源的内容包括：完整文档站、ante serve 使用的协议定义与 Rust SDK、支撑 Terminal-Bench 成绩的评测适配器（任何一轮结果都可据此复现），以及已经稳定的核心库如独立进程执行模块。核心的 harness 本身在 Alpha 期间仍在私有仓库开发，以预编译二进制形式随版本发布，稳定一块开放一块。

项目名字本身是个双关：既是「Another Terminal agent」的缩写，也指牌桌上入局要先押的底注。开发方给出的长期设想是所谓「细胞原生」智能体——像生物体内的细胞那样微小、可随时丢弃、能大规模复制。按这个思路，可验证、够便宜、随处能跑三件事其实是同一个设计决策：只有轻到能成千上万地铺开，智能体才谈得上自组织。

对于关注本地化部署、注重数据不出机器，或者单纯受够了动辄数百 MB 客户端的开发者，这个只有 15MB 的选项值得关注一下。

来源：Hacker News / GitHub（AntigmaLabs/ante）

最容易想到的解法是给 Obsidian 装一个 AI 插件。这在电脑上确实好用，社区插件配合 Ollama 或 LM Studio 跑本地模型，再通过 MCP 或文件系统连接器读取笔记库，效果相当扎实。但换到手机上，这条路走不通：社区里那些声称支持本地模型的插件，没有一个真的把模型跑在手机里，它们实际是通过局域网或 Tailscale 回连电脑——本质仍是远程调用，一旦电脑关机或没有网络就彻底失效。

卡点：手机端本地模型应用普遍不能读文档

这位撰稿人此前一直用 PocketPal 作为手机上的本地模型工具，它能在设备上直接运行模型、离线聊天，界面也不错，但和多数手机端模型运行器一样，不支持上传文档。原因在于硬件限制——手机上很少有工具内置 RAG（检索增强生成）能力，而没有 RAG，模型就无法真正”读”用户自己的笔记库。

他最终找到的解法是 Noema：一款能在手机本地完成文档索引的模型运行器，免费，原生支持 GGUF、MLX 以及 Liquid AI 的 SLM 格式。该应用目前仅有 iOS 版本，安卓用户可以关注功能类似的 LocalRAG。

把笔记库接进本地模型的步骤

1. 在手机上安装 Noema 并完成基本设置。
2. 首次尝试添加文件时，应用会自动下载一个嵌入模型，用于把文本转换成可检索的向量。这是一次性步骤，之后新增的文档都会在设备本地完成索引，全过程不产生任何云端请求。
3. 点击加号图标，在系统”文件”应用中定位到 Obsidian 笔记库所在目录。
4. 选中需要纳入的 .md、.txt 文件添加为文档。除 Markdown 外，PDF、EPUB、TXT、CSV、JSON、JSONL 格式同样支持，因此丢进笔记库里的 PDF 也能一并检索。
5. 直接向模型提问。它会跨多条笔记给出综合回答，并附上带编号的引用，指向答案实际取自哪一段内容。

这一点正是它与普通”和文件聊天”功能的区别：给出的是检索结果而非泛泛摘要，来源可核对。

使用时的注意事项

• 留意上下文窗口。 文档会迅速吃掉上下文长度，一次性挂载过多笔记会影响回答质量，建议按主题分批添加。
• 预留存储空间。 模型文件加上嵌入索引需要占用数 GB 空间，空间紧张的手机需要先清理。
• 不必拘泥于具体应用。 无论使用哪种手机系统，挑选工具时的核心标准是两条：能从系统文件管理器读取文档，且内置 RAG 能力。满足这两点，就能搭出一套离线可用的笔记问答流程。

真正的价值在断网时体现

既然手机上已有各类云端 AI 应用，为何还要折腾本地方案？这位撰稿人给出的理由很实际：网络并非随时可用——Wi-Fi 会断、可能停电、基站可能故障，出行途中也常常没有信号。本地方案在飞行模式下照常给出带引用的完整回答，云端应用则会在失去信号的瞬间罢工。

此外，本地运行器在功能上也并不寒酸：可以收藏回答、把回答固定到应用内置的速记面板、对某条回答做分支，或保留格式直接复制回 Obsidian；温度、上下文长度等参数也都开放调节。Obsidian 本身免费，仅官方同步服务 Obsidian Sync 需每月 4 美元，整套流程的额外成本几乎为零。

来源：XDA Developers