Liquid AI发布LFM2.5-24B-A2B，一款24B参数的混合专家（MoE）本地推理模型，每token激活约2B参数，主打在个人电脑与边缘设备上持续运行的智能体场景。模型支持长上下文（131K token）、多种部署格式与推理框架，在工具调用和智能体任务上表现亮眼，但在知识与编码基准上并非全面领先，厂商建议配合检索及独立复测。
Liquid AI发布了LFM2.5-24B-A2B，一款面向本地部署的24B参数混合专家（MoE）推理模型。该模型每个token只激活约2B参数，主打在个人电脑和其他边缘设备上运行需要持续推理、调用工具和处理多步骤任务的智能体。
Liquid AI在Hugging Face官方团队文章中说，LFM2.5-24B-A2B于2026年10月13日发布，是LFM2.5系列中规模最大、也是最后一款模型。模型权重已经在Hugging Face开放，另有基础模型版本可供微调。
这次发布延续了近年来将部分人工智能工作从云端推向本地设备的路线。与单纯追求参数规模不同，Liquid AI把重点放在激活参数量、内存占用、工具调用速度以及长时间运行的成本上。
更大的总参数量，更小的每次计算量
LFM2.5-24B-A2B拥有约240亿总参数，但每个token只激活约20亿参数。它采用40层架构，每个MoE模块包含64个专家并使用top-4路由，同时结合门控短卷积和分组查询注意力（GQA）。
模型的上下文窗口从上一代LFM2-24B-A2B的32K扩大到131,072个token，词表从约6.5万个token扩展到12.8万个token。Liquid AI称，这一变化也改善了中文、日文等非拉丁文字的分词表现。
根据模型卡，LFM2.5-24B-A2B是一款纯文本推理模型，会在生成最终回答前先进行显式推理。模型卡列出的活跃参数量为2.45B，训练预算为约36万亿token，支持英语、中文、日语、韩语、越南语、泰语、印地语等多种语言。
训练过程分为多个阶段。Liquid AI表示，预训练规模从上一代的约17万亿token增加到约33万亿token；随后又使用2万亿个32K上下文token和3000亿个131K上下文token进行中期训练，内容侧重推理、数学、代码、指令遵循、多语言文本和长上下文任务。工具调用和多轮轨迹贯穿其中。
后训练阶段则包括监督微调、教师模型专门化、多领域在策略蒸馏，以及在OpenClaw、Hermes Agent、Pi和OpenCode等智能体框架中进行的智能体强化学习。
工具调用表现突出，但知识和编码任务并非全面领先
Liquid AI在16项基准上，将LFM2.5-24B-A2B与Qwen3.6-35B-A3B、Gemma-4-26B-A4B-it和Nemotron-3.5-Lightning进行比较。公司称，LFM2.5-24B-A2B是参测模型中总参数量和激活参数量最小的模型，但在工具使用和智能体任务上具有竞争力。
在公司公布的结果中，LFM2.5-24B-A2B在AutomationBench上的得分为27.69，高于Qwen3.6-35B-A3B的8.72；在LiveClaw上得分为48.09，高于Qwen模型的38.19。在BFCLv4、ToolSandbox和τ³-Bench Banking等工具调用测试中，它也取得了最高或接近最高的成绩。
不过，这并不意味着模型在所有任务上都占优。Qwen3.6-35B-A3B在PinchBench、GPQA Diamond、SWE-Bench Verified和SciCode等测试中领先；Gemma-4-26B-A4B-it在HLE上得分更高。Liquid AI也建议，在知识密集型任务中为LFM2.5-24B-A2B配合检索或网页搜索，而不要只依赖模型本身。
这些分数是Liquid AI依据各项基准推荐的生成参数、使用vLLM完成的公司评测结果。它们可以说明模型在特定设置下的能力分布，但不能直接替代独立复测，也不能推导出模型在所有真实业务中的表现。
公司称本地推理速度可达每秒184个token
Liquid AI称，LFM2.5-24B-A2B已经获得llama.cpp、MLX、vLLM、SGLang和ONNX等推理框架的支持。
在公司的设备测试中，该模型在Apple M5 Max上的解码速度为每秒184个token，在AMD Ryzen AI Max+ 395上为每秒114个token。Liquid AI称，这一速度最高约为同组其他MoE模型的1.7倍，同时使用的内存更少。
在GPU测试中，公司使用SGLang 0.5.22、单张NVIDIA B300、1024个输入token和最多256个输出token进行测试。结果显示，在高并发条件下，LFM2.5-24B-A2B的输出吞吐量超过每秒2.1万个token。
这些数字需要结合测试条件理解。它们是特定硬件、精度、框架和并发设置下的吞吐量，并不代表单个用户在普通电脑上可以获得同样的速度。实际体验还会受到量化格式、上下文长度、内存带宽和并发任务数量影响。
模型卡同时提供了多种部署格式，包括原生权重、FP8、GGUF、ONNX以及面向Apple Silicon的MLX版本。对于希望降低内存需求、使用CPU或在Mac上运行的开发者，这些格式比单一的原生模型文件更具实际意义。
从模型调用转向持续运行的本地智能体
Liquid AI在发布文章中展示了一个在M5 Max MacBook Pro上运行的本地智能体示例。该智能体可以规划任务、调用工具并完成多步骤工作，模型推理和工具调度均在设备上完成。
公司强调，重点不在于某一个具体工具，而在于工具调度循环是否足够快：用户提出需求后，智能体进行规划、请求确认、执行操作，再根据结果继续下一步。对于需要长时间运行的个人助理、代码代理、文件处理工具和企业内部自动化系统，这种交互延迟可能比一次性回答的峰值质量更重要。
模型也可以通过OpenAI兼容的本地服务接入智能体框架。Liquid AI给出的示例包括把本地服务地址指向http://localhost:8080/v1或其他推理后端，并将上下文长度设置为131072。不同后端使用的端口不同，llama.cpp和MLX通常使用8080，vLLM使用8000，SGLang使用30000，LM Studio使用1234。
不过，本地运行不等于完全离线。需要实时搜索、第三方连接器或外部服务的任务仍可能把数据发送到网络；如果智能体能够读取文件、运行代码或操作账号，权限、审计、确认和回滚机制仍然是部署的一部分，而不是由“模型在本地运行”自动解决的问题。
本地硬件也会影响这条路线的成本结构。AIFlux此前报道的英伟达64GB版DGX Spark显示，厂商正在把更大模型的本地推理能力压缩到开发者桌面设备中。但设备采购、电力、散热和维护成本，会成为云端按token付费之外的另一组支出。
小型决策模型与大型推理模型可能形成组合
LFM2.5-24B-A2B发布前，Liquid AI还推出了面向边缘设备的开放d1决策模型。正如AIFlux此前的报道，这类模型不以生成长文本为目标，而是直接输出分类、路由和风险判断。
这提示出一种可能的本地智能体架构：小型决策模型先判断请求是否需要升级、调用哪个工具或转交人工；较大的推理模型再处理复杂规划、知识检索和代码任务。这样的组合可以降低每次调用的成本，也能把高风险操作放入更明确的确认流程中。
但模型规模变小并不意味着验证责任变小。开发者仍需要检查数据许可、提示词和工具边界、测试集是否泄漏，以及高置信度错误是否会触发不可逆操作。对于需要联网或操作个人数据的智能体，模型的本地性只能降低部分数据外传风险，不能代替完整的安全设计。
开放权重降低门槛，也把评测责任交给使用者
LFM2.5-24B-A2B和LFM2.5-24B-A2B-Base目前均可从Hugging Face获取。开发者可以使用Transformers加载原生模型，也可以根据设备选择GGUF、ONNX或MLX版本，并通过vLLM、SGLang、llama.cpp等后端提供服务。
Liquid AI的策略，是用混合架构和稀疏激活降低本地运行大型模型的门槛，再用智能体训练和工具调用评测把模型从“能够回答问题”推向“能够持续完成任务”。这并不能消除本地部署的硬件门槛，但可能改变开发者对模型大小的判断标准：总参数量之外，激活参数量、内存占用、运行时支持和工具调用可靠性同样决定模型是否适合真实工作流。
下一步仍要看独立开发者和第三方评测能否在不同硬件、量化格式和真实智能体任务中复现Liquid AI公布的结果。对本地智能体而言，速度只是入口；长时间运行的稳定性、权限控制、工具调用错误率和数据边界，才决定它能否从演示走向生产环境。
来源
- Hugging Face：Run fast, private agents on-device with LFM2.5-24B-A2B
- Liquid AI：LFM2.5-24B-A2B Benchmarks
- Hugging Face模型卡：LiquidAI/LFM2.5-24B-A2B
- Hugging Face基础模型卡：LiquidAI/LFM2.5-24B-A2B-Base
- Liquid Docs：LFM文档
本文根据Liquid AI、Hugging Face及相关模型文档整理。模型性能数字主要来自厂商在特定测试条件下公布的结果，实际表现可能因硬件、软件栈、量化方式和任务设置而异。