混合AI定义、优势及处理机制分析

混合AI对生成式 AI规模化扩展至关重要。

1.什么是混合AI？

混合AI指终端和云端协同工作，在适当的场景和时间下分配AI计算的工作负载，以提 供更好的体验，并高效利用资源。在一些场景下，计算将主要以终端为中心，在必要 时向云端分流任务。而在以云为中心的场景下，终端将根据自身能力，在可能的情况 下从云端分担一些AI工作负载。

2.混合AI的优势

混合 AI 架 构（或仅在终端侧运行AI），能 够 在 全 球 范 围 带 来 成 本 、能 耗 、性 能 、隐 私 、 安全和个性化优势。

成本

随着生成式AI模型使用量和复杂性的不断增长，仅在云端进行推理并不划算。因为 数据中心基础设施成本，包括硬件、场地、能耗、运营、额外带宽和网络传输的成本将 持续增加。 例如，当前面向大语言模型推理的云计算架构，将导致无论规模大小的搜索引擎企 业负担更高运营成本。试想一下，未来通过生成式AI大语言模型增强的互联网搜索， 比 如GPT，其运行参数远超1750亿。生成式AI搜索可以提供更加出色的用户体 验和搜索结果，但每一次搜索查询（query）其成本是传统搜索方法的10倍。目前每 天有超过100亿次的搜索查询产生，即 便 基 于 大 语 言 模 型 的 搜 索 仅 占 其 中 一 小 部 分，每 年 增 量 成 本 也 可 能 达 到 数 十 亿 美 元 。

将 一 些 处 理 从 云 端 转 移 到 边 缘 终 端 ，可 以 减 轻 云 基 础 设 施 的 压 力 并 减 少 开 支 。 这使混合 A I 对生成式 A I 的持续规模化扩展变得至关重要 。 混 合 A I 能够利用现 已 部 署 的 、具 备 A I 能 力 的 数 十 亿 边 缘 终 端，以 及 未 来 还 将 具 备 更 高 处 理 能 力 的 数十亿终端。 节省成本也是生成式AI生态系统发展的重要一环，可以支持OEM厂商、独立软件开 发商（ISV）和应用开发者更经济实惠地探索和打造应用。例如，开发者可以基于完 全在终端上运行的Stable Diffusion创建应用程序，对于生成的每个图像承担更低的 查询成本，或完全没有成本。

能耗

支持高效A I处 理 的 边 缘 终 端 能 够 提 供 领 先 的 能 效，尤 其 是 与 云 端 相 比。边缘终端 能够以很低的能耗运行生成式AI模型，尤其是将处理和数据传输相结合时。这一能 耗成本差异非常明显，同时 能 帮 助 云 服 务 提 供 商 降 低 数 据 中 心 的 能 耗，实 现 环 境 和 可持续发展目标。 

可靠性、性能和时延

在 混合A I架 构中，终 端侧AI处理十分可靠，能够在云服务器和网络连接拥堵时， 提供媲美云端甚至更佳的性能7。当生成式AI查询对于云的需求达到高峰期时，会产 生大量排队等待和高时延，甚至可能出现拒绝服务的情况8。向边缘终端转移计算负 载可防止这一现象发生。此外，混合AI架构中终端侧处理的可用性优势，让用户无论 身处何地，甚至在无连接的情况下，依然能够正常运行生成式AI应用。

隐私和安全

终端侧A I从本质上有助于保护用户隐私，因为查询和个人信息完全保留在终端上。 对于企业和工作场所等场景中使用的生成式AI，这有助于解决保护公司保密信息的 难题。例如，用于代码生成的编程助手应用可以在终端上运行，不向云端暴露保密信息，从而消除如今众多企业面临的顾虑9。对于消费者使用而言，混合AI架构中的“隐私 模式”让用户能够充分利用终端侧AI向聊天机器人输入敏感提示，比如健康问题或 创业想法。此 外，终 端 侧 安 全 能 力 已 经 十 分 强 大，并 且 将 不 断 演 进，确保个人数据 和模型参数在边缘终端上的安全。

个性化

混合AI让更加个性化的体验成为可能。数字助手将能够在不牺牲隐私的情况下，根 据 用 户 的 表 情、喜 好 和 个 性 进 行 定 制。所形成的用户画像能够从实际行为、价 值观、 痛点、需求、顾虑和问题等方面来体现一个用户，并且可以随着时间推移进行学习和 演进。它可以用于增强和打造定制化的生成式AI提示，然后在终端侧或云端进行处理。 用户画像保留在终端内，因此可以通过终端侧学习不断优化和更新。 个性化不仅仅适用于消费者，企业或机构可以借助它标准化代码的编写方式，或者 制作具有特殊语气和声音的公共内容。 

3.AI工作负载的分布式处理机制

我们期望打造能够支持不同工作负载分流方式的混合AI架 构，可 以 根 据 模 型 和 查 询复杂度进行分布式处理，并能持续演进。例如，如果模型大小、提示和生成长度小 于某个限定值，并且能够提供可接受的精确度，推理即可完全在终端侧进行。如果 是更复杂的任务，模型则可以跨云端和终端运行；如果需要更多最新信息，那么也可 以连接至互联网获取。

3.1 以终端为中心的混合AI

在以终端为中心的混合A I架构中，终端将充当锚点，云端仅用于分流处理终端无 法充分执行的任务。许多生成式A I模 型 可 以 在 终 端 上 充 分 运 行（参 阅 图2），也 就 是 说终端可通过运行不太复杂的推理完成大部分处理工作。 例如，用户在笔记本电脑上运行 Microsoft 365 Copilot 或必应Chat时，包含高达数 百 亿 参 数 的 模 型 将 在 终 端 上 运 行，而 更 复 杂 的 模 型 将 根 据 需 求 在 云 端 进 行 处 理。 对用户来说，这种体验是无缝的，因为终端侧神经网络或基于规则而运行的判 决器（arbiter）将决定是否需要使用云端，无论是为了有机会使用更好的模型还是检索互联网信息。如果用户对请求处理结果的质量不满意，那么再次尝试发起请 求时可能就会引入一个更好的模型。由于终端侧A I处理能力随着终端升级和芯片 迭代不断提升，它可以分流更多云端的负载 。

对于各种生成式A I应 用，比 如 创 作 图 像 或 起 草 邮 件，快 速 响 应 式 的 推 理 更 受 青 睐， 即使它在准确度上会稍有损失。终端侧AI的快速反馈（即低时延）可以让用户使用 改进的提示来快速迭代推理过程，直至获得满意的输出结果。

3.2 基于终端感知的混合AI

在基于终端感知的混合AI场景中，在边缘侧运行的模型将充当云端大语言模型（类 似 大 脑 ）的 传 感 器 输 入 端（ 类 似 眼 睛 和 耳 朵 ）。例 如，当 用 户 对 智 能 手 机 说 话 时 ， Whisper 等自动语音识别（ASR）的AI模型将在终端侧运行，将语音转为文字，然后 将其作为请求提示发送到云端。云端将运行大语言模型，再将生成的文本回复发回 终端。之后，终端将运行文本生成语音（TTS）模型，提供自然免提回答。将自动语音 识别和文本生成语音模型工作负载转移至终端侧能够节省计算和连接带宽。随着大 语言模型变为多模态并支持图像输入，计算机视觉处理也可以在终端上运行，以进 一步分流计算任务并减少连接带宽，从而节省成本。

在更先进的版本中，隐私将得到进一步保护，终端侧AI能够承担更多处理，并向云 端提供经过改进且更加个性化的提示。借助终端侧学习和终端上的个人数据，比如 社交媒体、电子邮件、消息、日历和位置等，终端将创建用户的个人画像，与编排器 （orchestrator）程序协作，基于更多情境信息提供更完善的提示。例如，如果用户让手 机来安排与好友会面的时间并在喜爱的餐厅预订座位，编排器程序了解上述个性化信 息并能够向云端大语言模型提供更佳提示。编排器程序可在大语言模型缺乏信息时 设置护栏并帮助防止产生“AI幻觉 ”。对于较简单的请求，较小的大语言模型可在终 端侧运行，而无需与云端交互，这类似于以终端为中心的混合AI。

3.3 终端与云端协同处理的混合AI

终端和云端的AI计算也可以协同工作来处理AI负载，生成大语言模型的多个token就 是 一 个 例 子 。大 语 言 模 型 的 运 行 都 是 内 存 受 限 的，这 意 味 着 计 算 硬 件 在 等 待 来 自 DRAM的内存数据时经常处于闲置状态。大语言模型每次推理生成一个token，也就 是基本等同于一个单词，这意味着GPT-3等模型必须读取全部1750亿参数才能生 成一个单词，然后再次运行整个模型来生成下一个token，完整的推理过程可以以此 类推。鉴于内存读取是造成推理性能的瓶颈因素，更高效的做法就是同时运行多个大 语言模型以生成多个token，并且从DRAM一次性读取全部参数。每生成一个token 就要读取全部参数会产生能耗和造成发热，因此使用闲置的算力通过共享参数来推 测性并行运行大语言模型，可谓是在性能和能耗上实现双赢。

为了生成四个token，一个近似的大语言模型（比原始目标大语言模型小7至10倍，因此 准确性更低）要在终端上按顺序连续运行四次才可以。终端向云端发送这四个token， 云端高效运行四次目标模型来检查其准确度，而仅读取一次完整的模型参数。在云端 token是被并行计算的，每个目标模型都有零个、一个、两个、三个或四个预测token 作为输入。这些token在被云端确认或校正之前被认为是“近似的”。上述推测性解码 过程将持续到完整的答案出现时为止。我们的早期实验和其他已发布结果10显示， 通过四个token的推测性解码，平均两到三个token是正确可被接受的，这会带来单 位时间内生成 token数的增加，并节省能耗。