第 2 章：机器学习系统

目标

机器学习系统所处的环境如何决定其系统本质？为何这些系统会在不同计算平台上广泛部署？

机器学习系统必须适应极为多样的计算环境，每种环境都带来独特的约束与机遇。云端部署可利用海量算力，但受限于网络延迟；移动设备贴近用户，却受制于严苛的功耗限制；嵌入式系统通过本地处理降低延迟，但模型复杂度受限；而极小型设备则实现大规模感知，但内存仅有数千字节。这些部署场景决定了系统架构、算法选择和性能权衡。理解环境特定的需求，是机器学习系统工程决策的基础。掌握这些知识，工程师才能选择合适的部署范式，设计兼顾性能、效率与实用性的系统架构，适配不同计算平台。

学习目标

• 解释物理约束（光速、功耗墙、内存墙）为何决定了多样化的 ML 部署范式
• 区分云端 ML、边缘 ML、移动端 ML 和 TinyML 的资源特征、约束与最佳应用场景
• 分析算力、延迟、隐私、能效等资源权衡，制定针对具体应用的部署策略
• 运用系统化的部署决策框架，评估 ML 应用的隐私、延迟、算力与成本需求
• 通过“训练 - 推理分离”“层级处理”“渐进式部署”“联邦学习”等模式，设计混合 ML 架构
• 评估真实 ML 系统，识别其采用的部署范式及效果
• 批判常见部署误区，避免 ML 系统架构设计中的错误决策
• 总结通用设计原则，构建在不同部署环境下均能兼顾性能、效率与实用性的 ML 系统

部署范式框架

前文介绍了机器学习系统的三大核心组成：数据、算法与计算基础设施。虽然这一三元框架为理论奠定了基础，但从概念到实践的转变，关键在于部署环境。部署环境是决定系统设计的核心维度。本章将系统性分析计算环境如何塑造 ML 系统的架构决策，建立以部署为核心的系统工程理论基础。

当代机器学习应用因部署约束而呈现出极为丰富的架构多样性。以计算机视觉为例¹：同一卷积神经网络在不同环境下部署，系统形态截然不同。云端医学影像可利用几乎无限的算力，采用集成方法²和复杂预处理；而移动端实时目标检测则需大幅简化架构以满足极低延迟要求。工厂自动化则更强调能效和确定性响应，牺牲模型复杂度。这些差异并非算法本身，而是环境约束塑造的架构选择。

本章将提出机器学习部署范式的系统分类法，分析从云数据中心到微控制器嵌入式系统的四大主流部署类别。每种范式都源于不同的运行需求：算力、功耗、延迟、隐私和网络连接假设。通过理论框架，为生产级 ML 系统的架构决策提供分析基础。

现代部署策略已超越传统的“中心化 - 分布式”二元对立。越来越多的应用采用混合架构，将计算任务在多个范式间分配，以优化整体性能。例如语音识别系统：唤醒词检测在超低功耗嵌入式芯片上实现，语音转文本在移动端处理以保障隐私和低延迟，语义理解则交由云端完成。这种多范式协作反映了工程现实：最优的 ML 系统往往需要架构异构性。

部署范式空间具有清晰的维度结构。云端 ML 追求极致算力，接受网络延迟；边缘计算则将推理靠近数据源，满足低延迟需求；移动端 ML 强调用户本地和离线能力；TinyML 则以极低能耗实现大规模分布式智能，但模型复杂度极低。

通过对这些部署范式的系统分析，本章将建立以系统工程为核心的 ML 架构设计方法论，帮助工程师在算法能力与实际约束间实现最佳平衡。最终将介绍混合架构的集成策略，以及适用于所有部署场景的核心设计原则。

图 1 展示了算力、延迟和部署约束如何形成这一部署谱系。 第 7 章：AI 框架 将探讨支撑各范式的软件工具， 第 11 章：AI 加速 关注硬件加速，而本章聚焦于决定系统架构的根本部署权衡。下文将系统梳理各主流范式，并分析它们如何在现代 ML 系统中协同。

部署谱系

从云到嵌入式的部署谱系并非出于设计偏好，而是由计算系统的物理定律所决定。这些不可逾越的约束为工程师划定了硬性边界，推动了针对不同场景优化的专用部署范式的演化。

光速决定了实时应用的最低延迟。光在光纤中传播速度约为每秒 20 万公里，美东到美西的理论最小往返延迟为 40ms。加上路由、DNS 和处理开销，云服务总延迟通常为 100-500ms。对于需要 10ms 内响应的安全关键应用（如自动驾驶紧急制动、工业机器人），云端部署物理上不可行。

功耗墙源于 Dennard 缩放失效（2005 年），晶体管微缩不再降低功率密度，芯片无法无限提速，否则功耗和热量将同步激增。数据中心 30-40% 电力用于制冷，移动设备需热降频防止损坏。这一约束推动了低功耗架构在移动和嵌入式领域的普及。

内存墙指处理器速度与内存带宽的差距日益扩大。算力可通过增加处理单元线性提升，但内存带宽仅随芯片面积平方根增长，导致数据传输成为瓶颈。大模型尤为突出，参数量远超内存带宽承载能力。

规模经济带来单位成本差异。云服务器可虚拟化支持数千用户，单用户成本低于$50。但需保障响应或隐私的应用无法共享资源，失去经济优势。嵌入式处理器单价$5-50，可部署到数十亿终端，云连接则成本高昂。

这些物理约束是永久性的，决定了计算格局。理解这些边界，有助于做出合理的 ML 系统架构决策。

如图 1 所示，部署谱系的存在源于物理与硬件约束，而非设计偏好。理解这些限制，有助于认识为何 ML 系统无法采用统一方案，必须覆盖从云到嵌入式的全谱系。

第 1 章：引言 建立了 ML 系统三要素（数据、算法、基础设施）的统一框架，各部署范式正是基于物理约束对三要素的不同优化。云端 ML 以丰富基础设施支撑复杂算法，移动端 ML 强调数据本地性，TinyML 则在极端资源下追求算法高效。

现代计算的最大瓶颈在于内存带宽与算力的扩展速率不同。算力可线性扩展，内存带宽仅随芯片面积平方根增长，导致处理器“饿死”在等待数据上。大模型尤甚，参数量远超带宽承载能力。

Dennard 缩放失效³进一步加剧了这一问题。2005 年前，晶体管微缩可提升频率且功耗不变，之后功率密度不降反升，推动多核与专用加速器（GPU/TPU）发展。移动设备需热降频，数据中心需大规模制冷，功耗墙直接推动了低功耗架构和边缘部署的需求。

物理极限还带来不可逾越的延迟下限。光速决定美东西岸 80ms 往返，网络路由等再加 20-420ms，总延迟 100-500ms，纯云端部署无法满足实时需求。网络带宽受限于光纤物理和无线频谱。通信约束要求本地处理，驱动边缘部署。

热量也是限制因素。移动设备需降频防止过热，数据中心需大规模制冷，温度过高会降低可靠性、提升错误率、加速老化。热约束要求在不同场景下权衡算力与可持续运行。

这些约束推动了四大部署范式的演化。理解这些核心约束，是选择合适部署范式、设定合理性能预期的基础。

这些理论约束在硬件上有具体体现。表 1 展示了各范式代表性硬件平台，涵盖算力、功耗、成本等，直观反映了不同部署方式的实际影响。⁴⁵

在理解了部署谱系的物理与经济驱动后，本章将系统分析各个主要部署范式，首先是云端 ML，其他范式皆由此衍生。云端 ML 在追求算力的同时，接受网络带来的延迟约束，适合对计算能力要求极高、但可容忍延迟的任务，如复杂模型训练和推理。

云端机器学习利用集中式基础设施的可扩展性与算力，处理大规模数据、协作开发模型和进行高级分析。云数据中心采用分布式架构和专用资源，训练复杂模型，支持从推荐系统到自然语言处理等多种应用。接下来将详细探讨云端 ML 系统在大规模应用中的有效性。

云端 ML 定义

云端机器学习（Cloud ML）是指在_集中式计算基础设施（如数据中心）上部署机器学习模型。这些系统的_功率范围在千瓦到兆瓦_之间，利用_专用计算系统_处理_大规模数据集_和训练_复杂模型。云端 ML 提供_可扩展性_和_计算能力_，适合需要大量资源和协作的任务。然而，它依赖于_稳定的网络连接_，并可能对实时应用引入_延迟_。

图 3 概述了云端 ML 的能力，后文将详细讨论。

云基础设施和规模

要理解云端 ML 在部署谱系中的位置，首先需考虑其定义特征。云端 ML 的主要特征是其集中式基础设施，具备前所未有的规模。图 4 通过 Google Cloud TPU 的例子说明了这一点⁶。如表 1 所示，云端系统如 NVIDIA DGX A100 和 Google TPU v4 Pod 相比移动设备具有 100-1000 倍的计算优势，具备>1000 TFLOPS 的计算能力和兆瓦级的功耗。云服务提供商提供的虚拟平台具备>100GB/s 的内存带宽，分布在全球的数据中心支持在资源受限设备上无法实现的计算负载。然而，这种集中化带来了关键的权衡：100-500ms 的网络往返延迟使得实时应用无法使用，而运营成本则随使用量线性增加。

云端基础设施带来了通过云 API 的卓越部署灵活性⁷，使训练好的模型可以通过移动、Web 和 IoT 平台在全球范围内访问。多个团队可以无缝协作，同时访问项目并进行集成版本控制。按需计费的定价模式⁸消除了前期资本支出，而资源则可以根据需求弹性扩展。

一个常见的误区是认为云端 ML 强大的计算资源使其对所有应用都具有普遍优势。云基础设施提供了卓越的计算能力和存储，但这一优势并不意味着对所有应用都是最优解。云端部署带来了显著的权衡，包括网络延迟（通常为 100-500ms 的往返）、传输敏感数据时的隐私问题、随使用量增加的持续运营成本，以及对网络连接的完全依赖。而边缘和嵌入式部署在需要实时响应（如自动驾驶需要<10ms 的决策时间）、严格的数据隐私（如处理病人数据的医疗设备）、可预测的成本（一次性硬件投资与持续的云费用相比）或在无网络环境下操作（如偏远地区的工业设备）时表现更佳。最佳的部署范式取决于具体应用的需求，而非单纯的计算能力。

云端 ML 的权衡与约束

云端 ML 的巨大优势伴随着固有的权衡，影响着部署决策。延迟是最重要的物理约束。网络往返延迟通常在 100-500ms 之间，使得云处理不适合需要<10ms 响应的实时应用，如自动驾驶和工业控制系统。除了基本的时间约束外，网络延迟导致的不可预测响应时间还使得跨地理分布的基础设施性能监控和调试变得复杂。

隐私和安全在采用云端部署时也是重大挑战。将敏感数据传输到远程数据中心带来了潜在的安全漏洞，并使得遵循法规变得复杂。处理受 GDPR⁹或 HIPAA¹⁰等法规约束的数据的组织，必须实施全面的安全措施，包括加密、严格的访问控制和持续监控，以满足严格的数据处理要求。

成本管理带来了运营复杂性，因为费用会随着使用量的增加而增加。以一个每天处理 100 万次推理请求、每次$0.001 的生产系统为例：年成本达到$365,000，而一次性购买边缘硬件的费用仅为$100,000。云端与边缘硬件的成本平衡点在 100,000-1,000,000 次请求之间，直接影响部署策略。不可预测的使用高峰进一步复杂化了预算编制，要求具备复杂的监控和成本管理框架。

网络依赖性是另一个关键约束。任何连接中断都会直接影响系统可用性，这在网络接入有限或不可靠的地方尤为成问题。此外，供应商锁定也使得在不同提供商之间转换时，工具和 API 的依赖性带来了可移植性和互操作性挑战。组织必须根据应用需求和风险承受能力，仔细权衡这些约束与云端带来的好处，并制定相应的弹性策略，详见 第 16 章：稳健 AI 。

大规模训练与推理

云端 ML 的计算优势在需要大规模计算的消费级应用中最为明显。虚拟助手如 Siri 和 Alexa，利用云端 ML 处理自然语言，能够同时处理海量并发交互，并通过不断接触多样的语言模式和用例进行自我优化。

Netflix 和 Amazon 的推荐引擎则展示了云端资源的另一种重要应用。这些系统使用协同过滤¹¹等技术处理海量数据集，发掘用户偏好和行为模式。云计算资源使得随着用户数据的增长，系统能够持续更新和优化；Netflix 每天处理超过 1000 亿条数据点，以提供个性化内容推荐，直接提升用户参与度。

金融机构通过云端 ML 能力彻底改变了欺诈检测。通过实时分析海量交易数据，基于历史欺诈模式训练的 ML 算法能够检测异常和可疑行为，帮助实现主动欺诈预防，最大限度减少财务损失。

这些应用展示了云端 ML 如何将计算优势转化为大规模复杂处理任务的变革能力。除了这些旗舰应用，云端 ML 还广泛应用于社交媒体的个性化广告、电子邮件服务中的预测文本、电子商务中的产品推荐、搜索结果的增强以及网络安全威胁检测等日常在线体验中。

边缘 ML：降低延迟与隐私风险

云端 ML 的计算优势伴随着固有的权衡，限制了其在许多现实场景中的适用性。前文提到的 100-500ms 延迟和隐私问题，成为了需要即时响应或本地数据处理应用的障碍。边缘 ML 应运而生，旨在消除这些障碍，通过将计算移 closer to 数据源，降低延迟，同时满足本地数据主权的需求。

这一范式转变对于云端往返延迟不可接受的应用至关重要。需要毫秒级决策的自主系统和要求实时响应的工业物联网¹²应用，无法容忍网络延迟。同样，受限于严格数据隐私法规的应用，必须在本地处理信息，而不是将其传输到远程数据中心。边缘设备（网关和 IoT 集线器¹³）在部署谱系中占据中间地带，在资源约束和性能需求之间取得平衡。

边缘 ML 定义

边缘机器学习（Edge ML）是指在_网络边缘或附近_部署机器学习模型。这些系统的_功率范围在十瓦到几百瓦_之间，依赖于_本地化硬件_实现_实时处理。虽然移动设备也可以看作是一种边缘计算，但边缘 ML 通常指_专用的、固定的基础设施，如网关、现场服务器或工业控制器，其计算能力介于个人移动设备和云数据中心之间。边缘 ML 通过本地处理数据，减少_延迟_并增强_隐私_，但其主要限制在于_相较于云基础设施的计算资源受限_。图 5 概述了边缘 ML 的关键维度，后文将详细探讨。

边缘 ML 的应用涵盖可穿戴设备、工业传感器和智能家居电器等，这些设备在不依赖中央服务器的情况下处理数据¹⁴（图 6）。边缘设备在计算资源、功耗和成本上介于云系统和移动设备之间。25-100 GB/s的内存带宽支持100MB-1GB参数的模型，通过优化技术（ 第 10 章：模型优化 ）实现比云端模型快 2-4 倍的推理速度。通过本地处理消除网络往返延迟，实现<100ms 的响应时间，同时节省大量带宽：本地处理 1000 个摄像头视频流可避免 1Gbps 的上行带宽费用，每年可为云端节省$10,000-100,000 的开支。

边缘 ML 的优势与部署挑战

边缘 ML 提供了可量化的好处，解决了云端的关键限制。延迟从云端的 100-500ms 降低到边缘的 1-50ms，使得需要实时响应的安全关键应用成为可能¹⁵。带宽节省同样显著：一家零售商店如果有 50 个摄像头实时传输视频，带宽需求可从 100Mbps（每月$1,000-2,000 的费用）降至不足 1Mbps，通过本地处理仅传输元数据，减少 99% 的带宽需求。隐私通过本地处理得到改善，消除了传输风险，简化了合规性。操作弹性确保系统在网络故障期间仍能正常运行，这对于制造、医疗和建筑管理等领域至关重要。

这些好处也带来了相应的局限性。有限的计算资源¹⁶显著限制了模型复杂度：边缘服务器的处理能力通常是云基础设施的 10-100 倍，限制可部署模型的参数量在百万级别，而非亿万级别。管理分布式网络的复杂性呈非线性增长。协调成千上万设备的版本控制和更新需要复杂的编排系统¹⁷。物理可接触性带来的安全挑战也更加严峻，部署在零售店或公共基础设施中的边缘设备面临篡改风险，需要基于硬件的保护机制。硬件异构性进一步增加了部署的复杂性，因为不同能力的多样化平台需要不同的优化策略。边缘服务器的初始部署成本为$500-2,000，虽然这些成本会被长期的运营节省所抵消，但在大规模部署时仍需考虑。

实时工业与物联网系统

在对延迟、数据隐私和操作弹性要求严格的场景中，边缘 ML 得到了广泛应用。自动驾驶汽车可能是最具挑战性的应用之一，其安全关键决策必须在毫秒级别内完成，基于无法传输到远程服务器的传感器数据。特斯拉的全自动驾驶系统就是一个例子，它的边缘硬件能够在<10ms 内处理来自八个摄像头的输入，做出驾驶决策，而这一延迟是云处理由于网络原因无法实现的。

智能零售环境则展示了边缘 ML 在带宽密集型、敏感隐私的应用中的实际优势。Amazon Go 商店通过数百个摄像头的实时视频流处理，跟踪顾客的移动和商品选择，实现无现金自助购物。这一基于边缘的方案同时解决了技术和隐私问题：数百个摄像头的高分辨率视频传输需要超过 200Mbps 的带宽，而本地处理确保顾客视频数据不离开商店，消除了隐私担忧和合规风险。

工业物联网¹⁸利用边缘 ML 实现对生产效率和工人安全有直接影响的应用。制造设施部署边缘 ML 系统进行实时质量控制，视觉系统以超过每分钟 60 个零件的速度检查焊接质量，并进行预测性维护¹⁹，监控每个设施超过 10,000 个工业资产。这种方法在各制造行业实现了 25-35% 的计划外停机时间减少。

智能建筑利用边缘 ML 在网络故障期间优化能耗，同时保持操作连续性。配备边缘建筑管理系统的商业建筑，处理来自 5,000-10,000 个传感器的数据，监测温度、占用率、空气质量和能耗，边缘处理将云端传输需求减少 95%，同时实现亚秒级响应时间。医疗保健应用同样利用边缘 ML 进行病人监测和手术辅助，通过本地处理保持 HIPAA 合规，同时实现实时手术指导的<100ms 延迟。

移动 ML：个人化与离线智能

边缘 ML 解决了云端部署的延迟和隐私限制，但也带来了新的约束：对专用边缘基础设施的需求、持续的网络连接以及可观的前期硬件投资。数十亿个人计算设备（智能手机、平板电脑和可穿戴设备）的普及，使得将智能直接带入用户手中成为可能。移动 ML 正是这一趋势的产物，优先考虑用户的接近性、离线能力和个性化体验，同时在电池供电设备固有的严格功耗和热量限制下运行。

移动 ML 将机器学习直接集成到可携带设备中，如智能手机和平板电脑，为用户提供实时、个性化的功能。当用户隐私、离线操作和即时响应比计算复杂性更为重要时，这一范式表现尤为出色。移动 ML 支持语音识别²⁰、计算摄影²¹和健康监测等应用，同时通过设备内计算保护数据隐私。这些电池供电的设备必须在性能与能效、热管理之间取得平衡，适合频繁、短时的 AI 任务。

移动 ML 定义

移动机器学习（Mobile ML）使机器学习模型能够直接在_可携带的电池供电设备（如智能手机和平板电脑）上运行。其功率范围在_单瓦到十瓦_之间，利用_设备内计算_提供_个性化和响应迅速的应用。该范式保护_隐私_并确保_离线功能_，但必须在_性能_与_电池寿命、存储限制_之间取得平衡。接下来将通过四个关键维度分析移动 ML，揭示该范式如何在能力与约束间取得平衡。图 7 概述了移动 ML 的能力。

移动设备的约束介于边缘设备与云设备之间：8GB 内存、128GB-1TB 存储、通过神经处理单元²²实现的 1-10 TOPS AI 计算，功耗为 3-5W。系统级芯片架构²³将计算与内存集成，以最小化能耗。25-50 GB/s的内存带宽将模型限制在10-100MB参数，需通过激进的优化（ 第 10 章：模型优化 ）来适应。电池限制（18-22Wh 容量）使得能量优化至关重要：1W 的持续 ML 处理将设备使用寿命从 24 小时缩短至 18 小时。专用框架（TensorFlow Lite²⁴、Core ML²⁵）提供硬件优化的推理，确保<50ms 的用户界面响应时间。

移动 ML 的优势与资源约束

移动 ML 在提供响应迅速、保护隐私的用户体验方面表现出色。实时处理实现了<10ms 的延迟，确保了面部检测在 60fps 下低于 5ms 的延迟，语音唤醒检测在 2-3ms 内响应。隐私通过设备内处理得到保障，所有数据均在本地处理，Face ID 的生物识别数据完全在硬件隔离的安全区内处理²⁶，键盘预测在用户数据上本地训练，健康监测在无复杂基础设施要求下保持 HIPAA 合规。离线功能消除了对网络的依赖：谷歌地图在本地分析数百万条道路段数据进行导航，翻译支持 40 多种语言对的实时翻译，模型大小为 35-45MB，准确率达到云端的 90%，音乐识别则在本地数据库中匹配。个性化深度前所未有，iOS 以 70-80% 的准确率预测用户下一个打开的应用，通知管理根据个人模式优化投递时机，摄像头系统则通过隐式反馈不断适应用户偏好。

这些优势是以显著的资源约束为代价的。旗舰手机为单个 ML 应用分配的内存仅为 100MB-1GB，占总内存的 0.5-5%，迫使模型保持在 100-500MB 以内，而云端则可部署 350GB 以上的模型。电池寿命²⁷对用户影响明显：每小时处理 100 次推理，每次 0.1 焦耳，日常消耗 0.36% 的电池，叠加基线耗电；而视频处理以 30fps 运行则可能将电池寿命从 24 小时缩短至 6-8 小时。热降频则会不可预测地限制持续性能，A17 Pro 芯片峰值性能为 35 TOPS，但在长时间运行中仅能维持 10-15 TOPS，需采用自适应性能策略。开发复杂性在各平台间成倍增加，Core ML 和 TensorFlow Lite 需分别实现，设备异构性（尤其是 Android 从$100 的入门机型到$1,500 的旗舰机型）要求多种型号的模型。部署摩擦则带来更多挑战：应用商店审批流程需 1-7 天，无法像云端部署那样快速修复 bug。

个人助手与媒体处理

移动 ML 在多个应用领域取得了变革性成功，充分展示了设备内处理的独特优势。计算摄影或许是最显著的例子，它将智能手机相机转变为复杂的成像系统。现代旗舰手机的每张照片都经过多个 ML 处理流程：人像模式²⁸利用深度估计和分割网络实现单反相机级别的虚化效果，夜景模式则通过 ML 对齐和合并 9-15 帧，降噪提升 10-20dB，谷歌 Pixel 更是对每张照片处理 10-15 个不同的 ML 模型，实现 HDR 合并、超分辨率和场景优化。

语音驱动的交互则展示了移动 ML 如何改变人机沟通。这些系统将超低功耗的唤醒词检测（消耗<1mW）与设备内语音识别（延迟<10ms）相结合，用于简单命令的处理。键盘预测演变为上下文感知的神经网络模型，短语预测准确率达到 60-70%，减少 30-40% 的输入工作量。实时相机翻译则以 15-30fps 的速度处理 100 多种语言，完全依赖设备内处理，实现即时视觉翻译。

通过可穿戴设备如苹果手表，健康监测从传感器数据中提取复杂信息，同时保持完全隐私。这些系统在活动检测中超过 95% 的准确率，并包括 FDA 批准的心房颤动检测，灵敏度超过 98%，在设备内处理极其敏感的健康数据，以维持 HIPAA 合规。无障碍功能通过持续的本地处理展现出变革性的社会影响：实时文本检测和识别、声音识别通过触觉反馈提醒听障用户环境提示、VoiceOver 生成视觉内容的自然语言描述。

增强现实框架利用移动 ML 实现 60fps 的实时环境理解。ARCore 和 ARKit 以厘米级精度追踪设备位置，同时映射 3D 环境，实现手部追踪（提取 21 个关节的 3D 姿势）和面部分析（50 多个关键点网格）以实现实时效果。这些应用要求持续的亚 16ms 帧时间，仅有设备内处理才能满足用户期望的无缝体验。

尽管移动 ML 展现了强大的能力，但一个常见的陷阱是试图直接将桌面训练的模型部署到移动或边缘设备，而不进行架构修改。强大的工作站上开发的模型在资源受限设备上往往会失败。以 ResNet-50 模型为例，它在推理时需要 4GB 内存（包括激活和批处理）和 40 亿次浮点运算，如果直接运行在 512MB RAM 和 1 GFLOP/s处理器的设备上，将无法实现。除了简单的资源违规，针对桌面的优化模型可能使用移动硬件不支持的操作（专用数学运算）、假设浮点精度而嵌入式系统不具备，或需要与单样本推理不兼容的批处理。成功部署要求从一开始就进行架构感知设计，包括针对移动设备的专用架构技术、仅整数运算的微控制器，以及在降低计算量的同时保持准确性的优化策略。

Tiny ML：超大规模的感知

从云端到边缘再到移动的演进，展示了智能如何在计算平台上逐步分布，但每一步仍需相当的资源。即使是移动设备，凭借其复杂的处理器和数 GB 的内存，仍处于全球计算格局的相对特权地位，需求以瓦特计的功耗和数百美元的硬件投资。对于真正普及的智能（每个表面都有传感器、每台机器都有监控、每个物体都有智能），这些资源需求仍然过于高昂。Tiny ML 通过将智能推向其绝对极限，完成了这一部署谱系的构建，使用成本低于$10、功耗低于 1 毫瓦的设备。这一范式不仅在技术上实现了普遍感知的可行性，更在经济上使其在大规模应用中成为可能。

与移动 ML 需要数 GB 内存和多核处理器的复杂硬件不同，Tiny 机器学习在具有千字节 RAM 和单美元价格点的微控制器上运行。这一极端约束迫使我们在机器学习部署的思路上发生重大转变，优先考虑超低功耗和极小成本，而非计算复杂性。这一结果使得在其他任何规模下都不可能实现的新类型应用成为可能。

Tiny ML 将智能带入最小的设备中，从微控制器²⁹到嵌入式传感器，在资源极为受限的环境中实现实时计算。这一范式在需要普遍感知、自主操作和极端能效的应用中表现出色。Tiny ML 系统支持预测性维护、环境监测和简单手势识别等应用，同时针对能效进行了优化³⁰，通常在有限的电源如纽扣电池上运行数月或数年³¹。这些系统在偏远或断网环境中提供可行的解决方案，克服了电源、连接和维护访问的限制。

Tiny ML 定义

Tiny 机器学习（Tiny ML）是指在_超受限设备（如微控制器和传感器）上执行机器学习模型。这些设备的功率范围在_毫瓦到亚瓦_之间，优先考虑_能效_和_紧凑性。Tiny ML 实现了在资源受限环境中的_本地决策_，在需要_有限电源下的长期运行_的应用中表现出色。然而，由于计算资源极为有限，其应用范围也受到限制。

接下来将通过四个关键维度分析 Tiny ML，概述本章讨论的 Tiny ML 的关键特征。图 8 概述了 Tiny ML 的关键特征。

极端资源限制

TinyML 在硬件极限下运行：Arduino Nano 33 BLE Sense（256KB RAM、1MB Flash、0.02-0.04W、$35）和 ESP32-CAM（520KB RAM、4MB Flash、0.05-0.25W、$10）分别比云系统减少了 30,000-50,000 倍的内存和 160,000 倍的功耗（图 9）。这些约束实现了数月或数年的自主运行³²，但要求专门的算法在<1 TOPS 算力和微秒级响应时间下提供可接受的性能。设备尺寸从手掌大小到 5x5mm 芯片不等³³，使其能够在以前无法想象的环境中实现普遍感知。

TinyML 的优势与操作权衡

TinyML 在其他规模下无法实现的独特优势，使其在某些应用场景中具有变革性潜力。微秒级的延迟消除了所有传输开销，实现了 10-100μs 的响应时间，满足了对亚毫秒决策的应用需求：工业振动监测以 10kHz 的采样率处理，延迟低于 50μs；音频唤醒词检测分析 16kHz 音频流，延迟低于 100μs；精密制造系统以超过每分钟 1000 个零件的速度进行检测。对于大规模部署而言，TinyML 的经济优势同样显著：完整的 ESP32-CAM 系统仅需$8-12，使得 1000 个传感器的部署成本仅为$10,000，而蜂窝网络替代方案则需$500,000-1,000,000。农业监测在$5,000-30,000 之间即可覆盖 100 公顷，而基于摄像头的系统则需$100,000-200,000 以上；而 10 万个传感器的城市级网络，使用 TinyML 的成本为$1-2 百万，而边缘替代方案则需$50-100 百万。能量效率使得设备在纽扣电池上以 1-10mW 的功耗运行数年，支持如野生动物追踪、混凝土结构健康监测和无电力基础设施下的农业传感器等应用。通过太阳能、振动或热量等方式的能量收集，甚至可以实现设备的永久运行。由于数据始终保留在传感器内，隐私保护优于其他所有范式，提供了无法通过加密强度实现的数学保障。

这些能力的实现以巨大的权衡为代价。计算约束极大：微控制器提供的 RAM 为 256KB-2MB，而智能手机为 12-24GB（差距达 5,000-50,000 倍），迫使模型保持在 100-500KB，参数量在 10,000-100,000 之间，而移动设备为 1-10 百万参数。开发复杂性要求跨越神经网络优化、硬件级内存管理、嵌入式工具链和专用调试（使用示波器和 JTAG 调试器）等多个领域的专业知识，涵盖多种微控制器架构。模型准确性因极端压缩而下降，TinyML 模型通常仅实现云端模型准确性的 70-85%，而移动设备为 90-95%，这限制了其在对精度要求高的应用中的适用性。部署灵活性受限，设备通常运行单一固定模型，更新时需耗费大量电力进行固件刷新，且存在刷坏设备的风险。初始部署决策至关重要，因为设备的操作寿命可达数年。生态系统的碎片化³⁴（微控制器供应商和 ML 框架之间）带来了巨大的开发开销和平台锁定挑战。

TinyML 在环境与健康监测中的应用

Tiny ML 在其独特优势得以发挥的领域取得了显著成功——超低功耗、极小成本和数据隐私保护，使得其他范式下无法实现的应用成为可能。工业预测性维护展示了 TinyML 通过分布式智能改造传统基础设施的能力。制造设施部署数千个振动传感器，连续运行 5-10 年，仅需$15-50 的成本，相比传统有线传感器每点$500-2,000 的费用，部署成本从$5-20 百万降至$150,000-500,000，局部异常检测则可提前 7-14 天预警设备故障，实现计划外停机时间减少 25-45%。

唤醒词检测是 TinyML 最显著的消费级应用，数十亿设备以<1mW 的功耗实现持续监听。这些系统以 16kHz 音频流处理神经网络，参数量在 5,000-20,000 之间，压缩至 10-50KB，检测唤醒词的准确率超过 95%。亚马逊的 Echo 设备使用消耗<10mW 的专用 TinyML 芯片 AML05 进行检测，仅在唤醒词触发时激活主处理器，平均功耗降低 10-20 倍³⁵。

精准农业利用 TinyML 的经济优势，在传统解决方案成本过高的情况下实现监测。监测 100 公顷土地大约需要 1,000 个监测点，TinyML 使其成本降至$15,000-30,000，而蜂窝连接的替代方案则需$100,000-200,000 以上。这些传感器在电池上可连续工作 3-5 年，同时进行时间模式的本地分析，仅传输可操作的见解，而非原始数据流。

野生动物保护则展示了 TinyML 在偏远环境监测中的变革潜力。研究人员部署太阳能供电的音频传感器，消耗 100-500mW，处理连续音频流以识别物种。通过本地分析，这些系统将卫星传输需求从每天 4.3GB 减少到 400KB，减少了 10,000 倍，使得大规模部署 100-1,000 个传感器成为经济上可行。医疗可穿戴设备实现 FDA 批准的心电监测，灵敏度在 95-98% 之间，每秒处理 250-500 个 ECG 样本，功耗低于 5mW。这一效率使得连续监测时间从传统实验室研究的数小时延长至数周，同时将诊断成本从$2,000-5,000 降至$100 以下。

混合架构：范式结合

对各个独立部署范式的分析——从云端的强大计算能力到 Tiny ML 的超高能效——揭示了工程权衡的谱系，每种范式在特定约束和用例下具有独特的优势和局限性。云端 ML 最大化算法复杂度，但带来了延迟和隐私的约束；边缘 ML 降低了延迟，但对计算资源的要求更为严格；移动 ML 优先考虑用户体验，但受到电池寿命和热管理的限制；Tiny ML 在极端能效下实现普遍智能，但模型复杂度受到严重限制。每种范式在其特定的约束和应用场景中都经过优化。

然而，实际生产系统很少仅限于单一范式，因为每种方法的局限性为互补集成创造了机会。一个同时使用 Tiny ML 进行唤醒词检测、移动 ML 进行本地语音识别、边缘 ML 进行上下文处理和云端 ML 进行复杂自然语言理解的语音助手，展示了更强大的处理能力。混合机器学习正式化了这种集成策略，创建统一的系统，利用每种范式的互补优势，同时减轻各自的局限。

混合 ML 定义

_混合机器学习（Hybrid ML）是指将多种 ML 范式（云端、边缘、移动和 Tiny ML）集成以形成统一的分布式系统。这些系统通过在计算层之间战略性地分配工作负载，利用互补的优势，同时减轻各自的局限，实现_可扩展性、适应性_和_隐私保护，这是单一范式无法实现的。

多层级集成模式

混合 ML 设计模式提供了有效集成范式的可重用架构解决方案。每种模式代表了一种战略性的方法，通过在计算层之间分配 ML 工作负载，针对延迟、隐私、资源效率和可扩展性的特定权衡进行优化。

本分析确定了五种基本模式，解决混合 ML 系统中的常见集成挑战。

训练 - 服务分离

最常见的混合模式之一是训练 - 服务分离，即模型在云端训练，但推理发生在边缘、移动或 Tiny 设备上。这一模式利用云端强大的计算资源进行训练，同时享受设备内推理带来的低延迟和隐私保护³⁶。例如，智能家居设备通常在云端大数据集上训练模型，但在本地运行推理，以确保快速响应和保护用户隐私。实际上，这可能涉及在强大的 NVIDIA DGX A100 等系统上训练模型，利用其 8 个 A100 GPU 和 TB 级内存，然后将优化后的版本部署到边缘设备如 NVIDIA Jetson AGX Orin 上进行高效推理。类似地，移动设备上的计算摄影模型通常在强大的云基础设施上训练，但部署时需在手机硬件上高效运行。

层级处理

层级处理创建了一个多层级系统，数据和智能在 ML 堆栈的不同层级之间流动。这一模式有效结合了云端 ML 系统（如前文讨论的大规模训练基础设施）与多个边缘 ML 系统（如 NVIDIA Jetson 平台）的能力，平衡了中央处理能力与本地响应能力。在工业物联网应用中，微小传感器可能执行基本的异常检测，边缘设备则聚合和分析来自多个传感器的数据，而云系统则处理复杂的分析和模型更新。例如，ESP32-CAM 设备（来自 Tiny ML 示例）可能在传感器级别执行基本的图像分类，将数据传输到 Jetson AGX Orin 设备（来自边缘 ML 案例研究）进行更复杂的计算机视觉任务，最终连接云基础设施进行复杂分析和模型更新。

这种层级结构使得每个层级可以处理适合其能力的任务。Tiny ML 设备处理即时、简单的决策；边缘设备管理本地协调；云系统则处理复杂的分析和学习任务。智能城市的建设通常采用这一模式，街道传感器将数据传输到社区边缘处理器，后者再连接到城市级云分析。

渐进式部署

渐进式部署通过在计算层之间适应模型，创建分层智能架构，系统地压缩模型。一个模型可能最初是云端的大型版本，然后逐步优化为边缘服务器、移动设备，最后是 Tiny 传感器，具体技术详见 第 10 章：模型优化 。

亚马逊 Alexa 就是这一模式的典范：唤醒词检测在 TinyML 设备上使用<1KB 的模型，功耗<1mW，边缘处理则使用 1-10MB 的模型，功耗 1-10W，而复杂的自然语言理解则需要在云基础设施中使用 GB 级别的模型。这种分层方法将云端推理成本降低了 95%，同时保持了用户体验。

然而，渐进式部署带来了操作复杂性：跨层级的模型版本控制、确保各版本间的一致性、管理连接中断期间的故障级联，以及在数百万设备上协调更新。生产团队必须在 TinyML 优化、边缘编排和云端扩展等多个领域保持专业知识。

联邦学习

联邦学习³⁷使得在保持隐私的前提下，从分布式数据中学习成为可能。谷歌的生产系统处理 60 亿个移动键盘，通过本地保留输入文本的方式训练改进模型。每轮训练涉及 100-10,000 个设备贡献模型更新，需要协调设备可用性、网络状况和计算异构性。

生产部署面临着重大挑战：训练轮次中设备掉线率高达 50-90%，网络带宽限制了更新频率，差分隐私机制则防止信息泄露。聚合服务器必须处理间歇性连接、不同设备能力，并确保尽管数据分布非独立同分布（non-IID），仍能实现模型收敛。这需要专门的监控基础设施，以跟踪分布式训练进度并在不访问原始数据的情况下进行故障排除。

协作学习

协作学习使得同层设备之间可以进行点对点学习，通常补充层级结构³⁸。例如，自主驾驶车队可以直接在车辆之间共享道路状况或交通模式的学习，同时与云基础设施通信。这种横向协作使系统能够共享实时信息，并相互学习经验，而无需始终通过中央服务器路由。

生产系统案例研究

真实世界的实施将多种设计模式集成到连贯的解决方案中，而不是孤立地应用它们。生产 ML 系统形成了互联网络，每个范式在特定角色中发挥作用，同时与其他范式通信，遵循利用各自优势和解决局限的集成模式。

图 10 通过特定的连接类型展示了这些关键交互：“部署”路径显示了模型如何从云端训练到各种设备，“数据”和“结果”则显示了从传感器通过处理阶段到云端分析的信息流，“同步”演示了设备间的协调。注意数据通常是从传感器通过处理层向上流动到云端分析，而模型部署则是从云端训练向下流向各个推理点。交互并非严格的层级关系。移动设备可能同时与云服务和 Tiny 传感器直接通信，而边缘系统则可以协助移动设备进行复杂的处理任务。

农业监测展示了层级数据流：土壤传感器执行本地异常检测，将结果传输到边缘处理器，后者汇总来自多个传感器的数据，然后将见解路由到云基础设施进行农场范围的分析，同时向农民的移动应用更新。信息沿着处理层向上流动，每个层级根据其计算资源增加分析复杂性。

健身追踪器则展示了 Tiny ML 与移动设备之间的网关模式：可穿戴设备使用针对微控制器优化的算法持续监测活动，将处理过的数据同步到智能手机，后者结合来自多个来源的指标，然后定期将更新传输到云基础设施进行长期分析。这使得尽管缺乏直接的网络连接，微小设备仍能参与大规模系统。

这些集成模式揭示了部署范式如何通过协调的数据流、模型部署和跨层级协助互为补充。工业系统将云端、边缘、移动和 Tiny ML 的能力组合成分布式架构，优化延迟、隐私、成本和操作要求。范式之间的交互往往比单个组件的能力更能决定系统的成功。

跨部署范式的共享原则

尽管存在差异，所有 ML 部署范式共享核心原则，使系统化理解和有效混合成为可能。图 11 展示了从云到微型设备的多样化实现如何在数据管道管理、资源管理和系统架构等核心挑战上趋同。这种趋同解释了为何技术能够在范式间有效转移，以及混合方法在实践中成功的原因。

最上层展示了贯穿各范式的 ML 系统实现。云端 ML 在数据中心进行大规模训练，边缘 ML 则侧重于本地推理，移动 ML 运行在个人设备上以服务用户，TinyML 则在极为受限的系统上执行。尽管表面上存在差异，这些实现却在底层展现出更深层次的共性。

中间层则识别出团结所有范式的核心系统原则。数据管道管理（ 第 6 章：数据工程 ）负责从数据收集到部署的信息流，无论是在云数据中心处理 PB 级数据，还是在微控制器上处理 KB 级数据，都保持一致的模式。资源管理在各个规模上创造了平衡计算、内存、能源和网络容量等竞争需求的普遍挑战。系统架构原则则指导无论部署环境如何，模型、硬件和软件组件的集成。这些基础原则在各个规模上保持了一致性，即使实现方式相差数个数量级。

最底层则展示了这些原则在实际维度上的具体体现。各个规模的优化和效率策略（ 第 10 章：模型优化 ）形式各异：云端的 GPU 集群训练、边缘的模型压缩、移动的热管理和 TinyML 的数值精度，但都追求在可用资源内最大化性能。运营方面（ 第 13 章：机器学习运维 ）则以各自特有的方式解决部署、监控和更新问题，但面临的挑战在本质上是相似的。对可信 AI（ 第 17 章：可信 AI ， 第 16 章：稳健 AI ）的安全、隐私和可靠性要求是普遍适用的，但实现技术必须适应每个部署环境。

这种三层结构解释了技术为何能够在各个规模间有效转移。云端训练的模型能够成功部署到边缘设备，因为训练和推理在不同约束下优化了相似的目标。移动优化的见解能够为云端效率策略提供参考，因为两者都管理着相同的基本资源权衡。TinyML 的创新推动了跨范式的进步，正因为其极端约束迫使其解决所有规模上普遍存在的核心问题。混合方法（训练 - 服务分离、层级处理、联邦学习）之所以有效，是因为其底层原则在各个范式间是一致的，使得尽管存在巨大的资源差异，集成依然能够无缝进行。

比较分析与选择框架

基于对共享原则的理解，跨部署范式的系统比较揭示了驱动部署决策的精确权衡，并突显了每种范式的优势应用场景，为从业者提供了进行明智架构选择的分析框架。

计算资源与部署位置之间的关系是 ML 系统中最重要的比较之一。随着我们从云端部署转向 Tiny 设备，计算能力、存储和能耗都显著下降。云端 ML 系统凭借其数据中心基础设施，几乎可以利用无限的资源，以 PB 级别的规模处理数据，以十亿级别的参数训练模型。边缘 ML 系统虽然受限，但仍通过边缘 GPU 和神经处理单元等专用硬件提供显著的计算能力。移动 ML 则在智能手机和平板电脑等设备上实现计算能力与能效的平衡。位于谱系最末端的 TinyML，在计算资源极为受限的情况下运行，内存通常仅有千字节级别，功耗则低于 1 毫瓦。

表 2 量化了各范式在性能、操作和部署维度上的差异，清晰地揭示了延迟（云：100-1000ms → 边缘：10-100ms → 移动：5-50ms → Tiny：1-10ms）和隐私保障（TinyML 的完全本地处理提供最强保障）的梯度。

图 12 通过雷达图展示了性能和操作特征。图 a 对比了计算能力和可扩展性（云端 ML 的优势）与延迟和能量效率（TinyML 的优势），边缘和移动 ML 则处于中间位置。

开发复杂性与硬件能力呈反比：云端和 TinyML 需要深入的专业知识（分别是云基础设施和嵌入式系统），而移动和边缘则利用更易获取的 SDK 和工具。成本结构则呈现相反的趋势：云端带来持续的运营开支（每月$1000 以上），边缘需要适度的前期投资（$100 到$1000），移动利用现有设备（$0-10）以最小化基础设施开支，而 TinyML 则通过降低硬件和连接成本（$1-10）来实现最低成本，同时需要更高的开发投资。

理解这些权衡对于选择合适的部署策略至关重要，以使应用需求与范式能力相匹配。

选择部署范式时，一个关键的误区是仅仅根据模型准确性指标进行选择，而忽视了系统层面的约束。团队往往通过比较模型在孤立状态下的准确性来选择部署策略，忽略了决定实际可行性的关键系统需求。例如，一个在云端以 99% 准确率部署的模型，如果网络延迟超过反应时间要求，则无法用于自动驾驶紧急制动。同样，一个耗尽移动设备电池的边缘模型，尽管准确率更高，但也无法满足应用需求。成功的部署需要同时评估多个维度：延迟要求、功率预算、网络可靠性、数据隐私法规和总拥有成本。必须在模型开发之前确立这些约束，以避免在项目后期进行代价高昂的架构调整。

部署选择决策框架

选择合适的部署范式需要对应用约束进行系统评估，而非基于组织偏见或技术趋势。图 13 提供了一个分层决策框架，通过关键需求（隐私、延迟、计算需求和成本约束）逐步筛选选项。通过这一结构化方法，确保部署决策源于应用需求，扎根于前文建立的物理约束和定量比较。

仅仅依靠技术约束不足以做出全面的部署决策。组织因素同样在成功中起着关键作用，因为它们决定了团队是否具备实施和维护所选范式的能力。团队的专业知识必须与范式要求相匹配：云端 ML 需要分布式系统知识，边缘 ML 需要设备管理能力，移动 ML 需要平台特定的优化技能，而 TinyML 则需要嵌入式系统的专业知识。缺乏相应技能的组织，可能面临较长的开发周期和持续的维护挑战，从而削弱技术优势。监控和维护能力同样决定了在大规模下的可行性：边缘部署需要分布式设备编排，而 TinyML 则需要专门的固件管理，许多组织可能缺乏这些能力。成本结构则通过其时间模式进一步复杂化决策：云端带来持续的运营开支，适合不可预测的工作负载；边缘需要适度的前期投资，后续成本较低；移动利用用户提供的设备，最小化基础设施开支；而 TinyML 则通过降低硬件和连接成本，同时需要较高的开发投资，来实现最低的整体成本。

成功的部署是在技术优化与组织能力之间取得平衡的结果。范式选择代表了系统工程的挑战，超越了单纯的技术需求，涵盖了团队技能、运营能力和经济约束。这些决策受到 AI 规模法则中探讨的基本缩放法则的制约，运营方面详见 第 13 章：机器学习运维 ，基准测试方法见 第 12 章：AI 基准测试 。

常见误区与陷阱

理解部署范式需要识别常见的误区，以避免导致糟糕架构决策的错误思维。这些误区往往源于对机器学习系统设计核心权衡的过于简化的认识。

误区：“单一范式适用所有” - 最普遍的误区是认为一种部署方法可以解决所有 ML 问题。团队往往标准化使用云端、边缘或移动解决方案，而不考虑应用特定的约束。这一误区忽视了部署范式基础中讨论的物理约束。实时机器人技术无法忍受云端延迟，而复杂的语言模型则超出了 Tiny 设备的能力。有效的系统往往需要混合架构，战略性地利用多种范式。

误区：“边缘计算总是减少延迟” - 许多从业者认为边缘部署会自动提高响应速度。然而，边缘系统可能引入处理延迟、负载均衡开销和潜在的网络跳数，这些都可能超过直接云连接的延迟。设计不当的边缘部署，可能因本地计算能力不足而表现出比优化后的云服务更差的延迟。边缘的好处只有在本地处理时间加上减少的网络距离超过基础设施复杂性带来的成本时才会显现。

误区：“移动设备可以通过优化处理任何工作负载” - 这一误解低估了电池寿命和热管理带来的基本限制。团队往往认为模型压缩技术可以任意降低资源需求，同时保持性能。然而，移动设备面临硬性物理限制：电池容量随体积缩放，而计算需求则随模型复杂性增加。一些应用需要的计算资源是任何优化都无法在移动电源预算内实现的。

误区：“Tiny ML 只是更小的移动 ML” - 这一误区误解了资源受限范式之间的定性差异。Tiny ML 在极端约束下运行，迫使其采用与移动优化截然不同的算法方法。微控制器环境的内存限制以千字节而非兆字节计量，需要超出移动优化所采用的量化等专用技术。适合 Tiny ML 的应用本质上代表了一类与移动应用截然不同的计算问题。

误区：“成本优化等同于资源最小化” - 团队常常认为最小化计算资源就会自动降低成本。这一观点忽视了运营复杂性、开发时间和基础设施开销。云端部署可能消耗更多的计算资源，但通过降低维护、自动扩展和共享基础设施的成本，提供更低的总拥有成本。最优的成本解决方案往往是在接受更高的单元资源消耗的前提下，换取简化的操作和更快的开发周期。

总结

本章分析了机器学习系统的多样化格局，揭示了部署上下文如何直接影响系统设计的各个方面。从云环境的庞大计算资源，到 Tiny 设备在极端约束下的运行，每种范式都展现了独特的机遇和挑战，直接影响架构决策、算法选择和性能权衡。从云端到边缘，再到移动和 Tiny ML 的谱系，反映了智能在计算基础设施上分布的重大演变。

从集中式云系统到分布式边缘和移动部署的演变，展示了资源约束如何推动创新，而不仅仅是限制能力。每种范式的出现，都是为了应对其前身的特定局限：云端 ML 利用集中式算力处理复杂任务，但必须应对延迟和隐私问题；边缘 ML 将计算移近数据源，降低延迟但引入中间资源约束；移动 ML 将这些能力扩展到个人设备，平衡用户体验与电池寿命；Tiny ML 则在极端能效下实现普遍智能，适用于以前无法接触的部署场景。这一演变展示了深思熟虑的系统设计如何将限制转化为专门优化的机遇。

关键要点

• 部署上下文对架构决策的影响大于算法偏好
• 资源约束带来了创新的机遇，而非单纯的限制
• 混合方法正成为 ML 系统设计的未来
• 隐私和延迟的考量日益倾向于分布式智能这些范式反映了一个持续的转变，即系统被精细调整以满足特定的操作要求，超越了统一方案，朝着上下文感知的系统设计迈进。随着这些部署模型的成熟，混合架构应运而生，结合了它们的优势：云端训练配合边缘推理、移动设备间的联邦学习，以及优化整个谱系的层级处理。这一演变展示了部署上下文将如何继续推动系统架构、训练方法和优化技术的创新，创造出更复杂、更具上下文感知的机器学习系统。

然而，部署上下文只是系统设计的一个维度。运行在这些环境中的算法同样影响着资源需求、计算模式和优化策略。一个需要数 GB 内存和数十亿次浮点运算的神经网络，其部署方式与一个仅需千字节和整数比较的决策树截然不同。下一章（ 第 3 章：深度学习基础 ）将探讨神经网络的数学基础，揭示为何某些部署范式适合特定算法，以及算法选择如何贯穿整个系统栈。