最近关注端侧大模型的人应该都有同感宣传稿很多“能跑模型”和“能用模型”完全是两回事。尤其当目标变成 AI Agent 时难度又从“本地出几段文本”上升到“模型有没有能力完成工具调用、任务拆解和多轮闭环”。这次我们把视线放到 Liquid AI LFM 2.5 这个模型系列上结合手机本地部署的真实约束聊一聊它的架构特点、启动方式、功能边界和性能观察方法。先说结论上的判断LFM 2.5 不是一个单纯刷评测分数的稠密模型系列它在设计上更强调推理成本和部署灵活性官方公开资料里也给过不少面向边缘侧、移动端的部署讨论。配合端侧推理框架这类模型确实有机会在手机上成为“Agent 引擎”而不是云端 API 的中转站。不过也有前提手机的内存容量、NPU 兼容性、同频内存带宽都会直接影响真实体验不是每个版本都适合塞进手机。这篇文章会按一条可验证的路径展开先看 LFM 2.5 的能力规格和部署边界再讲手机端跑 Agent 需要准备什么环境、怎么启动服务然后给出功能测试、接口调用、批量任务、性能观察和问题排查的完整思路。整个过程不粉饰具体跑分也不会告诉你“装上就好”而是把判断方法交给你——同一套方法换到电脑、开发板、小主机上同样适用。如果你关心的是“这个 Agent 能不能在本地低成本跑起来”“工具调用稳不稳”“能不能接到自动化流程里”这篇文章可以直接往下看。1. 核心能力速览先说清楚一个容易混淆的点Liquid AI LFM 2.5 是模型系列不是某一个固定文件。实际部署时还要区分 Dense 版本和 MoE 版本、原始权重和量化格式不同规格在手机上的可行性差异很大。下面的表格来自公开资料与常规部署经验具体数值需要以你实际拉取到的模型文件和手机配置为准。能力项说明项目类型端侧可部署的大语言模型系列面向 Agent / 对话 / 多模态场景模型系列Liquid AI LFM 2.5包含不同参数量与稀疏专家版本架构关键词非完全传统 Transformer融合状态空间 / 线性注意力 / 专家路由等设计典型部署设备手机、平板、ARM 小主机、带独显的电脑均可按规格选择启动方式命令行服务、MobileLLM / llama.cpp / MLC 等框架封装、App 内集成是否支持 CPU支持手机端通常先跑 CPU再看 NPU / GPU 加速显存 / 内存需求需按版本与上下文长度重新测试不能一概而论是否支持 API通过本地服务封装后可提供类似 OpenAI 的接口是否支持批量任务可以通过脚本循环调用接口或队列化任务实现适合场景隐私敏感数据处理、离线工具型 Agent、端侧自动化的最后一跳对于手机端来说这条链路里最重要的不是“模型有多少参数”而是“实际激活多少参数、权重文件多大、长上下文时内存怎么涨”。从公开技术资料看LFM 2.5 这类含稀疏专家设计的模型让不用的专家权重不参与计算这对端侧推理是友好的理论上可以做到“总参数量大但单次推理的低活跃参数少”。如果换到传统 Dense Transformer 模型同样跑 70B 是不可能的但在 MoE 路线的模型上它有概率被压到手机能接受的范围。不过这里必须提醒一句手机上能跑的模型能力深度和云端完整版一定有差距尤其工具调用稳定性、长上下文记忆都会打折扣。把“本地能跑”理解成“云端托管能力完全复制”是端侧 Agent 最大的预期误区。2. 适用场景与使用边界2.1 适合谁手机本地跑 Agent第一类用户是隐私敏感场景的人。比如内部会议记录整理、个人健康数据简单分析、出差环境下的本地知识库检索这些内容并不适合无差别上传到公共 API。模型放在本机原始素材不出设备至少能把“数据流向哪家服务商”这个问题控制住。第二类是自动化折腾党。手机同时扮演 Agent 推理端和任务调度端搭配 Termux、Tasker 或自建 Python 脚本可以做一些定时简报、本地 RSS 摘要、离线草稿生成。这类场景单次生成量不算大手机端跑几分钟可以接受。第三类是离线环境开发者。在没有稳定外部网络的机房、工地、车载设备上用一块 Android 开发板或旧手机充当 Agent 推理服务通过局域网 HTTP 接口给周边设备提供文本生成能力这在工业运维和边缘计算场景里真实存在。2.2 不适合什么不适合高并发在线服务也不适合质量要求极高的长文本创作。手机内存带宽有限单次请求往往要占用很大一部分内存带宽多个请求同时进来模型推理速度会掉得很明显。也不适合做完整的多模态 Agent 重负载流水线。如果 Agent 每一轮都要“图像输入 大段视觉 token 高分辨率图片 复杂工具调用”手机端非常容易触发内存压力要么进程被杀要么响应延迟到无法使用。2.3 使用边界本地 Agent 如果涉及人脸、声音、照片、文档等敏感素材部署和使用时必须明确授权来源。公司内部数据要先做脱敏个人数据要评估泄露风险模型输出要人工复核。模型文件本身如果来自第三方转换渠道下载后建议校验哈希检查来源可信度。商用场景还要额外确认模型许可证是否允许不能只看“开源模型”四个字就拿来打包卖服务。3. 手机本地部署环境准备3.1 操作系统与处理器工程化测试建议优先使用 Android 设备原因不是 iOS 不能跑而是 Android 侧的工具链更完整Termux 可安装 Linux 用户态llama.cpp 等推理项目对 Android 的构建支持也更早。处理器优先选支持 armv8.2a 以上的型号较新的骁龙、天玑、麒麟芯片都满足更老的 armv8.0 芯片也能编译跑但部分算子优化会用不上。系统里要在“开发者选项”里打开 USB 调试同时确认设备剩余存储至少超过模型文件体积的两倍。比如模型量化文件是 8GB那么设备剩余空间建议不低于 16GB因为转换、拷贝、运行时临时文件都会占用空间。3.2 编译器与依赖如果方案走 llama.cpp需要准备 Android NDK 或直接在 Termux 里使用 clang。更简单的方式是下载社区预编译的 Termux 包再安装构建工具pkg update pkg upgrade pkg install git cmake ninja python clang如果方案走 MLC-LLM需要一台电脑端完成模型转换与 Android 打包手机端不作为构建机只作为运行设备。MLC 的优点是 TVM 编译优化较激进缺点是初次配置重Android 工程构建步骤繁琐。3.3 模型文件来源与格式LFM 2.5 原始权重需要从官方渠道获取手机端一般不会直接读 safetensors 原始文件而是转成 GGUF 或 MLC 专属格式。转换动作可以在 x86 Linux 电脑上用 llama.cpp 的转换脚本完成也可以在手机 Termux 里执行但后者慢很多。模型转换的核心是把 Hugging Face 权重目录转换为单文件 GGUF# 通用模板实际脚本名与参数以 llama.cpp 当前版本为准 python convert_hf_to_gguf.py ./model_dir \ --outfile ./model_q4_k_m.gguf \ --outtype q4_k_m转换完成后把model_q4_k_m.gguf复制到手机存储目录例如/sdcard/Models/lfm2.5/。注意路径不要带空格避免后续脚本解析出错。3.4 磁盘与端口手机端部署建议把模型放在外部存储或独立数据分区不要塞进 App 私有目录再频繁读写。模型文件一旦放好不要随意改名。如果后续要起 HTTP 服务还应该确认一个可用端口常见本地服务用 8080、8000、7860但不同框架默认端口不同冲突时用netstat -tlnp检查占用。4. 安装部署与启动方式4.1 方式一Termux llama.cpp手机装好 Termux 后用 git 拉取最新源码重新编译并启用 Vulkan 后端足够跑通大部分脚本如果你的设备兼容性一般先关闭 GPU 加速用纯 CPU 版验证链路。git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DLLAMA_CURLON -DGGML_VULKANON cmake --build . -j4编译完成后可以通过命令行确认模型是否正常加载./llama-cli -m /sdcard/Models/lfm2.5/model_q4_k_m.gguf \ -p 你是一个本地 Agent先输出当前任务拆解 \ -n 256能正常打印回答说明模型权重、分词器和基础调用链路没问题。4.2 方式二PC 端 MLCL-LLM 打包MLC 路线更适合做独立 App需要电脑上预先装好 Python 3.10 以上版本安装mlc-llm与mlc-ai包再使用它的 Android 打包命令。最后产出的是 APK模型文件可以打进 APK 里也可以首次启动时从手机存储引导导入。# 通用模板特定参数需按 MLC-LLM 项目文档调整 mlc_llm package --model ./model_dir \ --target android \ --output ./distAPK 生成后可以用 adb 安装adb install -r ./dist/app-debug.apkMLC 方案的好处是能利用 TVM 做 layer fusion在部分芯片上的提速明显坏处是调试成本更高如果模型结构较新需要等待 MLC 社区适配。4.3 启动为本地 HTTP 服务把模型跑成 HTTP 服务是接 Agent 的关键一步。手机端不再直接和模型终端交互而是由 Python 脚本或 App 调用 HTTP 接口完成多轮对话、工具调用和批量任务。以 llama.cpp 内置的 server 为例./llama-server -m /sdcard/Models/lfm2.5/model_q4_k_m.gguf \ --host 0.0.0.0 \ --port 8080 \ --ctx-size 4096 \ -n 512手机启动服务后不要立刻锁屏部分系统锁屏会杀掉后台进程。验证服务是否起来可以在同一局域网电脑上执行curl http://手机IP:8080/v1/models能返回模型列表说明服务已经就绪可以把请求地址作为 Agent 的本地大模型 API。4.4 初始化检查清单启动后优先检查四个东西日志有没有报显存或内存不足加载模型的耗时是否在可接受范围第一次输入生成是否明显延迟局域网端口能否从外部访问。任何一步失败都先别继续接入 Agent先用最短 prompt 排除基本问题。5. 功能测试与效果验证5.1 基础对话能力验证 Agent 之前先做基础对话。输入一个没有指令格式的普通问题例如“请用三句话说明什么是函数调用”。观察模型是否理解中文指令、输出结构和标点是否异常、是否出现重复循环。如果基础对话都在乱说后面工具调用基本不会稳。5.2 Agent 工具调用测试Agent 的核心不是聊天而是触发工具。可以先设计一个假想工具查询天气。要求模型输出指定 JSON 结构比如必须包含action和action_input字段。测试提示词你是一个智能助手可以调用下面的工具 - name: weather description: 查询指定城市的天气 parameters: {city: string} 用户问北京今天需要带伞吗 请先决定是否调用工具。如果调用输出 JSON{action: weather, action_input: {city: 北京}} 如果不需要调用直接给出自然语言答案。判断成功的标准是模型根据用户意图正确输出了weather调用而不是生成一段带有解释的文字或者直接编造天气。如果模型总是把工具名和参数写成文本而非 JSON需要检查量化精度是否过低、system prompt 是否过长、上下文窗口是否被截断。5.3 多轮记忆与上下文约束真实 Agent 场景最少需要三轮对话记忆。测试时给模型连续三段指令第一轮让模型记住一个临时值例如“今天会议主题是端侧推理优化”。第二轮插入无关问题干扰上下文。第三轮要求模型回答“会议主题是什么”。模型如果正确回答且没有把第二轮内容混淆进来说明上下文管理可用。如果记忆丢失最常见原因是手机端本地服务把ctx-size设置过短历史消息超出窗口后被截断。如果ctx-size设置得很大但内存不够模型加载后可能中途被杀这里需要在长记忆和稳定性之间做取舍。5.4 批量文本生成批量任务的输入文件可以做成 JSONL一行一个请求。下面是一个 Python 测试脚本示例import json import requests input_path tasks.jsonl url http://127.0.0.1:8080/v1/chat/completions with open(input_path, r, encodingutf-8) as f: for line in f: task json.loads(line) payload { model: lfm2.5, messages: [ {role: system, content: 你是本地 Agent只做原文改写。}, {role: user, content: task[text]} ], temperature: 0.3, max_tokens: 256 } try: resp requests.post(url, jsonpayload, timeout180) result resp.json() print(task[id], result[choices][0][message][content]) except Exception as e: print(failed, task[id], e)批量任务的常见坑是中途某一条文本长度超限导致整个进程卡住。稳妥做法是给每条请求加独立的timeout并且把单条输出长度上限调低一点。跑完后再做抽样复核避免模型把格式改错。5.5 失败判断标准凡是出现以下现象都说明当前配置不适合直接进入生产 模型加载后第一次推理耗时超过数十秒、输出中途中断且日志出现 OOM、多轮轮次超过五次后响应质量明显下降、工具调用 JSON 频繁出现字段缺失或转义错误。遇到这些先不要怀疑模型能力先检查设备剩余内存、进程是否被系统回收、上下文窗口设置、服务端日志报错。6. 接口 API 与批量任务设计6.1 标准请求结构手机端本地服务只要兼容 OpenAI 格式Agent 框架接入就不会太痛苦。一个标准请求体可以这样构造{ model: lfm2.5, messages: [ {role: system, content: 你是端侧 Agent。}, {role: user, content: 查询上海天气并用一句话总结。} ], tools: [ { type: function, function: { name: weather, description: 查询天气, parameters: { type: object, properties: { city: {type: string} }, required: [city] } } } ], tool_choice: auto }注意tools字段不是所有本地推理版本都支持完全一致部分版本只支持在 system prompt 中约定函数格式接口名也可能不同。正式接入前要先用最小请求确认服务是否回传tool_calls字段如果服务层不支持需要在最外层封装一层函数调用解析器把模型输出的文本按约定解析成结构化动作。6.2 curl 调用模板在电脑或手机同网段下用 curl 直接测试接口是排查链路最快的方式。如果服务进程还在但 Python 请求失败先跑一遍 curl能区分问题出在网络层还是代码层。curl http://127.0.0.1:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { model: lfm2.5, messages: [ {role: user, content: 简单介绍下你自己} ], max_tokens: 128 }返回结果里如果出现choices[0].message.content说明服务与请求链路正常可以继续排查 Python 代码。6.3 批量任务队列化超过几十条任务时不建议单线程循环跑请求。手机端的服务只有一个模型实例在推理串行循环本来没问题但脚本一旦中断就要从头跑。更稳的批量方案是把任务写入 JSON 文件用任务 ID 追踪进度。输入配置可以参考下面结构{ job_id: job_001, input_file: ./data/input.jsonl, output_dir: ./results, failed_dir: ./results/failed, max_retries: 3, concurrency: 1 }脚本按行读取input_file成功后结果写入output_dir失败则把原始行挪到failed_dir最后统计成功数和失败 ID。批量任务过程不要无脑重试同一行短时间重复三到五次仍然失败应直接跳过集中人工检查。6.4 安全暴露边界手机本地服务如果绑定了0.0.0.0在同一局域网内可被其他设备访问。公共 Wi-Fi 环境下建议只绑定127.0.0.1通过安全通道访问。不要把本地调试服务直接暴露到公网不要在服务里携带高权限工具也不要让 Agent 直接操作删除、转账、授权等高危动作。所有工具调用都应设计成先返回候选动作、再由人工确认的模式。7. 资源占用与性能观察7.1 观察工具手机不是电脑没有任务管理器那么直观。调试时可以在电脑上执行adb shell top -b -n 1 | head -20重点看 CPU 占用最高的进程是不是推理进程。如果要观察单个进程的内存adb shell dumpsys meminfo com.termux运行时 Android Studio Profiler 也能接真机能看到更细的内存曲线。对于模型进程被系统杀死这类问题logcat 里会留下lowmemorykiller或am_kill的记录。7.2 手机端性能瓶颈在哪里手机跑 LLM 的瓶颈通常在内存带宽而不是 CPU 核心数量。文本生成是逐 token 进行的每生成一个 token都要把模型权重读取一遍。量化模型如果超过内存带宽承受范围生成速度就会极慢。上下文越长缓存在内存里占用的越多真实可用的权重读取带宽也会受到影响。因此观察性能时除了看端到端首 token 延迟还要记录生成过程中的 CPU 频率曲线。如果 CPU 一开始很高几分钟后骤降多半是设备过热降频了。这种情况下给手机加散热背夹不是玄学对长文本生成确实有正面作用。7.3 如何降低资源占用优先降低采样长度与上下文窗口例如ctx-size从 8192 降到 4096内存占用会有明显下降。其次换更低的量化精度从 Q8 降到 Q4模型体积下降的同时速度通常会提升代价是输出质量有一定损失。如果 Agent 场景依赖固定工具描述可以把 system prompt 精简减少每轮输入的 token 数。手机端不比 GPU 服务器能用 512 token 讲清楚的指令就不要灌 2000 token 的复杂 schema。8. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后打印错误找不到模型路径包含空格或文件名不对检查加载命令与ls实际文件修改为绝对路径不要用带中文和空格的目录服务启动成功但局域网内访问不到服务只绑定了 127.0.0.1curl http://127.0.0.1:端口对比局域网访问启动参数改为--host 0.0.0.0第一轮回答很慢第二轮直接被杀死上下文窗口过大导致内存不足dumpsys meminfo查看内存压力降低ctx-size使用更小量化模型输出全是乱码或反复重复加载时 chat template 不匹配检查命令行是否带-p且未加模板使用 chat 专用模板或服务端生成接口工具调用不输出 JSON量化精度过低或指令被截断用短 system prompt 重复测试提高量化精度简化工具描述批量任务跑一半卡住单条请求上下文超长查看服务端日志最后的请求内容增加 timeout单条限制长度失败跳过手机锁屏后服务停止系统省电策略杀后台logcat 查am_kill关闭该 App 电池优化守住前台唤醒锁CPU 跑几分钟后速度骤降设备过热降频观察/sys/class/thermal温度物理散热、降低生成长度、间歇任务上表的问题覆盖了大部分手机端本地 Agent 的早期失败场景。真正偏向模型本身的问题反而不多——多数情况下是路径、端口、上下文和内存这四个因素互相叠加导致现象很像模型能力不足。排查时按“先链路后参数再模型”的顺序来不要一上来就换模型。9. 最佳实践与使用建议9.1 保留最小可运行配置第一次验证不要追求最强能力。用最低量化、最短上下文、最小 batch 先把链路跑通再逐步加大上下文观察内存曲线。手机端模型的“配置漂移”问题比电脑端更严重改一个参数可能让原本稳定的 Agent 流程直接瘫痪。留存一套验证过的最小配置写进 README。9.2 目录与任务分离模型文件、输入素材、输出结果建议分目录管理models/ lfm2.5_q4.gguf prompts/ agent_system.txt inputs/ tasks.jsonl outputs/ results/ failed/ logs/ server.log批量任务脚本的输出建议每次都写入独立的时间戳目录避免覆盖上一轮结果。模型权重文件不要反复复制通过软链或绝对路径指定。9.3 Agent 安全边界手机本地 Agent 的使用要遵守“最小权限原则”。如果 Agent 能读取通讯录、发短信、调用支付接口那它就不再是便捷工具而是高风险入口。建议将所有工具调用设计为只读优先执行类动作必须经过复核。涉及人脸、通讯录、语音、生物特征的数据未获明确授权不能采集和处理。9.4 输出复核机制本地模型输出质量再高也不能当作最终事实。Agent 生成的摘要、邮件、报告建议增加一个复核步骤要么用规则校验关键词和格式要么人工抽检。对批量任务而言抽样比例不应低于 5%错误率超过阈值时停止后续任务先修正提示词或参数。10. 总结与下一步Liquid AI LFM 2.5 最值得尝试的点是把“采用混合架构的模型跑在本地 Agent 链路里”这件事变成了一个可以实验的方向。对手机用户来说最先验证的不是聊天好坏而是模型能不能在低内存条件下完成工具调用 JSON 输出、多轮记忆和批量任务调度。最容易踩的坑依然是量化过后工具调用变差、上下文窗口与内存冲突、服务被系统后台回收这三类问题占去实际调试的大部分时间。下一步可以作为扩展方向的是把手机端的 HTTP Agent 服务接到局域网自动化脚本里做一个简单的定时任务或者用同一套 LFM 架构在 PC 上跑更高精度版本对比手机端与桌面端的能力差距。端侧推理的价值不在于性能超越云端而在于把一部分高频、敏感、离线的任务真正留在了自己手里。这篇文章可以先收藏等实际部署时按章节顺序对照操作能少走不少弯路。
最近关注端侧大模型的人应该都有同感宣传稿很多“能跑模型”和“能用模型”完全是两回事。尤其当目标变成 AI Agent 时难度又从“本地出几段文本”上升到“模型有没有能力完成工具调用、任务拆解和多轮闭环”。这次我们把视线放到 Liquid AI LFM 2.5 这个模型系列上结合手机本地部署的真实约束聊一聊它的架构特点、启动方式、功能边界和性能观察方法。先说结论上的判断LFM 2.5 不是一个单纯刷评测分数的稠密模型系列它在设计上更强调推理成本和部署灵活性官方公开资料里也给过不少面向边缘侧、移动端的部署讨论。配合端侧推理框架这类模型确实有机会在手机上成为“Agent 引擎”而不是云端 API 的中转站。不过也有前提手机的内存容量、NPU 兼容性、同频内存带宽都会直接影响真实体验不是每个版本都适合塞进手机。这篇文章会按一条可验证的路径展开先看 LFM 2.5 的能力规格和部署边界再讲手机端跑 Agent 需要准备什么环境、怎么启动服务然后给出功能测试、接口调用、批量任务、性能观察和问题排查的完整思路。整个过程不粉饰具体跑分也不会告诉你“装上就好”而是把判断方法交给你——同一套方法换到电脑、开发板、小主机上同样适用。如果你关心的是“这个 Agent 能不能在本地低成本跑起来”“工具调用稳不稳”“能不能接到自动化流程里”这篇文章可以直接往下看。1. 核心能力速览先说清楚一个容易混淆的点Liquid AI LFM 2.5 是模型系列不是某一个固定文件。实际部署时还要区分 Dense 版本和 MoE 版本、原始权重和量化格式不同规格在手机上的可行性差异很大。下面的表格来自公开资料与常规部署经验具体数值需要以你实际拉取到的模型文件和手机配置为准。能力项说明项目类型端侧可部署的大语言模型系列面向 Agent / 对话 / 多模态场景模型系列Liquid AI LFM 2.5包含不同参数量与稀疏专家版本架构关键词非完全传统 Transformer融合状态空间 / 线性注意力 / 专家路由等设计典型部署设备手机、平板、ARM 小主机、带独显的电脑均可按规格选择启动方式命令行服务、MobileLLM / llama.cpp / MLC 等框架封装、App 内集成是否支持 CPU支持手机端通常先跑 CPU再看 NPU / GPU 加速显存 / 内存需求需按版本与上下文长度重新测试不能一概而论是否支持 API通过本地服务封装后可提供类似 OpenAI 的接口是否支持批量任务可以通过脚本循环调用接口或队列化任务实现适合场景隐私敏感数据处理、离线工具型 Agent、端侧自动化的最后一跳对于手机端来说这条链路里最重要的不是“模型有多少参数”而是“实际激活多少参数、权重文件多大、长上下文时内存怎么涨”。从公开技术资料看LFM 2.5 这类含稀疏专家设计的模型让不用的专家权重不参与计算这对端侧推理是友好的理论上可以做到“总参数量大但单次推理的低活跃参数少”。如果换到传统 Dense Transformer 模型同样跑 70B 是不可能的但在 MoE 路线的模型上它有概率被压到手机能接受的范围。不过这里必须提醒一句手机上能跑的模型能力深度和云端完整版一定有差距尤其工具调用稳定性、长上下文记忆都会打折扣。把“本地能跑”理解成“云端托管能力完全复制”是端侧 Agent 最大的预期误区。2. 适用场景与使用边界2.1 适合谁手机本地跑 Agent第一类用户是隐私敏感场景的人。比如内部会议记录整理、个人健康数据简单分析、出差环境下的本地知识库检索这些内容并不适合无差别上传到公共 API。模型放在本机原始素材不出设备至少能把“数据流向哪家服务商”这个问题控制住。第二类是自动化折腾党。手机同时扮演 Agent 推理端和任务调度端搭配 Termux、Tasker 或自建 Python 脚本可以做一些定时简报、本地 RSS 摘要、离线草稿生成。这类场景单次生成量不算大手机端跑几分钟可以接受。第三类是离线环境开发者。在没有稳定外部网络的机房、工地、车载设备上用一块 Android 开发板或旧手机充当 Agent 推理服务通过局域网 HTTP 接口给周边设备提供文本生成能力这在工业运维和边缘计算场景里真实存在。2.2 不适合什么不适合高并发在线服务也不适合质量要求极高的长文本创作。手机内存带宽有限单次请求往往要占用很大一部分内存带宽多个请求同时进来模型推理速度会掉得很明显。也不适合做完整的多模态 Agent 重负载流水线。如果 Agent 每一轮都要“图像输入 大段视觉 token 高分辨率图片 复杂工具调用”手机端非常容易触发内存压力要么进程被杀要么响应延迟到无法使用。2.3 使用边界本地 Agent 如果涉及人脸、声音、照片、文档等敏感素材部署和使用时必须明确授权来源。公司内部数据要先做脱敏个人数据要评估泄露风险模型输出要人工复核。模型文件本身如果来自第三方转换渠道下载后建议校验哈希检查来源可信度。商用场景还要额外确认模型许可证是否允许不能只看“开源模型”四个字就拿来打包卖服务。3. 手机本地部署环境准备3.1 操作系统与处理器工程化测试建议优先使用 Android 设备原因不是 iOS 不能跑而是 Android 侧的工具链更完整Termux 可安装 Linux 用户态llama.cpp 等推理项目对 Android 的构建支持也更早。处理器优先选支持 armv8.2a 以上的型号较新的骁龙、天玑、麒麟芯片都满足更老的 armv8.0 芯片也能编译跑但部分算子优化会用不上。系统里要在“开发者选项”里打开 USB 调试同时确认设备剩余存储至少超过模型文件体积的两倍。比如模型量化文件是 8GB那么设备剩余空间建议不低于 16GB因为转换、拷贝、运行时临时文件都会占用空间。3.2 编译器与依赖如果方案走 llama.cpp需要准备 Android NDK 或直接在 Termux 里使用 clang。更简单的方式是下载社区预编译的 Termux 包再安装构建工具pkg update pkg upgrade pkg install git cmake ninja python clang如果方案走 MLC-LLM需要一台电脑端完成模型转换与 Android 打包手机端不作为构建机只作为运行设备。MLC 的优点是 TVM 编译优化较激进缺点是初次配置重Android 工程构建步骤繁琐。3.3 模型文件来源与格式LFM 2.5 原始权重需要从官方渠道获取手机端一般不会直接读 safetensors 原始文件而是转成 GGUF 或 MLC 专属格式。转换动作可以在 x86 Linux 电脑上用 llama.cpp 的转换脚本完成也可以在手机 Termux 里执行但后者慢很多。模型转换的核心是把 Hugging Face 权重目录转换为单文件 GGUF# 通用模板实际脚本名与参数以 llama.cpp 当前版本为准 python convert_hf_to_gguf.py ./model_dir \ --outfile ./model_q4_k_m.gguf \ --outtype q4_k_m转换完成后把model_q4_k_m.gguf复制到手机存储目录例如/sdcard/Models/lfm2.5/。注意路径不要带空格避免后续脚本解析出错。3.4 磁盘与端口手机端部署建议把模型放在外部存储或独立数据分区不要塞进 App 私有目录再频繁读写。模型文件一旦放好不要随意改名。如果后续要起 HTTP 服务还应该确认一个可用端口常见本地服务用 8080、8000、7860但不同框架默认端口不同冲突时用netstat -tlnp检查占用。4. 安装部署与启动方式4.1 方式一Termux llama.cpp手机装好 Termux 后用 git 拉取最新源码重新编译并启用 Vulkan 后端足够跑通大部分脚本如果你的设备兼容性一般先关闭 GPU 加速用纯 CPU 版验证链路。git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DLLAMA_CURLON -DGGML_VULKANON cmake --build . -j4编译完成后可以通过命令行确认模型是否正常加载./llama-cli -m /sdcard/Models/lfm2.5/model_q4_k_m.gguf \ -p 你是一个本地 Agent先输出当前任务拆解 \ -n 256能正常打印回答说明模型权重、分词器和基础调用链路没问题。4.2 方式二PC 端 MLCL-LLM 打包MLC 路线更适合做独立 App需要电脑上预先装好 Python 3.10 以上版本安装mlc-llm与mlc-ai包再使用它的 Android 打包命令。最后产出的是 APK模型文件可以打进 APK 里也可以首次启动时从手机存储引导导入。# 通用模板特定参数需按 MLC-LLM 项目文档调整 mlc_llm package --model ./model_dir \ --target android \ --output ./distAPK 生成后可以用 adb 安装adb install -r ./dist/app-debug.apkMLC 方案的好处是能利用 TVM 做 layer fusion在部分芯片上的提速明显坏处是调试成本更高如果模型结构较新需要等待 MLC 社区适配。4.3 启动为本地 HTTP 服务把模型跑成 HTTP 服务是接 Agent 的关键一步。手机端不再直接和模型终端交互而是由 Python 脚本或 App 调用 HTTP 接口完成多轮对话、工具调用和批量任务。以 llama.cpp 内置的 server 为例./llama-server -m /sdcard/Models/lfm2.5/model_q4_k_m.gguf \ --host 0.0.0.0 \ --port 8080 \ --ctx-size 4096 \ -n 512手机启动服务后不要立刻锁屏部分系统锁屏会杀掉后台进程。验证服务是否起来可以在同一局域网电脑上执行curl http://手机IP:8080/v1/models能返回模型列表说明服务已经就绪可以把请求地址作为 Agent 的本地大模型 API。4.4 初始化检查清单启动后优先检查四个东西日志有没有报显存或内存不足加载模型的耗时是否在可接受范围第一次输入生成是否明显延迟局域网端口能否从外部访问。任何一步失败都先别继续接入 Agent先用最短 prompt 排除基本问题。5. 功能测试与效果验证5.1 基础对话能力验证 Agent 之前先做基础对话。输入一个没有指令格式的普通问题例如“请用三句话说明什么是函数调用”。观察模型是否理解中文指令、输出结构和标点是否异常、是否出现重复循环。如果基础对话都在乱说后面工具调用基本不会稳。5.2 Agent 工具调用测试Agent 的核心不是聊天而是触发工具。可以先设计一个假想工具查询天气。要求模型输出指定 JSON 结构比如必须包含action和action_input字段。测试提示词你是一个智能助手可以调用下面的工具 - name: weather description: 查询指定城市的天气 parameters: {city: string} 用户问北京今天需要带伞吗 请先决定是否调用工具。如果调用输出 JSON{action: weather, action_input: {city: 北京}} 如果不需要调用直接给出自然语言答案。判断成功的标准是模型根据用户意图正确输出了weather调用而不是生成一段带有解释的文字或者直接编造天气。如果模型总是把工具名和参数写成文本而非 JSON需要检查量化精度是否过低、system prompt 是否过长、上下文窗口是否被截断。5.3 多轮记忆与上下文约束真实 Agent 场景最少需要三轮对话记忆。测试时给模型连续三段指令第一轮让模型记住一个临时值例如“今天会议主题是端侧推理优化”。第二轮插入无关问题干扰上下文。第三轮要求模型回答“会议主题是什么”。模型如果正确回答且没有把第二轮内容混淆进来说明上下文管理可用。如果记忆丢失最常见原因是手机端本地服务把ctx-size设置过短历史消息超出窗口后被截断。如果ctx-size设置得很大但内存不够模型加载后可能中途被杀这里需要在长记忆和稳定性之间做取舍。5.4 批量文本生成批量任务的输入文件可以做成 JSONL一行一个请求。下面是一个 Python 测试脚本示例import json import requests input_path tasks.jsonl url http://127.0.0.1:8080/v1/chat/completions with open(input_path, r, encodingutf-8) as f: for line in f: task json.loads(line) payload { model: lfm2.5, messages: [ {role: system, content: 你是本地 Agent只做原文改写。}, {role: user, content: task[text]} ], temperature: 0.3, max_tokens: 256 } try: resp requests.post(url, jsonpayload, timeout180) result resp.json() print(task[id], result[choices][0][message][content]) except Exception as e: print(failed, task[id], e)批量任务的常见坑是中途某一条文本长度超限导致整个进程卡住。稳妥做法是给每条请求加独立的timeout并且把单条输出长度上限调低一点。跑完后再做抽样复核避免模型把格式改错。5.5 失败判断标准凡是出现以下现象都说明当前配置不适合直接进入生产 模型加载后第一次推理耗时超过数十秒、输出中途中断且日志出现 OOM、多轮轮次超过五次后响应质量明显下降、工具调用 JSON 频繁出现字段缺失或转义错误。遇到这些先不要怀疑模型能力先检查设备剩余内存、进程是否被系统回收、上下文窗口设置、服务端日志报错。6. 接口 API 与批量任务设计6.1 标准请求结构手机端本地服务只要兼容 OpenAI 格式Agent 框架接入就不会太痛苦。一个标准请求体可以这样构造{ model: lfm2.5, messages: [ {role: system, content: 你是端侧 Agent。}, {role: user, content: 查询上海天气并用一句话总结。} ], tools: [ { type: function, function: { name: weather, description: 查询天气, parameters: { type: object, properties: { city: {type: string} }, required: [city] } } } ], tool_choice: auto }注意tools字段不是所有本地推理版本都支持完全一致部分版本只支持在 system prompt 中约定函数格式接口名也可能不同。正式接入前要先用最小请求确认服务是否回传tool_calls字段如果服务层不支持需要在最外层封装一层函数调用解析器把模型输出的文本按约定解析成结构化动作。6.2 curl 调用模板在电脑或手机同网段下用 curl 直接测试接口是排查链路最快的方式。如果服务进程还在但 Python 请求失败先跑一遍 curl能区分问题出在网络层还是代码层。curl http://127.0.0.1:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { model: lfm2.5, messages: [ {role: user, content: 简单介绍下你自己} ], max_tokens: 128 }返回结果里如果出现choices[0].message.content说明服务与请求链路正常可以继续排查 Python 代码。6.3 批量任务队列化超过几十条任务时不建议单线程循环跑请求。手机端的服务只有一个模型实例在推理串行循环本来没问题但脚本一旦中断就要从头跑。更稳的批量方案是把任务写入 JSON 文件用任务 ID 追踪进度。输入配置可以参考下面结构{ job_id: job_001, input_file: ./data/input.jsonl, output_dir: ./results, failed_dir: ./results/failed, max_retries: 3, concurrency: 1 }脚本按行读取input_file成功后结果写入output_dir失败则把原始行挪到failed_dir最后统计成功数和失败 ID。批量任务过程不要无脑重试同一行短时间重复三到五次仍然失败应直接跳过集中人工检查。6.4 安全暴露边界手机本地服务如果绑定了0.0.0.0在同一局域网内可被其他设备访问。公共 Wi-Fi 环境下建议只绑定127.0.0.1通过安全通道访问。不要把本地调试服务直接暴露到公网不要在服务里携带高权限工具也不要让 Agent 直接操作删除、转账、授权等高危动作。所有工具调用都应设计成先返回候选动作、再由人工确认的模式。7. 资源占用与性能观察7.1 观察工具手机不是电脑没有任务管理器那么直观。调试时可以在电脑上执行adb shell top -b -n 1 | head -20重点看 CPU 占用最高的进程是不是推理进程。如果要观察单个进程的内存adb shell dumpsys meminfo com.termux运行时 Android Studio Profiler 也能接真机能看到更细的内存曲线。对于模型进程被系统杀死这类问题logcat 里会留下lowmemorykiller或am_kill的记录。7.2 手机端性能瓶颈在哪里手机跑 LLM 的瓶颈通常在内存带宽而不是 CPU 核心数量。文本生成是逐 token 进行的每生成一个 token都要把模型权重读取一遍。量化模型如果超过内存带宽承受范围生成速度就会极慢。上下文越长缓存在内存里占用的越多真实可用的权重读取带宽也会受到影响。因此观察性能时除了看端到端首 token 延迟还要记录生成过程中的 CPU 频率曲线。如果 CPU 一开始很高几分钟后骤降多半是设备过热降频了。这种情况下给手机加散热背夹不是玄学对长文本生成确实有正面作用。7.3 如何降低资源占用优先降低采样长度与上下文窗口例如ctx-size从 8192 降到 4096内存占用会有明显下降。其次换更低的量化精度从 Q8 降到 Q4模型体积下降的同时速度通常会提升代价是输出质量有一定损失。如果 Agent 场景依赖固定工具描述可以把 system prompt 精简减少每轮输入的 token 数。手机端不比 GPU 服务器能用 512 token 讲清楚的指令就不要灌 2000 token 的复杂 schema。8. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后打印错误找不到模型路径包含空格或文件名不对检查加载命令与ls实际文件修改为绝对路径不要用带中文和空格的目录服务启动成功但局域网内访问不到服务只绑定了 127.0.0.1curl http://127.0.0.1:端口对比局域网访问启动参数改为--host 0.0.0.0第一轮回答很慢第二轮直接被杀死上下文窗口过大导致内存不足dumpsys meminfo查看内存压力降低ctx-size使用更小量化模型输出全是乱码或反复重复加载时 chat template 不匹配检查命令行是否带-p且未加模板使用 chat 专用模板或服务端生成接口工具调用不输出 JSON量化精度过低或指令被截断用短 system prompt 重复测试提高量化精度简化工具描述批量任务跑一半卡住单条请求上下文超长查看服务端日志最后的请求内容增加 timeout单条限制长度失败跳过手机锁屏后服务停止系统省电策略杀后台logcat 查am_kill关闭该 App 电池优化守住前台唤醒锁CPU 跑几分钟后速度骤降设备过热降频观察/sys/class/thermal温度物理散热、降低生成长度、间歇任务上表的问题覆盖了大部分手机端本地 Agent 的早期失败场景。真正偏向模型本身的问题反而不多——多数情况下是路径、端口、上下文和内存这四个因素互相叠加导致现象很像模型能力不足。排查时按“先链路后参数再模型”的顺序来不要一上来就换模型。9. 最佳实践与使用建议9.1 保留最小可运行配置第一次验证不要追求最强能力。用最低量化、最短上下文、最小 batch 先把链路跑通再逐步加大上下文观察内存曲线。手机端模型的“配置漂移”问题比电脑端更严重改一个参数可能让原本稳定的 Agent 流程直接瘫痪。留存一套验证过的最小配置写进 README。9.2 目录与任务分离模型文件、输入素材、输出结果建议分目录管理models/ lfm2.5_q4.gguf prompts/ agent_system.txt inputs/ tasks.jsonl outputs/ results/ failed/ logs/ server.log批量任务脚本的输出建议每次都写入独立的时间戳目录避免覆盖上一轮结果。模型权重文件不要反复复制通过软链或绝对路径指定。9.3 Agent 安全边界手机本地 Agent 的使用要遵守“最小权限原则”。如果 Agent 能读取通讯录、发短信、调用支付接口那它就不再是便捷工具而是高风险入口。建议将所有工具调用设计为只读优先执行类动作必须经过复核。涉及人脸、通讯录、语音、生物特征的数据未获明确授权不能采集和处理。9.4 输出复核机制本地模型输出质量再高也不能当作最终事实。Agent 生成的摘要、邮件、报告建议增加一个复核步骤要么用规则校验关键词和格式要么人工抽检。对批量任务而言抽样比例不应低于 5%错误率超过阈值时停止后续任务先修正提示词或参数。10. 总结与下一步Liquid AI LFM 2.5 最值得尝试的点是把“采用混合架构的模型跑在本地 Agent 链路里”这件事变成了一个可以实验的方向。对手机用户来说最先验证的不是聊天好坏而是模型能不能在低内存条件下完成工具调用 JSON 输出、多轮记忆和批量任务调度。最容易踩的坑依然是量化过后工具调用变差、上下文窗口与内存冲突、服务被系统后台回收这三类问题占去实际调试的大部分时间。下一步可以作为扩展方向的是把手机端的 HTTP Agent 服务接到局域网自动化脚本里做一个简单的定时任务或者用同一套 LFM 架构在 PC 上跑更高精度版本对比手机端与桌面端的能力差距。端侧推理的价值不在于性能超越云端而在于把一部分高频、敏感、离线的任务真正留在了自己手里。这篇文章可以先收藏等实际部署时按章节顺序对照操作能少走不少弯路。
