把PyTorch训练好的模型部署到iPhone上，最容易卡住的环节往往不是训练本身，而是模型格式的兼容性和推理时的资源调度。Core ML作为苹果原生的端侧推理框架，并不直接读取PyTorch的权重文件，需要先将模型导成TorchScript，再借助coremltools转换成MLModel格式。这个过程如果只是跑通一个小例子问题不大，但真实项目里的多输入、动态形状、自定义算子以及量化设置，都可能让转换结果在模拟器上看起来正常，一到真机就出现无法加载或推理结果异常。
一、模型转换：从PyTorch到Core ML的稳定链路
PyTorch导出TorchScript有两种常用方式：torch.jit.trace和torch.jit.script。trace通过给定一个示例输入，让模型实际跑一次并记录所有张量运算，因此它对输入形状非常敏感，只能处理静态图。如果模型中有if、for这类动态控制流，trace会只保留某一条执行路径，转换结果在真机上可能输出错误。script则会解析Python源码并生成完整的计算图，对控制流的表达能力更强。实际部署时，只要模型代码没有大量无法被TorchScript理解的动态特性，建议优先使用torch.jit.script。
下面是一个导出脚本的示例，同时处理了eval模式和输入张量命名，方便后续coremltools识别。
import torch
import torchvision
model = torchvision.models.mobilenet_v2(pretrained=True)
model.eval()
example_input = torch.rand(1, 3, 224, 224)
scripted_model = torch.jit.script(model)
scripted_model.save("mobilenet_v2_scripted.pt")
# 如果模型结构中有trace不友好的动态逻辑，优先使用script
# 备用方式：traced_model = torch.jit.trace(model, example_input)
得到TorchScript文件后，使用coremltools完成到MLModel的转换。转换时最好显式声明ImageType输入和ClassifierConfig或输出形状，否则得到的模型接口可能不利于iOS端调用。最低部署版本也会影响可用算子和是否支持某些量化组合。比如iOS 14以上才支持部分控制流，iOS 15以上对ML Program的支持更稳定。
import coremltools as ct
model = ct.models.MLModel("mobilenet_v2_scripted.pt")
# 指定输入为图像，尺寸与训练时一致
image_input = ct.ImageType(name="input", shape=(1, 3, 224, 224), scale=1/255.0, bias=[0, 0, 0])
model = ct.convert(
model,
inputs=[image_input],
minimum_deployment_target=ct.target.iOS15,
compute_precision=ct.precision.FLOAT32
)
model.save("MobileNetV2.mlmodel")
print("转换完成")
转换完成后，可以先在Python环境中调用predict验证输出，但真正的兼容性验证必须放在真机上。模拟器和真机在ANE调度、内存限制、模型加载方式上都存在差异。例如某些模型在模拟器上能正常加载，但真机会因为ANE编译失败而走CPU回退，延迟和耗电表现完全不同。建议在转换后立即通过Xcode把mlmodel拖入工程，用最简单的VNCoreMLRequest或直接MLModel接口跑一次前向，确认无加载错误。
二、量化策略：FP16与INT8在端侧的真实收益
Core ML模型通常以FP32精度保存，体积和计算量都偏大。iPhone上的神经网络引擎（ANE）对FP16支持最好，很多模型在导出时直接使用FP16权重和激活，既能减小一半体积，又能在ANE上以接近原生的吞吐运行。INT8量化则进一步把权重压缩到8位整数，配合线性量化参数来还原浮点范围。它的体积收益更明显，但推理精度下降的风险也更高，尤其是对输出分布范围较大的回归任务或对细微数值变化敏感的分割模型。
实际选择时，可以先做FP16，再评估INT8。只要模型不是极端敏感，分类、检测一类的任务通常能接受INT8的精度损失。转换时通过compute_precision和compute_units控制精度与执行设备。
import coremltools as ct
model = ct.models.MLModel("mobilenet_v2_scripted.pt")
image_input = ct.ImageType(name="input", shape=(1, 3, 224, 224), scale=1/255.0, bias=[0, 0, 0])
# FP16量化
model_fp16 = ct.convert(
model,
inputs=[image_input],
minimum_deployment_target=ct.target.iOS15,
compute_precision=ct.precision.FLOAT16
)
model_fp16.save("MobileNetV2_fp16.mlmodel")
# INT8量化：需要提供代表性数据做校准
def representative_data():
for _ in range(10):
yield {"input": torch.rand(1, 3, 224, 224).numpy()}
model_int8 = ct.convert(
model,
inputs=[image_input],
minimum_deployment_target=ct.target.iOS15,
compute_precision=ct.precision.INT8,
representative_data=representative_data
)
model_int8.save("MobileNetV2_int8.mlmodel")
不要盲目相信转换工具打印的“量化完成”。需要准备一小批真实场景的数据，分别跑FP32、FP16和INT8模型，统计输出张量的平均绝对误差或分类Top-1一致率。如果模型输出是概率分布，可以用KL散度；如果是边界框回归，可以直接比较坐标差。通常在100到500张有代表性的数据上做快速验证，就能判断INT8是否可接受。这种方式比在真机上反复打包测试高效得多。
Core ML的INT8量化依赖代表性数据来估计激活值范围，如果校准数据与实际线上输入分布不一致，误差会明显放大。因此校准数据最好从真实用户场景中采样，而不是用训练集的随机子集或纯合成数据。对于输入归一化范围、通道顺序也要与训练时完全一致。
三、推理加速与工程落地：封装、调度与性能测量
MLModel加载后，预测调用默认会由Core ML自动选择执行设备。如果希望模型强制跑在ANE或GPU上，可以通过MLModelConfiguration的computeUnits属性控制。all表示自动调度，cpuAndGPU排除ANE，cpuOnly适合调试。对于量化后的模型，通常保持all让系统在ANE、GPU和CPU之间切换。只有在明确发现ANE回退导致性能抖动时，才手动指定设备。
import CoreML
let modelURL = Bundle.main.url(forResource: "MobileNetV2_int8", withExtension: "mlmodelc")!
let config = MLModelConfiguration()
config.computeUnits = .all
do {
let model = try MLModel(contentsOf: modelURL, configuration: config)
// 使用model.prediction(from:)进行推理
} catch {
print("模型加载失败: \(error)")
}
如果转换时没有使用ImageType，输入就会变成MLMultiArray，iOS端需要手动完成图像缩放、通道转换和归一化，这一步通常比模型前向还耗时。推荐在转换阶段就使用ImageType并配置好scale和bias，让Core ML或Vision框架在端侧高效完成预处理。如果必须使用MLMultiArray，可以通过Accelerate或vImage做像素转换，尽量放在后台线程。
性能测量要使用CACurrentMediaTime或DispatchTime而不是简单的Date，并且在循环预热后取多次平均。首次预测往往会包含模型编译、内存分配和冷启动开销，单独看首次耗时没有参考意义。下面是一个简单的同步测量封装。
import CoreML
import QuartzCore
func measurePrediction(_ model: MLModel, input: MLFeatureProvider, iterations: Int = 100) {
// 预热
for _ in 0..<10 {
_ = try? model.prediction(from: input)
}
let start = CACurrentMediaTime()
for _ in 0..<iterations {
_ = try? model.prediction(from: input)
}
let end = CACurrentMediaTime()
let avgMs = (end - start) / Double(iterations) * 1000.0
print("平均推理耗时: \(avgMs) ms")
}
虽然上面演示了同步调用，但在真实产品中不要把模型预测放在主线程。即使是10毫秒级别的推理，频繁调用也可能挤占UI渲染时间，造成滑动掉帧。建议使用DispatchQueue或OperationQueue串行执行预测，并结合Vision框架的请求回调处理异步结果。如果业务场景是摄像头实时视频流，最好维持固定帧率，丢弃处理不过来的帧，而不是无限制排队。
另一个容易忽略的点是MLModel实例的线程安全。Core ML文档明确指出预测调用可以在多个线程上执行，但同一个输入对象不能被并发修改。若使用MLMultiArray，需要为每路并发预测复制一份输入，或者用锁串行访问。对于高并发请求，可以在对象池中缓存多个模型实例，避免反复加载带来的开销。
部署链路打通只是第一步。模型迭代后要重新走转换、量化、真机验证的闭环，并记录延迟、耗电和精度指标，才能持续保证端侧体验。