在 DGX Spark 上跑多模型 Agent 协作：如何通过资源调度压低推理成本
最近我们团队在 DGX Spark 集群上尝试了一套针对多模型 Agent 优化的推理栈，核心目标就是解决多模型共存时的资源调度问题，尝试在不增加硬件投入的前提下，通过调度机制提升资源利用率。
最令我们意外的是，在完全没有开启投机采样（Speculative Decoding）且没有进行量化处理的情况下，这套推理栈在处理不同规模模型时的吞吐量表现依然非常强劲。我们使用了 2 台 DGX Spark 集群进行了实测，具体的 Decode 速度数据如下：
首先是 DeepSeek V4 Flash (C4)，其实测 Decode 速度达到了 55.99 tok/s；其次是 Gemma 4 26B A4B (C4)，速度为 63.75 tok/s；而表现最出色的是 Nemotron 3 Nano Omni 30B NVFP4 (C4)，其 Decode 速度直接冲到了 90.83 tok/s。
这组数据证明了在高性能集群环境下，即使不依赖量化带来的精度损失，通过优化推理栈的调度，依然能获得极高的吞吐效率。
为了验证这套方案在实际 Agent 工作流中的可行性，我们设计了一个比较极端的测试场景：在同一个端点（Endpoint）下，由调度器动态控制三个不同模型的激活与切换。这种方式本质上是在用“时间”换“空间”，即通过微小的延迟来换取显存的共享。
实测结果显示，模型激活的等待时间分布在 2s 到 16s 之间。虽然这种切换延迟对于需要极低实时性的 C 端对话产品来说可能不够理想，但对于企业级的异步工作流（例如自动化报表分析、代码审计等）而言，这种延迟完全在可接受范围内。相比于为每个模型单独购买独立显卡，这种通过调度来压低成本的方案在经济账上要划算得多。
目前这套方案虽然已经达到了较高的吞吐量，但仍有优化空间。如果后续在现有基础上开启投机采样，预计上述的 Decode 速度数字还能进一步上涨。
对于那些需要在私有化环境下部署 AI Agent，且对计算成本极其敏感的团队来说，我建议不要盲目追求为每个模型分配独立资源，而应尝试构建一套多模型共享的推理栈。这种思路能让团队在有限的 GPU 资源下，支撑起更复杂、多模型协作的 Agent 链路，从而真正实现 AI 能力在业务端的高效落地。
