你对手机里的 AI 说：“查一下明天的天气，再按结果调整日程。”它不能只回一段像样的话。它得先请求天气程序，再读取结果，最后调用日历。这类连续操作需要 Agent——能把任务拆成几步，并指挥外部程序的 AI。问题是，模型太大，手机跑不动；模型太小，又容易在执行中掉链子。
Liquid AI 发布的 LFM2.5-2.6B，正面回应了这个取舍。它是面向端侧部署的小模型：产品名写作 2.6B，官方模型页给出的精确参数量是 2.69B。它支持最长 128K 的上下文窗口，还经过面向多步 Agent 工作流的后训练。换句话说，厂商想做的不是手机里的“全能专家”，而是一个体积较小、能记住较长任务过程，也会按规矩调用工具的执行中枢。
下文中的速度、内存和评测成绩主要来自厂商数据，目前缺少独立复现，尤其不能把“手机 30 tok/s”理解成所有手机、所有使用条件下都能达到这一速度。
小模型不只要会聊天
LFM2.5-2.6B 延续 LFM2 的混合架构。官方列出的 30 层中，包括 22 个 double-gated short convolution blocks 和 8 个 GQA 层。对普通读者来说，重要的不是记住这些结构名，而是它试图在有限参数和设备资源下，兼顾处理文本的能力与推理效率。
它更关键的能力是工具调用（tool calling）——模型不只是生成自然语言，还能按约定格式，请求外部程序执行搜索、计算或应用操作。官方模型页描述了它的基本流程：开发者先用 JSON 提供可用工具，模型再输出带有专用标记的函数调用。程序执行后，把结果交还给模型继续处理。这就像给 AI 一张明确的通讯录：它不必假装自己知道天气或已经改好日历，而是要正确找到工具、填好参数，再接着完成任务。
官方称，它接受了 agentic post-training，即针对 Agent 工作方式做的后训练，并在常见 Agent 框架中训练，以提高多步任务的兼容性。推荐用途包括工具使用、数据抽取、RAG——先检索资料再回答——以及长上下文工作流。
128K，装得下不等于跑得轻松
上下文窗口是模型一次推理能处理的词元总量，其中不只有用户问题，还包括历史对话、工具返回结果和模型已经生成的内容。LFM2.5-2.6B 支持 131,072 个词元，通常简称 128K。对 Agent 来说，这很实用：任务走过十几步后，前面的指令和中间结果仍可能留在窗口里。
但“支持 128K”和“在手机上舒适使用完整 128K”是两回事。上下文越长，内存与计算开销通常越高。现有材料没有给出手机型号、测试时的上下文长度，也没有说明速度测的是读取提示还是生成答案。长任务中的工具结果不断累积后，实际速度和稳定性仍待验证。
本地部署方面，Reddit 帖文转述称，官方 Q4_K_M GGUF 文件约 1.67 GB，可通过 llama.cpp 运行。GGUF 是本地推理常用的模型文件格式；Q4 则意味着量化，即用更低位数保存权重，以减小文件和内存需求，代价可能是一定程度的质量下降。官方还提供或说明了 Transformers、vLLM、SGLang、Docker Model Runner 等加载路径。
30 tok/s 的意义在哪里？
厂商测试称，LFM2.5-2.6B 在手机 CPU 上可达每秒 30 个词元，在 Ryzen AI Max+ 395 上为 113 tok/s，在 M5 Max 上为 220 tok/s，测试内存占用低于 2.5 GB。词元可以粗略理解为模型读写文本时使用的小片段。30 tok/s 若能在具体设备和真实 Agent 流程中复现，意味着本地工具调度不必总等云端返回，隐私敏感的数据抽取和重复操作也有机会留在设备上完成。
能力方面，厂商数据呈现出一个比“以小胜大”更克制的结论。LFM2.5-2.6B 在 ToolSandbox 和 IFBench 上分别得到 77.83、59.17，高于对比中的 Qwen3.5-9B 的 76.44、56.47；但在 BFCLv4 和 LiveCodeBench 上只有 56.88、59.41，低于后者的 60.13、69.86。也就是说，它在部分工具使用和指令遵循评测中很有竞争力，却没有全面追上更大的模型。
这正是它值得关注之处：端侧 Agent 未必需要一个包办所有工作的“最聪明大脑”。许多任务只是抽取字段、查询信息、操作文件或反复调用工具。一个速度较快、成本较低的小模型，可以承担这些执行工作；至于它是否能长期稳定地完成复杂链条，现有材料还不能下结论。
局限与未知
- 30 tok/s 和低于 2.5 GB 内存均为厂商口径，缺少手机型号、量化版本、上下文长度和测试方法，不能泛化到任意设备。
- 128K 是支持上限。完整长上下文在手机上的内存开销，以及连续十余次工具调用后的稳定性，尚无独立验证。
- 官方明确不推荐把它用于 agentic coding；编码和知识密集型任务仍是弱项。现有评测数据也未见第三方复现。