vLLM 发布 Flint 模型 Day-0 支持

出处作者 / 发布主体：Inferact and Recursive原标题：Day-0 Support for Flint on vLLM

78AI 研判分

核心综述

vLLM 宣布对 Recursive 推出的 40B MoE 模型 Flint 提供 Day-0 支持。该模型在单张 GB200 GPU 上可实现约 500 tokens/s 的解码速度，并支持 NVFP4 和 BF16 两种量化检查点及 262K 长上下文。开发者可通过专用 Docker 镜像快速部署。

报道全文原始报道全文

本文目录4 个章节

vLLM 从第一天起就支持 Recursive 的 Flint。其 NVFP4 和 BF16 检查点均可在单张 GPU 上运行，即使在拥有 100K token 上下文的情况下，单个请求在一张 GB200 上的解码速度也能达到 约 500 tokens/s。

Flint 是一个拥有 40B 参数的 MoE（混合专家）模型，每个 token 仅激活约 2.5B 参数。它在大多数层中采用滑动窗口注意力机制，并支持 262K token 的上下文长度。该模型提供两个独立的检查点：NVFP4（经过量化感知训练）和 BF16。

快速开始

Day-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 的层级堆栈及其两个子层。金色标记了与标准预归一化 MoE 不同的部分。全屏查看。

以局部注意力为主。 35 层使用 RoPE 关注 513 token 的滑动窗口；其余 14 层关注完整上下文且无位置编码。只有这 14 层为整个序列保留 KV，因此缓存开销为每 token 28 KiB。
可学习的 attention sinks、GQA（32 个 query 头和 4 个 KV 头），以及 per-head Q/K RMSNorm。
256 个 experts，sigmoid top-6，外加一个 shared expert。 第 0 和 1 层使用 dense MLP 代替。

NVFP4 checkpoint 是一个 GGUF 文件，其 blocks 采用 NVIDIA 的 NVFP4 格式，但字节序不同。vLLM 在加载时对其进行无损重打包，并以 weight-only (W4A16) 模式运行，激活值和 KV cache 均为 BF16，这与 Recursive 的参考实现一致。每个 Flint kernel 都遵循参考实现的舍入点，并且在 GSM8K、GPQA-Diamond、长上下文 MRCR 和工具调用套件上的准确率与参考实现匹配。

优化

我们的第一个实现基于 vLLM 的标准 layers，在小 batch size 下速度较慢：一次 decode step 需要运行 1,096 个 kernels，其中许多是为更大的 batch size 调优的。我们逐个替换为 Flint 专用的 kernels，并对照参考实现进行检查。

图 2：每次更改后，单个 GB200 上的模型前向延迟，针对 100K 上下文的 batch-1 decode 和 8,192-token prefill。切换 checkpoint，或显示所有 shape 的表格。全屏打开.

融合 Q/K norm、RoPE 和 KV-cache write (−8%)：用一个 kernel 替代三个。
小 batch MoE kernels (−27%)：router 和 expert GEMVs 仅读取被选中 experts 的权重。这也是 prefill 阶段最大的增益来源。
小 batch dense GEMV (−25%)，使用与大 batch kernel 相同的 packed NVFP4 权重。
Norm 和 SiLU kernels (−10%)，遵循参考实现的舍入规则。
Decode attention (−5%)，包含 sinks 和滑动窗口，使用 CuTe DSL 实现。
低延迟 decode path (−14%)，如下所示。

对于最多 8 个请求，低延迟路径将每个 MoE layer 作为七个 kernels 运行：Q/K norm、RoPE、routing 和 expert combine 被融合到相邻的 GEMV kernels 中。每个 kernel 通过 programmatic dependent launch 启动，从而在前一个 kernel 仍在运行时加载其权重。

图 3：低延迟 decode path 上单个 MoE layer 的七个 kernels。

总体而言，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 风格的工具调用和思考块（thinking blocks），因此需使用 glm47 解析器。当 tool_choice 为 "none" 时，--exclude-tools-when-tool-choice-none 参数会从提示词中移除工具定义，以匹配参考实现。
默认采样设置包括 temperature 1.0、top-p 0.95 和 top-k 20。推理过程计入 max_tokens，因此对于复杂问题建议至少预留 32K token。
Flint kernels 针对单张 Blackwell GPU（TP=1，BF16 KV cache）进行优化；其他配置将回退至 vLLM 的标准层实现。