端侧 AI 国内外发展现状：模型、系统、芯片与产品生态调研

端侧 AI 国内外发展现状：模型、系统、芯片与产品生态调研

版本历史

术语与缩略语

可靠性标记

• 【C】可由单一官方产品页、开发者文档、上游项目或厂商公开材料直接核验的事实。
• 【C*】由多个独立一手来源共同支持的稳定结论。
• 【S】由有限厂商样本归纳的趋势，不代表完整市场份额或所有终端。
• 【P】面向研发与产品的建议，不是厂商承诺或性能保证。
• 【?】公开材料未披露，或无法从本次资料中稳定复核的细节。

1. 核心判断（TL;DR）

• 【C*】端侧 AI 已从“把一个模型塞进应用”转向操作系统托管的模型服务与端云路由：Apple 提供 Foundation Models framework，Android 将 Gemini Nano 集成进 AICore，Windows 将 NPU 作为 Copilot+ PC 的系统能力入口 [S02][S04][S06]。
• 【C*】真实边界由内存、上下文、量化、算子覆盖、功耗和设备矩阵共同决定，而不是单一 TOPS。Apple 的端侧 Foundation Model 会话上下文为 4,096 tokens；QNN HTP 路径要求量化且限制动态 shape；Windows Recall 也有明确的存储与硬件门槛 [S03][S08][S07]。
• 【C*】国内厂商已把轻量模型、低比特推理与智能体交互带入手机功能，但主流形态仍是端云协同。OPPO、vivo、荣耀公开了端侧模型或终端能力；华为、小米和百度的公开资料也显示系统能力、联网条件或云侧知识服务仍是架构的一部分 [S19][S21][S24][S16][S26][S31]。
• 【S】竞争焦点正在从模型参数量转为“可治理的终端 AI 平台”：模型分发与更新、异构后端选择、隐私边界、降级路径、评测协议和应用 API 将比单次 demo 更影响规模化交付 [S04][S12][S13][S14]。
• 【P】端侧项目的发布门槛应同时验证任务质量、首 token/端到端时延、峰值内存、能耗/温控、离线率、云端回退率和数据边界；只报告 token/s 或 NPU TOPS 不能证明用户体验已达标 [S03][S08][S10][S14]。

2. 问题、范围与方法

本文把“端侧 AI”定义为模型或 AI 算法在手机、PC、嵌入式设备或本地边缘网关执行，并将端云协同视为其常见而非例外的部署模式。研究对象不是某一家厂商的营销口号，而是能被工程团队复用的四层契约：模型是否适配设备资源；操作系统如何提供访问、分发和隐私边界；运行时怎样把图分配给 CPU/GPU/NPU；产品怎样在离线、联网、长上下文与安全约束之间做路由。

方法分为四步。第一，优先采集 Apple、Android、Microsoft、芯片厂商、推理运行时和中国终端厂商的官方资料，直接事实标为【C】。第二，区分“已公开产品能力”“开发者接口”“峰值演示指标”与“趋势归纳”；未经披露的模型落点、芯片规格或实际覆盖设备不补充推断。第三，以资源约束和失败路径校正营销指标，特别检查上下文、存储、量化、动态 shape、地区/账号、网络、模型下载与热设计。第四，将跨平台共性转为验证条件和建议，不把单一机型或单次 demo 外推为市场排名。

图 1 概括端侧 AI 的交付闭环。模型权重只是起点：只有把真实任务、设备资源、后端覆盖、端云策略与持续观测放在同一条链上，才可以判断“本地推理”是否真的改善体验或隐私。

图 1：端侧 AI 的端到端交付闭环。来源：依据 Apple Foundation Models、Android AICore、Windows ML、LiteRT、ONNX Runtime 与 QNN 文档综合绘制；用于表达工程控制面，不表示某一厂商的内部架构 [S02][S04][S08][S12][S14]。

3. 全球技术基线

3.1 从应用内 SDK 走向 OS 级模型服务

Apple、Google/Android 和 Microsoft 已分别把端侧模型能力放入更靠近操作系统的服务层。Apple 在 2025 年发布 Foundation Models framework，使应用可以调用系统的端侧基础模型；Apple Intelligence 的公开架构同时区分设备端处理与 Private Cloud Compute，后者不能被表述为纯本地执行 [S01][S02]。苹果文档还明确该模型可用性依赖设备、地区和下载状态，单个会话的上下文上限为 4,096 tokens，并提示其不适合承担基础数学、代码生成或复杂逻辑推理；同会话不能并发请求 [S03]。这意味着 API 的存在不等于每个生成任务都适合交给端侧模型。

Android 将 Gemini Nano 作为 AICore 系统服务中的模型能力，应用可通过 ML Kit Generative AI API 访问文本生成、摘要、改写、图像描述和语音转写等任务 [S04]。官方材料说明，本地提示处理无需调用服务器，AICore 不直接访问互联网，输入和输出处理后不保留记录；与此同时，推理速度依赖设备硬件，模型可用性和能力仍受设备支持条件约束 [S04]。Google 对 Gemma 4/AICore 开发者预览也提示，不具备 AICore 的设备会先走 CPU，开发预览性能不能代表量产终端 [S05]。这揭示了 Android 的关键现实：开发接口统一，但硬件体验仍高度分层。

Windows 的 Copilot+ PC 把 NPU 40+ TOPS 设为硬件类别门槛，Windows ML 则以 Execution Provider 连接 QNN、OpenVINO 等后端，并可在不可用时使用 GPU/CPU 路径 [S06]。Recall 的公开说明强调本地快照分析、显式开启和加密保护，但同时要求 16GB 内存、256GB 存储与 50GB 可用磁盘，在剩余空间低于 25GB 时暂停存储 [S07]。因此，系统平台化并没有消除资源约束；它只是将资源、模型分发与权限治理从每个应用迁移到平台统一负责。

3.2 推理运行时是“可部署”与“可量产”之间的关键层

端侧模型不是导出成某种格式后自然获得加速。LiteRT（原 TensorFlow Lite）覆盖 Android、iOS、Web、桌面和 IoT，提供转换、量化及 GPU/NPU 等委派路径 [S12]；ExecuTorch 1.0 将 PyTorch 原生部署扩展到手机、嵌入式与 AI PC，但其部分后端仍处于 alpha/beta，必须逐模型、逐设备验证算子覆盖和精度 [S13]。ONNX Runtime 以 EP 抽象衔接 NNAPI、QNN、CoreML、DirectML、CUDA/TensorRT 等后端，文档将 profiling、线程、图优化、内存管理和 I/O binding 都列为性能控制点 [S14]。这些机制让模型团队可以复用接口，也使运行时选择和回退成为必须被管理的产品行为。

后端限制会直接改变架构选择。ONNX Runtime 的 QNN EP 面向 Android 和 Windows 上的 Snapdragon 平台；公开限制包括 HTP 后端需要量化模型、动态 input shape 不受支持，而 GPU 路径适用 FP32/FP16 [S08]。这意味着同一模型的动态 batch、长序列或自定义算子，可能触发 CPU/GPU 回退、图切分或转换失败。I/O binding 可以减少主机与设备之间的复制，但需额外管理缓冲区生命周期和会话内存 [S14]。浏览器侧也出现 WebGPU 路径，例如 Transformers.js 的版本更新加入浏览器端模型能力；但浏览器兼容性、下载大小和显存仍须按目标环境实测 [S15]。

【C*】全球运行时生态正在收敛为“统一图表示 + 后端委派 + 设备能力发现 + 回退”的模式，而非一个单一 NPU API。图 2 概括了这一异构路径。其工程后果是，性能团队应把模型转换成功率、被加速图比例、回退算子、复制/同步、冷启动和稳态分别记录；只测 NPU kernel 的峰值不能代表应用的端到端表现 [S08][S12][S13][S14]。

图 2：端侧 AI 的异构部署与端云路由。来源：根据 QNN EP、LiteRT、ExecuTorch、ONNX Runtime、AICore 和 Windows ML 的公开接口综合绘制；虚线表示依设备能力、模型条件或策略发生的可选路径 [S04][S06][S08][S12][S13][S14]。

3.3 芯片指标必须回到模型与系统约束

NPU TOPS 是芯片吞吐能力的一个标称维度，不能直接推导 token/s、交互时延或电池体验。高通 AI Hub/QAIRT 与 QNN 为 Snapdragon 的模型部署提供后端，实际可用图仍受量化、静态 shape 和支持算子约束 [S08]。联发科将 NPU、NeuroPilot 和 LiteRT 作为手机与 IoT 的端侧 AI 软件组合，但其标称性能或芯片宣传数字应保留为厂商口径，不能跨平台直接比较 [S09]。Windows Copilot+ PC 的 40+ TOPS 定义同样只是准入类别，不是对任意模型端到端时延的承诺 [S06]。

嵌入式场景更能暴露资源边界。NVIDIA Jetson Orin Nano Super 开发套件公开规格为 67 INT8 TOPS、8GB LPDDR5、102GB/s 内存带宽和 7–25W 功耗范围 [S10]。NVIDIA 的边缘 LLM/VLM 部署指引将 8GB Orin Nano 主要指向约 4B 级模型，并明确模型大小还取决于量化、KV cache 与并发负载 [S11]。因此，模型“能加载”并不等于能以目标上下文、并发和热稳态运行。手机、PC 与机器人都要面对相同的分配问题：权重占用、激活、KV cache、预处理、显示/传感器与其他系统任务在有限内存和热预算中竞争。

4. 国内发展、差距与机会

国内端侧 AI 的公开形态与全球趋势一致：手机厂商把小模型、量化、NPU 和系统智能体结合；模型公司通过开放权重和多种本地后端降低部署门槛；但面向知识、搜索、复杂推理和跨服务执行的能力依然常采用端云协同。公开资料的粒度不一，故本报告只陈述各厂商已披露的模型、设备或软件路径，不以机型名称推断全部算力、隐私策略或离线范围。

华为的 HarmonyOS 5 公开材料描述小艺接入盘古能力并采用端侧与云侧协同；功能还受 HOTA、联网、华为账号和地区等条件影响 [S16][S17]。昇腾软件栈资料将 MindIE SD 列为可面向手机和 IoT 等端侧设备的推理组件 [S18]。相对地，盘古 5.5 与昇腾 AI 云服务在公开页面的定位是行业模型和云算力，不能据此写成手机端模型已完全本地部署 [S17]。这一边界提醒团队，品牌层面的“AI”不是推断模型执行位置的充分证据。

OPPO 提供了较具体的端侧展示：其 2025 年 WAIC 材料称，3B 端侧模型在 Find X8s、Find N5 上演示峰值 200 token/s 和 128K 上下文，并将能力用于深度研究；2026 年又与联发科在天玑 9500/ColorOS 16 上演示端侧翻译、补光等能力 [S19][S20]。这些数据可作为该厂商的公开演示口径，却不能替代独立、跨机型的性能结论。vivo 公开蓝心模型矩阵包含 1B、3B、7B、13B 的端侧规格，X Fold6 公开了 AI 文件管理和会议助手等终端功能；后者页面未明确每项功能都由蓝心本地模型执行，因此不能强行归为纯端侧推理 [S21][S22]。

荣耀从 Magic6 的 70 亿参数端侧模型，发展到 MagicOS 9 的 30 亿参数模型及 YOYO 智能体，并在 2025 年资料中说明 Magic8/MagicPad3 Pro 通过第五代骁龙 8 至尊版和低比特端侧模型承载智能体能力 [S23][S24][S25]。小米澎湃 OS 的公开材料重点是人车家跨端协同，而国际 HyperAI 页列出的写作、转写、翻译和图像能力明确可能要求联网，并随地区、语言和机型变化，且包含 Google Gemini；这些材料不能直接等同于中国市场的纯本地模型方案 [S26][S27]。百度与荣耀合作材料则明确将 Magic 模型用于本地意图和敏感信息处理，而将文心用于云侧知识和生活服务，给出了端云分工的一个清晰实例 [S31]。

图 3：国内端侧 AI 的产品与生态分层。来源：依据华为、OPPO、vivo、荣耀、小米、联发科、Qwen、百度与腾讯公开材料归纳；表示公开能力的技术位置，不表示市场份额或厂商组织结构 [S16][S19][S21][S24][S26][S28][S29][S31][S33]。

4.1 中国模型、芯片与软件生态的可见连接点

联发科天玑 9500 的公开资料披露 NPU 990、3B LLM 与 1.58-bit BitNet 支持；其与 OPPO 的协作给出了芯片、系统与手机功能联动的可见案例 [S20][S28]。高通虽非中国厂商，但已通过荣耀等国产 OEM 进入本地终端生态；公开资料可以支持“低比特端侧模型与特定 Snapdragon 平台结合”的案例，却不能泛化为所有国产手机都具有相同路径 [S25]。因此，国内机会不只在设计 NPU，更在于把不同 SoC 的算子集、内存、驱动、模型编译与系统调度做成稳定的软件适配层。

Qwen3 开放 0.6B、1.7B、4B、8B 等 Dense 模型，官方资料列出 Ollama、LM Studio、MLX、llama.cpp、KTransformers 等本地工具链；其官方仓库还列出 MNN、面向 iOS/Android 的 ExecuTorch 等运行路径 [S29][S30]。这提供了将中国开源模型带到多种本地环境的基础，不等于这些后端已经获得每种手机的量产认证。腾讯公开的 HY-1.8B-2Bit 提供 GGUF INT2/BF16 和 Arm/SME2 推理路径，同时说明模型规模和监督微调流程仍有局限 [S33]。这类小模型与低比特工作说明端侧的关键不是单纯缩小参数，而是同时面对任务能力、格式、ISA、算子和内存系统的联合约束。

4.2 机会与差距：从“端侧能力展示”走向工程化治理

【S】国内公开资料已显示模型小型化、低比特、手机系统智能体和跨设备协同在快速推进，但对第三方开发者而言，稳定 API、设备覆盖、模型版本治理、跨 SoC 后端行为和评测口径的公开程度仍不均衡 [S16][S19][S21][S24][S29]。这不是单一厂商的问题，而是端侧 AI 进入规模交付后的普遍工程难题。全球平台同样面对设备门槛与后端限制，只是 Apple、Android、Windows 已更明确地将部分模型服务、分发或 EP 抽象放入系统层 [S02][S04][S06][S14]。

【P】最有价值的投入是形成“模型—编译—后端—设备—体验”的可观测闭环：一方面，建立覆盖目标 SoC、系统版本、网络与温度条件的基准集；另一方面，记录模型转换、NPU 受理、回退算子、内存峰值、端云路由和任务质量。这样才能将厂商 demo 转化为可发布的能力，也能让终端、编译器、NPU 驱动、模型和产品团队围绕同一个事实集合协作。

能力成熟度对比矩阵

5. 关键机制深挖

5.1 模型与资源预算：参数量之外的内存、上下文和热设计

接口与实现依据。 Apple Foundation Models framework、Android AICore/ML Kit、LiteRT、ExecuTorch 与 ONNX Runtime 都是模型调用、转换或后端分配的接口；其实现最终要把权重、激活、KV cache、tokenizer、预处理和后端缓冲区放入目标设备的内存与功耗预算 [S02][S03][S04][S12][S13][S14]。Apple 对单会话 4,096 tokens 的公开限制，以及 NVIDIA 对 8GB Jetson Orin Nano 的约 4B 级模型指引，说明上下文和并发会与权重体积共同限定可运行模型 [S03][S11]。实现设计应先建立资源账本：模型格式和量化、prompt/输出长度、并发、KV cache、峰值工作集、首 token 与持续生成的热状态必须一并记录。

失效边界。 把“某设备 NPU TOPS 很高”或“单次能加载模型”视为可发布依据会失效。长 prompt 和多轮会话会增长 KV cache；流式生成会延长持续功耗；相机、显示、通信和后台任务会争用内存/带宽；低比特量化可能降低内存但暴露不支持算子或任务质量退化。设备的散热、充电状态、频率策略和系统版本也会使短测的 token/s 无法代表连续使用。尤其不能把厂商峰值演示与不同模型、不同序列长度或不同精度的独立结果横向对比。

验证条件。 对每个目标模型，应在固定设备、OS、固件、温度/电量条件下，分别测量加载、首 token、预热后生成、长上下文、并发和持续运行；同时记录峰值 RSS/显存、能耗或温升、输出质量和崩溃/降级情况。测试集至少要有典型、最长上下文、最坏输入和离线场景。若模型依赖端云协同，应把云端回退另列，不可混入“本地时延”。验证结果应能复现模型 hash、量化方式、tokenizer、prompt、采样参数和版本。

成本与权衡。 更高精度和更长上下文可能提高任务质量，却带来更大存储、延迟和热负担；更激进的量化可降低资源消耗，却增加校准、精度测试和后端适配成本；为了避免 OOM 预留内存会减少并发或可用功能。负责人应以具体用户任务的完成率、隐私等级和资源 SLO 决定模型档位，而不是将最大参数量当作唯一目标。

5.2 异构后端与图划分：让“加速”成为可解释的系统行为

接口与实现依据。 LiteRT 的 delegate、ONNX Runtime 的 EP、Windows ML 的后端选择和 QNN EP 都将模型图或算子交给 CPU、GPU、NPU 等不同执行单元 [S06][S08][S12][S14]。以 QNN 为例，Android/Windows Snapdragon 的 HTP 路径要求量化且不支持动态 input shape，GPU 路径的精度范围也不同 [S08]。实现上，运行时需要解析模型、编译或缓存后端产物、切分不受支持的节点、管理 host/device 缓冲区，并在后端不可用或转换失败时选择回退路径。I/O binding 可减少复制，但意味着应用要正确管理缓冲区和会话生命周期 [S14]。

失效边界。 “模型已启用 NPU”不等于整张图都在 NPU 上执行。动态 shape、自定义算子、量化不匹配、布局转换、版本差异或驱动缺陷都可能使图被切分；频繁的 CPU/NPU/GPU 往返可能让端到端时延劣于纯 CPU 路径。只读取后端初始化成功日志、只测单算子或忽略 fallback 都无法说明真实加速。不同芯片上同名 NPU 的算子、精度和编译器支持也不应假定一致。

验证条件。 对每次模型/运行时升级，保存后端分配报告、受理图比例、未受理算子、复制/同步时间、缓存命中、加载时间与最终端到端指标；对动态序列、最大输入和高并发分别测试。测试还必须比较主路径、明确禁用加速器的基线以及强制回退路径，并校验各路径的输出质量/数值误差。若系统会自动选择 EP，应记录实际选中的后端而非只写配置意图。这样才能将性能退化归因到模型、编译、驱动、内存或调度层。

成本与权衡。 支持更多后端会扩大模型转换、精度回归、驱动兼容与 CI 设备池成本；缓存编译产物可缩短启动，却增加磁盘占用和失效策略复杂度；固定 shape 有助于 NPU 编译，但会损害输入弹性。平台团队需要维护一份由真实工作负载驱动的后端能力矩阵，并在“通用性、性能、可维护性和精度”之间明确取舍。

5.3 端云协同与隐私：执行位置必须是可验证的产品契约

接口与实现依据。 Apple Intelligence 公开区分设备端与 Private Cloud Compute；Android AICore 说明本地提示处理、无直接互联网访问以及输入/输出不留存；荣耀—百度合作公开说明本地意图/敏感信息和云侧知识服务的分工 [S01][S04][S31]。这些资料表明，端侧 AI 的实现不仅是模型选择，还是路由、权限、账号、网络、缓存、下载和日志策略的组合。产品接口需要能声明任务是否可离线、哪些字段可上云、云端失败如何降级、模型如何更新，以及用户如何知情和控制。

失效边界。 “支持离线”不等于首次使用不需要下载、账户或地区资格，也不等于全部输入不会被发送到服务端。小米国际 HyperAI 公开列出联网、地区、语言和机型条件；HarmonyOS 小艺相关能力也存在系统更新、联网和账号条件 [S16][S17][S26]。如果产品没有逐任务记录实际执行位置、网络请求和回退原因，隐私声明无法被工程验证。把云侧检索、工具调用、同步日志或错误遥测遗漏在数据流图之外，是常见的失败边界。

验证条件。 发布前应建立数据流清单：输入字段、模型下载、端侧缓存、云侧调用、日志、账号/地区依赖和保留期限都需标注。对断网、弱网、拒绝权限、模型未下载、设备不支持、云端超时和内容安全拒绝分别做测试，确认用户可见行为和数据边界符合声明。可使用网络拦截、系统日志审计、代理测试和自动化用例，验证“声称本地”的任务不会产生未声明的上行请求。端云路由指标应区分正常云调用、可接受回退和异常泄露风险。

成本与权衡。 更严格的本地优先会限制模型规模、知识时效和复杂推理能力；更多云端回退会改善能力覆盖，却增加网络时延、服务成本、合规审查和用户信任风险；关闭遥测会降低诊断能力。技术负责人应把隐私、可靠性与成本作为同一个路由优化问题，并将执行位置、原因和可解释性纳入验收，而不是在功能上线后再补治理。

6. 演进方向与情景

全球与国内样本共同说明，2026 年端侧 AI 的分水岭并不是“设备能否跑 LLM”，而是模型服务能否成为稳定的平台能力。Apple、Android 和 Windows 正在将模型访问或硬件选择系统化；LiteRT、ExecuTorch、ONNX Runtime 等运行时将模型跨后端部署模块化；中国终端厂商把轻量模型、低比特和智能体嵌入手机功能 [S02][S04][S06][S12][S13][S14][S19][S24]。下一阶段的技术难题会更偏向版本治理、体验 SLO、数据边界和生态兼容，而不只是压缩一次模型。

图 3 已展示国内生态的分层关系：开源模型与设备模型不必竞争，也可以通过统一格式、编译工具和系统服务形成互补。比如 Qwen3 的本地后端路径降低了原型门槛，系统服务则能处理模型下载、权限与跨应用资源管理 [S04][S29][S30]。但这种互补的前提是准确披露设备支持、模型版本、执行位置与回退；否则终端 AI 会在机型碎片、内存争用和用户预期差异中失去可信度。

6.1 对研发组织的含义

端侧 AI 团队不宜按“模型组、系统组、芯片组”彼此孤立地验收。模型组可交付权重和质量基线，编译/运行时组可交付目标后端的受理与性能，OS/安全组可交付权限、分发和数据边界，产品组则要定义离线、弱网、低电量和不支持设备上的用户预期。共同的工作对象应是任务 workload：输入分布、上下文、设备矩阵、执行位置、质量指标、时延、内存、能耗、错误率和回退率。这样才能识别某项收益是模型、后端、系统版本还是路由策略带来的。

6.2 对个人能力的含义

从系统软件、性能工程或 AI 推理走向端侧 AI 负责人，核心不是掌握某一品牌 NPU 的命令，而是具备四个闭环能力：将用户任务形式化为可测 workload；阅读模型图、量化和运行时日志，解释实际后端路径；把内存、KV cache、温度、时延和质量作为联合约束；将本地/云端执行位置转化为可测试的隐私与可靠性契约。具备这四点的人，才能在模型、OS、编译器、驱动和产品团队之间提供可验证的决策输入。

7. 建议与验收

7.1 项目启动时先写“端侧工作负载合同”

每个功能在选择模型前，应定义任务目标、允许输入、语言/图像/语音分布、最大上下文、响应时限、离线要求、允许的云端能力、隐私级别、目标设备、最低内存与能耗预算。合同还应包含正确性/质量判定和不支持设备的降级文案。这样做可以将 Apple/Android 的设备可用性、QNN 的量化/shape 限制、Windows 的硬件门槛等外部条件变成产品可验证条件，而不是上线后的兼容事故 [S03][S04][S06][S08]。

第二步是把观测嵌入运行时：记录模型与量化版本、实际 EP/delegate、加速图比例、首 token、端到端时延、峰值内存、温度/功耗代理指标、执行位置、回退原因与任务质量。任何“性能提升”都应同时保存基线、设备、OS/驱动、输入和原始 trace/日志。第三步才是优化模型、提示、量化、图划分或缓存。该顺序可防止把一个特定机型上的演示结果误认为平台能力。

主张—证据矩阵

7.2 团队机制建议

1. 建立 设备能力矩阵：按 SoC、NPU 后端、RAM、OS、地区和模型版本记录支持任务、量化格式、最大上下文、主/回退后端与已知问题。
2. 建立 端到端性能协议：冷启动、首 token、预热、稳态、长上下文、并发、低电量和热稳态必须分开测试；严禁只报单次 token/s。
3. 建立 执行位置审计：每项任务在产品、日志与测试中标记本地、云端、模型下载和回退，敏感字段的网络路径要可复核。
4. 建立 模型发布门禁：将质量、格式转换、后端受理率、峰值内存、能耗、崩溃率与回退率放入 CI/灰度指标，模型或驱动升级必须可回滚。
5. 建立 跨层评审：当瓶颈来自算子支持、内存、温度或隐私路由时，由模型、编译器/运行时、OS/驱动和产品共同确认收益、风险与 owner。

建议—验收矩阵

8. 不确定性与研究限制

1. 本报告不做市场份额、出货量、融资、招聘数量或“谁领先”的定量排名；公开资料不足以支持此类结论。
2. 厂商公开的 TOPS、token/s、上下文或功能演示可能采用不同模型、精度、序列长度、温度、网络和测试方法，故只作为该厂商的说明性材料，不用于跨设备性能对比。
3. OS/API 文档说明某项能力可如何被调用，不证明所有应用、地区或设备都可用；Apple、Android、Windows 的设备、地区、下载、NPU/EP 条件应以发布时版本重新核验 [S03][S04][S06][S07]。
4. 中国终端厂商公开材料常聚焦产品能力而非完整的数据流、模型运行位置、芯片规格或第三方开发 API；本文对未披露细节保持【?】而非推断。
5. 开源模型和本地后端能支持原型，不等于已针对每个移动 SoC 做量产认证；模型转换、量化质量、后端算子覆盖、驱动稳定性与许可条件需在实际项目中单独验证 [S08][S13][S14][S29][S30]。
6. 本文的端云隐私讨论基于公开架构或条件说明，不替代安全审计、数据保护影响评估、渗透测试或法律合规意见。

参考来源

附录：研究方法

A. 证据采集规则

1. 优先采用模型、操作系统、芯片、运行时或终端厂商的官方页面和上游项目文档；不以二手转载、聚合跑分或社交媒体截图支持技术事实。
2. 对“本地”“离线”“隐私”“端云协同”等词，分开核对执行位置、联网、模型下载、账号、日志和回退条件；未披露时保留【?】。
3. 对 TOPS、token/s、参数量、上下文和功耗，记录原始厂商条件，仅用于说明该来源中的能力/约束，不进行跨来源归一化排名。
4. 页面会随产品版本更新；实际立项和发布前应重新访问对应官方文档，并在目标硬件上完成回归测试。

B. 建议的最小实验记录

C. 图表说明

图 1 至图 3 为基于公开系统/运行时接口和厂商披露信息绘制的结构图，不包含市场份额、性能排名或未公开内部实现；其用途是帮助团队建立可验证的端侧 AI 交付和治理边界。