先看证据
本地代理的矛盾：模型总量大，单步计算却要轻
Liquid AI在Hugging Face发布了LFM2.5-24B-A2B，一款面向本地代理的24B参数推理模型。它要解决的不是单纯让聊天模型在设备上回答问题，而是让模型先推理，再调用工具，并在多轮任务中继续推进，同时尽量降低持续运行代理的推理成本。模型名称中的A2B指向每个 token 激活约2B参数，这正是发布方强调的效率来源。
这组数字也带来一个容易误读的冲突：24B描述模型总规模，2B描述每个 token 实际参与计算的参数规模，两者不是可以互换的硬件指标。稀疏激活可以降低单步计算量，但不代表模型在存储时只需要容纳2B参数。Liquid AI称它在对比模型中内存使用最少，却没有在材料中给出绝对内存占用、量化配置或最低设备规格，因此“适合本地”仍需要落到具体机器上验证。
架构没有变成小模型，变化在计算如何分配
LFM2.5延续LFM2-24B-A2B的主体架构：40层网络，每个MoE模块有64个专家，通过top-4路由选择专家，并结合门控短卷积与分组查询注意力。换言之，它不是把24B模型裁成一个只有2B参数的稠密模型，而是保留更大的专家池，让每个 token 只经过其中一部分。对部署者而言，这解释了为什么模型规模和推理速度可以同时呈现不同面貌，但并没有消除权重装载、上下文缓存和推理后端带来的实际约束。
版本升级还扩大了模型可处理的输入范围。上下文窗口从32K增至131K，词表则从65K扩展到128K，发布方称词表扩展有助于非拉丁文字的分词。预训练数据从约17T token 增至约33T，之后又加入2T个32K上下文 token，重点覆盖推理、数学、代码、指令跟随和多语言内容，并增加300B个131K上下文 token，偏重长上下文数据。这些改动扩大了模型训练覆盖面，但材料没有说明长上下文在不同设备上的内存代价。
训练目标从答题转向在工具环境里完成任务
LFM2.5与前代的一个关键区别，是它被定义为只进行推理的模型，会在最终回答前显式生成推理过程。训练材料也持续加入工具调用和多轮交互轨迹，后训练则包含多领域 on-policy 蒸馏、面向代理任务的第二阶段蒸馏，以及在代理框架中进行的强化学习。Liquid AI列出的训练环境包括OpenClaw、Hermes Agent、Pi和OpenCode。这些安排说明，模型能力的目标不只是生成一段看似合理的文本，也包括在工具反馈之后接着行动。
这对工程团队的价值，体现在代理工作负载的评价方式上。模型必须遵循指令、选择工具，并在多轮交互中处理工具返回的信息，单轮知识问答分数不能完整预测这些表现。发布方对16项基准的评估覆盖工具使用和代理工作流、知识、指令跟随、数学与代码，并称模型在八项工具及代理基准中的五项领先或持平，在三项指令跟随基准中均领先。不过，材料没有提供逐任务的失败案例或跨框架稳定性分析，训练目标不能代替对团队自身工具定义的测试。
基准优势集中在工具调用，速度数字也有条件
具体分数比“代理能力强”更能帮助选型。LiveClaw上，LFM2.5得分48.09，Qwen3.6-35B-A3B为38.19，后者总参数和激活参数都约多出一半。Liquid AI还称，LFM2.5在AutomationBench上的得分超过次优模型三倍。与此同时，较大模型在GPQA Diamond、HLE和AA-Omniscience等知识密集型基准，以及SWE-Bench Verified和SciCode等代码基准上仍有优势。这个结果分布指向一种明确取舍：工具执行和指令遵循是它更有说服力的切入点，不应由此推断它在所有任务上都胜过更大的模型。
速度数据同样要连同测试设备与负载来读。发布方报告称，模型在Apple M5 Max上达到184 token/s，在Ryzen AI Max+ 395上达到114 token/s，属于对比MoE模型中最快的一档，最高比次优模型快1.7倍。单张NVIDIA B300上的“超过21K输出 token/s”则是在高并发条件下给出的，不是单个用户交互时的设备端响应速度。评估使用vLLM，并按各基准推荐的生成参数运行，因此这些数字提供了比较依据，却不能直接代表另一套后端、并发模式或应用链路的实际延迟。
部署入口已经铺开，隐私与适用范围仍需自证
模型发布时已列出llama.cpp、MLX、vLLM、SGLang和ONNX支持，也提供Transformers加载入口，要求使用兼容Transformers 5.0.0及以上的版本。代理侧的训练环境与推理侧的部署后端并不是同一件事，支持某个后端也不自动保证团队现有工具、模型格式和设备组合能够无缝运行。技术负责人应把入口视为降低试用成本，而不是省略集成验证的承诺。材料没有给出这些路径之间的精度、内存和速度对照，不能仅凭兼容列表决定生产部署方式。
“本地”和“私有”也需要按数据路径拆开判断。本地推理有机会减少把提示词发送给远程模型服务的需求，但如果代理调用网页搜索或其他联网工具，相关请求和返回内容仍可能离开设备。结合基准表现，合理的起步方案是先在目标硬件上测试工具调用、指令遵循和多轮任务，再为知识密集型请求接入检索或网页搜索，并单独审查工具的数据流。若团队的首要任务是复杂代码修复或广泛知识问答，较大的模型仍应进入对照组。LFM2.5的优势是让本地代理更值得尝试，而不是让硬件、任务边界和治理问题自动消失。