vLLM 首日支持 Recursive 的 Flint 模型

vLLM 从一开始就支持 Recursive 的 Flint。它的 NVFP4 和 BF16 检查点都在单个 GPU 上运行，在单个 GB200 上，单个请求解码速度约为 500 个 token/s，即使有 100K 个 token 的上下文。

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 层的预规范 MoE，隐藏大小为 2048。让它与众不同的是，它很少查看整个上下文。

图 1：Flint 的层堆栈及其两个子层。金色标记了它与标准预规范 MoE 的不同之处。在全屏中打开它.

• mostly local attention。35 层使用 RoPE 关注 513 个 token 的滑动窗口；其余 14 层使用无位置编码关注整个上下文。只有这 14 层保留整个序列的 KV，因此缓存成本为每个 token 28 KiB。
• learned attention sinks，GQA 使用 32 个查询头和 4 个 KV 头，以及每头 Q/K RMSNorm。
• 256 个专家，sigmoid top-6，加上一个共享专家。第 0 层和第 1 层使用密集 MLP。

NVFP4 检查点是一个 GGUF 文件，其块以不同的字节顺序使用 NVIDIA 的 NVFP4 格式。vLLM 在加载时无损地重新打包它，并以 weight-only (W4A16) 运行，使用 BF16 激活和 KV 缓存，就像 Recursive 的参考实现一样。每个 Flint 内核都遵循参考的舍入点，并且在 GSM8K、GPQA-Diamond、长上下文 MRCR 和一个工具调用套件上与它具有相同的准确性。

优化

我们的第一个实现，是从 vLLM 的标准层构建的，在较小的批处理大小上运行缓慢：一个解码步骤运行了 1,096 个内核，其中许多内核是为更大的批处理大小调优的。我们逐个替换它们为 Flint 特定的内核，并逐一检查每个内核与参考。

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

• fused Q/K norm, RoPE 和 KV-cache write（−8%）：一个内核代替三个。
• small-batch MoE kernels（−27%）：路由器和专家 GEMVs 只读取选定专家的权重。也是最大的预填充增益。
• small-batch dense GEMV（−25%）在相同的打包 NVFP4 权重上，就像大批处理内核一样。
• norm 和 SiLU kernels（−10%）遵循参考的舍入。
• decode attention（−5%）具有 sinks 和滑动窗口，在 CuTe DSL 中。
• low-latency decode path（−14%），如下所示。

对于最多 8 个请求，低延迟路径将每个 MoE 层作为七个内核运行：Q/K 规范、RoPE、路由和专家组合融合到相邻的 GEMV 内核中。每个内核都使用程序依赖启动，因此在前一个内核仍在运行时加载其权重。

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

总共，NVFP4 解码从 4.81 毫秒降至 1.78 毫秒（2.7 倍），BF16 解码从 3.53 毫秒降至 2.34 毫秒（1.5 倍），8K 令牌预填充从 207 毫秒降至 145 毫秒（1.4 倍）。现在前向运行 346 个内核，而不是 1,096 个。端到端服务，100K 上下文批处理-1 解码每令牌耗时 2.06 毫秒（约 485 令牌/秒），这是前向加上 LM 头和采样。

使用说明

• Flint 发出 GLM-4.7 风格的工具调用和思考块，因此需要 glm47 解析器。--exclude-tools-when-tool-choice-none 在 tool_choice 是 "none" 时从提示中删除工具定义，与参考匹配。
• 默认采样设置为温度 1.0，top-p 0.95 和 top-k 20。推理计入 max_tokens，因此对于难题至少允许 32K。
• Flint 内核针对单个 Blackwell GPU（TP=1，BF16 KV 缓存）；其他配置回退到 vLLM 的标准层。