很多开发者对端侧小模型的印象还停留在“能跑个问答、做个文本补全”的阶段。直到真正开始做 Agent 时才发现云端大模型虽然能力强但每条请求要上传数据、每轮对话要等网络、每个月还要看账单。于是问题自然就变成了能不能让 Agent 直接跑在用户设备上不上云、不等待、不烧接口费这就是 On-Device Agents 的切入点也是 LFM2.5-2.6B 这类模型值得关注的原因。从命名和参数规模看它是一个约 26 亿参数的语言基础模型目标不是“陪你聊天”而是“帮你干活”识别意图、调用工具、完成设备上的具体操作。我的判断是在端侧 Agent 这个方向上2.5B 到 2.6B 参数并不是“凑合的妥协方案”而是一个在算力、内存、体验和效果之间更容易取得平衡的甜点区间。这篇文章不会堆砌一堆我没有实测过的 benchmark 数字而是想把几件事讲透什么是端侧 Agent为什么小模型做 Agent 比做聊天更难如何把 LFM2.5-2.6B 部署到本地以及怎么搭建一个最小可用的工具调用闭环。读完你可以直接照着搭一个端侧 Agent 雏形并且避开那些最容易踩的坑。1. 这篇文章真正要解决的问题先说一个常见场景。你做了一个 AI 助手功能包括查天气、定闹钟、提醒日程。最开始接入的是云端大模型效果确实不错但问题很快就出现了成本不可控。每个用户每天都在发起多轮对话每轮对话都要把历史上下文重新发送一遍token 消耗量远高于“聊天”场景。延迟不稳定。Agent 的决策链路长模型要“思考、决策、调用工具、再生成回复”网络一波动用户体感就是卡片转圈。隐私压力大。日程、通讯录、位置这些本来就在端侧的数据因为 Agent 要理解上下文被迫打包上传到云端。这三个问题单拎出来都不致命一旦组合在一起就几乎决定了“云端 Agent”很难成为默认形态。产品只能把它当成一个高级功能而不是系统级入口。LFM2.5-2.6B 这类模型要解决的正是这三件事推理在本地完成数据不出设备延迟只取决于硬件没有服务端账单。当然26 亿参数换来不了 70B 模型的复杂推理能力但它能覆盖大量“低频但高频使用”的 Device Agent 任务比如设置提醒、控制智能家居、读取屏幕信息、填表单、管理文件。如果你属于下面任何一类开发者这篇文章都值得认真看移动端或 PC 端应用开发者想给应用加入端侧 AI Agent 能力物联网和边缘设备开发者设备无法稳定接入云端但又需要智能交互隐私敏感场景的从业者比如医疗、金融、企业办公数据不能出本地被云端 Agent 成本困扰的产品负责人想验证“端云混合”方案是否可行。核心结论先放这里LFM2.5-2.6B 这类模型的价值不在于单点能力比云端大模型强而在于它把“Agent 功能”从云端中心化部署变回了产品本地能力的一部分。2. 端侧 Agent 的核心概念与 LFM 模型的定位2.1 什么是 On-Device AgentAgent智能体在这里指的不是一个聊天框而是一个能自主完成多步任务的程序。它的典型结构是理解用户意图规划执行步骤调用外部工具如闹钟、日历、系统 API根据工具返回结果继续决策最终给用户回复。On-Device 指的是整个推理和决策过程发生在用户设备上。设备可以是手机、PC、平板、车载系统、智能音箱或机器人。与云端 Agent 相比它最大的区别是模型权重在本地工具调用也在本地用户数据不需要离开设备。2.2 LFM 是什么LFM 是 Language Foundation Model 的缩写即语言基础模型。基础模型意味着它未经特定下游任务深度定制是一个通用的文本理解与生成底座。开发者拿到之后可以基于它做指令微调、量化部署或者直接把它接入应用逻辑。LFM2.5-2.6B 从命名上看指的是版本号为 2.5、参数规模在 2.6B约 26 亿参数的模型。这一类模型和流行的“小参数大能力”路线一致参数不多但架构、训练数据和指令遵循能力都在向小型化做针对性优化目的就是能在端侧高效运行。2.3 2.6B 参数意味着什么参数规模直接决定硬件占用。我们粗略估算一下FP16 半精度下2.6B 参数权重约占 5.2GBINT8 量化下约占 2.6GBINT4 量化下约占 1.3GB 到 1.6GB再加上 KV Cache、临时激活值和推理开销整体内存占用会再高一些。换算成实际体验一台 8GB 内存的普通电脑加载 INT4 量化后的 LFM2.5-2.6B 模型可以比较流畅地跑 CPU 推理。如果是手机旗舰芯片配合端侧推理框架也能实现每秒几十 token 的生成速度。这个量级正好卡在“手机跑得动”和“效果还够用”之间。对比 7B 模型INT4 量化后权重约 3.5GB 到 4GB对手机内存压力明显更大CPU 推理速度通常只有 2.6B 的一半左右。对比 70B 级别的云端模型它完全无法端侧部署只能走网络请求。所以 2.5B 到 2.6B 这个区间是兼顾能力、速度与部署成本的合理选择。2.4 LFM 与云端大模型的分工一个成熟的端云混合 Agent 架构往往是这样的用户请求 │ ▼ 端侧小模型LFM2.5-2.6B │ ├── 简单的本地任务直接调用工具完成 ├── 隐私敏感任务本地下文理解 本地工具执行 └── 复杂推理任务做意图压缩 路由到云端大模型端侧模型负责“快”和“隐私”云端模型负责“强”和“博学”。两者不是替代关系而是共存关系。端侧模型能跑通 70% 的常见请求就已经能大幅降低成本和延迟这是 On-Device Agent 商业上成立的前提。3. 为什么 On-Device Agent 值得关注很多人会问既然端侧模型能力有限为什么不都放云端要回答这个问题不能只看模型能力要看整个产品形态。下面几个维度对实际项目的影响是决定性的。3.1 隐私与数据本地化Agent 类应用和普通问答应用有一个本质差别Agent 需要做具体操作必然涉及设备上的私有数据。日程、通讯录、位置、输入习惯、屏幕内容这些数据一旦上传云端对用户来说就是风险。端侧 Agent 把“理解”和“执行”放在本地数据没有机会离开设备。即使未来需要云端协助也只会发送去除隐私后的结构化摘要而不是原始上下文。这会让产品在隐私合规上的压力小很多。3.2 延迟体验的提升云端 Agent 的一个典型卡顿点是“多轮工具调用”模型每调用一次工具就要经历一次完整的通信往返。如果链路是“端到云 → 云到工具服务 → 云再生成 → 回传”单次工具调用的延迟可能高达一到三秒甚至更久。端侧 Agent 的推理在本地工具也在本地延迟主要取决于模型推理速度和工具本身执行速度。在硬件合理的设备上一次简单意图识别加工具调用可以控制在几百毫秒到一秒以内。这种体感差异是用户能否把语音助手当成日常功能的关键。3.3 离线与弱网可用地铁、电梯、地下室、偏远郊外网络环境永远不稳定。云端 Agent 在弱网下几乎不可用而端侧 Agent 可以完整运行。这个能力对特殊行业尤其重要野外巡检、应急通信、车载导航、医疗便携设备网络不是“偶尔断”而是“本来就没有”。3.4 成本结构的变化云端 Agent 的成本模型是“按 token 计费”用户对话越多Agent 调用工具越频繁成本越高而且不可控。端侧 Agent 是一次性部署模型推理消耗的是设备本身的算力和电量。对 C 端产品来说这意味着每个用户的新增边际成本趋近于零。对 B 端产品来说可以把昂贵的 GPU 资源集中到复杂推理任务上而不是浪费在“今天天气怎么样”这种高频低难度请求上。3.5 长期记忆与个性化端侧 Agent 还有一个容易被忽视的优势记忆可以长期存放在本地。云端模型受限于上下文窗口和隐私策略很难为每个用户维护一份完整的个人记忆库。而端侧 Agent 可以把用户偏好、历史操作、常用设置写入本地向量数据库在每个会话启动时快速加载。这意味着什么意味着 Agent 可以越用越懂你而且不需要上传任何隐私数据。这个能力对需要高粘性的应用来说商业价值非常大。4. 端侧 Agent 的技术难点与能力边界如果说“部署一个小模型”是体力活那么“让小模型稳定做 Agent”才是真正的技术活。这里有几个关键难点。4.1 工具调用格式的稳定性云端大模型经过大量指令微调输出 JSON 或调用函数通常很准。而端侧小模型参数量少指令遵循能力弱经常出现以下问题不调用工具直接把工具结果“想象”出来参数名写错多传或少传字段把工具说明当成了普通文本回复。应对方法有两种一是模型本身微调过 Function Calling二是在推理层用提示词强制输出 JSON再靠代码解析。LFM2.5-2.6B 如果具备命令遵循能力可以优先走 OpenAI 兼容接口的tools参数如果效果不稳定就必须做一层格式兜底。4.2 多轮任务的上下文管理Agent 场景下用户往往不会一次说完整需求。例如“帮我把明天早上的闹钟设到八点……不对改成八点半。”这种多轮语境对小模型是一个大考验。模型不仅要理解指令还要能判断“改”指的是改哪个闹钟、从几点改到几点。端侧模型的上下文窗口通常有限可能是 4K、8K 或 16K。如果每轮对话都把完整历史塞进去很快就会撑爆窗口。更合理的方式是在端侧做记忆裁剪只保留关键信息比如当前任务目标、已经确定的参数、最近两轮对话。必要时离线生成摘要把长历史压缩成结构化记忆。4.3 系统提示词的长度控制端侧小模型对长提示词非常敏感。系统提示词越长模型越容易混淆重点生成速度也会下降。因此给端侧 Agent 写系统提示词要尽量精简明确角色列出可用工具和参数规定输出格式规定不要做什么。千万不要把云端模型那套几千字的“角色设定 样例 few-shot”直接搬到端侧效果会明显变差。4.4 推理速度与设备续航端侧 Agent 虽然省了网费和云费但消耗的是设备电量和计算资源。2.6B 模型在 CPU 上推理时如果线程设置不合理可能造成设备发烫、掉电加快。在真实产品中必须考虑使用 4bit 或更低量化开启部分 GPU 加速限制并发请求数在低电量时主动降级为云端方案。4.5 幻觉与安全边界模型越小幻觉不一定越严重但输出稳定性会差一些。尤其在 Agent 场景模型的错误输出可能直接触发系统操作。比如把闹钟设在“25:00”或者把文件命名成乱码。因此端侧 Agent 必须在执行工具前增加“参数校验层”不能完全信任模型输出。下面这张表能帮你快速理解云端大模型与端侧小模型在 Agent 任务上的差异维度云端大模型LFM2.5-2.6B 等端侧模型推理能力强中低偏简单任务工具调用稳定性高一般需要格式兜底延迟受网络影响通常较高本地推理更快隐私数据需上云数据不出设备成本按 token 计费一次性部署成本可离线使用否是上下文窗口大通常较小需要裁剪适合任务复杂推理、知识问答设备操作、隐私敏感短任务这个表格背后有一个清晰的判断端侧模型不是“穷人版的云端模型”而是为特定场景重新设计的另一种 Agent 形态。理解这一点后续做架构选型才不会选错方向。5. LFM2.5-2.6B 环境准备与基础部署这一节我们把 LFM2.5-2.6B 跑起来。文章以通用流程演示具体模型文件、推理框架版本请以你实际拿到的东西为准但思路完全一致。5.1 硬件与软件环境建议最低配置内存8GB 以上运行 INT4 量化模型操作系统Windows / macOS / Linux 均可磁盘空间模型文件约 2GB 左右推荐工具llama.cpp 或 Ollama二者都支持 GGUF 格式并内置 OpenAI 兼容接口。如果只有 CPU也能跑。2.6B 模型在 CPU 上生成速度大概是每秒 15 到 30 token取决于设备和线程数。对演示 Agent 来说已经足够。5.2 部署方案一使用 llama.cpp先把 llama.cpp 编译出来# 拉取代码 git clone https://github.com/ggerganov/llama.cpp cd llama.cpp # 编译需要 cmake 和 C 编译器 cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j假设你已经拿到 LFM2.5-2.6B 转换后的 GGUF 文件名字为lfm2.5-2.6b-q4_k_m.gguf可以把模型放到models目录下。启动一个 OpenAI 兼容的本地服务./build/bin/llama-server \ -m models/lfm2.5-2.6b-q4_k_m.gguf \ --host 127.0.0.1 \ --port 8080 \ -c 8192 \ -t 8参数说明-m指定模型文件路径--host和--port服务监听地址和端口-c上下文窗口长度这里设置为 8192-tCPU 推理线程数建议根据 CPU 物理核心数调整。启动成功后日志里会出现类似server is listening on http://127.0.0.1:8080的信息。5.3 部署方案二使用 Ollama如果你更习惯 Ollama 的命令行体验可以这样做。先把 GGUF 文件导入# 1. 安装 ollamamacOS / Linux / Windows curl -fsSL https://ollama.com/install.sh | sh # 2. 创建 Modelfile内容如下 # FROM /path/to/lfm2.5-2.6b-q4_k_m.gguf # TEMPLATE {{ .System }} {{ .Prompt }} # 3. 创建并启动模型 ollama create lfm2.5 -f Modelfile ollama run lfm2.5Ollama 会自动管理模型生命周期并且也提供http://127.0.0.1:11434/v1的 OpenAI 兼容接口。两种方案选一种即可我后面的示例代码都假设接口是兼容的。5.4 验证部署是否成功用 curl 发一个最简单的请求curl http://127.0.0.1:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { model: lfm2.5-2.6b, messages: [ {role: system, content: 你是一个端侧助手。}, {role: user, content: 用一句话介绍你自己。} ] }如果返回一个包含choices字段的 JSON说明部署成功。到这里模型已经能“说话”了但它还不是 Agent。下一步我们把工具调用能力接上。6. 用 LFM2.5-2.6B 搭建一个最小端侧 Agent6.1 Agent 的最小闭环一个端侧 Agent 至少需要四个部分模型推理、工具定义、消息循环、参数校验。我们用一个“设置闹钟”的示例把这条链路跑通。整体流程是这样的用户输入 → 模型判断意图 → 输出工具调用请求 → 代码解析参数 → 执行本地工具 → 工具结果回填给模型 → 模型生成最终回复 → 返回给用户6.2 方法一使用 OpenAI 兼容的 tools 参数新版 llama.cpp 和 Ollama 都支持 OpenAI 风格的tools参数。如果 LFM2.5-2.6B 版本带有命令遵循能力优先用这种方式。# 文件路径agent_demo.py import json from openai import OpenAI # 这里可以切换为 Ollama 的地址 http://127.0.0.1:11434/v1 client OpenAI( base_urlhttp://127.0.0.1:8080/v1, api_keynot-needed, ) tools [ { type: function, function: { name: set_alarm, description: 在设备上设置一个闹钟。, parameters: { type: object, properties: { time: { type: string, description: 闹钟时间24小时制格式为 HH:MM。 }, label: { type: string, description: 闹钟备注例如开会、起床。 } }, required: [time] } } } ] def set_alarm(time: str, label: str ) - dict: # 实际项目中在这里调用系统的闹钟 API print(f[exec] 设置闹钟 {label or 未命名} 在 {time}) return {status: ok, time: time, label: label} messages [ { role: system, content: 你是运行在用户设备上的端侧助手。 你只能调用提供的工具完成任务调用工具时参数必须符合 JSON 格式。 }, {role: user, content: 明天早上九点提醒我开周会}, ] for _ in range(5): # 最多循环 5 次防止无限调用 resp client.chat.completions.create( modellfm2.5-2.6b, messagesmessages, toolstools, temperature0.2, ) msg resp.choices[0].message # 没有工具调用直接输出最终回复 if not msg.tool_calls: print(最终回复:, msg.content) break # 有工具调用把模型的消息追加进上下文 messages.append(msg) for tc in msg.tool_calls: print(模型请求调用工具:, tc.function.name, tc.function.arguments) try: args json.loads(tc.function.arguments) except json.JSONDecodeError: args {} # 执行本地工具 result set_alarm(**args) # 把工具结果回填给模型 messages.append({ role: tool, tool_call_id: tc.id, content: json.dumps(result, ensure_asciiFalse) }) print(messages 长度:, len(messages))这段代码有几个关键点messages会持续累积保证模型能看到“用户请求 → 工具调用 → 工具结果”的完整轨迹tool_calls是 OpenAI 兼容接口的标准返回字段本地推理框架会解析模型的输出工具执行必须放在真实环境里做校验不能直接把模型给的参数当最终值。6.3 方法二提示词约束 JSON 输出如果 LFM2.5-2.6B 对tools参数的支持不稳定可以退回到提示词约束。它的原理是把工具描述直接写进系统提示词并要求模型只输出指定格式的 JSON。# 文件路径agent_demo_fallback.py import json TOOL_SCHEMA 你可以调用以下工具 - set_alarm(parameters: {time: HH:MM, label: string}) 注意 1. 你需要调用工具时只输出 JSON不允许输出其他文字。 2. JSON 格式必须为 {action: set_alarm, params: {...}} 3. 不需要调用工具时输出 {action: reply, params: {content: 你的回答}} user_input 下午三点半提醒我取快递 prompt TOOL_SCHEMA \n用户请求 user_input # 请求模型并拿到原始输出 # 这里假设 resp_text 是模型生成的文本 # resp_text client.chat.completions.create(...).choices[0].message.content # 假设我们已经拿到了模型输出 # resp_text {action: set_alarm, params: {time: 15:30, label: 取快递}}这段代码只是示意重点在于你需要在代码层把模型输出作为 JSON 解析再做参数校验。如果解析失败可以重试一次要求模型“只输出 JSON”。这种方法对参数非常小、没有专门微调过 Function Calling 的模型更实用。6.4 运行方式python agent_demo.py预期你会看到类似下面的运行日志模型请求调用工具: set_alarm {time: 09:00, label: 开周会} [exec] 设置闹钟 开周会 在 09:00 最终回复: 好的已经帮你设定明天早上九点的闹钟提醒开周会。如果模型没有正确触发工具调用不要急着怪模型先检查系统提示词是否足够明确再检查服务是否真的支持tools参数。7. 运行结果与效果验证Agent 和普通问答不一样不能只看“回复是否通顺”还要看“工具是否被正确调用”。建议从五个角度验证。7.1 工具调用是否触发这是第一步。输入“帮我定一个明天早上八点的闹钟”观察日志里是否出现模型请求调用工具: set_alarm。如果没有触发先排除三种情况模型服务没有启用 tools 支持系统提示词里没有强调“必须调用工具”模型本身不具备命令遵循能力需要切换为 JSON 提示词方案。7.2 参数是否正确触发工具调用后重点看参数解析。比如用户说“八点”设备是 24 小时制模型应该输出time: 08:00而不是time: 8点。出现后者说明参数描述还不够明确工具描述里要写清楚格式样例。7.3 最终回复是否自然工具执行完毕后模型需要根据工具返回值生成自然语言回复。如果模型把工具返回的原始 JSON 直接读给用户比如“工具执行结果为 status ok”说明系统的提示词还需要加一句“根据工具结果生成简洁的回复”。7.4 多轮对话是否连续再测试一个更复杂的场景用户帮我设一个明早八点的闹钟 用户不对改成八点半理想情况下第一轮触发set_alarm并记录第二轮模型应该知道是“修改已经设置的闹钟”。如果 LFM2.5-2.6B 在第二轮没有调用工具需要检查messages是否完整传入了历史记录。7.5 失败时先看哪里一旦运行结果不符合预期建议按这个顺序排查看模型的原始响应确认是输出格式错误还是根本没有触发工具调用看llama-server日志确认请求是否到达、上下文是否被截断看代码抛出的异常是 JSON 解析失败还是参数校验失败做一个最小测试只用系统提示词不加工具定义看模型能否正确理解意图。记住一个原则小模型的 Agent 效果问题八成出在“提示词不够具体”和“没有格式兜底”上。先把这两件事做好再去怀疑模型能力。8. 常见问题与排查思路这里整理我在端侧 Agent 落地过程中最常遇到的问题直接列成表格方便查阅。问题现象可能原因排查方式解决方案启动时内存不足模型未量化或量化等级过高查看模型文件大小和进程内存占用改用 q4_k_m 或更低比特量化响应延迟过高CPU 线程数不足上下文太长观察 prompt eval 和 token gen 速度增加线程数减小-c开启 GPU 加速工具调用一直不触发模型未有效支持 tools 参数打印原始响应确认是否包含tool_calls字段改用提示词 JSON 输出方案或替换指令遵循更强的模型模型输出 JSON 解析失败输出含多余文字或格式不规范检查错误日志中的模型原始文本增加重试逻辑再次要求“只输出 JSON”中文夹杂英文或重复采样参数不合理词表适配一般观察连续多个输出样例降低 temperature提高 repetition_penalty多轮对话后行为混乱上下文窗口被截断记忆丢失检查messages长度和截断逻辑裁剪历史保留 system、最近轮次和关键参数工具执行了但回复不自然提示词没有要求根据工具结果生成回复查看最终回复示例系统提示词增加“根据工具结果生成简洁自然回复”排查工具调用问题时最有效的办法不是看最终输出而是打印完整对话轨迹。把messages里每一轮的role、content、tool_calls全部打出来问题往往一眼就能看出来。9. 最佳实践、回归评测与后续学习方向9.1 量化策略要分场景如果设备内存充足优先试 INT8 或较低压缩比的 INT4测一下准确率能不能接受。如果发现工具调用成功率明显下降就不要追求极限压缩。更稳妥的做法是内存紧张的设备用 INT4开发调试时用 FP16 或 INT8评测通过后再切换到更小体积的版本。9.2 系统提示词要保持精简端侧模型对长提示词的理解能力有限。系统提示词建议控制在 200 到 500 字内工具描述写清“工具名、参数类型、格式样例、何时使用”。把最重要的“必须输出 JSON、参数必须合规”放在提示词开头比放在结尾更有效。9.3 工具列表宁少勿多每次调用模型时所有工具描述都会占据上下文空间。工具越多模型越容易混淆。合理做法是先根据用户意图做一次粗分类只把相关工具传给模型。比如识别到是闹钟相关请求时再把set_alarm、list_alarms等工具传给模型。9.4 必须设计降级链路端侧模型不一定能处理所有请求。生产环境务必设计三层降级第一层端侧模型直接完成第二层端侧模型识别到复杂任务后把脱敏后的摘要发给云端第三层用户主动请求强大模型时明确提示数据会离开设备。这个降级逻辑既保护体验也保护隐私。9.5 工具执行要做校验和授权模型输出的time参数可能是 “25:00”也可能是个空字符串。工具执行前必须有一层参数校验例如时间格式必须匹配^\d{2}:\d{2}$且小时在 0 到 23 之间。涉及发送消息、删除文件、访问通讯录等敏感操作必须经过用户确认不能由模型静默执行。9.6 建立回归评测集端侧模型迭代很快每次换模型文件、改提示词、调整量化等级都可能影响 Agent 行为。建议准备一个 20 到 50 条的小规模评测集覆盖不同意图的指令带错误参数或缺失参数的指令多轮修改指令需要拒绝执行的请求。每条评测都记录“工具是否触发、参数是否正确、最终回复是否合格”。小模型效果不稳定但通过回归能稳定住下限。9.7 下一步学习方向如果你准备在真实产品中落地端侧 Agent下面这几个方向值得继续深入模型微调用少量工具调用数据对 LFM2.5-2.6B 做 LoRA 微调是提高工具调用稳定性最直接的办法端侧推理优化研究 KV Cache 量化、Prefill 加速、算子融合把推理延迟继续压下去Agent 记忆管理实现本地向量数据库 摘要压缩让 Agent 有长期记忆设备端框架集成学习如何在 Android、iOS 或嵌入式 Linux 上调用 LFM 模型并与系统 API 打通。端侧 Agent 这个方向最有趣的地方在于它把大模型的能力从“云端 API”变成了“设备本地能力”。LFM2.5-2.6B 的价值不是替代云端大模型而是让 Agent 真正成为用户设备上的基础设施。如果你正在做端侧 AI 产品建议从今天的最小示例开始先跑通一条工具调用链路再逐步扩成完整的 Agent 系统。
LFM2.5-2.6B端侧Agent实战：部署与工具调用闭环构建
很多开发者对端侧小模型的印象还停留在“能跑个问答、做个文本补全”的阶段。直到真正开始做 Agent 时才发现云端大模型虽然能力强但每条请求要上传数据、每轮对话要等网络、每个月还要看账单。于是问题自然就变成了能不能让 Agent 直接跑在用户设备上不上云、不等待、不烧接口费这就是 On-Device Agents 的切入点也是 LFM2.5-2.6B 这类模型值得关注的原因。从命名和参数规模看它是一个约 26 亿参数的语言基础模型目标不是“陪你聊天”而是“帮你干活”识别意图、调用工具、完成设备上的具体操作。我的判断是在端侧 Agent 这个方向上2.5B 到 2.6B 参数并不是“凑合的妥协方案”而是一个在算力、内存、体验和效果之间更容易取得平衡的甜点区间。这篇文章不会堆砌一堆我没有实测过的 benchmark 数字而是想把几件事讲透什么是端侧 Agent为什么小模型做 Agent 比做聊天更难如何把 LFM2.5-2.6B 部署到本地以及怎么搭建一个最小可用的工具调用闭环。读完你可以直接照着搭一个端侧 Agent 雏形并且避开那些最容易踩的坑。1. 这篇文章真正要解决的问题先说一个常见场景。你做了一个 AI 助手功能包括查天气、定闹钟、提醒日程。最开始接入的是云端大模型效果确实不错但问题很快就出现了成本不可控。每个用户每天都在发起多轮对话每轮对话都要把历史上下文重新发送一遍token 消耗量远高于“聊天”场景。延迟不稳定。Agent 的决策链路长模型要“思考、决策、调用工具、再生成回复”网络一波动用户体感就是卡片转圈。隐私压力大。日程、通讯录、位置这些本来就在端侧的数据因为 Agent 要理解上下文被迫打包上传到云端。这三个问题单拎出来都不致命一旦组合在一起就几乎决定了“云端 Agent”很难成为默认形态。产品只能把它当成一个高级功能而不是系统级入口。LFM2.5-2.6B 这类模型要解决的正是这三件事推理在本地完成数据不出设备延迟只取决于硬件没有服务端账单。当然26 亿参数换来不了 70B 模型的复杂推理能力但它能覆盖大量“低频但高频使用”的 Device Agent 任务比如设置提醒、控制智能家居、读取屏幕信息、填表单、管理文件。如果你属于下面任何一类开发者这篇文章都值得认真看移动端或 PC 端应用开发者想给应用加入端侧 AI Agent 能力物联网和边缘设备开发者设备无法稳定接入云端但又需要智能交互隐私敏感场景的从业者比如医疗、金融、企业办公数据不能出本地被云端 Agent 成本困扰的产品负责人想验证“端云混合”方案是否可行。核心结论先放这里LFM2.5-2.6B 这类模型的价值不在于单点能力比云端大模型强而在于它把“Agent 功能”从云端中心化部署变回了产品本地能力的一部分。2. 端侧 Agent 的核心概念与 LFM 模型的定位2.1 什么是 On-Device AgentAgent智能体在这里指的不是一个聊天框而是一个能自主完成多步任务的程序。它的典型结构是理解用户意图规划执行步骤调用外部工具如闹钟、日历、系统 API根据工具返回结果继续决策最终给用户回复。On-Device 指的是整个推理和决策过程发生在用户设备上。设备可以是手机、PC、平板、车载系统、智能音箱或机器人。与云端 Agent 相比它最大的区别是模型权重在本地工具调用也在本地用户数据不需要离开设备。2.2 LFM 是什么LFM 是 Language Foundation Model 的缩写即语言基础模型。基础模型意味着它未经特定下游任务深度定制是一个通用的文本理解与生成底座。开发者拿到之后可以基于它做指令微调、量化部署或者直接把它接入应用逻辑。LFM2.5-2.6B 从命名上看指的是版本号为 2.5、参数规模在 2.6B约 26 亿参数的模型。这一类模型和流行的“小参数大能力”路线一致参数不多但架构、训练数据和指令遵循能力都在向小型化做针对性优化目的就是能在端侧高效运行。2.3 2.6B 参数意味着什么参数规模直接决定硬件占用。我们粗略估算一下FP16 半精度下2.6B 参数权重约占 5.2GBINT8 量化下约占 2.6GBINT4 量化下约占 1.3GB 到 1.6GB再加上 KV Cache、临时激活值和推理开销整体内存占用会再高一些。换算成实际体验一台 8GB 内存的普通电脑加载 INT4 量化后的 LFM2.5-2.6B 模型可以比较流畅地跑 CPU 推理。如果是手机旗舰芯片配合端侧推理框架也能实现每秒几十 token 的生成速度。这个量级正好卡在“手机跑得动”和“效果还够用”之间。对比 7B 模型INT4 量化后权重约 3.5GB 到 4GB对手机内存压力明显更大CPU 推理速度通常只有 2.6B 的一半左右。对比 70B 级别的云端模型它完全无法端侧部署只能走网络请求。所以 2.5B 到 2.6B 这个区间是兼顾能力、速度与部署成本的合理选择。2.4 LFM 与云端大模型的分工一个成熟的端云混合 Agent 架构往往是这样的用户请求 │ ▼ 端侧小模型LFM2.5-2.6B │ ├── 简单的本地任务直接调用工具完成 ├── 隐私敏感任务本地下文理解 本地工具执行 └── 复杂推理任务做意图压缩 路由到云端大模型端侧模型负责“快”和“隐私”云端模型负责“强”和“博学”。两者不是替代关系而是共存关系。端侧模型能跑通 70% 的常见请求就已经能大幅降低成本和延迟这是 On-Device Agent 商业上成立的前提。3. 为什么 On-Device Agent 值得关注很多人会问既然端侧模型能力有限为什么不都放云端要回答这个问题不能只看模型能力要看整个产品形态。下面几个维度对实际项目的影响是决定性的。3.1 隐私与数据本地化Agent 类应用和普通问答应用有一个本质差别Agent 需要做具体操作必然涉及设备上的私有数据。日程、通讯录、位置、输入习惯、屏幕内容这些数据一旦上传云端对用户来说就是风险。端侧 Agent 把“理解”和“执行”放在本地数据没有机会离开设备。即使未来需要云端协助也只会发送去除隐私后的结构化摘要而不是原始上下文。这会让产品在隐私合规上的压力小很多。3.2 延迟体验的提升云端 Agent 的一个典型卡顿点是“多轮工具调用”模型每调用一次工具就要经历一次完整的通信往返。如果链路是“端到云 → 云到工具服务 → 云再生成 → 回传”单次工具调用的延迟可能高达一到三秒甚至更久。端侧 Agent 的推理在本地工具也在本地延迟主要取决于模型推理速度和工具本身执行速度。在硬件合理的设备上一次简单意图识别加工具调用可以控制在几百毫秒到一秒以内。这种体感差异是用户能否把语音助手当成日常功能的关键。3.3 离线与弱网可用地铁、电梯、地下室、偏远郊外网络环境永远不稳定。云端 Agent 在弱网下几乎不可用而端侧 Agent 可以完整运行。这个能力对特殊行业尤其重要野外巡检、应急通信、车载导航、医疗便携设备网络不是“偶尔断”而是“本来就没有”。3.4 成本结构的变化云端 Agent 的成本模型是“按 token 计费”用户对话越多Agent 调用工具越频繁成本越高而且不可控。端侧 Agent 是一次性部署模型推理消耗的是设备本身的算力和电量。对 C 端产品来说这意味着每个用户的新增边际成本趋近于零。对 B 端产品来说可以把昂贵的 GPU 资源集中到复杂推理任务上而不是浪费在“今天天气怎么样”这种高频低难度请求上。3.5 长期记忆与个性化端侧 Agent 还有一个容易被忽视的优势记忆可以长期存放在本地。云端模型受限于上下文窗口和隐私策略很难为每个用户维护一份完整的个人记忆库。而端侧 Agent 可以把用户偏好、历史操作、常用设置写入本地向量数据库在每个会话启动时快速加载。这意味着什么意味着 Agent 可以越用越懂你而且不需要上传任何隐私数据。这个能力对需要高粘性的应用来说商业价值非常大。4. 端侧 Agent 的技术难点与能力边界如果说“部署一个小模型”是体力活那么“让小模型稳定做 Agent”才是真正的技术活。这里有几个关键难点。4.1 工具调用格式的稳定性云端大模型经过大量指令微调输出 JSON 或调用函数通常很准。而端侧小模型参数量少指令遵循能力弱经常出现以下问题不调用工具直接把工具结果“想象”出来参数名写错多传或少传字段把工具说明当成了普通文本回复。应对方法有两种一是模型本身微调过 Function Calling二是在推理层用提示词强制输出 JSON再靠代码解析。LFM2.5-2.6B 如果具备命令遵循能力可以优先走 OpenAI 兼容接口的tools参数如果效果不稳定就必须做一层格式兜底。4.2 多轮任务的上下文管理Agent 场景下用户往往不会一次说完整需求。例如“帮我把明天早上的闹钟设到八点……不对改成八点半。”这种多轮语境对小模型是一个大考验。模型不仅要理解指令还要能判断“改”指的是改哪个闹钟、从几点改到几点。端侧模型的上下文窗口通常有限可能是 4K、8K 或 16K。如果每轮对话都把完整历史塞进去很快就会撑爆窗口。更合理的方式是在端侧做记忆裁剪只保留关键信息比如当前任务目标、已经确定的参数、最近两轮对话。必要时离线生成摘要把长历史压缩成结构化记忆。4.3 系统提示词的长度控制端侧小模型对长提示词非常敏感。系统提示词越长模型越容易混淆重点生成速度也会下降。因此给端侧 Agent 写系统提示词要尽量精简明确角色列出可用工具和参数规定输出格式规定不要做什么。千万不要把云端模型那套几千字的“角色设定 样例 few-shot”直接搬到端侧效果会明显变差。4.4 推理速度与设备续航端侧 Agent 虽然省了网费和云费但消耗的是设备电量和计算资源。2.6B 模型在 CPU 上推理时如果线程设置不合理可能造成设备发烫、掉电加快。在真实产品中必须考虑使用 4bit 或更低量化开启部分 GPU 加速限制并发请求数在低电量时主动降级为云端方案。4.5 幻觉与安全边界模型越小幻觉不一定越严重但输出稳定性会差一些。尤其在 Agent 场景模型的错误输出可能直接触发系统操作。比如把闹钟设在“25:00”或者把文件命名成乱码。因此端侧 Agent 必须在执行工具前增加“参数校验层”不能完全信任模型输出。下面这张表能帮你快速理解云端大模型与端侧小模型在 Agent 任务上的差异维度云端大模型LFM2.5-2.6B 等端侧模型推理能力强中低偏简单任务工具调用稳定性高一般需要格式兜底延迟受网络影响通常较高本地推理更快隐私数据需上云数据不出设备成本按 token 计费一次性部署成本可离线使用否是上下文窗口大通常较小需要裁剪适合任务复杂推理、知识问答设备操作、隐私敏感短任务这个表格背后有一个清晰的判断端侧模型不是“穷人版的云端模型”而是为特定场景重新设计的另一种 Agent 形态。理解这一点后续做架构选型才不会选错方向。5. LFM2.5-2.6B 环境准备与基础部署这一节我们把 LFM2.5-2.6B 跑起来。文章以通用流程演示具体模型文件、推理框架版本请以你实际拿到的东西为准但思路完全一致。5.1 硬件与软件环境建议最低配置内存8GB 以上运行 INT4 量化模型操作系统Windows / macOS / Linux 均可磁盘空间模型文件约 2GB 左右推荐工具llama.cpp 或 Ollama二者都支持 GGUF 格式并内置 OpenAI 兼容接口。如果只有 CPU也能跑。2.6B 模型在 CPU 上生成速度大概是每秒 15 到 30 token取决于设备和线程数。对演示 Agent 来说已经足够。5.2 部署方案一使用 llama.cpp先把 llama.cpp 编译出来# 拉取代码 git clone https://github.com/ggerganov/llama.cpp cd llama.cpp # 编译需要 cmake 和 C 编译器 cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build --config Release -j假设你已经拿到 LFM2.5-2.6B 转换后的 GGUF 文件名字为lfm2.5-2.6b-q4_k_m.gguf可以把模型放到models目录下。启动一个 OpenAI 兼容的本地服务./build/bin/llama-server \ -m models/lfm2.5-2.6b-q4_k_m.gguf \ --host 127.0.0.1 \ --port 8080 \ -c 8192 \ -t 8参数说明-m指定模型文件路径--host和--port服务监听地址和端口-c上下文窗口长度这里设置为 8192-tCPU 推理线程数建议根据 CPU 物理核心数调整。启动成功后日志里会出现类似server is listening on http://127.0.0.1:8080的信息。5.3 部署方案二使用 Ollama如果你更习惯 Ollama 的命令行体验可以这样做。先把 GGUF 文件导入# 1. 安装 ollamamacOS / Linux / Windows curl -fsSL https://ollama.com/install.sh | sh # 2. 创建 Modelfile内容如下 # FROM /path/to/lfm2.5-2.6b-q4_k_m.gguf # TEMPLATE {{ .System }} {{ .Prompt }} # 3. 创建并启动模型 ollama create lfm2.5 -f Modelfile ollama run lfm2.5Ollama 会自动管理模型生命周期并且也提供http://127.0.0.1:11434/v1的 OpenAI 兼容接口。两种方案选一种即可我后面的示例代码都假设接口是兼容的。5.4 验证部署是否成功用 curl 发一个最简单的请求curl http://127.0.0.1:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { model: lfm2.5-2.6b, messages: [ {role: system, content: 你是一个端侧助手。}, {role: user, content: 用一句话介绍你自己。} ] }如果返回一个包含choices字段的 JSON说明部署成功。到这里模型已经能“说话”了但它还不是 Agent。下一步我们把工具调用能力接上。6. 用 LFM2.5-2.6B 搭建一个最小端侧 Agent6.1 Agent 的最小闭环一个端侧 Agent 至少需要四个部分模型推理、工具定义、消息循环、参数校验。我们用一个“设置闹钟”的示例把这条链路跑通。整体流程是这样的用户输入 → 模型判断意图 → 输出工具调用请求 → 代码解析参数 → 执行本地工具 → 工具结果回填给模型 → 模型生成最终回复 → 返回给用户6.2 方法一使用 OpenAI 兼容的 tools 参数新版 llama.cpp 和 Ollama 都支持 OpenAI 风格的tools参数。如果 LFM2.5-2.6B 版本带有命令遵循能力优先用这种方式。# 文件路径agent_demo.py import json from openai import OpenAI # 这里可以切换为 Ollama 的地址 http://127.0.0.1:11434/v1 client OpenAI( base_urlhttp://127.0.0.1:8080/v1, api_keynot-needed, ) tools [ { type: function, function: { name: set_alarm, description: 在设备上设置一个闹钟。, parameters: { type: object, properties: { time: { type: string, description: 闹钟时间24小时制格式为 HH:MM。 }, label: { type: string, description: 闹钟备注例如开会、起床。 } }, required: [time] } } } ] def set_alarm(time: str, label: str ) - dict: # 实际项目中在这里调用系统的闹钟 API print(f[exec] 设置闹钟 {label or 未命名} 在 {time}) return {status: ok, time: time, label: label} messages [ { role: system, content: 你是运行在用户设备上的端侧助手。 你只能调用提供的工具完成任务调用工具时参数必须符合 JSON 格式。 }, {role: user, content: 明天早上九点提醒我开周会}, ] for _ in range(5): # 最多循环 5 次防止无限调用 resp client.chat.completions.create( modellfm2.5-2.6b, messagesmessages, toolstools, temperature0.2, ) msg resp.choices[0].message # 没有工具调用直接输出最终回复 if not msg.tool_calls: print(最终回复:, msg.content) break # 有工具调用把模型的消息追加进上下文 messages.append(msg) for tc in msg.tool_calls: print(模型请求调用工具:, tc.function.name, tc.function.arguments) try: args json.loads(tc.function.arguments) except json.JSONDecodeError: args {} # 执行本地工具 result set_alarm(**args) # 把工具结果回填给模型 messages.append({ role: tool, tool_call_id: tc.id, content: json.dumps(result, ensure_asciiFalse) }) print(messages 长度:, len(messages))这段代码有几个关键点messages会持续累积保证模型能看到“用户请求 → 工具调用 → 工具结果”的完整轨迹tool_calls是 OpenAI 兼容接口的标准返回字段本地推理框架会解析模型的输出工具执行必须放在真实环境里做校验不能直接把模型给的参数当最终值。6.3 方法二提示词约束 JSON 输出如果 LFM2.5-2.6B 对tools参数的支持不稳定可以退回到提示词约束。它的原理是把工具描述直接写进系统提示词并要求模型只输出指定格式的 JSON。# 文件路径agent_demo_fallback.py import json TOOL_SCHEMA 你可以调用以下工具 - set_alarm(parameters: {time: HH:MM, label: string}) 注意 1. 你需要调用工具时只输出 JSON不允许输出其他文字。 2. JSON 格式必须为 {action: set_alarm, params: {...}} 3. 不需要调用工具时输出 {action: reply, params: {content: 你的回答}} user_input 下午三点半提醒我取快递 prompt TOOL_SCHEMA \n用户请求 user_input # 请求模型并拿到原始输出 # 这里假设 resp_text 是模型生成的文本 # resp_text client.chat.completions.create(...).choices[0].message.content # 假设我们已经拿到了模型输出 # resp_text {action: set_alarm, params: {time: 15:30, label: 取快递}}这段代码只是示意重点在于你需要在代码层把模型输出作为 JSON 解析再做参数校验。如果解析失败可以重试一次要求模型“只输出 JSON”。这种方法对参数非常小、没有专门微调过 Function Calling 的模型更实用。6.4 运行方式python agent_demo.py预期你会看到类似下面的运行日志模型请求调用工具: set_alarm {time: 09:00, label: 开周会} [exec] 设置闹钟 开周会 在 09:00 最终回复: 好的已经帮你设定明天早上九点的闹钟提醒开周会。如果模型没有正确触发工具调用不要急着怪模型先检查系统提示词是否足够明确再检查服务是否真的支持tools参数。7. 运行结果与效果验证Agent 和普通问答不一样不能只看“回复是否通顺”还要看“工具是否被正确调用”。建议从五个角度验证。7.1 工具调用是否触发这是第一步。输入“帮我定一个明天早上八点的闹钟”观察日志里是否出现模型请求调用工具: set_alarm。如果没有触发先排除三种情况模型服务没有启用 tools 支持系统提示词里没有强调“必须调用工具”模型本身不具备命令遵循能力需要切换为 JSON 提示词方案。7.2 参数是否正确触发工具调用后重点看参数解析。比如用户说“八点”设备是 24 小时制模型应该输出time: 08:00而不是time: 8点。出现后者说明参数描述还不够明确工具描述里要写清楚格式样例。7.3 最终回复是否自然工具执行完毕后模型需要根据工具返回值生成自然语言回复。如果模型把工具返回的原始 JSON 直接读给用户比如“工具执行结果为 status ok”说明系统的提示词还需要加一句“根据工具结果生成简洁的回复”。7.4 多轮对话是否连续再测试一个更复杂的场景用户帮我设一个明早八点的闹钟 用户不对改成八点半理想情况下第一轮触发set_alarm并记录第二轮模型应该知道是“修改已经设置的闹钟”。如果 LFM2.5-2.6B 在第二轮没有调用工具需要检查messages是否完整传入了历史记录。7.5 失败时先看哪里一旦运行结果不符合预期建议按这个顺序排查看模型的原始响应确认是输出格式错误还是根本没有触发工具调用看llama-server日志确认请求是否到达、上下文是否被截断看代码抛出的异常是 JSON 解析失败还是参数校验失败做一个最小测试只用系统提示词不加工具定义看模型能否正确理解意图。记住一个原则小模型的 Agent 效果问题八成出在“提示词不够具体”和“没有格式兜底”上。先把这两件事做好再去怀疑模型能力。8. 常见问题与排查思路这里整理我在端侧 Agent 落地过程中最常遇到的问题直接列成表格方便查阅。问题现象可能原因排查方式解决方案启动时内存不足模型未量化或量化等级过高查看模型文件大小和进程内存占用改用 q4_k_m 或更低比特量化响应延迟过高CPU 线程数不足上下文太长观察 prompt eval 和 token gen 速度增加线程数减小-c开启 GPU 加速工具调用一直不触发模型未有效支持 tools 参数打印原始响应确认是否包含tool_calls字段改用提示词 JSON 输出方案或替换指令遵循更强的模型模型输出 JSON 解析失败输出含多余文字或格式不规范检查错误日志中的模型原始文本增加重试逻辑再次要求“只输出 JSON”中文夹杂英文或重复采样参数不合理词表适配一般观察连续多个输出样例降低 temperature提高 repetition_penalty多轮对话后行为混乱上下文窗口被截断记忆丢失检查messages长度和截断逻辑裁剪历史保留 system、最近轮次和关键参数工具执行了但回复不自然提示词没有要求根据工具结果生成回复查看最终回复示例系统提示词增加“根据工具结果生成简洁自然回复”排查工具调用问题时最有效的办法不是看最终输出而是打印完整对话轨迹。把messages里每一轮的role、content、tool_calls全部打出来问题往往一眼就能看出来。9. 最佳实践、回归评测与后续学习方向9.1 量化策略要分场景如果设备内存充足优先试 INT8 或较低压缩比的 INT4测一下准确率能不能接受。如果发现工具调用成功率明显下降就不要追求极限压缩。更稳妥的做法是内存紧张的设备用 INT4开发调试时用 FP16 或 INT8评测通过后再切换到更小体积的版本。9.2 系统提示词要保持精简端侧模型对长提示词的理解能力有限。系统提示词建议控制在 200 到 500 字内工具描述写清“工具名、参数类型、格式样例、何时使用”。把最重要的“必须输出 JSON、参数必须合规”放在提示词开头比放在结尾更有效。9.3 工具列表宁少勿多每次调用模型时所有工具描述都会占据上下文空间。工具越多模型越容易混淆。合理做法是先根据用户意图做一次粗分类只把相关工具传给模型。比如识别到是闹钟相关请求时再把set_alarm、list_alarms等工具传给模型。9.4 必须设计降级链路端侧模型不一定能处理所有请求。生产环境务必设计三层降级第一层端侧模型直接完成第二层端侧模型识别到复杂任务后把脱敏后的摘要发给云端第三层用户主动请求强大模型时明确提示数据会离开设备。这个降级逻辑既保护体验也保护隐私。9.5 工具执行要做校验和授权模型输出的time参数可能是 “25:00”也可能是个空字符串。工具执行前必须有一层参数校验例如时间格式必须匹配^\d{2}:\d{2}$且小时在 0 到 23 之间。涉及发送消息、删除文件、访问通讯录等敏感操作必须经过用户确认不能由模型静默执行。9.6 建立回归评测集端侧模型迭代很快每次换模型文件、改提示词、调整量化等级都可能影响 Agent 行为。建议准备一个 20 到 50 条的小规模评测集覆盖不同意图的指令带错误参数或缺失参数的指令多轮修改指令需要拒绝执行的请求。每条评测都记录“工具是否触发、参数是否正确、最终回复是否合格”。小模型效果不稳定但通过回归能稳定住下限。9.7 下一步学习方向如果你准备在真实产品中落地端侧 Agent下面这几个方向值得继续深入模型微调用少量工具调用数据对 LFM2.5-2.6B 做 LoRA 微调是提高工具调用稳定性最直接的办法端侧推理优化研究 KV Cache 量化、Prefill 加速、算子融合把推理延迟继续压下去Agent 记忆管理实现本地向量数据库 摘要压缩让 Agent 有长期记忆设备端框架集成学习如何在 Android、iOS 或嵌入式 Linux 上调用 LFM 模型并与系统 API 打通。端侧 Agent 这个方向最有趣的地方在于它把大模型的能力从“云端 API”变成了“设备本地能力”。LFM2.5-2.6B 的价值不是替代云端大模型而是让 Agent 真正成为用户设备上的基础设施。如果你正在做端侧 AI 产品建议从今天的最小示例开始先跑通一条工具调用链路再逐步扩成完整的 Agent 系统。