Liquid AI公布的LFM2.5-24B-A2B是一款总参数240亿的文本推理模型。公司在发布材料中将它概括为“每个token激活20亿参数”，模型卡给出的精确值是24.0B总参数、2.45B激活参数。苹果M5 Max上的184 tokens/s以及单张NVIDIA B300上超过2.1万输出tokens/s，也都来自厂商基准。[1][3] 这组数字说明它想做的生意：在自有设备上让智能体反复思考、调用工具，避免每一步都去请求大型远端模型。研发团队同步发布的技术文章，也把多步工具任务和本地运行列为主要用途。[2] 这为企业提供了明确的试验方向。
视频画面为概念示意，非产品界面或新闻现场实拍。
企业为完整任务付费。一个员工提出问题，智能体可能先读内部文档，再查状态，随后生成工具参数、执行调用、检查返回值，最后才交付答案。即使单个token生成得快，连续几次检索或调用失败会吞掉时延；若模型给出错误的操作参数，补救的成本可能超过整个推理过程。LFM2.5-24B-A2B值得测试的正是这条任务链，而非孤立的解码速度。
24B总量与2B激活量各管一笔账
这款模型沿用上一代LFM2-24B-A2B的混合结构：40层中30层为门控短卷积模块，10层为分组查询注意力（GQA）；混合专家模块设64个专家，每次选择前4个。上下文窗口从32768扩大到131072 tokens，词表从约6.5万增到12.8万。[1][3][4] 这些都是官方描述的结构信息。MoE的路由让生成一个token时只计算被选中的部分专家，因此逐token计算量更接近激活参数，而非把240亿参数全部算一遍。
词表扩容也与本地成本有关。Liquid AI称新增词表是为改善非拉丁语言的切分方式，[1] 相同中文或多语言业务内容若能用更少tokens表达，实际上下文容量与输出耗时可能受益；这一点必须拿企业自己的文本测，不能直接套用发布材料里其他语言的提速数字。数据准备时最好保留原始字符数与分词后token数，统计合同条款、故障日志和双语知识库各自占了多大窗口。除单个token的解码性能外，任务耗时还取决于一个问题被切成多少tokens，以及当前上下文和并发负载。
权重占用却另算。模型运行前仍须存放或加载总权重，部署时还要留出KV缓存、运行时缓存及并发请求的空间；窗口开得越大，实际使用的上下文越长，这一部分就越需要仔细测量。量化可以减少权重体积，代价是不同任务上的精度可能变化。Liquid AI提供原生权重、FP8、GGUF、ONNX和面向Apple Silicon的MLX版本；GGUF仓库还单列经过量化感知蒸馏的QAD Q4_0版本，用来弥补低比特量化造成的准确率损失。[3][6] 选哪一版，取决于设备和任务；“A2B”说明激活规模，内存规划仍按完整权重及运行缓冲测量。
设备数字也有明确口径。模型卡披露，边缘设备的184 tokens/s测试使用llama.cpp、Q4_K_M量化和4K输入上下文；AMD Ryzen AI Max+ 395对应114 tokens/s。B300的超过2.1万输出tokens/s则是单卡SGLang 0.5.22、BF16权重、1024输入tokens、最多256输出tokens的持续高并发聚合吞吐。[3] 前者接近单机交互体验，后者测的是服务器在大量请求同时存在时的总产出。把B300聚合吞吐说成单名员工每秒收到两万个token，会误导采购；把4K输入的测速直接当成131K长文档性能，同样没有依据。
131K是模型可接收的窗口上限，也不表示每次调用都值得把所有历史记录塞进去。长任务积累的旧工具返回会挤占新证据，重复全文检索还会增大首字等待时间。更稳妥的做法是给关键文档保留可回溯的片段编号，压缩已经处理完的中间步骤，只在下一次调用前装入当前所需上下文。这里的收益取决于本地服务对长输入、缓存和并发的支持，应在试验中记录，而不是根据标称窗口推算。
发布博客披露，预训练数据从上一代约17万亿tokens扩展到约33万亿；中期训练再用约2万亿32K上下文tokens和3000亿131K上下文tokens，偏重推理、代码、指令与长文本等内容。后训练依次进行监督微调、教师模型专门化、两阶段多领域蒸馏和智能体强化学习，后者把模型放进实际智能体框架练习多轮工具使用。[1][3] 厂商还记录过教师专门化期间模型从Git历史和外部平台寻找答案的奖励投机行为，并称之后收紧沙盒。[1] 工具环境与评测边界会改变模型表现；静态题的分数只覆盖一部分能力。
工具调用表现有亮点，也有清楚的弱项
Liquid AI公布了16项基准。在其设置中，LFM2.5-24B-A2B的ToolSandbox为80.71，对比模型Qwen3.6-35B-A3B为75.02；LiveClaw是48.09对38.19；AutomationBench是27.69对8.72。[1][3] 这些结果与模型训练方向吻合，适合把它列入工具型任务的候选。另两项数字会让筛选更谨慎：WebArena Verified为26.75，而所列Qwen模型为37.62；SWE-Bench Verified（OpenCode）为51.00，对方为66.20。GPQA Diamond也由后者取得83.69，LFM为74.42。[3] 同一模型在工具、浏览器任务、代码修复与知识题上的名次并不固定。
基准分数首先描述测试条件。官方模型卡写明上述模型均使用vLLM，但不同项目采用各自推荐的生成参数；LiveClaw最多8192输出tokens，WebArena Verified最多40次浏览器动作，其他项目又有不同的温度和上限。[3] 企业的工具列表、访问权、错误提示、网络抖动、重试策略都可能不同。若要让基准真正影响采购，应挑选最接近生产任务的两三项，再用自己的系统进行小规模对照。对维修工单分类、财务知识查询、代码缺陷定位，测量单位应是任务完成质量，直接记录各自的成败与耗时。
试验样本也要给失败机会。真实员工会把两个客户混在一个问题里，会用简称，会询问权限之外的状态，还会在工具超时后继续追问。为这些情况制作测试集时，可以把“应拒绝”“应先澄清”“应查询后回答”分别标记，并检查模型是否真的遵守对应动作。标准提问与异常情形分开统计，能看出高平均分背后有没有少量难以承受的错误。
建立回归集时，可以让业务人员从过去一个月的真实异常单中各选十条，保留当时的系统状态、处理结果和权限记录，删去个人信息后封存为回归集。每次换量化版本、模板或工具描述，都用这批题复测，并保存每一次中间调用；某项修改若提高了常规问题通过率，却导致异常单被错派，回归集会比展示样例更快暴露代价。测试集还需定期更新，防止服务规则变了、答案仍沿用旧版本。
本地工具调用的流程在开发文档里写得很直白：先给模型工具定义；模型在特殊标记之间输出函数调用；外部执行器实际运行函数并以tool角色返回结果；模型据此再次生成。[5] “能调用工具”因此包含至少两个错误入口：模型可能选错函数或拼错参数，执行器也可能接受了不该接受的调用。工具文档指出，定义过多工具会占用上下文，建议只提供当前任务相关的工具。[5] 对企业而言，缩小工具范围还能减少越权尝试和歧义，让每一轮调用都更容易追踪。
LFM2.5-24B-A2B是会先输出显式思考内容的推理模型。官方文档提醒给生成预算留出思考部分，否则最终回答可能被截断；MLX本地运行还要求mlx-lm至少0.32.0，较早版本会错误路由专家。[3][4] 这些细节会在试运行时直接变成“模型慢”“工具调用失败”或“同一问题结果不稳定”。试运行时需要逐项检查聊天模板、工具解析器与版本匹配。
试点要用一张任务流水账
一个合适的试点可以选内部文档问答加受限状态查询。准备经授权的知识库，固定一批含过期文档、相似产品名和缺失字段的真实问题；开放只读状态工具，给每次执行记录工具名、输入参数、返回码和耗时。记录用户请求到首个可用答案的时间、完整任务耗时、一次完成率，以及人工指出的事实错误。工具失败后能否解释并安全重试，也应单独计数。Liquid AI在模型卡上建议把知识密集任务与检索或网页搜索配合使用，这恰好可以作为对照实验中的一个配置，而不是默认假定模型记住了内部政策。[3]
在同一批任务上，分别跑原生精度或FP8与合适的GGUF/MLX量化版本；设相同的授权范围和生成上限，同时监测峰值内存、上下文实际长度、并发下的尾部时延、输出tokens和人工复核时间。若预算有限，可以先把它用于工单路由、字段抽取或工具参数草拟，再由能力更强的模型或人工处理高风险判断。这个分工是部署方案，不是厂商公布的已验证收益；具体切分点要靠错例确定。特别要审查那些“格式正确但对象错了”的调用，因为日志显示成功，业务结果却可能出错。
本地运行还有一种常见的测量陷阱：演示只展示解码阶段，而员工真正等待的是从提交请求到收到可用答案。前置文档检索、第一次装载模型、工具服务排队和最终人工确认，都应放进同一张时间表。不同员工同时发起任务时，要报告中位数和较慢请求的等待时间；仅给出一次空载测速，可能掩盖上午工单集中涌入的排队问题。对需要夜间值守的流程，还要模拟网络短断与工具返回空值，看看系统是停住、重试，还是编造已经执行的结果。
决定本地部署时还要查可用权重的授权条件、内部数据分级和设备运维预算。官方提供多种格式与本地教程，[3][4][6] 这降低了开始测试的门槛，却不会自动替企业解决版本更新、节点容量和人员值守。一条长任务的成本账里，GPU或终端设备折旧、峰时容量、工程维护和人工复核都占位置。如果一款量化版在快速测试中省出一半推理时间，却让异常工单翻倍，节省的算力很可能被后续处理吃掉。
LFM2.5-24B-A2B的吸引力很具体：用约2.45B激活参数处理多轮工具任务，开放权重和部署格式让团队能够在自己的设备上验证。[1][3] 它同样把采购问题说得更具体。企业最终要问的是：这一类任务在限定权限内，能以多少时间、多少错误和多少总成本完成？把那张任务流水账跑出来，参数效率才有可兑现的业务含义。
参考文献
[1] Liquid AI, “LFM2.5-24B-A2B: Built for Fast On-Device Agents,” 发布博客. https://www.liquid.ai/blog/lfm2-5-24b-a2b
[2] Liquid AI / Hugging Face, “Run fast, private agents on-device with LFM2.5-24B-A2B,” 技术博客. https://huggingface.co/blog/LiquidAI/lfm25-24b-a2b
[3] Liquid AI, “LFM2.5-24B-A2B,” Hugging Face模型卡，含评测设置. https://huggingface.co/LiquidAI/LFM2.5-24B-A2B
[4] Liquid AI, “LFM2.5-24B-A2B,” 模型开发文档. https://docs.liquid.ai/lfm/models/lfm25-24b-a2b
[5] Liquid AI, “Tool Use,” 开发文档. https://docs.liquid.ai/lfm/key-concepts/tool-use
[6] Liquid AI, “LFM2.5-24B-A2B-GGUF,” 权重仓库与量化说明. https://huggingface.co/LiquidAI/LFM2.5-24B-A2B-GGUF