安卓 AI 新范式：本地 DeepSeek + 云端 Claude步骤详解

移动端 AI 应用正在从“纯云端调用”走向“端云协同”。过去很多安卓 AI 工具会直接接入 Claude、GPT、Gemini 等云端大模型，能力强、效果稳定，但也带来了三个明显问题：调用成本高、网络依赖强、用户隐私压力大。尤其是办公助手、学习工具、移动端代码助手这类产品，大量请求其实只是短问答、代码片段生成、表格公式解释、文本改写，如果全部交给云端旗舰模型处理，成本并不划算。

但完全依赖本地模型也并不现实。端侧小模型虽然可以离线运行，适合处理高频轻任务，但在万字级文档理解、复杂合同分析、长代码审查等场景下，仍然容易出现遗漏、误判或幻觉。因此，更适合中小团队的方案是：DeepSeek 本地模型承接日常任务，Claude 云端模型处理低频但高价值的长文本任务。

本文将围绕安卓端 AI 工具开发，介绍一套基于 DeepSeek 本地离线推理 + Claude 云端长文本兜底 的混合架构方案，重点保留核心接口、模型路由和 MNN 本地加载逻辑，去掉过多冗余代码，让文章更适合开发者阅读和落地参考。

---

一、为什么安卓 AI 应用需要混合架构？

在移动端落地 AI 功能时，开发者通常会面临两个极端选择。

一种是纯云端方案。所有请求都发送到 Claude、GPT 或其他云端大模型，优点是模型能力强、长文本理解好、推理质量稳定；缺点也很明显：API 成本随用户量快速增长，一旦网络不稳定，核心功能就会受到影响。

另一种是纯本地方案。将 DeepSeek、Qwen、Llama 等轻量模型量化后部署到安卓端，用户可以离线使用，日常请求几乎没有 API 成本，也更有利于隐私保护。但本地 1B—1.5B 级模型受限于参数规模、上下文长度和移动设备算力，很难稳定处理复杂长文档和高风险推理任务。

所以更合理的方式不是二选一，而是按任务类型分流：

• 短问答、代码片段、数学演算、文本改写：优先走本地 DeepSeek；
• 万字文档、合同 PDF、长代码审计、论文总结：自动切换到 Claude 云端；
• 网络异常、云端超时、用户关闭云端：自动降级为本地离线模式。

这种架构的核心价值不是“模型越多越好”，而是让不同模型出现在最适合的位置上。

---

二、整体架构设计：本地离线层 + 云端按需层

整个项目可以拆成三层：本地推理层、云端模型层、模型路由层。

1. 本地推理层：DeepSeek 负责高频轻任务

本地层可以选择 DeepSeek 轻量模型，例如 DeepSeek-Coder 1B/1.3B 系列，或者 DeepSeek-R1-Distill-Qwen-1.5B 这类小参数推理模型。前者更适合代码生成、代码解释、函数补全；后者更适合学习问答、数学推理和短文本分析。

在安卓端部署时，可以借助 MNN 这类移动推理框架。MNN 官方定位是轻量化推理引擎，面向移动端、嵌入式和端侧 LLM 场景，适合将模型量化后集成到 App 内运行。

在项目内测中，INT4 量化后的 1B—1.5B 级模型可以作为安卓端本地推理起点。原文保留的实测数据为：模型资源占用约 2.1GB，骁龙 8 Gen3 机型单轮短输入推理平均约 690ms，低配天玑 920 机型约 1250ms。需要注意的是，这类数据会受到模型格式、量化方式、线程数、上下文长度、设备散热和是否启用硬件加速等因素影响，因此更适合作为项目内测参考，而不是行业通用结论。

2. 云端模型层：Claude 处理长文本和复杂任务

云端层主要负责本地模型不擅长的场景，例如合同分析、长篇 PDF 总结、论文阅读、复杂代码审计、业务报告生成等。

如果使用 Claude 3.5 Sonnet，需要注意它官方发布时的上下文窗口为 200K tokens，而不是“百万级上下文”。Anthropic 在后续 Claude 平台文档中也提到，部分更新模型和配置可支持更大的上下文窗口。因此文章中更稳妥的写法应是“Claude 长上下文模型”，而不是简单写成“Claude 3.5 Sonnet 具备百万级上下文”。

3. API 管理层：统一云端模型配置

当项目同时接入 Claude、DeepSeek 云端 API、测试环境和正式环境时，base URL、模型名、密钥、超时策略很容易散落在多个模块中，后续维护成本较高。

在这类多 API 管理场景中，可以使用 koalaapi 这类大模型 API 聚合平台，用于统一管理云端模型调用入口、鉴权参数和模型切换配置。需要注意的是，本地 MNN 推理仍然建议由 App 内部通过 JNI 或本地服务直接调用，不必强行纳入 API 聚合链路。

---

三、模型路由策略：短任务本地跑，长任务云端兜底

原始方案中使用 inputText.length > 15000 判断是否调用 Claude，这种方式简单直接，但在生产环境中不够严谨。因为中文、英文、代码、Markdown、JSON、PDF OCR 文本的 token 密度不同，单纯按字符数判断可能会误判。

更合理的方式是结合三个条件：

第一，看输入长度。超过本地模型可承受范围时，优先走云端。

第二，看任务类型。合同审核、长 PDF、代码审计、论文总结这类高复杂任务，即使字符数不算特别长，也可以优先交给 Claude。

第三，看用户设置。如果用户关闭云端模式，就强制使用本地模型，并在结果中提示能力边界。

为了让文章更简洁，这里只保留核心路由代码：

enum class ModelRoute {
    LOCAL_DEEPSEEK,
    CLOUD_CLAUDE
}

fun decideRoute(
    inputText: String,
    cloudEnabled: Boolean,
    taskType: String? = null
): ModelRoute {
    val tokenEstimate = inputText.length / 2

    val complexTask = taskType in listOf(
        "contract_review",
        "long_pdf",
        "code_audit",
        "research_summary"
    )

    return when {
        !cloudEnabled -> ModelRoute.LOCAL_DEEPSEEK
        tokenEstimate > 15000 || complexTask -> ModelRoute.CLOUD_CLAUDE
        else -> ModelRoute.LOCAL_DEEPSEEK
    }
}

业务调用层可以进一步简化：

suspend fun handleAiRequest(
    inputText: String,
    cloudEnabled: Boolean,
    taskType: String?
): String {
    return when (decideRoute(inputText, cloudEnabled, taskType)) {
        ModelRoute.LOCAL_DEEPSEEK -> {
            localDeepSeek.runInfer(inputText)
        }

        ModelRoute.CLOUD_CLAUDE -> {
            claudeApi.docAnalyze(buildClaudeReq(inputText)).content
        }
    }
}

这段代码不追求完整覆盖所有异常情况，而是展示最核心的工程思路：先判断任务，再决定模型。

四、核心接口封装：Claude 与 DeepSeek 云端备用

云端接口建议分开封装，不要把 Claude、DeepSeek、OpenAI-compatible 请求都混在一个 Retrofit Service 中。这样后续更换模型、调整 base URL 或接入不同计费策略时，维护成本更低。

1. DeepSeek 云端 API 接口

DeepSeek 云端接口可以作为本地推理不可用时的备用方案，也可以处理部分短文本云端任务。

interface DeepSeekCloudApi {
    @POST("v1/chat/completions")
    suspend fun chatRequest(@Body req: ChatReq): ChatResp
}

2. Claude API 接口

Claude 接口单独封装，便于配置独立域名、密钥、模型名和超时策略。

interface ClaudeApi {
    @POST("v1/messages")
    suspend fun docAnalyze(@Body body: ClaudeDocReq): ClaudeResp
}

需要特别说明的是，DeepSeek 官方文档显示，其 API 支持 OpenAI/Anthropic 兼容格式，并提供 Anthropic API 格式的接入地址。这意味着开发者可以使用 Anthropic 风格的请求格式调用 DeepSeek 模型，但这并不等同于“通过 DeepSeek 调用 Claude”。如果项目目标是调用原生 Claude，应使用 Anthropic 官方 API；如果只是希望以 Anthropic 协议调用 DeepSeek，则使用 DeepSeek 的 Anthropic-compatible endpoint。

配置示例可以写成：

{
  "ANTHROPIC_BASE_URL": "https://api.deepseek.com/anthropic",
  "ANTHROPIC_MODEL": "deepseek-v4-flash"
}

这类配置适合接入 DeepSeek 的 Anthropic 兼容协议；如果要直连 Claude，则应替换为 Anthropic 官方地址和对应模型名。

---

五、DeepSeek 本地化部署：MNN 更适合量产，Ollama 更适合验证

DeepSeek 本地部署可以分成两条路线：量产路线和原型验证路线。

1. 量产路线：MNN 原生集成

正式安卓项目建议使用 MNN 这类移动端推理框架，将模型转换、量化、加载和推理过程纳入工程化流程。

常见步骤如下：

1. 准备 DeepSeek 轻量模型权重；
2. 根据 MNN 支持的流程完成模型转换；
3. 进行 INT4 或其他量化压缩；
4. 将模型文件放入 assets 或通过首次启动下载；
5. 通过 JNI 或本地推理模块在 App 内调用。

保留最关键的模型转换示例即可：

mnnconvert -f ONNX \
  --modelFile deepseek-lite.onnx \
  --MNNModel deepseek-lite.mnn

Kotlin 侧只需要暴露一个本地推理入口：

class LocalDeepSeek {
    companion object {
        init {
            System.loadLibrary("deepseek_mnn")
        }
    }

    external fun nativeInfer(prompt: String): String

    fun runInfer(prompt: String): String {
        return nativeInfer(prompt)
    }
}

这里不展开 C++ 推理细节，因为实际项目中还涉及 tokenizer、prefill、decode、采样策略、上下文缓存、内存复用等内容。对博客读者来说，保留 Kotlin 调用入口和 MNN 转换命令已经足够理解整体链路。

2. 原型验证路线：Termux + Ollama

如果团队只是做 Demo 或内部验证，可以先用 Termux + Ollama 快速跑通本地模型：

ollama run deepseek-r1:1.5b

这种方式上手快，但不适合直接量产。原因包括安装流程不可控、用户设备差异大、后台服务管理复杂、资源占用不稳定，以及应用商店审核存在不确定性。量产项目仍然建议走 MNN、NCNN、llama.cpp Android 集成或其他更可控的端侧推理方案。

---

六、缓存优化：用 Room 降低重复请求成本

除了模型分流，缓存也是移动端 AI 应用降本的重要手段。对于办公助手、学习工具、代码解释器这类产品，用户经常会重复请求相似内容，比如固定格式总结、模板生成、常见公式解释等。

Android 官方 Room 是基于 SQLite 的持久化抽象层，常用于本地结构化数据存储和离线缓存场景。官方文档也明确提到，当设备无法访问网络时，应用可以继续读取本地缓存内容。 本文不展开完整 DAO 代码，只保留设计思路：

• 对 Prompt 做 hash，作为缓存 key；
• 保存模型返回结果、使用模型、路由方式和过期时间；
• 用户再次输入相同或高度相似 Prompt 时，优先读取本地缓存；
• 对合同、隐私文档、财务内容等敏感数据，可以默认不缓存或只缓存摘要。

例如：

在某办公助手原型项目的内测样本中，加入本地推理、Prompt 缓存和云端按需路由后，高频场景 API 调用量下降约 68.3%。

---

七、成本与性能收益：核心是把 90% 高频请求留在本地

混合架构最大的价值，是让高频请求尽可能在本地完成，把云端模型留给真正需要它的任务。

日常约 90% 请求可由本地 DeepSeek 承接，只有约 10% 的超长文档、合同解析、复杂代码审查任务进入 Claude 云端。相比所有请求都直连 Claude，月度 API 开销下降约 73.2%。

这个结论在逻辑上是成立的：只要产品中存在大量短文本、高频、重复型任务，本地推理和缓存就会显著减少云端 token 消耗。例如：

• 测试设备：骁龙 8 Gen3、天玑 920 等；
• 测试任务：短问答、代码生成、长文档总结；
• 测试样本：日常请求与长文本请求的比例；
• 成本口径：是否包含失败重试、缓存命中和超时降级。

---

八、稳定性与安全设计：移动端 AI 不能只关注模型效果

移动端 AI 项目上线后，真正影响用户体验的往往不是模型本身，而是网络、缓存、密钥、降级和隐私设计。

1. 云端失败要自动降级

Claude 云端请求可能遇到网络波动、超时、限流或服务不可用。产品内应设置超时和重试策略，如果连续失败，就自动切换到本地 DeepSeek，并在界面上提示：

当前网络不稳定，已切换至离线模式，结果可能不适合处理超长文档。

这比直接报错更符合移动端用户体验。

2. API Key 不应明文写入 App

gradle.properties 可以避免密钥直接暴露在业务代码中，但它并不能彻底防止 APK 被反编译后提取密钥。更稳妥的方式是将长期 API Key 放在服务端，安卓端只持有短期 token，并结合用户鉴权、设备标识和频率限制。

3. 用户应能主动关闭云端

对于涉及合同、简历、病历、财务数据的场景，用户可能不希望内容上传云端。因此，设置页应提供“仅本地离线模式”开关。关闭后，所有请求都由本地 DeepSeek 处理，系统需要明确提示本地模型在长文档和复杂推理上的能力边界。

---

九、典型商用场景

1. 办公助手 App

本地 DeepSeek 可以处理 Excel 函数生成、会议纪要整理、短邮件改写、表格字段解释等任务；Claude 则负责劳动合同审核、报销制度解析、长篇 PDF 总结和跨章节风险提取。

这种模式适合企业内部工具，因为员工日常需求大多是碎片化文本处理，只有少量任务真正需要长上下文模型。

2. 移动端编程工具

本地 DeepSeek-Coder 可以离线生成 Kotlin、JavaScript、Python 代码片段，也可以解释常见报错、生成正则表达式和 SQL 语句。对于大型代码文件、复杂漏洞审计、架构优化建议，则交由 Claude 云端处理。

这样即使用户处于弱网环境，也能使用基础代码助手；联网后则获得更强的长上下文分析能力。

3. 学习刷题 App

学习类产品可以让本地 DeepSeek 负责数学演算、错题解释、知识点总结和短答案生成；Claude 负责长篇教材精读、论文式材料分析、章节总结和个性化学习计划。

这种架构可以在用户体验和推理成本之间取得平衡，避免每一道普通题目都消耗高成本云端 token。

---

十、结语：移动端 AI 的竞争点，是模型调度能力

对于安卓 AI 应用来说，真正成熟的架构不是“所有问题都交给最强模型”，而是根据任务复杂度、输入长度、网络状态、隐私要求和成本预算进行动态调度。

DeepSeek 本地模型适合承担高频、低成本、可离线的轻量任务；Claude 云端模型适合处理低频、高价值、长上下文和高风险任务。两者结合后，既能降低 API 成本，又能提升弱网环境下的可用性，还能让用户在隐私和效果之间获得更多选择。

随着端侧量化技术、移动推理框架和大模型 API 聚合平台逐步成熟，未来移动端 AI 应用会越来越像一个“模型调度系统”：本地模型负责即时响应，云端模型负责深度分析，缓存系统负责降本增效，路由策略负责把每一次请求分配给最合适的模型。

对于中小团队来说，这套 DeepSeek 本地离线推理 + Claude 云端长文本兜底 的混合架构，不仅是降低成本的方案，更是移动端 AI 产品走向稳定商业化的一条现实路径。