重新审视 CPU 在 AI 中的价值：基于NVIDIA DGX Spark 的 RAG 实战

在大量企业级场景中，工程师和技术人员需要快速定位关键信息。他们查找的往往是内部资料，比如硬件规格说明、项目文档、技术笔记等。但现实情况是，这些资料通常分散在不同系统和位置，导致传统的关键词搜索效率低下，体验也并不理想。

此外，这类文档往往具有高度敏感性，要么是公司内部机密，要么涉及核心知识产权。这意味着，它们无法被直接上传到外部云服务或公共的大语言模型 (Large Language Models, LLMs) 中进行处理。因此，真正的技术难题在于：如何在不牺牲数据安全与隐私的前提下，构建一个人工智能 (AI) 检索系统，实现在端侧输出安全可靠、响应迅速且上下文精准的答案？

架构解法：在 DGX Spark 上构建异构 RAG 系统

在当下的 AI 系统中，GPU 往往被视为“默认算力担当”。但从工程视角来看，一次完整的 AI 推理流程其实由多个计算阶段组成，而这些阶段对算力的需求并不相同。GPU 非常擅长处理大规模矩阵运算；但还有不少环节更强调低延迟与灵活性，比如查询解析、数据检索以及向量编码等。这些任务如果一味压给 GPU，反而可能带来不必要的延迟和资源浪费。

这正是 NVIDIA DGX Spark 桌面平台的优势所在，其基于 NVIDIA GB10 Grace Blackwell 超级芯片架构打造，在硬件层面为异构计算提供了天然基础。在这样的硬件基础之上，结合 FAISS、llama.cpp 等软件栈，以此展示 CPU 不再只是被动的预处理器，而是转变为一个以低延迟为目标的主动计算引擎，成为驱动本地 AI 响应的关键力量。

架构与设计：在桌面级硬件上本地运行 RAG 系统

检索增强生成 (Retrieval-Augmented Generation, RAG) 是一种非常适合用于查询私有、本地数据的 AI 架构，它可以将这些封闭领域的知识转换为一个可检索的向量数据库，再由语言模型基于检索到的上下文在本地生成答案。这样一来，开发者既能获得 AI 辅助的智能问答体验，又能完全掌控数据的隐私与所有权。

为了展示这一系统在实际中的工作方式，我们选择了一套非常贴近开发者日常的示例数据集：
完整的树莓派硬件规格文档、编程指南以及应用说明。这些文档往往篇幅较长、格式不统一。很多开发者都有过类似体验，为了查一个 GPIO 引脚定义、电压阈值或默认状态，不得不在多个 PDF 之间来回翻找，耗时长又低效。而在本地 RAG 系统中，用户只需输入自然语言问题，系统会从本地文档数据库中检索相关文本片段，再通过语言模型生成符合上下文的精准答案。

在 RAG 架构确定之后，接下来就进入了系统设计中的一个关键问题：
向量化 (Embedding) 阶段应该放在哪里运行，才能在性能和响应速度之间取得最佳平衡？

在 RAG 管线中，为何 CPU 是更明智的选择

在 RAG架构中，第一步是将用户输入的问题转换为向量表示，即文本向量化。这一阶段对整体检索与生成的准确性至关重要，但它的计算特征，与 GPU 擅长的大规模矩阵运算其实并不匹配。在真实使用场景中，用户的查询通常只是一小段短语或一两句话。这使得向量化成为一个吞吐量要求不高，但对延迟极其敏感的任务。如果把这类小批量请求交给 GPU，不仅无法发挥 GPU 的并行优势，反而会引入额外开销，例如调度延迟、PCIe 传输延迟，以及算力资源利用率偏低等问题。

正因为如此，我们选择将向量化阶段放在 CPU 上执行，而这恰好凸显了 DGX Spark 平台中基于 Arm 架构的系统级芯片 (SoC) 的优势。DGX Spark 集成了由高性能 Arm Cortex-X 与 Cortex-A 核心组成的异构 CPU 架构。其中，Cortex-X 系列专为高频、低延迟场景而设计，在多线程性能与能效之间取得了良好平衡。这使其非常适合向量化这类小批量、内存访问密集型的推理任务。

当与 int8 量化的向量化模型结合使用时，CPU 在低功耗条件下，能提供稳定、可预测的性能表现，从而保证快速响应和流畅的交互体验。对于桌面级或边缘侧的查询系统而言，Cortex-X 架构针对实时搜索与推理等延迟敏感型工作负载进行了优化，在单线程性能和能效之间实现了出色平衡。

接下来我们将通过真实案例来展示，
向量化质量的差异是如何直接影响整个 RAG 系统输出结果的可靠性的。

有据可依的答案：用 RAG 消除“幻觉”问题

文本向量化这一阶段的精度直接决定了后续检索结果的相关性，也在很大程度上影响了整个 RAG 系统输出的质量。但从更宏观的角度来看，RAG 被设计出来，本质上是为了解决一个长期困扰 AI 应用的核心问题——大模型幻觉 (Hallucination)。

当语言模型缺乏足够的上下文信息，或无法访问最新、权威的技术文档时，往往会“自信满满”地生成听起来很合理，但实际上并不准确的回答。在技术和企业级场景中，这种看似正确却并未基于事实的输出，往往会带来严重风险。正因如此，RAG 的关键价值在于：它使得语言模型能基于真实文档内容进行回答，而不是凭“语言概率”进行猜测，从根本上降低幻觉出现的可能性。

为了验证这一点，我们通过使用开发者的常见问题，并结合一套内部技术文档，设计并运行了一次可控实验，用来直观观察 RAG 在抑制幻觉方面的实际效果。

场景一：未搭载 RAG 系统的 LLM

查询问题：“树莓派 4 上，哪些 GPIO 默认配置了下拉电阻 (Pull-down Resistor)？”

当我们将这个问题直接发送给 Meta-Llama-3.1-8B 模型，而不引入 RAG 或向量检索机制时，结果清楚地暴露了一个“无事实约束”的大模型所存在的不稳定性问题：

第一次尝试：模型给出了一组 GPIO 列表，包括 GPIO 1、3、5、7、9、11……并声称这些引脚默认配置了下拉电阻。

第二次尝试（同样的问题）：模型却返回了一份完全不同的 GPIO 列表，包括 GPIO 3、5、7、8……，并且还重新定义了部分引脚的属性，例如，GPIO 4 在第一次回答中被认为是上拉电阻，但在这次回答中却变成了下拉电阻。

观察结论：尽管两次输出在事实层面明显相互矛盾且并不准确，模型在两次回答中都表现得非常“自信”。这正是缺乏上下文约束和事实依据时，LLM 幻觉问题的典型体现。

场景二：引入 RAG 架构后查询场景一相同问题

当我们将完全相同的问题放入本地运行的 RAG 系统中，结果发生了本质性的变化：事实准确，返回的答案与官方技术文档完全一致，并经过人工核验，结果正确无误；可追溯性强，系统在回答中明确标注了信息来源，引用了数据手册中的具体章节和表格编号，方便开发者进一步查阅与验证。

这一对比非常直观地体现了 RAG 架构的核心优势。RAG 并不是让模型基于训练分布去“猜”答案，而是要求每一次回答都建立在真实文档检索结果之上。正是这种“先检索、再生成”的机制，使得 RAG 能够有效抑制幻觉问题，确保输出内容真实、可验证、可追溯，这对于技术和企业级场景尤为关键。

从性能角度看，在该实验中，由 Arm CPU 处理的向量化阶段，单次耗时通常在 70 至 90 毫秒之间，完全满足交互式查询系统对低延迟响应的要求。

架构优势：统一内存

在传统系统架构中，CPU 生成的数据通常需要通过 PCIe 等互连通道，传输到 GPU 的独立显存空间中。这一过程不仅会引入额外的延迟，还会占用宝贵的带宽资源，成为整体性能链路中的隐性瓶颈。而在统一内存 (Unified Memory) 架构下，CPU 与 GPU 共享同一块内存空间。这意味着，CPU 生成的向量结果可以被 GPU 直接访问，无需显式的数据拷贝或内存传输操作，从而显著简化数据流转路径。这种设计带来的效果非常直接：推理管线更短、延迟更低、整体效率更高。对于 RAG 这类强调实时交互体验的 AI 推理场景而言，每一毫秒的延迟都至关重要。

我们在下表中通过 DGX Spark 平台在 RAG 各阶段的内存使用情况分析，用量化数据来直观展示这一架构的优势。

 

阶段	阶段说明	观测到的 DRAM 占用（约）	关键技术解读
空闲状态（启动前）	系统尚未启动 RAG 任务	~3.5 GiB	操作系统及后台服务的 基础内存占用
模型加载	启动 llama-server， 加载 LLaMA 3.1 8B Q8_0 模型	~12 GiB	模型权重直接映射到统一内存， CPU 与 GPU 可共享访问
向量化阶段	使用 E5-base-v2 模型， 在 CPU 上对文本分块进行向量化	~13 GiB	CPU 生成的向量数据直接写入 共享 DRAM，无需额外拷贝
查询执行	FAISS 向量检索， 以及通过 llama.cpp 的 基于 GPU 的生成	~14 GiB	GPU 直接访问共享张量， 消除 PCIe 拷贝开销
任务完成后	查询结束， 部分缓存释放	~12 GiB	模型仍常驻内存， 为下一次查询做好准备

 

表：RAG 各执行阶段的 DRAM 使用情况

请注意：本文中提到的所有性能与内存占用数据，均基于我们在 DGX Spark 平台上的测试环境和具体工作负载配置。实际结果可能会因系统参数设置、模型规模等因素而有所不同。
不过，这组内存与性能画像仍可作为规划本地 AI 工作负载、评估内存可扩展性与可预测性时的一个实用参考。

基于上述测试，总结出以下几条对工程实践非常有价值的结论：

• 管线各阶段内存使用稳定：
  在整个 RAG 执行过程中，DRAM 占用从空闲时的5 GiB，提高到高峰期约 14 GiB，整体增长仅约 10 GiB。这表明系统在不同阶段都展现出了高效且可控的内存管理能力，资源利用非常紧凑。
• 模型与向量数据可持续驻留内存：
  模型加载完成后，内存占用上升至约 12 GiB，并且在多次查询之后仍保持稳定。这说明模型权重和向量数据不会在查询过程中被频繁回收或驱逐出 DRAM，可以被复用，避免了重复加载带来的性能损耗。
• 从 CPU 到 GPU 的切换阶段内存变化极小：
  在向量化阶段，内存占用约为 13 GiB；进入 GPU 生成阶段后，仅小幅上升至 14 GiB。这清楚地表明：向量数据和 Prompt 张量被 GPU 直接就地使用，过程中没有发生明显的内存重新分配，也不存在 PCIe 数据拷贝开销。

统一内存不仅降低了开发复杂度，更在执行层面提供了稳定、高效的内存运行特性，成为桌面级与边缘级 AI 推理架构的重要基础。

结语：CPU 是 AI 系统设计中不可或缺的“关键协作者”

通过在 DGX Spark 上构建并运行一个完整的本地 RAG 系统，让我们重新审视了 CPU 在现代 AI 架构中的真实价值。在大量实际 AI 应用中，尤其是围绕检索、搜索和自然语言交互的场景，计算负载并不只集中在 LLM 的推理本身。查询解析、文本向量化、文档检索、Prompt 组装等关键环节，恰恰是 CPU 最擅长的领域。

随着 AI 持续向端侧与边缘部署演进，CPU，尤其是高能效的 Arm 架构，将在系统中扮演越来越核心的角色。
CPU 会是未来低延迟、强隐私保护 AI 系统中不可或缺的核心赋能者。

如果你想要复现本文中的实践，或将类似方案用于真实项目，可以在 Arm Learning Path 中找到完整示例与分步教程，对应的内容正是基于本文所介绍的架构与实现方式。无论你是在做概念验证(PoC)，还是规划生产级部署，这些模块化教程都能帮助你快速上手真实的 RAG 工作流——它们充分利用了 CPU 高效向量化与统一内存架构，并针对基于 Arm 的平台进行了优化，非常适合作为本地 AI 应用落地的起点。快来与我们一起动手尝试吧！