AI时代移动端开发：“端侧AI”被混同于“Gemini Nano跑在你手机上”，但Nano在2026年依然只在有限旗舰机型上可用，真实工程架构必须按L1系统Nano→L2自带LiteRT→L3传统ML Kit→L4云端API做四层降级，而且降级逻辑官方不提供、必须自己写——一个普通App团队想做端侧AI功能，到底该从哪一层切入才不至于第一版就背上四层兼容的债？

一、导语：一个被过度简化的隐喻

2023年Google I/O之后，“Gemini Nano”几乎成了移动端AI的代名词。媒体叙事高度一致：手机将拥有本地大模型，隐私、离线、低延迟三大红利随之而来。两年多过去，到2026年，这一叙事的工程现实却呈现出明显的收敛：Nano的可用范围仍然集中在Pixel与少数与Google深度合作的旗舰机型上，通过Android AICore以系统组件形式分发，第三方应用通过ML Kit GenAI APIs或Firebase AI Logic间接调用，而非直接持有模型权重。

这一现实并不意外。系统级大模型的分发涉及模型体积、芯片NPU适配、内存预算、热管理与合规审查，任何一项都足以把“全量设备可用”推迟数年。真正值得讨论的问题不是“Nano什么时候普及”，而是：在一个Nano只覆盖少数设备、LiteRT需要自带模型、ML Kit只覆盖传统任务、云端API始终可用的世界里，一个普通App团队应该如何设计自己的端侧AI架构？

笔者认为，当前社区讨论中存在一个系统性偏差：把“端侧AI”当作一个整体能力来规划，而不是当作一组能力差异极大、可用性差异极大、维护成本差异极大的分层能力来规划。这种偏差的直接后果，是团队在第一版就试图接入全部四层，最终背上沉重的兼容债务。本文的目的，是把这一债务显性化、可定价化，并给出可操作的切入路径。

本文评述：把端侧AI视为“分层可用性谱系”而非“单一技术栈”，是理解当前移动端AI工程复杂度的关键前提。任何跳过分层直接谈“端侧大模型落地”的方案，都隐含了对设备覆盖率的过度乐观假设。

二、背景与问题定义：端侧AI的“可用性断层”

2.1 概念澄清：端侧AI、系统级模型与应用级模型

在展开分析前，需要给出三个准确定义，避免后续论证滑移。

端侧AI（On-device AI）：指推理计算发生在用户设备本地、不依赖网络往返的AI能力集合。其判定标准是推理执行位置，而非模型来源。一个随App打包的量化模型在本地推理，属于端侧AI；一个通过系统服务在本地推理的模型，同样属于端侧AI。

系统级模型（System-level Model）：由操作系统或系统组件分发、维护、更新的模型，应用通过系统API调用，不持有权重。Gemini Nano经由Android AICore分发即属此类；Apple在iOS 26中开放的Foundation Models框架亦属此类。

应用级模型（App-level Model）：由应用自行打包、随应用版本分发、由应用团队负责量化与适配的模型。通过LiteRT（原TensorFlow Lite）、ONNX Runtime Mobile、ExecuTorch等运行时加载的模型属于此类。

三者的关键差异不在“是否端侧”，而在谁承担分发成本、谁承担适配成本、谁承担版本漂移风险。这一差异构成了后文四层架构划分的根本依据。

2.2 可用性断层的三个维度

“Nano只在有限旗舰机型可用”只是断层的一个切面。完整的断层至少包含三个维度：

维度	典型表现	工程后果
设备覆盖断层	系统级模型仅限特定SoC与旗舰机型	必须为大多数设备准备回退路径
能力覆盖断层	系统级模型擅长生成，传统ML Kit擅长分类/检测	不同任务需路由到不同层
质量覆盖断层	端侧量化模型与云端大模型存在可感知质量差	需定义质量降级可接受阈值

这三个维度相互独立，意味着“接入四层”不是冗余设计，而是对三类断层的分别应对。但分别应对的代价，正是本文要讨论的“降级债”。

2.3 问题的准确表述

综合上述，本文要回答的问题可以精确表述为：

给定一个能力需求集合 R、一个目标设备分布 D、一个可接受的维护预算 B，如何选择端侧AI的接入层级子集 L ⊆ {L1, L2, L3, L4}，使得在满足 R 在 D 上的最低可用性约束下，长期维护成本最小？

这个表述把“该从哪一层切入”从直觉问题转化为约束优化问题。它不追求“最优解”的精确计算（因为成本函数难以完全量化），但提供了一个结构化的思考框架，后文第5、6节将据此展开。

三、四层架构的逐层解剖：能力、边界与代价

本节逐层分析L1至L4的能力边界与工程代价。需要强调的是，四层并非严格的“优劣排序”，而是“分发主体不同、适配责任不同”的分类。L4并非最差，L1并非最优，选择取决于任务与设备分布。

3.1 L1：系统级Nano（Android AICore / Apple Foundation Models）

L1的本质是“借用系统能力”。在Android侧，Gemini Nano通过AICore以系统组件形式存在，应用侧主要通过ML Kit GenAI APIs（如Summarization、Proofreading、Rewriting、Image Description等）或Firebase AI Logic的on-device路径调用。在iOS侧，Apple在2025年WWDC公布的Foundation Models框架于iOS 26开放，提供约30亿参数级别的端侧基础模型，通过Swift API访问。

能力特征：以自然语言生成、摘要、改写、图像描述为主；模型经过系统级对齐与安全过滤；推理在NPU上执行，延迟通常在数百毫秒量级（具体随任务长度与设备而异）。

边界：设备白名单严格；API能力受系统版本约束；应用无法微调、无法替换模型、无法控制量化策略；输出受系统安全层影响，某些任务可能被拒绝。

代价：接入成本最低（调用系统API），但可用性最低、可控性最弱。对应用而言，L1是“锦上添花”层，而非“保底”层。

本文评述：L1最大的工程陷阱不是“设备少”，而是“能力不可预期”。系统级模型的输出受安全策略、系统版本、甚至地区配置影响，应用无法通过契约保证行为一致性。因此L1适合做“增强体验”，不适合做“核心链路唯一依赖”。

3.2 L2：自带LiteRT（应用级模型）

L2的本质是“自带模型”。LiteRT（TensorFlow Lite在2024年后的新品牌名）是Google的端侧推理运行时，支持CPU/GPU/NPU委托（delegate），通过NNAPI、GPU delegate或厂商Delegate（如Qualcomm QNN、MediaTek NeuroPilot）加速。ONNX Runtime Mobile与ExecuTorch是同类替代方案。

能力特征：模型完全由应用控制，可针对任务微调、量化（INT8/INT4）、裁剪；可覆盖分类、检测、分割、嵌入、小规模生成等广泛任务；设备覆盖取决于模型体积与算力需求，通常可覆盖中高端机型。

边界：模型体积受APK/IPA大小与下载策略约束；大模型（>1B参数）在移动端内存与热管理上挑战显著；Delegate兼容性碎片化，同一模型在不同SoC上性能差异可达数倍。

代价：接入成本中等偏高，需要模型转换、量化、Delegate选型、性能调优、设备矩阵测试。但可控性最强，是“能力自主”的核心层。

关于LiteRT的官方文档与性能最佳实践，可参考 Google AI Edge LiteRT 官方文档 与 LiteRT GitHub 仓库。

3.3 L3：传统ML Kit（预置任务API）

L3的本质是“预置任务”。ML Kit提供文本识别（OCR）、条码扫描、人脸检测、姿态检测、语言识别、翻译、智能回复等任务级API，部分能力端侧执行、部分依赖云端。其价值在于“开箱即用”，无需模型管理。

能力特征：任务边界清晰，API稳定，覆盖设备广；端侧子集（如OCR、条码、人脸）在多数中端机型可用。

边界：无法自定义模型；任务固定，无法覆盖生成式需求；部分API的端侧/云端行为由SDK内部决定，应用不可控。

代价：接入成本低，维护成本低，但能力天花板明显。L3是“稳定保底”层，适合作为传统CV/NLP任务的默认路径。

ML Kit的端侧能力清单与版本说明见 ML Kit 官方文档。

3.4 L4：云端API（生成式与重型任务）

L4的本质是“借用云端算力”。Gemini API、OpenAI API、Claude API、以及各家云厂商的模型服务均属此类。其能力上限最高，覆盖生成、推理、多模态等重型任务。

能力特征：质量最高、能力最全、迭代最快；不受设备算力约束。

边界：依赖网络；存在延迟、成本、隐私合规、服务可用性风险；部分场景（离线、敏感数据）不可用。

代价：接入成本低，但运营成本（token费用、带宽）与合规成本持续存在。L4是“能力上限”层，也是“最后兜底”层。

3.5 四层能力矩阵对比

层级	分发主体	设备覆盖	可控性	接入成本	维护成本
L1 系统Nano	OS/系统组件	极低（旗舰白名单）	极低	低	低（但不可控）
L2 自带LiteRT	应用	中（取决于模型）	高	中高	高
L3 ML Kit	SDK	高	低	低	低
L4 云端API	云服务商	全（需网络）	中	低	中（费用/合规）

这张矩阵揭示了一个反直觉的结论：接入成本与维护成本并不同向变化。L1接入最易但可控性最差；L2接入最难但可控性最强；L3/L4接入易、维护中等。团队决策时若只看“接入成本”，几乎必然选择L1+L4，然后在设备覆盖不足时被迫补L2，最终形成“先简后繁”的返工债。

四、为什么官方不提供降级逻辑：责任边界的工程学

4.1 官方SDK的设计哲学：单层能力，明确契约

无论是ML Kit、LiteRT还是Firebase AI Logic，官方SDK的设计目标都是“把单层能力做到稳定、可预期、有明确契约”。ML Kit不负责判断“你的设备是否该用Nano”；LiteRT不负责判断“模型加载失败后是否该转云端”；Firebase AI Logic的on-device路径也不负责跨层编排。这不是能力缺失，而是责任边界的主动划分。

从工程经济学角度看，跨层降级逻辑高度依赖应用的具体任务、质量阈值、成本模型与合规要求，无法抽象为通用SDK。一个摘要任务可以接受云端兜底，一个敏感医疗文本任务可能禁止上云；一个图像描述任务可以接受Nano的简化输出，一个法律文书校对任务可能要求更高精度。这些差异使得“通用降级SDK”在商业上不成立。

本文评述：官方不提供降级逻辑，本质上是把“策略责任”留给应用。这一划分是合理的，但社区普遍低估了它的工程含义——降级逻辑不是几行if-else，而是一套需要设计、测试、监控、演进的子系统。

4.2 降级逻辑的四个隐含子系统

一个生产级的降级编排，至少包含四个子系统：

（1）能力探测子系统：判断当前设备是否支持L1（系统版本、AICore状态、模型下载状态）、L2（模型文件完整性、Delegate可用性、内存余量）、L3（SDK版本、所需任务API可用性）、L4（网络状态、鉴权状态）。探测必须是异步、可超时、可缓存的，否则会拖慢首屏。

（2）路由决策子系统：根据任务类型、质量要求、成本预算、用户偏好，决定优先层与回退顺序。路由规则应可配置、可灰度、可远程更新，而非硬编码。

（3）执行与回退子系统：处理超时、异常、质量不达标三类失败，并触发下一层。回退需有次数上限与总超时预算，避免“层层回退导致用户等待过长”。

（4）可观测子系统：记录每层命中率、失败原因、延迟分布、质量评分，用于持续优化路由规则与发现设备碎片化问题。

这四个子系统的存在，解释了为什么“四层兼容”不是简单的API调用叠加，而是一个需要独立设计的工程模块。第7节将给出代码骨架。

五、“降级债”模型：把兼容成本显性化

5.1 债务的构成

本文提出“降级债”（Fallback Debt）概念，指因接入多层降级能力而产生的、随时间和设备碎片化持续累积的维护成本。其构成可分解为四项：

债务项	来源	累积方式
兼容债	设备/系统版本碎片化	每新增一层，测试矩阵乘性增长
漂移债	系统模型/云端API版本更新	行为变化导致路由规则失效
质量债	各层输出质量不一致	需持续校准阈值与提示词
认知债	团队对四层行为理解不足	排障时间随层数增加

需要说明的是，上述四项债务的“成本”难以精确货币化，本文不给出虚构的量化数字，而是给出相对关系：兼容债随层数近似乘性增长；漂移债随外部依赖数量线性增长；质量债与认知债随层数线性增长但单次成本高。这一相对关系足以支撑“渐进式分层”的结论。

5.2 债务的“利率”：为什么越晚还越贵

降级债的特殊性在于其“利率”很高。原因有三：

其一，接口耦合的路径依赖。若第一版把L4调用直接嵌入业务代码，后续补L1/L2时需重构调用链；若第一版就抽象出统一的“AI能力接口”，后续加层只需实现接口。前者是返工，后者是扩展，成本差异显著。

其二，测试资产的沉没成本。每层都需要独立的设备矩阵、性能基线、质量评估集。若第一版只做L4，测试资产仅覆盖网络与云端；后续补L2时需重建端侧测试资产，且旧资产无法复用。

其三，用户预期的锁定。若第一版以L4的高质量输出建立用户预期，后续在无网场景降级到L2的量化模型，用户感知的质量落差会被放大。反之，若第一版就以端侧为主、云端为辅，用户预期更易管理。

本文评述：降级债的“利率”高于多数技术债，因为它同时涉及接口、测试资产与用户预期三条路径。这意味着“先上线再补层”的策略在端侧AI场景下风险更高，第一版的架构选择具有超常的杠杆效应。

六、切入决策框架：普通团队该从哪一层开始

6.1 三角模型：能力需求、设备覆盖、维护成本

切入层的选择，本质是在三个约束间求平衡：

能力需求（R）：任务是否需要生成式能力？是否需要多模态？质量阈值多高？若任务可用传统CV/NLP解决，L3即可；若必须生成式，则L1/L2/L4三选一。

设备覆盖（D）：目标用户中旗舰机占比多少？是否必须覆盖中低端？若必须全覆盖，L1不可作为唯一层；若目标用户以旗舰为主，L1可作为首发层。

维护成本（B）：团队是否有端侧模型工程能力？是否有设备测试实验室？是否有持续监控体系？若答案是否，应优先选择维护成本低的层。

6.2 四类典型团队的切入建议

团队类型	特征	建议首发层	后续扩展
A. 无端侧经验的内容类App	需摘要/改写，团队无ML工程	L4 + L1（可选增强）	视覆盖率补L2
B. 有CV基础的图像类App	需检测/分割，有模型团队	L2（自带模型）+ L3兜底	按需接L4做重型任务
C. 隐私敏感的工具类App	数据不可上云	L2为主 + L1增强	L4仅用于非敏感任务
D. 追求全覆盖的社交App	用户设备跨度大	L4 + L3（保底）	L1/L2按设备分层灰度

这张表的读法是：首发层应选择“能力满足 + 覆盖达标 + 维护可承受”的交集，而非“技术最先进”的层。对多数普通团队，L4+L3的组合能以最低债务覆盖第一版需求；L1作为增强项按设备灰度接入；L2仅在确有模型自主需求时引入。

6.3 反模式清单：第一版最容易踩的四个坑

反模式一：把L1当保底。误以为“系统有Nano就能用”，结果在非白名单设备上功能直接不可用。正确做法：L1只做增强，保底用L3或L4。

反模式二：四层一次性接入。为“未来兼容”提前实现四层，导致测试矩阵爆炸、发布周期拉长。正确做法：先两层，留好接口，按数据驱动加层。

反模式三：降级逻辑散落在业务代码。每个调用点各写一套if-else，后续无法统一治理。正确做法：抽象统一的能力接口与编排器（见第7节）。

反模式四：无质量阈值定义。只判断“成功/失败”，不判断“质量是否达标”，导致低质量端侧输出被当作成功。正确做法：为每层定义质量评估集与阈值。

七、工程实现：降级编排的代码骨架与验证清单

7.1 统一能力接口

第一步是把“AI能力”抽象为与层级无关的接口。以下为Kotlin示意骨架（伪代码级，省略具体SDK调用）：

interface AiCapability<Req, Res> {
    val layer: AiLayer
    suspend fun isAvailable(ctx: Context): Boolean
    suspend fun execute(req: Req): Result<Res>
    fun qualityScore(res: Res): Float
}

enum class AiLayer { L1_SYSTEM, L2_LITERT, L3_MLKIT, L4_CLOUD }

class AiOrchestrator<Req, Res>(
    private val chain: List<AiCapability<Req, Res>>, // 按优先级排序
    private val minQuality: Float,
    private val totalTimeoutMs: Long
) {
    suspend fun run(req: Req): Result<Res> = withTimeout(totalTimeoutMs) {
        for (cap in chain) {
            if (!cap.isAvailable(context)) continue
            val r = runCatching { cap.execute(req) }.getOrNull() ?: continue
            if (cap.qualityScore(r) >= minQuality) return@withTimeout Result.success(r)
        }
        Result.failure(NoCapabilityAvailable())
    }
}

这段骨架的关键设计点有三：链式优先级、可用性预检、质量阈值门控。它把“降级”从散落的if-else收敛为一个可测试、可观测的编排器。实际实现中，isAvailable需缓存结果（避免每次调用都探测），qualityScore需基于离线评估集校准。

7.2 能力探测的异步与缓存

L1的探测涉及AICore状态查询，可能耗时数百毫秒；L2的探测涉及模型文件校验与Delegate初始化，可能耗时更久。若在用户点击时同步探测，首屏体验会被拖垮。推荐做法：应用启动后在后台线程预热探测，结果写入本地缓存，调用时读缓存并设置TTL（如24小时或系统版本变更时失效）。

// 探测结果缓存示意
data class CapabilitySnapshot(
    val layer: AiLayer,
    val available: Boolean,
    val reason: String?,
    val timestamp: Long,
    val deviceFingerprint: String // 系统版本+SoC+模型版本
)

// 失效条件：TTL过期 或 deviceFingerprint变化
fun isValid(s: CapabilitySnapshot, now: Long): Boolean =
    now - s.timestamp < TTL_MS && s.deviceFingerprint == currentFingerprint()

7.3 验证清单

上线前，建议按以下清单逐项验证（可作为团队内部检查表）：

• 🌿 每层均有独立的可用性探测，且探测不阻塞主线程；
• 🌿 每层均有超时设置，总超时预算不超过用户可接受上限；
• 🌿 每层均有质量评估集与阈值，低质量输出能触发回退；
• 🌿 回退次数有上限，避免“层层回退”导致长等待；
• 🌿 每层命中率、失败原因、延迟分布已接入监控；
• 🌿 路由规则可远程配置，支持灰度与快速回滚；
• 🌿 无网、弱网、飞行模式、系统版本升级等边界场景已覆盖；
• 🌿 隐私敏感数据在L4路径上有明确的脱敏或禁止策略。

八、关键数据与案例：设备覆盖、性能与成本

8.1 设备覆盖的公开信息

关于Gemini Nano的设备覆盖，Google官方文档（ML Kit GenAI APIs与AICore相关页面）列出的支持设备以Pixel 8/9系列及部分合作厂商旗舰为主，且对系统版本、AICore版本、模型下载状态有额外要求。具体清单随文档更新而变化，读者应以 ML Kit GenAI 官方文档 与 Android Gemini Nano 开发者页面 的最新版本为准。本文不引用可能过时的具体机型数量，以避免误导。

Apple侧，Foundation Models框架在iOS 26开放，支持设备为具备足够神经引擎算力的机型（Apple官方文档标注为A17 Pro及更新芯片的设备）。这一覆盖同样属于“旗舰优先”策略。

本文评述：两家平台方的策略高度一致——系统级模型优先覆盖旗舰，再逐步下探。这一策略在商业上合理（保证体验下限），在工程上则意味着应用团队不能把L1当作普遍可用能力。任何“Nano已普及”的判断，都与官方文档的覆盖范围不符。

8.2 性能的量级关系（非精确基准）

本文不虚构具体毫秒数，但可给出基于公开资料的量级关系：系统级模型（L1）在NPU上执行短文本任务通常在数百毫秒量级；应用级量化模型（L2）的延迟高度依赖模型规模与Delegate，小模型可在数十毫秒，大模型可能达秒级；云端API（L4）的端到端延迟受网络影响，通常在数百毫秒至数秒。读者应以自身设备矩阵的实测为准，可参考 LiteRT 性能最佳实践 中的测量方法。

8.3 成本结构的定性分析

L4的成本以token计费与带宽为主，随调用量线性增长；L2的成本以模型体积（下载流量、存储）与工程人力为主，前期投入高、边际成本低；L1/L3的成本以集成与测试为主，运营成本低但能力受限。对高频调用的功能，L2的长期成本通常低于L4；对低频、高质量要求的任务，L4更经济。这一权衡应在产品设计阶段就明确。

九、对比与局限：四层架构的适用边界

9.1 四层架构的适用条件

四层架构并非万能。它适用于：目标设备跨度大、任务对延迟/隐私敏感、团队有一定工程能力、产品生命周期较长（>1年）的场景。对于设备分布集中（如企业内部专用设备）、任务单一、生命周期短的项目，两层甚至单层即可，强行四层反而是过度设计。

9.2 与“单一云端”和“单一端侧”方案的对比

方案	优势	劣势
单一云端	简单、质量高、迭代快	离线不可用、隐私风险、成本随量增长
单一端侧	隐私好、离线可用、边际成本低	覆盖受限、质量上限低、维护重
四层降级	覆盖与质量兼顾、可渐进演进	架构复杂、债务高、需持续治理

9.3 局限与风险

四层架构的主要风险包括：路由规则随外部API变化而失效（漂移债）；端侧模型质量评估缺乏统一标准（质量债）；多设备测试成本高（兼容债）；团队认知负担重（认知债）。这些风险无法完全消除，只能通过“渐进式分层 + 可观测 + 远程配置”来管理。

十、前沿预判：2026—2028的技术走向

基于公开的路线图与学术进展，笔者认为未来两三年有三个值得关注的趋势：

其一，系统级模型的下探速度将慢于社区预期。模型体积、NPU适配、热管理、合规审查共同决定了“全量设备可用”需要多代硬件迭代。这意味着L1在2026—2027仍将是“旗舰增强层”，而非“普遍保底层”。

其二，应用级小模型（L2）的工程工具链将快速成熟。LiteRT、ExecuTorch、ONNX Runtime Mobile在量化、Delegate、性能分析上的工具链持续完善，模型转换与调优的门槛在下降。这会使L2从“专家专属”走向“有ML基础的团队可用”。

其三，跨层编排可能以“平台服务”形式出现，但短期内仍需自建。云厂商与平台方有动机提供“端云一体”的编排服务（如Firebase AI Logic的混合路由），但其通用性受限于应用的具体策略。笔者认为，未来2—3年内，自建编排器仍是多数团队的现实选择，但可逐步复用平台提供的探测与路由原语。

本文评述：上述预判基于公开路线图与技术趋势的推理，不构成对具体产品发布时间的承诺。读者应持续跟踪官方文档与学术会议（如MobiCom、MobiSys、NeurIPS的端侧推理相关论文）的最新进展。

十一、结论与展望

回到开篇的问题：普通App团队该从哪一层切入？本文的答案是——不要问“哪一层最好”，要问“哪一层的债务我付得起”。对多数团队，首发选择L4+L3的组合，以最低债务覆盖第一版需求；L1作为增强项按设备灰度接入；L2在确有模型自主需求时引入。架构上，第一版就应抽象统一能力接口与编排器，为后续加层留好扩展点，而非一次性实现四层。

端侧AI的工程复杂度，本质上是“可用性断层”与“降级债”的复合体。把这两者显性化、可定价化，团队才能在能力上限与债务下限之间做出理性选择。随着系统级模型下探、L2工具链成熟、平台编排原语丰富，这一选择的空间会逐步扩大，但“策略责任在应用”的基本格局在短期内不会改变。

展望未来，笔者认为端侧AI将沿着“能力分层化、编排服务化、评估标准化”三条路径演进。应用团队的竞争力，不在于接入了几层，而在于能否用最小的债务，把合适的能力送到合适的设备上。

十二、参考文献与拓展资源

12.1 主要参考文献（8—9篇）

1. Google AI Edge. LiteRT: Lightweight runtime for on-device AI. 官方文档，2025. 链接
2. Google Developers. ML Kit GenAI APIs: On-device generative AI. 官方文档，2025. 链接
3. Android Developers. Gemini Nano and AICore: On-device model access. 官方文档，2025. 链接
4. Apple Developer. Foundation Models framework. 官方文档，2025. 链接
5. Qualcomm AI Hub. AI Engine Direct and on-device model deployment. 技术文档，2025. 链接
6. Google AI Edge. LiteRT Performance Best Practices. 官方文档，2025. 链接
7. Meta AI. ExecuTorch: On-device inference for PyTorch models. 开源文档，2025. 链接
8. ONNX Runtime. ONNX Runtime Mobile: Cross-platform on-device inference. 官方文档，2025. 链接
9. Firebase. Firebase AI Logic: Hybrid on-device and cloud inference. 官方文档，2025. 链接

12.2 拓展教程与视频资源

• 🌿 ML Kit GenAI Android 集成教程（官方，含设备要求与错误码说明）
• 🌿 LiteRT Android 快速上手（官方，含Delegate配置）
• 🌿 WWDC 2025 Foundation Models 相关 Session（官方视频）
• 🌿 LiteRT GitHub 示例仓库（含模型转换与性能分析脚本）
• 🌿 🔒 复制本站文章内容需登录并达到 L3。当前：未登录