体验 Intern-S2-Preview 的 MTP 加速：35B 科学多模态模型推理能快多少？

InternLM

470人浏览 · 2026-05-26 15:18:15

InternLM · 2026-05-26 15:18:15 发布

一、模型介绍

最近体验了上海人工智能实验室新发布的 Intern-S2-Preview 模型，它的定位比较有意思：不是单纯追求更大的参数规模，而是把重点放在多模态科学任务和推理速度上。它是一个 35B模型，在 Qwen3.5 的基础上继续预训练，并通过模型结构调整到强化学习的一整套科学任务训练流程，增强了模型在专业科学任务、通用推理、多模态理解以及 agent 工作流上的能力。

体验链接：

https://chat.intern-ai.org.cn/

GitHub链接：

https://github.com/InternLM/Intern-S1

HuggingFace链接：

https://huggingface.co/collections/internlm/intern-s2

ModelScope链接：

ModelScope 魔搭社区

二、 MTP 加速技术

Intern-S2-Preview 有一个比较值得单独体验的点：MTP (Multi-Token Prediction) 加速。官方在模型介绍中提到，Intern-S2-Preview 在 RL 阶段采用了 shared-weight MTP with KL loss，用于减少训练和推理行为之间的不匹配，并提升 MTP accept rate 和 token generation speed。同时，它还结合了 CoT compression，用来在保留推理能力的同时缩短回复长度。

简单说，MTP 可以理解为一种面向大模型生成阶段的“草稿加速”机制。普通自回归生成通常是一次预测一个 token：模型生成一个 token，再把这个 token 拼回上下文里，继续生成下一个 token。这个过程很稳定，但每一步都需要完整地跑一轮模型，长回复时延迟就会被不断累积。

MTP 的思路则是：先由模型内部的 MTP 模块一次性草拟多个后续 token，然后再交给主模型进行验证。如果这些草稿 token 和主模型的判断一致，就可以一次接受多个 token；如果中间某个 token 不匹配，就从这个位置回退，继续正常生成。这样一来，主模型不再是“每跑一轮只确认一个 token”，而是有机会“一轮确认多个 token”，从而减少生成轮数，提高整体 token 生成速度。

这里还有一个关键词叫 accept rate，也就是草稿 token 被主模型接受的比例。accept rate 越高，说明 MTP 草稿越靠谱，主模型每次验证后能批量接受更多 token，加速效果也就越明显。反过来，如果草稿经常被拒绝，MTP 不但加速有限，还可能带来额外开销。

Intern-S2-Preview 里提到的 shared-weight MTP，可以粗略理解为：不是为每个未来位置单独准备一套 MTP head，而是让多个预测步骤共享同一套 MTP 权重。这样做的好处是结构更统一，也更贴近推理时“递归生成多个草稿 token”的实际使用方式，因此有助于提升草稿 token 的质量和接受率。

三、推理加速评测

3.1 评测数据集： ShareGPT

这次测速使用的是 ShareGPT 数据集，这个数据集来自早期用户与 ChatGPT 的真实多轮对话记录，内容形式比较接近实际聊天场景，而不是单纯的随机字符串或者固定模板 prompt。因此，用它来做 serving benchmark 会更贴近真实在线推理服务中的输入分布。

用于评估推理服务的吞吐和延迟。ShareGPT 在这里主要承担两个作用：① 提供比较自然的文本 prompt；② 让 benchmark 可以构造不同长度的输入和输出请求，模拟真实服务压力。

3.2 关注指标

后面的结果分析中，我主要关注下面几个指标：

（1）Output token throughput 表示每秒生成多少输出 token，是最直观的吞吐指标。

（2）TPOT 表示 Time Per Output Token，可以理解为平均每个输出 token 的耗时。

（3）ITL 表示 Inter-Token Latency，也就是相邻输出 token 之间的延迟，更能反映 decode 阶段的逐 token 生成速度。

（4）TTFT 表示 Time To First Token，也就是首 token 延迟。需要注意的是，MTP 主要优化的是 decode 阶段，因此它不一定会改善 TTFT。在某些配置下，由于 speculative decoding 需要额外的 draft 和验证调度，TTFT 甚至可能略有增加。

（5）Accept length 是判断 MTP 是否有效的关键指标。它表示平均每轮 speculative decoding 能接受多少个 draft token。简单来说，Accept length 越高，说明 MTP 草稿越容易被主模型接受；主模型一次 forward 能推进的 token 越多，整体生成速度也就越容易提升。

四、评测结果

Intern-S2-Preview 在开启和不开启 MTP 情况下的ShareGPT测试结果

结论：在 8×H200 + SGLang 的 serving 环境下，Intern-S2-Preview 开启 MTP 后，在长输出场景中表现出明显加速效果。随着目标输出长度从 1024 增加到 16000，MTP 带来的 output throughput 提升从 15.68% 增长到 97.52%，TPOT/ITL 降低幅度从约 35% 增长到 61%。这说明 MTP 的核心优势集中在 decode 阶段，尤其适合长文本生成和高吞吐推理场景。

分析：

MTP是在长输出场景下非常有效的 decode 加速手段。最核心的趋势是：输出越长，MTP 收益越大。

在 Output=1024 时，MTP 的 output throughput 从 4613.84 tok/s 提升到 5337.15 tok/s，提升约 15.68%。这个收益已经能看到，但不算特别夸张。

当输出长度增加到 4096 时，提升变得明显：
6314.97 tok/s -> 9556.03 tok/s 提升 51.32% 
到了 8192 输出长度时，MTP 提升进一步扩大： 
6400.63 tok/s -> 11262.87 tok/s 提升 75.97% 
最新的 16000 输出长度实验最有代表性：
6173.51 tok/s -> 12194.04 tok/s 提升 97.52%

也就是说，在超长生成场景中，开启 MTP 后 output token throughput 接近翻倍。从 TPOT 和 ITL 也能看到同样规律。Output=16000 时：

TPOT: 10.05 ms -> 3.86 ms，降低 61.61% ITL: 10.12 ms -> 3.88 ms，降低 61.61%

这说明 MTP 的收益不是简单来自某一次 benchmark 波动，而是确实降低了 decode 阶段每个 token 的平均生成成本。Accept length 也能解释这个现象。随着输出长度增加，MTP on 的 Accept length 从大约 2.97 提升到 3.63：

Output=1024: Accept length 2.97 Output=4096: Accept length 3.14 Output=8192: Accept length 3.39 Output=16000: Accept length 3.63

这表示 speculative decoding 中，模型平均每轮能接受更多 draft tokens。换句话说，长输出时 MTP 草稿 token 的利用率更高，因此主模型不再需要完全逐 token 解码，整体速度自然会明显提升。

附录一环境搭建

1.1 实验环境

使用的是 8 张 144GB显存的NVIDIA H200显卡，推理引擎SGLang部署于Ubuntu22.04系统，环境中的主要组件版本如下：

sglang            0.0.0.dev1+g7f154ba44
sglang-kernel     0.4.2.post2+cu129
torch             2.11.0+cu129
transformers      5.8.1
triton            3.6.0

Intern-S2-Preview 模型在 8 卡 H200 上部署启动后，单卡 SGLang 进程显存大约在 122GB 左右。

从显存占用来看，这个模型包含多模态、MTP 等相关模块，实际部署时并不是一个简单 35B dense 模型的体量感。因此这里使用 8 张 H200 来跑，相对比较稳妥。

1.2 SGLang模型部署

这次测试分成两组：

不开启 MTP

作为推理速度测试的baseline，先看不开启 MTP 的启动方式：

python -m sglang.launch_server \
  --model-path XXX \                                   # Huggingface下载的模型权重路径
  --served-model-name Intern-S2-Preview \              
  --tp 8 \                                             # 8 卡 tensor parallel
  --trust-remote-code \                                # 包含自定义模型结构和推理逻辑，需开启Trust模式
  --host 0.0.0.0 \
  --port 30000 \
  --reasoning-parser qwen3 \                           # 适配 Qwen3 系列的 reasoning 和 tool call 格式
  --tool-call-parser qwen3_coder \ 
  --mem-fraction-static 0.8 \                          # 限制 SGLang 静态显存使用比例
                                                       # 给运行时调度、KV cache 和其他临时开销留出空间
  --model-loader-extra-config '{"enable_multithread_load": "true", "num_threads": 64}' \
                                                       # 开启多线程加载模型权重，加快模型启动速度
  --enable-metrics

2. 开启 MTP

开启MTP后，启动命令如下：

python -m sglang.launch_server \
  --model-path /mnt/shared-storage-user/llmbr-share/lyutianyi/models/Intern-S2-Preview \
  --served-model-name Intern-S2-Preview \
  --tp 8 \
  --trust-remote-code \
  --host 0.0.0.0 \
  --port 30000 \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_coder \
  --mamba-scheduler-strategy extra_buffer \
  --speculative-algo NEXTN \
  --speculative-eagle-topk 1 \
  --speculative-num-steps 3 \
  --speculative-num-draft-tokens 4 \
  --mem-fraction-static 0.8 \
  --model-loader-extra-config '{"enable_multithread_load": "true", "num_threads": 64}' \
  --enable-metrics

和 baseline 相比，开启 MTP 主要多了下面5组参数：

--mamba-scheduler-strategy extra_buffer

这个参数用于调度策略配置。由于 speculative decoding （推测式解码）会引入 draft token、验证 token 等额外中间状态，因此这里使用 extra_buffer 给调度过程预留额外 buffer。

--speculative-algo NEXTN

这是本次开启 MTP 加速的关键参数。NEXTN 可以理解为让模型利用 MTP 能力预测接下来的多个 token，然后再由主模型进行验证。

也就是说，MTP 加速的目标不是让每个 token 的计算完全消失，而是让一次主模型 forward 尽量确认多个 token，从而减少整体生成轮数。

--speculative-num-steps 3

表示 speculative decoding 的预测步数。这里设置为 3，可以理解为让 MTP 模块向后进行多步草稿预测。

--speculative-eagle-topk 1

这里 topk 设置为 1，表示 draft 阶段选择最确定的候选 token。对于体验 MTP 加速来说，这样的配置比较直接：优先让草稿路径保持确定性，观察 accept rate 和生成速度的变化。

--speculative-num-draft-tokens 4

表示每轮 speculative decoding 拿去交给主模型验证的Token数量。

1.3 Benchmark部署

测速工具使用的是 SGLang 自带的在线服务 benchmark：

python -m sglang.bench_serving

这个工具会向已经启动好的 SGLang HTTP 服务持续发送请求，并统计请求吞吐、token 吞吐、首 token 延迟、逐 token 延迟等指标。

以输入长度 1024、输出长度 4096 为例，benchmark 命令如下：

python -m sglang.bench_serving \
  --backend sglang-oai-chat \                          # 按OpenAI /v1/chat/completions 格式访问 SGLang 服务
  --base-url http://<server-ip>:30000 \
  --model /path/to/Intern-S2-Preview \
  --served-model-name Intern-S2-Preview \
  --tokenizer /path/to/Intern-S2-Preview \
  --dataset-name random \                                        # 模型全样本的输出长度设置一个50%的随机波动
                                                                 # 避免所有请求长度完全相同
                                                                 # 接近真实服务中“有长有短”的请求分布
  --dataset-path /path/to/ShareGPT_V3_unfiltered_cleaned_split.json \
  --random-input-len 512/1024 \                                  # 多档输入长度测试
  --random-output-len 1024/4096/8192/16384 \                     # 多档输出长度测试
  --random-range-ratio 0.5 \
  --num-prompts 1024/2048/4096 \                                 # 多档样本量测试
  --request-rate inf \                                           # 请求尽快发出，测试满负载吞吐量
  --max-concurrency 64 \                                         # 并发量级
  --warmup-requests 16 \                                         # 正式测试前的额外请求，减少首次请求波动
  --seed 1 \
  --apply-chat-template \
  --extra-request-body '{"temperature": 0.0}' \                  # 减少temperature对Benchmark的影响
  --output-details