vLLM 从 day 0 支持 Recursive 的 Flint 模型

vLLM 从第 0 天起就支持 Recursive 的 Flint。其 NVFP4 和 BF16 检查点均可在单块 GPU 上运行，在单块 GB200 上，即使上下文长达 100K token，单个请求的解码速度也约为 500 token/s。

Flint 是一个 40B 参数的 MoE，每个 token 仅激活约 2.5B 参数，大多数层采用滑动窗口注意力，上下文长度为 262K token。它以两个独立的检查点形式发布：NVFP4（量化感知训练）和 BF16。

快速开始

第 0 天的 Docker 镜像 vllm/vllm-openai:flint（x86_64 和 arm64，CUDA 13.0）已内置 Flint 支持：

# NVFP4 checkpoint (GGUF): config and tokenizer come from the BF16 repo
docker run --gpus all --ipc=host -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:flint \
  RecursiveSI/flint-nvfp4-gguf \
  --hf-config-path RecursiveSI/flint --tokenizer RecursiveSI/flint \
  --enable-auto-tool-choice --tool-call-parser glm47 \
  --reasoning-parser glm47 --exclude-tools-when-tool-choice-none
 
# BF16 checkpoint
docker run --gpus all --ipc=host -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:flint \
  RecursiveSI/flint \
  --enable-auto-tool-choice --tool-call-parser glm47 \
  --reasoning-parser glm47 --exclude-tools-when-tool-choice-none

Flint 支持正在合并到 vLLM 中（#62938）。使用包含该支持的 vLLM 构建，以相同方式提供服务：

# NVFP4 checkpoint (GGUF): config and tokenizer come from the BF16 repo
vllm serve RecursiveSI/flint-nvfp4-gguf \
  --hf-config-path RecursiveSI/flint --tokenizer RecursiveSI/flint \
  --enable-auto-tool-choice --tool-call-parser glm47 \
  --reasoning-parser glm47 --exclude-tools-when-tool-choice-none
 
# BF16 checkpoint
vllm serve RecursiveSI/flint \
  --enable-auto-tool-choice --tool-call-parser glm47 \
  --reasoning-parser glm47 --exclude-tools-when-tool-choice-none

模型架构

Flint 是一个 49 层的 pre-norm MoE，隐藏层大小为 2048。其与众不同之处在于，只有很少一部分会关注整个上下文。

图 1：Flint 的层堆栈及其两个子层。金色标记表示与标准 pre-norm MoE 不同之处。全屏打开。

以局部注意力为主。35 层使用 RoPE 关注 513 token 的滑动窗口；其余 14 层关注完整上下文，不使用位置编码。只有这 14 层会为整个序列保留 KV，因此缓存成本为每 token 28 KiB。
可学习的注意力汇、GQA（32 个查询头和 4 个 KV 头），以及逐头 Q/K RMSNorm。
256 个专家，sigmoid top-6，外加一个共享专家。第 0 层和第 1 层改用稠密 MLP。

NVFP4 检查点是一个 GGUF 文件，其块采用 NVIDIA 的 NVFP4 格式，但字节序不同。vLLM 在加载时无损地重新打包，并以仅权重量化（W4A16）方式运行，激活和 KV 缓存使用 BF16，与 Recursive 的参考实现一致。每个 Flint 内核都遵循参考实现的舍入点，并在 GSM8K、GPQA-Diamond、长上下文 MRCR 和一套工具调用测试上与其精度一致。

优化

我们的第一个实现基于 vLLM 的现成层构建，在小批量下速度很慢：一个解码步骤运行了 1,096 个内核，其中许多是针对大得多的批量调优的。我们逐一用 Flint 专用内核替换它们，并对照参考实现检查每一项更改。

图 2：每次更改后在单块 GB200 上的模型前向延迟，针对 100K 上下文下的批量 1 解码和 8,192 token 的预填充。切换检查点，或显示每种形状的表格。全屏打开。

融合 Q/K norm、RoPE 和 KV 缓存写入（−8%）：一个内核代替三个。
小批量 MoE 内核（−27%）：路由器和专家 GEMV 仅读取所选专家的权重。这也是预填充的最大收益。
小批量稠密 GEMV（−25%），使用与大批量内核相同的打包 NVFP4 权重。
Norm 和 SiLU 内核（−10%），遵循参考实现的舍入。
解码注意力（−5%），支持汇和滑动窗口，使用 CuTe DSL。
低延迟解码路径（−14%），如下所示。

对于最多 8 个请求，低延迟路径将每个 MoE 层作为七个内核运行：Q/K norm、RoPE、路由和专家组合被融合到相邻的 GEMV 内核中。每个内核都通过程序化依赖启动（programmatic dependent launch）启动，因此它会在前一个内核仍在运行时加载自己的权重。

图 3：低延迟解码路径上一个 MoE 层的七个内核。

总体而言，NVFP4 解码从 4.81 ms 降至 1.78 ms（2.7×），BF16 解码从 3.53 ms 降至 2.34 ms（1.5×），8K token 的 prefill 从 207 ms 降至 145 ms（1.4×）。一次前向现在运行 346 个 kernel，而不是 1,096 个。端到端服务时，100K 上下文下的 batch-1 解码每 token 耗时 2.06 ms（约 485 tokens/s），这包括前向加上 LM head 和采样。

使用说明

Flint 输出 GLM-4.7 风格的 tool calls 和 thinking blocks，因此需要 glm47 解析器。当 tool_choice 为 "none" 时，--exclude-tools-when-tool-choice-none 会从 prompt 中移除 tool definitions，与参考实现一致。
默认采样设置为 temperature 1.0、top-p 0.95 和 top-k 20。推理过程计入 max_tokens，因此难题至少预留 32K。
Flint kernels 面向单块 Blackwell GPU（TP=1，BF16 KV cache）；其他配置回退到 vLLM 的标准层。