一位AI产品经理的DGX Spark实践启示录：揭秘本地LLM推理如何重构AI应用开发范式

极速上手：使用ASUS Ascent GX10，三步为你的代码集成文生图功能

Blender开源生态如何让NVIDIA GB10系统成为3D创作新大陆

DGX Spark 桌面超算如何点亮癫痫研究的神经密码——一个科学家与“迷你超级计算机”的真实故事

"Spark"点燃星空：英伟达工程师如何用DGX Spark把后院变成太空观测站

本次讲座探讨基于本地LLM推理的后端开发。接下来会分享在AI开发中遇到的瓶颈问题，以及如何从依赖AI服务转向嵌入AI应用的过程，同时解释为何DGX Spark成为关键解决方案，并介绍本地推理方案。

故事要从几个月前说起——当时我的团队成员说需要某个LLM服务商的API密钥进行测试。作为称职的团队管理者，我爽快地提供了密钥，却忘了设置使用限制。结果他们不仅用于测试，还将其集成到CI/CD流水线中，每天运行数十次测试。直到收到26美元的账单时，我才惊觉问题：虽然金额不大，但这种开发测试阶段的消耗已让人不安——若推广到生产环境，成本恐怕会呈指数级增长。这促使我开始思考更优的解决方案。

过去一两年，绝大多数AI应用都采用"外部服务+API调用"模式：通过调用大型模型服务商提供的网络接口获取推理结果。但行业正在发生转变——越来越多团队尝试将AI直接嵌入应用内部，而非依赖外部服务。这种转变的核心逻辑在于：并非所有应用都需要千亿参数的巨型模型。对于许多场景，十亿参数级别的小模型甚至更小模型就足够胜任，且成本更低、响应更快。无论是在客户端设备还是服务器端运行，这种"AI作为应用组件"的模式正逐渐替代传统的分布式网络调用方案，显著降低延迟与成本。

但这种转变也面临挑战——部署AI到应用中绝非易事。它不像编写普通函数或调用标准库那样简单，需要整合模型、推理引擎、硬件适配等多个复杂组件。我们团队常思考的问题是：如何构建环境将AI真正嵌入应用而非依赖外部服务？如何实现本地推理？如果能在数据中心或云端完成，是否也能在客户端设备实现？答案是肯定的，但需要解决从客户端到生产级数据中心的推理部署难题。这正是DGX Spark登场的原因——它为我们社区提供了关键的技术路径和解决方案。

一个关键问题是：如何将开发阶段的AI应用顺利过渡到生产环境？无论是本地AI推理、模型微调还是其他AI任务，如何实现开发到生产的无缝衔接？能否统一技术栈？好消息是——完全可以！因为DGX Spark运行Ubuntu系统，内置CUDA生态，支持ARM架构的多种推理引擎，可直接在设备上进行本地推理。更棒的是，这套技术栈能直接迁移到云端生产环境，实现开发-生产环境的一致性。

第二个常见疑问是：使用DGX Spark进行本地推理，效率是否比调用外部大模型API更高？答案是肯定的。DGX Spark配备20核ARM处理器、Grace Blackwell 10 GPU及大量算力单元，我们将在现场演示中验证：本地推理不仅更快，还能直接将开发环境部署到生产环境。

有人担心这种部署是否过于复杂？毕竟开发者时间宝贵。解决方案在于：基于Ubuntu的容器化支持，可兼容Llama、VLM等开源模型及Python运行时。通过硅基算力调度优化，系统能智能分配任务到GPU或CPU运行，避免环境配置的复杂性。

特别要强调的是，当团队开始优化Grace Blackwell架构的模型训练时，这实际上是从开发环境向生产级MLOps的自然延伸——DGX Spark正是这一过程的理想起点。

我们能否像安装普通软件那样，直接用apt install、yum install、pip install或conda install加上模型名称就能一键运行？这正是我们与Farid团队长期攻关的核心目标。经过持续探索，我们已实现这一愿景——在数月前的Ubuntu峰会上推出的"推理快照"技术正是关键突破。

推理快照是一种将开源模型标准化打包的方案，支持在本地设备或服务器端快速部署。其实现原理包括：与硬件硅层深度协作，针对不同芯片架构（如CPU、GPU）进行模型优化；统一管理模型架构、运行时引擎、API标准及跨硬件的依赖项；自动化处理模型分发、版本更新等复杂流程。最终目标是让开发者只需选择模型和所需生成的模态类型，就能自动完成安装、依赖管理及版本更新——无需手动配置安装路径、硬件驱动或追踪新模型来源。

以DGX Spark高速设备为例，执行sudo snap install Gemma 3命令后，Gemma 3模型即可本地运行，开发者能立即基于该模型进行应用开发。这正是技术落地的魅力所在。

我刚才展示的是通过伪快照安装Gemma 3模型的过程。由于模型权重下载需要时间，我已提前完成安装。现在大家看到的是已安装状态。

通过运行Gemma 3 status命令，可以看到该快照正运行在Nvidia GPU ARM64架构上——这意味着这个开源模型已针对DGX Spark上的Nvidia GPU进行了专门优化，并提供了本地主机端点供调用。接下来我将演示基于此构建的应用，但先简单测试下快照功能：运行Gemma 3 chat会打开聊天界面，显示已连接本地主机，此时输入提示词（比如经典问题“为什么天空是蓝色的”），响应速度极快，比传统服务器-客户端流传输更迅速。

虽然用ORM工具或Docker也能运行该模型，但快照的独特价值在于：你可以在其基础上构建完整应用，这些应用能自动识别机器上运行的Gemma 3模型，并适配不同硬件环境——无GPU时自动切换CPU，有其他加速器时则调用硅优化方案。当然，DGX Spark的卓越性能在此功不可没。

那么如何基于快照构建应用呢？看这个名为“chat”的Python应用。代码非常简洁：首先读取快照数据，获取我们之前通过GMA3 status看到的JSON状态文件，从中提取快照提供的端点URL。关键点在于：现有兼容OpenAI或其他服务商的代码只需修改URL即可复用，无需API密钥，因为所有操作都在本地完成。

当同一台机器运行多个快照和模型时，每个模型都有独立URL。代码会查询可用模型列表，确定要使用的模型后，通过相同逻辑处理流式传输、构建消息内容并输出结果。这种设计让开发者能专注业务逻辑，无需处理底层硬件适配或依赖管理——这正是快照技术带来的生产效率提升。

那么，如何基于已安装的模型快照构建应用呢？这就是我展示的“chat”应用——它是一个Python脚本。让我们逐行解析这个简洁的代码文件。 代码首先读取快照数据，获取我们之前通过GMA3 status命令查看的JSON状态文件。该文件包含快照提供的本地推理端点URL。关键设计在于：现有兼容OpenAI或其他云服务API的代码库可以原样复用，唯一需要修改的只是将请求目标从远程服务器改为这个本地端点。由于所有推理都在用户设备完成，自然无需API密钥。

当同一台机器运行多个模型快照时（比如同时安装了Gemma 3和其他模型），每个模型会独立监听不同URL。代码会动态查询可用模型列表，根据业务需求选择特定模型。无论是流式传输处理、消息体构建还是结果输出，都沿用标准API规范——这本质上是个本地化的聊天应用，与我们刚刚演示的快照测试逻辑一致。

构建过程也极简高效：只需执行snapcraft build命令，或将其写入Makefile实现自动化构建。这种设计让开发者既能享受本地部署的低延迟优势，又能复用成熟的云端应用开发范式，真正实现“一次开发，全场景部署”的愿景。

构建流程极为简洁：执行snapcraft build命令即可，我通常将其写入Makefile实现自动化。相关代码库会公开上线，无需担心复现问题。实际构建时，先执行snapcraft build编译，再通过snap install关联Gemma模型进行测试。

现在演示Makefile构建过程：执行make build时可能遇到经典错误（如用户权限问题），这正是珍贵的教学案例——只需将用户加入LXD组即可解决。权限生效后重新构建，由于项目已缓存，构建速度极快。最终会生成可安装的包文件，执行make install即可完成本地部署，生成demo-app命令行工具。

现在我想展示测试环节——通过向聊天接口发送curl请求，我们可以实时观测到每秒处理的token数量，这是最贴近实际场景的性能验证。当发送测试提示后，系统展现了惊人的处理速度：每秒可处理70至80个token，而这仅仅是我们在DGX Spark上对该模型进行初步优化的成果。未来通过缓存机制升级和持续调优，还能进一步提升token处理速率。

接下来演示的是我的demo应用——执行这个Python脚本后，系统会调用本地推理端点完成交互。或许有人会说“聊天应用早过时了，现在都2025年”，但事实证明这类应用依然实用有效。不过更值得关注的是，我们正见证AI真正融入应用内核的变革：当用户使用这些应用时，会感受到后台有股“魔法力量”在运作，却无需知晓具体实现细节。

我构建的另一个应用更贴合实际需求——它并非原创，而是基于聊天应用代码改造而来。核心功能是读取本地存储的敏感PDF文件（内含不可外泄的机密信息），并完成文件摘要生成。这种设计完美解决了传统方案中“敏感数据需上传云端”的痛点，所有处理均在本地完成，既保障了数据安全，又充分发挥了本地推理的高效优势。

该应用首先提取PDF文本内容，随后基于提取的文本调用相同代码逻辑，并赋予系统提示词：“你是一位擅长文档摘要与冗余信息剔除的助手，请总结这份PDF文件。” 以Nvidia Jetson Thor技术文档为例——虽然VS Code可能无法直接显示PDF，但通过本地推理可生成摘要。

具体到代码层面，PDF摘要器通过系统提示词驱动模型完成分析。构建流程沿用之前的Makefile，已预先完成编译。运行本地PDF摘要器处理Thor文档时，所有操作均在设备端完成，无需上传云端。生成的摘要清晰呈现了Nvidia Jetson Thor作为高性能物理AI平台的特性、核心功能及技术参数。

这一设计的核心价值在于：应用代码可直接调用封装在snap包中的AI模型，形成依赖链——snap包可相互依赖，类似Android/iOS开发中系统级库的调用方式。在Ubuntu生态（涵盖DGX Spark、Jetson Thor及多数AI云服务器）中，这种依赖管理机制能让开发者将应用与系统级AI能力深度整合，实现“开箱即用”的部署体验。

两个演示案例的代码均将开源至GitHub，无需担心复现问题

https://github.com/abdelrahmanhosny/embedded-ai

这些内容包含相关教程——若在谷歌搜索"inference snaps"，你会在Ubuntu平台找到它们。所有资源均为开源：我们打包发布的模型是开源的，用于封装这些snap的模板（仅需使用snapcraft工具）同样开源。所有项目均托管于GitHub，欢迎贡献代码。若你心仪某款开源模型，目前我们已支持Gemma 3 Quan 2.5、DeepSeek R1等，并持续扩展模型库与硅基硬件优化方案。欢迎在GitHub讨论区反馈试用体验。