LFM2.5-24B-A2B：专为端侧智能体打造的快速模型

LFM2.5-24B-A2B 是什么

Liquid AI 推出的 LFM2.5-24B-A2B 是一款面向端侧智能体（On-Device Agents）场景优化的混合专家（MoE）架构模型。从命名规则可以拆解出关键信息：总参数量 24B，激活参数仅 A2B（约 2B 级别），这意味着模型在推理时只需调用极小一部分参数即可完成计算。

这种设计思路与当前端侧 AI 的核心矛盾直接相关：用户希望本地设备具备足够强的语言理解与工具调用能力，但手机、笔记本、边缘设备的算力和内存都极为有限。24B 的总容量保证了知识储备，2B 级别的激活着则把每次推理的计算开销压到了可接受的范围。

混合专家（Mixture of Experts, MoE） 是一类稀疏激活的神经网络架构。它的核心思想是把前馈层拆分成多个并行的「专家」子网络，并额外训练一个轻量的「路由器」（router/gating network）。每次前向计算时，路由器根据当前 token 的表示，只挑选其中少数几个专家参与运算，其余专家保持闲置。这样一来，模型的总参数量可以做得很大（用于存储知识），但单个 token 的实际计算量只取决于被激活的专家数量，从而在推理成本与模型容量之间实现解耦。这与稠密模型「参数越多、每次计算量越大」的线性关系形成鲜明对比，也是 MoE 被广泛用于超大规模模型的关键原因。

激活参数（Activated Parameters） 指模型处理单个 token 时真正参与浮点运算的参数规模，通常等于被选中专家参数量加上共享层与注意力部分的参数。它与「总参数量」是两个不同概念：DeepSeek^广告、Mixtral 等 MoE 模型都采用「大总量、小激活」的命名方式，例如把总参数 24B、激活约 2B 的模型记作 24B-A2B。激活参数直接决定推理时的计算量（FLOPs）和理论延迟，而总参数量则决定显存/内存占用。理解这一区分是判断端侧模型能否落地的关键——它决定了模型「跑得动」与「装得下」这两件事分别受什么约束。

为什么端侧智能体需要专用模型

智能体（Agent）和普通对话模型对推理引擎的要求并不相同。一个典型的端侧智能体需要频繁执行多轮循环：解析用户意图、选择工具、生成结构化参数、读取返回结果、继续决策。这个过程中，低延迟比单次回答质量更关键——用户无法接受每次工具调用都等待数秒。

LFM2.5-24B-A2B 在 Hacker News 上引发讨论，核心原因也在于此：它试图解决的不是「模型能做什么」，而是「模型能在多快的速度下、在多小的设备上做什么」。对于本地运行的自动化助手、隐私敏感场景下的文档处理、以及需要离线可用的工具调用流程，这类模型提供了一个更务实的选项。

混合专家架构在端侧的取舍

MoE 架构并不是新概念，但把它用在端侧有独特的工程权衡。

优势：容量与速度的解耦

传统稠密模型如果要提升能力，必须同步增加推理成本。MoE 把「记住多少」和「每次算多少」拆开：24B 参数分布在多个专家中，路由器根据输入动态选择激活路径。据 HN 讨论中的分析，A2B 级别的激活量让模型在消费级硬件上有了运行的可能性，而不必依赖数据中心 GPU。

挑战：内存占用与路由开销

MoE 的代价同样明显。虽然激活参数少，但全部 24B 权重仍需加载到内存中，这对统一内存架构的设备（如苹果 Silicon 芯片）相对友好，对独立显存有限的设备则构成压力。此外，路由器本身的调度逻辑会引入额外延迟，端侧部署时需要针对具体硬件做量化与算子优化。

统一内存架构（Unified Memory Architecture, UMA） 指 CPU、GPU 及其他加速器共享同一块物理内存池的设计，苹果 M 系列芯片是典型代表。在传统独立显卡方案中，模型权重需要驻留在显存里，而显存容量通常远小于系统内存；一旦模型权重超出显存上限，就必须依赖 CPU 卸载或分页换入换出，导致速度骤降。UMA 方案下，GPU 可以直接访问全部系统内存，因此 24B 这类总参数量较大的模型在 MacBook 上也能整体加载。这也是为何文章强调「对统一内存架构的设备相对友好，对独立显存有限的设备则构成压力」——内存带宽和容量的差异，往往比算力本身更能决定端侧 MoE 模型的实际可用性。

端侧智能体的真实应用边界

结合 HN 评论区的讨论方向，这类模型的实际价值集中在几个场景：

本地隐私优先的自动化——数据不出设备，智能体在本地完成邮件分类、日程整理、文档摘要等任务。

低延迟工具调用——相比云端 API 往返，本地模型可以做到近乎即时的函数调用响应，适合需要高频交互的界面操作。

离线可用性——在网络不稳定或完全隔离的环境中，端侧模型是唯一可行的方案。

需要清醒认识的是，2B 级别的激活着意味着它在复杂推理、长链条规划上的能力无法与云端大模型正面竞争。它的定位是「够用的本地智能体」，而非「全能助手」。

对开发者的实际意义

LFM2.5-24B-A2B 的出现，反映了一个正在成形的趋势：模型厂商开始针对「端侧智能体」这一细分场景做专门优化，而不是简单地把大模型缩小。对开发者而言，这意味着在选择本地推理方案时，除了看参数量和 benchmark，还需要关注激活着、内存占用、以及是否针对工具调用做了格式与延迟上的优化。

端侧 AI 的竞争，正在从「能不能跑」转向「跑得好不好、快不快」。