什么是 Flare？
Flare 是一个专为 NVIDIA SM120 和 SM121 GPU 设计的本地推理服务器。它面向长对话、编码代理以及反复调用工具的工作负载。其核心目标是在保持文本生成响应速度的同时，高效利用工作站和紧凑型系统的资源。
不同于优先考虑广泛兼容性的服务平台，Flare 围绕选定的模型、硬件、内核和部署模式，采用了一套专门的契约。这种更聚焦的范围使模型准备、内存管理、调度和执行能够协同设计。
当 Flare 支持的模型方案、预先准备的容量以及 NVIDIA 硬件要求与本地工作负载相匹配时，它最为适用。
架构如何工作
Flare 将模型准备和运行时服务划分为两个主要组件：Ignition 和 Helios。
Ignition：构建时模型准备
Ignition 运行在标准 Python 机器学习生态中。它使用 PyTorch、Transformers 和 FlashInfer/b12x 来加载模型、调优内核、编译前向传播并捕获 CUDA 图。
其结果是一个准备好的运行时软件包。编译和 CUDA 图捕获会在服务开始前完成，因此生产运行时无需执行这些准备步骤。
Helios：基于 Rust 的服务运行时
Helios 是用于提供 Ignition 生成的软件包的 Rust 运行时。它无需 Python 即可运行，负责调度、缓存存储、请求处理以及运行时资源的显式所有权管理。
模型方案
-> Ignition 准备
-> 内核调优和前向传播编译
-> CUDA 图捕获
-> 运行时软件包
-> Helios 服务这一边界让模型开发能够继续使用熟悉的 Python 工具，同时使服务运行时保持小巧且专注。
主要功能
- 专注于 NVIDIA 支持：Flare 专为 NVIDIA SM120 和 SM121 GPU 设计，而不是面向广泛的加速器范围。
- 构建时使用 Python：模型准备使用 PyTorch、Transformers 和 FlashInfer/b12x。
- 运行时使用 Rust：Helios 无需 Python 即可提供准备好的软件包。
- 服务前优化：内核调优、前向传播编译和 CUDA 图捕获会在处理请求前完成。
- 显式内存规划：缓冲区和执行容量会提前规划。
- 完整的对话状态：Flare 将循环状态和 KV 缓存视为统一的对话状态，以实现正确的复用、分支和恢复。
- 方案驱动的模型支持：模型方案定义模型计算，并在必要时针对布局或执行进行专门处理。
- 面向本地工作负载：该系统面向本地机器上的长会话、编码代理和重复工具调用。
前置条件与设置
尝试使用 Flare 前，请确认你的环境符合其有意限定的适用范围。
- 确认 GPU 架构。Flare 面向 NVIDIA SM120 和 SM121 GPU。README 未声称支持其他 GPU 架构。
- 选择受支持的模型方案。Flare 不承诺普遍兼容所有模型。模型必须符合可用方案及其预期数据流。
- 规划运行时容量。确定预期对话和请求所需的缓冲区及执行容量。
- 准备 Python 构建环境。Ignition 在模型准备期间依赖 PyTorch、Transformers 和 FlashInfer/b12x。
- 准备模型软件包。使用 Ignition 加载模型、调优内核、编译前向执行并捕获 CUDA 图。
- 使用 Helios 提供服务。准备完成后，将生成的运行时软件包提供给 Rust 服务运行时。
README 未提供确切的安装命令、依赖版本或启动参数。请按照仓库的模型准备和服务指南执行权威流程。配置详情请参阅CLI 指南。
基本使用流程
Flare 的基本流程是先准备、后提供服务。以下示例仅用于说明概念，并非可执行的 CLI 语法，因为 README 未定义具体命令。
第 1 步：选择兼容的模型
从 Flare 方案覆盖的模型开始。方案负责模型计算，并可在数据流匹配时复用规范模型实现。如果需要不同的布局或执行行为，方案会对相应部分进行专门处理。
第 2 步：确定所需容量
估算准备好的软件包必须支持的工作负载。考虑对话长度、并发执行需求、缓存使用、循环状态以及重复的工具交互。Flare 要求在提供服务前规划重要的缓冲区和容量。
第 3 步：构建运行时软件包
通过 Ignition 运行准备流程。在此阶段，Flare 使用 Python 生态来执行耗时的设置工作。
输入：
受支持的模型方案
模型参数
规划的执行容量
Ignition 执行：
模型加载
内核调优
前向传播编译
CUDA 图捕获
输出：
准备好的运行时软件包第 4 步：启动 Helios
配置 Helios 以提供已准备好的软件包。Helios 负责请求处理、调度和缓存存储，服务运行时无需使用 Python。有关实际配置选项和启动接口，请参阅 CLI 文档。
第 5 步：运行目标工作负载
使用真实的长对话、编码代理会话和工具调用模式测试 Flare。简短的合成提示可能无法暴露与 Flare 设计目标工作负载相同的状态管理、内存流量或调度行为。
理解对话状态
Flare 将对话状态视为不只是 KV 缓存。当模型同时使用循环状态时，该状态必须与缓存保持同步。Flare 将这些元素作为一个整体进行管理，因此复用、分支和恢复等操作能够正确保留完整对话。
这种设计对代理尤其重要。代理可能会暂停等待工具结果，在评估不同方案时创建分支，或恢复之前的会话。只保留模型状态的一部分，可能会导致后续行为不正确。
高级提示
根据实际所需容量进行准备
由于执行容量和缓冲区会提前规划，准备工作的选择会直接影响可提供的服务。不要假设一个软件包适用于所有上下文长度、并发级别或模型配置。请遵循项目文档中的容量规则。
避免在服务路径中进行编译
在开始生产服务前，让 Ignition 完成内核调优、前向编译和 CUDA 图捕获。这种分离是 Flare 设计的核心部分，而不是可选优化。
将状态视为原子单元
实现对话复用、分支或恢复时，请保留 Flare 管理的完整状态。避免设计出假定 KV 缓存始终是模型唯一持久状态的集成。
以配方作为模型边界
将模型特定的计算放入模型配方中，并将调度、请求处理和缓存存储交给运行时。这遵循 Flare 的职责分离原则，有助于让共享运行时专注于核心功能。
根据实际工作负载进行基准测试
Rust 提供了明确的资源所有权，但仅凭实现语言并不能保证更高的推理性能。GPU 计算、内存流量、调度、模型结构和工作负载形态仍然十分重要。
如需覆盖更广泛的模型、硬件或部署场景，请将 Flare 与 vLLM 进行比较。两种系统都可以使用 CUDA 图，但在范围和设计权衡上有所不同。请针对计划部署的确切模型、对话模式、容量和机器进行基准测试。
阅读设计文档
如需深入了解运行时、模型配方、状态管理和调度边界为何采用这种结构，请参阅仓库中的核心设计文档。
结论
Flare 为 NVIDIA SM120 和 SM121 GPU 上的特定模型提供了专用的本地推理路径。Ignition 使用熟悉的 Python 工具准备经过优化的运行时软件包，而 Helios 则通过精简的 Rust 运行时提供服务。它最适合有计划的本地工作负载，包括长对话、编码代理、重复的工具调用，以及对内存和对话状态的显式管理。