基于IBM LinuxONE的Spyre加速检索增强生成：一种安全、高通量企业AI推理的云原生架构

# 基于 IBM LinuxONE 的 Spyre 加速检索增强生成：面向安全、高通量企业 AI 推理的云原生架构
来源：https://arxiv.org/html/2608.21393

###### 摘要

在企业环境中运行大型语言模型一直面临一道现实壁垒：数据存储在一处，AI 算力位于另一处，而将敏感记录在两者之间移动会带来延迟、安全性和监管风险方面的实际难题。IBM 的 Spyre 加速器——一款为 LinuxONE 及更广泛的 IBM Z 系列构建的 PCIe 推理卡——改变了这一等式。在本文中，我们设计了一套完全运行于 IBM LinuxONE 上的六子系统 RAG 架构，使用 Spyre 进行生成式推理，利用 Telum II 片上加速器处理轻量级分类任务，并通过 Red Hat OpenShift 进行容器编排。整个流程——从查询接收、向量检索、提示组装、LLM 推理、合规过滤到响应交付——全部保持在单个 LinuxONE 系统内，因此敏感数据永远无需离开硬件边界。我们逐步阐述了每个子系统的设计选择，深入探讨了 Spyre 的编译与服务栈，解释了 LinuxONE 的 Secure Execution 技术如何将机密计算保障扩展到 AI 工作负载，并针对云 GPU 和本地替代方案对该架构进行了基准测试。初步分析显示，端到端 RAG 延迟低于两秒，相比平台外推理可减少高达 20 倍，同时满足了受监管行业实际所需的强加密和可审计性要求。

关键词：IBM LinuxONE，IBM Spyre 加速器，检索增强生成，大型语言模型，机密计算，云原生 AI，watsonx，Red Hat OpenShift，企业 AI

## 1 引言

与任何大型银行或保险公司的首席技术官谈论生成式 AI，对话很快会从“它能做什么？”转向“数据流向哪里？”。这个看似简单的问题，已经阻碍了无数生产部署。能够回答复杂问题、总结冗长政策文件或起草客户信函的模型，往往运行在云端 GPU 集群上。将企业数据传输到这些集群意味着要对其进行序列化、加密传输、通过网络推送、在另一端解密、运行推理，然后逆转整个过程。每一步都增加延迟。每一步都是潜在的合规风险。对于受 GDPR、DORA、HIPAA 或日益增多的数据驻留法规约束的组织而言，每一步都需要独立的审计跟踪和风险评估 [2 (https://arxiv.org/html/2608.21393#bib.bib2), 3 (https://arxiv.org/html/2608.21393#bib.bib3)]。

IBM LinuxONE 提供了摆脱这一困境的途径。它是一个仅支持 Linux 的服务器平台——无需专有操作系统——恰好具备一些独特的硬件特性：内置到每个数据路径的加密引擎、一种名为 Secure Execution 的机密计算能力（可将系统管理员也排除在外），以及足够的垂直扩展能力，可将原本需要一整排商品服务器才能处理的工作整合到单个机箱中 [1 (https://arxiv.org/html/2608.21393#bib.bib1), 6 (https://arxiv.org/html/2608.21393#bib.bib6)]。随着 2025 年 Spyre 加速卡的推出，LinuxONE 获得了先前所缺乏的能力：能够在本平台上运行数十亿参数的语言模型，而无需将推理任务分发到外部 GPU [4 (https://arxiv.org/html/2608.21393#bib.bib4)]。

正是这一硬件转变促使了本文的写作。我们着手设计一个 RAG 流水线——输入查询，输出有依据的答案——该流水线在 LinuxONE 上使用 Spyre 端到端运行，位于标准 OpenShift 集群内，并使用 IBM Granite 模型家族。目标非常具体：对典型 200 个 token 的答案实现低于两秒的响应时间、零数据出口、完全兼容欧盟 AI 法案要求的审计跟踪，以及平台团队可以使用熟悉的 Kubernetes 工具实际运维的架构。

本文其余部分组织如下：第 2 节 (https://arxiv.org/html/2608.21393#S2) 涵盖技术背景——RAG 基础、LinuxONE 硬件以及 Spyre 加速器在 IBM AI 路线图中的位置。第 3 节 (https://arxiv.org/html/2608.21393#S3) 详细介绍了我们架构中的六个子系统。第 4 节 (https://arxiv.org/html/2608.21393#S4) 深入探讨 Spyre 的软硬件栈及其对推理性能的影响。第 5 节 (https://arxiv.org/html/2608.21393#S5) 涉及安全和机密计算。第 6 节 (https://arxiv.org/html/2608.21393#S6) 对我们的方法与替代方案进行了基准测试。第 7 节 (https://arxiv.org/html/2608.21393#S7) 提供了实用的部署建议，第 8 节 (https://arxiv.org/html/2608.21393#S8) 则坦诚地讨论了当前的局限性，随后是总结。

## 2 背景与相关工作

### 2.1 RAG 如何工作及其重要性

检索增强生成背后的核心思想很简单：不是让语言模型纯粹基于训练时记忆的内容来回答问题，而是首先从一个可信的知识库中查找相关信息，并将其与问题一起交给模型 [7 (https://arxiv.org/html/2608.21393#bib.bib7)]。然后，模型生成一个理想情况下基于检索到的证据而非凭空捏造听起来合理的胡言乱语的响应。

实践中，检索步骤通常涉及将用户查询编码为稠密向量，将其与存储在向量数据库中的文档块的预计算嵌入进行比较，并取回最相似的 top-k 段落。近期研究表明，通过 RRF 等排序融合技术将稠密检索与传统关键词搜索 (BM25) 结合，往往比单独使用任何一种方法效果更好 [13 (https://arxiv.org/html/2608.21393#bib.bib13), 8 (https://arxiv.org/html/2608.21393#bib.bib8)]。在此初始检索之上进行交叉编码器重排可以进一步提高相关性，尽管会增加一点延迟。检索到的段落随后与系统指令和对话历史一起拼接成提示模板，然后输入 LLM。

有趣之处——也是我们工作的切入点——在于部署环境。大多数已发表的 RAG 架构隐含地假设向量数据库、应用服务器和 LLM 可以通过快速网络相互通信，并且 LLM 位于某个 GPU 集群上。当知识库包含不能离开特定物理边界的受监管数据时，这个假设就不成立了。

### 2.2 IBM LinuxONE：并非传统意义上的大型机

人们一听到“IBM Z 架构”就立刻联想到绿屏和 COBOL。LinuxONE 值得一个更清晰的介绍。它运行 Linux——Ubuntu、SUSE、Red Hat——而且仅此而已。没有 z/OS 选项，没有 CICS，没有 IMS。开发者使用 Python、Java、Go 或任何他们喜欢的语言编写代码。应用作为容器部署在 OpenShift 或原生 Kubernetes 上。从软件角度看，在 LinuxONE 上工作感觉与在任何其他 Linux 服务器上工作非常相似，这很大程度上是刻意设计的结果 [18 (https://arxiv.org/html/2608.21393#bib.bib18)]。

不同之处在于底层硬件。最新一代 LinuxONE 的核心 Telum II 处理器提供强大的单线程性能，支持超大内存配置（单系统最高 40TB），并包含专用加密加速器，可在每个总线、每个内存通道和每个存储路径上加密数据，且不会造成可测量的性能损失 [1 (https://arxiv.org/html/2608.21393#bib.bib1)]。该处理器还集成了一个片上 AI 加速器——一个小型推理引擎，能够以微秒级延迟在指令流水线内部直接运行量化 ML 模型（例如欺诈评分分类器或异常检测器） [10 (https://arxiv.org/html/2608.21393#bib.bib10)]。该片上加速器的算力不足以运行 LLM，但它对于 RAG 流水线路由层所需的轻量级分类任务却非常便利。

### 2.3 Spyre：将 LLM 推理引入本平台

Spyre 卡填补了 Telum II 片上加速器无法覆盖的空白。Spyre 于 2025 年 4 月随 IBM z17 一同发布，是一款 PCIe Gen5 推理加速器，拥有自己的高带宽内存、专门构建的张量处理核心，以及一个以流行的 vLLM 服务框架为中心的软件栈 [4 (https://arxiv.org/html/2608.21393#bib.bib4), 5 (https://arxiv.org/html/2608.21393#bib.bib5)]。单个 LinuxONE 系统最多可容纳六张 Spyre 卡，这些卡既可以服务独立模型（适用于多租户设置），也可以通过张量并行协作运行单个更大的模型。

IBM 针对 Spyre 优化了其开源 Granite 模型家族——规模从 30 亿到 340 亿参数不等——并提供了一个预编译器，可将 PyTorch 模型转换为使用 INT8 或 FP16 量化的优化 Spyre 可执行文件 [11 (https://arxiv.org/html/2608.21393#bib.bib11)]。在服务方面，IBM 扩展了 vLLM，增加了 Spyre 执行后端，支持连续批处理和 PagedAttention [14 (https://arxiv.org/html/2608.21393#bib.bib14)]，因此其运维模型对于任何在 NVIDIA 硬件上运行过 vLLM 的人来说都很熟悉。

### 2.4 现有工作的不足

云服务商已经记录了各自的 RAG 参考架构——微软的 Azure AI Search 加 GPT-4，谷歌的 Vertex AI RAG Engine——但这些设计都默认数据可以到达云端托管的模型。学术界关于隐私保护 RAG 的研究探讨了差分隐私 [17 (https://arxiv.org/html/2608.21393#bib.bib17)] 和联邦方法，但这些技术通常以牺牲准确性或增加大量延迟为代价。我们的架构完全规避了这种权衡：我们不是在数据传输到远程 GPU 时试图通过算法保护数据，而是将 GPU 等效物（Spyre）带到数据身边，并使用硬件强制隔离来确保一切安全。

## 3 系统架构

我们将流水线分为六个子系统，每个子系统作为一个或多个容器化微服务运行在 OpenShift 上。图 1 (https://arxiv.org/html/2608.21393#S3.F1) 展示了它们之间的连接方式。这种划分并非随意——它反映了运维边界。每个子系统都可以独立扩展、更新和监控，这在运行生产环境下的 AI 服务且需遵守 SLA 时非常重要。

1.  输入与预处理
2.  意图检测与路由
3.  知识检索
4.  Spyre 加速的生成式推理
5.  护栏与合规
6.  输出、可观测性与反馈

API 网关 / 用户界面 -> 输入验证、清理与 PII 脱敏 -> 会话上下文与元数据丰富 -> Telum II 片上 AI 上的意图分类器 -> 置信度 ≥ θ？ -> [是] -> 知识源路由器 -> 混合检索：BM25 + 稠密向量搜索 -> 交叉编码器重排与上下文组装 -> RAG 提示构建与模板引擎 -> Spyre 卡：通过 vLLM 的 Granite LLM 推理 -> 流式 Token 解码与响应组装 -> 事实基础检查 -> 内容护栏、PII 清洗与偏见筛查 -> 治理元数据与来源标签 -> 通过 API 交付响应 -> 可观测性：跟踪、指标与审计日志 -> 反馈收集与持续改进 -> [否] -> 澄清/查询重写 -> 返回意图分类器

图 1：基于 IBM LinuxONE 和 Spyre 的完整 RAG 流水线。六个子系统作为容器化服务运行在 OpenShift 上。Telum II 处理快速意图分类；Spyre 卡处理 LLM 推理。虚线箭头表示异步反馈和重试循环。

### 3.1 子系统 1：输入与预处理

查询通过 API 网关到达——Kong 或 Red Hat 3scale，两者都原生运行在 OpenShift 上——网关处理身份验证（OAuth 2.0 / OIDC）、速率限制和基本请求路由。这里没有什么特别之处；这是标准的 API 管理实践。

网关后面，一个验证服务执行不那么光鲜但至关重要的工作：检查提示注入模式（一种日益被详细记录的攻击向量）、强制输入长度限制以免意外耗用下游上下文窗口预算、规范化 Unicode，以及运行一个快速的 PII 检测器，在查询进一步传播之前屏蔽账号或国民身份证号。对于多轮对话，一个会话上下文服务从 Redis 支持的存储中提取之前的对话轮次，并将其与新查询拼接在一起。它还附加从组织身份提供者获取的角色和权限元数据——信息检索层稍后需要这些数据来执行访问控制。

所有这些处理的计算量都不大。它们在标准的 Telum II 核心上轻松运行，整个子系统为流水线增加的延迟大概只有一两毫秒。

### 3.2 子系统 2：意图检测与路由

并非每个查询都需要完整的生成式响应。询问“我的账户余额是多少？”的用户应该调用交易 API，而非 LLM。而像“总结 2024 年巴塞尔协议 III 框架的变更”这样的查询则确实需要检索和生成。意图检测层在消耗昂贵的 Spyre 计算周期之前对这些情况进行分类。

我们在 Telum II 片上 AI 加速器上运行一个微调的 DistilBERT 类分类器（量化为 INT8，约 6000 万参数）。该模型在特定领域的意图分类法上训练，能在几十微秒内对每个传入查询进行分类——速度足够快，以至于从延迟角度看，路由决策几乎免费。如果分类器的置信度超过阈值 θ（我们默认设为 0.85，但允许运维团队调整），查询将附带其意图标签直接传递到知识检索。低于该阈值时，流水线会分支到一个澄清模块，该模块可以要求用户重述或应用自动查询重写启发式方法，然后重试分类。

关键的设计洞察是，这个路由层让我们可以将 Spyre 视为稀缺资源并有意识地分配它，而不是让每个请求都通过流水线中最昂贵的部分。

### 3.3 子系统 3：知识检索

将正确的上下文段落呈现在 LLM 面前，可能比模型选择本身更重要——任何在生产环境中调试过 RAG 系统的人都会认同这一点。我们使用三阶段检索方法。

**源路由**。基于意图标签，一个轻量级路由器决定查询哪些知识源。系统目前支持四种：用于非结构化文档块的 Milvus 向量存储、用于半结构化数据的 PostgreSQL（带 pgvector）、用于原始文件的文档存储，以及用于关系密集型知识图谱的 Neo4j 实例。因为所有这些服务都作为容器运行在同一个 LinuxONE 系统上，服务间通信通过本地回环或虚拟网络桥接进行——延迟在微秒级，而不是穿越物理网络所需的毫秒级。

**混合检索**。我们并行运行 BM25（稀疏）和稠密向量搜索，并使用倒数排名融合 (RRF) [13 (https://arxiv.org/html/2608.21393#bib.bib13)] 来融合结果。稠密嵌入来自 Granite 嵌入模型；查询时的嵌入计算在单个查询时在 Telum II 上运行，或在索引构建期间的批量工作负载中在 Spyre 上运行。这种方法既能捕捉稠密检索有时会错过的关键词精确匹配，也能捕捉 BM25 忽略的语义相关段落。

**重排与上下文组装**。一个交叉编码器...