06 · 端侧 AI 与移动端推理：模型能下载，不等于应用能交付

定位：端侧研究与原型边界复盘。 edge-llm 和 face-android 主要是教程；iOS 食物识别目录有四个 Swift 源文件，但本次未编译、未做真机推理，也未验证其图像输入 API。不能将它们汇总成“已完成多端 AI 部署”。

端侧 AI 的吸引力很明确：减少网络依赖，让敏感数据有机会留在设备上，降低远程调用需求。但它并不是把云端 SDK 换成本地模型文件这么简单。

claude-demo 的端侧语言模型、人脸检索和食物识别资料，恰好覆盖了三个经常被混在一起的问题：模型能力、运行时能力，以及应用是否正确使用了这些能力。

一、模型、运行时和应用是三个兼容性层次

模型层决定输入张量、输出含义和可处理任务；运行时负责算子、量化、设备后端和执行；应用负责图像、文本、权限、线程、状态及用户交互。

不同运行时和模型格式的选型资料，可以帮助建立候选，但不能替代实际转换与测试。模型使用了某种量化方式，不意味着目标设备后端支持全部算子；运行时能够加载文件，也不意味着预处理与训练时一致。

资源约束同样如此。手机总内存不是应用可以自由使用的内存。语言模型的权重、KV Cache、工作区，叠加图像缓存、界面和系统占用后，峰值才是实际约束。冷启动、连续运行温度和电量也应该进入评估。

二、人脸识别是一条管线，不是一个模型名称

Android 研究提供了较完整的逻辑分解：

flowchart LR Camera["相机图像"] --> Detect["检测人脸与关键点"] Detect --> Align["坐标转换与对齐"] Align --> Quality["质量检查与必要的活体判断"] Quality --> Embedding["特征嵌入及归一化"] Embedding --> Search["向量检索"] Search --> Threshold["阈值、身份决策与拒识"]

这里最容易出问题的不是矩阵乘法，而是接口：关键点是哪个语义顺序，坐标是像素还是归一化值，前置相机是否镜像，旋转后坐标如何变换，模型输入的通道顺序与数值范围是什么。

原始实战示例把部分关键步骤放在未实现的辅助函数里，而且检测器关键点与五点对齐模板之间没有完整适配链。因此它适合解释结构，不是可以直接落地的 Android 工程。

量化模型还必须核对实际张量类型、维度和缩放参数。不能因为文件名含 INT8，就继续按未经确认的浮点数组解释所有输入输出。

三、距离语义和语言边界也属于算法正确性

归一化向量的平方欧氏距离与余弦相似度满足：

squared_l2 = 2 - 2 * cosine_similarity
cosine_similarity = 1 - squared_l2 / 2

前提是两侧向量都已单位归一化。如果索引返回的是距离，业务却按“分数越高越相似”筛选，模型本身再好也没有意义。

JNI 边界还要求数据类型一致。教程中的示意代码选择浮点距离，却使用 sizeof(jlong) 从浮点对象复制数据。在常见 ABI 下，这可能从 4 字节对象读取 8 字节；它不应被直接搬进工程。应建立明确的距离、标签和排序返回契约，而不是靠注释解释不安全的打包方式。

这是教程代码的审查结论，不是对一个已部署 Android 产品的漏洞通报。

四、检索阈值必须匹配图库与样本量

如果单次非同人比较的误接受概率为 false_accept_rate，在独立、同分布假设下，对 gallery_size 个对象比较时，至少一次误接受的概率为：

1 - (1 - false_accept_rate) ** gallery_size

只有在小概率条件下，才可以近似为两者相乘。现实图库存在相关性，不能不加说明地把独立假设当成精确业务模型。

还需要警惕样本量：一万次独立负样本试验即使没有发生误接受，单侧 95% 二项上界仍约为 0.00030，不能据此证明百万分之一的误接受率。原始资料中更低尾部阈值的讨论，应补充足够的数据和统计方法。

阈值之外还要考虑图库更新、不同光照设备、人口群体差异、重复注册，以及允许用户拒绝或删除生物特征数据的机制。本地运行不自动完成隐私治理。

五、iOS 原型：哪些已经存在，哪些仍是接口假设

食物识别原型已有 SwiftUI 界面、拍照/选图入口、分析状态、可用性检查和结构化结果类型。这些都是可以定位到源码的实现。

但分析器把 UIImage 直接放入 Prompt，通过注释宣称支持图像输入。本次没有对应 SDK 编译证据；目录内也没有找到独立的 Vision 请求、图像识别模型或视觉结果转文本管线。因此，准确描述应当是“含待验证模型接口的应用原型”，不能写成“端侧多模态识别已跑通”。

如果所选语言模型接口不接受图片，可以考虑以下替代设计：

图像 → 经验证的视觉识别模块 → 结构化识别事实
     → 可选语言解释模块 → 业务校验与界面展示

这条管线需要新增实现，不能把它反过来描述为仓库现状。支持哪个系统、SDK、设备和地区，也必须由实际接口文档、编译与运行时可用性共同确认，而不是拼接不同教程里的版本号。

图 06：已有模块、未核验的直接图像输入、建议新增的视觉识别链分别标注。虚线不代表已经实现的 Vision 管线，也不表示 SDK 编译或真机推理通过。

六、结构化输出还需要语义与状态检查

FoodItem 定义了热量、营养元素和置信度等字段。类型约束能减少解析失败，却不保证数值合理、份量准确或模型置信度经过校准。

食物份量无法仅凭一个整数类型变得可测量。原型中的结果应当明确作为估算，不能包装成专业测量或个体医疗依据。

交互上还应验证：分析期间更换图片、重复点击、取消、模型不可用和旧请求迟到时，结果是否仍属于当前图片。明确的请求身份和取消策略是移动端正确性的一部分，不只是界面体验优化。

七、最小验收矩阵

层次	建议验证内容
模型输入输出	类型、形状、归一化、量化参数与样例一致性
平台与资源	SDK 编译、设备可用性、冷启动、峰值内存、连续运行
算法质量	真实标注集、拒识、阈值与统计置信范围
应用状态	图片切换、取消、错误、重复请求和结果归属
数据治理	授权、用途、日志、存储、同步和删除路径

这份矩阵是后续落地建议，本次没有执行移动端编译或性能实验。

结语

端侧 AI 的技术门槛，往往出现在模型与应用之间的连接处。资源账本、张量契约、距离语义、统计验证和异步状态都做对，才有资格讨论“部署完成”。