今年 AI 硬件的节奏明显变快了但真正值得开发者注意的消息往往不是“又发布了一款新品”而是“把几个原本分散的技术趋势焊在了一起”。小米这次展示的玄戒 O100 原型机和 AI Cube 真机首秀就属于后者。表面看是自研芯片加一个新硬件实际上它把两个关键词绑定到了一起芯片把 AI 算力搬到本地Xiaomi MiMo 这类端侧模型让 AI 能力在本地真正跑起来。对开发者来说比起发布会上的参数和口号更值得追问的是端侧模型会不会改变我们写应用的方式什么任务适合放在本地跑什么任务仍然要交给云端自研芯片在这套体系里到底扮演什么角色这篇文章不打算做成发布会复述而是拆开这套组合背后的技术逻辑并给出一套可以照着操作的端侧模型最小实践路径。1. 这篇文章真正要解决的问题先说判断玄戒 O100 和 AI Cube 的组合本质上不是“手机芯片的常规升级”而是把 AI 能力从云端大模型主导推向“本地芯片 本地模型”的产物主导。这个变化看起来是硬件新闻实际影响的是软件架构。以前我们写一个 AI 功能默认做法是调云端 API以后越来越多的功能会先尝试在设备端完成只有搞不定的才交给云端。很多开发者对端侧模型的认知停留在“内存占用小、精度差一点的模型”这是一个容易误判的地方。端侧模型不是云端大模型的后退而是另一套产品逻辑它在离线、隐私、时延和成本约束下做推理牺牲一部分上限换来了确定性的体验。换句话说云端模型解决“能不能做到”端侧模型解决“在设备上稳定做到”。这篇文章主要面向三类读者AI 应用开发工程师想判断哪些功能应该迁移到端侧。移动端或嵌入式开发工程师需要理解 NPU、量化、模型格式这些概念。关注 AI 硬件趋势的技术人想透过发布会新闻看清楚产业变化。读完这篇文章你会理解自研芯片与端侧模型为什么必须配套能够区分云端推理与端侧推理的适用边界并且可以跑通一个不依赖特定厂商 SDK 的最小端侧推理示例之后再迁移到具体业务中。2. 为什么自研芯片和端侧模型要放在一起看过去几年手机、汽车、IoT 设备里的 AI 功能绝大多数是“端到端上云”的设备采集数据上传到云端大模型等结果返回。这种模式有几个长期痛点。第一是延迟不可控。网络状况一波动用户体验就从“对话流畅”变成“转圈等待”。对语音助手、实时翻译、拍照场景几百毫秒的延迟差别非常明显。第二是隐私边界模糊。音频、图片、位置信息上传到云端即便有隐私协议用户仍然会对“设备是否在监听”产生疑虑。许多企业甚至因为数据合规要求根本不允许用户数据出设备。第三是成本不可忽视。高并发调用云端大模型推理成本会随着用户规模线性增长规模一大AI 功能从“技术演示”变成“成本黑洞”。端侧模型改变的是推理发生的位置模型直接部署在设备上输入输出都在本地闭环。数据不出设备延迟不依赖网络单次推理的边际成本接近零。但这又带来了新的约束设备内存有限CPU/GPU 算力有限电池有限NPU 的指令集和算子支持也有限。所以端侧模型不是“能跑就行”而是要在模型体积、精度、延迟、功耗四者之间做取舍。这也是自研芯片和端侧模型必须放在一起看的原因。芯片决定硬性边界NPU 算力有多大内存带宽够不够支持的算子是否完整能否高效处理 INT8/INT4 这类量化数据。模型决定软性指标参数量多大结构能否被芯片高效映射量化后精度损失多少。芯片和模型是同一个问题的一体两面。对比维度云端推理端侧推理运行位置云端 GPU/服务器集群手机、IoT、车载等本地设备延迟依赖网络波动大本地计算相对稳定隐私数据需上传合规成本高数据不出设备隐私边界清晰算力上限高可支撑百亿级以上参数模型低通常为十亿级参数以下模型单次推理成本随调用量线性增长接近零边际成本极低离线能力无法离线使用可完全离线运行难点服务端架构、并发、成本控制模型压缩、芯片适配、功耗控制所以单独评估一枚芯片或单独评估一个模型都容易得到片面结论。真正重要的是“芯片指令集 算子库 模型结构 量化策略”的协同程度。小米把玄戒 O100、AI Cube 和 Xiaomi MiMo 放同一场展示目的就是让外界看到这套协同已经可以跑到真机阶段。3. 玄戒 O100 与 AI Cube从芯片到整机的技术组合从目前公开的信息看玄戒 O100 是小米展示的原型 SoCAI Cube 是搭载端侧 AI 能力的新形态设备两者一起出现意味着小米不只是发布一颗芯片而是验证一条“自研芯片驱动端侧体验”的完整链路。之所以强调这是“组合”而非“单点”是因为芯片性能和用户体验之间还隔着模型适配。一颗 SoC 要跑好端侧模型至少要解决三件事算子覆盖模型里的卷积、矩阵乘、注意力计算等算子能否在 NPU 上高效执行而不是退回 CPU。显存与带宽端侧模型推理时参数要频繁读写。带宽不足时NPU 再强也会被数据搬运拖慢。功耗调度同样跑完一次推理是否能把大核、小核、NPU 的功耗调度到最优这对移动设备尤其关键。从逻辑上推理玄戒 O100 这类自研芯片的价值不在于“算力数字比谁大”而在于小米可以针对自家模型做指令集和算子库的定制。自研芯片配合自研模型可以把 INT8/INT4 量化、稀疏化、算子融合这些优化推进到更底层。第三方芯片做通用兼容自研芯片则可以做垂直优化。AI Cube 的价值则在于形态探索。名字里的 Cube 暗示它是一个固定形态的“AI 盒子”很可能侧重于家庭、办公或智能座舱这类场景。核心亮点是内置 Xiaomi MiMo 端侧模型即开即用不依赖云端或者降低对云端的依赖。更稳妥的判断是AI Cube 代表一种产品思路——把端侧模型变成用户可以感知的硬件入口而芯片是支撑这个入口的基础设施。对开发者来说这里有一个关键信号以后 AI 应用的运行环境会更加碎片化不再只有“安卓/iOS 云端 API”这一种组合而是会出现“不同芯片 不同端侧模型 不同厂商的推理 SDK”的矩阵。做 AI 应用的人需要提前考虑模型格式兼容和推理框架抽象层避免被单一厂商绑定。4. Xiaomi MiMo 与端侧模型核心概念与模型选型Xiaomi MiMo 从命名和展示场景来看是小米的端侧模型系列内置在 AI Cube 这样的设备中承担本地推理任务。这里我们不展开具体参数因为目前公开材料有限更值得先讲清楚的是端侧模型这个技术方向本身。端侧模型是指直接部署在终端设备上的 AI 模型参数量通常从几亿到几十亿不等。它同样具备理解、生成、分类、识别等能力只是规模和通用性比云端大模型小换来了体积小、延迟低、可离线运行三个特点。新手最容易误解的是“端侧模型就是缩水版大模型”。实际上端侧模型在工程上更像一个“定向优化产品”。云端大模型追求通用能力模型结构往往庞大且稀疏推理需要高吞吐计算端侧模型追求在受限设备上稳定完成高频任务推理路径更短算子更集中量化后仍需保持可用精度。两者不是继承关系而是分工关系。做模型选型时建议重点看五个维度参数量决定模型体积和内存占用。移动端一般 1B-7B 是比较现实的区间具体看设备内存和 NPU 算力。精度与量化FP16 精度高但体积大INT8/INT4 体积小、速度快但可能有精度损失。选型时要用业务数据集实测。延迟指标单次推理的 P50/P95 延迟既看模型结构也看芯片 NPU 的适配程度。上下文与任务复杂度多轮对话、长文档理解这类任务端侧模型的压力会明显增大必要时需要端云协同。算子兼容性模型是否包含目标芯片不支持的自定义算子决定能否直接上 NPU。端侧模型选型的另一面是工程格式。社区里常见的模型格式包括 ONNX、TFLite、MNN、NCNN、Core ML 等。如果只做原型验证ONNX 是很好的中间格式绝大多数训练框架都能导出且 ONNX Runtime 有丰富的后端支持如果做最终落地通常要转为芯片厂商推荐的格式或直接调用厂商推理 SDK。在实际业务中更推荐的做法是设计“端云协同”架构。简单来说设备端先跑一个轻量模型做快速判断如果置信度足够直接返回结果如果置信度不足或任务复杂度超出端侧能力再请求云端大模型。这个思路既能覆盖大多数高频简单请求又能在复杂场景保留上限。5. 端侧模型开发的运行环境与整体架构在写代码之前先想清楚端侧模型应用的架构。端侧模型通常不是单独存在的模型文件而是夹在“采集、预处理、推理、后处理、业务决策”这条链路中间的一个模块。一个典型的端侧模型模块可能要包含数据接入摄像头帧、音频流、文本输入等。预处理图像缩放与归一化、音频重采样、文本 tokenizer 等。这类逻辑占用的开发时间往往比模型推理本身更多。推理执行加载模型、调用 NPU/CPU 后端执行推理。后处理把输出张量解析成类别、坐标、文本等结构化结果。端云决策判断当前结果是否可信是否需要升级到云端模型。下面给一个环境准备清单。这里的版本号不是硬性要求实际项目请以当前稳定版本为准操作系统Windows 10/11、macOS、Ubuntu 20.04 均可。Python 版本3.8 或更高。依赖库onnxruntime、numpy、pillow。推理框架onnxruntime支持 CPU、CUDA、DirectML 等多种后端。示例模型公开的 MobileNet ONNX 模型用于演示通用流程与小米相关产品无关。安装命令如下pip install onnxruntime numpy pillow安装完成后可以写一个端到端的最小推理流程。下面的示例用图片分类任务演示加载一张图片预处理成模型要求的尺寸执行推理输出概率最高的前 5 个类别。为了保持示例的通用性我们使用 ONNX 格式作为中间载体。如果你的目标芯片是特定厂商平台后续再迁移到对应 SDK。先看完整代码# 文件路径infer_demo.py import sys import numpy as np import onnxruntime as ort from PIL import Image def preprocess(image_path, input_size(224, 224)): 读取图片并预处理为模型输入张量 img Image.open(image_path).convert(RGB) img img.resize(input_size) img_array np.asarray(img, dtypenp.float32) / 255.0 # 使用 ImageNet 数据集的均值和标准差做归一化 mean np.array([0.485, 0.456, 0.406], dtypenp.float32) std np.array([0.229, 0.224, 0.225], dtypenp.float32) img_array (img_array - mean) / std # 将 HWC 转换为 CHW并增加 batch 维度 img_array np.transpose(img_array, (2, 0, 1)) img_array np.expand_dims(img_array, axis0) return img_array def main(image_path, model_pathmobilenetv2-7.onnx): # 1. 创建推理会话 session ort.InferenceSession(model_path, providers[CPUExecutionProvider]) # 2. 获取模型输入信息 input_name session.get_inputs()[0].name input_shape session.get_inputs()[0].shape print(f模型输入名称: {input_name}, 输入形状: {input_shape}) # 3. 预处理图片 input_data preprocess(image_path) # 4. 执行推理 outputs session.run(None, {input_name: input_data})[0] # 5. 后处理取概率最高的 Top 5 probs np.squeeze(outputs) top5 np.argsort(probs)[::-1][:5] print(预测结果 Top 5:) for idx in top5: print(flabel{idx}, prob{probs[idx]:.4f}) if __name__ __main__: if len(sys.argv) ! 2: print(用法: python infer_demo.py 图片路径) sys.exit(1) main(sys.argv[1])这段代码有几个关键点需要说明。预处理部分模型输入是 224x224 的 RGB 图像像素值先缩放到 0 到 1然后做均值方差归一化。这套预处理规则对应 ImageNet 分类模型的标准输入格式换成其他模型时必须阅读模型的输入要求否则会出现精度大幅下降。推理部分session.run的第一个参数是输出张量名传None表示返回所有输出第二个参数是一个字典键是模型输入名值是输入数据。如果你的模型有多个输入这个字典也要包含多个键值对。后处理部分np.squeeze是为了去掉 batch 维度。输出结果的形状通常是[1, num_classes]我们要把它压缩成[num_classes]再用argsort取前 5 个类别。这段代码可以在没有 GPU 的电脑上直接运行适合用来理解端侧推理的完整链路。实际落地上图像预处理通常要改成 C 或移动端代码并针对目标平台优化内存拷贝但流程是一致的。6. 端云协同与模型切换的通用思路端侧模型不是万能的它只在“任务定义清晰、对延迟敏感、数据隐私要求高”的场景里有优势。开发者在架构设计阶段最好直接把端云协同考虑进去而不是先做端侧后面发现搞不定再加云端。端云协同的本质是两层判断一层是“要不要切”一层是“怎么切”。什么时候应该走端侧什么时候切换到云端可以从三个角度判断。第一是任务复杂度。如果任务是固定类别的分类、特定领域的短语音识别、简单指令理解端侧模型足够。如果任务是开放式问答、长文本总结、复杂多轮推理端侧模型大概率不够直接交给云端更合适。第二是置信度兜底。很多任务可以设计成“端侧优先云端兜底”。端侧模型先给一个结果如果结果置信度高于阈值就作为最终结果返回如果置信度低于阈值说明模型没有把握再发起云端请求。第三是网络与资源状态。设备处于弱网状态时与其等待云端失败不如直接用端侧模型给一个“够用”的结果。设备电量低、发热严重时也要减少向云端请求优先保证基础体验。下面是一个简化的端云协同决策示例# 文件路径hybrid_infer_demo.py def hybrid_infer(image): # 1. 先跑端侧模型 local_result local_model.infer(image) # 2. 置信度足够高直接返回 if local_result.confidence 0.85: return local_result # 3. 置信度不足且当前网络可用再请求云端 if network.is_available(): cloud_result cloud_model.infer(image) if cloud_result is not None: return cloud_result # 4. 云端不可用或请求失败返回端侧结果作为兜底 return local_result这个示例展示的是一种可落地的决策模式。实际项目中阈值不能拍脑袋定需要用一批有代表性的样本统计端侧模型在哪些样本上置信度低、哪些样本上犯错再决定阈值设在什么位置。端云协同还需要考虑另一件事模型版本和数据格式的统一。端侧模型和云端模型的输入输出最好使用同一套协议这样上层业务代码只需要关心结果而不需要关心结果来自哪个模型。否则每切换一次模型业务层就要改一次解析逻辑长期维护成本会很高。7. 运行结果与效果验证运行上面的端侧推理示例时命令如下python infer_demo.py cat.jpg正常情况下的输出大约如下模型输入名称: input, 输入形状: [batch_size, 3, 224, 224] 预测结果 Top 5: label281, prob0.9123 label282, prob0.0212 label285, prob0.0157 label287, prob0.0034 label290, prob0.0012如果输出中某个 label 的概率显著高于其他项说明推理链路已经跑通。接下来要做的是效果验证。这里要区分两个概念模型精度验证和工程性能验证。模型精度验证用的是业务数据集。比如你的端侧模型要识别产品缺陷就用一批真实缺陷图片测试准确率、召回率并和云端模型的结果做对比。这类验证通常在模型选型阶段就要做而不是等模型部署完再测试。工程性能验证关注四个指标模型大小决定安装包体积和下载成本也影响设备内存占用。首次加载时间从应用启动到模型加载完成的时间直接影响用户可感知的启动速度。平均推理耗时连续推理多次统计 P50/P95 延迟。注意带 NPU 的设备要区分 CPU 与 NPU 两套数据。内存峰值推理过程中内存占用会不会超过系统限制尤其是低端设备容易在这一步暴露问题。如果推理结果不符合预期先检查最容易出问题的三个环节。第一步看输入预处理是否有误图像尺寸、归一化方式、通道顺序都要与模型要求一致。第二步看模型输出的解析逻辑是取整个张量还是取某个指定输出需要根据模型定义确定。第三步看是否存在数据加载错误比如模型文件本身损坏或者输入图像本来就是空白图片。8. 常见问题与排查思路端侧模型开发的问题往往不是单点技术问题而是从模型、框架到芯片适配的一连串问题。下面整理了几条高频问题按现象、原因、排查和解决思路逐一说明问题现象可能原因排查方式解决方案模型加载失败模型文件路径错误或模型格式与推理框架不匹配检查文件是否存在查看推理框架支持的格式清单确认路径必要时用格式转换工具转换模型推理结果精度极低输入预处理方式与训练时不一致对比模型输入要求与预处理代码检查归一化和通道顺序统一预处理逻辑重点核对尺寸、均值、方差、RGB/BGR 顺序推理速度慢模型未走 NPU退回 CPU或模型体积过大查看推理日志中使用的执行提供程序测试不同后端耗时转成目标芯片格式或使用厂商推理 SDK必要时量化压缩模型内存占用过高推理时模型参数和中间张量同时常驻内存用内存分析工具观察推理过程的内存曲线降低 batch size减少输入分辨率使用 INT8/INT4 量化运行时报 shape mismatch输入张量形状与模型要求不一致打印模型输入形状和实际预处理后的张量形状对比调整预处理代码保持两者一致连续推理后设备发热模型推理触发频率过高或未做温控策略统计推理频率与功耗数据增加节流策略降低触发频率将复杂任务分流到云端这些问题的排查思路有共通之处先确认“模型是不是跑对了”再确认“工程上放的位置对不对”最后才考虑“是不是平台适配问题”。很多人一上来就怀疑芯片适配不好结果发现是预处理少做了一个归一化这一类成本很低却很常见的错误值得在开发流程里用模板代码固化下来。9. 最佳实践与工程建议结合前面几章的内容给出几条可以直接用到项目里的工程建议。第一模型选型和量化要尽早做不要等应用写完再塞模型。端侧模型的性能上限在选型阶段就已经确定。选型时用真实设备跑一遍推理记录加载时间、内存峰值和延迟对比多个候选模型后再定方案。量化策略也要在这个阶段验证INT8/INT4 不是所有模型都能无损转换。第二抽象一层推理适配层。不要在前端逻辑里直接写死某一个推理框架的 API。建议封装统一的接口比如LocalModel.predict(input) - Result底层的框架切换、端侧与云端切换都在适配层完成。这样未来更换芯片平台或模型格式时不需要改上层业务代码。第三量化不是越狠越好。过度量化会导致精度明显下降尤其对分类边界模糊的任务影响很大。建议先跑 FP16 基线再尝试 INT8最后再用 INT4 评估观察每级量化带来的精度损失找到业务可接受的临界点。第四重视模型版本管理。端侧模型是随应用分发的资产不是后端服务。新模型发布时要考虑到旧版本应用无法立即升级的问题需要设计合理的模型版本策略。常见的做法包括应用内置一个基础模型启动后从服务端接收增量更新或者通过配置中心控制模型分发比例。第五隐私与安全边界不能因为模型在本地就放松。本地模型同样可能被逆向提取模型文件需要考虑加密或混淆。模型接收的外部输入也需要做校验避免恶意构造的输入触发不合预期的推理结果。涉及权限管理和数据访问时坚持最小权限原则设备端应用只申请完成任务所必需的权限。第六功耗与发热要提前做预算。端侧模型不是跑一次就完事高频触发会持续消耗电量。设计功能时给推理频率设定上限例如语音唤醒后连续监听的时间不能无限拉长图像分析类功能可以考虑节流或降低分辨率。第七端云协同要设计兜底策略。端侧模型在弱网环境、极端噪声、模糊图像等场景下会有明显的失败率。产品逻辑上要接受“端侧结果不够好”这一事实不能因为模型在本地就把用户体验上限锁死。正确的做法是让端侧模型负责高频、简单、离线任务云端模型负责复杂、长尾、高价值任务两者用统一的接口串联起来。10. 总结与后续学习方向玄戒 O100 和 AI Cube 的真正看点不在于“自研芯片”这个标签而在于它呈现了一个明确的技术方向端侧模型不再只是手机里的一个语音助手模块而是会成为独立硬件的核心能力芯片、模型、设备三者会形成更紧密的绑定。对开发者来说这意味着 AI 应用的架构设计要更早地考虑“本地能做什么、云端做什么、怎么切换”而不是默认一切都发生在云端。这篇文章讲清楚的几个要点包括端侧模型和云端模型的分工逻辑、自研芯片与端侧模型的协同关系、端云协同的架构思路以及一个可以直接跑通的最小推理示例。代码本身只是演示更值得带走的是那一套从模型选型、预处理到工程验证的思考方式。如果你准备在真实项目里落地端侧模型下一步可以按这个顺序深入先用自己的业务数据评测一个公开的基础模型跑通精度和性能基线再尝试量化并对比精度变化然后确认目标芯片平台使用厂商推理 SDK 做 NPU 适配最后设计端云协同的兜底策略。真机大规模上手之前发布会上的一切数字都只当作参考真正的判断标准只有一个在真实设备上用真实数据跑一遍。