MLOps for edge AI: Preparing AI models for deployment at the edge

面向边缘AI的MLOps：为边缘部署准备AI模型

Component | Article_teaser

2026年10月5日

19分钟阅读

人工智能

,

边缘计算

Luis Javier Arizmendi Alonso

高级首席解决方案架构师

Subpattern | social_share_set

Component | social_share

分享

Subpattern | subscribe

Component | social_icon

订阅RSS

Component | Icon

© Red Hat, Inc. CC-BY-4.0许可

Subpattern | results_nav

组布局

Component | Nav_links

• 返回所有文章

Component | Generic

当我开始尝试将AI模型应用于边缘计算场景时，一切进展都很顺利。但当我达到“它能运行”的阶段，并开始思考如何将其投入实际应用时，整个过程变得复杂起来。我开始质疑：一个训练好的模型如何转化为可以部署到边缘的实体？在运行AI模型时，如何最大程度发挥边缘设备的性能？如何管理数百个分布式的模型？如何在长时间内保持模型的准确性？

如果你曾经有过这些疑问，那么请继续阅读本系列文章。在这里，我们将回答这些问题以及其他与边缘AI模型生命周期相关的问题。

本系列共四部分，将完整呈现AI模型的旅程：从训练完成的那一刻起，经过部署到数千个边缘设备，实现平台和AI模型生命周期的大规模管理，最终进入持续的监控、优化和重新部署循环，从而在大量设备上保持模型的准确性。

但让我们从头开始。

在本文中，我们将聚焦于从训练流水线到已签名AI模型的旅程，这些模型已准备好前往边缘。

在深入细节之前，建议你阅读配套文章《将AI迁移至边缘：优势、挑战与解决方案》。这是理解为什么组织要将AI推理迁移到边缘的良好起点。本系列文章将更深入探讨与边缘环境特别相关的机器学习运维（MLOps）概念，而将通用的MLOps实践排除在讨论范围之外。

架构：理解各组件的分布位置

首先要提出的问题是：哪些MLOps组件应该部署在哪里？

边缘AI并不强制要求我们在远程站点运行架构，完全取代云端现有的运行环境。更好的方法是进行分布部署。MLOps生命周期的某些部分必须保留在云端，而其他部分则必须在边缘运行。

核心数据中心或云端应保留哪些内容？模型训练、超参数优化和实验跟踪通常属于这些位置，因为这里计算资源充足，且对内存或功耗预算没有压力。模型注册表、数据集版本管理系统、重新训练流水线、集中式监控聚合、治理记录以及舰队管理控制平面也应集中部署。这些功能得益于可靠的基础设施，且没有严格的实时性或低延迟要求。

在边缘端，职责范围更窄，但约束条件更严格。推理过程应尽可能靠近传感器或执行器运行。边缘端负责本地特征提取、即时执行、本地事件检测和短期数据缓冲。通常情况下，完整的模型训练不会在边缘端进行——尽管在空闲时段进行有限的本地微调或采用联邦学习模式正变得越来越实用，相关内容将在第4部分“保持模型随时间准确”中介绍。

典型边缘AI架构拓扑示例（使用Red Hat产品）

这两层之间的连接性需要处理从核心到边缘的模型更新，同时将遥测数据、训练数据和监控数据从边缘传输到核心。此外，在连接性方面，大多数边缘计算用例有一个重要要求：推理功能不应依赖互联网连接。

在推理请求期间，如果系统需要调用远程应用程序编程接口（API），则该系统并未为边缘环境设计；这是一个客户端-服务器应用，一旦网络中断就会失效。

一旦明确各组件的部署位置，下一个问题是：模型本身在部署到边缘硬件之前需要具备怎样的形态？

模型准备：优化与运行时格式

我需要在此声明：本节内容适用于深度学习模型，但需注意并非所有边缘AI用例都需要深度学习模型，因为经典机器学习方法（如决策树、梯度提升树或统计异常检测）通常无需以下任何步骤即可在边缘硬件上高效运行。

如果您正在考虑使用深度学习模型（如计算机视觉、语音或基于大语言模型（LLM）的应用），从训练到部署的路径涉及多个关键因素。

训练后的深度学习模型几乎从不会以适合在边缘设备上高效运行的格式存在。它通常以PyTorch检查点或完整32位浮点（FP32）精度的Hugging Face模型文件形式存在，专为高内存GPU设计。在部署到边缘设备之前，需要对其进行优化并编译成目标硬件可高效执行的格式。

优化

为什么需要优化？训练流水线输出的完整模型可能占用其优化版本数倍的内存且运行速度慢得多。在运行操作系统（OS）、应用程序负载和推理服务的8GB共享CPU/GPU内存设备上，未优化的模型根本无法运行。

优化流程可能包含多个阶段。当模型本身过大时，知识蒸馏是合适的工具。与其他下文技术不同，它不会修改原始模型，而是训练一个更小的学生模型来模拟更大教师模型的行为，在进一步优化前从根本上减少模型容量。

下一个技术是剪枝，通过移除对输出贡献较小的权重来实现。非结构化剪枝通过移除单个权重实现更高压缩率，但需要运行时支持稀疏计算；结构化剪枝则移除整个预定义参数组，生成具有相同架构但更小的模型，更易于映射到硬件加速器。

最后，量化是一种技术，它通过将模型权重从高精度（即FP32）转换为较低精度来实现，但代价是降低模型的推理准确性。混合精度策略会将容易出现精度损失的层以FP16或FP32运行，而将其他层保持在8位整数（INT8）或4位整数（INT4）中，通常能在模型体积缩减和精度保持之间取得最佳平衡。

运行时格式

在手头已有优化后的模型后，准备模型时的下一个决策是选择在边缘设备上使用的运行时格式。但这里有一个重要限制：这一选择可能因硬件而异，这在边缘计算场景中可能颇具挑战，因为边缘设备通常包含异构设备群。

有一种格式被视为实现尽可能硬件无关的最佳选择：开放神经网络交换格式（ONNX）。这是最重要的格式需要理解，因为它在不同目标硬件的格式之间充当通用中间步骤。常见的训练框架如PyTorch和TensorFlow可以将训练好的模型导出为ONNX，然后从ONNX编译到特定硬件的目标平台。

这里再补充一个免责声明。当提到ONNX时，我指的是可移植的交换格式，但还有一个名为ONNX Runtime的运行时，它不是格式。运行时用于执行ONNX格式的模型。

ONNX格式和ONNX Runtime的美妙之处在于，你可以直接在x86_64和aarch64架构上使用CPU或GPU后端运行模型，这使其成为在异构设备群中实现单一通用格式的最便携选择。

但为什么还会存在其他运行时格式呢？

当你的边缘使用场景中可移植性不如在特定芯片上榨取每毫秒性能重要时，原生硬件运行时会接管。例如，如果你使用的是NVIDIA特定设备，那么另一个运行时如TensorRT可能是最佳选择。TensorRT会将ONNX模型编译为NVIDIA硬件特定的执行引擎，通常在NVIDIA硬件上相比ONNX Runtime能提供更高的吞吐量和更低的延迟。

然而，这些特定硬件的运行时格式也有其缺点。默认情况下，为一种GPU微架构编译的TensorRT引擎无法在另一种架构上运行，因此在异构设备群中需要为每种GPU类型分别生成引擎。TensorRT提供了一种硬件兼容模式，允许引擎跨多种架构运行，但你仍然需要从基础ONNX重新编译模型。因此，在生产边缘部署中，当性能至关重要时，按架构分别构建仍然是推荐的路径。

上述内容对其他特定硬件的运行时和运行时格式（如OpenVINO）同样适用，OpenVINO执行的优化与TensorRT类似，但针对的是英特尔硬件（CPU、集成GPU和视觉处理单元（VPUs））。

边缘设备上的大语言模型（LLMs）

需要指出的是，这里描述的技术和格式主要适用于当前主导边缘AI的预测性AI模型，例如用于质量控制和监控的计算机视觉模型、用于预测性维护的时间序列模型，以及用于异常检测的结构化数据模型。边缘设备上的生成式AI（gen AI），如大语言模型（LLMs），是一个正在兴起并不断增长的应用场景，但其优化特性有所不同。

例如，标准的INT8训练后量化方法是为编码器和卷积架构设计的。大语言模型（LLMs）需要特定的量化方法，如激活感知权重量化（AWQ）和通用训练后量化（GPTQ），这些方法能更精确地处理Transformer解码器层的宽激活动态范围。就像非LLM边缘模型依赖ONNX（格式）和TensorRT或ONNX Runtime（运行时）实现优化推理一样，LLMs也有自己的格式和运行时生态系统。

在服务器端，使用SafeTensors序列化或通过AWQ/GPTQ量化后的模型，可在高吞吐量运行时（如vLLM）上运行。在CPU和混合CPU/GPU边缘硬件上，GPT生成的统一格式（GGUF）——一种通常自带量化功能的模型容器格式——已成为主流格式，搭配llama.cpp（vLLM中也包含该实验性功能）使用。

总结回到非生成式AI领域，这目前占边缘AI最常见的用例。针对异构设备集群的推荐流程是：使用PyTorch或TensorFlow进行训练，导出为ONNX作为通用中间格式，然后在编译时分支生成特定硬件的变体（按NVIDIA GPU类型生成TensorRT引擎，针对Intel设备使用OpenVINO，其他设备使用ONNX Runtime模型）。

在边缘AI用例的模型准备中，下一步是什么？实际上，量化、剪枝、知识蒸馏和格式转换等优化技术很少单独应用。它们会被串联成MLOps流水线，实现从训练模型到部署产物的全流程自动化、版本管理和可复现性，这正是下一章节要讨论的内容。让我们深入探讨。

模型CI/CD流水线：部署前建立信心

在数据中心（云或本地）运行AI时，可以快速迭代模型版本并频繁推送更新。但在边缘设备上，若将一个错误模型同时推送到10,000台设备，将导致无法轻易恢复的重大问题。

如何确保你的模型已准备好使用？AI持续集成/持续交付（CI/CD）流水线就是决定模型是否具备部署资格的关卡。

标准软件CI/CD检查代码能否编译和单元测试是否通过。对于AI模型，这些检查是必要但不充分的。在你的边缘AI用例MLOps流水线中，需要增加三种额外的关卡类型。

AI CI/CD关卡类型

数据验证在训练运行生成模型前检查训练数据集。例如，它会验证预期的类别分布是否存在，标注错误率是否低于阈值，以及训练集和评估集之间是否存在数据泄露。在损坏或不平衡数据上训练的模型可能在离线评估中表现准确，但在生产环境中会系统性失败。

模型精度回归测试通过使用保留测试集对候选模型与当前生产模型进行对比，该测试集由最近的生产标注示例主动维护。与在原始训练测试集上进行评估相比，这种测试方式能提供更强的信号，因为生产测试集反映了当前现实世界的输入分布，而不是模型最初训练时的分布。此外，它还能帮助检测过拟合问题。一个模型可能在静态训练测试集上持续提高分数，但同时却在记忆测试集内容，因此只有通过与新鲜的生产数据进行测试，才能验证模型是否仍然具备泛化能力。

硬件性能验证。虽然数据和精度验证适用于MLOps的通用场景，但硬件性能验证更具体针对边缘计算用例。它会在舰队中每类设备的代表性物理硬件上运行候选模型，测量推理延迟、内存占用和功耗。一个模型即使通过了所有精度验证，但如果其内存占用超过了部署目标变体的限制，或其推理延迟超过了目标应用的服务等级协议（SLA），则仍会被判定为验证失败。此验证必须在实际目标硬件上运行，而不是在云GPU或模拟环境中进行。目前，这一步骤仍主要依赖人工操作，团队持续构建自己的内部设备和脚本，将设备连接到CI流水线。Jumpstarter等项目旨在标准化这一过程，为CI/CD流水线提供一致的方式，在真实或虚拟硬件上运行测试，而无需每次重新设计相关基础设施。

Red Hat OpenShift AI（Red Hat提供的统一企业级混合AI和MLOps平台）中的AI流水线基于Kubeflow Pipelines构建，为这些多阶段模型CI/CD流水线提供编排基础设施。作为OpenShift AI的一部分，MLflow跟踪训练运行、参数集和工件哈希值，使每个模型都能追溯到生成它的数据和流水线配置。

部署策略

假设您的模型已通过MLOps流水线集成验证。接下来该怎么办？

您可能会认为需要开始考虑持续部署流水线。

我的意思是，部署流水线需要管理经过验证的模型如何通过金丝雀部署（先向小部分设备推送并监控，再全面部署）、蓝绿部署（与生产版本并行运行，生产版本是唯一处理请求的版本）或按设备组分阶段部署等策略到达舰队。

在进入这些步骤之前，您仍需做出一个重要决策：如何打包您的模型以及如何将其分发到边缘位置。

为分发打包模型

模型权重是训练流水线的输出，最终它们是一个文件。该文件需要以某种方式到达边缘设备，与执行它的推理运行时一起。总体而言，您可以直接分发该文件，或使用不同的传输机制，如容器镜像。

影响打包决策的另一个重要因素是，边缘部署通常在连接间歇性或完全缺失的环境中运行，例如具有射频（RF）屏蔽的工厂车间、偏远地区的变电站、穿过覆盖空白区域的车辆，或设计上禁止外部网络接入的物理隔离站点。

每种方法在模型体积、更新频率和离线行为方面都有其权衡。让我们看看一些主要模式。

打包模型的不同方式

将模型和运行时嵌入同一容器镜像

第一种方法将模型权重直接嵌入容器镜像中，与推理运行时一起打包。模型和运行它的代码以单个开放容器倡议（Open Container Initiative，OCI）镜像的形式进行部署和传输。无需依赖外部存储的运行时依赖项，模型和运行时始终使用经过验证的相同版本。明显的缺点是，任何模型更新都需要重新构建和重新分发完整的容器镜像。对于经常离线或模型更新频率较低的远端设备，这种权衡是合理的：简单性和可靠性超过了更新带来的开销。

用于模型的专用容器镜像（Modelcar模式）

第二种方法称为Modelcar模式，将模型权重打包为一个专用的、轻量级的OCI容器镜像，仅作为数据载体。运行时服务器拥有自己的容器镜像。推理服务器（例如OpenShift AI、OpenShift和现在MicroShift中都可用的KServe）在启动时通过初始化容器从该sidecar挂载模型。这将模型版本与运行时版本解耦。模型和运行时各自拥有独立的发布周期、各自的OCI签名链，以及在注册表中各自独立的版本历史。这是最灵活的模式，也是与云原生实践最契合的模式。

直接使用模型文件

第三种方法直接分发文件。它将模型作为外部文件（例如存储在简单存储服务（Simple Storage Service，S3）存储桶中）存储在卷或对象存储端点上，并在启动时将其挂载到推理容器中。这允许模型独立于运行时容器进行更新。问题是它会创建运行时依赖项：如果容器启动时存储端点不可用，除非文件已下载，否则推理会失败，这使模型更新变得复杂。

此外，在边缘计算场景中，存储系统通常是远程的，连接也不可靠。这种方法还需要单独的分发基础设施（如网络文件系统（Network File System，NFS）、S3兼容对象存储或专有解决方案），并需要其自身的身份验证、访问控制、版本管理和安全扫描。当模型以容器形式打包时，你会失去容器注册表自动提供的签名、扫描和版本管理能力，同时还要为并行分发系统增加操作负担。对于大多数边缘部署场景，这种操作投入并不划算。

将模型嵌入操作系统镜像

第四种方法将模型嵌入操作系统镜像中。例如，当模型与bootc镜像模式操作系统（即Red Hat Device Edge）结合时，模型可以直接作为文件嵌入操作系统镜像，或包含在容器镜像中，使内核、驱动程序、运行时和模型成为一个单一的原子单元，一起部署并一起回滚。

该模型的优势在于实现最大一致性，但缺点是任何模型更新都需要重新构建和重新分发操作系统镜像。对于模型频繁变更或不同设备需要不同模型版本的部署场景，更新周期成本会变得非常高。这种模式最适合以下场景：模型更新极少、认证要求需要完全不可变的堆栈，或单个构件的操作简便性超过全镜像重新分发的成本，例如设备在断开连接的环境中运行时。

最佳选择取决于连接性特征和更新频率。对于经常断开连接的远端边缘设备，将模型嵌入操作系统镜像可实现原子化部署、无外部依赖项和一致的回滚操作。对于具有可靠连接且模型频繁更新的边缘设备，解耦模式则能提供灵活性，同时避免外部存储风险。

在本系列的后续内容中，我们将主要使用基于容器的模型示例（第一、第二和第四种方法），这些模型主要通过OCI容器镜像仓库进行分发——与用于应用容器的同一OCI容器仓库——因为这为边缘计算架构提供了多重优势。

模型仓储与分发

你可能已经决定将模型打包成容器镜像是最优方式。但如何将这些容器镜像分发到边缘设备呢？

答案很简单。如果容器镜像是AI模型的主要分发单元，那么用于托管和分发这些镜像的基础设施应与所有其他容器工作负载使用的基础设施相同：容器镜像仓库。

在进一步探讨容器镜像仓库使用之前，需要澄清一个术语：模型注册表（model registry）。在MLOps领域，模型注册表是一个元数据和生命周期管理系统。它不存储模型权重或分发模型，而是跟踪模型版本、实验血缘关系、评估指标、审批状态和部署历史。模型注册表回答的是“这个模型的哪个版本包含在此构件（在我们的情况下是容器镜像）中，我们对它了解哪些信息？”，而容器镜像仓库回答的是“这里是有签名且不可变的构件，可以拉取使用”。

回到容器镜像仓库，需要记住它不是一个文件服务器。它提供内容存储，其中每一层都通过其哈希值进行标识，支持镜像签名、漏洞扫描、访问控制、去重、增量更新、多架构清单支持以及跨仓库复制。对于边缘计算场景，复制是一个优秀的分发方法，你可以在边缘位置设置一个小型的次级容器镜像仓库来复制镜像。

如果你在思考为何要使用容器镜像仓库来通过容器镜像分发模型，请记住：当你将模型作为OCI容器镜像存储时，容器镜像仓库中所有这些功能会自动应用于你的模型分发架构，无需额外工具。

与之替代的方案——通过对象存储或NFS以原始文件形式分发模型——需要分别构建每项能力。你需要单独实现签名机制、漏洞扫描器、访问控制系统、复制机制以及模型文件的保留策略，所有功能都需在注册表之外运行，并产生各自的操作开销。构建并行文件分发基础设施所需的操作投入通常过高。

通过将OCI作为模型分发格式，你可以使用同一套基础设施来管理舰队所需的其他所有资产，而减少边缘侧的基础设施投入始终是巨大的优势。

应用容器已经存储在注册表中，但通过bootc构建的操作系统容器镜像也可以像GitOps配置清单或Helm图表一样，以相同方式存储和分发。其结果是实现一个统一的注册表，能够使用相同工具、相同签名密钥和相同访问策略来分发操作系统更新、应用部署、模型更新和配置清单。在为新边缘站点提供服务时，注册表是唯一需要访问的分发系统。

此外，像OCI Registry as Storage（ORAS）这样的项目简化了在容器镜像中分发模型的过程，并更进一步，通过提供通用规范和工具，将任意文件类型作为OCI制品进行存储，而不仅限于容器镜像。这意味着只要内容封装在OCI制品格式中，配置包、校准数据集或固件包等任意文件都可以通过相同注册表进行推送、拉取、签名和管理，使用相同的访问策略和工具——使容器镜像注册表成为向边缘分发和托管制品的通用系统。

Red Hat Quay作为企业级容器镜像注册表，是构建这种模型分发架构的理想选择，因为它原生支持多架构镜像索引、通过zstd:chunked压缩实现高效的分层下载（更多内容见第3部分：跨分布式舰队管理AI模型）、通过cosign实现镜像签名集成、漏洞扫描、镜像复制和镜像等功能。

那么，大语言模型（LLMs）又如何处理？

如前所述，大多数边缘AI用例使用非生成式模型，这也是为什么上述所有示例都聚焦于这种类型的AI。然而，边缘计算领域仍存在一些新兴的LLM用例，例如设备端的员工助手或协作者、自然语言接口等。如果想要在边缘运行LLM，LLM模型分发又会呈现怎样的形态？

对于LLM部署而言，模型权重并非唯一需要这种封装的制品。系统提示——包括少量示例、思维链指令和工具定义——直接控制模型行为，其影响程度可能与权重更新相当。

供应链安全：保护AI工件

当模型进入注册表后，在其前往边缘设备之前，需要验证是否有人篡改过它。

AI模型的威胁面与标准应用容器不同。模型后门攻击或AI木马会修改模型权重，使模型在正常输入下表现正确，但能可靠地对特定触发模式进行错误分类或数据外泄。被修改的模型会通过功能测试，因为它在所有输入上都真正执行了预期功能，除了精心设计的触发器。这是一个有意义的攻击向量。更糟糕的是，一个被篡改的模型分发到数千台设备上，会导致几乎无法通过法医调查发现的系统性故障。

保护模型分发到边缘设备

边缘部署更容易受到这种威胁，因为模型需要经过更长的CI/CD管道、注册表、复制跳转，有时甚至通过物理介质传输到隔离站点。每一步都可能是攻击插入点。

如前一节讨论的，在容器镜像中分发模型时，使用cosign（Sigstore项目的一部分）进行镜像签名可以关闭最直接的攻击向量。模型容器镜像在离开验证过的CI/CD管道时进行签名。无论模型通过何种方式到达设备，每个设备在加载模型前都会验证该签名。通过被入侵的注册表分发或通过USB传输到离线站点的篡改模型都会以相同方式被拒绝。

Red Hat OpenShift Pipelines可以在CI/CD管道内部直接自动化这个签名步骤，确保签名始终如一地应用而无需人工干预。Red Hat Trusted Artifact Signer更进一步，通过在您自己的OpenShift集群中运行Sigstore组件并使用您自己的信任材料，使您不再依赖外部基础设施。OpenShift、MicroShift以及搭载Podman的Red Hat Enterprise Linux（RHEL）都可以通过容器策略配置原生强制镜像签名验证，在镜像运行前拒绝未签名或签名错误的镜像。

模型与CVE

此外，软件物料清单（SBOM）生成解决了另一个威胁：模型所依赖组件中的漏洞。当模型和运行时一起打包（如前一节所述的第一种模型打包方式），一个SBOM可以覆盖整个堆栈：基础操作系统、包含Python包、CUDA工具包等依赖项的推理运行时。使用Modelcar模式时，SBOM位于运行时镜像中，所有可被利用的组件都位于此处。

容器镜像仓库（如 Red Hat Quay）会将 SBOM 元数据与镜像签名一同存储，但标准 SBOM 无法捕获模型特定信息，例如训练框架、数据集、模型是否基于基础模型进行微调，或应用了何种量化方式。AI 材料清单（AIBOM）弥补了这一空白。Red Hat 正在积极制定 AIBOM 标准并开发相关工具，用于结构化和验证 AIBOM 数据，探索其如何与安全工具（如 Red Hat Trusted Profile Analyzer）集成。Trusted Profile Analyzer 当前已能将 SBOM 与常见漏洞和暴露（CVE）数据库进行交叉验证，因此当发现漏洞时，可立即确认舰队中哪些模型镜像受到影响。

即使使用 SBOM，应对运行时镜像中 CVE 的最佳方式仍是避免这些漏洞的存在，而 Red Hat 在这方面也有解决方案。Red Hat Project Hummingbird 提供了专为减少组件数量而构建的最小化且强化的基础应用镜像。这有助于减少舰队中需要发现、跟踪和修复的 CVE 数量。

信任操作系统

SBOM 和最小化基础镜像解决了镜像内部的内容问题，但它们无法说明加载和运行模型的软件本身是否可信。如果执行签名检查的设备本身未被污染，签名检查才有意义。如果运行模型的操作系统已被攻击，它可能会报告任何信息，甚至可能告诉你恶意模型是安全的。安全启动通过在任何用户空间代码运行前验证从固件到引导加载程序和操作系统内核的完整链，有助于解决这一问题，从而确保执行模型签名检查的环境本身是可信的。

其局限性在于，安全启动仅验证到引导加载程序和操作系统内核，这可能不足以满足边缘计算场景的需求。

对于在工厂车间、变电站或偏远地点无人值守运行 AI 推理的边缘设备而言，物理访问是现实威胁，这意味着攻击者可以通过外部设备直接修改物理磁盘上的内容来篡改设备操作系统。

如果你认为使用基于镜像的操作系统（如上文提到的 bootc 镜像）能通过将系统文件存储在只读分区中来防范这些攻击，那就错了。

拥有物理访问权限的攻击者可以绕过这一保护，因为他们可以从外部介质启动，离线挂载磁盘并在操作系统启动前直接修改文件。这意味着 bootc 在运行时提供的只读保护无法防御在启动前已将设备掌握在手中的攻击者。推理运行时或模型权重可以通过这种方式被替换，且修改不会被检测到，因为在挂载时没有任何机制验证磁盘上的状态。

然而，bootc 密封镜像——这一新的实验性 bootc 功能——通过使用 composefs 和 fs-verity 在启动时验证整个根文件系统，从而弥补了这一差距。在镜像构建过程中，会计算根文件系统的 composefs 摘要，并将其嵌入到统一内核镜像（UKI）的内核命令行中，随后使用您的安全启动密钥对 UKI 进行签名。启动时，安全启动固件会验证 UKI 的签名，并通过 fs-verity 将内核命令行中的 composefs 摘要与实际挂载的根文件系统进行比对。在任何代码执行之前，包括通过物理介质更新到空气隔离站点的设备，都可以检测到对操作系统、运行时或模型加载器的离线篡改，因为文件系统必须与构建时签署的内容完全一致。

下一步计划

我们已经到达了一个关键节点：模型已完成训练、优化、打包，并存储在已签名且已扫描的注册表中，必要时即使在离线环境中也可以部署。

在第二部分《在边缘运行 AI 模型》中，我们将追踪模型从注册表到部署设备的全过程，这些设备将作为异构边缘硬件舰队的一部分运行模型。我们将根据设备类别选择合适的执行平台，管理硬件加速器及其依赖链，应对特定的边缘 AI 需求，并回顾 AI 模型的消息架构模式。

Block | Dynamic pattern deluxe promo

Component | Band_header

Resource

企业组织 AI 入门指南

了解 Red Hat 如何帮助您采用并扩展 AI 解决方案。探索两种 AI 类型（预测性 AI 和生成性 AI）及其独特优势。

Component | spacer

Component | Cta_multi_basic

Subpattern | simple_cta

Component | CTA

获取资源

Deluxe mbox

Component | Card_header

关于作者

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

Blog post

重新构想代理时代的企业创新引擎

构建 AI 驱动的多模态合规监控器：从训练到跟踪到聊天

Original podcast

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

使用 PyTorch 标准化 AI 堆栈

Subpattern | card_flex

Subpattern | text_basic

继续探索

• 什么是代理 AI？ 文章

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

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

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

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

继续探索 mbox

Subpattern | simple_text

按频道浏览

探索所有频道

Pattern | raw_html

自动化

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

人工智能

平台更新：让客户随时随地运行AI工作负载

开放混合云

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

安全性

了解我们如何在不同环境和技术中降低风险的最新进展

边缘计算

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

基础设施

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

应用程序

深入解析我们应对最复杂应用挑战的解决方案

虚拟化

面向本地或跨云工作负载的企业虚拟化未来