1. 手机跑大模型这件事LiteRT-LM 到底解决了什么LiteRT-LM 是 Google 推出的端侧 LLM 推理框架专门跑在手机、手表、IoT 设备这类 ARM NPU 的硬件上。它能做什么一句话让 1B~2B 级别的大模型在移动端以接近云端 API 的响应速度离线运行。适合谁做移动端 AI 应用的 Android/iOS 开发者、想在设备端做隐私敏感推理的团队以及需要离线可用能力的边缘计算场景。先看一组实测数据来自高通骁龙 8 Elite Gen 5 上运行 Gemma 3 1B 的场景首次响应时间TTFT约 0.12 秒解码速度超过 100 tokens/s2B 模型 INT4 量化后运行时内存占用低于 1.5GB。这个数字意味着什么你在手机上问一个问题模型几乎在你松手的瞬间就开始吐字了体验和调云端 API 没有肉眼可见的差别。但这里有个容易被忽略的前提LiteRT-LM 不是 Ollama 的替代品也不是 vLLM 的竞品。它占据的是完全不同的生态位。vLLM 跑在云端 A100/H100 上做高并发 API 服务Ollama 跑在 PC 上做开发调试LM Studio 给非技术用户尝鲜用而 LiteRT-LM 的目标是手机、手表、IoT 设备上的 ARM NPU 架构。四者形成的是互补关系不是替代关系。为什么它能这么快核心在于 NPU 加速。NPU 是专门为神经网络计算设计的芯片苹果的 Neural Engine、高通的 Hexagon、联发科的 APU 都属于这类。它的特点是并行计算能力强、功耗低。在 LiteRT-LM 的后端选择中CPU 是基准性能1xGPU 大约 7 倍NPU 可以达到约 100 倍。这个差距在 TTFT 上体现得尤其明显CPU 约 12 秒GPU 约 1.5 秒NPU 约 0.12 秒。我试过在 Android 设备上把后端从 GPU 切到 NPU同样的模型、同样的输入首字延迟从 1.5 秒级别直接掉到 0.1 秒级别那种「按下即出字」的感觉和云端 API 几乎一致。但这里有个坑不是所有设备都支持 NPU 后端需要芯片厂商的 SDK 集成到位而且模型格式必须是.litertlm不能直接拿 GGUF 或 safetensors 来用。LiteRT-LM 支持的模型格式是专有的.litertlm需要从 Hugging Face 的 litert-community 页面下载预转换模型。目前覆盖 Gemma 系列Gemma 3 1B、Gemma 4 E2B、Llama 系列、Phi 系列、Qwen 系列以及支持工具调用的 FunctionGemma。量化方面支持 INT4、INT8 和混合量化其中 INT4 是大多数场景的首选——Gemma 4 E2B INT4 参数量 2.3B模型文件仅 557MB运行时内存占用低于 1.5GB大多数现代手机都能流畅跑起来。多模态方面LiteRT-LM 原生支持图像输入VLM、音频输入语音对话和工具调用Function Calling这意味着你可以在端侧构建一个能看、能听、能调用本地 App 功能的 Agent。Chrome 浏览器内置的 AI 助手已经在生产环境使用了 LiteRT-LM这也是它跨平台能力的一个佐证。但端侧部署不是「下载模型就能跑」这么简单。模型加载、算子兼容、性能验证这三个环节每一个都有具体的坑。下面我会从实际配置出发把这条路径走通同时说明如何用 TaoToken 的统一 Key/API 通道衔接云端调试和端侧部署——毕竟端侧模型能力有限复杂推理还是得回云端而统一通道能让你的调试和部署用同一套接口规范。2. 接入前的准备TaoToken 统一通道与端侧环境在真正把模型塞进手机之前你需要先解决一个现实问题端侧模型的调试和验证往往需要在 PC 上先跑通逻辑再移植到移动端。而 PC 上的调试如果直接用云端 API接口规范和端侧又不一样来回切换很麻烦。TaoToken 的统一 Key/API 通道就是用来抹平这个差异的——你用同一套 Base URL 和 Key既可以在 PC 上调用云端大模型做复杂推理验证也可以在端侧用 LiteRT-LM 做本地推理两者通过统一的接口规范衔接。TaoToken 的 API 地址是https://taotoken.net/api官网是https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content。你需要先在控制台创建一个 API Key这个 Key 在后续的云端调试和端侧混合方案中都会用到。具体操作路径进入控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsole在 API Keys 页面生成一个新的 Key。生成后保存好因为页面刷新后不会再完整显示。如果你需要查看接入文档可以访问https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdoc里面有完整的接口说明和示例代码。端侧环境方面你需要准备以下工具链Android 开发环境Android Studio 最新版NDK 组件LiteRT-LM 依赖 JNI 绑定必须安装 NDK。安装路径是 File → Settings → SDK Manager → SDK Tools → 勾选 NDK 和 CMake。模型文件从 Hugging Face 的 litert-community 页面下载.litertlm格式的模型。以 Gemma 3 1B IT 为例下载地址是https://huggingface.co/litert-community/Gemma3-1B-IT。注意不要下载成 GGUF 或 safetensors 格式LiteRT-LM 不认这些。依赖配置在 Android 项目的settings.gradle或项目根build.gradle中添加仓库然后在app/build.gradle中添加 LiteRT-LM 的依赖。版本号方面LiteRT-LM 仍在快速迭代撰写本文时最新版本是 0.10.0但请以 GitHub 官方仓库的最新 release 为准。这里有一个关键决策点你是纯端侧部署还是端云混合纯端侧适合隐私敏感、离线可用的场景但模型能力受限于 1B~2B 级别。端云混合则是把简单问答、隐私敏感请求交给端侧 LiteRT-LM复杂推理、长上下文、知识密集型请求路由到云端 API。TaoToken 的统一通道让这个路由逻辑变得简单——你只需要在代码里判断请求类型然后决定走本地引擎还是走https://taotoken.net/api的云端接口。如果你打算长期做端侧 Agent 开发建议同时了解一下 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-plan它提供的是面向编码和 Agent 场景的长期通道方案和端侧部署的调试需求能形成互补。环境准备好之后下一步就是具体的配置片段。我会给出可复制的 Gradle 依赖、EngineConfig 配置和基准测试代码你可以直接拿去改。3. 可复制的端侧推理配置从 Gradle 到 EngineConfig这一节是整篇文章的核心操作部分。我会给出完整的配置片段包括 Gradle 依赖、模型加载、后端选择、多模态配置和基准测试代码。你按照步骤复制粘贴改一下模型路径就能跑。3.1 Gradle 依赖配置首先在项目根目录的settings.gradle中确认仓库配置。如果你用的是新版 Android StudiodependencyResolutionManagement块通常在settings.gradle里dependencyResolutionManagement { repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { google() mavenCentral() maven { url uri(https://jitpack.io) } } }然后在app/build.gradle中添加 LiteRT-LM 的依赖dependencies { implementation com.google.ai.edge.litertlm:litertlm-android:0.10.0 }注意版本号 0.10.0 是撰写本文时的版本LiteRT-LM 迭代很快建议去 GitHub 官方仓库确认最新 release。另外这个库依赖 NDK 的 JNI 绑定如果你的 Android Studio 没有安装 NDK编译时会报NDK not configured的错误。安装路径是 File → Settings → SDK Manager → SDK Tools → 勾选 NDK 和 CMake然后同步 Gradle。3.2 模型加载与 EngineConfig 配置模型文件不要打包进 APK。一个 557MB 的模型文件会让安装包体积爆炸用户下载困难更新成本也高。推荐的做法是应用首次启动时从服务器下载模型到设备私有目录这样安装包小、模型可独立更新、还能做完整性校验。模型下载完成后用EngineConfig初始化推理引擎。以下是一个完整的配置片段import com.google.ai.edge.litertlm.Backend import com.google.ai.edge.litertlm.Engine import com.google.ai.edge.litertlm.EngineConfig // 模型文件路径从私有目录读取 val modelPath File(filesDir, gemma3-1b-it-int4.litertlm).absolutePath // 引擎配置 val config EngineConfig( modelPath modelPath, backend Backend.NPU(), // 优先 NPU不支持时回退 GPU maxNumTokens 1024, // 控制总 Token 数影响内存占用 cacheDir cacheDir.absolutePath ) // 初始化引擎首次初始化可能需要 30-60 秒 val engine Engine(config) engine.initialize()这里有几个关键参数需要解释。backend指定推理后端可选Backend.CPU()、Backend.GPU()、Backend.NPU()。NPU 性能最好但兼容性取决于设备芯片GPU 兼容性更广但性能约为 NPU 的 1/14CPU 是兜底方案。maxNumTokens控制总 Token 数直接影响内存占用低端设备建议设为 512 或 1024。cacheDir用于缓存编译后的算子首次初始化慢是因为要做算子编译后续启动会快很多。3.3 多模态模型的视觉后端配置如果你用的是多模态模型比如支持图像输入的 VLM必须显式指定visionBackend否则初始化会失败val config EngineConfig( modelPath modelPath, backend Backend.GPU(), visionBackend Backend.CPU(), // 多模态模型必须指定视觉后端 maxNumTokens 1024 )这个坑我踩过第一次用多模态模型时只配了backend没配visionBackend结果初始化直接抛异常报错信息是Vision backend not specified。加上visionBackend Backend.CPU()之后就正常了。3.4 推理执行与流式输出引擎初始化完成后创建 Session 执行推理import com.google.ai.edge.litertlm.Content val session engine.createSession() // 同步推理 val response session.generateResponse( Content.Text(请用三句话介绍量子计算) ) println(response) // 流式推理适合长文本生成 val stream session.generateResponseAsync( Content.Text(讲一个关于 AI 的故事) ) stream.collect { token - print(token) // 逐 token 输出 }流式推理在移动端体验上很重要。用户不需要等整个回答生成完才看到内容而是逐字出现感知延迟大幅降低。实测下来NPU 后端下流式输出的首 token 延迟约 0.12 秒后续 token 以超过 100 tokens/s 的速度吐出体验接近云端 API。3.5 基准测试代码要验证端侧推理的性能你需要拿到 TTFT、解码速度、内存占用这三个核心指标。LiteRT-LM 提供了BenchmarkInfo接口val benchmarkInfo conversation.getBenchmarkInfo() val decodeSpeed benchmarkInfo.tokensPerSecond // 解码速度tokens/s val totalTime benchmarkInfo.totalTimeSeconds // 总耗时秒 val ttft benchmarkInfo.timeToFirstTokenSeconds // 首 token 延迟秒 Log.d(LiteRT-LM, TTFT: ${ttft}s, Decode: ${decodeSpeed} tok/s, Total: ${totalTime}s)跑基准测试时建议用固定的输入文本比如 1024 token 的输入分别在 CPU、GPU、NPU 三种后端下各跑 5 次取平均值。这样你才能拿到可对比的数据而不是被单次波动误导。3.6 内存管理与低端设备适配在 RAM 小于 4GB 的低端设备上需要做额外配置。首先在AndroidManifest.xml中启用大堆内存application android:largeHeaptrue ... /application然后限制上下文长度maxNumTokens设为 512 或更低。模型选择上优先用 ≤2B 参数的 INT4 量化模型。如果还是内存不足可以考虑用 0.5B 级别的小模型虽然能力下降但至少能跑起来。配置部分到这里就完整了。接下来是验证环节——你怎么确认配置生效了、性能达标了、没有踩到算子兼容的坑。4. 验证请求与成功结果从 TTFT 到算子兼容配置写完之后你需要一套验证流程来确认端侧推理真的跑通了而不是「编译通过但运行时崩溃」。这一节我会给出具体的验证步骤和预期结果包括基准测试、算子兼容检查和端云混合路由的验证。4.1 基准测试步骤第一步是跑通单次推理。用一段固定的输入文本比如 1024 token 的英文段落调用generateResponse确认能正常返回结果。如果这一步就失败大概率是模型文件路径不对或格式不对。第二步是采集性能数据。用上一节的BenchmarkInfo代码分别在 CPU、GPU、NPU 三种后端下跑。预期结果参考如下以骁龙 8 Elite Gen 5 运行 Gemma 3 1B 为例后端TTFT1024 token 输入解码速度内存占用CPU~12s~5 tok/s基准GPU~1.5s~40 tok/s中等NPU~0.12s100 tok/s低如果你的 NPU 后端 TTFT 在 1 秒以上说明 NPU 没有真正生效可能回退到了 GPU 或 CPU。检查方式是看日志里有没有NPU backend initialized的输出或者用芯片厂商的 profiling 工具确认。第三步是长序列测试。把输入长度拉到 2048 或 4096 token观察内存占用和解码速度的变化。端侧设备的内存带宽有限长序列下解码速度会下降这是正常现象。如果内存直接爆掉说明maxNumTokens设太大了需要调低。4.2 算子兼容检查LiteRT-LM 的算子兼容性是端侧部署最容易踩坑的地方。不是所有模型的所有算子都能在 NPU 上执行部分算子会回退到 CPU导致性能下降。检查方法是看初始化日志里有没有fallback to CPU的警告。常见的算子兼容问题包括自定义激活函数、非标准注意力变体、动态 shape 操作。如果你用的模型是从 Hugging Face 下载的预转换.litertlm文件通常已经做过算子适配兼容性较好。但如果你自己转换模型就需要用 LiteRT 的转换工具检查算子支持列表。一个实用的排查技巧先用 CPU 后端跑通确认模型本身没问题再切到 GPU最后切到 NPU。如果 CPU 能跑但 NPU 崩溃那就是算子兼容问题需要换模型或等框架更新。4.3 端云混合路由验证端侧模型能力有限复杂推理还是得回云端。TaoToken 的统一通道让这个路由变得简单。以下是一个路由判断的伪代码示例suspend fun routeRequest(prompt: String): String { val complexity estimateComplexity(prompt) // 估算复杂度 val isPrivacySensitive checkPrivacy(prompt) // 检查隐私敏感 return if (complexity THRESHOLD !isPrivacySensitive) { // 简单请求走端侧 LiteRT-LM localEngine.generateResponse(Content.Text(prompt)) } else { // 复杂请求走云端 TaoToken API cloudClient.chatCompletion( baseUrl https://taotoken.net/api, apiKey TAOTOKEN_API_KEY, model gpt-4o, messages listOf(Message(user, prompt)) ) } }验证这个路由是否生效你可以分别发一条简单请求和一条复杂请求看日志里走的是本地引擎还是云端接口。简单请求比如「今天天气怎么样」复杂请求比如「帮我分析这段代码的时间复杂度并给出优化方案」。4.4 成功结果的判定标准一次可复现的端侧推理验证成功标准包括模型能正常加载并初始化单次推理能返回合理结果NPU 后端下 TTFT 低于 0.5 秒解码速度超过 50 tokens/s内存占用低于 2GB长序列输入不崩溃端云路由能正确切换。如果这些指标都达标说明你的端侧部署配置是有效的。接下来就是排查常见错误——那些我踩过的坑你大概率也会遇到。5. 本篇常见错排查401、local proxy failed 与算子回退端侧部署的报错和云端 API 的报错不太一样但有些是共通的。这一节我整理了几类高频错误包括 TaoToken 云端调试时的 401、本地代理配置问题、LiteRT-LM 的算子回退和 OAuth 相关报错。5.1 401 UnauthorizedKey 没配对这是 TaoToken 云端调试时最常见的错误。报错信息通常是{error: {message: Invalid API key provided, type: invalid_request_error}}原因很简单API Key 没配、配错了、或者用了过期的 Key。排查步骤确认https://taotoken.net/api的请求头里Authorization: Bearer sk-xxx的 Key 是完整的确认 Key 没有多余空格确认 Key 没有过期。如果你在端侧代码里硬编码了 Key检查一下有没有被混淆或截断。5.2 local proxy failed本地代理配置问题这个报错通常出现在你用了本地代理工具的场景。报错信息类似local proxy failed: connection refused排查方向确认代理地址和端口是否正确确认代理服务是否在运行确认端侧设备的网络能访问到代理。注意端侧设备手机、手表和 PC 不在同一个网络环境时localhost 代理是访问不到的需要用局域网 IP 或公网地址。5.3 reading choices响应解析失败这个报错出现在你调用云端 API 后解析响应时Error: reading choices: unexpected end of JSON input原因通常是响应体为空或格式不对。排查确认请求的Content-Type是application/json确认请求体是合法的 JSON确认 API 返回的是标准 OpenAI 格式的响应。如果你用的是流式接口需要按 SSE 格式逐行解析不能直接当完整 JSON 解析。5.4 OAuth 相关报错如果你用的是 Claude Code 或类似的 OAuth 认证流程可能会遇到OAuth token expired or invalid排查确认 OAuth token 没有过期确认回调地址配置正确确认 scope 包含所需的权限。对于 Claude Code 的接入Base URL 填https://taotoken.net/apiKey 填你的 TaoToken API KeyModel ID 填你需要的模型比如claude-sonnet-4-20250514。这三件套缺一不可。5.5 LiteRT-LM 算子回退端侧特有的报错日志里会出现Operator X not supported on NPU, fallback to CPU这不是致命错误但会导致性能下降。排查确认模型是 litert-community 的预转换版本确认 LiteRT-LM 版本是最新的如果还是回退考虑换一个算子兼容性更好的模型。部分自定义算子确实无法在 NPU 上执行这是硬件限制只能等框架更新或换模型。5.6 模型加载失败报错信息Failed to load model: invalid .litertlm format原因下载的模型文件不是.litertlm格式或者文件损坏。排查确认从 litert-community 页面下载的是.litertlm后缀的文件确认文件大小和页面标注一致确认下载过程中没有中断。如果你从其他来源拿了 GGUF 或 safetensors 文件LiteRT-LM 是不认的需要先转换。5.7 内存不足崩溃报错信息java.lang.OutOfMemoryError: Failed to allocate a XXX byte allocation排查降低maxNumTokens换更小的模型0.5B 或 1B启用android:largeHeaptrue确认设备 RAM 是否真的够用。低端设备上跑 2B 模型确实吃力这时候要么换模型要么把复杂请求路由到云端。这些错误覆盖了端侧部署和云端调试的主要场景。遇到报错时先看日志里的具体错误信息再对照上面的排查方向基本能定位到问题。6. 端云协同的下一步统一通道与 Coding Plan端侧部署跑通之后你会发现一个现实LiteRT-LM 能覆盖的场景是有限的。1B~2B 的模型做简单问答、隐私敏感推理、离线可用场景没问题但遇到复杂推理、长上下文、知识密集型任务还是得回云端。这时候统一通道的价值就体现出来了。TaoToken 的 API 通道https://taotoken.net/api让你在端侧和云端之间切换时不需要改接口规范。端侧用 LiteRT-LM 的本地引擎云端用 TaoToken 的 OpenAI 兼容接口两者的调用逻辑可以封装成同一个抽象层。你只需要在路由层判断请求类型然后决定走本地还是走云端。如果你打算长期做端侧 Agent 开发Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-plan提供的是面向编码和 Agent 场景的长期通道方案。端侧 Agent 的工具调用、代码生成、多轮对话这些场景和 Coding Plan 的定位是匹配的。你可以把它理解为端侧推理的云端补充——端侧负责即时响应和隐私保护云端负责复杂推理和知识密集型任务。模型对话功能https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chat可以用来快速验证模型能力在把某个模型部署到端侧之前先在云端跑一遍看看效果确认值得端侧部署再动手。API Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keys则是你创建和管理 Key 的地方端侧和云端共用同一套 Key 体系。从云端到端侧完整的 LLM 部署能力图谱是云端 vLLM 做高并发 API 服务PC 端 Ollama/LM Studio 做开发调试移动端 LiteRT-LM 做离线推理。三者不是替代关系而是互补关系。TaoToken 的统一通道把这三者串起来让你在不同场景下用同一套接口规范减少切换成本。端侧部署的未来展望短期看是更多模型支持Qwen、Mistral、DeepSeek和更小的模型0.5B 甚至更小中期看是端侧多模态成熟和端云协同标准化长期看是端侧可运行 7B 甚至更大模型NPU 成为手机标配离线 AI 成为默认。LiteRT-LM 在这条路径上占据的是移动端 NPU 加速这个关键生态位。你现在就可以动手从 Hugging Face 下载一个 Gemma 3 1B 的.litertlm模型按照第 3 节的配置片段在 Android 项目里跑通用第 4 节的基准测试验证性能遇到报错对照第 5 节排查。跑通之后再考虑用 TaoToken 的统一通道把端云路由接起来。这条路径我走过坑不少但走通之后你手里就多了一个能在手机上离线跑大模型的完整方案。