手机本地跑 AI Agent许多人的第一反应是“把某个 7B 模型塞进手机扔一段提示词能回复就算成功”。真做完之后会发现这个阈值定得太低了。手机上的 Agent 能不能落地取决于三件事模型架构对端侧推理是否友好、推理框架能否把模型变成一个可调用的服务、模型在工具调用场景里是否能稳定输出结构化指令。LFM 2.5 之所以值得单独写一篇因为它正好是这三件事的交集。标题里的 Cloud Codes 可以理解为一个发布环境备注真正的重点是 Liquid AI LFM 2.5 这套架构和它在手机端的实测价值。这篇博文不会直接丢给你一堆跑分也不会假装我已经在某台旗舰机上跑完了全部流程。更实际的做法是给出一套可重复的验证链路权重获取、格式确认、推理框架接入、HTTP API 暴露、Agent 工具调用验证、性能观察和排错清单。你按这条路走完基本就知道它到底适不适合自己的手机。先说明一个前提LFM 2.5 的公开细节并不是“铺天盖地”的状态。不同参数档位、量化版本、许可证范围都会直接影响部署方式。所以正文里会区分“确定的架构方向”和“需要以官方仓库为准的参数细节”避免用想象补全技术规格。1. 核心能力速览在动手之前先把关键信息放在表格里。下面的表格不是某个官网参数页的复制而是把“手机本地跑 AI Agent”需要关注的点拆开方便你按行核对自己手里的设备条件能力项说明项目定位面向本地/端侧部署的 AI Agent 实验模型与推理链路核心是 LFM 2.5模型来源Liquid AI 相关公开项目具体权重以官方仓库发布为准架构关键词LFM 系列混合线性时间序列/状态空间等方向不是纯标准 Transformer 路线手机端部署路线常见方案为 llama.cpp、Ollama Android 等社区成熟推理框架内存占用取决于参数量、上下文长度和量化等级不能用一个固定数字覆盖所有档位API 能力通过 llama-server 或 Ollama 可暴露 HTTP API兼容常见 Chat 调用格式批量任务可串行执行本地轻量任务队列不适合高并发或端侧大规模并行适合人群关注 AI Agent、端侧模型架构选型、隐私敏感场景的技术开发者合规提示模型许可证、输入数据授权、输出内容复核都不能省从这张表能直接得出一个判断LFM 2.5 这一类模型真正价值不在“聊天流畅度”而在“更低的端侧推理成本”和“Agent 化的工程可能性”。它能不能跑到你的手机上不能只看参数量还要看上下文长度、量化支持和工具调用稳定性。2. LFM 2.5 架构解析端侧 Agent 真正要看什么2.1 架构不是参数游戏讨论手机本地大模型很多人习惯只看“多少 B”。这个指标在服务端有一定参考价值在端侧却经常失真。真正影响手机体验的是三件事激活参数数量、KV Cache 增长速度、量化后的精度损失。一个模型总参数很大但如果推理时只激活一部分参数端侧未必跑不动反过来一个模型参数看似不大如果每次生成都要维护超大上下文缓存手机内存照样被迅速吃光。所以解析 LFM 2.5 的架构不能只问“它有多强”而要问“它为了降低推理成本做了什么”。从 LFM 系列的路径来看核心方向是减少对注意力层的绝对依赖。注意力层在长上下文里会带来明显的缓存开销而混合线性时间序列或状态空间结构在处理长序列时更“省”。这类设计对 Agent 场景非常重要因为 Agent 需要携带工具定义、历史对话、观察结果上下文天然比普通聊天更长。不过这里要克制LFM 2.5 具体每一层怎么排、专家数量多少、上下文窗口多大我不能在没有官方文档的情况下给死数字。更稳妥的方式是把它当作“值得端侧验证的候选模型”而不是“已经验证过的端侧标准答案”。你实操前要做的第一件事是打开官方发布说明把参数量、上下文长度、支持格式抄到自己的测试记录里。2.2 三个决定能否上手机的架构检查点第一个检查点是“有没有适配 GGUF / MLX 格式的权重”。手机端主流框架几乎不直接加载 Safetensors 原始权重而是把模型量化成 GGUF 这类格式。如果 LFM 2.5 只提供原始权重没有官方或社区量化版本那部署成本会立刻上升你需要自己用工具转换。第二个检查点是“工具调用能力是否以可解析格式暴露”。AI Agent 的基础能力是让模型输出一段结构化 JSON再交给代码去执行工具。模型在纯对话任务里表现好不代表它能在 Function Calling 格式下稳定输出。这个问题不能靠跑分判断只能靠实际提示词验证。第三个检查点是“上下文长度和实际内存增长比例”。Agent 多轮任务里系统提示词、工具定义、中间结果都会占用上下文。你必须知道在目标上下文长度下KV Cache 会吃掉多少内存。这个数据在手机端无法靠“肉眼”估算需要先跑一轮递增上下文的压力测试。2.3 官方权重与第三方量化下载权重时优先看官方仓库有没有提供现成的 GGUF、MLX 或其他端侧格式。如果官方没有提供再去搜索可信的社区量化版本并对比 SHA256 哈希。不要随手从不知名网盘下载量化文件量化版本一旦做错轻则效果异常重则加载失败。这里推荐一个稳妥的工作流先在电脑上把权重下载好用 llama.cpp 跑通一次推理再把同一个模型文件复制到手机。这样能提前排除“模型文件本身损坏”的问题。国内网络环境下模型下载可以优先考虑 ModelScope 等授权镜像渠道避免下载中断。3. 适用场景与使用边界3.1 适合做哪些事LFM 2.5 跑在手机上的最大优势是数据不出设备。适合的场景包括本地会议记录整理、离线文本分类、敏感文档问答、简单工具调用的 Agent 原型验证。对这些场景来说模型不需要做到云端大模型那么全面只要能在低内存占用下稳定完成特定任务就有价值。另一个适合的场景是“Agent 架构选型前的 PoC”。如果你正在比较多个端侧模型想看看 LFM 2.5 在工具调用、长指令遵循、量化敏感度上的表现用手机做一轮对比测试成本很低也比租 GPU 实例更直接。3.2 边缘场景不要硬上不适合的场景也很明显第一重度多轮复杂 Agent例如几十轮对话、大量外部工具并行调用手机内存和算力撑不住第二大规模 RAG本地向量索引如果太大检索阶段就会卡死第三对输出质量要求极高的正式内容生成端侧量化模型会出现语义漂移需要人工复核。更要提醒的是合规边界。手机本地跑 Agent不代表数据就“绝对安全”。如果输入素材来自他人要确认是否有授权如果模型被用于人脸、声音、版权内容相关场景必须获得明确许可。输出内容在商用前要做效果复核不要把端侧模型的单次输出当作最终交付物。4. 环境准备与前置条件在写具体命令前先给出一份通用检查清单。由于 LFM 2.5 的官方支持矩阵还需要以仓库为准手机端部署通常会用到以下条件。检查项建议操作系统Android 优先Termux 环境完整iOS 端工具链受限手机内存建议先确认系统剩余内存跑 8B 级量化模型需要较大的可用内存存储空间权重和临时缓存预留足够空间避免存储写满导致进程被杀Termux确认已安装并启用存储权限推理框架llama.cpp 或 Ollama Android按需选择电脑辅助建议先在电脑上完成权重下载与最小推理验证4.1 建议先在电脑上验证一次手机端的坑很多来自模型文件本身。我建议把电脑当作“模型中转站”先下载模型、跑通一次对话、确认工具调用格式没问题再把模型文件通过数据线或局域网上传到手机。这样可以隔离问题如果电脑上也跑不起来就不是手机环境的问题。电脑端主要检查三件事模型权重能否正常加载、基础对话是否有明显乱码、Function Calling 或 JSON 输出是否稳定。任何一步失败都不要急着往手机上搬运。4.2 手机端需要安装的软件手机端最常见的路线是在 Termux 中编译 llama.cpp。Termux 本质上是一个 Android 上的 Linux 终端环境可以运行 clang、cmake、git 等工具。你也可以选择 Ollama Android 的图形化方案但如果想观察日志、精确控制参数llama.cpp 更合适。无论是哪条路线都不要在手机端临时下载几百 MB 到几个 GB 的权重。先把权重放在电脑上验证再传到手机的models目录。推荐目录结构如下/sdcard/llm/ ├── models/ │ ├── lfm-2.5-q4_k_m.gguf │ └── models.txt ├── logs/ │ └── server.log └── agent/ └── tasks.json5. 安装部署与启动方式5.1 路线 ATermux llama.cpp先在 Termux 中安装基础依赖pkg update pkg upgrade -y pkg install git cmake make gcc clang python -y然后克隆 llama.cpp 并编译。手机 CPU 核心数有限编译时可以用-j2或-j4控制并行度避免把手机卡死git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build -j2如果编译报错通常是缺少依赖或 CMake 版本过低。此时先执行pkg install cmake make gcc clang -y更新一遍再重新编译。不要在一个报错日志都没看完的情况下反复重试先看最后 20 行输出。编译完成后启动 llama-server./build/bin/llama-server \ -m /sdcard/llm/models/lfm-2.5-q4_k_m.gguf \ --ctx-size 4096 \ --host 127.0.0.1 \ --port 8080 \ -t 4这里重点解释两个参数。--host 127.0.0.1表示只在本机访问更安全但如果你想在电脑浏览器里调试就需要改成--host 0.0.0.0。-t 4是线程数不是越大越好。手机 CPU 有大核和小核之分线程数设置过高反而会因为调度和发热导致性能下降。5.2 路线 BOllama AndroidOllama Android 提供更接近“一键运行”的体验安装后可以通过图形界面拉取模型并运行。它的优势是内置了模型管理和 HTTP API适合快速验证缺点是日志暴露不如 llama.cpp 完整底层参数控制也没那么细。如果你用 Ollama启动后默认 API 地址通常是http://127.0.0.1:11434。但要注意Ollama 的模型仓库里是否已经收录 LFM 2.5以及收录的是哪个量化版本需要到实际可用的模型库页面确认。不要以为所有模型都会自动出现在 Ollama 的仓库中。5.3 启动后的首次访问服务启动成功之后用浏览器访问http://127.0.0.1:8080可以看到 llama.cpp 自带的 Web 页面输入一句话能正常回复就说明模型加载成功。这一步失败时优先看终端日志而不是去 Web 端反复刷新。常见原因包括模型文件路径错误、上下文长度超出内存上限、量化文件不兼容。把日志中的错误信息定位到具体报错行再针对处理。6. 功能测试与效果验证6.1 基础对话测试启动服务后先用最简单的 Prompt 验证模型推理链路。以 llama.cpp 为例接口路径是/v1/chat/completionscurl http://127.0.0.1:8080/v1/chat/completions \ -H Content-Type: application/json \ -d { model: lfm-2.5, messages: [ {role: user, content: 用三句话解释液态神经网络与标准 Transformer 的主要区别} ], max_tokens: 512, temperature: 0.7 }这里把model字段写成lfm-2.5只表示“我想调用这个模型”真正决定模型身份的仍然是启动命令中的权重路径。返回结果里如果包含choices字段并能看到完整中文回答就是链路通了。6.2 工具调用验证Agent 场景与普通聊天最大的区别就在这里。你要验证的不是“模型能不能编一个 JSON”而是“给定工具定义后模型会不会按格式返回参数”。先定义一个简单工具{ name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名称} }, required: [city] } }然后发送包含工具定义的请求。如果框架原生支持 Function Calling就按 OpenAI 兼容格式传tools字段如果不支持就在系统提示词里写明“只输出 JSON格式为 {tool: get_weather, params: {city: 北京}}”再用正则或 JSON 解析器提取结果。判断成功的标准不是“模型输出了 JSON”而是“连续十次输入不同城市模型都能输出可解析且参数正确的 JSON”。如果模型在第二轮就开始混入额外解释文字说明这个量化版本的工具调用稳定性不足需要换更高精度量化或调整提示词。6.3 Agent 多轮循环测试本地 Agent 的完整链路是用户指令 → 模型判断需要调用工具 → 程序执行工具 → 把结果拼接回上下文 → 模型生成最终回答。这个循环非常消耗资源所以建议先用少量轮次测试。下面是一个 Python 脚本骨架import requests API_URL http://127.0.0.1:8080/v1/chat/completions def chat(messages): resp requests.post( API_URL, json{ model: lfm-2.5, messages: messages, temperature: 0.3, max_tokens: 1024, }, timeout300, ) return resp.json()[choices][0][message][content] messages [{role: system, content: 你是一个本地助手只能查询城市天气。}] messages.append({role: user, content: 北京今天适合出门吗}) reply chat(messages) print(reply)注意timeout300不是随便写的。手机端推理速度远低于电脑一个长回答可能超过 60 秒。如果超时时间设置过短即使模型正在生成你的调用也已经中断。6.4 长指令遵循测试Agent 系统提示词往往很长里面包含工具列表、输出格式、处理规则。端侧量化模型经常会在长指令下“丢失”某些要求。你可以构造 500 字以上的系统提示词要求模型必须输出指定格式然后反复测试。这一轮测试最能反映 LFM 2.5 在真实 Agent 场景中的可用度。很多模型在短提示词下表现优秀一旦工具定义超过五个、规则描述超过十条就开始漏掉约束。遇到这种情况优先精简系统提示词、把工具拆成更小的 Schema不要幻想换一句“请你注意规则”就能解决。7. 接口 API 与批量任务7.1 统一 API 入口手机端服务跑起来后接口能力是它最大的价值。llama.cpp 的 llama-server 提供/v1/chat/completions风格的接口基本对齐 OpenAI Chat 格式方便接入现有的 Agent 框架或脚本。即使你的 Agent 代码之前在云端 API 上运行只要把base_url换成手机局域网地址也能很快适配。统一 API 的好处是后面你想切换到不同模型只需要改服务启动命令和模型文件而 Agent 代码不变。这降低了模型替换成本也让对比测试更方便。7.2 Python 调用示例import requests url http://127.0.0.1:8080/v1/chat/completions payload { messages: [ {role: system, content: 你是本地 Agent输出 JSON。}, {role: user, content: 把这句话翻译成英文今天要测试接口稳定性。} ], max_tokens: 512, temperature: 0.3 } response requests.post(url, jsonpayload, timeout120) data response.json() if choices in data: print(data[choices][0][message][content]) else: print(error:, data)这个例子包含了一个关键技巧timeout设置与手机推理速度匹配。另一个技巧是检查返回 JSON 中的错误字段很多手机端失败会显示为 GPU 内存不足或请求超时而不是模型回答错误。7.3 手机端的批量任务策略手机不适合高并发批量任务但适合串行执行本地轻量队列。比如你要对 20 条本地笔记做摘要可以写一个简单脚本每次读一条调用本地 Agent生成结果然后 sleep 一段时间避免手机过热。推荐批量任务配置{ input_file: ./notes.txt, output_dir: ./output, prompt_template: 请对以下笔记做摘要{content}, interval_sec: 5, max_retries: 3, timeout_sec: 120 }Python 脚本的伪代码逻辑如下import json import time import requests with open(batch_config.json, r, encodingutf-8) as f: config json.load(f) with open(config[input_file], r, encodingutf-8) as f: lines [line.strip() for line in f if line.strip()] for idx, line in enumerate(lines): prompt config[prompt_template].format(contentline) for attempt in range(config[max_retries]): try: resp requests.post( http://127.0.0.1:8080/v1/chat/completions, json{messages: [{role: user, content: prompt}]}, timeoutconfig[timeout_sec], ) result resp.json()[choices][0][message][content] with open(f{config[output_dir]}/result_{idx}.md, w, encodingutf-8) as out: out.write(result) break except Exception as exc: print(ftask {idx} attempt {attempt} failed: {exc}) time.sleep(config[interval_sec] * (attempt 1))这里没有使用复杂的并发库因为手机端 CPU 在同时处理多个请求时反而会因为资源争抢导致单个任务变慢。串行加间隔是最稳的端侧批量策略。8. 资源占用与性能观察8.1 手机端如何观察内存和 CPU在 Termux 中可以使用htop查看进程内存和 CPU 占用如果没有安装就先执行pkg install htop。启动 llama-server 后在另一个 Termux 会话中运行htop按进程名找到llama-server观察 RES 内存列。RES 表示常驻物理内存是判断模型是否超过手机内存上限的重要依据。不要只看 RSS 数字本身还要结合系统可用内存。如果系统剩余内存已经很低Android 会主动杀掉后台进程。服务无预兆退出通常是内存不足被系统回收而不是程序崩溃。观察推理速度时直接看 llama.cpp 日志。llama.cpp 每次生成结束会打印类似eval time和tokens per second的信息。记录不同上下文长度下的 token/s然后做对比。不同机型差异很大不要用网络上某台机器的数字直接当作自己的预期值。8.2 影响性能的关键参数上下文长度是最容易被忽略的变量。--ctx-size设置越大KV Cache 占用内存越高。手机端不建议一开始就设置 16384建议从 2048 或 4096 起步确认生成速度可接受后再逐步提高。-t线程数同样需要实测。四个线程不一定比两个线程快因为手机散热和大小核调度会影响实际频率。连续生成时如果手机背部明显发热说明线程数可能偏高或任务本身超出了手机散热能力。量化等级也会影响内存和速度。Q4_K_M 通常是内存和质量的平衡点但不同模型对不同量化等级的敏感度不同。如果 Q4 输出质量下降明显可以先尝试 Q5 或 Q6 版本看内存是否还能承受。这些测试必须在手机上做因为电脑上的内存充足情况无法代表手机环境。8.3 性能记录建议每次测试都要记录这些信息模型文件名、量化等级、上下文长度、线程数、内存占比、平均生成速度、是否发热降频。没有这些记录后续换模型版本就没办法对比。我建议在logs目录里放一个性能记录表模型文件量化ctx线程内存占比token/s备注lfm-2.5-q4_k_m.ggufQ4_K_M40964待测待测首次测试手机端大模型优化是一个需要持续记录的过程不记录就没有优化空间。9. 常见问题与排查方法手机端跑大模型问题容易出在工具链和系统资源两个层面。下面整理高频问题与排查方向。问题现象可能原因排查方式解决方案启动后 Web 页面打不开端口被占用或服务未启动查看启动日志和netstat -tlnp更换端口或检查模型路径请求超时手机推理速度慢或模型正在处理长序列缩短 Prompt减少max_tokens增大客户端 timeout降低上下文长度Android 杀掉进程可用内存不足或系统省电策略查看日志末尾是否有 killed换更小模型或降低 ctx-size输出乱码模型文件损坏或量化异常在电脑端跑同一模型对比重新下载权重并校验哈希CPU 占用过高且发热线程数设置过多检查top中负载降低-t并让设备休息工具调用输出不稳定量化精度损失或提示词约束不够连续测试十次提高量化档位或强制 JSON 输出API 一直报错接口路径或请求格式不对直接用 curl 验证校准 URL、Header 和 Payload局域网无法访问服务只监听了 127.0.0.1检查--host参数按需修改为0.0.0.0并注意安全遇到问题时最重要的原则是先看日志。手机端报错信息有时会被系统吞掉Termux 会话关闭后日志就丢了。建议启动服务时把日志写到文件./build/bin/llama-server \ -m /sdcard/llm/models/lfm-2.5-q4_k_m.gguf \ --host 127.0.0.1 \ --port 8080 \ /sdcard/llm/logs/server.log 21后续排查时直接打开日志文件比在屏幕前盲猜可靠得多。另一个常见问题是模型文件放在 SD 卡或内部存储后Termux 没有读取权限。如果日志显示failed to open file不要反复检查路径先确认 Termux 的存储权限是否打开。10. 最佳实践与合规提醒手机本地跑 AI Agent最大的工程陷阱是“在电脑上测得很顺上手机后全面翻车”。这通常不是模型本身的问题而是环境差异。建议第一次测试时先跑最小配置短上下文、短回答、低线程数、无批量任务确认链路通畅后再逐步增加难度。模型文件、输入素材、输出结果要分目录管理。不要把所有东西堆在一个目录里。端侧测试经常需要切换量化版本如果没有清晰的目录结构很容易把旧模型当作新模型测试浪费大量时间。接口服务默认不要监听公网。如果需要在局域网内访问要确认手机处于可信网络。更不要图省事把 API Key 或敏感数据写死在脚本里。手机如果丢了数据保护策略会比电脑端更难处理。合规使用是一条硬线。涉及人脸、声音、版权素材时必须确认获得授权处理其他人的对话记录或文档前要先评估隐私风险模型许可证允许什么范围内的使用也要提前确认。端侧模型不等于“可以任意用”数据和模型都会携带各自的权利边界。批量任务必须先做小样本试跑再扩大范围。手机生成的单个结果如果质量不稳定整个批量任务的质量也不会稳定。每个输出文件都建议保留对应的输入索引和模型参数记录方便回溯错误。最后还要提醒一点不要让手机在无人看管状态下长时间高负载运行。大模型连续推理会让电池温度升高可能触发系统降频甚至自动关机。如果你有固定批量任务把它拆成多个小批次执行每批之间留出足够的冷却时间。手机 Agent 这类任务的验收标准不是“模型下载完成”而是“模型能否在受控条件下稳定完成用户指令、工具调用和结果返回”。LFM 2.5 到底适不适合你的使用场景建议先跑通一次基础对话、一次工具调用、一次小批量任务再做判断。这样得到的效果比任何参数表都可靠。