模型 · Liquid AI via Hugging Face
LFM2.5：每个词元激活2B参数，代理先思考再行动
2026年10月13日，Liquid AI推出LFM2.5-24B-A2B，具有24B总参数、2B激活参数，采用必经的多步思考并支持工具调用。它的看点是代理架构：每个词元由选中的专家处理，而内存需求和完成任务所需时间仍要分别评估。
这对买家意味着什么
它适合进入候选名单的场景，是助手通过工具逐步获取信息并据此行动。买家需要将MoE架构与实际流程结合评估；激活的权重部分较小，本身并不能确定服务器大小或完整任务的耗时。
少量激活参数意味着什么
根据Liquid AI的公告，模型保留前代LFM2-24B-A2B的架构：40层，每个MoE模块包含64个专家，每次选择其中四个。MoE是混合专家，各个模型组件分担处理工作。单个词元经过选中的部分，所以2B激活参数描述计算路径，24B总参数则描述完整参数集合。
代理通常存在多轮中间步骤：接收命令输出、理解结果、选择下一次调用，最后才组织答案。每个生成词元都重复消耗计算，包括思考过程中的词元。较小的激活路径，使这类架构值得用于长工具流程的试验，但仍不能据此确定某台设备能够同时服务多少个代理。
激活2B不等于只需存储2B权重
系统仍需在某处保存所需权重，并向计算提供选中的专家。权重放在哪里、采用什么数字精度，都要与激活路径分开考虑。文章的Transformers示例使用bfloat16加载模型，这是一个具体运行选项，不能自动代表其他精度，也不能代表所有本地配置。
长对话还需要缓存注意力状态，通常称为KV缓存，它用于处理后续内容，资源需求取决于运行配置。因此，选择服务器时应分别考虑权重、缓存和并发请求。A2B标签有助于理解计算量，却无法替代所选运行环境如何放置模型、如何同时服务多项任务的说明。
必须先完成思考过程
LFM2.5-24B-A2B被描述为仅采用多步思考的模型：最终答案之前，会产生明确的思考过程。这直接影响界面体验。词元输出速度与获得有用结果的等待时间，是两种不同指标。用户可能需要等待中间思考结束，代理还需等待工具执行；对于短操作，应先决定可以接受多长等待。
上下文从32K扩大到131K词元，分词器词表从65K扩大到128K，作者将词表扩展与非拉丁文字处理联系起来。词表决定文本如何拆分，不能当成额外上下文。更大的窗口也不证明每个事实都能有效回忆；历史、工具结果和生成内容共同使用预算。分析一个缺陷时，整个代码仓库并不自动成为最佳输入。
通过本地运行环境连接代理
公告列出llama.cpp、MLX、vLLM、SGLang和ONNX支持。建议的结构是在本地提供兼容OpenAI消息格式的后端，再让代理框架连接它。这里的兼容指通信格式，模型推断运行可以留在本地。Hermes示例分别配置服务器地址、模型及工具使用。
这种结构可以分别观察模型质量与框架行为。要复现缺陷，代理需要可用工具，以及正确返回的调用结果。宣布支持某个运行环境，并不能证明企业的完整组合已经正常工作。Liquid AI还发布LFM2.5-24B-A2B-Base；要使用文中描述的成品代理，应选择相应的代理训练模型，基础版本不会自动具有同样属性。权重采用LFM Open License v1.0。第5节依据1000万美元年收入门槛限制商业使用，企业选型时需要考虑这些条款。
按照完整行动链选择
Liquid AI分别讨论Apple M5 Max上的解码，以及单张NVIDIA B300在高并发下的总词元输出。这是不同负载：前者描述本地解码流，后者描述服务器整体输出。公告没有完整披露这些测量的精度、输入与批处理配置，所以不能将其中的数字速度转换为待购买设备的性能承诺。
简短试用可以围绕已知缺陷展开：用工具获取日志，选择相关文件，执行检查并解释结果。观察整条流程是否完成，以及包含思考过程的总耗时。LFM2.5值得探索的具体角色，是现有代理框架中的本地工具任务执行者。架构提供了试验理由，而完成的行动链才提供团队适用性的证据。
选购系统前要验证什么
- 命令返回部分结果、权限错误或意外格式时，代理会怎样处理？
- 能否将工具调用历史与思考文本分别保存，以调查失败任务？
- 写入代码仓库或外部系统前，哪些操作需要用户作出决定？
- 分词是否保留工作材料中的俄语路径、标识符和混合语言名称？
买家建议属于我们的编辑解读。原文并不证明目录中某款系统的速度或兼容性。