【Q&A】从文本到知识图谱：DGX Spark如何高效支持离线批处理与图构建

DGX Spark是否支持GPUDirect RDMA技术？一文看懂

DGX Spark软件更新今日上线，同步支持基于NVIDIA GB10的OEM系统

本QA整理自NVIDIA线上讲座《DGX Spark Live: Process Text for GraphRAG With Up to 120B LLM》

1.问：GraphRAG on DGX Spark 是否能高效处理多节点文本摄取，在处理较大语料库时，索引是否会成为主要瓶颈？

答：如果本地运行文本到知识图谱（text2 KG）任务，默认情况下可能不支持多节点，因为演示可能未将其作为默认功能。但可以通过高速互连连接两个 DGX Spark，且其具有大内存和大量ARM CPU 核心，适合离线批处理任务。实际上，这些任务不需要节点间通信，可以独立运行这些任务，然后存储并拼接三元组列表，不一定需要多节点和节点间通信。

2.问：很多机器都能处理相关任务，为什么要在DGX Spark 上进行，讨论它有什么意义？

答：一般建议使用70B 模型及以上，模型越大通常效果越好，这里使用120B 模型，甚至可以尝试对253B 模型进行量化，效果可能更好。DGX Spark 具有CPU 和GPU 通过NVLink 进行统一内存通信的能力，速度极快（可达太字节级别），而传统计算机在数据从CPU 到GPU 的传输上会有时间开销。此外，DGX Spark 是一个小型版本的Blackwell，适合小规模测试，后续可无缝扩展到数据中心规模。

3.问：120B 模型在图结构检索方面表现如何，与70B 范围相比在实际工作中是否有明显优势？

答：从8B 到200 多亿参数的大型语言模型（LLM），随着模型大小和架构变化，质量持续提高，一般来说模型越大性能越好，因为相近发布时间的模型在数据技术上差异不大。对于图结构检索，主要用于索引阶段，因为对大量文档进行嵌入进行检索成本过高，但也可以尝试。传统模型在处理单个或少量单词短语的语义相似性上表现良好，但在处理大型文档时，前沿模型表现更优，这就是在索引阶段使用大型前沿模型的原因。

4.问：在DGX Spark和5090 上哪个更具性能优势？

答：由于没有进行基准测试，不能确定。这取决于具体的批处理设置，5090 可能具有更多的浮点运算能力，但它连接到英特尔CPU 是通过PCIe 连接，数据传输可能会成为瓶颈。一般来说，需要对特定的批处理大小和模型大小进行测试，但两者都是不错的选择。DGX Spark 是Blackwell 的小型版本，适合小规模测试，后续可扩展到大规模应用，而5090 是游戏GPU，堆栈与DGX Spark 略有不同。

5.问：统一内存对DGX Spark上的GraphRAG 有帮助吗？

答：统一内存对所有图相关任务都非常强大。图神经网络（GNN）部分的计算量相对较小，成本主要在于内存传输等操作。例如在检索时，无法将整个数据库加载到 GPU 内存中，而统一内存能够实现快速的数据传输，因此非常有用。

6.问：对于大规模图，是否有首选的分区策略以保持跨 Spark 工作节点的延迟可预测性？

答：一般不使用DGX Spark 进行图神经网络相关的图分区，现在使用cuGraph，它基于wholegraph，能够将图的特征键值存储分布到任意数量的GPU 上，可处理多达1.6 万亿条边的情况，而之前其他解决方案无法实现。不建议使用DGX Spark 进行图分区，建议使用英伟达提供的相关工具。

7.问：如何在DGX Spark上提取本地生物医学论文中的节点和关系，并使用120 模型将其存储到Orango DB 时管理GPU 内存和数据移动？

答：在DGX Spark上，它有20 个ARM 核心，可作为通用开发机器构建容器化服务，Orango DB 运行在Docker 镜像中，Web 应用程序使用Nex.js 也运行在单独的Docker 容器中。可以使用Olana 来配置模型的加载和卸载，避免同时加载多个模型导致GPU 内存不足。还建议使用其他推理解决方案，如VLM、SG lang、TRTLM，这些都在DGX Spark上经过测试，可能提供较好的性能。

8.问：对于大规模图，是否支持增量更新，例如是否可以在不重建整个图索引的情况下添加新文档？

答：在PyG 中肯定是可行的，在Sento 的演示中也应该可以实现。

9.问：该管道能否将传统嵌入与图边相结合，还是完全针对结构化节点关系查询进行优化？

答：可以将传统文档检索技术与GraphRAG 相结合。在GraphRAG 管道中，除了红色部分（GraphRAG 解决方案）外，还可以添加任何传统的文档检索技术，将其检索到的文档进行嵌入并附加到提示中，经过微调的系统能够学会同时对传统文档和子图进行推理。虽然向量RAG 在只需要一个文档回答问题的情况下效果较好，GraphRAG 在处理多个实体分散在多个文档中的情况时更具优势，但将两者结合并进行微调，效果总是优于单独使用任何一种方法。

10.问：Spark 在遇到严重约束之前，实际能力如何？

答：Spark 作为开发机器相当强大，许多处理数据中心规模业务的客户在迁移到更大规模的硬件（如GB200）之前，会使用它进行测试。增加 Spark 的数量可以进一步提高处理速度，因为这些过程是完全独立的，可以并行处理。除了最大内存限制外，一般没有其他严重的约束，如今大多数前沿模型的大小都可以适配到Spark 上，甚至可以进行量化处理。

11.问：如何评估输出质量，提示中的风格、光线、构图、细节等因素是否重要？

答：图是通过提示向大型语言模型（LLM）查询并附加文档来创建的，修改提示（如添加“please”）可能对结果有一定改善，但一般来说，前沿模型已经足够智能，不需要超级精心设计的提示就能获得较好的结果。提示中的风格、光线等因素与知识图的创建关系不大，可能指的是知识图可视化方面的提示。

12.问：能否在Jetson Nano 上进行文本知识图谱处理？

答：如果将Jetson Nano 连接到云端，理论上可行，但Jetson Nano 可能无法运行足够好的 LLM 以获得良好的结果。截至7 个月前，能在其上运行的最小LLM 是14B 模型，但不确定Jetson Nano 是否能运行该模型，而且英伟达可能不会为旧芯片（如Jetson Nano）提供新的堆栈支持。不过，英伟达在 build.nvidia.com 上提供了推理端点，有两个预配置的 LLM，可以获取API 密钥并在任何有CPU 的机器上运行。

13.问：是否有与云平台（如AWS Bedrock）的基准测试？

答：没有相关基准测试。选择在本地处理还是数据中心处理，各有利弊，本地处理具有大内存的优势，可以根据需求进行选择。

14.问：根据个人经验，哪些是最佳的前沿模型？

答：英伟达的 Llama Neotron 模型表现令人印象深刻，特别是253B 模型和49B Super V1.5 模型，两者表现相当，但49B 模型参数空间减少了5 倍，成本更低。也可以选择Claude 和GPT，但它们无法在本地运行。个人推荐尝试49B V1.5 或253B 模型，未来可能会有 253V1.5 模型推出。