Managing enterprise AI at scale: Hosting, deployment patterns, and Day 2 operations

扩展企业级AI：托管、部署模式与第2天运维

Component | Article_teaser

2026年8月28日

8分钟阅读

人工智能

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架构的4层结构。在本文中，我们将讨论各层的运营方、工作负载运行位置（托管API、自托管或混合模式），以及Red Hat AI Enterprise如何将这4层整合为紧密耦合的生产AI系统。我们还将探讨RAG、微调和智能体的部署影响，以及第2天运维的相关考量。

托管API与自托管的对比

构建AI基础设施时，一个根本性选择是使用托管AI模型的API还是自行托管模型。这一决策直接影响我们之前讨论的架构，影响成本结构、数据隐私、运维复杂度以及扩展速度。

托管AI模型

托管AI模型通过OpenAI、Anthropic和Google等供应商的API访问。请求发送到其云基础设施，响应通常按令牌或请求计费。供应商负责运营第1至第3层基础设施。您的团队可选择区域、模型名称、层级和配额，但不管理GPU、权重存储、推理引擎或服务。集成点是供应商端点和API协议。

这种安排避免了服务的资本支出和第2天运维，但按令牌计费成本在规模扩大时可能迅速上升。除非供应商提供私有或区域条款，否则提示和输出通常会离开您的网络。可用性、定价、限流和模型更新仍由供应商控制。

自托管模型

自托管模型运行在您控制的基础设施上，可部署在本地或私有云中。您的团队负责运营第1至第3层，或将其委托给企业内部的托管Kubernetes或AI平台。模型构件通过下载或镜像获取，推理引擎部署在服务层后，监控、扩展、补丁和模型推广均由内部处理。数据和提示可保留在企业边界内，这对受监管的工作负载更有利。高流量时基础设施成本通常更可预测，但代价是需要GPU容量、平台技能和事件响应能力。

许多组织采用混合策略：对低风险或探索性工作负载使用托管API，对必须保留在其环境中的数据使用自托管模型。混合设计在每个工作负载都有明确托管选择和清晰流量路径时效果最佳，例如：出站到供应商API与调用内部推理路径、必要时使用私有链接，以及在使用托管模型进行推理时决定RAG检索存储和嵌入是否保留在企业侧。

当您选择自托管（无论是出于合规性、延迟、成本还是主权原因），仍然需要一个能够可靠实现四层系统架构的平台。对于已经采用 Red Hat 标准化方案的组织，Red Hat AI Enterprise 是一个完整的 AI 平台，它能够在您现有的基础设施上以生产级方式部署第 1 至第 4 层，而无需重新构建全新方案。

在 Red Hat AI Enterprise 中，Red Hat OpenShift 是用于 GPU 调度和多团队隔离的 Kubernetes 基础设施，而 Red Hat OpenShift AI 则负责模型生命周期管理、服务部署和智能体集成。OpenShift AI 内置了生产级推理能力，无需额外部署独立的服务组件即可获得可调用的模型端点。

计算与硬件

Red Hat OpenShift 解决了自托管模型时难以正确处理的操作问题：跨团队的 GPU 配额与隔离、混合加速器支持，以及将 AI 组件作为标准容器工作负载运行。这包括通过分区或时间切片共享单个 GPU，使小型工作负载无需各自独占完整设备。OpenShift AI 在同一集群或连接集群中运行推理服务、Model Context Protocol (MCP) 服务器、智能体框架、RAG 管道及相关服务。

模型存储与生命周期管理

在 Red Hat AI Enterprise 的 OpenShift AI 中，权重文件和相关构件通常存储在持久化存储中，推理引擎可从中拉取数据，常见方式是作为 ModelCar 镜像（以容器镜像形式打包的模型文件）的 Open Container Initiative (OCI) 镜像仓库，或配置好的对象存储位置。模型注册表构建在这些存储之上，用于记录版本、元数据和发布状态，使团队能够注册、追踪并部署已批准的构建版本，而非依赖非正式的共享文件夹。

此外，集中式模型目录帮助团队发现经过验证和优化的模型，并在这些构件注册和部署前，以受控方式开展实验。训练中心支持使用私有数据进行定制化，包括微调和强化学习风格的工作流（通过偏好或奖励信号改进行为），从而确保领域适应性始终在您掌控的平台上进行。

推理服务

这是 AI 基础设施堆栈第三层（推理与模型服务）的具体实现，OpenShift AI 提供了完整的解决方案。其模型服务在路由、健康检查、副本和与 GPU 容量对齐的自动扩缩容后部署推理引擎，为应用程序提供稳定且兼容 OpenAI 的端点。

该路径中的推理引擎通常采用 vLLM；对于需要大规模扩展的工作负载，llm-d（一个原生 Kubernetes 的分布式大语言模型推理堆栈）可扩展这一模式。Red Hat 将这些组件整合为 Red Hat AI Inference。在 OpenShift AI 上无需单独部署，因为服务平台已将这些引擎作为内置运行时提供；独立版本则面向在 OpenShift AI 之外运行推理的环境，例如 Red Hat Enterprise Linux (RHEL) 或其他 Kubernetes 平台。

OpenShift AI 上的模型服务结合底层 vLLM 引擎，通常是 AI 基础设施与应用程序之间的标准边界。边界上方的所有内容（如提示、RAG 编排和智能体）均以服务形式调用模型。

在将模型连接到企业数据和系统时，Red Hat AI Enterprise 覆盖了集成层（基础设施堆栈中的第4层）的两个方向，与 OpenShift AI 配合使用。

在系统到AI的路径上，我们提出了在共享模型端点上设置具备AI感知能力的前端门。在 Red Hat AI Enterprise 中，这个前端门并非额外需要操作的组件：OpenShift AI 通过 Red Hat Connectivity Link 集成了AI网关功能，使平台团队可以在服务路径上为每个团队设置访问权限、配额和令牌预算，采用模型即服务（MaaS）的模式。当推理在 OpenShift AI 之外运行时，Connectivity Link 可作为独立网关使用。

在AI到系统的路径上，产品组合强调具备治理能力的智能代理工作流。MCP 通过一组可在集群中部署的精选服务器实现操作化，使代理能够通过共享协议发现并调用已批准的工具。MCP 生命周期操作符将这些服务器作为工作负载进行部署和管理。

为了在这些服务器上提供统一的治理入口点，Connectivity Link 的 MCP 网关（目前处于技术预览阶段）集中处理身份验证、路由、联邦工具发现和工具级访问控制，这与面向模型推理的 Connectivity Link AI 网关是不同的。团队还可以通过脚手架和平台 MCP 服务器暴露自定义工具以及 OpenShift AI 资源，例如已批准的模型、工作台（交互式开发环境）和流水线运行。AI 安全防护机制增加了监控、性能跟踪和漂移检测（监控模型行为或数据随时间的变化），确保模型和输出在生产环境中保持可靠。

部署中的应用模式

本系列文章的第一篇《企业AI模型选择：平衡性能、隐私和运营适配》讨论了RAG、微调和智能代理工作流如何将模型与您的领域对齐。在生产环境中，问题不再仅仅是这些模式是什么，而是还需要运行和推广哪些其他内容。

RAG 是最明显的例子。推理可能使用托管API或自托管模型，但组织通常拥有嵌入式管道和检索索引，包括摄入能力、安全备份的存储以及对检索来源的访问控制。端到端延迟包含检索过程，而不仅仅是推理，推广检查通常涵盖检索质量以及最终答案。

微调带来了不同的负担。训练通常在与推理分离的GPU上以突发方式运行，除非需求稳定到可以共享；团队治理训练数据，按环境批准检查点，一旦上线，就将微调后的工件像其他服务模型一样进行运营。

智能代理更进一步。除了推理，它们还需要一个编排运行时和对系统的受控访问权限，通常是批准API或MCP工具的白名单，包含超时设置、审计调用以及对高影响操作的人工审批或策略控制。在将系统投入生产之前，团队会确认白名单有效，并确保被允许的工具在超时或出错时能够安全失败。

大多数生产环境设计会结合这些模式，例如使用指令微调模型配合RAG和小型工具集。因此，模型标识符、提示模板、检索索引版本和代理工具配置通常会被固定在一起，并作为一组组件在开发、测试和生产环境中统一推广。回滚操作会撤销一个单位的变更，而不是让你猜测是哪个组件发生了变化。

第二天运维

第二天运维是确保生产AI系统上线后保持稳定的关键。与任何企业服务一样，工作负载需要在推理和关键集成路径上对延迟、可用性和错误率有明确的目标。这些目标决定了容量规划。峰值并发量和令牌吞吐量比平均负载更重要，而自托管服务会引入托管API隐藏的约束条件，例如GPU内存限制、副本冷启动（新副本将模型加载到内存时的延迟）以及当需求超过舰队服务能力时产生的队列。

可观测性

可观测性是团队判断是否达成目标的依据。推理延迟、错误率、令牌使用量和队列深度可以显示服务本身是否健康。RAG增加了检索命中率和延迟的指标；代理则增加了与关联ID（将相关事件链接到一个用户或会话的共享标识符）绑定的工具调用日志。按应用、团队和模型分解的成本，使流量带来的财务和容量影响变得清晰可见，而不是埋没在单一供应商账单中。

故障与连续性规划

故障仍然会发生，且通常不在模型本身。托管API可能会超时或限流，GPU节点可能消失，糟糕的部署可能导致质量退化，代理依赖的上游工具也可能失效。提前规划这些情况的团队会定义降级模式，例如回退到较小的模型、提供缓存响应、在没有写工具的情况下仅读取运行代理，或临时禁用代理功能。连续性规划因托管模式而异。自托管环境通常需要注册表复制和备用集群或区域；托管API将正常运行时间责任转移给供应商，而应用级故障转移和索引及配置的备份仍需由你方负责。

安全与治理

安全与治理将相同的运维规范扩展到系统上线后“谁”和“什么”可以执行操作。代理通常使用服务账户而非个人凭证运行，每个工具都遵循最小权限原则，并通过验证限制注入和滥用行为，包括提示注入（精心设计的输入试图覆盖指令或窃取数据）。经过批准的模型和工具目录、按使用场景划分的风险等级（如内部助手与客户功能与自动化修复的对比），以及对高影响力自动化的审核关卡，可确保这些能力与现有变更管理保持一致，并在必要时获得人工批准。

选择一个功能强大的模型只是第一步。接下来关键的是，这个选择是否能够适应你的基础设施、托管模式以及负责运营的团队。一个在纸面上看起来合适的模型，如果无法被你的系统存储、服务或集成，可能在实践中并不现实。对于某些工作负载，托管 API 可能是一个良好的起点，但若数据必须保留在你的边界内，它可能不是长期的最佳选择。混合架构很常见；重要的是要明确流量路径、数据边界以及每一层的负责人。

将生产环境中的 AI 视为一个系统，而非单纯的模型端点。集成和稳态运营通常比模型选择更复杂。将模型标识符、提示词、检索索引和工具配置作为一组内容进行推广，并在系统投入生产前规划可观测性、故障模式和治理策略。

了解更多

• Red Hat AI Enterprise

• 免费试用 Red Hat AI Enterprise

Block | Dynamic pattern deluxe promo

Component | Band_header

Resource

适应性强的企业：为什么 AI 准备度就是应对变革的准备度

这本电子书由 Red Hat 首席运营官兼首席安全官 Michael Ferris 所著，帮助 IT 领导者应对当前面临的 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

Chad Zammar

Subpattern | social_links

Chad Zammar 是 Red Hat Ansible 自动化架构师，专精于使用 Ansible 和 OpenShift 进行 IT 和基础设施自动化。

他于 2005 年获得计算机科学博士学位，此后一直在软件工程和解决方案架构领域积极活跃。通过与多个行业公司的合作，他掌握了分布式系统、云架构与技术、数据工程、运筹学、AI、Web 技术、电信、虚拟现实和嵌入式系统等广泛的技术技能。

Chad 目前居住在蒙特利尔，闲暇时间喜欢徒步旅行、公路旅行、阅读纸质书籍或使用 Ansible 进行自动化。

更多该作者的文章

类似内容推荐

Dynamic pattern

Blog post

Ask Red Hat 如何在企业 AI 故障排除中赢得信任

在 AI 时代增强安全风险管理的 5 种方式

Original podcast

使用 PyTorch 标准化 AI 堆栈

技术讲解 | 用开源定义主权 AI

Subpattern | card_flex

Subpattern | text_basic

继续探索

• 什么是智能体 AI？文章

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

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

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

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

Keep Exploring mbox

Subpattern | simple_text

按频道浏览

探索所有频道

Pattern | raw_html

自动化

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

人工智能

平台更新，帮助客户在任何地方运行 AI 工作负载

混合云

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

安全

关于如何在各类环境和技术中降低风险的最新动态

边缘计算

关于简化边缘运算平台的最新动态

基础设施

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

应用

深入探讨我们如何应对最复杂的应用挑战

虚拟化

企业虚拟化的未来：无论是本地部署还是跨云环境，助力您的工作负载高效运行