MLOps for edge AI: Managing AI models across distributed fleets

边缘AI的MLOps：管理分布式舰队中的AI模型

组件 | 文章简介

2026年10月20日

20分钟阅读

人工智能，边缘计算

Luis Javier Arizmendi Alonso

高级首席专家解决方案架构师

Subpattern | social_share_set

组件 | 社交分享

分享

Subpattern | 订阅

组件 | 社交图标

订阅RSS

组件 | 图标

© Red Hat, Inc. CC-BY-4.0 授权

Subpattern | 结果导航

组布局

组件 | 导航链接

• 返回所有文章

组件 | 通用

在边缘部署AI既充满回报又充满挑战。在之前的系列文章中，你已经了解了如何优化和打包边缘AI模型，以及如何执行它们以满足边缘常见用例需求，但还有更多内容需要探讨。

在本文中，我们将重点从模型和服务架构转向管理问题，这些问题会影响我们的边缘AI用例，当模型在数千台设备上运行时。我们将回答诸如以下问题：你如何知道哪个版本正在哪里运行？如何在不引发舰队范围事故的情况下进行更新？以及如何管理那些无法通过常规方式连接的设备？

这些问题定义了边缘AI模型管理，它们看起来简单但实际更复杂。在云AI中，模型管理是一个集中式问题。而在边缘，你管理着数千到数十万台地理分布的设备，每台设备都有自己的硬件配置、连接状况、区域业务背景，甚至可能有自己的监管要求。在云中简单的模型更新，在整个边缘舰队中可能变得异常复杂，一次性向所有设备推送不良更新所引发的事故，与云中的事故性质完全不同。

边缘AI舰队管理：了解并控制何处运行什么

AI模型管理的答案始于你管理设备及其运行AI模型的操作系统（OS）所采用的方法。

声明式与命令式管理

管理设备状态有两种基本方法：声明式和命令式。命令式方法会告诉每个设备在特定时刻该做什么。声明式方法则定义期望状态，并让每个设备持续地将其实际状态与该定义进行对齐。对于边缘AI舰队管理，声明式方法更为合适。边缘设备会断线、意外重启，并在中心系统无法完全预见的条件下运行。除了更好的可扩展性，声明式系统天然地处理了这些问题，因为设备在能够连接时会自动向期望状态收敛。GitOps进一步扩展了这一理念，通过版本控制仓库作为单一真相来源。你将更改提交到Git仓库，每个设备上的代理会应用这些更改。这为你提供了完整的审计跟踪、回滚到任何先前状态的能力，以及通过标准拉取请求工作流程实现的清晰变更审批流程。

拉取与推送管理

接下来的问题是，包含AI模型的设备如何将实际状态反馈给控制平面，以及系统如何传递配置更新。在此，存在两种模式：拉取（pull）和推送（push）管理。在基于推送的模型中，中央系统发送更新并记录已发送的内容，而在基于拉取的模型中，边缘设备主动发起请求，中央系统只需响应即可。基于拉取的通信在网络方面具有实际优势，这对边缘场景至关重要。默认情况下，位于网络地址转换（NAT）后方、企业防火墙后方或使用蜂窝连接的设备无法从外部访问。基于推送的管理需要向每个设备建立入站连接，这意味着需要开放防火墙规则或管理虚拟专用网络（VPN）隧道。而基于拉取的通信只需设备具备出站连接，即使在网络限制严格的环境中，这种连接也几乎普遍存在。对于边缘AI部署而言，这通常是决定性因素。

推送管理模式的另一个问题是，当推送失败、设备离线或更新部分完成时，记录的状态与设备实际状态可能会出现偏差。相比之下，在基于拉取的模型中，每台设备会定期报告其实际运行状态。控制平面存储的是接收到的内容，而非发送的内容，这也是基于拉取的管理更适合边缘使用场景的另一个原因。

舰队分段

下一个需求是能够通过比“一次性全部设备”更具体的条件来定位配置、AI模型和系统更新。真实的边缘部署通常需要分段，例如：

• 按硬件类别划分，因为不同硬件运行不同的模型变体
• 按地理位置划分，因为不同国家可能有不同的监管要求
• 按业务部门划分，因为服务于多个团队的共享平台需要租户隔离
• 按运营组划分，因为生产设备和测试设备需要不同的策略

因此，应在设备注册时为其附加元数据，并在整个设备生命周期中维护这些信息。然后可以使用这些标签（如硬件类别、地理位置、业务部门和运营层级）来表达部署策略，例如“将模型版本v2.1部署到所有标记为hardware-class=jetson-orin-agx、region=europe且operational-tier=production的设备”。这是实现定向发布、合规性报告和事件响应的基础。

通过管理API进行集成

另一个需要考虑的因素是将管理平台与其他子系统集成，以释放更大价值并支持更复杂的使用场景。拥有应用程序编程接口（API）是简化这种集成的最佳方式，因为管理API使基础设施可组合。当管理控制台或命令行界面（CLI）中提供的相同功能也可以通过API访问时，可以轻松将舰队管理集成到现有的持续集成和持续交付（CI/CD）管道中，作为更广泛发布流程的一部分触发模型部署，从可观测性平台查询设备状态，并自动化对运营事件的响应。

Red Hat 产品采用的正是这种方案。例如，Red Hat 高级集群管理为 Red Hat OpenShift 和 MicroShift 部署提供了该 API，支持基于标签的集群定位、策略传播、GitOps 支持以及与外部自动化工具集成的管理。Red Hat 边缘管理器则为 Red Hat 企业 Linux（RHEL）/ Red Hat 设备边缘节点提供了类似功能，支持定义设备组（可反映硬件、地理位置或业务属性的任意组合），并通过基于拉取的通信方式在 NAT 和防火墙边界进行跨网络通信，无需对现场设备开放入站访问。

借助这些工具，您可以实现部署一致性：确保正确的模型部署到合适的设备上。这是必要条件，但模型质量才是决定系统是否能创造价值的关键。不仅如此，在《第 1 部分：为部署准备 AI 模型》中，我们描述了模型分发的挑战，但将模型存储并传输到设备上只是问题的一部分。您还需要一个用于跟踪模型版本的存储位置。通常通过模型注册表来处理这个问题。模型注册表是部署前注册、版本化和管理模型的中心位置。它存储每个模型的元数据，例如项目、训练设置、性能指标和部署事件，是模型治理的关键组成部分。

Red Hat OpenShift AI 包含模型注册表功能。在 Edge Manager 的下一个版本中，新的目录收集器将从该注册表中收集选定的模型元数据和工件引用，并将其发布到 Edge Manager 软件目录。这有助于简化边缘环境的模型生命周期管理：当您注册新模型版本时，它会立即显示在目录中，操作人员可以使用他们已熟悉的发布策略将其部署到设备集群。

我们之前提到过，确保正确的模型部署到合适的设备至关重要，但要验证这一点，您需要在设备集群中同时监控基础设施指标和 AI 特定的指标——这正是下一节的内容。

边缘 AI 可观测性：监控 AI 特定质量指标

设备集群的可见性通常涵盖基础设施状态，例如每个设备运行的操作系统版本、容器镜像和模型标签。但对于 AI 工作负载，仅凭基础设施状态是不够的。设备可能报告正在运行模型版本 v2.1，并且从基础设施角度来看完全健康，但该模型可能因本地环境的分布偏移而实际产生退化的推理结果。

在集群规模上监控 AI 质量需要与标准基础设施监控不同的遥测策略。您无法将数千台设备的原始推理输入和输出流式传输到中央平台；这会带来巨大的带宽成本，接收端的存储需求也非常庞大。正确的架构应在设备端收集统计摘要，并仅转发这些摘要（仅在极少数情况下需要转发原始数据）。

这种机制如何运作？哪些数据不属于常规基础设施监控的范畴？

在设备端，推理服务会计算并公开AI特定指标，例如其自身置信度分数的分布（模型对其预测的确定程度）、按类别划分的检测率随时间的变化（每个输出类别被预测的频率）以及推理延迟百分位数。这些指标非常重要。例如，如果在6周内置信度分数分布持续下降，而所有基础设施指标均保持正常，这表明模型在其当前环境中遇到了困难。如果某个历史上经常出现的类别突然检测率为零，这说明环境发生了变化。

这些数据不是原始检测结果，而是包含相关信息的摘要。此时，您可以将这些摘要发送到本地或区域聚合层级，该层级会聚合其站点或区域内所有设备的数据，并在转发到中央平台（核心数据中心或云）之前可能应用过滤器。

如果采用这种分层架构，每个层级的带宽成本将与其聚合的设备数量成比例，而不是与原始推理事件的数量成线性关系。在中央平台，聚合后的指标可驱动全舰队的仪表板和警报，例如跨站点的准确性退化热图、按模型版本划分的漂移趋势图，以及按设备类别分段的置信度分布直方图。这些视图使操作人员能够发现设备层级无法察觉的问题，比较不同地区的模型性能，并优先处理最关键的问题。

OpenTelemetry是该遥测管道的标准协议。每个边缘设备上的OpenTelemetry收集器将指标转发到区域聚合点，然后由该聚合点将其转发到中央的Prometheus和Grafana部署。一旦信息集中化，您就可以从中提取可操作的见解。例如，您可以使用Red Hat TrustyAI（Red Hat OpenShift AI的一部分），在中央平台添加AI特定分析，包括统计漂移测试、偏差检测和模型可解释性。这种组合为运维团队提供了在下游业务指标出现之前，检测舰队级别模型退化的可见性。

可观测性会告诉您何时需要更新模型。将AI模型升级传输到设备则是另一个完全不同的问题。让我们深入探讨它是如何运作的。

边缘AI模型更新：使用受限链路

将模型分发到数千个分布式设备会引入一组新的挑战，尤其是在带宽、延迟和可靠性在不同站点存在差异的情况下。

一种有效的方式是通过分层注册表架构在地理分布的基础设施中分发模型更新。核心的中央注册表、靠近边缘站点集群的区域镜像注册表，以及用于孤立环境的本地注册表构成分层结构。当您在核心发布新模型版本时，它会向外传播到镜像。边缘设备会从最近的可用层级拉取模型，从而提高边缘站点在连接性较差时的拉取可靠性。

基于OpenShift和MicroShift的多层AI模型分发拓扑示例

分发拓扑解决了模型工件的来源问题。下一个挑战是减少设备最初需要传输的数据量，因为边缘网络并非数据中心网络。许多设备通过4G或5G蜂窝链路连接，数据传输存在成本。其他设备则通过最初为业务应用流量设计的共享广域网（WAN）链路连接。这意味着将多吉字节的模型镜像同时分发到数千台设备时，会演变为一个网络规划问题。

对此没有单一答案，这取决于为AI模型选择的封装方式。如《第1部分：为部署准备AI模型》中所述，存在多种分发方法，但在大多数边缘AI部署场景中，基于容器的封装是最优选择。它提供了开放容器倡议（OCI）层去重、基于注册表的版本控制，以及与应用程序容器共享的单一分发基础设施。因此，本文将假设模型以OCI容器镜像形式封装和分发，无论是与运行时嵌入在一起，还是作为专用的ModelCar sidecar容器。

除了选择分发方式外，还需要考虑另一个因素：边缘架构中的带宽通常有限。好消息是，当使用OCI镜像作为AI模型分发方式时，您可以通过多种不同程度的方案来减少升级过程中的带宽使用。

差分升级

基准方案是标准的OCI层去重。当您推送更新后的容器镜像时，设备只会下载变更的层。如果如《第1部分：为部署准备AI模型》中所示，您将AI模型与运行时一起封装在容器镜像中，当更新AI模型时，推理运行时层保持不变，设备只需下载模型权重层。这无需特殊配置，是OCI格式固有的特性。

需要注意的是，这种优势主要适用于单镜像方案，即模型和运行时共享同一个容器镜像。在ModelCar模式中，模型镜像仅包含权重文件。当模型变更时，整个镜像会完全改变，因此没有可复用的层，去重在此场景下没有实际价值。在这种情况下，您需要额外方案，例如zstd:chunked压缩。

除了标准层去重外，zstd:chunked压缩更进一步。客户端可以根据差异块选择性下载层内的单个块（默认4MB），通过HTTP范围请求实现。运行时会复用本地已存在的文件或块，无需重新下载。对于版本间部分权重文件保持不变的模型镜像，这甚至可以在单个层内减少传输量。这意味着ModelCar镜像（仅包含单个权重文件且无法从层去重获益）在使用zstd:chunked进行增量更新时，仍能通过设备仅下载变更的字节范围实现实际传输量减少，其余部分可从本地存储复用。

如果你不想使用 zstd:chunked，仍然有其他方法可以减少带宽使用。你可以使用二进制差分技术，通过计算两个版本的层之间的二进制差异并仅传输差异部分，这种方式类似于 OSTree 在更新时的实现。它的工作原理是怎样的？tar-diff 库结合 bsdiff 和 zstd，能够从预先生成的补丁文件中逐字节重建更新后的层，这些补丁文件的大小比完整容器层小几个数量级。

每种方法都涉及不同的权衡。标准层去重无需配置，可与任何 OCI 兼容的注册表和运行时配合使用，但只有在镜像的某部分未发生变化时才有效。zstd:chunked 方法更进一步，即使在单个层内部也能生效，但需要注册表和边缘设备上的容器运行时都支持该方法，且节省效果取决于版本间二进制内容变化的程度。

此外，zstd:chunked 带来的节省效果需要容器镜像注册表的支持；在断开连接的传输场景中（例如必须通过 USB 驱动器使用更新文件），这些优势将不适用。最后，使用 tar-diff 实现的二进制差分方法在三种方法中能产生最小的数据传输量，因为它可以精确计算两个版本之间的差异，而与层结构无关。然而目前还没有 OCI 标准定义差分分发，因此交付机制需要在标准注册表和 OCI 客户端之外添加额外的工具支持。

Red Hat 已经提供了将这些方法投入实践所需的所有基础组件，并正在积极弥补现有缺失的部分。对于分层注册表架构，Red Hat Quay 提供了两种互补的分发机制。地理复制允许单个 Quay 部署将镜像数据存储在多个互联区域中。当你推送镜像时，数据会存储在最近的存储后端，并在后台复制到其他节点。最近的可用存储始终用于拉取操作，使分发对客户端完全透明。这种方法在核心到区域层级（站点保持可靠连接）中表现良好。

对于连接不稳定或按计划连接的站点，仓库镜像使用独立的 Quay 部署，按照可配置的时间表从上游注册表拉取内容。每个镜像仓库可以独立运行，即使与源断开连接时也能继续提供拉取服务。这种方法适用于区域到边缘层级（无法保证连接）。Red Hat Quay 支持存储和提供 zstd:chunked 压缩的镜像，因此本文中提到的部分层下载和本地块重用功能开箱即用。兼容的运行时（Podman、CRI-O）会自动处理块级去重，无需额外构建或维护注册表。

在二进制差分方面，Red Hat 正在开发 oci-delta 工具，旨在大幅简化 tar-diff 工作流的实际使用。该工具预计将在 RHEL 10.3 和 9.9 中作为技术预览版发布。Edge Manager 已集成该工具，用于提供 bootc 镜像差分更新。目前，要实现二进制差分更新需要手动组合 tar-diff 和自定义脚本来生成、存储并应用补丁。oci-delta 的目标是将这些功能整合为单一受支持工具，降低团队使用最小传输量需求时构建和维护自定义工具的门槛。

注意本节仅关注容器镜像的差异，但边缘AI还需要考虑其他类型的差异。与其将容器镜像作为变更单位，不如将模型更新构建为前一模型的差异。核心思想是仅传输发生变更的模型权重（例如以.ptd文件形式），然后将其应用到设备上已有的模型中。这种方法在新版本仅重新训练模型部分模块，或对大型基础模型进行微调且仅有少量权重变更时效果显著。其优势与之前提到的类似：传输数据量大幅减少，更新能更快到达设备，设备在连接缓慢或间断的情况下可节省带宽。这种方法也与前述方案兼容，因为运行时环境和基础模型保持不变，仅需将微小的权重差异传输到边缘设备。

这种采用差异和压缩技术的分级注册表架构可以处理连接缓慢或间断的设备，但针对完全无法连接任何注册表的设备需要采用不同方案。

边缘AI模型更新：断开连接与物理隔离环境

我们已看到模型打包方式如何决定在连接环境下的更新单元和传输机制；这一原则同样适用于断开连接的架构。

让我们从以文件形式分发模型开始。当直接以文件形式分发模型时，更新单元是模型文件本身及其伴随的元数据或配置信息。在断开连接的环境中，传输机制通常是人工复制。这意味着需要将新文件存储在物理介质上，携带到现场，并复制到推理服务读取的目录中。这种方法适用于单个设备，但难以扩展。缺乏内置版本管理、无法实现版本间的原子切换，也没有标准方式验证本地文件与预期部署内容是否一致。这些缺口通常需要通过自定义脚本解决，随着设备规模扩大会增加维护负担。

在本文系列中，我们一直使用基于容器镜像的模型分发方式。在这种情况下，无论模型是嵌入在推理容器中还是作为ModelCar边车组件，模型更新都等同于常规的容器镜像更新（bootc OS镜像除外，此时模型更新需要完整的操作系统镜像更新）。两种情况的传输机制相同（通过物理介质传输OCI档案），但传输粒度存在差异。

对于需要部署到完全隔离站点的基于容器镜像的模型更新，流程包括：将更新后的模型镜像导出为可移植的OCI档案，通过物理介质（通常在计划维护期间使用USB驱动器或外部硬盘）传输该档案，然后将其导入设备本地的容器存储库。一旦存入本地存储库，模型将像从实时注册表拉取一样被容器运行时访问。

对于嵌入模型的bootc OS镜像更新，完整的操作系统镜像同样采用OCI档案机制。设备通过从本地档案执行bootc升级并重启到新版本来应用更新。

在上述两种情况下，所有工件均保留使用 cosign 进行签名，设备会根据工件的来源方式在本地验证签名。通过 USB 驱动器传输的更新必须通过与从实时仓库拉取的更新相同的签名验证。这对于物理隔离的部署环境尤其重要，因为在这些环境中，物理传输通道位于正常监控范围之外。

我们讨论的是单个设备的升级，但在设备数量较多且偶尔断开连接的站点中情况又如何呢？在这种情况下，如果设备数量足够且站点空间和物流条件允许，部署本地 OCI 镜像仓库镜像作为中间层是一个非常有效的解决方案。该镜像可以在断开连接时手动同步，或在连接窗口期间自动同步，不仅适用于 AI 模型，也适用于任何容器化应用和 bootc 镜像。当连接到区域仓库时，镜像会从区域仓库拉取数据，并在任何时间（包括断开连接时）从本地存储为所有本地设备提供服务。

您可以根据站点支持的情况，使用上述基于文件的方法或本地仓库镜像方法来更新 RHEL、Red Hat Device Edge 和 OpenShift。

当边缘站点托管大量设备时，添加管理层（如 Edge Manager）来整体管理边缘站点舰队也变得有意义，因为 Red Hat 的管理工具也支持在断开连接的环境中进行部署。

上述方法建立了一个高效可靠的交付管道。但如果操作系统或 AI 模型更新出现问题时又会怎样呢？

部署失败时：回滚失败的更新

即使采用分阶段部署，部署偶尔也会失败。在边缘环境中，如果没有自动回滚功能，平均恢复时间（MTTR）可能会变得很长，因为设备位于远程位置，系统可能无法立即检测到故障。在推送了错误更新后，手动回滚大量设备将构成重大运营事件。自动回滚必须在设备级别触发，当设备本身检测到异常时立即执行。

存在两种不同的回滚机制，它们针对不同的故障模式。第一种是 AI 模型回滚。

AI 模型回滚

对于不使用 Kubernetes 的基于容器的部署，Podman 也有自己的实现方式。当更新后容器无法正常启动时，Podman 自动更新功能可以自动回滚，恢复到之前的镜像并重新启动容器。默认情况下，此检查确认容器启动并保持运行，但也可以与自定义健康检查命令配合使用，使更新是否成功的判断标准变为推理合理性检查，而不是简单的端口检查。需要注意的是，这种方法在容器级别生效。对于直接嵌入推理镜像中的模型，健康检查命令针对该单个容器执行。相比之下，在 ModelCar 风格的部署中，模型本身是一个边车容器，负责将文件复制到共享卷。真正重要的健康检查不是在 ModelCar 容器上，而是在读取模型的 serving 容器上，因为该组件负责执行推理并能够检测到问题。

操作系统回滚

第二种机制是通过 bootc rollback 实现的操作系统级别原子回滚，它会回滚整个操作系统镜像，包括内核、驱动程序、运行时环境以及嵌入在操作系统镜像中的任何模型构件。当操作系统或驱动程序更新导致比模型本身更低层级的组件出现问题时，这种机制是合适的响应方式。如果更新后的健康检查失败，Greenboot 会自动触发此回滚操作。

对于 AI 工作负载，这些健康检查还可以帮助构建自动化回滚系统，而无需依赖人工进行升级后的指标审查。在这种情况下，检查应包括 AI 质量验证和基础设施验证。在 bootc 更新后，Greenboot 会通过将一组已知良好的推理样本输入更新后的模型，并验证输出结果是否在定义的容差范围内与预期结果匹配，从而执行 AI 健康检查。如果更新后的模型未能通过此检查（无论是由于驱动程序更新改变了 TensorRT 行为，新模型变体与目标硬件不兼容，还是模型构件在传输过程中损坏），Greenboot 都可以在无人干预的情况下自动将系统回滚到之前已知良好的状态。

自动化回滚至关重要，但没有人希望陷入需要使用它的境地。下一个问题是，如何从根本上避免依赖回滚。最安全的更新是在其取代现有已正常运行的系统之前，已在真实生产环境中进行过测试。

安全部署：冠军模型、挑战者模型和金丝雀发布

什么是 AI 模型的冠军模型和挑战者模型？当前正在生产环境中运行的模型是冠军模型，它已经在整个设备集群中运行，其行为已被验证。更新的模型候选者是挑战者模型：它已通过离线测试，但目前尚不清楚它在实际设备上的表现如何。

我们想要证明的是，在挑战者模型接管之前，它至少与冠军模型一样优秀。在边缘计算场景中，这种验证无法像云服务那样通过将实时流量分割到两个模型版本之间来实现（例如，传感器和推理服务之间没有负载均衡器）。解决方案是将流量分割到设备层级。

一小部分设备运行挑战者模型，而舰队中其余设备继续运行当前冠军模型。两个组在相同条件下接收相同类型的输入，因此可以直接比较它们的结果。只有当挑战者在关键指标上达到或超越冠军（如置信度评分、每类检测率以及实际目标硬件上的延迟和内存占用）时，才会替换冠军。由于两个组同时向相同的下游系统写入数据，因此需要如《第2部分：在边缘运行AI模型》中所述的模型版本标签。没有该标签时，金丝雀测试结果和生产结果将混合成一个无法区分的聚合数据。

选择运行挑战者的设备组与比较本身同样重要。设备数量过少会导致结果无意义；选择范围过于狭窄（例如全部来自一个站点或一种硬件类型的设备）将无法准确代表整个舰队。理想的设备组应足够大，能在测试窗口内得出明确结论，同时具有足够的多样性，覆盖舰队中不同硬件、位置和环境条件。

在某些情况下，即使运行挑战者的设备组风险也过高？这种场景也有对应的解决方案：蓝绿部署——具体来说是蓝绿影子模式。在这种模式下，挑战者与冠军运行在相同设备上并接收相同输入，但系统不会对挑战者的输出采取任何行动。冠军继续做出所有实际决策，而挑战者的结果被单独记录，并与冠军和可用的真实数据进行对比。由于挑战者的输出从未进入共享下游系统，因此输出不会像之前场景那样混合。但需要注意的是，同时在相同设备上运行两个模型需要能够加载和运行多个模型的推理服务器，因此并发模型执行是蓝绿影子部署的必要条件。

你可以使用自己的工具实现这些模式，但Red Hat也提供了相关产品。例如，Edge Manager支持舰队发布策略，可通过标签定位设备并按顺序分批发布，每批都需达到成功阈值后才能进入下一批。用于按站点、硬件类型或阶段分组设备的相同标签，也可以定义哪些设备优先运行挑战者，因此新模型可以先发送到舰队中定义的特定部分，只有通过验证后才会推广到其余设备。对于OpenShift和MicroShift部署，Red Hat Advanced Cluster Management for Kubernetes通过放置规则实现类似功能，按标签选择集群，并仅将挑战者工作负载部署到匹配的子集，再扩展到整个舰队。

接下来的内容

通过我们看到的交付、回滚和安全发布技术，舰队可以可靠地进行更新，并在出现问题时恢复。但今天正确部署的模型不会永远保持准确。传感器漂移、环境变化以及模型在实际场景中看到的数据变化会随时间推移降低性能，且这种退化往往足够隐蔽，以至于部署流水线本身无法察觉。

在第 4 部分：保持模型随时间准确，我们将探讨如何覆盖模型发布后持续保持其有效性的完整周期。这包括监控已部署模型的准确性下降迹象，从设备舰队中捕获并使用真实世界数据进行重新训练，并将重新训练后的版本再次通过验证和发布流程，形成闭环。

Block | Dynamic pattern deluxe promo

组件 | Band_header

产品试用

Red Hat Device Edge | 产品试用

一个灵活的平台，为跨工作负载和设备的操作提供一致性。

组件 | spacer

组件 | Cta_multi_basic

子模式 | simple_cta

组件 | CTA

立即体验

Deluxe mbox

组件 | Card_header

关于作者

子模式 | speaker

卡片布局

组件 | Image_embed

组件 | Person

Luis Javier Arizmendi Alonso

子模式 | social_links

Luis Arizmendi 是一位热衷于边缘计算、人工智能、MLOps 和物理 AI 交叉领域的技术极客，拥有大规模容器化工作负载和高性能或实时确定性操作基础设施优化的深厚背景。

在 Red Hat，他帮助组织设计可扩展的架构，将人工智能从数据中心延伸至边缘，直至必须在现实世界中感知、决策和行动的系统。

热衷于开源技术，以及人工智能、边缘计算和机器人技术融合到下一代智能自主系统中的趋势。

阅读该作者的更多文章

类似内容推荐

动态模式

博客文章

无需共享延迟的共享 GPU：Red Hat AI 的优先级感知服务

以开源方式构建 AI：Red Hat 与 Linux 基金会的研究洞察

原始播客

代理 AI 能够修补互联网吗？

Red Hat 如何为可扩展 AI 清理 IT 债务

子模式 | card_flex

子模式 | text_basic

继续探索

• 什么是代理 AI？文章

• 预测性 AI 与生成性 AI 对比 文章

• 构建生产就绪 AI/ML 环境的首要考虑因素 电子书

• 以 Ansible 方式实现生成性 AI 视频

• 通过现代应用平台实现创新与转型 电子书

继续探索 mbox

子模式 | simple_text

按频道浏览

探索所有频道

模式 | raw_html

自动化

有关 IT 自动化的最新动态，涵盖技术、团队和环境

人工智能

有关平台的最新动态，使客户能够随时随地运行 AI 工作负载

开放混合云

探索我们如何通过混合云构建更加灵活的未来

安全

有关我们如何在各种环境和技术中降低风险的最新动态

边缘计算

有关简化边缘操作平台的最新动态

基础设施

有关全球领先的企业级 Linux 平台的最新动态

应用程序

深入了解我们解决最复杂应用程序挑战的方案

虚拟化

企业虚拟化的未来，适用于本地或跨云的工作负载