Local LLM

本地 LLM 做 Agent，最容易被低估的不是模型能不能回答问题，而是它能不能稳定地把一串工具调用跑完。 这句话听起来有点扫兴。毕竟现在 7B、8B、14B 模型的 benchmark 分数越来越好，Ollama、llama.cpp、llama-server 也把本地部署门槛降到了很低。我之前写过一篇 本地 LLM 推理工具的取舍，当时重点放在推理后端、模型格式和生态锁定上。但如果你真的想把本地模型接进自动化工作流，另一个问题会更快冒出来：模型单步看起来不错，多步之后为什么还是崩？ HN 上这两天有个项目 Forge 很适合拿来讨论这个问题。它的标题很抓人：“Guardrails take an 8B model from 53% to 99% on agentic tasks”。我对这种数字一向谨慎，因为 agentic task 的定义、评测场景和采样参数都会强烈影响结果。但 Forge 真正值得看的地方，不是“8B 追平 frontier model”这个营销点，而是它把本地 Agent 失败拆成了几个非常工程化的小故障：工具调用解析失败、走错步骤、错误恢复失败、上下文预算失控，以及多个工作流争用同一个 GPU 推理槽。 说白了，它不是在训练一个更聪明的模型，而是在给一个不够稳定的模型加流程控制。 为什么本地 Agent 会在多步任务里快速掉队 很多人第一次做工具调用 Agent，会拿一个天气查询、数据库查询或者代码搜索 demo 开始。模型需要做的事情很简单：读用户问题，选择工具，填参数，拿结果，再回答。单步成功率只要看起来有 90%，体验就会很好。 问题出在复合任务上。 假设一个工作流有 5 步，每一步成功率都是 90%。如果这些步骤必须全部正确，整体成功率不是 90%，而是 0.9 的 5 次方，大约 59%。这还是独立错误的理想情况；真实 Agent 里，前一步的轻微偏差会污染后续上下文，错误会复利。 Forge 作者在 HN 发布帖 里也用了类似的“compounding math”解释：本地模型每一步都不算太差，但连续工具调用会把小错误放大成任务失败。这其实是我最认同它的地方。生产环境的 Agent 可靠性，很多时候不是靠“再换一个大模型”解决，而是靠把可控部分从自然语言里拿出来，交给确定性系统。 这也是为什么我会把 Forge 和之前写过的 Statewright 状态机护栏 放在同一类问题里看。Statewright 更偏“限制 Agent 在什么阶段能做什么”，Forge 更偏“当模型工具调用出错时，如何修、如何重试、如何阻止它跳步骤”。两者的共同点是：它们都不再迷信一个超长 system prompt。 ...

如果你已经在本地跑过大模型，应该很熟悉这个循环：先等通用推理框架支持新模型，再等量化格式稳定，再等各种 wrapper 把 API、工具调用、流式输出补齐。等一切能用时，下一代模型又来了。 所以我看到 Hacker News 上 DeepSeek 4 Flash local inference engine for Metal 这条讨论时，第一反应不是“又一个本地 LLM 项目”，而是：它把通用框架的路线反过来了。 ds4.c 不是一个新的 llama.cpp 替代品，也不是 Ollama 那种“模型管理 + 服务封装”。README 开头就把边界画得很死：它是一个只服务 DeepSeek V4 Flash 的原生推理引擎，主路径是 DeepSeek V4 Flash 专用的 Metal graph executor、DS4 专用加载器、prompt rendering、KV state 和 server API glue。换成人话说，它不是想做“什么模型都能跑”，而是想把一个特定模型在 Apple Silicon 上榨干。 坦白说，我挺喜欢这种不讨好所有人的设计。因为本地推理这件事，很多时候不是缺一个更漂亮的客户端，而是缺一条足够明确的工程假设。 “窄引擎”到底在赌什么 通用推理框架的优势很明显：模型覆盖广、社区大、格式生态成熟。比如 llama.cpp 已经是 GGUF 世界的事实底座，GitHub API 显示它仍在高频更新，star 超过 10 万。Hypho 之前写过 本地 LLM 推理引擎之争，核心判断也是：如果你要严肃做本地部署，底层引擎的透明度和社区活跃度比“安装是否一行命令”更重要。 但通用性有代价。 一个框架要支持几十种架构，就很难为某个模型的奇怪结构做激进假设。ds4.c 选择了另一边：它接受自己只能跑 DeepSeek V4 Flash，换来对这个模型的深度适配。项目 README 里列出的几个卖点很有代表性：DeepSeek V4 Flash 的 active parameters 更少；thinking 模式下推理段落更短；上下文窗口达到 1M tokens；KV cache 可以高度压缩并持久化到磁盘；2-bit 量化在特定 MoE 专家上效果可接受。 ...

如果你做过 Web 端 AI 功能，大概率踩过同一个坑：用户只是想总结一段文字、给评论纠错、从页面里问几个问题，你却要把内容发到云端 LLM，承担 token 成本、排队延迟、隐私合规和数据出境解释。 所以我看到 Hacker News 上 The Prompt API 这条讨论冲到两百多分时，第一反应不是“浏览器终于也有 AI 了”，而是：这东西如果真能稳定落地，会改变一类低风险 AI 功能的默认架构。 Chrome 的官方文档把 Prompt API 描述得很直接：网页或 Chrome Extension 可以把自然语言请求发给浏览器内置的 Gemini Nano。换成人话说，就是以前你在前端调用 fetch('/api/ask')，后端再转发给 OpenAI、Gemini 或自建 vLLM；现在有些场景可以直接在浏览器里问本地模型。 这听起来很香，但我不建议现在就把它当成“云端 LLM 替代品”。它更像一块新的系统拼图：适合放在用户设备边缘，处理轻量、局部、对隐私敏感、失败代价不高的任务。 它真正解决的不是“更聪明”，而是“更靠近数据” Prompt API 背后的标准化工作在 Web Machine Learning Community Group 的 prompt-api 仓库 里。这个 Explainer 说得很清楚：今天 Web 开发者要用语言模型，通常只有两条路：调用云端 API，或者自己把模型用 WASM/WebGPU 之类的方式塞进浏览器。前者简单但有隐私和成本问题，后者灵活但工程负担很重。 浏览器内置模型想走第三条路：模型由浏览器或操作系统提供，Web 应用只拿到一个标准 API。 说白了就是：模型不属于你，运行环境也不完全属于你，但调用入口变简单了。 这件事的工程价值不在于 Gemini Nano 一定比你后端的大模型强。恰恰相反，它大概率不会更强。它的价值在于位置：模型离用户输入、页面 DOM、临时草稿、聊天记录更近。很多数据本来就停留在浏览器里，如果只是做摘要、标签、轻量问答、辅助改写，非要绕一圈云端并不总是合理。 Chrome 的 built-in AI 入门文档 也强调了这个方向：内置 AI 让 Web 应用在不部署、不管理自有模型的情况下完成 AI 任务。这个表述很克制，它没有承诺“最强模型”，而是在强调部署和管理成本。 ...

引言：一个「只修皮毛」的工具为什么获得 16 万星 2023 年，Ollama 以「Docker for LLMs」的定位进入开发者视野——一行命令下载模型，本地跑起来。这种低门槛让它迅速积累了 16.9 万 GitHub Stars，成为本地运行大模型的事实标准。 然而，它的底层问题正在被更多开发者意识到：许可证归属争议长达一年未处理、自研后端性能反而低于 llama.cpp 30-50%、模型格式产生供应商锁定……这些问题在 Hacker News 上引发了大量讨论，HN 热帖当天获得 603 分。 本文不是「二选一」的观点稿，而是一次基于事实的深度拆解——为什么 Ollama 的工程实践存在系统性缺陷，以及真正值得投入生产的替代方案是什么。 背景：llama.cpp 才是本地 LLM 的真正引擎 要理解 Ollama 的问题，先要了解它依赖的底层技术。 llama.cpp 由 Georgi Gerganov 于 2023 年 3 月用一个晚间编写，最初只是一个将 LLaMA 模型跑在消费级硬件上的 C++ 推理引擎。它的核心创新是 GGUF 量化格式——让数十亿参数的大模型能够在普通电脑的 CPU 和 GPU 上高效运行。 今天，llama.cpp 拥有： 104,116 Stars，450+ 贡献者 MIT 许可证，完全开源 2026 年 2 月，ggml.ai 项目并入 Hugging Face，确保长期可持续发展 可以说，没有 llama.cpp，就没有本地 LLM 生态的今天。 问题是：Ollama 几乎从未承认这一点。 问题一：长达 400 天的许可证争议 Ollama 于 2023 年 6 月公开，基于 MIT 许可证开源。然而，其二进制发布包中包含 llama.cpp 代码，却从未附带 llama.cpp 要求的版权声明——这是 MIT 许可证的唯一主要义务。 ...

真实案例引入：为什么医疗数据不该上云 2025 年底，某三甲医院的 AI 团队在内部文档分析场景中遇到了一个典型困境：医生需要向 AI 助手上传患者病历、检查报告进行语义检索，但医院 IT 合规政策明确禁止将患者数据上传至第三方云服务。 他们最初的方案是自建 GPT-4 API 代理——但每个月 API 费用数万元，且数据仍然要先出医院网络。后来他们接触到 GAIA 框架，在一台配备 AMD Ryzen AI 9 的工作站上跑起了完全本地化的 RAG 问答 Agent，所有病历数据从未离开医院内网。 「我们关掉了网络访问权限，Agent 依然能跑完整流程。HIPAA 合规审计直接通过。」——项目负责人后来在 AMD 社区分享道。 这不是孤例。随着 ChatGPT API 成本上涨和企业数据外泄风险加剧，「纯本地 AI 推理」从概念验证进入了生产可用阶段。AMD GAIA 框架正是在这个节点上，将本地 Agent 开发从极客玩具变成了企业级选项。 GAIA 框架核心拆解 架构概览 GAIA 是 AMD 官方开源的 AI Agent 开发框架，GitHub 已有 1.1k Stars、77 Forks，最新版本 v0.17.2 于 2026 年 4 月 13 日发布，最近提交距今仅 6 小时。项目采用 Python + C++ 双引擎设计，核心定位是「让 AI Agent 跑在你的 PC 上，而不是别人的服务器上」。 ...