Why self-hosted inference is essential: Building a reliable, sovereign inference layer

为什么自托管推理至关重要：构建可靠且主权的推理层

Component | Article_teaser

2026年7月30日

8分钟阅读

人工智能

Richard Naszcyniec

AI技术产品营销总监

Joshua Wilson

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

您的代理可以访问其工具。身份范围有限。治理措施已就绪。如果代理背后的模型无法可靠地调用这些工具，所有这些都不重要。

我曾亲眼目睹这种情况的发生。一个团队在LangChain或CrewAI上构建代理。它在开发阶段运行正常。它通过了测试阶段。然后有人提出了一个显而易见的问题：推理实际在何处运行？几乎每次的答案都是第三方托管API——OpenAI、Anthropic或Google。不是因为团队更喜欢这种方式，而是因为运行在他们自己基础设施上的开源模型对于代理工作负载来说不够可靠。框架处理编排，托管API处理推理，两者都不在组织的控制之下。

这创造了主权困境。同一家致力于数据主权的企业——因为合规性或法规要求——却将每个提示、每个工具调用和每个推理步骤都路由到他人的数据中心。

在我们之前的讨论中，我们曾描述过单个AI代理部署在一夜之间遭遇的三个失败案例——43个重复工单、错误账户被收取4000美元费用，以及一个虚构的退款政策导致公司不得不兑现280美元的退款。这些失败的发生是因为生产基础设施缺失——开发阶段正常运行的代理与生产就绪部署之间的差距是一个基础设施问题。如果推理层也超出你的控制范围，这个差距就不是运营问题，而是管辖权问题。

BYOA（自带代理）是红帽AI的解决方案。该平台为任何代理框架提供生产基础设施，无需代码更改。但如果推理层削弱了平台保护的主权，这个故事就会开始出现裂痕。本文将介绍红帽如何帮助弥合这一裂痕。

聊天是宽容的。代理则不是。

大多数企业最初从聊天开始。用户提出问题，模型给出回答。单次交互，无状态。如果回答略有偏差，用户会重新表述并再次尝试。这种交互模式内置了优雅的降级处理。

代理工作负载在每个维度上都打破了这一假设。一个进行多轮决策的代理——规划步骤、调用工具、评估结果、修订方法——需要模型以工具完全预期的模式生成工具调用。在六步工具调用序列中，一个格式错误的JSON对象不会产生模糊的错误答案，而是会彻底破坏整个工作流程。工具调用失败。代理会重试（如果还记得凌晨6点的事件，就会生成43个重复工单）。更糟糕的是，代理可能静默生成错误输出——比如告诉客户退款窗口是90天，而实际政策是30天。

可以这样理解：聊天是一场对话，而代理是一份合同。对话可以容忍歧义，但合同不能。当模型生成工具调用时，它不是在建议一个动作，而是在执行一个动作。精确度的门槛截然不同。

这正是为什么大多数企业默认使用托管的前沿模型来处理代理工作负载。最佳托管模型与本地运行的开源权重模型之间的可靠性差距已足够显著，以至于企业认为必须做出主权妥协。对决策者而言，这种妥协意味着每次代理交互生成的数据都位于你无法控制的司法管辖区内。对开发者而言，这意味着部署架构无法承受API弃用通知的冲击。

vLLM 的变革

这种可靠性差距并非不可逾越。它是一个工程问题，而 Red Hat 正在系统性地缩小这一差距。

vLLM（Red Hat AI 的自托管推理引擎）现已在 Red Hat OpenShift AI 上正式发布。它是代理堆栈的基础。如果推理无法满足代理工作负载的需求，其上层的身份、治理和连接能力都将失去根基。

开源权重模型在工具调用中的不可靠性有三个具体原因，Red Hat 正在逐一解决。

智能默认值解决了配置问题。过去，为代理工作负载运行开源权重模型需要手动调整——选择解析器、设置温度参数、定义工具调用格式。任何一项配置错误都会导致工具调用以难以诊断的方式失败。vLLM 为代理工作负载预置了经过验证的配置，使工具调用在首次部署时即可正确运行。无需手动调整。开发者只需将代理指向 vLLM 端点，即可获得可靠的工具调用行为，而无需成为推理配置专家。

多轮对话强化解决了误差累积问题。在多轮代理循环（规划、调用、评估、修订）中，各轮次之间微小的 token 处理不一致会逐渐累积。到第 4 或第 5 轮时，模型将基于退化的上下文运行。vLLM 的多轮对话强化技术能减少复杂代理工作流中的累积误差。对决策者而言，这决定了代理在演示环境（1-2 次工具调用）和生产环境（数分钟或数小时内数十次调用）中的表现差异。

模型分层（将模型能力与任务复杂度匹配）解决了成本和延迟问题。一个能力强大的编排模型负责规划和协调，而小型专业模型负责执行任务——工具调用、数据检索、代码生成。我发现这个概念最能引起决策者的共鸣：你不是在昂贵模型和廉价模型之间做选择，而是在工作流中每个任务上运行最适合的模型。所有本地部署，全部由你掌控。

随着每项强化功能的发布，vLLM 的基准测试结果都会与托管前沿模型保持同步。目标不是实现理论上的性能对等，而是达到企业代理工作负载所需的特定可靠性阈值。

编写代码胜过编写 JSON

智能默认值和多轮对话强化改进了模型生成工具调用的方式。但还有一个更根本的解决方案——它彻底改变了工具调用的格式。

JSON 工具调用要求模型为每次工具调用生成精确的格式化模式。这种格式非常严格。缺少一个括号、类型错误或字段多余都会导致调用失败。当工具模式发生变化（而它们确实会变化）时，模型必须完美生成更新后的结构。没有部分得分的余地。

代码即操作（Code-as-Actions，一种让代理通过编写Python代码调用工具，而非生成JSON工具调用模式的方法）完全规避了这一问题。与其要求模型生成严格的JSON结构，不如让代理编写Python代码来调用工具。这种方法充分发挥了开源权重模型在代码生成方面的优势，而非强迫它们使用小偏差就会导致失败的格式。

我没想到这种模式会如此迅速地出现。Cloudflare、Anthropic和Pydantic三家机构独立得出了代码即操作的结论。当三家拥有不同代码库、不同模型选择和不同使用场景的组织都得出相同的架构结论时，这是一个值得重视的信号。这种技术趋同也验证了该方法的可行性：这不是红帽的实验，而是行业的发展方向。

对开发者而言，代码即操作消除了解析器维护的负担。无需编写处理不同工具模式的定制代码，模式变更时也不会出现脆弱性。在自主权方面，代码即操作使开源权重模型能够弥补与托管前沿API之间的可靠性差距，而无需将敏感数据传输到外部。

掌控API协议，而不仅仅是模型权重

可靠的推理和可靠的工具调用解决了性能问题。但还有一个大多数团队在投入后才意识到的锁定风险：API协议本身。

基于OpenAI Responses API构建的代理依赖于OpenAI的模式、行为和可用性。开发者编写代理时是按照OpenAI的协议进行的。如果OpenAI调整定价、弃用接口或改变行为，组织将不得不接受这些变更——按照OpenAI的时间表，而非自己的时间表。迁移到不同后端意味着需要重写代理的集成层。对于运行数十个代理的组织而言，这种重写绝非周末项目。

Open Responses（Open GenAI Stack（OGX）是红帽AI的服务器端代理循环，此前称为Llama Stack，实现了OpenAI Responses API规范）直接解决了这个问题。基于OpenAI Responses API构建的代理只需进行少量代码修改，即可指向OGX端点。相同的API协议，不同的后端。端点后端运行的模型可以是Llama、Granite或您基础设施上运行的任何开源权重模型。

可移植性原则贯穿于所有API接口。vLLM已经提供了符合OpenAI Chat Completions标准的端点。Open Responses在Responses API格式中增加了状态管理和工具调用功能。Anthropic Messages API和Google Interactions API前端支持正在路线图中——使用Claude Agents或Google ADK的组织将能够将代理指向自托管基础设施，而无需重写代理代码。

对于希望使用内置速率限制和策略执行的托管基础设施的团队，模型即服务（MaaS，目前处于技术预览阶段）提供了第三种推理路径——基于OpenShift AI的托管模型服务平台，集成Gateway API和Connectivity Link。结合vLLM（直接集群部署）、OGX（代理循环）和MaaS（托管），组织可以在完全自托管和平台托管之间获得控制权的完整光谱，所有接口均兼容OpenAI API。要对这三种路径进行实际对比，请参见《使用红帽AI部署代理：红帽开发者上OpenClaw的奇特案例》。

我需要明确说明这是什么，以及它不是什么。OGX实现了与OpenAI、Anthropic和Google（这些是专有供应商，而非开放标准组织）的兼容API。这并不意味着对API规范本身的主权控制，而是对后端的主权控制：您的基础设施、您的模型、您的数据。API契约变得可移植。组织可以自主决定是否以及何时吸收上游变更。对于评估供应商风险的决策者而言，这种区别——在不控制标准的情况下控制实现——才是真正重要的技术主权形式。

在推理边界处，主权实际表现为何样

从推理视角来看6 AM事件中幻觉生成的退款政策会呈现何种样貌。代理生成了一个90天的退款窗口，而实际政策是30天。一位客户在第47天退回了价值280美元的产品，并引用了代理的回应。团队接受了退货。随后因AI代理未经授权做出合同性陈述而引发法律风险。

现在比较两种场景。在第一种场景中，代理通过托管API运行。该生成的输出及对话中的客户数据（客户姓名、购买历史、产品详情）都传输到了第三方数据中心并返回。故障在组织无法控制的司法管辖区内生成了数据。事件响应需要与API提供商协调。审计轨迹取决于提供商保留和共享的内容。

在第二种场景中，代理在组织自身基础设施上的vLLM上运行。故障仍然发生——自托管推理无法防止幻觉输出（这正是推理边界处的防护措施要解决的问题，如“为何仅靠提示级防护不足”中所述）。但故障发生在组织边界内部。提示、生成的输出和客户数据从未离开。审计轨迹完整。事件响应遵循内部流程。监管报告仍由组织控制。

这就是在推理边界处数据主权的含义。不是防止故障——而是防止故障生成无法追溯的数据。

确认主权支持（在美国和欧盟一般可用）将这一原则扩展到支持链。当组织需要帮助处理推理问题时，支持交互本身不会跨越司法管辖区边界。

主权不是产品特性。它是整个堆栈的属性——推理运行的位置、谁控制API契约、凭证如何流动、审计轨迹捕获的内容。当您控制推理层时，您不仅是在运行模型，更是在决定数据存储的位置、适用的法律以及谁可以访问数据。这与“哪个模型最便宜”的讨论是完全不同的议题。

推理层是可靠的。主权故事是连贯的。但这两个方面都无法回答一个关键问题：如何确认运行在该基础设施上的代理实际上是否在工作？我们将在下一篇文章中探讨这个问题。

入门

准备好按照自己的条件运行推理了吗？

• 在开发者沙箱中免费试用OpenShift AI：在预配置环境中部署和测试vLLM推理

• 体验Red Hat AI交互式演示：通过OpenAI兼容端点提供开源权重模型

• 阅读 Red Hat AI 文档：智能默认设置、模型分层与工具调用配置

• 探索 Red Hat AI 开发者资源：vLLM、OGX 和 Granite 的试用版、演示和上游项目链接

• 开始 OpenShift AI 学习路径：从模型服务到推理优化的动手教程

• 进行数字主权准备度评估：建立组织的主权基准线

Block | Dynamic pattern deluxe promo

Component | Band_header

Resource

开始使用 AI 推理

了解如何构建更智能、更高效的 AI 推理系统。学习量化、稀疏性以及 vLLM 等 Red Hat 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

Richard Naszcyniec

Subpattern | social_links

在 Sybase、Siebel Systems、Oracle、IBM 和 Red Hat（自 2012 年起）等公司拥有三十多年软件行业经验，目前担任 AI 技术架构师和 AI 未来学家。在 Red Hat 工作期间，我曾领导团队通过战略销售策略提升全球销售业绩，此前还负责 Application Services（中间件）业务单元的技术竞争营销。如今，我的使命是揭开 AI 架构的神秘面纱，帮助专业人士和组织理解 AI 如何创造商业价值、推动创新并有效集成到软件解决方案中。我利用丰富的经验，指导 AI 的战略实施，工作重点是解释 AI 架构的组成部分、实际应用方式以及如何转化为具体的商业价值，例如获得竞争优势、差异化优势和通过简单创新方案提升客户满意度。我热衷于赋能企业不仅利用 AI 预测未来技术格局，更主动塑造未来。同时，我也致力于推广 AI 的负责任使用，帮助每个人实现超越以往的成就。

更多该作者的文章

Joshua Wilson

类似内容推荐

Dynamic pattern

Blog post

介绍 asago：开源 AI 安全与治理编排

Red Hat OpenShift 机密计算和沙箱功能的新进展

原始播客

技术讨论 | 用开源定义主权 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平台最新动态

应用程序

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

虚拟化

适用于本地部署或跨云环境的企业虚拟化未来