模型即服务指南

人们对 AI 的兴趣与日俱增，企业组织迫切希望利用大语言模型（LLM）、预测性分析、视觉功能和其他高级工具来挖掘业务价值。然而，将 AI 从孤立实验推向广泛的企业组织采用，会带来重大的基础架构和运维挑战。

许多企业组织在开启 AI 之旅时，会先连接来自 OpenAI 或 Anthropic 等提供商的商业 LLM 应用编程接口（API），认为这是实现生产应用的最快方式。但随着使用量的增加，成本持续攀升，团队也面临数据隐私、可观测性和自定义方面的限制。在某些情况下，商业 AI 提供商还会在未充分预警的情况下更改模型，扰乱企业组织的业务运营。

对此，部分企业组织走向了另一个极端：从头开始构建自己的模型基础架构。这种自力更生的做法常常会导致团队各自为政地部署 Llama 或 Mistral 等开源模型，缺乏统筹协调，最终形成一个支离破碎的局面：各团队自行搭建技术栈，导致基础架构冗余、图形处理单元（GPU）闲置、运维开销激增，同时引发安全防护和治理问题，成本飙升，但未能带来多少业务价值。

近期，Llama、DeepSeek、Mistral、Qwen 等 LLM 的规模急剧膨胀，使得这些挑战愈发严峻。与几年前规模相对较小的 AI 模型不同，如今的大型模型可能需要 TB 级 vRAM，而这些 GPU 成本高昂。如果不能高效利用这些资源，会​迅速推高成本。当同一企业组织内的多个团队各自独立尝试部署这些模型时，情况则会变得更糟。这种分散的做法加剧了运维开销与支出。

企业组织需要采用一种内部方法来简化和整合模型的使用，优化硬件资源，并为不同的内部用户群体提供可控且可扩展的访问权限。若缺乏此类方法，AI 举措将面临采用率低和运维费用高的风险，基础架构投资仍然得不到充分利用，也难以实现可衡量的成果（例如提高生产力、降低运维成本或加快获得见解的速度）。

利用模型即服务（MaaS）方法，企业组织能够一次性部署 AI 模型，并将它们作为注重安全性的共享资源提供给整个企业。与为各个团队管理孤立部署的方式不同，MaaS 方法可协助公司集中管理 AI 基础架构和运维，简化内部 AI 采用。

实现集中式模型运维，提供对 AI 的共享访问

• 对于 AI 工程师而言，MaaS 通过 API 提供了一种更快捷的方法，可让他们轻松访问高性能模型，而无需下载模型、管理依赖项，或通过冗长的 IT 工单流程申请 GPU 分配。

MaaS 的运作机制是将 AI 运维团队设立为共享 AI 资源的中央所有者。模型部署在可扩展的平台（如红帽® OpenShift® AI 或其他类似平台）上，然后通过 API 网关进行公开。这种设置允许多个用户、开发人员和业务部门为最终用户提供简化的访问方式，同时满足 IT 和财务团队的首要安全防护和治理要求。这种机制可包含计费功能，无需直接的硬件访问权限或深厚的技术专业知识即可使用模型。其目标是让用户能够便捷地使用 AI 模型，而不是访问运行这些模型所需的资源，如 GPU 和张量处理单元（TPU）。在提供所有这些优势的同时，还能满足企业性能与合规要求，并且不会增加最终用户的访问复杂性。

在实际应用中，用户仅通过 API 获得模型所生成的响应并进行交互。正如公共 AI 提供商为最终用户降低硬件复杂性一样，内部 MaaS 部署也提供同样的简洁体验。用户无需直接管理硬件或软件基础架构、等待 IT 工单代其处理所需事宜，或者等待环境配置完成，而是由 IT 运维和 AI 团队集中管理模型生命周期、安全防护、更新和基础架构扩展，为用户提供精简且受控的访问权限。

这种集中式管理不仅简化了内部 AI 运维，还强化了安全防护与治理。通过 API 网关进行凭据管理，能够对 AI 模型的访问实施严格控制。企业组织可以轻松跟踪模型使用情况，建立内部计费机制，确保遵循隐私合规准则，并设定明确的运维边界，打造兼具可管理性与实用性的企业 AI。在令牌级别（输入和输出）跟踪使用情况是最准确、最精细的方式，其精确度远超 GPU 级别的任何指标。

控制使用、限制访问并管理成本

• 对于 IT 和平台工程师而言，他们可利用集中监督来防止未经授权的模型部署，强制执行安全防护与合规标准，并简化生命周期和基础架构管理。
• 对于财务团队而言，集中式使用情况跟踪和内部计费机制可减少资源浪费，实现更加可预测且可追溯的 GPU 使用，避免因分配给团队的专用硬件利用率不足而导致费用超支。

MaaS 主要通过将 API 网关与 AI 基础架构集成来实现控制，这使得团队能够在非常精细的层面上管理和监控 AI 使用。

传统 AI 部署常常存在无人管理或使用效率低下的问题，因为个人或团队会在缺乏集中监督的情况下独立部署模型。这种分散的做法可能会导致代价高昂的效率低下问题，造成 GPU 资源闲置或利用率不足。而将 API 网关置于 AI 基础架构的核心位置，可以在用户与模型之间创建一个受控的访问点。

这种设置有助于实现精确到单个令牌级别的使用情况跟踪。团队可以清晰掌握每个用户、团队或应用的资源消耗量，准确归因 GPU 和基础架构成本。例如，企业组织可以确定特定用户或应用是否在过度占用资源，并采取相应的纠正措施，例如限制使用或通过内部计费机制分摊成本。

API 网关提供的限流功能可确保性能稳定，防止资源耗尽。IT 团队可利用限流来管理访问强度，防止单一用户独占 GPU 资源或影响其他用户的性能体验。

此外，API 网关还提供细粒度的凭据管理和访问控制。内部用户可自主生成凭据来访问 AI 模型，从而减少管理负担。IT 团队还可在更短的时间内撤销或修改凭据，灵活响应不断变化的安全要求或使用模式。

这一切都意味着成本管理变得更加透明且具备可问责性。IT 团队可以将 GPU 和基础架构费用准确地分摊到实际使用资源的团队或业务部门。

支持任何模型、任何加速器和任何云平台

MaaS 方法的核心原则之一是控制。它使企业组织能够​自主筛选并部署广泛的 AI 模型，选择他们偏好的硬件加速器，并在现有的云或本地环境中运行。通过这种方法，企业组织可以根据自己的技术需求、安全要求和运维偏好，自由、准确地实施 AI。

• 企业组织在采用 AI 时面临诸多严格限制，通常表现为：
  • 受限于特定云服务。
  • 被专有模型生态系统所束缚。
  • 受制于固定的硬件基础架构。
• MaaS 可通过多种方式突破这些限制，包括：
  • 支持开源或专有模型、定制训练模型以及 Llama 和 Mistral 等热门 LLM。
  • 突破基于文本的模型范畴，涵盖预测性分析、计算机视觉、音频转录工具以及图像或视频生成等其他多模态生成式 AI 用例。
• MaaS 不依赖于硬件加速器，因此：
  • 企业组织可以选择符合其工作负载、成本结构和性能需求的 GPU 或其他加速器。
  • 集中式 AI 团队可以做出关键的规模调整和部署决策，从而提高效率，减少技术基础较弱的用户所犯的错误。
• 集中管理有助于：
  • 优化基础架构的分配和使用。
  • 降低运维开销，防止资源配置错误。
• MaaS 支持在任何环境中进行部署，包括：
  • 本地、混合云、隔离环境和公共云，对于需要实现数据主权、监管合规性或严格安全控制的受严格监管的行业而言，这一点尤其有价值。

红帽通过集中处理 AI 模型的部署和访问，在内部采用了 MaaS。我们的内部 AI 团队使用红帽 OpenShift 和红帽 OpenShift AI 作为底层平台，集中管理 AI 资源和模型运维。这种集中式模型部署在整个企业组织内简化了用户对 AI 的使用，使开发人员和业务团队能够高效地将 AI 功能集成到其工作流中，而无需具备专用硬件或深厚的技术专业知识。

我们的实施采用可扩展的服务架构，该架构在 OpenShift AI 中使用 GPU，并通过集中式 API 网关连接用户，从而实现受控、安全至上且可追溯的 AI 模型访问。通过基于令牌的监控，我们可以精细管理使用情况，以便精确跟踪使用模型的人员、使用频率和使用量。这样一来，我们可以优化硬件使用，减少不必要的 GPU 资源消耗，并获得详细见解，以便在不同的内部团队或项目之间准确分摊成本。

我们的 MaaS 实施采用 GitOps 工作流，具备高可用性和可靠性。这种运维方法可减少人工干预和潜在错误，实现对 AI 部署的清晰管控。

我们内部 MaaS 实施的一个关键优势是显著提升了资源利用效率和用户体验。通过实施 MaaS，多个团队无需独立置备 GPU 和部署模型，从而消除了重复工作，简化了内部运维，并大幅缩短了价值实现时间。新模型通过测试和验证后，红帽团队可以立即集成并使用这些模型，而不会因为硬件分配或置备任务而耽误时间。

准备好简化 AI 交付并释放基础架构投资的真正价值了吗？首先查看我们的 MaaS 深度介绍，进一步了解 MaaS 的工作原理。然后，浏览 OpenShift AI 产品页面，评估平台功能和 GPU 使用指导。

对于在内部构建 MaaS 的团队，红帽咨询可帮助企业组织量身设计并实施符合其需求的模型服务环境。如需了解更多信息，请访问面向 AI 的红帽咨询页面。

想要更全面地了解真实示例？观看我们的点播式网络培训课堂系列，其中包括 MaaS 专题会议。