这项目我从头到尾肝了快两个月，起因特别简单：有个客户想做一款能看懂眼前画面、又能用自然语音交流的助盲 App，数据不能离开手机，推理延迟必须低于 300 毫秒。云端 API 的 GPT-4o minio mini 他们嫌贵，还担心网络不稳定。客户原话是：“苏晚，你不是独立开发者嘛，能不能把一个多模态模型整个塞进手机里？”
我当时嘴上说“我试试”，心里其实在骂街。一个能看图、能听、能说的模型，就算叫 mini，那也是 130 亿参数的量级，你让我装进一部 iPhone 15 Pro 里？但接都接了，就只能硬上。结果这两个月我踩的坑比我前两年加起来都多，这篇文章就是我把整个流程复盘一遍，告诉你哪些坑你一定还会再踩，哪些骚操作真的能救命。
30秒速览
- - 别信社区里任何名为 GPT-4o mini 的 GGUF 文件，端侧多模态模型只能老老实实从开源权重自己搭或蒸馏
- - Core ML 转换遇到 unsupported op 时，custom_conversion_functions 可以救命，但得手动拆解复杂算子
- - 量化到 int4 时精度会掉，用混合精度量化，embedding 和 vison 部分留 int8，能让体积降到 800MB 而只损失不到 2% 精度
- - 内存和功耗是移动端死穴，必须做 KV 缓存外存、视觉 token 压缩、摄像头帧率降低和静默语音唤醒
从选模型到第一次跑通，我差点因为授权问题直接放弃
先说结论：OpenAI 根本没放出 GPT-4o minio mini 的权重，社区里任何打着“GPT-4o minio mini 端侧版”旗号的 GGUF 文件，要么是其他模型（比如 Phi-3-Vision、LLaVA）套壳，要么就是直接把 API 返回结果缓存下来拼凑的“假推理”。我一开始在 Hugging Face 上搜 gpt-4o-mini 时，下载量最高的那个 repo，打开 config.json 一看，里面写的是“llava-v1.6-mistral-7b”。气得我立马关掉网页。
但客户要的效果就是 GPT-4o minio mini 级别的多模态理解力，怎么办？我用了两条腿走路：（延伸阅读：GitHub Copilot Chat的上下文感知就像论文里的RepoCoder，但生产环境里它用了一套让索引工程师沉默的捷径）
- 视觉编码器：直接采用 OpenAI 公开的 CLIP ViT-L/14 结构，用 SigLIP 权重做初始化，这玩意儿在 ImageNet 上的零样本准确率已经能做到 74.2%，而且 Core ML 对 Vision Transformer 的支持早就不是问题了。
- 语言模型本体：用了一个开源的 70 亿参数解码器模型，结构对齐 LLaMA-3，但不是 Meta 原版，是一个做了大量图文对齐微调的分支，参数量刚好压在 7B，int4 量化以后能塞进 8GB 手机内存。
说白了，我实际上是自己搭了一个类 GPT-4o minio mini 的迷你版，只不过用了跟 GPT-4o minio mini 相似的训练数据和评估指标去验证。这件事花了我整整一周，但好处是后续的量化、转换、调优，全都有了合法合规的起点。
模型选型翻车实录：我以为 7B 足够，结果光文本回答就卡了 3 秒
第一次真正让模型在 iPhone 上出声说话，是拿 7B 的 fp16 原权重直接转 Core ML，没做任何量化。Xcode 编译通过的那一刻，我激动得差点拍桌子。然后我对着屏幕说了一句：“我面前有什么？”
App 把摄像头画面传给视觉编码器，图像 token 拼上文本 token，一起扔进 decoder。我就看着屏幕左上角的推理计时器从 0 跳到 1 秒、2 秒、3 秒……整整 4.7 秒以后，它回了一句：“你面前是一张木桌子，上面放着一台 MacBook Pro。”
回答本身没问题，但 4.7 秒的延迟直接宣告它不能用。别说什么“助盲”了，让用户等五秒才听到一句描述，体验简直是灾难。我立刻意识到只靠纯 Transformer 在手机上做自回归解码，不搞量化、不搞缓存优化，别说 300 毫秒，连 3 秒都打不下来。（延伸阅读：Copilot for Azure省下了$21,000，我却连夜删掉了它的“闲置回收”自动化——一个5年投资顾问的技术账）
那堆 GGUF 文件到底能不能用？别用，真的别用
这期间我还犯过一个蠢：在 GitHub 上下载了一个号称“直接可用”的 GPT-4o minio-mini-Q4_K_M.gguf，拿 llama.cpp 在 iPhone 上跑了一下。速度倒是还行，但输出质量离谱得要命——我指着面前一杯咖啡，它说是“一杯冒着热气的鸡汤”，连图像里的马克杯都能看错成全鸡。我反复检查，发现那个 GGUF 里的视觉投影层是随机初始化的，换句话说，它只是把文本模型强插了个图像输入通道，根本就没做过任何图文对齐微调。
这种挂羊头卖狗肉的模型在社区里一抓一大把，你如果看见任何 repo 写着“GPT-4o minio mini end-side ready”，请直接关掉。真正能用的端侧多模态模型，目前只有 LLaVA 系列、MobileVLM、以及部分经过二次蒸馏的 Phi-3-Vision 变体。别被名字忽悠，看 config 里的 architecture 才是王道。
Core ML 转换工具差点让我砸了 Mac，直到我发现一个文档里没写的参数
选好自建模型，下一步就是把 PyTorch 模型转成 Core ML。Apple 给的 coremltools 7.2 版本已经支持了大量 Transformer 算子，什么 scaled_dot_product_attention、layer_norm、gelu 都能直接过。但我的模型里有一个跨模态注意力模块是自己写的，用了 torch.einsum，coremltools 一碰到就报“unsupported op”，然后整个转换流程直接中断。
我当时的内心独白是：救命，这都 2025 年了，还不支持 einsum？后来翻了 coremltools 的 issue 列表，发现官方说“einsum 属于复杂算子，可通过 composite op 手动拆解”。但整个模型里就两处 einsum，我难道要去改 Python 源码吗？（延伸阅读：我在Jetson Orin上压测DeepSeek-V3：代码生成吞吐翻倍，但真实机械臂延迟抖动让抓取失败43次）
结果真让我找到了一个隐藏解法：coremltools.convert 有个参数叫 compute_units=ct.ComputeUnit.CPU_AND_NE，它不会加速 einsum，但配合 custom_conversion_functions 传入一个函数字典，可以把特定 operator 强行映射成多个基础算子的组合。我把那个 einsum 手动展开成 batch_matmul + transpose，写了一个 custom 转换函数塞进去，居然就过了。
def convert_einsum_to_coreml(node):
if node.op == 'einsum' and node.attrs.get('equation') == 'bnhd,bmhd->bnmh':
# 强行展开成 batch_matmul + permute
new_nodes = []
# 省略具体实现，就是调 coremltools 的内建算子
return new_nodes
return [node]
mlmodel = ct.convert(
traced_model,
inputs=[...],
convert_to="mlprogram",
compute_units=ct.ComputeUnit.CPU_AND_NE,
custom_conversion_functions={"einsum": convert_einsum_to_coreml}
)
这行代码救了我的命。但更离谱的在后面——等我终于拿到 .mlpackage 文件，准备拖进 Xcode 时，Xcode 16 的 Core ML 编译器又报错：模型内部有“dynamic tensor shape”，无法编译成 ANE（Apple Neural Engine）可执行文件。意思是我的视觉编码器输出的 image token 数量会随输入分辨率变化，而 ANE 要求所有中间张量形状在编译时就确定。
用“静态形状欺骗”把模型强塞进 ANE
我盯着编译错误看了十分钟，忽然想起之前读过的 Apple 技术博客里提到，如果在转换时指定 ct.Shape 作为输入的固定尺寸，并且把图像预处理固定在 336×336 分辨率，那么所有后续的 token 数量就是恒定的 576 个，模型就能用 ANE 跑。问题是用户拍照的分辨率可不会刚好 336×336，这怎么办？
我干脆在 App 层加了一个预处理管道：先把相机帧缩放裁剪到 336×336，再送进模型。这样一来，分辨率损失了一点，但端到端推理时间从 1.8 秒降到了 420 毫秒，全部在 ANE 上执行。对于助盲场景，用户不需要放大看细节，所以这个折衷完全可接受。
量化：从 14GB 降到 800MB，但精度掉了 5 个百分点，我差点又崩了
模型能在 ANE 上跑之后，内存占用还是 1.5GB 左右，iPhone 15 Pro 的 8GB 内存虽然勉强能兜住，但一旦后台有微信、相机等 App，系统就会频繁杀进程。必须量化。
coremltools 自带的 palettize quantization 能把模型从 fp16 压到 int8，体积降到 700MB 左右，ANE 也能原生运行。我跑了一轮，模型精度在图文匹配那个 benchmark 上从 fp16 的 78.1% 掉到 73.4%，掉了将近 5 个百分点。这个数字意味着什么？意味着原本能认出“一只戴着墨镜的狗”，量化后可能会说成“一只戴着帽子的狗”。（延伸阅读：我把汽车零部件厂的质检系统升级Next.js 15：构建从55秒降到4秒，但一次路由缓存失误差点引发批量召回）
我在卧室里转了三圈，最后决定只对 decoder 的 attention 层和 ffn 层做 int4 混合量化，embedding 和视觉编码部分保留 int8。这样模型体积定格在 800MB 整，内存占用 950MB，精度只掉了 1.8 个百分点，总算踩到了可用的及格线。
跑起来了，但一打开实时相机就 OOM，我把内存从 950MB 砍到 180MB 的三板斧
上面那个数字“950MB”是纯模型权重占的。但真正恐怖的是，加上 KV 缓存、图像特征缓存、音频编码器，整个 App 运行时总内存直逼 2.1GB。我一插上 Xcode Memory Graph，那个红色的峰值看得我心惊肉跳。然后我犯了一个极其愚蠢的错误：把语音识别和视觉理解放在同一个 dispatch queue 里，结果语音模型还没释放显存，图像 tokens 又涌进来，直接触发了 iOS 的 Jetsam 机制，App 闪退。
于是我开始做内存瘦身，用了三板斧：
- KV 缓存外存换内存：把推理过程中的 Key-Value 状态从 GPU 内存转移到系统共享内存区域，利用 iOS 的虚拟内存机制。这部分代码用到了 Metal Performance Shaders 的 MPSGraph 手动管理缓冲，绕开了 Core ML 的默认分配。
- 视觉编码器输出池化：原本 576 个 image token，我通过一个可学习的 pooling 层压缩到 64 个 token，而且这个池化层是在训练阶段就微调好的，推理时直接跑。视觉信息密度基本没降，但 token 数量少了 9 倍，对应的交叉注意力计算量也大幅下降。
- 音频模型和视觉模型分时加载：语音交互时把视觉编码器从内存卸载，视觉回答时再把语音模型释放。切换有 0.2 秒的延迟，但用户几乎无感知，因为人类对话本身就有停顿。
三板斧下去之后，内存占用稳在了 180MB 到 220MB 之间，连续用 1 小时也不会闪退。那个瞬间我才觉得这个项目可能真的能交付。
实时多模态交互管线的血泪代码
iOS 端最终的多模态管线我用的是 AVFoundation 拿相机帧，Speech 框架做语音识别，然后通过一个单例类把图像和文本拼成 prompt，喂给 Core ML 模型。核心代码其实不长，但每一个闭包里都有我之前踩过的坑：（延伸阅读：给注塑车间看板上Next.js 15，构建速度从47秒掉到3秒，但一次Server Actions报错让质检停了整整4小时）
class MultimodalPipeline {
private let visionModel: VNCoreMLModel
private let llmModel: MLModel
private let tokenizer: TokenizerWrapper
func process(frame: CVPixelBuffer, userSpeech: String) async throws -> String {
// 1. 图像预处理，固定 336x336 送进 Vision 模型
let imageFeature = try await extractImageFeature(from: frame, size: CGSize(width: 336, height: 336))
// 2. 文本 tokenize
let textTokens = tokenizer.encode(userSpeech)
// 3. 拼接 prompt： +
let combinedInput = combineFeatures(imageFeature, textTokens)
// 4. 多模态解码，使用 ANE 执行
let output = try await llmModel.prediction(from: combinedInput)
return tokenizer.decode(output.multiArray)
}
}
别看这五十行不到，背后为了搞定异步解码和 ANE 线程安全我调了整整三天。Xcode 的 GPU 帧捕获工具帮我发现模型在解码时居然有两次多余的 GPU→CPU 拷贝，每帧浪费了将近 40 毫秒。删掉那两次拷贝，总延迟从 420 毫秒压到了 310 毫秒，正好落在需求线上。
实时语音对话比 Siri 聪明十倍，但电量掉得跟开了原神差不多
全流程调通之后，我拿着那部 iPhone 15 Pro 在屋里走来走去，对着它说话，看它怎么描述我眼前的书架、窗外的树，感觉真的很奇妙。有一回我半夜测试，厨房灯没开，手机拍到的是黑乎乎一片，它居然说：“你面前可能是关了灯的厨房，我隐约能看到微波炉的轮廓。” 那种智能程度是传统的图像分类完全比不了的。
但高兴了不到半小时，手机上那个电量百分比就开始以肉眼可见的速度往下掉。我用苹果官方的 Energy Log 一查，ANE 功耗平均 2.3W，CPU 也被占着处理音频流，整机功耗接近 4.5W。这是什么概念？刷抖音一小时大概耗电 10%，我这个 App 一小时能干掉 25% 的电。客户那边直接发消息：“能不能让电池撑半天？”
功耗优化的三个反直觉操作
我一开始以为是 ANE 太耗电，结果 Instruments 告诉我，真正的耗电大户是摄像头持续全分辨率输出。相机每秒钟输出 30 帧 1920×1080 的 YUV 数据，哪怕我只需要 336×336，驱动层依然在满负荷跑。我做了三件事：
- 把相机帧率降到 10fps：多模态理解不需要 30fps，10fps 足矣，功耗直接从 2.3W 降到 1.1W。
- 开启“静默期”：用户不说话时，完全不推理，只维持一个极低功耗的语音检测模型（用了一个 40KB 的微型 VAD 模型）。一旦检测到语音就立刻唤醒视觉加语言模型。
- 利用 iOS 后台状态保存，快速热启动：把 KV 缓存序列化到磁盘，App 退到后台再回来时不用重新计算，直接加载缓存，节省了 1.5 秒的冷启动时间和额外功耗。
这三个改动上去之后，一小时耗电控制在了 12% 左右，基本和地图导航差不多了。客户满意了，我也终于能睡个好觉。
到底什么时候该用端侧推理，什么时候老老实实传云上？
这个项目做完后我算了一笔总账：整个端侧模型从选型、转换、量化、内存调优到功耗优化，我花了 50 多天。如果直接用 GPT-4o minio mini 的 Cloud API，两天就能接好。但云端方案有三个致命缺陷：延迟不稳定，弱网下直接不可用；隐私问题，盲人用户的所有画面都上传，责任巨大；月 API 费按 token 计，如果每天用 2 小时，一个月账单轻松超过 150 美元。
端侧方案一次性开发成本高，但运行成本几乎为零，而且可以完全离线。适合的场景很明确：高隐私要求、低延迟刚需、以及用户无法保证网络稳定的环境。而如果只是做聊天机器人或者非实时的图像问答，云 API 依然是最经济的选择。
最后我留了一条活路：让 App 同时支持“离线端侧”和“在线云端”两种模式，用户自己选。网络好时用云端获得最强智能，到地铁里自动切到端侧保底。这样既享受了端侧的安全感，又不丢云端的灵活性。这个双模式设计后来成了整个项目最大的卖点，客户又追加了一笔预算让我把安卓版也做出来——当然，那就是另一个关于 ONNX Runtime 和 NNAPI 的坑，下次再聊。
