2.6B小模型，瞄准本地Agent

Liquid AI 把更大的端侧模型推向本地 Agent

Liquid AI 在 2026 年 8 月 4 日发布 LFM2.5-2.6B，目标是让工具调用型 Agent 直接运行在个人电脑、手机、车载设备和其他边缘硬件上。 这不是一次单纯的参数扩容：相比此前主打轻量部署的 LFM2.5-1.2B，新模型把参数量提高到 26 亿，试图在设备可承受的内存占用与 Agent 所需的指令遵循、任务规划、结构化输出之间找到更实用的平衡点。

LFM2.5-2.6B 是一款面向设备端部署的 26 亿参数基础模型。 Liquid AI 在官方 Hugging Face 文章中把它描述为可广泛部署的本地 Agent 模型，重点不是陪用户闲聊，而是理解任务、选择工具、生成参数、读取工具返回结果，再继续完成后续步骤。

本地 Agent 是指模型推理和主要任务循环在用户设备上完成的智能代理。 它与普通本地聊天模型的区别在于，后者通常只负责输入文本、输出文本；前者还要在模型、文件、应用程序、数据库和系统工具之间反复交互，执行一个可持续多轮运转的工作流。

2.6B 是一个经过现实约束的尺寸

26 亿参数不是一个追求榜单头名的规模，而是端侧硬件能够认真考虑的规模。 以仅计算模型权重、不包含 KV Cache、运行时缓冲区和系统占用的理论值估算，LFM2.5-2.6B 使用 FP16 精度时需要约 5.2 GB 内存，INT8 量化后约 2.6 GB，4-bit 量化后约 1.3 GB。

| 权重精度 | 仅权重理论占用 | 更适合的设备 | 主要取舍 | |---|---:|---|---| | FP16 | 约 5.2 GB | 独立显卡、统一内存较大的 AI PC | 精度保留更完整，但内存压力最高 | | INT8 | 约 2.6 GB | 主流笔记本、部分高端移动设备 | 质量与资源消耗相对均衡 | | 4-bit | 约 1.3 GB | 手机、树莓派级设备、嵌入式硬件 | 更容易常驻内存，但量化方式会影响输出稳定性 |

实际运行内存一定高于表中的权重数字。 Agent 需要保存对话历史、工具描述和工具返回内容，长上下文还会增加 KV Cache；不同推理框架的算子实现、量化格式和硬件后端，也会带来数百 MB 到数 GB 的额外开销。因此，“4-bit 权重约 1.3 GB”不等于一台只有 2 GB 空闲内存的设备就能稳定运行完整 Agent。

LFM2.5-2.6B 相比 1.2B 版本增加了约 117% 的参数。 这部分容量如果能有效转化为更稳的指令遵循和工具参数生成能力，就比单纯增加常识问答分数更有意义，因为本地 Agent 最常见的失败并不是“不知道答案”，而是选错工具、漏掉参数、输出格式损坏，或者在工具已经报错后继续重复调用。

| 项目 | LFM2.5-1.2B | LFM2.5-2.6B | 变化与意义 | |---|---:|---:|---| | 参数量 | 12 亿 | 26 亿 | 增加约 117% | | FP16 理论权重占用 | 约 2.4 GB | 约 5.2 GB | 2.6B 对移动设备的压力明显更高 | | 4-bit 理论权重占用 | 约 0.6 GB | 约 1.3 GB | 两者仍有机会进入消费级端侧部署范围 | | 核心定位 | 极轻量设备端任务 | 更完整的本地 Agent | 从“能运行”转向“能执行多步骤任务” | | 适合场景 | 分类、改写、简单问答 | 工具调用、工作流编排、私有数据处理 | 2.6B 更强调任务可靠性 |

小模型开始从聊天转向执行

这次发布最值得关注的变化，是小模型的产品目标正在从生成内容转向执行动作。 过去端侧模型常被当作云端大模型的低配替代品，典型用途是摘要、翻译、文本改写和离线问答；LFM2.5-2.6B 则明确把本地工具调用和 Agent 工作流放在中心位置。

工具调用是模型按照预定义结构选择外部功能并生成参数的能力。 例如，用户要求“找出下载目录里上周收到的三份报价单，比较总价并写一封回复邮件”，模型本身不应凭空编造文件内容，而应先调用文件搜索工具，再调用文档解析工具，完成比较后把邮件草稿交给用户确认。

模型不会因为支持工具调用就自动拥有系统权限。 真正执行读文件、发邮件或修改日历的是宿主应用，模型只负责提出调用意图和参数；权限边界、沙箱、操作确认、日志记录与失败重试，都必须由 Agent 框架和产品层实现。

一个可靠的本地 Agent 通常包含以下循环：

1. 接收用户任务，并判断是否需要调用工具；
2. 从允许使用的工具集合中选择一个工具；
3. 生成符合约束的参数；
4. 由宿主程序执行工具，而不是让模型直接操作系统；
5. 把执行结果返回模型；
6. 由模型判断任务是否完成，或继续下一次调用；
7. 在敏感操作前要求用户确认，并保留可审计记录。

26 亿参数能否胜任这个循环，关键取决于可靠性而不是语言风格。 一次普通问答答偏了，用户可以重新提问；一次 Agent 调用把日期写错、文件选错或参数字段漏掉，就可能直接破坏工作流。对这类模型而言，结构化输出成功率、连续多步调用成功率、错误恢复能力和拒绝越权操作的能力，往往比开放式聊天榜单更有参考价值。

Liquid AI 的路线不是把 Transformer 原样缩小

LFM2.5 延续了 Liquid AI 面向设备效率设计的混合架构路线。 这类设计不会让每一层都承担同样昂贵的全局注意力计算，而是组合局部信息处理模块与注意力模块，在需要全局关系建模的位置使用更重的计算，把更多高频、短距离的信息处理交给成本较低的结构。

混合架构的目标是在相同硬件上降低延迟和内存压力。 对本地 Agent 而言，这种优化比云端批量推理更重要，因为个人设备通常一次只服务一个用户，首 token 延迟、单轮工具决策时间和持续功耗会直接影响体验。一个回答质量略高、但每次工具调用都要等待十几秒的模型，很难成为真正可用的桌面助手。

LFM2.5 系列此前已经把预训练数据量从 10 万亿 token 扩展到 28 万亿 token，增幅为 180%。 Liquid AI 同时扩大了包含强化学习在内的后训练流程，意图是在不把参数规模推高到数十亿甚至数百亿的情况下，提高小模型的指令遵循能力。更多数据并不自动等于更强模型，但对于容量受限的小模型，数据筛选、训练配比和后训练质量通常比继续堆参数更关键。

Liquid AI 对端侧多模态的布局也不只限于文本。 LFM2.5 家族此前覆盖 Base、Instruct、日语、视觉语言和音频语言方向，其中官方宣称新一代音频模型的速度达到前代的 8 倍，目标设备包括汽车、手机和物联网硬件。LFM2.5-2.6B 的意义在于补上更强的文本决策核心，让语音输入、视觉感知和工具执行最终能够汇入同一个本地工作流。

它不会取代云端大模型，但可能替代大量云端请求

LFM2.5-2.6B 与大型云端模型并不是正面替代关系。 26 亿参数仍然意味着有限的知识容量、复杂推理深度和长任务稳定性，它不适合被包装成能够独立处理所有软件工程、科研分析或开放世界规划任务的通用智能体。

LFM2.5-2.6B 更现实的竞争对手是其他 1B 至 4B 级开放权重模型。 Qwen、Gemma、Llama 和 SmolLM 等家族都在覆盖轻量部署市场，而 Liquid AI 的差异化重点是设备原生架构、低延迟和 Agent 工作流，而不是仅依靠通用考试分数证明能力。

| 比较维度 | LFM2.5-2.6B 的侧重点 | 常见 1B—4B 小模型 | 云端大型模型 | |---|---|---|---| | 部署位置 | 本地和边缘设备 | 本地部署为主，也可上云 | 数据中心为主 | | 隐私 | 数据可不离开设备 | 取决于部署方式 | 通常需要上传请求 | | 离线运行 | 支持 | 多数支持 | 通常不支持 | | 工具调用 | 作为核心产品方向 | 各模型支持程度不同 | 通常更成熟 | | 复杂推理 | 受 2.6B 规模限制 | 同样受参数规模限制 | 整体更强 | | 单次调用费用 | 本地运行无按 token 计费 | 本地运行无按 token 计费 | 通常按 token 或套餐计费 | | 隐性成本 | 设备、功耗、工程适配 | 设备、功耗、工程适配 | 网络、订阅和数据治理 |

本地模型最容易替代的是高频、重复、边界明确的云端请求。 邮件分类、会议记录整理、文件检索、表单填写、日历管理、设备控制和企业内部知识查询，都不一定需要数百亿参数模型持续介入。更合理的架构是让 2.6B 模型承担路由和常规执行，遇到复杂推理、低置信度结果或超长上下文时，再把经过脱敏的任务升级给更强模型。

混合 Agent 会比纯本地或纯云端方案更快落地。 本地模型负责隐私数据读取、权限检查、工具选择与简单总结，云端模型负责难题求解；这样既减少敏感信息暴露和网络往返，也避免让小模型硬扛超出能力范围的任务。

本地化并不自动等于安全

本地运行解决了数据传输问题，但没有解决 Agent 的全部安全问题。 当模型能够访问文件、浏览器、终端和企业系统时，恶意文档中的提示注入、未经确认的写操作、工具返回内容污染和权限配置错误，仍然可能导致数据泄露或误操作。

部署 LFM2.5-2.6B 时应把模型视为不可信的决策组件。 开发者至少需要执行以下约束：

• 工具采用白名单机制，默认不开放任意命令执行；
• 读权限与写权限分离，删除、发送和支付等动作必须二次确认；
• 不把工具返回文本直接视为系统指令；
• 为每次工具调用记录模型输入、参数、结果和错误信息；
• 设置最大调用次数，防止 Agent 陷入重复执行循环；
• 对结构化参数做类型、范围和路径校验；
• 在量化后重新测试工具调用，不能只验证聊天质量；
• 商业部署前核对 Hugging Face 模型卡中的许可证及使用限制。

量化后的可靠性测试尤其容易被忽略。 4-bit 模型可能在一般问答中看不出明显退化，却更容易在 JSON 字段、引号闭合、枚举值和长工具描述中出错。对于 Agent 产品，开发者应分别统计单次工具选择准确率、参数合法率、多步任务完成率和误调用率，而不是只看用户主观感觉。

现在下结论还需要独立测试

Liquid AI 当前给出的定位足够清晰，但官方宣传不能替代跨硬件实测。 LFM2.5-2.6B 是否真的适合“到处部署”，最终要看它在 Apple Silicon、x86 CPU、消费级 NVIDIA GPU、Android 芯片和嵌入式 NPU 上的首 token 延迟、生成速度、峰值内存与功耗。

Agent 能力也需要比传统 benchmark 更严格的验证。 一个模型可能在单轮工具调用测试中表现良好，却在连续五步任务中逐渐偏离目标；也可能正确选择工具，却无法处理超时、空结果和权限拒绝。官方文章展示的是方向，社区接下来需要补齐可复现的量化结果与真实工作流对比。

LFM2.5-2.6B 最重要的信号，是端侧小模型开始争夺 Agent 的控制层。 过去行业默认 Agent 的“大脑”必须放在云端，本地设备只是输入输出终端；现在 2B—4B 级模型正在尝试接管高频决策，让模型靠近数据、应用和传感器。

这款模型值得关注，但不值得神化。 它大概率无法在复杂推理上挑战顶级云端模型，却可能在私密、低延迟、持续在线和成本敏感的任务中更有产品价值。对开发者来说，真正值得测试的问题不是“2.6B 能不能像旗舰模型一样聊天”，而是“它能不能在我的设备上连续调用五次工具而不犯错”。如果答案是肯定的，本地 Agent 才算真正跨过了演示阶段。

参考来源

• Liquid AI：Deploy local agents everywhere with LFM2.5-2.6B：本次模型发布的官方说明，介绍 LFM2.5-2.6B 的本地 Agent 定位与部署方向。
• Reddit LocalLLaMA 社区关于 LFM2.5 系列的讨论：社区对 LFM2.5 微型设备端模型、延迟和多模态能力的讨论。