iPhone 端侧双模型实践：聊天与图像模型如何共存

把大语言模型和图像生成模型同时塞进一部 iPhone，最大的敌人不是算力，而是内存。开发者 Nathan 在 DEV 社区分享了他构建 Anvil 的经验——一个完全跑在 iPhone 上的私有 AI 助手，试图回答一个越来越现实的问题：端侧 AI 到底能做到什么程度？

两套模型，一个手机

Anvil 的架构很直接：聊天侧用 Gemma 4 E2B 通过 LiteRT LM 运行，图像侧是 Anvil Dream——一个 SDXL Lightning 变体，经 Apple 的 ml-stable-diffusion 转换为 Core ML 格式，在神经引擎上生成 1024x1024 图像。

两个模型的能力都不弱，但问题在于它们不能同时驻留内存。Nathan 的解法是运行时切换：根据用户当前操作，动态加载对应的模型，用完即卸。这是端侧 AI 应用绕不开的工程妥协。

iPhone 的统一内存架构在跑单个模型时表现不错，但两个模型加在一起的权重和中间激活值会迅速吃掉可用内存。Nathan 提到，这也是 Anvil 要求 iPhone 15 Pro 或更新机型的原因——旧设备的内存根本撑不住。

LiteRT LM 是 Google 推出的端侧大模型推理运行时，前身为 TensorFlow Lite（TFLite），后由 Google AI Edge 团队重命名并扩展以支持生成式 AI 工作负载。它针对移动端 CPU、GPU 和 NPU 做了算子级优化，支持权重量化（int8、int4）以压缩模型体积，并提供流式输出和 KV Cache 复用等推理加速机制。相比直接调用云端 API，LiteRT LM 让开发者能在设备本地完成 token 生成，避免网络往返延迟和数据外传。其局限在于受限于手机内存带宽和散热，可用模型规模和上下文长度都远小于云端部署。

ml-stable-diffusion 是 Apple 官方开源的转换工具库，用于将 Stable Diffusion 系列的 PyTorch 权重转换为 Core ML 格式，使模型能调用 iPhone 的神经引擎（Neural Engine）进行推理。转换过程中需要处理算子映射、权重精度选择（如 float16）以及模型分割，以适配神经引擎的内存限制。转换后的 Core ML 模型可与 Swift 应用深度集成，利用 Apple Silicon 的统一内存架构减少数据拷贝开销。这也是 SDXL Lightning 能在 iPhone 上以 1024x1024 分辨率生成图像的关键前提。

隐私优先的设计选择

Anvil 的定位很清晰：一个不依赖云端的私人助手。首次通过 WiFi 下载模型后，聊天、语音、笔记处理、任务管理、照片和文档操作全部在手机本地完成。没有账户体系，网络搜索和 iCloud 备份都是可选项，且与端侧聊天数据保持隔离。

这种设计牺牲了部分便利性——比如无法调用 GPT-4 级别的云端大模型——但换来的是数据不出设备的确定性。对于处理敏感信息的场景，这个取舍可能是值得的。

不过提一嘴，端侧小模型在复杂推理任务上的表现与云端大模型仍有明显差距。Gemma 4 E2B 在轻量级对话和指令跟随上够用，但面对多步骤逻辑推理或长上下文理解时，能力边界会比较明显。

Gemma 4 E2B 中的 E2B 指 Effective 2 Billion，即有效参数量约 20 亿。该命名来自 Google 对 Gemma 系列小模型的标注方式，强调模型在特定推理配置下的等效规模，实际参数可能因架构设计而略高。20 亿参数级别在手机端属于偏大的量级，通常需要 int4 量化后才可部署，文件体积约 1-2 GB，运行时占用内存更高。这类模型适合短对话、摘要和简单指令跟随，但在需要多步推理链或精确事实回忆的任务上，与 70B 级别的云端模型差距显著。

端侧 AI 的现实约束

Nathan 在帖子中主动征求测试者关于速度、续航和易用性的反馈，这本身就说明了端侧 AI 面临的核心挑战。

内存是硬约束。 两个模型不能共存意味着用户在不同功能间切换时会感受到加载延迟。这种体验在云端方案中几乎不存在，但在端侧是物理限制。

散热和续航是隐性成本。 神经引擎持续推理会产生热量，电池消耗也远高于普通应用。对于需要频繁使用 AI 功能的用户，这可能会成为日常使用的障碍。

模型更新是运维难题。 云端模型可以随时迭代升级，端侧模型需要用户重新下载数百 MB 甚至 GB 级的权重文件。

统一内存架构（Unified Memory Architecture，UMA）是 Apple Silicon 的核心设计之一：CPU、GPU 和神经引擎共享同一块物理内存池，无需在芯片间显式拷贝数据。这一架构在跑单个模型时优势明显，减少了数据传输延迟和冗余内存占用。但当两个大模型同时驻留时，它们共享同一内存上限，iPhone 15 Pro 的 8 GB 内存需同时承载系统、应用以及模型权重与中间激活值，实际留给 AI 模型的空间可能只有 3-4 GB。这就是 Anvil 必须运行时切换而非同时加载的根本原因，也是旧款 iPhone（6 GB 或更少内存）无法运行的根本瓶颈。

端侧 AI 的适用边界在哪里

Anvil 的尝试揭示了一个正在成形的趋势：端侧 AI 不是要替代云端 AI，而是在特定场景下提供一种不同的选择。

适合端侧的场景包括：对隐私极度敏感的个人数据处理、网络不稳定或不可用的环境、以及需要低延迟响应的简单交互。不适合的场景则包括：复杂推理、大规模知识检索、需要频繁更新模型能力的应用。

从工程角度看，Anvil 展示的模式——多个专用小模型按需切换——可能比试图在手机上跑一个全能大模型更务实。Gemma 负责理解和生成文本，SDXL Lightning 负责图像，各司其职，通过调度层协调资源。

这种架构的代价是用户体验上的碎片化，但换来的是在手机内存限制下依然能提供多种 AI 能力。对于想在端侧做 AI 应用的开发者来说，Anvil 的实践提供了一个值得参考的样本。

Anvil 目前已在 TestFlight 上公开测试，Beta 测试者可免费使用 Anvil Pro。