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

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

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

架構(gòu)解法

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

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

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

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

架構(gòu)與設(shè)計(jì)

在桌面級(jí)硬件上本地運(yùn)行 RAG 系統(tǒng)

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

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

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

在 RAG 管線中

為何 CPU 是更明智的選擇

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

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

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

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

有據(jù)可依的答案

用 RAG 消除“幻覺”問題

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

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

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

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

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

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

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

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

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

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

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

右滑查看場(chǎng)景二

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

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

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

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

我們?cè)谙卤碇型ㄟ^ DGX Spark 平臺(tái)在 RAG 各階段的內(nèi)存使用情況分析，用量化數(shù)據(jù)來直觀展示這一架構(gòu)的優(yōu)勢(shì)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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