先确定要验证什么
如果目标是离线聊天，先只做文本输入输出；如果目标是看图、语音或其他多模态，再检查该模型与当前 llama.cpp 构建是否支持对应输入。不要因为模型卡写了“多模态”，就假设现有 iOS 示例已经完整支持。
原始实践笔记讨论了 Qwen3.5-0.8B 与 Gemma 4 E2B，并记录了作者设备上的主观体验。这些记录没有形成统一、可复现实验条件，所以本文不把两者的 token/s 当作通用排名。
准备模型文件与构建环境
在 Mac 上准备 Xcode、可用于设备签名的开发配置、足够的可用磁盘空间，并从可信模型发布页取得 GGUF。核对模型许可证、文件完整性、量化版本及架构是否受所用 llama.cpp 版本支持。这里的步骤对应官方 SwiftUI 示例；仓库命令与工程位置若在未来版本变化，以所链接 README 为准。
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
./build-xcframework.sh
open examples/llama.swiftui/llama.swiftui.xcodeproj- 按 SwiftUI 示例 README 从仓库根目录构建框架；如工程名称或路径变化，使用 README 的当前命令。
- 在 Xcode 中配置自己的签名团队与目标设备。
- 把有权使用的 GGUF 模型交给示例应用，先验证单轮短文本提示与完整输出。
- 记录使用的仓库提交、模型文件名与量化格式、iPhone 机型、iOS 版本，再开始比较参数。
为什么模型能下载却运行失败
排查时把四笔预算分开：GGUF 文件占用的是磁盘；载入模型权重、上下文及 KV cache 占用运行内存；图像模型可能还要加载 mmproj 等额外文件；生成过程还会有临时缓冲与系统、其他 App 的占用。可下载不等于能在当前设备内存中稳定推理。
先用短上下文和纯文本模型复现，再逐步增加上下文长度或打开图像输入。若应用被系统终止、首字迟迟不出或温度明显上升，保存 Xcode 日志与设备内存数据；不要仅凭模型文件大小预测峰值内存。
表格可左右滑动，查看完整比较 →
| 现象 | 先检查 | 下一步 |
|---|---|---|
| 模型打不开 | GGUF 格式、量化版本与运行时支持 | 回到官方示例的已支持模型 |
| 短提示可用，长提示失败 | 上下文长度和 KV cache | 缩短上下文，记录峰值内存 |
| 文字可用，图片失败 | 模型能力、mmproj 和多模态运行时 | 按 mtmd 文档逐项核对 |
| 速度波动大 | 首字时间、持续生成、温度与后台占用 | 固定提示与设备状态重复测试 |
怎样测出对自己产品有用的性能
首字时间与持续 token/s 应分开测；提示长度、输出长度、上下文长度、量化格式、线程与加速设置要固定。每次从相同设备状态开始，至少记录多次结果及范围。也要测一次较长对话，因为短提示跑得快不代表长会话不受内存和温控影响。
原稿里的速度数字来自特定设备与配置记录，本文没有复测，也不推断在其他 iPhone 上能达到相同速度。选择模型时同时看任务完成质量、失败率、峰值内存与设备温度，而不是只看 token/s。
落到 App 时的最小安全边界
把模型下载、版本更新和本地数据权限与推理逻辑分开设计。对用户明确显示模型大小、离线能力及是否会向外发送内容；本地推理不自动意味着应用里其他网络请求也不存在。遇到超内存或能力不足时给出可恢复的提示，不把小模型输出包装成可靠的专业建议。
资料核对日期：2026-11-06。本文是基于作者技术笔记重新组织的部署路径；官方示例与多模态接口持续变化，实际接入前再核对当前仓库文档。