NVIDIA也开源了专为DGX Spark与Blackwell打造的本地推理利器：Flare

NVIDIA 刚刚开源了一个叫Flare的本地推理服务项目。

https://github.com/NVIDIA/flare-local-inference

简单来说，Flare 是 NVIDIA 专门为自家最新硬件设计的本地推理服务器。它主要面向：

• DGX Spark（GB10 Grace Blackwell 桌面系统）
• 搭载 SM120 / SM121 架构的 RTX Blackwell 工作站显卡

它的目标很明确：让工作站和紧凑型系统（尤其是 DGX Spark）的内存、带宽和算力发挥得更充分，同时保持生成响应的流畅性。特别针对长对话、编码 Agent、反复工具调用这类场景做了优化。

Flare 的设计原则很有意思，可以概括为几句话：  

1. 构建时拥抱 PyTorch 生态，运行时用 Rust 服务
      模型准备、内核调优、CUDA Graph 捕获都在 Python（Ignition）侧完成。真正对外提供服务时，则由轻量的 Rust 运行时（Helios）接管，运行时不再依赖 Python。 
2. 内存与状态提前规划
      不像很多通用引擎那样“边跑边申请”，Flare 会提前规划缓冲区和执行容量，把对话状态（包括 KV Cache）当作一个整体来管理，方便复用、分支和恢复。
3. 默认使用 FP8 KV Cache
      在保持精度可接受的前提下，进一步节省显存/统一内存占用。
4. 专注而非通用
      官方明确表示：vLLM 覆盖的模型和硬件更广，而 Flare 主动牺牲了广度，换取在特定硬件和特定工作负载上的深度优化。只有准备好了对应 recipe 的模型才能跑。

时机也很巧。就在 Flare 公开前后，DeepSeek 也开源了自家生产环境使用的推理框架 DeepInfer（DeepSeek把推理优化卷到极致了，DeepInfer有多激进？）。两边几乎前后脚动作，让不少人感慨：本地推理引擎的竞争正在加速。

对于已经入手或准备入手 DGX Spark 的开发者来说，Flare 提供了一个更原厂的选择。它不追求什么模型都能跑，而是追求在支持的模型和硬件上，把长上下文 Agent 场景跑得更稳、更省、更响应。

项目目前还比较新（Apache 2.0 协议），没有正式 Release 标签，但代码提交活跃，已经有模型准备文档、CLI 说明和核心设计文档。支持 Windows（包括 ARM64）原生服务，也支持多机通过 ConnectX 组网。

如果你正好在做本地 Agent、长对话应用，或者已经有 DGX Spark / 新一代 Blackwell 工作站，这个项目值得关注一下。

vLLM 与 Flare 的核心区别对比

两者都属于 LLM 推理服务引擎，但定位差异很大。Flare 官方 README 也直接承认这一点：vLLM 覆盖更广的模型、硬件和部署模式，而 Flare 主动牺牲广度，换取在特定场景下的深度优化。

硬件支持

• vLLM：非常广泛。支持 NVIDIA（几乎全系）、AMD ROCm、Intel GPU、Google TPU 等，还能做多机多卡、disaggregated 部署。
• Flare：极度聚焦。仅支持 NVIDIA SM120 / SM121 架构（主要是 DGX Spark 的 GB10，以及部分 RTX Blackwell 工作站卡）。其他硬件基本跑不了。

模型支持

• vLLM：几乎覆盖当前主流开源模型，很多新模型能做到 Day-0 支持。支持多模态、MoE、各种量化格式。
• Flare：只支持有官方 recipe（准备好的包）的模型。模型需要先通过 Ignition 做准备、内核调优和 CUDA Graph 捕获，才能被 Helios 运行时加载。通用性明显更低。

运行时架构（最关键技术差异）

• vLLM：以 Python 为主（配合高性能内核），运行时仍有 Python 层，灵活性高，但有一定解释器开销。
• Flare：

  • 构建时（Ignition）：用 PyTorch + Transformers + FlashInfer 做模型加载、内核调优、CUDA Graph 捕获。
  • 运行时（Helios）：纯 Rust 实现，完全没有 Python。编译和 Graph 捕获在服务启动前全部完成。

这使得 Flare 的运行时更轻、资源所有权更明确，启动后开销更低，适合对延迟和资源占用敏感的本地场景。

内存与状态管理

• vLLM：经典的 PagedAttention + 连续批处理 + 前缀缓存等，动态管理 KV Cache，适合高并发、变长请求。
• Flare：强调提前规划内存和执行容量。把对话状态（包括 KV Cache）当作一个整体统一管理，方便长对话的复用、分支和恢复。默认使用 FP8 KV Cache，进一步节省统一内存。

更适合选 vLLM 的情况：

• 需要快速支持各种新模型
• 硬件不统一（或有 AMD/TPU 等）
• 云端高并发生产服务
• 想要最大灵活性和社区生态

更适合选 Flare 的情况：

• 你有 DGX Spark 或对应 Blackwell 工作站
• 主要做本地长对话 / Agent / 工具调用场景
• 希望运行时更干净（无 Python）、内存规划更可控
• 愿意接受“只支持部分模型”的限制，换取在目标硬件上的针对性优化

一句话总结

• vLLM 是“全能选手”，适合绝大多数通用部署需求。
• Flare 是 NVIDIA 为自家最新本地硬件（尤其是 DGX Spark）量身定制的“专精选手”，在长上下文 Agent 场景上做了更激进的取舍。

目前 Flare 还比较新（2026 年 10 月刚公开），性能数据还需要社区实测验证。官方也建议：在真实模型和真实工作负载上直接对比两者。