# 在设备上运行的 AI，而不是在云端 关于 on-device 与 edge AI 的速成课——直接在手机、笔记本或传感器上运行模型，而不是在数据中心里。20 个概念——round-trip、隐私、离线、延迟、SLM、量化、蒸馏、fine-tuning、hybrid routing 等——每个都配有英文名称、一幅图示、一个例子和一张卡片。核心要点：一个在本地运行的小模型，解锁了隐私、离线使用、即时响应和零单次调用成本——代价是原始能力。结尾附有一页速查表，汇总所有概念。 - **Author:** Fedor Chishchin - **Level:** intermediate - **Reading time:** ~30 分钟阅读 - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/zh/learn/edge-ai-express --- ## 1. 云端 vs 设备端 整个话题归结为一个问题：模型到底在哪里运行？看懂这个分岔口——以及每一边的代价——其余一切就都顺理成章了。 ### 地图：六组共 20 个概念 > 一张地铁线路图：先看到整套线路，再一站一站地乘过去。 先是三个**基础**概念：云端 AI、设备端 AI，以及把它们分开的网络 round-trip。然后是六组，每章一组：**为什么**要在本地运行、如何把模型做**小**、坦诚面对能力上的**取舍**、**专精**、**hybrid** 模式，以及如何**用好**它。 之后每个概念都按同样的方式讲：它的**英文名称**（要记住——这就是术语）、一幅来自日常生活的画面、一张**图示**，以及一张带有这些字段的**卡片**：_问题_、_思路_、_例子_、_代价_、*何时使用*和*关联*。 _Diagram: 上面是基础概念；下面是第 2–7 章依次讲解的六个分组。_ ### Cloud AI — 在数据中心里的模型，通过网络访问 > 每次要答案都给远方的办公室打电话——你的问题传过去，专家作答，答案再传回来，每一次都是如此。 默认情况下，模型运行在**云端（cloud AI）**——数据中心里强大的服务器上——你的设备通过互联网访问它。你发出请求，它在远程被处理，响应再传回来。大多数 AI 都是这样工作的，这也是最大、最聪明的模型得以存在的原因：它们需要远超手机的硬件。但这也意味着，每一次调用都要经过网络，去往别人的计算机。 _Diagram: 云端：请求传到数据中心，响应再传回来——每次调用都是如此。_ #### Cloud AI (远程服务器上的模型) - **是什么:** 模型运行在数据中心的服务器上；设备通过网络调用它。 - **为什么:** 最大的模型需要远超手机的硬件。 - **例子:** 浏览器里的聊天助手：每个问题都发往服务商的服务器。 - **代价:** 每次调用都是一次 round-trip、账单上的一行费用，以及离开设备的数据。 - **关联:** **On-device AI** 的对立面；把两者分开的是 **round-trip**。 ### On-device AI / Edge AI — 模型就在你身边 > 一位专家就住在你家，而不是在城市另一头——你直接问，答案立刻就来，不用打电话，也不用赶路。 **设备端 AI（on-device AI）**，也叫 **edge AI**，在本地运行模型——在手机、笔记本、传感器、汽车上——不需要去往服务器。计算就发生在数据所在的地方，在你手里的硬件上。**Edge**（边缘）指网络的边缘：远离中心数据中心，处在用户和设备所在的地方。请求不再被送去别处作答，而是当场算出答案。 _Diagram: 设备端：数据和小模型在一起；不需要数据中心。_ #### On-device AI (edge AI) - **是什么:** 模型在本地运行——在手机、笔记本、传感器或汽车上。 - **思路:** 在数据所在的地方算出答案，不必去往服务器。 - **例子:** 手机键盘的自动补全，没有网络也能用。 - **代价:** 你只能用设备跑得动的模型。 - **关联:** 需要**小模型**；带来**隐私、离线、延迟、每次调用 $0**。 ### Round-trip — 全部差别就在一次网络往返 > 在家做饭 vs 叫外卖——饭菜可以一样，但前者每次都要骑手穿过半个城市，后者不用。 云端和设备端的核心区别不在 AI 本身，而在 **round-trip**：你的数据是否离开设备，以及你是否要等网络。这一个区别，驱动着本课里的每一项好处和取舍。把工作留在本地，你得到隐私、离线能力和速度，但只能用设备跑得动的模型。发到云端，你能用上最大的模型，但要为 round-trip、成本和数据外流付出代价。模型在哪里运行，几乎决定了一切。 _Diagram: 左边是云端：每次调用都要一去一回。右边是设备：答案当场就有。_ #### Round-trip (网络往返) - **是什么:** 请求去往服务器的行程，加上响应返回的行程。 - **为什么重要:** 每一项取舍都由它而来：延迟、成本、数据外流。 - **例子:** 一次云端调用：手机 → 互联网 → 服务器 → 互联网 → 手机。一次本地调用：这些统统没有。 - **关联:** **Cloud AI** 永远要付出它；**On-device AI** 避开了它。 > **框架性问题:** “这件事真的需要去云端做一次 round-trip吗——还是模型可以直接在设备上运行，而这会不会改变这里真正重要的东西？” > Cloud AI 运行在通过网络访问的远程服务器上；设备端（edge）AI 在本地运行，没有 round-trip。数据是否外流、是否要等网络，决定了每一项取舍。 ## 2. 为什么要在本地运行 在设备上运行模型不只是技术上的好奇心——它解锁了云端比不了的四大好处，其中任何一个都可能成为转向本地的决定性理由。 ### Privacy — 数据从不离开 > 把日记锁在家里的抽屉里，和把每一页都寄给一家公司去读——前一种把秘密留在你身边，后一种不会。 在本地运行最大的理由是**隐私（privacy）**：如果模型就在设备上，它处理的数据就无需离开——不用把个人照片、私人消息或敏感记录发到服务器。对于用户更愿意留在自己硬件上的东西，或是法规禁止交给第三方的数据，设备端就是答案。在数据所在的地方处理它，而不是把它送到别人的计算机上，这是任何云服务都无法完全比拟的隐私保证。 _Diagram: 照片、消息和笔记都在设备内部处理——没有任何东西发往第三方服务器。_ #### Privacy (数据留在设备上) - **问题:** 个人数据或受监管的数据不能（或不应）发送到服务器。 - **思路:** 在数据所在的地方处理——就在设备上。 - **例子:** 搜索个人照片或整理私人消息，不上传到云端。 - **何时使用:** 敏感数据、法规限制、用户信任。 - **关联:** 在 **hybrid** 中，这一部分位于 **privacy boundary** 之后。 ### Offline — 没有网络也能用 > 在隧道里，纸质地图照样能用，而在线地图一片空白——本地的东西不依赖信号。 设备端模型可以**离线（offline）**工作——在飞机上、在隧道里、在偏远地区，任何没有可靠网络的地方——因为它不需要服务器。网络一断，云端 AI 就干脆停了。对于必须随处可用、或不能假定有网络的功能，在本地运行不是优化，而是唯一的选择。不依赖网络，是云端从根本上无法提供的能力。 _Diagram: 没有信号时，云端功能停了——设备端模型继续作答。_ #### Offline (没有网络也能工作) - **问题:** 没有网络，云端 AI 就完全无法工作。 - **思路:** 设备上的模型不依赖网络。 - **例子:** 飞机上、隧道里、偏远地区的野外作业应用。 - **何时使用:** 功能必须随处可用，且不能假定有网络连接。 - **关联:** 与 **privacy** 一样，是云端从根本上无法提供的东西。 ### Latency — 没有 round-trip，就不用等 > 凭记忆回答，和每次都打电话问人——凭记忆是即时的。 **延迟（latency）**是从请求到响应的时间。没有网络 round-trip，设备端模型几乎可以立刻响应，没有连到远方服务器再返回的那段延迟。对于每一刻都很要紧的功能——自动补全、对输入作出反应——这是一项决定性的好处。 _Diagram: 在云端，一去一回的网络时间要加到计算时间上。在设备上，只有计算时间。_ #### Latency (响应延迟) - **是什么:** 从请求到响应的时间。 - **原理:** 本地没有网络路径——只剩下计算本身。 - **例子:** 你还在打字时，键盘建议就已经出现。 - **何时使用:** 功能对延迟敏感，并且调用频繁。 - **关联:** 直接来自没有 **round-trip**。 ### Per-call cost — 每次调用都不用付账单 > 凭记忆回答是免费的。给付费顾问打电话，则每通电话都要收费。 模型运行在用户已经拥有的硬件上，所以没有**单次调用成本（per-call cost）**——你不必为每个请求向服务商付费。对于高频使用的功能，“即时且每次调用免费”是一个强大的组合，是带着 round-trip 和计费表的云端给不了的。 _Diagram: 在云端，账单随每个请求增长。在设备上，一次调用的成本为零——硬件早已付过钱。_ #### Per-call cost (在设备上为零) - **问题:** 在云端，每个请求都是服务商账单上的一行。 - **思路:** 在用户的硬件上计算：一次调用的成本为零。 - **例子:** 一个每天被调用数百万次的功能，不会推高账单。 - **何时使用:** 常规任务、调用量很大。 - **关联:** 与 **latency** 相配：“即时且每次调用免费”。 > **好处问题:** “隐私、离线使用、即时响应、零单次调用成本——这里是不是有哪一项起决定性作用？因为其中任何一项，都可以成为在设备上运行的理由。” > 在本地运行解锁了云端比不了的四件事：隐私（数据从不离开）、离线使用（不需要网络）、即时响应（没有 round-trip）和零单次调用成本（用户自己的硬件）。 ## 3. 把模型做小 手机跑不动巨大的前沿模型。所以设备端 AI 依赖于把模型做得足够小以便装下——而缩小模型有几种标准办法。 ### SLM — 小模型能装进大模型装不下的地方 > 用一本口袋手册代替一整面墙的百科全书——全面程度差得多，但它装得进口袋，需要时就在手边。 设备的内存和处理能力有限，所以设备端 AI 使用**小语言模型（SLM，small language models）**——**参数**比巨型模型少得多、刻意做得紧凑的模型。它们不可能知道或做到最大模型所能做的一切，但小到足以在手机或笔记本上运行。整个 edge AI 领域都建立在它们之上：能力不弱的小模型这一趋势，才让在本地运行真正的 AI 变得切实可行。 _Diagram: 前沿模型住在数据中心里。SLM 的参数少得多，装得进手机的内存。_ #### SLM (small language model) - **问题:** 巨型模型装不进设备的内存和算力。 - **思路:** 参数少得多、从设计上就很紧凑的模型。 - **例子:** 一个打包进手机或笔记本应用里的小模型。 - **代价:** 知识更少，在难题上更弱。 - **关联:** 用 **quantization** 进一步缩小，由大模型通过 **distillation** 来教。 ### Quantization — 精度更低，体积小得多 > 把一个测量值存成“约 3.1”而不是“3.14159265”——会损失一点精度，但这个数字占的空间小得多，而且在大多数场合照样够用。 缩小模型的一项关键技术是**量化（quantization）**：用更低的精度——大致说，就是更少的位数——来存储模型内部的数字（**权重**，即 **weights**），这样整个模型占用的内存大幅减少，运行也更快。你牺牲一点点精度，换来体积的大幅缩减，对于装进设备来说，这通常是笔很划算的买卖。量化就是把一个原本装不进手机的模型压缩成能装进去的模型的办法，质量损失往往几乎察觉不到。 _Diagram: 同样的权重，更低的精度：用 4 位代替 16 位——内存减少到四分之一。_ #### Quantization (低精度权重) - **问题:** 模型对设备的内存来说太重了。 - **思路:** 用更低的精度存储权重——每个数用更少的位。 - **例子:** 用 4 位权重代替 16 位——模型轻四倍，也更快。 - **代价:** 损失一点精度；往往几乎察觉不到。 - **关联:** 用于 **SLM** 和**蒸馏**后的模型，把它们进一步缩小。 ### Distillation — 小模型向大模型学习 > 一个学徒，为了某一项具体工作而学师傅的手艺——不是师傅会的一切，但足以把这项工作做得几乎一样好，而体积只有一小部分。 另一项技术是**蒸馏（distillation）**：训练一个小模型去模仿大模型，让小模型以紧凑得多的形式，掌握大模型的大部分能力。大的**教师（teacher）**模型的行为，被转移到一个小的**学生（student）**模型里，而学生便宜到可以在本地运行。从一开始就做得紧凑的 SLM、进一步缩小它们的量化，再加上转移能力的蒸馏，三者结合，就能把一个有用的模型做得足够小，住进设备里。 _Diagram: 大的教师模型生成答案；小的学生模型学着模仿它们。_ #### Distillation (teacher → student) - **问题:** 从零训练的小模型很弱，而大模型又装不下。 - **思路:** 用大模型的答案来训练小模型——让它去模仿。 - **例子:** 大模型给样本打标签；小模型学着产出同样的结果。 - **代价:** 学生学到了教师的很多本领，但不是全部。 - **关联:** 与 **SLM** 和 **quantization** 一起——把模型做小的三种办法。 > **缩小问题:** “一个足够小的模型——从设计上紧凑、经过量化或蒸馏——能不能装进我的目标设备，同时仍然把工作做得足够好？” > 设备端 AI 依赖小模型：从设计上紧凑的 SLM、以更低精度存储它们的 quantization，以及把大模型的能力转移到能装进设备的小模型里的 distillation。 ## 4. 小就意味着能力更弱 缩小模型不是没有代价的——小模型确实做不了巨型模型能做的一切。坦诚面对这个差距，才能决定哪些东西该放在设备上。 ### Capability Trade-off — 天下没有免费的午餐 > 口袋计算器 vs 研究实验室——计算器即时可用、总在身边，但你不会让它去设计一座桥。 这就是**能力取舍（capability trade-off）**：小模型确实比大模型能力弱。它的通用知识更少，处理复杂推理没那么可靠，在困难的开放式任务上更弱。让它能在手机上运行的那份紧凑，是用原始能力换来的。所以设备端 AI 并不是简单地把云端 AI 搬到本地——它是一个刻意做弱的模型，换来隐私、离线使用和速度。假装小模型一样聪明，正是 edge 功能让人失望的原因。 _Diagram: 模型越大，能力越强——离设备也越远。刻度的每一端都有所得，也有所失。_ #### Capability Trade-off (体量 vs 能力) - **是什么:** 模型越小，知识越少，推理越弱。 - **收益:** 隐私、离线使用、速度和零单次调用成本。 - **例子:** 本地模型能把一句话补全得很好，但处理不了复杂的分析。 - **陷阱:** 假装小模型等同于巨型模型，是通往失望的路。 - **关联:** 部分可由 **specialization** 挽回，其余由 **hybrid** 覆盖。 ### Task Fit — 常规任务放设备上，难题交给云端 > 一位熟练的本地维修工能把家里的大多数活干得很好，只有那种罕见的、真正棘手的活，你才去找专家。 小的设备端模型很适合**常规、范围明确的任务**——文本分类、简单抽取、转写、自动补全、直接了当的辅助——这些活本来就用不着前沿模型。它在真正困难、新颖、多步骤的问题上就吃力了，而那正是最大的模型发挥价值的地方。这和难度的分布正好吻合：大多数日常任务完全在小模型能力范围之内，只有少数困难的任务才真正需要云端的巨型模型。 所以要讲究的是**任务匹配（task fit）**：让任务与设备跑得动的模型相匹配。如果一个功能的工作足够常规，设备端在隐私、离线、延迟和成本上都占优。如果它确实需要前沿水平的推理，设备做不到，就需要云端。知道这条线划在哪里，是 edge AI 的核心判断。把太难的活硬压给小模型，质量就会受损；把本该上云的活留在本地，功能就会表现不佳。 _Diagram: 左边是多数：交给小模型的常规任务。右边是少数的难题：交给云端。_ #### Task Fit (让任务匹配模型) - **问题:** 把太难的任务交给小模型，质量就差。 - **思路:** 常规且范围明确的放在设备上；前沿级难度的交给云端。 - **例子:** 分类、抽取、转写、自动补全——本地；新颖的多步骤分析——云端。 - **何时使用:** 每次你决定该把什么放在设备上的时候。 - **关联:** 任务之间的这条界线，是 **hybrid routing** 的基础。 > **能力问题:** “这个任务是否足够常规，小模型能做好——还是它确实需要设备给不了的前沿级推理？” > 小模型确实能力更弱——知识更少，困难推理更差。它很适合常规、范围明确的工作，不擅长前沿级的难题，所以要让任务匹配设备真正跑得动的东西。 ## 5. 专精胜过体量 这个洞见让 edge AI 比“小就是弱”所暗示的强大得多：一个专注于单一任务的小模型，在那个任务上可以媲美巨型通才模型。 ### Specialization — 专注的小模型 vs 通用的大模型 > 一位本地外科医生，同一台手术做过几千次，胜过一位很少做这台手术的杰出通才——在具体任务上，窄而精的功力胜过广博的知识。 小模型作为*通才*很弱，但在某个具体、定义明确的任务上，它可以媲美甚至击败大得多的通用模型。这就是**专精（specialization）**。巨型模型把能力分摊到所有事情上；为单一任务训练的小模型，则把有限的能力集中在那一处。所以对于狭窄的任务——你特定的分类、你特定的抽取——一个小的专精模型可以既足够好，又小到能在本地运行。专精挽回了缩小模型时损失的大部分能力。 _Diagram: 巨型模型把能力分摊到所有事情上。小的专家把全部能力给了一项任务。_ #### Specialization (窄模型) - **问题:** 小模型作为通才很弱。 - **思路:** 把它的全部能力对准一项狭窄的任务。 - **例子:** 一个只把客服工单分到你的各个主题里的模型。 - **代价:** 离开它的任务，这个模型仍然很弱。 - **关联:** 通过 **fine-tuning** 实现；挽回 **capability trade-off**。 ### Fine-tuning — 为小模型的工作打磨它 > 让学徒集中训练他每天都要做的那一件事——哪怕没有师傅那样广博的本领，他也会把这件事做得很出色。 让小模型以小搏大的办法，是针对你的具体任务对它做 **fine-tuning**（另有一门专门的课程讲这个）：用恰好是它要做的那项工作的样例来训练它，把这一项技能深深刻进去。针对你狭窄用途调优过的小模型，在这个用途上可以胜过大得多的通用模型——而且它仍然小到能装进设备。它不是一个弱的通才，而是一个碰巧很小的锋利专家。 _Diagram: 基础 SLM + 你的任务样例 → fine-tuning → 仍能装进设备的锋利专家。_ #### Fine-tuning (针对你的任务继续训练) - **问题:** 基础的小模型在你的任务上不够好。 - **思路:** 用恰好是这项工作的样例继续训练它。 - **例子:** 用你已标注的邮件做过 fine-tuning 的 SLM，分拣邮件像巨型模型一样好。 - **代价:** 需要好的样例和训练本身；模型仍然是窄的。 - **关联:** 通向 **specialization** 的路；结果是 **narrow + local**。 ### Narrow + Local — 强大的组合 > 一件只为一个用途打造、就放在手边的工具——不是你拥有的最万能的东西，但在那项任务上最快、最可靠。 设备端 AI 的制胜模式是 **narrow + local**：一个把一件事做得很好的小模型，就在设备上运行。你放弃了通用性——而单一用途的功能本来就不需要它——换来隐私、离线能力、即时响应和零成本。对于一个专注的功能，这种组合完全可以击败云端的巨型模型——更快、更便宜、更私密，而且在它所服务的那一件事上同样出色。专精，就是把“又小又弱”变成“又小又在关键处出色”的东西。 _Diagram: 狭窄的任务与本地执行相遇的地方——那就是制胜区。_ #### Narrow + Local (一件事，在设备上) - **问题:** 作为通才，小模型输给云端。 - **思路:** 一项任务，做到出色，就在设备上。 - **例子:** 一个只转写语音备忘录的本地模型。 - **代价:** 通用性——而单一用途的功能本来就不需要它。 - **关联:** 把 **specialization** 与 **on-device** 的好处结合起来。 > **专精问题:** “这是不是一个狭窄、具体的任务，让经过 fine-tuning 的小模型可以媲美巨型模型——使得设备端不只是可行，而且更好？” > 针对某个具体任务做过 fine-tuning 的小模型，在该任务上可以媲美巨型通才模型。Narrow 加 local——一个在设备上运行的锋利专家——把“又小又弱”变成了“又小又出色”。 ## 6. hybrid 模式 你不必为所有事情在云端和设备之间二选一。最强的系统两者并用——能在本地处理的就在本地处理，只在不得不时才求助云端。 ### Hybrid Routing — 常见情形走本地，困难情形走云端 > 一家诊所，护士就地处理常规就诊，只把复杂病例转给远处的专科医院——大多数需求在本地满足，少数困难的才往上转。 最强的模式是 **hybrid**：在设备上运行一个小模型，处理常见、常规或私密的工作，只在真正困难的情形下才**升级（escalate）**到强大的云端模型。因为大多数请求都很简单，大多数都在本地处理——又快、又免费、又私密——只有困难的少数才会往返云端的巨型模型。这就是模型经济学里的 **routing**（路由）思想，用在设备与云端的边界上：默认选最便宜、最本地的选项，只有当重型模型值得时才动用它。 _Diagram: 设备上的路由器把大多数请求发给本地模型，把困难的发给云端。_ #### Hybrid Routing (本地优先，升级到云端) - **问题:** 只用设备——能力不够；只用云端——没有隐私，也不能离线。 - **思路:** 常见而简单的走本地；少见而困难的升级到云端。 - **例子:** 助手在手机上回答简单问题，把复杂的分析发给云端模型。 - **代价:** 需要一个路由器和两个模型；你得决定什么算“困难”。 - **关联:** 来自模型经济学的 **routing** 思想；依赖 **task fit**。 ### Privacy Boundary — 把私密的和离线的部分留在设备上 > 你在家处理敏感文件，只把真正需要外部专家的部分寄出去——能保持私密的就保持私密。 hybrid 设计让你把对隐私敏感的部分和必须离线可用的部分放在设备上，同时仍然把需要强大推理的重活交给云端。个人数据可以在本地处理、从不外流；只有非敏感、确实困难的工作才会发出去。这样你就不必拿隐私换能力，也不必拿能力换隐私——你设计系统，让每一部分都运行在符合其需求的地方。这条边界本身——**privacy boundary**——就成了一件设计工具。 _Diagram: 个人数据在边界左侧处理。只有非敏感的重活才会越过边界。_ #### Privacy Boundary (什么可以离开设备) - **问题:** 你既需要隐私，又需要云端的强大能力。 - **思路:** 敏感的留在设备上；只有非敏感的重活才发出去。 - **例子:** 个人数据在本地处理，只有一个匿名化后的困难子任务发往云端。 - **代价:** 你得仔细决定什么算敏感。 - **关联:** 结合了 **privacy** 与 **hybrid routing**。 ### Device–Cloud Split — 把边界当作架构决策 > 决定哪些工作留在本地分部，哪些交给总部——一种有意的分工，而不是非此即彼的选择。 成熟的做法，是把“这个在哪里运行”当作**逐个功能**的决策——就像云架构的分层，或 LLM 阶梯的各级台阶。这就是**设备–云端划分（device–cloud split）**。有些工作出于隐私、离线、延迟或成本，属于设备；有些工作出于能力，属于云端；好的系统把每一项放在合适的位置。这不是一个全局的单一选择——而是你一块一块设计出来的架构。 _Diagram: 每个功能都有自己的位置和理由：延迟、隐私、离线——设备；能力——云端。_ #### Device–Cloud Split (逐功能安置) - **问题:** “全上云”或“全在设备”这样的单一选择，不适合任何产品的每一个功能。 - **思路:** 按每个功能的主要需求，决定它在哪里运行。 - **例子:** 自动补全——在设备上（延迟）；困难的多步骤任务——在云端（能力）。 - **何时使用:** 任何同时包含常规和困难 AI 功能的产品。 - **关联:** 把 **hybrid routing** 推广到架构层面。 > **hybrid 问题:** “我能不能在设备上处理常规和私密的工作，只把真正困难的情形升级到云端——既要隐私又要能力，而不是二选一？” > 最强的模式是 hybrid：用小的本地模型处理常见、私密、离线的工作，只在困难情形下才升级到云端的巨型模型。设备–云端划分是一种你一块一块设计出来的架构。 ## 7. 用好它 用好 edge AI，归结为认清本地何时真正占优，并坦诚面对为此交换掉的能力。 ### Decisive Benefit — 当本地真正占优时才上设备 > 当隐私、速度、离线或成本让某件事明显更适合在内部做时，你就把它留在内部——只有真正需要外部专家时才外包。 当设备端的某项好处起**决定性（decisive）**作用时，就上设备：数据必须保持私密，功能必须能离线，响应必须即时，或者单次调用成本必须为零——并且任务足够常规（或足够专精），小模型能够胜任。不要仅仅为了避开云端，就把真正困难的通用任务硬塞给一个弱的本地模型；也不要把本可以留在家里的私密数据发到云端。让位置与这个功能真正看重的东西相匹配。 _Diagram: 有没有决定性的好处？小模型够不够用？答案通向云端、设备，或 hybrid。_ #### Decisive Benefit (转向本地的理由) - **问题一:** 在这里，隐私、离线、延迟或零成本是否起决定性作用？ - **问题二:** 任务是否足够常规或专精，小模型能胜任？ - **例子:** 离线转写笔记：两个“是”——上设备。 - **陷阱:** “只是为了避开云端”而转向本地——结果损失了质量。 - **关联:** 汇集了**四大好处**、**task fit** 和 **hybrid**。 ### Honest Scoping — 对取舍保持坦诚 > 你接受口袋工具不是车间——只把它用在它真正能做的活上，而不是假装它是它不是的东西。 要讲究的是**坦诚界定范围（honest scoping）**：本地模型用真实的能力，换来隐私、离线、速度和成本。不要假装小模型和巨型模型一样聪明；而是把设备端功能的范围，限定在小模型真正能做好的事情上——把它收窄、让它专精，或保持它的常规性——然后把困难的部分路由到云端。用在它的长处与需求相吻合的地方，edge AI 是变革性的；硬推到小模型做不到的地步，它只会让人失望。带着清醒去选择它。 _Diagram: 功能设想被拆开：狭窄、常规、专精的部分放到设备上；困难的部分放到云端。_ #### Honest Scoping (把范围限定在模型能做到的事上) - **问题:** 功能被承诺为“像云端一样”，而小模型做不到。 - **思路:** 把功能的范围限定在小模型真正擅长的事情上。 - **做法:** 收窄它、让它专精、保持它的常规性；把困难的部分交给云端。 - **陷阱:** “小 = 巨型”，是必然通向失望的路。 - **关联:** **capability trade-off** 的直接结果。 ### 这些概念如何联系在一起 > 一架天平：一边托盘是云端的能力，另一边是设备的好处。课程里的每个概念，要么拨动一个托盘——要么帮你两边都得到。 **Cloud AI** 要付出 **round-trip**；**on-device AI** 避开了它，这就是它带来四大好处的原因。但设备需要**小模型**——SLM、quantization、distillation——而它们要付出**能力**的代价。**Specialization**（fine-tuning、narrow + local）挽回其中很大一部分，其余由云端通过 **hybrid** 来覆盖。 _Diagram: 设备避开了 round-trip，带来好处，但需要小模型，并付出能力的代价。专精把能力挽回；hybrid 用云端覆盖其余。_ #### 在构建设备端功能之前 - **是否有决定性的好处**——隐私、离线、延迟或零成本——是云端比不了的？ - **任务是否足够常规或专精**，小模型能做好？ - **模型能否装得下**——从设计上就小、经过量化或蒸馏——在目标设备上？ - **fine-tuning 能否**让一个小的专家在这个狭窄任务上媲美巨型模型？ - **是否应该用 hybrid**——常见情形走本地，困难情形走云端？ - **我是否坦诚**面对自己为本地好处而交换掉的能力？ #### 你把 edge AI 用好的迹象 - 当某项**好处起决定性作用**时才转向本地——隐私、离线、延迟或成本。 - 你用的是**足够小的模型**——从设计上就小、经过量化或蒸馏——能装进设备。 - 你让小模型**专精或做 fine-tuning**，在狭窄任务上媲美巨型模型。 - 你设计了 **hybrid** 划分，把私密和离线的工作留在本地，把困难的情形升级上去。 - 你**坦诚面对能力的取舍**，把功能的范围限定在小模型能做到的事上。 ## 速查表：全部 20 个概念 ### 基础 - **Cloud AI** (数据中心里的模型): 模型运行在远程服务器上；设备通过网络访问它。 - **On-device AI** (edge AI): 模型在本地运行——在手机、笔记本或传感器上。 - **Round-trip** (网络往返): 去服务器再回来。每一项取舍都由它而来。 ### 为什么要本地 - **Privacy** (数据留在原地): 数据从不离开设备。 - **Offline** (不需要网络): 在飞机上、隧道里、偏远地区都能用。 - **Latency** (响应延迟): 没有 round-trip——答案几乎是即时的。 - **Per-call cost** (在设备上为零): 在用户的硬件上，一次调用不花钱。 ### 把它做小 - **SLM** (small language model): 参数少得多的紧凑模型。 - **Quantization** (更低精度): 以更低精度存储权重——小好几倍，也更快。 - **Distillation** (teacher → student): 小的学生学着模仿大的教师。 ### 取舍 - **Capability Trade-off** (体量 vs 能力): 模型越小，知识越少，推理越弱。 - **Task Fit** (让任务匹配模型): 常规的放设备上；前沿级难度的交给云端。 ### 专精 - **Specialization** (窄模型): 一个窄的小模型，在它那一项任务上媲美巨型模型。 - **Fine-tuning** (针对你的任务训练): 用恰好是这项工作的样例来训练它。 - **Narrow + Local** (一件事，在设备上): 一件事做到出色，就在设备上。 ### Hybrid - **Hybrid Routing** (本地优先): 常见的走本地；困难的升级到云端。 - **Privacy Boundary** (什么可以离开): 敏感的留在设备上；只有非敏感的工作才发出去。 - **Device–Cloud Split** (逐功能安置): 每个功能在哪里运行，逐个功能来决定。 ### 用好它 - **Decisive Benefit** (转向本地的理由): 当某项好处起决定作用、且小模型能胜任时，就上设备。 - **Honest Scoping** (把范围限定在模型能做到的事上): 让功能贴合小模型真正能做到的事。 > Edge AI 把一个小模型直接放在设备上运行，用原始能力换来隐私、离线使用、即时响应和零成本。让它专精，在狭窄任务上媲美巨型模型；用 hybrid 把两者兼得；并对这笔取舍保持坦诚。 速成课结束 · 7 章 · 20 个概念 接下来是练习：挑一个常规任务——一次分类、一点抽取——在你自己的机器上用小模型运行它，不发任何云端调用。留意它是即时的、免费的、私密的。然后拿一个真正困难的问题去逼它，感受小模型的极限在哪里。最后，勾勒一个 hybrid：什么留在本地，什么升级到云端。当一个很小的本地模型把你的常规情形处理得完美、而且从不碰网络的那一刻，这笔取舍就变得具体了。但要把一个想法放在所有想法之上：在设备上运行的小模型，用原始能力换来隐私、离线使用、速度和零成本——所以能专精的地方就专精，必须的地方就用 hybrid，并对你所交换的东西保持坦诚。