Architecting offline-first generative AI applications for edge deployments using AWS services

使用 AWS 服务为边缘部署构建以离线优先的生成式 AI 应用 | AWS 架构博客

使用 AWS 服务为边缘部署构建以离线优先的生成式 AI 应用

根据西门子 2024 年《停机真实成本》报告，财富 500 强企业每年因计划外停机损失约 1.4 万亿美元。这种停机问题通常因缺乏快速检测和解决问题的技能而加剧。生成式 AI 提供了有前景的解决方案，但在工业环境中部署这些能力会带来独特的架构挑战：如何将大规模 AI 的能力带给云连接不可靠或不可用的地点？

答案在于采用离线优先架构，该架构将 AI 推理转移到边缘，同时利用云服务进行模型定制、部署编排和持续改进。这种模式需要在多个 AWS 服务之间进行精心协调，这些服务涵盖人工智能和机器学习（AI/ML）、物联网（IoT）和存储，并且需要在模型能力、硬件限制和运营复杂性之间做出权衡。

以下是一些可能受益于边缘智能应用的潜在用例：

• 维修团队难以将实时日志流与相关机器手册关联，并分析当前情况。
• 在卫星连接有限的区域（如海上平台、偏远钻井现场和管道维护站点），需要即时访问安全规程、设备手册和合规文件。
• 配备精准农业设备的远程农业设施，需要访问机械手册、作物管理协议和安全规程。

本文将逐步介绍使用 AWS 服务构建和部署边缘生成式 AI 应用的参考架构。我们涵盖端到端模式，从使用 Amazon Bedrock 和 Amazon SageMaker AI 在云端进行模型定制，到使用 AWS IoT Greengrass 进行边缘部署，再到由 Strands Agents 协调的本地推理。在此过程中，我们将重点介绍使该方法可行的关键架构决策和服务集成模式。

本文描述的是参考架构，不适用于直接生产环境。在部署到生产环境之前，请执行安全审查并实施适合您工作负载的控制措施。

离线优先 AI 的架构决策

设计离线优先 AI 架构首先要做出关键决策：如何在保持模型足够小以在边缘硬件上运行的同时，为您的领域定制语言模型。该模型必须适应现场级设备的计算和内存限制（通常为配备 16GB 或更多 VRAM 的 GPU），这意味着需要使用小型语言模型（SLMs）。您选择的定制策略会直接影响架构的复杂性、成本和数据管道需求。

以下策略代表了不断增加的架构复杂性层级，每种策略都有不同的基础设施需求和预期结果：

• 模型微调（FT）：一种相对轻量的流程，用于将预训练模型适配到特定任务。例如，你可以通过使用维护工单中的带标签问答对，微调模型以回答特定设备的故障排除问题。微调擅长教会模型你期望的输出格式、风格和结构。然而，它在注入基础模型原始训练数据中未包含的新领域知识方面效果较差。

• 持续预训练（CPT）：一种资源消耗较大的流程，通过使用特定领域的未标记数据扩展基础模型的训练，以嵌入新知识。例如，你可以通过在技术手册、维修日志和工程文档上继续训练，教会模型设备专用术语、故障模式和诊断流程。这种方法能有效将领域知识注入模型参数，但与微调相比，需要更多的计算资源和更大的数据集。

• 混合方法（FT + RAG）：检索增强生成（RAG）通过在推理时检索相关文档来增强模型响应，从而提供带来源引用的准确、最新答案，并减少幻觉。在我们的边缘实现中，使用 ChromaDB（SQLite + HNSW 默认配置），搭配在 CPU 上运行的 sentence-transformer 嵌入模型（384 维）。文档以 512 个标记为单位进行分块，重叠 50 个标记。在数据集达到 5 GB 时，检索延迟仍低于 50 毫秒。整个 RAG 管道运行在 CPU/SSD 上，不消耗任何 GPU 显存，将全部 16 GB 内存专用于大语言模型（LLM）。

• 混合方法（CPT + RAG + FT）：结合嵌入模型的持续预训练与语言模型的微调，以优化整个 RAG 管道。通过在特定领域查询上继续训练嵌入模型，使其更好地理解领域专用术语和行话，同时通过问答对微调语言模型，以实现你期望的格式和语气。例如，当操作员询问饼干机的状态时，他们期望得到一个应用程序来检查当前状态、每分钟吞吐量和饼干的视觉质量！这种双重优化确保了检索的准确性与响应质量，非常适合知识密集型应用。

要为你的应用选择合适的策略，需要从使用案例需求和预期结果反向推导。

参考架构

让我们分析一个基于 AWS 的边缘部署生成式 AI 解决方案的参考架构。该架构针对制造场景，操作员需要即时访问设备文档、日志关联和故障排除指南，且无需依赖云连接。我们选择了混合方法（FT + RAG），因为它平衡了两个架构关注点：通过微调实现任务特定行为以保持设备端模型紧凑，同时使用 RAG 提供无需重新训练即可实现的最新知识检索。下图展示了端到端架构：

该架构跨越两个信任域。在云端，每个服务（Amazon Simple Storage Service（Amazon S3）、Amazon Bedrock、SageMaker AI、IoT Greengrass）均基于专用的最小权限AWS身份和访问管理（IAM）角色运行。所有云到边缘的通信均使用IoT Greengrass设备证书进行双向TLS加密。操作门户需要身份验证。在边缘设备上，操作人员。

该架构分为三层：云端准备（步骤1-3）、部署编排（步骤4）和边缘推理（步骤5-9）。每一层均使用特定的AWS服务，这些服务因其集成能力而被选中。

1. 文档基础设置

技术手册和标准操作程序（SOP）存储在Amazon S3中，作为云端训练流水线和边缘RAG知识库的单一事实来源。Amazon S3与SageMaker AI和IoT Greengrass的集成使其成为必须在云和边缘之间传输工件的自然选择。

2. 标注数据准备

通过Amazon Bedrock上的Amazon Nova Pro，我们将原始文档处理为结构化的问答-上下文三元组以进行微调。这是一个关键的架构决策：我们不手动整理训练数据，而是使用云中的大型基础模型（FM）生成高质量的标注数据。Amazon Bedrock的无服务器推理使该步骤成本效益高，输出直接进入SageMaker AI流水线。

3. 模型定制（FMOps流水线）

Amazon SageMaker AI Pipelines编排了一个自动化的FMOps流水线，该流水线在特定领域的问答对上对gpt-oss-20b（专家混合（MoE）架构：总参数21B，每token激活3.6B，32个专家，128k上下文长度）进行微调。此处的流水线模式是刻意设计的：它实现了可重复、可版本化的模型定制，每当新增文档时即可触发。流水线训练模型理解设备特定的术语和响应格式，然后将定制后的模型工件存储在S3中以供后续部署。

4. 边缘部署

边缘设备（在我们的情况下，配置为g4dn.12xlarge，搭载4×NVIDIA T4 GPU，每块16 GiB，总加速器内存64 GiB，48个vCPU，129 GiB系统内存）提供了本地推理所需的GPU计算能力。硬件选择是直接影响模型可行性和服务策略的重要架构约束。由于gpt-oss-20b在每块T4 GPU上占用13 GB内存，根据吞吐量和延迟优先级，有两种部署策略可供选择：

• 模型复制 — 在四块GPU上各复制完整模型，支持四个并发客户端请求而无需排队。这以每块GPU内存中81%用于模型权重为代价，最大化吞吐量。
• 张量并行 — 模型在四块GPU间分片，每块GPU分配3.2 GB，每块GPU剩余约12.8 GB内存。剩余内存用作KV缓存，支持长文本交互所需的完整128K上下文窗口。

策略选择取决于工作负载特征：复制适合高并发、短查询环境，而张量并行适合并发用户较少但交互更复杂、更长的场景。

5. 边缘设备（制造工厂）

边缘设备（在我们的案例中，NVIDIA Jetson Xavier）提供了本地推理所需的GPU计算能力。硬件选型是重要的架构约束条件：你需要足够的显存（16 GB或更高）来运行量化后的SLM，这会直接影响哪些模型适用于你的部署场景。

6. 用户界面（Flask操作员门户）

基于Flask的网页界面在设备本地运行，允许维护操作员和技术人员提交关于设备问题、安全规程或维护任务的查询。在设备上运行UI可消除用户界面层对外部连接的依赖。

7. 离云端生成式AI

通过Ollama作为推理运行时，微调后的SLM在本地运行。Ollama提供轻量级、容器友好的服务层，支持量化模型格式（GGUF），在设备内存限制内实现高效推理。这将模型服务基础设施与任何云端依赖解耦。

8. 生成式AI编排

Strands Agents提供协调查询处理工作流的编排层。它将请求路由到合适的工具：查询本地RAG知识库、收集设备遥测数据。这种基于代理的模式提供了可扩展性。你可以添加新工具和数据源而无需修改核心推理管道。

9. 持续改进（反馈循环）

当网络连接可用时，用户交互和反馈会回传至云端，通过FMOps流水线实现模型持续优化。这形成良性循环：边缘使用数据改进下一版模型，Greengrass将新模型重新部署到设备。架构设计可抵御网络中断，反馈会在本地排队并择机同步。

先决条件

要实现类似方案，你需要：

• 一个AWS账户。如果你还没有AWS账户，可以创建一个。

• 你的AWS账户访问权限必须包含对Amazon SageMaker AI、Amazon Bedrock、AWS IoT Greengrass和Amazon S3等服务的IAM权限。

• 一台带有足够显存（>16 GB）的GPU的硬件设备，用于运行SLM。

实施概览

本节总结关键实施步骤。每个组件使用标准AWS服务配置：

• 数据准备 – Amazon Bedrock上的Amazon Nova Pro从原始文档生成结构化问答对，为SageMaker AI微调流水线生成训练数据。

• 模型微调 – SageMaker AI流水线使用生成的数据集对gpt-oss-20b进行QLoRA微调，然后将定制化模型文件存储到S3。

• 边缘部署 – AWS IoT Greengrass（或AWS Systems Manager）将量化模型（GGUF格式）传输到边缘设备。

• 本地推理 – Ollama通过领域特定的系统提示加载微调模型，限制响应为设备相关答案。

• 编排 – Strands Agents协调工作流，根据需要将查询路由到RAG知识库或遥测工具。

关于微调笔记本，请参考这个使用Amazon SageMaker AI微调SLM的示例笔记本。

安全考虑

将推理过程转移到边缘设备会改变安全边界。在云原生部署中，AWS负责管理大部分基础设施安全。而在边缘侧，您需要负责整个堆栈的安全，从物理设备访问到应用层控制。本节将概述在将此架构适配到您的环境时需要实施的安全控制措施。

身份验证与访问控制。Flask操作员门户运行在隔离设备上，但物理接近性不能替代身份验证。请与组织的身份提供商（SAML/OIDC）集成，或实施基于证书的双向TLS。实施基于角色的访问控制，确保操作员、管理员和维护人员仅能看到与其职责相关的接口。

静态数据加密。模型工件和ChromaDB向量数据库包含专有知识。使用全磁盘加密（例如Linux的LUKS或Windows的BitLocker）加密边缘设备的存储卷。通过AWS IoT Greengrass密钥管理器或设备上的硬件可信平台模块（TPM）管理加密密钥。

传输数据加密。边缘设备与AWS之间的所有通信（包括IoT Greengrass部署通道和反馈同步环路）必须使用TLS 1.2或更高版本。对于边缘组件之间的内部通信（Flask门户到Ollama，Strands Agents到ChromaDB），即使在回环接口上也要强制使用TLS，以防止本地拦截。

输入验证与提示防护。Strands Agents编排层从操作员接收自然语言输入。应用输入验证以拒绝格式错误或过长的查询。实施提示防护机制以检测和阻止提示注入尝试。在输出端应用内容过滤，防止模型泄露超出其预期范围的敏感信息。

网络隔离。将边缘组件划分为不同的网络区域：面向操作员的门户部署在周界网络，推理运行时部署在受限区域，云同步通道使用仅出站的隔离接口。使用防火墙规则确保仅允许预期流量在区域间流动。

IAM最小权限原则。在云端，管道中的每个AWS服务应使用自己的IAM角色，并仅限于其所需的最低权限。IoT Greengrass核心设备角色应仅访问其需要的特定S3前缀和IoT主题。SageMaker流水线执行角色不应具有访问生产S3存储桶的权限。

日志记录与监控。为所有云端服务启用AWS CloudTrail和Amazon CloudWatch。在边缘设备上，本地记录所有操作员查询、模型响应和同步事件。当网络连接可用时，将边缘日志转发至Amazon CloudWatch Logs或Amazon S3进行集中分析。为异常模式（如意外查询量、重复身份验证失败或未授权访问尝试）设置警报。

结果

我们使用30个领域特定的问题-答案对对微调后的gpt-oss-20b模型与基础模型进行了评估。两种配置均采用完整的RAG流程（ChromaDB + sentence-transformer嵌入模型）作为检索层。测试变量是：在相同检索上下文条件下，微调语言模型是否能提升生成质量。三位LLM评估者（通过Amazon Bedrock使用的Claude 4.5 Haiku和Claude 4.5 Sonnet，以及Amazon Nova Pro）根据准确性、完整性和相关性三个维度，在12分制评分标准下对响应结果进行评分。

LLM评估者

SLM

平均得分

Claude 4.5 Haiku

微调gpt-oss-20b + RAG

10.20/12（85%）

基础gpt-oss-20b + RAG

8.20/12（68.3%）

Claude 4.5 Sonnet

9.20/12（76.7%）

7.49/12（61.7%）

Nova Pro

9.90/12（82.5%）

基础gpt-oss-20b +RAG

8.70/12（72.5%）

这些结果支持了我们解决方案架构中提出的混合方法（FT + RAG），证明即使使用相对较小的微调数据集，也能在边缘端实现显著的性能提升。

清理

本架构中使用的AWS服务均为全托管服务，采用按需付费的计费模式，即您只需为实际调用次数付费。例外情况是Amazon S3中标签数据和微调模型的存储成本，如果未使用可考虑删除。

结论

本文介绍了使用AWS服务在边缘部署生成式AI的参考架构。演示的关键架构模式包括：

云端模型工厂 – 使用Amazon Bedrock进行自动化训练数据生成，结合Amazon SageMaker AI Pipelines实现可重复、版本化的模型定制，构建可扩展的FMOps工作流，将模型准备与部署过程解耦。

托管云到边缘桥接 – AWS IoT Greengrass提供部署编排层，处理模型打包、版本管理和生命周期管理，无需目标设备的持续连接。

自包含边缘推理栈 – 轻量级运行时（Ollama）与基于代理的编排框架（Strands Agents）结合，支持本地AI推理和可扩展的工具集成，所有操作均独立于云可用性。

反馈驱动的持续改进 – 异步反馈环在连接允许时将使用数据同步回云端，实现迭代模型优化而不干扰边缘操作。

这些模式的应用范围不仅限于制造领域。任何具有间歇性连接、严格延迟要求或数据本地化约束的环境（如海上能源、远程农业、交通运输、国防等）均可受益于这种架构方法。关键设计决策会因用例而异：选择合适的模型定制策略、根据模型需求确定边缘硬件规模，以及在RAG和微调之间进行取舍。整体集成模式保持一致。

与任何参考架构一样，我们建议在生产部署前进行安全审查。

要探索这种模式，可以考虑识别一个具有明确连接限制的用例，并从边缘硬件需求反向推导以选择模型定制策略。本文描述的混合（FT + RAG）方法在功能和复杂性之间提供了恰当的平衡。随着操作改进的验证，可以逐步扩展该方案。

准备好进一步探索了吗？参加 re:Invent 相关会议，了解以下内容：使用 AWS Serverless 实现智能制造业的实时洞察（CNS375），以及在工业自动化中边缘端实施智能体 AI（HMC317）。

关于作者

'"`