作者：Arm 首席解決方案架構(gòu)師 沈綸銘

在大量企業(yè)級場景中，工程師和技術(shù)人員需要快速定位關(guān)鍵信息。他們查找的往往是內(nèi)部資料，比如硬件規(guī)格說明、項目文檔、技術(shù)筆記等。但現(xiàn)實情況是，這些資料通常分散在不同系統(tǒng)和位置，導致傳統(tǒng)的關(guān)鍵詞搜索效率低下，體驗也并不理想。

此外，這類文檔往往具有高度敏感性，要么是公司內(nèi)部機密信息，要么涉及核心知識產(chǎn)權(quán)。這意味著，它們無法被直接上傳到外部云服務或公共的大語言模型 (Large Language Models, LLMs) 中進行處理。因此，真正的技術(shù)難題在于：如何在不犧牲數(shù)據(jù)安全與隱私的前提下，構(gòu)建一個人工智能 (AI) 檢索系統(tǒng)，實現(xiàn)在端側(cè)輸出安全可靠、響應迅速且上下文精準的答案？

架構(gòu)解法

在 DGX Spark 上構(gòu)建異構(gòu) RAG 系統(tǒng)

在當下的 AI 系統(tǒng)中，GPU 往往被視為“默認算力擔當”。但從工程視角來看，一次完整的 AI 推理流程其實由多個計算階段組成，而這些階段對算力的需求并不相同。GPU 非常擅長處理大規(guī)模矩陣運算；但還有不少環(huán)節(jié)更強調(diào)低延遲與靈活性，比如查詢解析、數(shù)據(jù)檢索以及向量編碼等。這些任務如果一味壓給 GPU，反而可能帶來不必要的延遲和資源浪費。

這正是 NVIDIA DGX Spark 桌面平臺的優(yōu)勢所在，其基于 NVIDIA GB10 Grace Blackwell 超級芯片架構(gòu)打造，在硬件層面為異構(gòu)計算提供了天然基礎。在這樣的硬件基礎之上，結(jié)合 FAISS、llama.cpp[1]等軟件棧，以此展示 CPU 不再只是被動的預處理器，而是轉(zhuǎn)變?yōu)橐粋€以低延遲為目標的主動計算引擎，成為驅(qū)動本地 AI 響應的關(guān)鍵力量。

[1] https://github.com/ggml-org/llama.cpp

架構(gòu)與設計

在桌面級硬件上本地運行 RAG 系統(tǒng)

檢索增強生成 (Retrieval-Augmented Generation, RAG) 是一種非常適合用于查詢私有、本地數(shù)據(jù)的 AI 架構(gòu)，它可以將這些封閉領域的知識轉(zhuǎn)換為一個可檢索的向量數(shù)據(jù)庫，再由語言模型基于檢索到的上下文在本地生成答案。這樣一來，開發(fā)者既能獲得 AI 輔助的智能問答體驗，又能完全掌控數(shù)據(jù)的隱私與所有權(quán)。

為了展示這一系統(tǒng)在實際中的工作方式，我們選擇了一套非常貼近開發(fā)者日常的示例數(shù)據(jù)集：完整的樹莓派硬件規(guī)格文檔、編程指南以及應用說明。這些文檔往往篇幅較長、格式不統(tǒng)一。很多開發(fā)者都有過類似體驗，為了查一個 GPIO 引腳定義、電壓閾值或默認狀態(tài)，不得不在多個 PDF 之間來回翻找，耗時長又低效。而在本地 RAG 系統(tǒng)中，用戶只需輸入自然語言問題，系統(tǒng)就會從本地文檔數(shù)據(jù)庫中檢索相關(guān)文本片段，再通過語言模型生成符合上下文的精準答案。

在 RAG 架構(gòu)確定之后，接下來就進入了系統(tǒng)設計中的一個關(guān)鍵問題：向量化 (Embedding) 階段應該放在哪里運行，才能在性能和響應速度之間取得最佳平衡？

在 RAG 管線中

為何 CPU 是更明智的選擇

在 RAG 架構(gòu)中，第一步是將用戶輸入的問題轉(zhuǎn)換為向量表示，即文本向量化。這一階段對整體檢索與生成的準確性至關(guān)重要，但它的計算特征，與 GPU 擅長的大規(guī)模矩陣運算其實并不匹配。在真實使用場景中，用戶的查詢通常只是一小段短語或一兩句話。這使得向量化成為一個吞吐量要求不高，但對延遲極其敏感的任務。如果把這類小批量請求交給 GPU，不僅無法發(fā)揮 GPU 的并行優(yōu)勢，反而會引入額外開銷，例如調(diào)度延遲、PCIe 傳輸延遲，以及算力資源利用率偏低等問題。

正因為如此，我們選擇將向量化階段放在 CPU 上執(zhí)行，而這恰好凸顯了 DGX Spark 平臺中基于 Arm 架構(gòu)的系統(tǒng)級芯片 (SoC) 的優(yōu)勢。DGX Spark 集成了由高性能 Arm Cortex-X 與 Cortex-A 核心組成的異構(gòu) CPU 架構(gòu)。其中，Cortex-X 系列專為高頻、低延遲場景而設計，在多線程性能與能效之間取得了良好平衡。這使其非常適合向量化這類小批量、內(nèi)存訪問密集型的推理任務。

當與 int8 量化的向量化模型結(jié)合使用時，CPU 在低功耗條件下，能提供穩(wěn)定、可預測的性能表現(xiàn)，從而保證快速響應和流暢的交互體驗。對于桌面級或邊緣側(cè)的查詢系統(tǒng)而言，Cortex-X 架構(gòu)針對實時搜索與推理等延遲敏感型工作負載進行了優(yōu)化，在單線程性能和能效之間實現(xiàn)了出色平衡。

接下來我們將通過真實案例來展示，向量化質(zhì)量的差異是如何直接影響整個 RAG 系統(tǒng)輸出結(jié)果的可靠性的。

有據(jù)可依的答案

用 RAG 消除“幻覺”問題

文本向量化這一階段的精度直接決定了后續(xù)檢索結(jié)果的相關(guān)性，也在很大程度上影響了整個 RAG 系統(tǒng)輸出的質(zhì)量。但從更宏觀的角度來看，RAG 被設計出來，本質(zhì)上是為了解決一個長期困擾 AI 應用的核心問題 —— 大模型幻覺 (Hallucination)。

當語言模型缺乏足夠的上下文信息，或無法訪問最新、權(quán)威的技術(shù)文檔時，往往會“自信滿滿”地生成聽起來很合理，但實際上并不準確的回答。在技術(shù)和企業(yè)級場景中，這種看似“正確”卻并未基于事實的輸出，往往會帶來嚴重風險。正因如此，RAG 的關(guān)鍵價值在于：它使得語言模型能基于真實文檔內(nèi)容進行回答，從而降低幻覺出現(xiàn)的可能性。

為了驗證這一點，我們通過使用開發(fā)者的常見問題，并結(jié)合一套內(nèi)部技術(shù)文檔，設計并運行了一次可控實驗，用來直觀觀察 RAG 在抑制幻覺方面的實際效果。

場景一：未搭載 RAG 系統(tǒng)的 LLM

查詢問題：“樹莓派 4 上，哪些 GPIO 默認配置了下拉電阻 (Pull-down Resistor)？”

當我們將這個問題直接發(fā)送給 Meta-Llama-3.1-8B 模型，而不引入 RAG 或向量檢索機制時，結(jié)果清楚地暴露了一個“無事實約束”的大模型所存在的不穩(wěn)定性問題：

第一次嘗試：模型給出了一組 GPIO 列表，包括 GPIO 1、3、5、7、9、11……并聲稱這些引腳默認配置了下拉電阻。

第二次嘗試（同樣的問題）：模型卻返回了一份完全不同的 GPIO 列表，包括 GPIO 3、5、7、8……，并且還重新定義了部分引腳的屬性，例如，GPIO 4 在第一次回答中被認為是上拉電阻，但在這次回答中卻變成了下拉電阻。

觀察結(jié)論：盡管兩次輸出在事實層面明顯相互矛盾且并不準確，模型在兩次回答中都表現(xiàn)得非?！白孕拧薄＿@正是缺乏上下文約束和事實依據(jù)時，LLM 幻覺問題的典型體現(xiàn)。

場景二：引入 RAG 架構(gòu)后查詢場景一相同問題

當我們將完全相同的問題放入本地運行的 RAG 系統(tǒng)中，結(jié)果發(fā)生了本質(zhì)性的變化：事實準確，返回的答案與官方技術(shù)文檔完全一致，并經(jīng)過人工核驗，結(jié)果正確無誤；可追溯性強，系統(tǒng)在回答中明確標注了信息來源，引用了數(shù)據(jù)手冊中的具體章節(jié)和表格編號，方便開發(fā)者進一步查閱與驗證。

右滑查看場景二

這一對比非常直觀地體現(xiàn)了 RAG 架構(gòu)的核心優(yōu)勢。RAG 并不是讓模型基于訓練分布去“猜”答案，而是要求每一次回答都建立在真實文檔檢索結(jié)果之上。正是這種“先檢索、再生成”的機制，使得 RAG 能夠有效抑制幻覺問題，確保輸出內(nèi)容真實、可驗證、可追溯，這對于技術(shù)和企業(yè)級場景尤為關(guān)鍵。

從性能角度看，在該實驗中，由 Arm CPU 處理的向量化階段，單次耗時通常在 70 至 90 毫秒之間，完全滿足交互式查詢系統(tǒng)對低延遲響應的要求。

架構(gòu)優(yōu)勢：統(tǒng)一內(nèi)存

在傳統(tǒng)系統(tǒng)架構(gòu)中，CPU 生成的數(shù)據(jù)通常需要通過 PCIe 等互連通道，傳輸?shù)?GPU 的獨立顯存空間中。這一過程不僅會引入額外的延遲，還會占用寶貴的帶寬資源，成為整體性能鏈路中的隱性瓶頸。而在統(tǒng)一內(nèi)存 (Unified Memory) 架構(gòu)下，CPU 與 GPU 共享同一塊內(nèi)存空間。這意味著，CPU 生成的向量結(jié)果可以被 GPU 直接訪問，無需顯式的數(shù)據(jù)拷貝或內(nèi)存?zhèn)鬏敳僮鳎瑥亩@著簡化數(shù)據(jù)流轉(zhuǎn)路徑。這種設計帶來的效果非常直接：推理管線更短、延遲更低、整體效率更高。對于 RAG 這類強調(diào)實時交互體驗的 AI 推理場景而言，每一毫秒的延遲都至關(guān)重要。

我們在下表中通過 DGX Spark 平臺在 RAG 各階段的內(nèi)存使用情況分析，用量化數(shù)據(jù)來直觀展示這一架構(gòu)的優(yōu)勢。

表：RAG 各執(zhí)行階段的 DRAM 使用情況

請注意：本文中提到的所有性能與內(nèi)存占用數(shù)據(jù)，均基于我們在 DGX Spark 平臺上的測試環(huán)境和具體工作負載配置。實際結(jié)果可能會因系統(tǒng)參數(shù)設置、模型規(guī)模等因素而有所不同。不過，這組內(nèi)存與性能畫像仍可作為規(guī)劃本地 AI 工作負載、評估內(nèi)存可擴展性與可預測性時的一個實用參考。

基于上述測試，總結(jié)出以下幾條對工程實踐非常有價值的結(jié)論：

管線各階段內(nèi)存使用穩(wěn)定：在整個 RAG 執(zhí)行過程中，DRAM 占用從空閑時的 3.5 GiB，提高到高峰期約 14 GiB，整體增長僅約 10 GiB。這表明系統(tǒng)在不同階段都展現(xiàn)出了高效且可控的內(nèi)存管理能力，資源利用非常緊湊。

模型與向量數(shù)據(jù)可持續(xù)駐留內(nèi)存：模型加載完成后，內(nèi)存占用上升至約 12 GiB，并且在多次查詢之后仍保持穩(wěn)定。這說明模型權(quán)重和向量數(shù)據(jù)不會在查詢過程中被頻繁回收或驅(qū)逐出 DRAM，可以被復用，避免了重復加載帶來的性能損耗。

從 CPU 到 GPU 的切換階段內(nèi)存變化極?。涸谙蛄炕A段，內(nèi)存占用約為 13 GiB；進入 GPU 生成階段后，僅小幅上升至 14 GiB。這清楚地表明：向量數(shù)據(jù)和提示詞張量被 GPU 直接就地使用，過程中沒有發(fā)生明顯的內(nèi)存重新分配，也不存在 PCIe 數(shù)據(jù)拷貝開銷。

統(tǒng)一內(nèi)存不僅降低了開發(fā)復雜度，更在執(zhí)行層面提供了穩(wěn)定、高效的內(nèi)存運行特性，成為桌面級與邊緣側(cè) AI 推理架構(gòu)的重要基礎。

結(jié)語：CPU 是 AI 系統(tǒng)設計中

不可或缺的“關(guān)鍵協(xié)作者”

通過在 DGX Spark 上構(gòu)建并運行一個完整的本地 RAG 系統(tǒng)，讓我們重新審視了 CPU 在現(xiàn)代 AI 架構(gòu)中的真實價值。在大量實際 AI 應用中，尤其是圍繞檢索、搜索和自然語言交互的場景，計算負載并不只集中在 LLM 的推理本身。查詢解析、文本向量化、文檔檢索、提示詞組裝等關(guān)鍵環(huán)節(jié)，恰恰是 CPU 擅長的領域。

隨著 AI 持續(xù)向端側(cè)與邊緣部署演進，CPU，尤其是高能效的 Arm 架構(gòu)，將在系統(tǒng)中扮演越來越核心的角色。CPU 會是未來低延遲、強隱私保護 AI 系統(tǒng)中不可或缺的核心賦能者。

如果你想復現(xiàn)本文中的實踐，或?qū)㈩愃品桨赣糜谡鎸嶍椖?，可以在Arm Learning Path[2]中找到完整示例與分步教程。無論你是在做概念驗證 (PoC)，還是規(guī)劃生產(chǎn)級部署，這些模塊化教程都能幫助你快速上手真實的 RAG 工作流 —— 它們充分利用了 CPU 高效向量化與統(tǒng)一內(nèi)存架構(gòu)，并針對基于 Arm 架構(gòu)的平臺進行了優(yōu)化，非常適合作為本地 AI 應用落地的起點?？靵砼c我們一起動手嘗試吧！

[2] https://learn.arm.com/learning-paths/laptops-and-desktops/dgx_spark_rag/

* 本文為 Arm 原創(chuàng)文章，轉(zhuǎn)載請留言聯(lián)系獲得授權(quán)并注明出處。