AREX-2部署前必查：config.json相同的陷阱

当微调模型声明与已有模型相同的架构类时，最诱人的做法就是换掉 --model-path 然后重启服务。BAAI 的 AREX-2 正好可以检验这个习惯是否可靠。这是一个 27B 模型，被训练为分轮次解决复杂问题——提出方案、测量结果、反思修正——采用 Apache 2.0 协议、不受门控限制，其 config.json 开头写着 Qwen3_5ForConditionalGeneration，与 Qwen 团队的 Qwen3.8-27B 属于同一个类。

我们此前一直用 sglang 服务基础版 Qwen3.8-27B，因此对比了两者的配置。先说一句：我们尚未运行 AREX-2，以下所有速度数据均来自基础模型。完整表格、命令和来源见 inferencekey.com 的 AREX-2 服务分析。

rss source: Same config.json, different serve command: what to check before serving AREX-2

看似“即插即用”的差异

BAAI 发布了一个干净的版本：层布局、注意力头数、上下文长度、词表和视觉塔全部与 Qwen3.8-27B 匹配。配置仅在 transformers_version 和两个冗余的顶层键上有所不同，而负责格式化对话和工具调用的 chat_template.jinja 文件甚至逐字节相同。

如果读到这里就停下，你会直接把旧命令搬过去用。这恰恰是第一个陷阱。

MTP（Multi-Token Prediction，多令牌预测）头 是一种在大模型主干之上附加的小型预测模块，通常由一到数个额外的 Transformer 层构成。它的作用是在每一步解码中不仅预测下一个令牌，还同时预测紧随其后的若干个令牌——这些预测会作为候选提交给主模型并行验证。若验证通过，服务器就能在一次前向传播中输出多个令牌，从而显著提升吞吐。代价是权重体积和显存占用增加，且预测准确率取决于训练时与主模型的对齐程度。由于 MTP 头属于附加结构，很多微调流程会冻结或直接丢弃它，导致 config.json 中的声明与实际发布的 safetensors 权重不一致——这正是 AREX-2 的情况。

safetensors 索引文件（通常命名为 model.safetensors.index.json）是 Hugging Face 生态中用于分片权重的清单，它逐条列出了发布版本中每一个张量的名称及其所在分片文件。相比 config.json 中声明的架构参数，索引文件反映的是实际存在的权重，因此是判断“模型到底带了什么”最可靠的依据。检查索引中是否存在以 mtp 为前缀的张量，就能立即确认 MTP 头是否真正随权重发布。

检查权重，而非配置

基础模型带有一个多令牌预测（MTP）头——一个小型额外层，用于提前预测几个令牌，从而让服务器每步输出多个令牌。AREX-2 的配置仍然声明了它，但它的权重文件中并不包含。

config.json                    "mtp_num_hidden_layers": 1
safetensors index (AREX-2)     0 mtp tensors
safetensors index (Qwen3.8)    15 mtp tensors

safetensors 索引列出了发布版本中的每一个权重张量，是诚实的清单。配置字段只是一个承诺，必须检查背后是否有实际支持。

第二个安静的变化发生在 tokenizer_config.json 中，它控制文本如何被切分成令牌。社区重新打包报告称，预分词器和解码器设置与 Qwen3.8 不同。可能无害，但也可能在 agent 运行数小时后表现为乱码的工具调用。

对基础模型正确的标志

我们最快的基模型设置运行在 RTX PRO 5000 的 CUDA 13 pod 上，使用 RadixArk 的 NVFP4 量化（权重压缩为 4 位浮点）和 z-lab 的 DFlash2 草稿模型，解码速度达到 115–136 tok/s。但换成 AREX-2 后，这些几乎都不再适用：

尚无 AREX-2 的 NVFP4 构建版本。 目前可选 BAAI 的 BF16 原版（54.7 GB）、prithivMLmods 的 FP8（35.9 GB）、cyankiwi 的 AWQ INT4（20.2 GB）或 numsu 的 INT4 W4A16（18.6 GB）。
草稿模型是针对另一个模型训练的。 投机解码让一个小草稿模型提出候选令牌，大模型一次验证；只有当大多数猜测被接受时才划算。z-lab 的 DFlash2 草稿模型针对基础 Qwen3.8-27B，而微调会改变模型偏好的令牌，因此它在 AREX-2 上的命中率无人知晓。numsu 的 INT4 卡片确实公布了两张 RTX 3090 上搭配 DFlash2 草稿模型的速度，但没有给出接受长度。
mamba_ssm_dtype。 AREX-2 要求 float32。我们的基础命令强制使用 bfloat16，这在 Qwen3.8 上没问题，但在一个为长反思运行调优的模型上尚未验证。
解析器是猜测。 这些 sglang 选项将原始模型文本转换为独立的推理和工具调用字段。qwen3 和 qwen3_coder 应该可用，因为模板匹配。但目前没有公开的 AREX-2 sglang 运行结果。
在长上下文和投机解码之间二选一。 基础模型的 1M 上下文是一个 YARN 覆盖，拉伸了其原生 262,144 位置，而 DFlash2 无法与之同时运行。因此：要么 1M 无草稿模型，要么 256K 带草稿模型。

NVFP4、FP8 与 INT4/W4A16 是三种不同的量化格式，对硬件的要求也各不相同。NVFP4 是 NVIDIA 在 Blackwell 及之后架构上推出的 4 位浮点格式，权重压缩率高且精度损失可控；FP8（E4M3/E5M2）需要 Ada、Hopper 或更新架构才具备原生张量核心支持；INT4 系列（如 AWQ、W4A16）则是最通用的方案，W4A16 表示权重 4 位、激活 16 位，几乎所有现代 GPU 都能通过反量化内核运行。

投机解码（Speculative Decoding） 的收益完全取决于接受长度（acceptance length）：草稿模型每轮提出 K 个候选令牌，主模型一次性验证，只有被接受的前缀才真正生效。接受长度越高，单步产出的令牌数越多，加速越明显；若接受长度接近 1，投机解码反而因额外开销而拖慢速度。草稿模型与主模型的分布越接近，接受长度越高——这正是“微调会改变模型偏好令牌，因此为基模型训练的草稿模型在微调版上命中率未知”的原因。

Ampere 上跑 FP8 是昂贵的错误

RTX A6000 是 Ampere 架构，没有 FP8 硬件，因此 sglang 将权重保持为 FP8 并通过 Marlin 内核即时解包。基础 Qwen3.8-27B 在该卡上解码速度为 24 tok/s；而 RedHatAI 的 INT4 W4A16 量化在相同卡、相同 1M 上下文下达到 41 tok/s。prithivMLmods 的 AREX-2 FP8 卡片也同意全速需要 Ada、Hopper 或更新架构。A100 也是 Ampere，因此也应选择 INT4。

权重不是全部开销。在基础模型的 INT4 1M 上下文运行中，sglang 占用约 46 GB，其中仅 17.8 GB 是权重，另外 11.5 GB 用于线性注意力层的状态，12.8 GB 用于 KV 缓存——模型保存的每令牌内存，避免每步重读整个上下文。AREX-2 的每 GPU 显存估算从 80 GB 到 24 GB 逐卡列出，仅供参考。

Marlin 内核 是 sglang、vLLM 等推理框架中用于在缺少原生低精度硬件支持的 GPU 上运行量化权重的高性能反量化矩阵乘内核。当模型权重以 FP8 存储但硬件（如 Ampere 架构的 A6000、A100）没有 FP8 张量核心时，框架必须在每次计算前将权重即时反量化回 16 位，这一步会消耗额外的显存带宽和计算周期，使实际解码速度反而低于直接使用 INT4 量化的方案。因此“更低的位宽一定更快”并不成立——量化格式与硬件架构的匹配度，往往比位宽本身更重要。

YARN（Yet Another RoPE extensioN） 是一种通过缩放旋转位置编码（RoPE）的频率来实现上下文长度外推的方法：模型在原生训练长度（如 262,144）上训练，推理时通过调整 RoPE 的缩放参数把有效位置范围拉伸到更长的序列（如 1M）。它不需要重新训练，但外推长度越大，长距离注意力精度衰减越明显。此外，YARN 的缩放配置通常与投机解码的草稿模型不兼容，因此实践中常需要在“长上下文”和“投机加速”之间二选一。

首次运行时应该测量什么

从最朴素的方法开始：在 80 GB 卡上跑 BF16、原生 256K 上下文、不加投机标志、使用相同的解析器、执行一个长 agent 任务。然后每次只改一个变量，像试音从底鼓开始一样。关注以下指标：

由于分词器变化，长会话后期工具调用能否干净解析
解码 tok/s 与同卡基础模型的对比，共享架构下应该匹配
若添加草稿模型，接受长度是多少——这个数字无人公布
每任务 GPU 小时数，因为基准协议允许每个案例最多 1,500 次模型调用和 24 小时

最后一项决定经济性。AREX-2 自我报告的 Frontier-CS 得分 70.7 和 BrowseComp 得分 84.0 来自 BAAI 评估仓库中的长协议，我们找不到独立复现。按小时租 GPU 只有在卡片持续有任务排队时才比按令牌定价划算，例如并排跑多个案例。对于单 GPU agent 设置，参见我们之前关于在单张租用 A100 上部署 80B 编码模型并由 Claude Code 驱动的文章。

这是一个合理的一卡项目，感谢 BAAI 和 Qwen 团队提供模型，prithivMLmods、cyankiwi、numsu、RedHatAI 和 RadixArk 提供量化，z-lab 提供 DFlash2，numsu 再次提供在 AREX-2 输出上训练的实验性 MTP 头，AI Search 提示发布，以及 sglang 和 vLLM 项目。配置表、基模型命令原文、慢启动的 worker 设置和完整限制列表见完整的 AREX-2 单 GPU 部署文章。