端侧AI怎么落地：员工电脑和手机能做什么，边界在哪

2026 年，端侧AI已经能在员工自己的设备上完成短文摘要、文稿润色和语音处理，但数据是否外传，仍由应用决定。落地时先选范围明确的工作流程，清楚标出需要转交云端的环节，再用自己的业务文档检验效果，通过后再扩大使用范围。

对业务负责人来说，真正值得问的是：一项工作中，哪些环节可以留在笔记本或手机上完成？让外勤人员把现场笔记整理成交接摘要，比一开始就要求助手在整个企业内开展研究、推理并执行操作，更适合作为起点。

本文已于 2026 年 10 月 23 日依据厂商当时在线的官方文档核验。 下方任务表根据文档中的能力说明和使用要求进行分析，并非性能基准测试。

什么是端侧AI？

端侧AI，是指让模型在设备自身的处理器上运行。 处理器可以是中央处理器（CPU）、图形处理器（GPU），也可以是神经网络处理器（NPU）——一种专为其支持的 AI 运算设计的芯片。运行模型并生成回答的过程称为推理。软件需要专门适配 NPU 才能利用它；设备有 NPU，并不代表所有 AI 应用都会自动加速。Microsoft 的 NPU 开发指南

可以把它想成一位坐在你身边、拿着文档工作的译员，而不是把文档快递到另一个办公室去翻译。本地推理让处理过程留在身边，但应用仍可能把副本发往别处，就像译完之后，仍有人可以用邮件把文档发出去。

单次本地模型调用本身无需将数据传出设备。但调用模型的应用可能上传提示词、同步文档、调用在线工具，或者选择云端模型。例如，Apple 的框架允许为模型提供查询本地或在线数据库的工具。模型在哪里处理数据，与应用如何向外共享数据，是两个不同的决定。 Apple 的 Foundation Models 文档

离线AI功能也需要提前准备：模型文件必须已经下载到设备上，应用还要能在断网时访问输入内容。如果文档只存在于无法连接的远程系统中，本地模型也无从生成摘要。

企业现在能用哪些端侧AI模型？

先确定工作流程能用什么软件，再核对硬件要求。 Apple 和 Google 的框架供开发者构建应用；Windows 提供特定的现成功能；桌面模型运行工具则让员工或开发者自行选择模型。这几条落地路径各不相同。

Apple Foundation Models：把小功能做进应用

Apple 的 Foundation Models 框架提供接口，让开发者使用 Apple 的编程语言 Swift 构建由模型驱动的功能。其端侧模型适合对给定文本生成摘要、提取细节、润色文稿等任务。引导式生成可以返回预先定义的 Swift 数据结构，适合需要明确字段、而非一段自由文本的应用。Apple 框架概览

对产品负责人来说，一个合理的功能是将技术人员的笔记整理成结构化交接记录，再交由人工审核。应用负责提供原始材料并定义输出格式。这项任务的边界，比让模型决定设备该怎么维修清晰得多。

Apple 目前的生成指南将代码生成、基础数学和逻辑推理列为应避免交给其端侧模型的任务。计算和校验应使用常规应用代码；凡是可能带来实际后果的生成内容，都需要评估。Apple 的能力使用指南

该框架从 iOS 26、iPadOS 26 和 macOS 26 这一代操作系统开始提供，较新的 API 另有可用性要求。硬件必须支持 Apple Intelligence，例如 iPhone 15 Pro、iPhone 16 及后续机型，以及搭载 M1 或后续芯片的 Mac。运行时还应检查实际模型是否可用，包括语言、地区和模型下载是否就绪。框架可用性、Apple 设备要求

实现时要明确指定端侧模型。 该框架如今也支持 Private Cloud Compute 和其他服务端提供方。应用声称使用 Foundation Models，已经不足以说明某次请求究竟在哪里运行。Apple 支持的模型类型

Google 端侧AI：Android 与 Chrome

Google Gemini Nano 是 Android 系统服务 AICore 背后的本地模型。开发者通过 ML Kit 调用它，可使用摘要、校对、改写等 API。对于外勤服务应用，先试点精简员工提供的笔记，是合理的切入点。Google 的 Android 概览

设备支持情况取决于具体 API 和模型版本。应查看 Google 的支持设备列表，并执行可用性检查；仅凭 Android 版本或内存容量，无法判断设备是否符合条件。此外还有运行限制：只有当应用处于最前台时，才允许执行 ML Kit GenAI 推理，同时还受请求配额和电池用量配额约束。因此，它不适合用来支撑无人值守的后台文档队列。ML Kit 要求与限制

更灵活的 Prompt API 仍处于 beta 阶段，没有服务等级协议，也没有弃用政策，因此 Google 可能进行破坏兼容性的调整。在让员工的关键工作依赖它之前，应先评估这项依赖的风险。Google Prompt API 的状态

Google Chrome 在受支持的台式机和笔记本上，通过浏览器内置 API 提供 Gemini Nano。网页产品可以在本地为已有文本生成摘要；Summarizer API 已在稳定版 Chrome 中提供，但仍需检查功能和模型是否可用。Chrome Summarizer 文档

CPU 运行路径至少需要 16 GB 内存和 4 个 CPU 核心；GPU 路径要求显存（VRAM）严格大于 4 GB。Google 还要求 Chrome 用户配置文件所在磁盘卷有 22 GB 可用空间。这是空闲空间要求，并不意味着模型文件本身就占这么大。这些基础模型 API 目前不支持 Android 或 iOS 上的 Chrome。Chrome 硬件要求

因此，开发内部网页工具时，应先核对员工实际使用的浏览器环境，再承诺所有人都能使用。本地模型不可用时，原始文本和人工处理流程仍应可用。

Copilot+ PCs：Windows 功能实用，但要看清适用范围

Microsoft Copilot+ PCs 为 Windows 的 Live Captions 翻译、Windows Studio Effects、改进版 Windows 搜索等功能提供硬件基础。各项功能都有各自的设备、语言和推送条件。Microsoft 企业功能指南

这类设备除了要满足 Windows 的要求，还需要兼容的 40+ TOPS NPU、16 GB 内存和 256 GB 存储空间。TOPS 表示每秒万亿次运算，描述的是计算能力，并不能说明模型回答业务问题的效果。Microsoft 硬件规格

Live Captions 是本地功能的一个实用例子：Microsoft 表示，音频处理和字幕生成都在设备上完成。Windows 本来就有标准字幕功能，Copilot+ 增加了翻译能力。不过，生成的字幕不会保存，因此它不能充当会议档案，也无法替代需要保留转录文本的工作流程。Microsoft Live Captions 文档

采购前应明确：究竟是哪项功能值得为它购买硬件。买到 NPU，并不会让 Microsoft Copilot 的云端功能或任意桌面模型自动转到这块芯片上运行。Windows AI 规格、NPU 软件要求

Ollama 与 LM Studio：自己选择本地大模型

Ollama 是本地模型运行工具，并提供可供应用调用的 API。其文档明确区分了本地模型运行和可选的云端功能。它适合希望将本地模型接入现有工作流程，并查看模型究竟使用 CPU 还是 GPU 资源的技术开发者。Ollama 文档

如果工作流程必须限制在本地，Ollama 文档给出了两种配置方式：在服务端配置中设置 disable_ollama_cloud: true，或设置环境变量 OLLAMA_NO_CLOUD=1 后重启。这会关闭 Ollama 的云端模型和网页搜索，但不能控制接入 Ollama 的其他应用如何联网。Ollama 仅限本地的配置

LM Studio 提供桌面界面，用于下载、加载模型并与之对话，支持的模型系列包括 Qwen、Mistral 和 Gemma。厂商公开训练后的模型文件时，这类模型称为开放权重模型；但各自的许可证仍有区别。LM Studio 入门指南

下载好文件后，LM Studio 支持离线对话、本地文档处理和本地服务器。其现行隐私政策另行说明了可选的云端模型和网页搜索功能。使用时应明确选择本地模型路径。离线运行、LM Studio 现行隐私政策

LM Studio 建议至少配备 16 GB 内存，不同平台还另有要求。这只是起点，并不保证所有模型都能装得下、跑得动。它支持 Apple Silicon，不支持 Intel Mac；Windows 的 x64 版本要求 CPU 支持 AVX2。LM Studio 系统要求

可以参考本地大模型选型指南，为现有机器挑选模型；也可以通过 Ollama 与 LM Studio 对比，比较运行工具、部署方式和工作用途许可。运行工具与模型，需要分别选择。

哪些任务适合留在员工设备上？

输入已经在设备上、任务范围明确、结果能由人工核查时，本地AI最有吸引力。 如果任务超出了设备能力，或需要由中心统一运营的服务，云端仍是有用的选择。表格最后一列是对落地方式的判断，并非实测质量排名。

语音转写与文本摘要要分开看。能改写文本的语言模型，并不自动具备音频转写能力。Google 的 Basic 语音模式使用传统端侧语音模型，Advanced 模式使用生成式模型。识别出来的文字是否保存、保存在哪里，仍需由应用决定。Google Speech Recognition 指南

比较成本时，可以对照付费云端 API 调用与不产生按次云端推理费用的免费本地运行，同时把硬件、电力和管理成本算进去。Google 对本地 API 成本的说明

比芯片标识更重要的实际限制

首先遇到的限制，往往是能处理多少工作，而不是模型能否启动。 上下文窗口是模型容纳指令、原始材料、对话历史和回答的工作空间。

Apple 当前指南写明，其默认端侧模型的上下文窗口为 4,096 token。token 是文本片段，输入与输出共享这一额度。指南也提供了查询实际模型容量的方法。处理长文档时，不能把整个上下文窗口都当成原文可用空间。Apple 上下文窗口指南

将文档分块有助于装入上下文，但应用必须保留不同分块之间的关联。比如截止日期在某一节，例外条件却在另一处，一组彼此独立的摘要就可能漏掉这层关系。应评估整个任务是否完成，而不只是看每个分块有没有生成文字。

桌面模型还需要内存来容纳权重和运行状态。更长的上下文和并发请求可能增加内存占用。一个人用来起草回复时运行正常的模型，在其他应用同时开启时，未必适合承担后台批处理。Ollama 内存与并发指南

因此，实际测试应放在有代表性的员工设备上，并保持日常应用运行。针对自己的工作负载，记录完成时间、请求失败情况、修改工作量和电池影响。上文的硬件门槛，都不能直接推导出普遍适用的速度或质量结论。

隐私与合规，要看整个应用

端侧处理可以让工作流程少一次向云端传输，却不能据此认定整个流程合规。 先弄清所选功能会发送什么、存储什么、暴露什么，再由相应的安全和合规负责人评估这套配置。

厂商的说法都有明确的适用范围：

• **Apple：**端侧模型可以断网运行，但 Foundation Models 也支持云端提供方，以及获取在线数据的工具。需要记录应用选用的模型和工具。Apple 支持的模型类型
• **Android 上的 Google：**ML Kit 表示，不会将输入数据和输出结果发送给 Google，但会发送性能与使用指标，并连接服务器获取更新。内容在本地处理，不等于没有网络活动。ML Kit 隐私条款
• **Chrome 中的 Google：**Google 表示，使用本地模型时不会向 Google 或第三方发送数据，首次下载模型需要联网。但这项说明并不能阻止使用该 API 的网站通过自身代码发送数据。Chrome 模型要求
• **Microsoft：**Live Captions 在本地处理数据，但其他功能的边界不同。Paint Cocreator 在 NPU 上生成图片，同时使用云端安全服务；Microsoft 表示会收集提示词和标识符以防止滥用。结果在本地生成，并不能证明整个功能都在本地运行。Cocreator 隐私说明
• **桌面运行工具：**Ollama 的本地隐私声明适用于本地运行场景。LM Studio 现行政策区分了本地处理与可选云端服务。即便云端提供方承诺不保留请求，也仍意味着请求已经离开设备。Ollama、LM Studio

在员工使用敏感材料前，应记录来源位置、所选模型、出站请求、本地历史记录、备份和删除行为。扩展程序及连接的工具也应纳入检查。设备加密和访问控制同样重要，因为把内容留在本地，也意味着把副本留在员工设备上。

关于端侧AI，哪些说法被夸大了？

“一台笔记本就能替代云端 AI 服务”的说法，把一次计算和一整套服务运作方式混为一谈。 即使推理搬到了本地，模型更新、技术支持、权限、评估，以及任务失败后的处理办法，仍然不可或缺。

NPU 对兼容的工作负载有用，但并不是模型兼容性的通用保证。离线回答省去了推理时的网络往返，却不能证明结果一定更快。装在本地的模型，也仍会编造细节或生成不合适的内容。

另一个极端也没有帮助：本地模型不必替代最强的云端模型，才算有价值。可靠的文稿润色或短文摘要，本身就可能值得采用。关键是这项具体功能，能否在员工现有设备上达到你的验收标准。

哪些人现在就适合部署端侧AI？

业务负责人可以开始试点范围明确、结果可审核的任务；采购方则应等到硬件需求得到实际验证。 不同角色，下一步各有侧重。

业务负责人可以从反复出现的任务入手，例如精简内部交接笔记。选择预期结果明确的输入，要求由人工批准输出，并保留原始材料供对照。

开发者或产品负责人可以在平台 API 与已部署设备、目标功能相匹配时采用它。模型可用性检查、输入限制和人工备用流程，都应成为产品的一部分。面对混合机型的手机群体，也要让无法运行该功能的用户仍能完成工作。

采购负责人或 CTO应先盘点现有设备，再决定是否换机。为某项 Windows NPU 功能采购硬件，与为桌面模型运行工具采购硬件，是两种不同的需求。等所选工作流程在有代表性的机器上证明有用之后，再批准硬件支出。

如果目标是无人值守的批量处理，而所用 API 禁止后台推理，或本地模型达不到质量要求，就先等一等。如果已经获批的云端流程足以满足需求，而本地运行在隐私、网络可用性或实际运作上没有带来有用的优势，就保留现有方案。

下周一就能开始：先试点一个流程

1. 1

   选定任务，划清数据边界

   明确具体的输入和输出，例如将交接笔记整理成更短的草稿。配置备用方案前，先决定这些内容是否允许离开设备。

2. 2

   核对实际设备和模型准备情况

   盘点相关操作系统、芯片、内存和可用存储空间。下载所需模型，确认可用性，并为不受支持的机器保留人工处理路径。

3. 3

   分别评估输出质量和网络行为

   使用获准的样本材料，将结果与原文对照，检查出站流量，再在离线状态下重复已经准备好的流程。离线运行成功，能为这条处理路径提供有用证据，但不能证明应用联网后从不上传数据。

4. 4

   决定是否扩大使用范围

   除了完成时间，还要记录失败情况、修改工作量和支持负担。只有任务确实有用、数据处理也符合预设边界时，才扩大使用范围。凡是允许访问云端的地方，都应明确标示。

想获取更多 AI 落地决策建议，可以订阅邮件通讯。