第5章：数据存储、云端使用与人工智能流水线（Data Storage, Cloud Usage and Artificial Intelligence Pipeline）

5.1 服务模型（Service Models）

本章开篇承接前节对云计算五大基本特征的讨论。在简要回顾按需自助服务（on-demand self-service）和可计量的服务（measured service）之后，作者继续列举了云端应满足的另外三条本质特征。第一条是广泛的网络访问（broad network access）：云端能力应当能够通过多种多样的"瘦"或"胖"客户端被访问，平台覆盖范围从智能手机、平板电脑一直延伸到笔记本电脑和工作站。第二条是资源池化（resource pooling）：云提供商的计算资源以池化方式运行，并采用所谓的多租户（multi-tenant）模型同时服务多个客户。虚拟资源的分配是依据消费者需求动态执行的，用户通常并不知晓所分配资源的确切位置（具体哪一台服务器或哪一个机柜）。然而，由于法律法规的限制，大多数提供商仍允许用户在较高的抽象层级上选择资源的归属位置，例如限制在某个国家、某个州或某个数据中心。云提供商能够动态分配的资源种类繁多，包括存储容量、CPU 与 GPU 算力、内存以及网络带宽。第三条是快速弹性（rapid elasticity）：云端具备在用户的虚拟环境中按需快速伸缩资源的能力，这种伸缩甚至可以基于某些触发器自动执行，从而给用户一种"资源无限"的使用体验。

接下来，作者介绍了 NIST 提出的云服务三大服务模型（Service Models），对应软件、平台和基础设施三种不同的云端交付形态。

软件即服务（Software as a Service, SaaS）：SaaS 的核心是"在云端运行特定应用程序"。云服务提供商向用户提供对单一应用的访问，服务器、操作系统、存储等底层基础设施的管理和配置完全由提供商控制，用户对此没有任何影响。典型的例子就是基于网页的电子邮件服务，例如 Gmail。

平台即服务（Platform as a Service, PaaS）：PaaS 在 SaaS 的基础上进一步扩展，向用户提供一整套应用程序、编程语言和开发工具。用户可以将自己开发的或获取的应用程序部署到云端。底层云基础设施仍然由云提供商完全控制，但用户能够决定在环境中部署哪些应用程序。

基础设施即服务（Infrastructure as a Service, IaaS）：IaaS 提供最灵活的服务形态，向用户提供对基础计算资源的访问。在这一模型下，底层云基础设施由云提供商提供，但用户可以自行控制和配置操作系统、存储以及应用程序的部署；用户也可以获得对部分网络组件的有限控制权，例如自行托管防火墙。

5.2 部署模型（Deployment Models）

NIST 所提出的部署模型（Deployment Models）从私有云（Private）出发，依次经过社区云（Community）再到公有云（Public），并允许把私有和公有云技术结合在一起的混合云（Hybrid）方案。

私有云是所有部署模型中最封闭、也通常被认为是最安全的形态。在该模型下，单一组织对多个属于该组织的消费者拥有独占使用权。这里所说的"私有"并不要求必须由该组织自建、自管、自营，也不要求所有硬件都部署在本地（on-premise）；第三方仍可以参与到这些环节中的一个或多个。

社区云则将使用权从一个组织扩展到多个组成同一社区的组织。在大多数情况下，这种社区由具有共同关切的若干机构构成，例如同一个地区或国家的若干家医院。同样，所有权、管理和运营可以与第三方共享，实际硬件也既可以部署在本地，也可以部署在异地。

公有云是一种对一般大众开放的云基础设施。在大多数情况下，公有云物理上部署在云提供商处，可以是单一公司，也可以由若干公司、大学和/或政府机构联合构成。

混合云则把多种云模型组合成一种部署形态。不同环境仍然是独立实体，但能够实现数据和应用程序的共享和交换。

5.3 AI 流水线（AI Pipeline）

由于 AI 流程本身的复杂性以及所涉及的众多步骤，研究者一直致力于开发更加自动化、更加一体化的 AI 流水线（AI pipeline），使其能够支撑从数据采集到模型部署的全过程 [8]。在该流水线的每一具体步骤中，根据具体场景的不同，都存在被自动化的可能，从而尽可能减少人工介入。

作者在开发与部署之间做出了重要区分。开发流水线（development pipeline）由若干步骤组成：数据采集、数据标注或打标签（annotation or labelling）、数据清洗（cleansing）、训练（training）以及验证（validation）。而部署流水线（deployment pipeline）则会把一个或多个已训练好的神经网络纳入其中，以接收（影像）数据并产出最终预测结果，而该结果还需要被整合进（临床）数据库 [8]。

5.4 本地实现（Local Implementation）

在本地部署 AI 时，可以把它嵌入到现有的 PACS 或 EMR 环境中，也可以作为私有云或本地（on-premise）服务运行。

网络（Networking）。本地网络由数据存储系统、处理器和部署系统等部件构成。这些部件彼此依赖——任何一个系统都依赖其他系统对它做出响应；没有这种响应，自身就无法工作。这种相互依赖使得通信成为开发 AI 流水线时一个至关重要的因素。本地网络的最终目标应当是把延迟降到最低，并使不同节点之间的处理保持同步。如果网络中的通信处于次优状态，那么即便配备了昂贵的硬件资源，整个网络也会因利用率不足而变得低效。

作者列举了几种能够在本地实现网络中提升通信效率的技术。第一种高性能计算中常用且有效的技术是降低模型精度（reducing model precision）。在许多情况下，数据和模型参数以双精度浮点数存储，这些都可以转换为单精度甚至更低的精度。由于医学数据本身并不要求双精度浮点数的精度，这种转换不会损害模型性能；此外，去除额外的整数位也有助于节省带宽、减小模型体积并减轻网络负担 [12]。

另一种提升数据交换速度的有效技术是压缩节点间传输的数据（compression of data transferred between different nodes）。在网络带宽有限的（医学）基础设施中，这种压缩尤为重要。一些压缩方法采用无损（lossless）方案，即解压后数据可以被完全恢复，但其节省带宽的能力有限。因此在实践中更常采用有损（lossy）方法。在基于深度学习的 AI 应用中，一种进行压缩的做法是把梯度更新的取值限制为二值（binary values），这种方法能够保证梯度方向正确，同时把每次传输的数据量压缩到 1 bit。另一种做法是忽略那些不重要的、小幅度的梯度更新值，只传递重要的梯度。Tao 等人把这一方法在联邦系统（federated systems）中加以实现，在医学 AI 流水线中具有应用价值 [13]。

一个由多个组件构成的 AI 流水线需要每个组件都积极参与、交换数据并在必要时向其它组件开放访问。然而，大多数 PACS 都无法在这样的"主动"环境中工作。例如，当 IP、主机名或 DICOM 属性发生变化时它们就可能失败，因为这些 PACS 往往被硬编码到某种预定义的、选项有限、灵活性极低的工作场景中 [14]。

GPU 与 CPU（GPU and CPU）。早期 AI 流水线和深度学习部署用 CPU 完成计算，并通过 CPU 集群来实现并行化，从而提升模型效率。然而，当前最先进的深度学习流水线已经普遍改用 GPU。对于许多医学机构而言，采购本地或基于云的 GPU 资源是部署 AI 流水线的一个关键步骤。

要构建一条 AI 流水线，CPU 和 GPU 节点都是必需的，任务在两者之间合理划分以达到最优的成本效率。由于 GPU 追求的是吞吐（performance）而不是延迟（latency），其延迟通常比 CPU 更差。因此，GPU 节点主要用在训练阶段，而 CPU 节点主要用在部署阶段——此时延迟成为关键因素。换言之，在医疗机构中建设大型本地 AI 站点时，GPU 与 CPU 设备的组合是最优选择。

数据管理（Data Management）。面对海量的数据，开发本地 AI 流水线时需要谨慎处理数据的准备、存储、处理和系统间交换。在开发和部署阶段，数据都应该被良好地集成进医院现有的 IT 系统。

在现有的医院影像归档系统上开发深度学习模型需要良好的集成。然而，医院环境中往往并存多个影像数据库（PACS），这种互操作性可能会受到妨碍。在开发阶段，深度学习模型可以直接基于一次性导出的 DICOM 影像数据（data dump）进行训练，从而避免在训练过程中反复访问 PACS。在部署之后，则需要保证本地或云端网络中的所有系统使用相同版本的 PACS，或者通过中间 web 协议把不同的 PACS 连接起来，从而整合来自不同 PACS 的数据。

与临床专家类似，AI 系统也需要多种类型的患者数据才能对医学情境形成完整的认识。例如在放射学中，常常需要补充患者的 EMR 数据；只有把这些相关信息整合进来，AI 模型才能得到正确的训练。这就要求同一医院内部不同科室之间进行数据交换，因此需要为所有相关科室开发协议和数据类型标准，以促进信息交换。

AI 模型（AI Models）。训练好的 AI 模型也应当被存储在医疗 IT 环境中。AI 研究者将来可能需要访问这些已训练模型，用以测试、部署、改进或迁移到新的框架。因此，模型必须能够被医院系统便捷地访问、查询和分析。在更大规模的网络中，模型互操作性（model interoperability）是另一个需要关注的问题：每个系统可能使用各自的深度学习框架，这给开发 AI 流水线带来了负担。目前学界正在研究如何通过标准化的交换格式来促进跨框架的模型互操作。一个被广泛使用的框架是 ONNX [15]，它使得 PyTorch、TensorFlow、Caffe、MXNet 和 CNTK 等多种深度学习框架能够共享模型属性，并在同一网络内协同工作。

在本地部署的 AI 流水线中，AI 模型还存在被各种偏倚影响的风险，包括人口学偏倚（demographic bias，如性别、年龄）和数据偏倚（data bias，如标注、设备、采集），从而限制其泛化能力。可行的解决方案包括使用分布式数据集和迁移学习。当前的深度学习模型往往是为有限类型的数据（例如单一模态或单一标注协议）而设计的，但随着影像技术的快速发展，模型设计需要能够应对数据格式的任何变化。模型必须能够以最小中断的方式处理新的数据格式。因此，在医学应用中应当避免使用静态的 AI 模型，转而设计更加灵活的模型。

5.5 云端实现（Cloud Implementation）

在 AI 流水线的开发阶段，云端可以用来提供算力（cloud-based learning）、数据科学工作空间、众包标注或分布式学习。

数据标注或打标签的过程通常非常耗时，且由于专家型医疗人员稀缺而难以组织。云端实现可以在这种情况下提供在线的标注环境，让全世界的专家对影像数据提供标注 [7]。在这一过程中，至关重要的是建立透明、文档完备的标注流程，并使用统一指南，以保证不同标注者之间的一致性 [1]。

在基于云的学习（cloud-based learning）中，云端被用来训练深度学习网络，利用云所提供的 CPU 或 GPU 算力。深度学习网络的编程和实现都在本地完成，云端的高性能计算（HPC）环境则被用来执行迭代学习过程。

数据科学工作空间（data science workspaces）则提供完整的数据科学环境，使所有开发步骤都可以在云端完成。在这种模式下，完整的编程环境以云端虚拟机的形式提供，同时还可以访问云端的 HPC 设施。

由于迁移到云端，学习阶段的开发不再局限于单一位置，而可以把工作分布到多个位置、乃至多个不同数据库的位置上进行。这种分布式学习或联邦学习（distributed or federated learning）是一个较新的研究方向，能够缓解数据共享和数据隐私方面的限制问题；它将在下一节中更详细地介绍。

在部署阶段，云端带来了若干新的可能性，包括：云端的单一 AI 算法、云端算力、联邦式 AI 部署以及 AI 平台 [16]。

许多 AI 应用由供应商以"云端单一 AI 算法"的形式提供。这意味着影像数据将从 PACS 发送到云端的 DICOM 接收器，或通过 web 上传接口上传；数据处理完成之后，报告或生成的其它输出（例如分割文件、处理过的影像数据等）将被返回到数据源。根据 Mehrizi 等人在 2020 年的一份报告，市场上的 269 个 AI 应用中，32% 仅以云端方式提供，46% 既支持云端部署也支持本地部署 [17]。除商业实现外，科研机构也在提供这类云端 AI 应用。RECOMIA 平台就是这样一个基于研究的 AI 应用提供方的例子，其目标是扩展并使其作为面向其他研究组开发的 AI 应用的研究市场 [7]。在部署阶段，当本地不具备所需的 HPC 设施时，云端算力同样可以被使用。

联邦式 AI 部署有若干种方案。一种方案由早期肺癌影像联盟（Early Lung Imaging Confederation, ELIC）[6] 提出并测试：影像数据按获取位置分布在全球各地，中央数据库则汇总各分布式系统的内容。执行去中心化影像任务的软件工具（无论是 AI 还是其他工具）会被分发到联邦网络中相关节点，并在这些节点上完成自动化的影像分析；所有得到的定量测量结果会被汇总到中央 HUB 上，再对聚合后的数据库作进一步分析。

AI 平台（AI platforms）可以提供集中化环境来管理和运行多个应用，用户可以通过某种在线市场访问这些应用 [16]。在这种基于云的 AI 工具市场中，开发者（须经市场运营方审批）可以把自己的工具分发给大量客户，而不必自建销售和部署团队 [16]。部署只需要在市场环境中完成，从而避免了在医院内部进行复杂而昂贵的连接工作。平台同时也涵盖了工作流和用户交互，使 AI 工具开发者能够专注于核心技术与平台 API 的对接。

对用户而言，这类平台消除了安装多种各自独立完成不同任务的 AI 应用的负担，AI 应用的选型和部署也由此被大幅简化。平台将负责数据传输，确保把正确的数据发送给正确的应用，并保证数据传输安全。使用平台的医院只需在数据连接层面完成一次性的配置和实现即可——当连接到平台时，所有 AI 工具都依赖这同一个数据连接来获取数据。未来的维护和变更也只需针对这一条平台连接（例如当迁移到新 PACS 或改变影像模态时），AI 工具本身的更新和升级则由平台提供方负责。这些 AI 工具可以来自单一供应商，也可以来自包括科研机构在内的多种供应方。平台提供方会基于工具的合规状态和结果质量等预先设定的标准来选择 AI 工具。这类市场已经存在多种；Mehrizi 等人在其技术图谱研究中报告了 2019 年的 10 个此类 AI 应用市场 [17]。

5.6 并行化方法（Parallelization Methods）

训练深度学习模型需要为上百万的参数寻找最优取值，过程非常耗时。在某些情况下，有必要把计算分布到并行机器上，以缩短训练时间并提升网络效率。除此之外，隐私考虑和数据治理挑战也常常存在。在这些场景下，分布式/联邦深度学习（distributed/federated deep learning）允许研究者在不直接访问其他机构数据的前提下开发 AI 流水线。

在数据并行（data parallelization）中，每个 worker（例如一台 GPU 机器）都获得相同的 DL 模型副本和一部分数据。为了避免任务重复，数据应被切分为互不重叠的批次（Fig. 5.3）。每个 worker 完成自己的处理之后，所有 worker 的 DL 参数会被更新，因此 worker 之间需要严格的同步。

在模型并行（model parallelism）中，多个处理器被并行化以执行一个深度神经网络某一部分的操作（Fig. 5.4）。例如，一个神经网络可以被划分为多个区段，每段由一个处理器负责，处理器之间在正向和反向传播中相互交换信息。模型并行的关键问题在于：如何把网络切分为多个区段以使各处理器能够正确协同工作。

流水线并行（pipeline parallelism）是模型并行和数据并行的结合，兼具两者的优点（Fig. 5.5）。在流水线并行中，数据被划分为互不重叠的 mini-batch，神经网络被切分为若干区段，每个区段由一个处理器负责。在反向传播中，某个 mini-batch 的梯度通过网络层进行传播，梯度处理在与各层关联的 GPU 上完成。

对于由众多层和复杂结构组成的更复杂的网络，把网络或数据切分到不同部分可能既不可行也不合理。因此，大型分布式深度学习项目在处理复杂网络时通常会采用混合并行（hybrid parallelism）——即模型并行、数据并行和流水线并行的组合。

5.7 同步（Synchronization）

在分布式深度学习中，最重要的问题之一是何时在 worker 之间同步参数。同步策略（synchronization strategies）在网络速度与性能之间形成了一个具有挑战性的折中。

在同步训练（synchronous training）中，worker 在各自完成一个批次（即一次迭代）之后共享各自的更新。这种方法在分布式深度学习平台中应用广泛，相比其它同步范式具有更好的收敛性。然而同步训练存在 straggler 问题：网络速度由最慢的 worker 决定，其他 worker 都必须等待最慢者完成。

在有界同步训练（bounded synchronous training）中，worker 在陈旧的（stale）参数上训练；由有界同步训练得到的参数是对同步训练所得参数的一个近似。然而，为了防止这种近似损害模型精度和收敛性，staleness 必须是有界的。这种做法让模型获得更大的自由度、效率更高，同时又避免了 straggler 问题 [19]。

另一种更新模型的方式是让参数独立或异步（asynchronous）更新：只要有一个 worker 完成一个批次并把梯度发送到网络，模型就立即更新，而不考虑其它 worker。这种方式可能导致收敛性问题，但模型会更加灵活，训练过程也会更快。

5.8 系统架构（System Architectures）

当 worker 数量庞大时，分布式深度学习架构设计中的另一个重大挑战是如何在不同 worker 之间同步参数。大量相互连接的 worker 彼此交换大量信息，每个处理器的性能都依赖于它从其它处理器接收到的参数。如果系统架构设计不当，单个 worker 的失败就会导致整个系统中断。本节将讨论不同的系统架构。

集中式架构（Centralized architectures）是指每个节点或 worker 都把自己的参数上报到一个（或一组）中央节点，即参数服务器（parameter server, PS）。一种做法是把模型参数切分为若干块，把每块参数发送到对应的 PS，从而让模型处理器和 PS 都能并行工作。著名的使用 PS 架构的系统包括 GeePS [20]、DistBelief [21] 和 TensorFlow [22]。

在去中心化网络（decentralized networks）中，处理器之间直接通信（在没有 PS 的全连接网络中）或通过其它处理器间接通信。在一个每个 worker 都与其他所有 worker 相连的全连接网络中，通信是一个主要关注点。但也存在其它拓扑结构，例如 Uber 广泛使用的 Horovod [23] 框架所实现的环形拓扑。相对于全连接拓扑，所有其它拓扑的主要缺点是：节点间的通信可能需要其它节点的参与，处理时间会显著增加。

去中心化拓扑比集中式拓扑更易于部署——不需要设置 PS，也省去了 PS 规划中的种种复杂性。另一个优势是：去中心化拓扑对失败更具鲁棒性，因为网络的存在并不依赖于某个中央枢纽。在去中心化网络中，其它 worker 可以轻松接管失败 worker 的工作，网络可以在不中断的情况下继续运行。去中心化架构也有缺点：在去中心化网络中通信仍是一个主要问题；将拓扑由全连接改为其它结构也会引入额外的复杂性和权衡。

无论是集中式还是去中心式拓扑，都假设数据对所有 worker 可见，模型参数则由中央服务器或各个节点控制。然而，在某些场景下（特别是在医学领域），数据和模型参数对其他 worker 或 PS 可能是不可见的。在这些情况下，就要使用联邦学习拓扑（federated learning topology）。在联邦学习中，数据保存在每个 worker 所在的本地，每台服务器基于自身数据共同训练一个全局网络。每个 worker 基于自己的数据集把更新后的模型参数上报给整个网络。这种拓扑对于带宽有限的网络也很有利——联邦学习并不在网络中交换庞大的训练数据，只传播参数。

联邦学习的常见拓扑包括聚合服务器法（aggregation server method）、点对点法（peer-to-peer method）和序列法（sequential methods）。

在聚合服务器法中，服务器在不同的 worker 之间初始化模型，每个 worker 计算自己的梯度并将其发送回中央服务器。所有 worker 都完成自己的梯度计算后，模型由聚合服务器进行聚合和更新，并把新模型发回给各 worker 继续训练下一轮迭代。

点对点拓扑则避免使用一个服务器来保存整个模型。模型由一个节点进行初始化，每个 worker 基于自身的数据开始训练。每个节点完成自己的梯度计算后，把计算出的参数上报给所有其它节点。在所有 worker 各自上报更新之后，模型被更新。

序列法中，模型先在一个机构的数据上训练，再被适配到具有不同扫描仪和协议的新机构。序列法有两种主要形式：领域适应（domain adaptation）和终身学习（lifelong learning）。在领域适应中，模型在数据丰富的源域上训练，然后再在目标域的新样本上重新训练（fine-tune）以学习新分布。由于领域适应的目标是在新域上最大化性能，模型在源域上的性能可能无法被保持。终身学习是序列法的另一种变体，专门用来解决这一问题。在终身学习中，预训练模型先看到新域的少量样本，在学习新分布的同时保持模型在原数据上的能力；一种实现方式是学习不同域的批量归一化（batch normalization）参数，并共享卷积滤波器 [24]。

5.9 讨论（Discussion）

虽然云端方案在医疗数据交换方面前景广阔，但仍必须面对来自医院 IT 主管层面对该技术的担忧和不安。在性能层面，这种担忧聚焦于：因带宽有限而导致的影像延迟、影像访问的延迟以及云服务中断带来的宕机。而在安全层面，分布式拒绝服务（DDoS）或黑客攻击等安全风险以及机密数据泄露则是主要顾虑。

2019 年 11 月的 Health IT Security 报告显示，云端医学影像环境中的安全问题仍然突出：当时约有 11.9 亿张影像可以通过大量连接到云端的 PACS 被未授权用户轻松访问 [25]。

云端最突出的安全问题包括：安全传输（例如数据加密）、隐私、（影像）数据的机密性以及完整性。云端的设计和实现应当把这四个方面纳入审慎的考虑。

除安全之外，云端实现还应通过提供备份或冗余存储来避免数据丢失，提供高可用性、低宕机时间，并通过基于角色的访问控制以及详尽的用户活动追踪和审计日志来提供受控和可追溯的访问。

基于大规模数据集训练的深度学习模型能够带来更好的临床性能和泛化能力，并作出偏倚更小的决策。联邦学习有助于在远程地区获得高质量的诊断和治疗，并能够利用其他机构的数据。这一优势在面对罕见病时尤为显著。此外，医院保留对自身数据的控制权，减轻了对第三方数据泄露或数据滥用的担忧；不过仍有一些顾虑，例如"能从参数服务器的更新中推断出什么"这样的问题。对研究者而言，联邦学习使其能够基于来自多个机构的多样化数据进行模型训练。这一点尤其重要，因为即便是最强的 DL 模型，在数据不足时也会失败。

然而，数据的异质性也可能带来重大影响。例如，若一个 FL 框架在多个机构上训练，它会向一个对所有参与方而言的最优点收敛。但这个全局最优点对每个机构而言未必是最优的，因为每个机构有自己特定的患者群体并对该群体存在一定的偏倚。

联邦学习训练虽然提供了一定程度的隐私，但它并不能保证模型的完全安全。即便不直接共享训练数据，FL 模型仍然存在信息泄露的风险。例如，模型反演（model inversion）、梯度泄露（gradient leakage）和对抗攻击（adversarial attacks）等技术都可能从模型中抽取机密数据。若攻击者能够追踪单家机构的梯度更新，那么该机构的数据就有可能被窃取。一些防护技术虽然可以使用，但它们都会给模型引入额外的复杂性并造成权衡。因此，在设计联邦学习范式时，应始终考虑所需的安全等级和性能水平，并基于对其他机构的信任程度、法律限制等设计一个最优的折中。

在联邦网络中，高水平的安全、可复现性（reproducibility）和可追溯性（traceability）至关重要。在集中式和本地 DL 模型中，所有数据和系统都由主系统控制，这意味着模型历史、硬件配置和超参数都是可访问的；因此错误可以被轻松调试和追踪。然而，在大规模联邦设置下，上述属性中的一部分无法被追踪——每个机构都有自己的设置、软件、网络和基础设施。一种确保模型可追溯性和完整性的方案是强制所有参与方声明其超参数和训练设置。

最后，在联邦拓扑中，安全的数据传输是必需的。在最严格的情况下，可能需要引入一个额外的"可信中介（trusted broker）"节点来在节点之间传输数据。这一节点会为系统增加额外开销，在某些情况下并不理想。传输数据的加密也至关重要——安全的数据传输可以防止第三方访问网络参数。

基于影像生物样本库和云端方案的数据共享实现仍必须应对技术、法律和社会层面的挑战。要克服这些挑战，需要满足若干条件。其一是通信、数据格式和词典/术语的标准化，这是实现高互操作性环境的基础。云端方案之间的数据交换和 API 标准化仍然有限 [9]。在医学影像中，DICOM 和 HL7 等通用数据标准，结合 IHE 所提供的工作流定义，可以在这一方向上提供帮助。

5.10 结论（Conclusion）

AI 解决方案是解决医疗领域许多现存问题的重要一步，它为医疗专家提供了强有力的工具。分布式 AI 解决方案，尤其是联邦学习，具备提供准确、安全、保护隐私且无偏倚的临床模型的能力。然而，在设计分布式 AI 流水线时需要考虑诸多因素：准确的训练需要合适的基础设施、数据准备和 AI 模型设计；如何执行并行化以及如何在 worker 之间实现高效且安全的通信，则是需要回应的另一个挑战。

我们需要支持机构内部、机构之间以及医患之间的共享。为实现这一目标，云端在促进更好的模型、流畅的影像和信息交换方面扮演着重要角色。基于云的医学影像共享和多中心数据库具有诸多优势：通过规模经济可降低成本，并通过提升性能获益；此外，通过在线的患者健康记录，患者与医生之间、医生与医生之间的数据访问和共享也变得更加容易。云端还提供了更大的、更灵活的存储容量。在云端实现 PACS 独立的存储意味着当迁移到另一个 PACS 供应商时，不再需要繁琐的数据迁移项目。最后，将医学影像信息整合并存储到云端的单一集中化存储库中，取代在多个不同站点使用多个 PACS，意味着医疗提供者可以跨不同科室和组织快速访问和共享影像，从而营造一个更加以患者为中心的环境。

本章个人批注

本章把"AI 流水线"这一抽象概念拆成了三层：云端基础设施层（服务模型、部署模型）→ 流水线本身的开发/部署阶段切分（开发流水线 vs 部署流水线）→ 并行化和同步机制（数据/模型/流水线并行、同步/有界同步/异步、集中式/去中心式/联邦式）。这三层构成了从硬件资源到模型训练、再到分布式协作的完整视图。

读完之后给我印象最深的是几个"看似简单、实则关键"的工程权衡：

第一，PACS 的"硬编码"问题。作者提到大多数 PACS 在 IP、主机名、DICOM 属性变更时容易失败，因为它们是按"预设场景"硬编码的。这其实揭露了一个医学影像 IT 的深层结构性问题——PACS 是为存档和分发设计的，而不是为"被 AI 流水线主动调用"设计的。所以本地部署 AI 几乎一定要绕开 PACS 的"主动 API 限制"，在开发阶段用一次性 DICOM dump，在部署阶段要么统一 PACS 版本，要么用中间 web 协议桥接。这给我做研究时一个直接的提示：当 AI 模型要"嵌入"医院 IT 时，最大的阻力往往不是 GPU 算力，而是 PACS 的"被动性"。

第二，GPU 与 CPU 的分工。作者明确说"GPU 最大化吞吐，CPU 优化延迟"——这一句对于做边缘部署或在临床端做实时推理的同学来说尤其关键。GPU 在训练阶段是无可争议的主力，但在部署阶段（特别是当推理延迟成为关键时），CPU 反而更合适。这个区分我以前在文档里模糊看到过，但本章讲得很清楚，是 GPU/CPU 混合架构设计的直接依据。

第三，联邦学习中的"全局最优 ≠ 机构最优"。这一句我读完愣了一会儿。FL 训练的目标是聚合出一个对所有参与方都"还过得去"的模型；但因为每个机构有自己特定的患者群体，全局最优点对单个机构来说可能反而不是最优的。这意味着联邦学习在提升"普遍性"的同时，可能降低每个机构本可以获得的"针对性"——这与多中心训练常被宣传的"提升泛化"在直觉上是一致的，但代价是个体精度可能下降。这一权衡在医疗 AI 的实际部署中具有深远的伦理和方法学含义：什么样的"公平"是值得追求的？

第四，压缩 / 降低精度对医学数据的可行性。作者说"医学数据不需要双精度"——这一点对训练成本控制的意义很大。在我的研究里，每次面对大规模 CT/MR 数据时，存储和带宽都很快成为瓶颈；本章给出的"梯度二值化、忽略小梯度更新"等压缩技术，对我将来做大规模多中心训练是非常实用的工具。

第五，ONNX 作为"框架互操作"的标准化路径。这一点其实呼应了第 2 章和第 3 章中"模型可复现、可迁移"的要求——模型不只是训练出来就行，还必须能被未来的研究者和医院系统访问、查询、迁移。ONNX 显然是目前最现实的跨框架互操作格式。

最后，Discussion 里那段"安全与可追溯"的论述，是这一章里对"工程 vs 法律/治理"交叉问题最直接的展开：联邦学习虽然避免了数据共享，但留下了"参数服务器更新"这个新的攻击面（梯度泄露、模型反演），并引入了"可信中介"这样的额外治理角色。这一节的现实意义在于：当我把一个"在云端训练好的模型"作为产品交付时，必须考虑它是否会反向泄露训练数据的某些信息——尤其在医学影像这种数据本身高度敏感、且可被重建（reconstruction）出视觉上可识别信息的场景里。

与上下章的衔接（一段话）

本章紧接第 4 章"数据准备"的最后一节"结论"——后者已经把"数据可用性是 ML/DL 模型开发与临床落地的最大瓶颈"明确定位出来，并把读者引向"存储与流水线实现"这一 IT 基础设施层。本章正是在这一接口上展开，把上一章准备好的数据放进一个可运行、可扩展、可共享的工程体系中。具体而言，本章先回顾云计算的五大本质特征和三大服务模型（SaaS/PaaS/IaaS）、四种部署模型（Private/Community/Public/Hybrid），再把"AI 流水线"切分为"开发流水线（采集/标注/清洗/训练/验证）"和"部署流水线（接收数据/产出预测/集成临床数据库）"两个独立视角；进而分别在"本地实现"（网络、GPU/CPU、数据管理、模型互操作）和"云端实现"（云端学习、数据科学工作空间、众包标注、联邦/分布式）两侧展开对比；最后深入到分布式/联邦学习的并行化方法、数据/模型/流水线并行、同步策略（同步/有界同步/异步）和系统架构（集中式/去中心式/联邦式及其子形态：聚合服务器、点对点、序列法）。这种从"基础设施→流水线→分布式算法"的递进，正好是上一章"数据是什么、怎么准备"的自然下游——上一章讲数据本身，本章讲承载数据与模型的 IT 基础设施；上一章用 NLP 抽取结构化标签，本章用联邦学习让分布在不同机构的标签和数据可以共同训练。本章末尾明确点出"数据共享 + 影像生物样本库 + 云端方案"是医疗 AI 大规模落地的下一阶段，从而为下一章（第 6 章"如何构建医学影像 AI 算法"）铺路：第 6 章将进入"算法本身"的工程细节，包括影像任务的分类（分类/定位/分割/重建/后处理）、CNN 的基本组件（卷积层、最大池化层、全连接层、上采样层）以及按任务选择算法架构。换言之，第 3 章讲流程、第 4 章讲数据、第 5 章讲承载数据和模型的 IT 基础设施与分布式算法——三章构成"流程 → 数据 → 基础设施"的三级递进；而第 6 章则将接力"基础设施"这个外部条件，把焦点拉回到算法本身的内部结构上。