MLOps at the edge: Running AI models at the edge

边缘计算中的 MLOps：在边缘运行 AI 模型

组件 | 文章简介

2026 年 10 月 8 日

19 分钟阅读时间

人工智能

,

边缘计算

Luis Javier Arizmendi Alonso

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

Subpattern | social_share_set

组件 | 社交分享

分享

Subpattern | 订阅

组件 | 社交图标

订阅 RSS

组件 | 图标

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

Subpattern | 结果导航

组布局

组件 | 导航链接

• 返回所有文章

组件 | 通用内容

在《第 1 部分：为部署准备 AI 模型》中，我们看到模型如何离开训练流程，作为已签名且优化的开放容器倡议（Open Container Initiative，OCI）制品，准备传输到边缘。现在，我们面临下一个问题：在边缘运行这些 AI 工作负载会带来哪些影响？

在数据中心运行 AI 推理时，可以使用标准化硬件和充足的内存。而在边缘，一个舰队可能跨越多种硬件平台。

在考虑更新策略或如何管理解决方案之前，有一个更基础的问题需要回答：在硬件受限且资源共享的设备上，运行 AI 模型需要满足哪些条件？

本文将围绕平台选择、硬件加速器依赖管理、共享内存和延迟挑战，以及连接传感器与推理、推理与下游系统的消息模式，探讨这一问题。

硬件现实：为什么边缘 AI 部署与云 AI 不同

当在“核心”（云或本地数据中心）运行 AI 时，您使用的是标准化硬件。您可以选择 GPU 实例类型，已知计算统一设备架构（Compute Unified Device Architecture，CUDA）版本，内存以几十 GB 为单位进行衡量。而边缘 AI 舰队则截然相反：本质上是异构的，资源受限的，并且在某些情况下，运行的操作工作负载会与 AI 推理争夺相同的硬件资源。

一个组织的舰队可能包含多种设备，例如基于 aarch64 的 NVIDIA Jetson Orin、带或不带 GPU 的 x86_64 架构的 Intel Atom 工业网关、配备 PCIe 独立 GPU 的 AMD 近边缘服务器，以及集成神经处理单元（Neural Processing Unit，NPU）的单板计算机。每种设备可能需要不同的运行时格式、不同的模型变体以及不同的资源管理策略。

《第 1 部分：为部署准备 AI 模型》通过展示推荐的流水线如何生成开放神经网络交换格式（Open Neural Network Exchange，ONNX）作为中间表示，并在需要时编译为特定硬件格式（如 TensorRT 按 GPU SKU、OpenVINO 用于 Intel、ONNX Runtime 用于异构设备），解决了运行时格式的问题。在本文中，我们将关注另一个与边缘硬件使用相关的重要因素：资源竞争。

边缘 AI 推理过程可能需要与应用程序的通信栈、遥测代理和看门狗服务共享内存和 CPU。而在边缘硬件上，这种资源共享的挑战更为显著，因为无论推理是在 CPU 上运行（所有进程都从同一个内存池中获取资源），还是在集成 GPU 上运行（这是边缘设备中最常见的 GPU 形式），情况都是如此。

NVIDIA Jetson 等平台将 CPU 和 GPU 统一到一个共享内存池中，这意味着操作系统（OS）进程和推理工作负载实际上在争夺相同的内存字节。边缘设备上的资源竞争不会像云环境那样导致响应变慢，但可能在推理过程中导致推理服务崩溃。在某些情况下，这使得资源隔离成为首要的架构设计考量，而不仅仅是优化手段。

此外，由于硬件异构性，维护硬件兼容性矩阵并不容易。一些兼容性问题在初期可能很少出现，但会在生产环境中，随着数百台设备的部署，在最糟糕的时刻突然暴露。Red Hat 通过 Red Hat Device Edge 和 Red Hat OpenShift 的认证硬件计划来解决这一问题。对于舰队中的每种设备类别，都会记录并测试经过验证的 OS 基线、内核、运行时和支持的加速器组合，将硬件管理从被动应对转变为主动预防，降低 AI 推理工作负载特别敏感的集成风险。

既然已经了解了硬件环境，接下来的问题是：在如此复杂的硬件异构性下，应该为每种设备类别选择哪种软件平台？

运行推理服务：选择合适的平台层级

承载推理服务的软件平台决定了可用的操作能力、平台本身消耗的资源开销，以及哪些工具能与管理基础设施集成。可选方案存在一个光谱范围，为每种设备类别选择合适的层级对效率和可操作性都至关重要。Red Hat 深知这一点，因此在这里提供广泛的选择方案，以帮助匹配您的平台和用例需求。

对于资源最受限的设备，当竞争工作负载和操作系统本身仅留下约 1 个核心和 1.5 GB 内存（如果通过网络部署，建议使用 3 GB / 4 GB）供平台操作系统使用时，Red Hat Device Edge 结合 Podman 通过 Quadlets 简化实现，可在无 Kubernetes 开销的情况下提供容器运行时功能。Quadlet 将声明式容器定义文件转换为 systemd 单元文件，使推理服务直接由 systemd 管理：可预测的启动顺序、失败时自动重启、通过 systemd 切片控制（MemoryMax 和 AllowedCPUs）设置资源限制，并与 journald 完全集成用于日志记录。像最小化的 ONNX Runtime 服务器或自定义轻量级推理容器这样的推理服务器可作为一流的 systemd 服务运行。这是对边缘设备最合适的层级，因为每兆字节都至关重要。不过，如果您希望继续使用容器 compose 文件部署应用，使用此平台时也可以实现。

对于至少拥有 2 核 CPU 和 2 GB 内存（如果通过网络部署，建议使用 3 GB / 4 GB）且需要 API 的设备，可以使用带有 MicroShift 的 Red Hat Device Edge，它为设备添加了轻量级 Kubernetes 支持。MicroShift 支持原生 Kubernetes 工作负载清单、健康检查和资源限制。借助 KServe（技术预览版）以原始部署模式（不包含无服务器组件）运行，通过提供标准化的 REST 和 gRPC 推理端点，显著降低了资源开销，从而帮助实现边缘 AI 模型部署。该层级适用于需要基于 Kubernetes 的结构化工作负载管理，但又无法承担完整 Kubernetes 集群资源成本的工业 PC 和推理设备。

对于资源更丰富的近边缘服务器，可以选择运行 OpenShift。OpenShift 为边缘用例提供了多种可能的架构方案。单节点 OpenShift（SNO）部署需要约 4 核 CPU 和 16 GB 内存。作为补充说明，这些资源是 SNO 的基础基础设施；如果您的用例需要在 SNO 上运行 Red Hat OpenShift AI（而不仅仅是推理），则基础设施至少需要 32 个 CPU 和 128 GB 内存，然后还需要为应用程序添加额外资源。

一个紧凑的 3 节点集群每个节点也需要 4 核 CPU 和 16 GB 内存，但可以提供完整的高可用性。

对于需要高可用性但无法负担 3 个完整节点的场景，OpenShift 4.20 引入了两种紧凑拓扑结构：带仲裁节点的双节点架构（Two-Node with Arbiter），通过添加一个轻量级的第三节点（其唯一职责是维护 etcd 集群仲裁）；以及带 fencing 的双节点架构（Two-Node with Fencing），通过基于基板管理控制器（BMC）的 fencing（由 Pacemaker 实现）仅使用 2 个节点即可实现相同效果，通过隔离故障节点防止脑裂。在这些情况下，控制节点至少需要 2 核 CPU 和 16 GB 内存，而仲裁节点（如有）仅需 1 核 CPU 和 8 GB 内存。

下方是官方文档中列出的每种 OpenShift 架构的最低资源需求摘要。请注意，当启用超线程时，每个 CPU 核心相当于 2 个虚拟中央处理单元（vCPUs），这通常是默认设置（除非用例要求运行确定性工作负载）。

每种 OpenShift 边缘架构的最低要求

最后，对于即使这些基准资源需求也过高的部署场景，OpenShift 的可组合架构允许集群管理员在安装时禁用可选组件（如控制台、裸金属操作符或存储操作符），进一步减少资源占用，使其与设备提供的资源相匹配。

虽然我们已将部分平台选项映射到硬件资源层级，但选择 Red Hat Device Edge 或 OpenShift 的决策涉及的变量远不止内存和 CPU 的余量。您还需要考虑运维模式、更新策略、连接性假设以及所需的 Kubernetes 兼容程度——所有这些因素都会产生影响。如果您对如何做出这一决策感兴趣，一篇之前的系列文章提供了涵盖这些维度的专用决策框架。

为每类设备选择合适的平台是必要的，但还不够。一旦确定平台，下一个挑战是验证这些设备提供的硬件加速功能是否能在该平台上可靠运行。

硬件加速：管理依赖链

大多数边缘AI部署依赖硬件加速。NVIDIA设备使用CUDA和TensorRT。Intel处理器使用OpenVINO和oneAPI工具包。AMD系统使用Radeon Open Compute（ROCm）。其他专用边缘AI加速器则自带各自的软件开发工具包（SDK）。这些技术栈在独立运行时表现良好，但AI工作负载特有的挑战在于，硬件、内核驱动、用户空间工具包和推理框架之间的依赖链存在脆弱性，可能引发静默故障。

这种脆弱性体现在多个层级。例如在应用层，当TensorRT、CUDA、驱动或GPU配置发生变化时，可能需要重新构建TensorRT引擎。在系统层，操作系统或内核更新可能使GPU驱动模块失效，导致加速器完全无法用于推理任务。这意味着，例如原本旨在修复常见漏洞和暴露（CVE）的OS更新，可能在模型下次加载时静默地破坏推理功能。另一个例子是，在NVIDIA Jetson平台上，通过容器访问集成的Tegra GPU依赖于平台特定的设备发现和容器运行时配置。当主机加速器配置和驱动发生变化时，可能需要生成或刷新CDI（Container Device Interface）规范，而设备暴露流程中的任何失败都可能导致推理容器即使驱动本身正常工作也无法访问GPU。

应对这些挑战需要两个层级的控制措施。在设备层级，必须固定整个软件栈，包括内核版本和驱动模块。在集群层级，需要部署流水线验证加速器可用性，并在每次更新后运行轻量级推理烟雾测试，以在错误扩散到整个集群前及时发现。

Red Hat在两个层级都提供了解决方案。在设备层级，Red Hat Device Edge和Red Hat Enterprise Linux（RHEL）均可使用bootc将操作系统作为不可变的、版本化的镜像进行管理，将内核、驱动模块和用户空间工具包固定在一起。在这些系统中，更新是原子操作的，如果更新破坏了加速器依赖，可提供回滚功能，因此推理工作负载所依赖的软件栈在部署之间不会发生静默漂移。

在基于OpenShift的部署中，等效控制来自声明式节点配置。Node Feature Discovery操作符可检测可用加速器并相应地标记节点，而GPU操作符则将完整驱动和工具包生命周期作为版本化资源进行管理。这两个操作符都通过提交到Git的自定义资源进行配置，因此加速器栈成为集群定义的一部分，其变更将经过与其他配置相同的GitOps审核和回滚流程。

对于舰队层，OpenShift（Tekton）和 OpenShift AI（Kubeflow）Pipelines 提供了部署流水线，可在每次更新后验证加速器可用性并执行轻量级推理烟雾测试。对于不属于 Kubernetes 集群的独立 RHEL 设备舰队，Red Hat Edge Manager 承担了这一职责，以受控且分阶段的方式在舰队中部署 bootc 镜像更新，并提供设备运行镜像版本的可见性。无论舰队是 Kubernetes 节点还是现场的裸机 RHEL 设备，这些原则均适用。结合这两种控制机制，可以弥合工作原型（POC）与能够在操作系统更新、驱动升级和模型变更后持续运行的部署之间的差距。

还需要考虑另一个因素：依赖链还会引发一个版本生命周期问题，其影响范围超出了单个设备的更新。当向舰队中添加新的设备类别时，模型的持续集成、持续交付和持续部署流水线可能需要为当前模型训练和验证时并不存在的硬件生成新的硬件特定编译版本。这不是一次性活动；对于当前生产环境和预发布仓库中所有需要在新硬件类别上运行的模型版本，都必须重复此过程。将 CI/CD 流水线设计为以矩阵输出形式生成所有必要的硬件变体，并使用模型版本和硬件目标进行标记，可以避免在采购新设备类型时陷入噩梦般的局面。

但加速器依赖链并不是边缘 AI 工作负载特有的执行挑战的唯一来源。一旦堆栈稳定且加速器可靠可用，就会出现两个云部署不会以相同方式面临的额外约束。在许多边缘设备上，CPU 和 GPU 共享同一个物理内存池，因此任何进程的峰值都会直接影响推理引擎。如果您计划使用这种统一内存设备，请继续阅读下一节，了解它如何影响您的边缘 AI 用例。

资源竞争与时间保证：边缘 AI 执行挑战

在使用统一内存设备时，边缘 AI 部署会面临一些常见的执行挑战。第一个也是最常见的是 AI 进程与常规进程之间的资源共享，但根据具体用例，还可能存在其他挑战，例如工作负载延迟敏感性。让我们分别探讨这两个方面。

边缘设备与共享资源

在配备嵌入式 AI 硬件的边缘平台上，CPU 和 GPU 共享同一个物理内存池。这意味着设备上运行的任何进程的内存峰值会直接减少可用于推理引擎的内存，可能导致推理过程中出现内存不足（OOM）故障，或者反过来，AI 推理可能会占用操作系统和应用程序运行所需的内存。

延迟挑战

延迟挑战在边缘AI用例中普遍存在，它有两个截然不同的维度，通常需要不同的解决方案。

第一个是延迟敏感性。许多边缘AI应用无法像云应用那样优化平均响应时间。例如，在传送带检测系统中，延迟检测会导致缺陷漏检，或在高频采样预测性维护系统中，即使偶尔允许延迟峰值，也需要保持持续的低延迟。

第二个是确定性。某些应用需要保证最坏情况下的响应时间，而不仅仅是低平均值。例如，必须在限定时间窗口内响应的安全联锁装置，或在调度抖动会破坏运动序列的机器人控制器，无法接受推理步骤通常在2毫秒内完成但偶尔因GPU调度器降级或内存分配器需要重新组织而耗时50毫秒的情况。这种情况下可能产生物理后果。

延迟敏感型推理

针对延迟敏感性挑战，对于使用批量推理且具有较宽松延迟要求的应用，第一个配置决策是服务器批量大小设置。批量处理能提高GPU利用率和吞吐量，但批量大小超过1时会引入排队延迟，可能违反响应时间要求。因此，对于大多数对延迟敏感的边缘AI用例，应显式将批量大小设置为1，而非依赖服务框架的默认值。

此外，聚焦于AI服务架构及其如何帮助降低延迟，有两种推理模式能在不牺牲精度的前提下减少有效资源消耗和推理时间。第一种是"分层"或"级联"推理，即在受限端设备上先运行小型快速模型处理常见简单案例，仅当置信度评分较低或存在硬性延迟限制时，才升级到更强大网关或云端的大型模型。

第二种模式是"自适应"推理，即仅当传感器输入发生显著变化时才运行完整推理流程，首先进行轻量级变化检测检查。这使系统在需要使用模型时无需处理之前的推理排队任务，同时作为额外优势，在稳定场景中可显著降低平均功耗。

这些模式假设使用具有快速推理时间的任务专用模型，例如目标检测、缺陷分类、预测性维护评分或姿态估计。当边缘工作负载涉及大型语言模型（LLM）时会出现不同的挑战——例如，运行在近边缘网关上的现场助手需要本地回答技术人员的查询或总结传感器日志。LLM推理延迟主要由令牌生成决定，而非单次前向传递，因此我们之前讨论的标准优化技术无法直接应用。

针对这种情况，有两项技术值得关注。第一种是推测解码，可以视为一种特殊的级联推理案例，通过使用小型草稿模型生成候选令牌序列，由更大的验证器模型并行接受或拒绝，从而减少所需的完整前向传递次数，并显著缩短受限硬件上的首次令牌生成时间。

第二种技术是键值（KV）缓存量化，该技术可降低注意力缓存的延迟和内存占用。这对于边缘用例来说是一个额外优势，因为正如我们所见，在统一内存的边缘平台上，推理会直接与设备上所有其他进程使用的相同内存池竞争。重要的是，您使用的推理服务器需要支持这些技术，从这个意义上说，vLLM推理服务器支持这些技术，该服务器通过Red Hat OpenShift AI作为模型服务堆栈的一部分提供。

确定性与AI推理

对于需要确定性的应用，这种调优并不充分，因为调度器、内存子系统和中断层都可能产生延迟，无论推理引擎配置得多么完善。解决这个问题需要在操作系统层面进行额外的功能和配置。

第一个是PREEMPT_RT实时内核配置，它用提供有界最坏情况延迟的调度器替代标准调度器。除了实时（RT）内核外，通过isolcpus内核参数配置的CPU亲和性和核心隔离是实现这些RT保证的必要前提条件。没有它们，其他内核线程仍可能被调度到推理核心上，从而破坏时间契约。

中断请求（IRQ）亲和性将相同原理扩展到硬件中断。网络接口、存储和传感器总线必须远离隔离核心，因为传入的中断会抢占甚至实时线程。在内存层面，通过hugetlbfs实现的巨型页（2 MB或1 GB页面）在边缘硬件使用大型模型权重和激活缓冲区时可减少TLB缺失。具备所有这些条件后，完整的控制循环具有可预测的最坏情况执行时间。

值得注意的是，这些功能不仅在RHEL和Red Hat Device Edge中可用，在OpenShift中也可以配置CPU和IRQ亲和性/隔离、内存巨型页以及其他优化功能。

还需要强调的是，我们描述的确定性控制（实时内核、CPU隔离、IRQ亲和性等）是为单次快速推理调用设计的，它们不适用于LLM推理，因为LLM推理的延迟主要由迭代令牌生成决定，无论调度器配置如何，其延迟都以数百毫秒为单位进行衡量。

本节也不涵盖针对非统一内存访问（NUMA节点）的调优，因为多插槽硬件在边缘设备中较为罕见。在极少数使用多插槽硬件的边缘部署场景中，RHEL、红帽设备边缘（Red Hat Device Edge）和OpenShift中也提供了相应的机制，因此可以在本文描述的控制措施基础上进行叠加配置。

将推理连接到数据：边缘AI消息传递模式

我们已经介绍了如何在设备上高效运行推理，但数据如何到达推理服务？推理输出又如何传递给使用这些输出的系统？在边缘计算场景中，这是一个直接影响延迟、可靠性和机器学习运维（MLOps）流程的架构选择。

大多数传感器和数据源并不原生支持REST或gRPC协议。它们通过内核驱动程序、Video4Linux2（V4L2）、串行接口或专有SDK暴露数据，因此在原始数据源和推理服务之间几乎总是存在一个数据捕获进程。因此，消息传递模式的选择本质上是关于该捕获进程与推理结果下游消费者之间如何协调的决策。

在设计数据传输架构时，需要定义进程间数据物理传输方式（通过套接字的序列化复制与零拷贝共享内存），并确定数据交换是同步、异步还是流式传输。简化这些选项的组合后，有三种模式覆盖了大多数边缘AI部署场景。

推理过程中的数据摄入模式

同步请求-响应模式

捕获进程通过REST或gRPC调用推理服务，等待结果返回后执行相应操作。这种模式易于追踪，但会导致调用方与推理服务之间紧密耦合，因为如果模型更新改变了推理耗时或输出格式，调用方就会失效。这意味着它对MLOps有影响，因为当模型变更时，需要验证其不会破坏数据管道。

事件驱动的发布-订阅模式

在这种模式下，捕获进程将传感器数据发布到输入主题，推理服务订阅并处理每条消息，结果则发送到下游消费者独立读取的输出主题。发布-订阅架构将生产者与消费者解耦，这是与请求-响应模式的关键区别。当模型更新改变输出模式时，只需协调输出主题的消费者，而无需修改捕获进程本身。

但存在多种发布-订阅解决方案，应该选择哪种？基于代理架构最常见的方案是消息队列遥测传输（MQTT）和Kafka，而ZeroMQ和数据分发服务（DDS）则完全跳过代理，直接连接发布者和订阅者。

MQTT适合资源受限设备，因为它体积小、开销低且服务质量（QoS）等级足够。其局限性在于MQTT无法实现消息保留和重放，因为没有消息存储功能。如果需要将新模型候选者与最近的生产流量进行验证，MQTT无法提供支持。

另一方面，Kafka 可以配置消息保留窗口，这使得在金丝雀组中的任何设备接收到更新之前，能够通过候选模型重放过去24小时的生产输入帧。Kafka 还支持在同一流上使用多个独立的消费者组，因此监控、存储和下游执行可以独立消费推理输出而互不干扰。权衡在于运维开销。Kafka 在边缘运行是一个非平凡的重型进程，在受限硬件上这种成本是真实存在的。

并非所有方案都需要代理。ZeroMQ 是一个库，而不是代理。在这种情况下，套接字通过发布-订阅、请求-响应或管道模式直接连接进程，因此无需安装或管理单独的代理进程。这消除了运维开销问题，但也去除了消息保留、重放、发现和重新连接逻辑。

DDS 采用类似的去中心化方法，但专为实时系统构建。它是 Robot Operating System 2（ROS2）的默认中间件，QoS 策略涵盖可靠性、持久性和截止时间强制。当流水线中已包含使用 DDS 的机器人组件时，DDS 是自然的选择，但其复杂性和资源占用更接近 Kafka 而非 MQTT。

持续流处理

在此模式中，数据和帧缓冲区在各个阶段（捕获、预处理、推理、后处理）之间持续传递，如果所有步骤都在同一设备上运行，通常使用零拷贝共享内存缓冲区在元素之间传递。这是延迟最低的选项，适合高吞吐量场景（如视频分析工作负载）。但它也有一些 MLOps 后果，正如你所想象的，最重要的问题是相互依赖性，就像同步请求-响应模式中发生的情况一样。接口定义和数据交换方式（数据流水线）需要成为必须与模型一同管理的工件。例如，如果你更新计算机视觉模型并更改输入分辨率、颜色格式或输出张量形状，这将需要对应的数据流水线更新。单独部署其中一项而忽略另一项会导致静默故障——例如，推理服务可能接收到格式错误的帧并生成看似有效但实际错误的输出。

我们在此讨论的模式涵盖了在捕获、推理和下游系统之间传输数据的主要架构选择，以及每种选择带来的 MLOps 影响，但还有一个额外要求。现在我们将讨论显式模型版本标记，它在实践中意味着什么，以及为什么对部署和可追溯性至关重要。

显式模型版本标记作为 MLOps 要求

在 AI 模型金丝雀发布或跨多个设备的蓝绿部署过程中（更多内容见第3部分：管理分布式舰队中的 AI 模型），一部分设备运行新模型版本，而其余设备运行旧版本。两组设备同时将结果写入相同系统和服务。如果没有在每个输出中标记版本，金丝雀指标和生产指标将无法区分。准确率变化、延迟变化和输出分布差异都会混合成单一聚合结果。无法区分新模型和旧模型的行为差异。

该标签还从另一个方向封闭了审计链。当特定的推理输出驱动下游操作时，必须能够追溯到生成它的模型版本、训练数据集和流水线运行记录。

在实际应用中，标签是一个小型标识符——类似于模型名称、版本，以及可选的运行或实验ID——它被嵌入到生成推理结果的位置。具体放置位置取决于所选择的消息模式。对于请求-响应模式，标签可以作为专用的元数据字段包含在响应负载中，与推理结果并列。对于发布-订阅模式，标签的最佳位置可能是在消息元数据中，由消息代理附加到每条消息，与推理结果本身分开。

大多数消息代理（包括Kafka和MQTT）都允许发布者将键值头信息或属性附加到消息内容中。将版本标签放置在该位置意味着每个消费者都可以从固定位置读取它，而无需了解消息正文中的推理输出结构。对于通过共享内存传递缓冲区的连续流式处理流水线，缓冲区本身仅包含张量数据，其格式由流水线接口固定，因此版本标签必须通过单独的元数据通道传输。标签可以在推理组件将缓冲区传递到下一阶段之前，写入到附加的小型共享内存段中，或写入流水线运行时为帧级元数据提供的轻量级侧通道中。

服务框架不会自动添加此标签。Triton、OpenVINO Model Server和TorchServe会返回模型输出，但它们不知道设备属于哪个金丝雀分组，也不知道部署属于哪个实验。该上下文必须由推理包装器注入，然后包含在服务生成的每个输出中。

下一步

现在，我们的模型已在正确的硬件上运行，采用正确的运行时格式，并已启用资源隔离。但第一天正确运行与在数千台设备上持续数月的运营管理是两个不同的问题。

在下一篇文章《第3部分：跨分布式舰队管理AI模型》中，我们将探讨部署与第二天运营之间的操作层。我们将回答以下问题：

• 如何知道当前每台设备上运行的是哪个模型版本？如何按硬件类别、地理位置或业务部门向特定设备组推送更新？如何通过受限链路高效传输大型模型工件？

• 如何接触完全没有网络连接的设备？

• 在新模型版本接触整个舰队之前，如何将其与当前生产模型进行验证？

您还将了解部署失败时会发生什么，如何设计包含AI质量检查而非基础设施健康状况的回滚机制，以及如何满足监管行业对现场边缘AI系统施加的治理和可追溯性要求。

Block | Dynamic pattern deluxe promo

Component | Band_header

Product trial

Red Hat Device Edge | Product Trial

一个灵活的平台，可在工作负载和设备之间提供操作一致性。

Component | spacer

Component | Cta_multi_basic

Subpattern | simple_cta

Component | CTA

Try it

Deluxe mbox

Component | Card_header

About the author

Subpattern | speaker

Card layout

Component | Image_embed

Component | Person

Luis Javier Arizmendi Alonso

Subpattern | social_links

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

在 Red Hat，他帮助组织设计可扩展的架构，将 AI 从数据中心延伸至边缘，部署到需要感知、决策和在现实世界中行动的系统中。

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

阅读该作者的更多文章

类似内容推荐

Dynamic pattern

博客文章

边缘上的 MLOps：在边缘运行 AI 模型

Red Hat OpenShift：与 AxyomCore 一起为 Telenor 构建弹性 5G 自主边缘

原始播客

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

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

Subpattern | card_flex

Subpattern | text_basic

继续探索

• 通过 Red Hat Enterprise Linux 电子书 提升边缘的安全性、灵活性和可扩展性

• Red Hat 与 Cisco：通过视频 在边缘扩展网络自动化

• 三星通过 Red Hat OpenShift 案例研究 推动 5G 和边缘网络

继续探索 mbox

Subpattern | simple_text

按频道浏览

浏览所有频道

Pattern | raw_html

自动化

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

人工智能

关于使客户能够在任何地方运行 AI 工作负载的平台的最新动态

开放混合云

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

安全

关于我们在不同环境和技术中降低风险的最新动态

边缘计算

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

基础设施

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

应用程序

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

虚拟化

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