Beyond the model: Architecting production-grade enterprise AI systems

超越模型：构建生产级企业AI系统

Component | Article_teaser

2026年8月27日

6分钟阅读

人工智能

Chad Zammar

Ansible自动化架构师

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：托管、部署模式和第2日运营》将讨论各层的运营责任划分，从托管API与自托管的对比，到容量规划、扩展性及第2日运营。如果您尚未确定模型候选名单，或想了解如何在构建模型前进行模型对比，我们之前的《企业AI模型选择：平衡性能、隐私与运营适配》已涵盖这些背景内容。

企业AI基础设施

下文描述的架构列出了所有生产级AI能力依赖的4层结构，从硬件到企业集成。您运营哪些层级取决于托管选择。使用托管模型API时，供应商通常负责运行1至3层（计算、模型存储及推理和模型服务），您只需在顶层集成应用程序。采用自托管模型时，您需要自行在本地环境中部署或委派这些层级。无论哪种情况，集成（第4层）始终是您的责任。

第1层：计算与硬件

计算和硬件构成基础。每个推理请求最终都要在处理器和加速器上执行，对于大型语言模型（LLMs）和大多数生成式工作负载而言，这意味着需要使用GPU或类似加速器，因为底层的矩阵运算在CPU上无法高效扩展。

自托管推理通常在数据中心的GPU服务器或云端的GPU实例上运行，通过企业级Kubernetes平台（如配备GPU操作符的Red Hat OpenShift）进行调度和隔离。该层级的规模直接取决于您选定的模型和预期的生产并发量。更大的模型需要每个实例更多的设备内存，而更多的同时用户则需要更多的副本或更大的设备。当容量不足时，用户会遇到延迟增加、请求被限流或排队等待，而非立即得到响应。

如果通过托管 API 提供推理服务，供应商会为模型本身运营这一层的大部分功能。您的环境仍然需要计算资源来处理周边工作负载，包括应用程序服务、检索增强生成（RAG）的嵌入和数据摄入作业，以及为检索和集成提供支持的数据存储。

第 2 层：模型存储

模型存储保存推理引擎在运行时加载的模型文件。一个完整的软件包通常包括权重文件、分词器词表（用于将文本转换为标记的映射关系），以及描述架构和部署设置的配置信息。存储容量需求直接取决于您最终选定的模型。更高的参数数量和更高的数值精度会增加磁盘占用空间和启动加载时间；而量化版本的模型则能减少这两方面的开销。

对于自托管部署，权重文件通常存储在持久化块存储或对象存储中（例如 S3、MinIO 或版本化的 Open Container Initiative（OCI）镜像）。运行时，推理引擎通过服务启动时获取文件，或从已包含该软件包的附加存储中读取文件来加载权重。网络带宽、存储凭证和存储的复制策略会影响新实例准备就绪的速度，以及相同构建版本从测试环境迁移至生产环境的可靠性。当多个模型同时处于生产环境时，应为每个环境维护一个受控的批准检查点目录，避免依赖非正式的共享文件夹进行操作、合规性和成本跟踪。

第 3 层：推理与模型服务

推理是训练好的模型消耗输入并返回输出的步骤，输出可以是生成的文本、分类结果或嵌入向量。在生产环境中，这一步通常会拆分为两个容易混淆的相关部分。

推理引擎执行模型：它将权重加载到加速器内存中，对输入进行分词，对请求进行批处理，流式传输标记，并通过限制并发数确保多个客户端可以共享一个模型而不影响稳定性。广泛使用的开源推理引擎包括 vLLM、Text Generation Inference 和适用于本地开发的 Ollama。

大多数引擎都提供兼容 OpenAI 的 HTTP API（例如 /v1/chat/completions），这让应用团队可以通过熟悉的接口调用模型，而无需依赖单一供应商的 SDK。在 Red Hat 方面，Red Hat AI Inference 是支持该引擎和运行时层的官方解决方案，其核心基于 vLLM。该方案可以独立部署，但相同的功能也已内置于 Red Hat AI Enterprise 中，因此选择该平台作为标准的团队已无需额外处理这一层。

模型服务是该引擎成为生产服务的方式：包括路由、健康检查、副本管理和与 GPU 资源匹配的自动扩缩容。服务层构建在引擎之上而非替代引擎。我们下一篇文章将介绍 Red Hat AI Enterprise 如何在 Red Hat OpenShift AI 上实现这一服务层。

这一层之上的一切（如提示工程、RAG 编排和代理系统）都会将模型视为可调用的服务。

第 4 层：与现有生态系统的集成

一旦模型可以通过 API 访问，就需要将其连接到企业其他部分：数据库、内部服务、工单系统、监控系统、身份提供商和业务逻辑。这正是 AI 从独立能力转变为应用架构组成部分的关键环节。

在实际应用中，集成层是企业复杂性的主要所在，从身份验证和授权到审计日志、速率限制和数据转换。在规划AI部署时，这一层最容易被低估。

集成是双向进行的，调用方向不同会导致复杂性差异显著。

从系统到AI

您的应用程序向托管模型端点发送请求并获取响应。在这一方向上，模型处于被动状态：它处理接收到的内容并返回结果。这种模式是聊天机器人、内容生成以及大多数请求/响应AI功能（包括RAG）的基础。

在安全性方面，您的服务保留凭证和数据访问权限，而非模型本身，模型仅能看到您包含在每个请求中的内容。同样，只要您的应用程序而非模型决定流程顺序，代码协调的多步骤工作流（如先分类后总结或流式聊天）也遵循这一模式。

集成通常通过HTTP调用兼容OpenAI的推理API实现，包含提示模板和上下文管理。生产环境仍需超时设置、重试机制、成本控制以及对请求和结果的审计日志。当多个内部系统共享一个模型端点时，AI感知的网关可以在服务端强制实施身份验证、配额、基于令牌的速率限制以及针对推理流量的可观察性，而非将模型视为通用HTTP API。

Red Hat Connectivity Link 为Kubernetes和Red Hat OpenShift 提供原生AI网关能力。

从AI到系统

此处的流程方向相反。模型或其周围的代理框架通过查询数据库、创建工单、调用内部API或读取文档存储等方式主动联系您的系统。它决定使用哪个工具，构建调用，解释结果，并可能在规划循环中串联多个调用。这种模式是代理AI、自主工作流和使用工具的助手的基础。

生产环境集成需要工具发现、身份验证、输入验证、错误处理以及防止意外操作的防护措施。如果没有标准化的工具暴露方式，每个代理到系统的连接都将成为与特定框架和API形状绑定的定制化集成。模型上下文协议（Model Context Protocol，MCP）解决了这一缺口。您通过MCP服务器发布能力，代理通过共享协议发现并调用这些能力，因此相同工具可以跨兼容MCP的代理和模型提供商使用。在企业级规模下，这些服务器仍需要一个受控的前端门禁，提供联合发现、基于身份的工具过滤和审计功能，而非让每个代理直接连接到每个MCP端点。Red Hat Connectivity Link 正在为Red Hat OpenShift 添加MCP网关（目前处于技术预览阶段），与面向模型推理的原生AI网关形成互补。

结论

The 4 layers in this article work as a checklist for any model you plan to run: compute to execute it, storage to hold and version its artifacts, an engine and serving layer to expose it as a stable endpoint, and integration in both directions with the systems around it. The architecture itself doesn't change with your hosting choice, what changes is who operates each layer. A managed API hands layers 1 through 3 to the vendor, self-hosting keeps them on your estate, and integration remains yours either way.

When you standardize on Red Hat for either self-hosted or hybrid AI, Red Hat AI Enterprise provides all 4 layers of this architecture which you can run on infrastructure you already have rather than having to build something new. The next article in this series, Managing enterprise AI at scale: Hosting, deployment patterns, and Day 2 operations , covers how that platform implements each layer, hosting considerations, and Day 2 operations.

Block | Dynamic pattern deluxe promo

Component | Band_header

Resource

The adaptable enterprise: Why AI readiness is disruption readiness

This e-book, written by Michael Ferris, Red Hat COO and CSO, navigates the pace of change and technological disruption with AI that faces IT leaders today.

Component | spacer

Component | Cta_multi_basic

Subpattern | simple_cta

Component | CTA

Get the resource

Deluxe mbox

Component | Card_header

About the author

Subpattern | speaker

Card layout

Component | Image_embed

Component | Person

Chad Zammar

Subpattern | social_links

Chad Zammar is a Red Hat Ansible Automation Architect specialized in IT and Infrastructure automation with Ansible and OpenShift.

He earned his PhD in Computer Science in 2005 and has since been very active in the field of software engineering and solutions architecture. He acquired a wide range of technical skills through engagements with companies in diverse sectors, including but not limited to distributed systems, cloud architecture and technologies, data engineering, operations research, AI, web technologies, telecommunications, virtual reality, and embedded systems.

Chad lives in Montreal where he is either hiking, road tripping, reading a paper-based book or automating something with Ansible.

More from this author

More like this

Dynamic pattern

Blog post

How Ask Red Hat earns trust in enterprise AI troubleshooting

5 ways to augment security risk management in the AI era

Original podcast

Standardizing the AI stack with PyTorch

Technically Speaking | Defining sovereign AI with open source

Subpattern | card_flex

Subpattern | text_basic

Keep exploring

• What is agentic AI? Article

• Predictive AI vs. generative AI Article

• Top considerations for building a production-ready AI/ML environment E-book

• Generative AI, the Ansible way Video

• Innovate and transform with a modern application platform E-book

Keep Exploring mbox

Subpattern | simple_text

Browse by channel

Explore all channels

Pattern | raw_html

Automation

The latest on IT automation for tech, teams, and environments

Artificial intelligence

Updates on the platforms that free customers to run AI workloads anywhere

Open hybrid cloud

Explore how we build a more flexible future with hybrid cloud

Security

The latest on how we reduce risks across environments and technologies

Edge computing

Updates on the platforms that simplify operations at the edge

Infrastructure

世界领先的Linux平台最新动态

应用

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

虚拟化

企业虚拟化的未来，无论是本地部署还是跨云环境中的工作负载