Dense Models 到底 Dense 在哪：为什么 vLLM 先把 MRv2 默认给普通 Transformer
vLLM v0.25.0 里有一句很容易滑过去的话：
Model Runner V2 is now the default for all dense models.这句话看起来只是 release note 里的一个范围说明。但如果把它拆开，其实能顺手建立一张大模型推理系统的概念地图：
dense model
MoE
router
expert
active parameters
hybrid model
attention-free model
Model Runner V2
expert parallelism先给结论：在 vLLM 这个语境里，dense model 可以先理解成：
每个 token 推理时，基本都会经过同一套完整 Transformer 层和同一套 FFN/MLP 权重的普通语言模型。它主要是和 MoE 对比。MoE 不是每个 token 都走所有专家，而是由 router 为每个 token 选择少数 expert。于是 MoE 有“总参数量”和“每 token 激活参数量”的差别。
vLLM 先让 dense models 默认走 MRV2，不是因为 dense 模型更重要，而是因为它们的执行路径更稳定：没有 token-dependent expert dispatch，没有 all-to-all expert 通信，没有 hybrid state/cache 特例，适合先把新 runner 的公共路径跑稳。
1. 术语卡：先把关键名词钉住
Dense model
人话定义：每个 token 基本走同一套参数和同一条计算路径的模型。Llama、Mistral dense 版、Gemma、普通 Qwen causal LM 都属于这个直觉范围。
容易误解：这里的 dense 不是说权重矩阵里没有 0，也不是指 PyTorch 里的 dense tensor。它是和 MoE 的 sparse activation 对比：dense model 对每个 token 使用同一套主干层；MoE 对每个 token 只激活部分 expert。
MoE / Mixture of Experts
人话定义：把 Transformer 里的 FFN/MLP 层换成多个 expert；每个 token 来的时候，router 选择 top-k 个 expert 来处理它。
关键来源：Switch Transformer 论文说，普通深度学习模型通常对所有输入复用同一套参数，而 MoE 为每个输入选择不同参数，形成 sparsely-activated model。Mixtral 8x7B 论文给了更直观的例子：每层有 8 个 FFN experts，每个 token 每层选 2 个 expert。
Sparse activation
人话定义：模型总参数很多，但一次 token 前向只激活其中一部分。
这和“权重矩阵稀疏”不是一回事。多数 MoE expert 内部仍然是普通 dense matrix multiplication；稀疏发生在“选哪些 expert”这个路由层面。
Router / gating network
人话定义：MoE 里的分流器。它看当前 token 的 hidden state，然后决定这个 token 应该送给哪些 expert。
工程影响：router 的选择是 token-dependent 的。同一 batch 里的不同 token 可能去不同 expert，导致排序、分发、聚合和跨 GPU 通信都比 dense model 麻烦。
Expert
人话定义：MoE 里的一个 FFN/MLP 分支。可以粗略理解为“很多个可选的前馈网络模块”。
Mixtral 的例子是每层 8 个 experts，每个 token 选 2 个。DeepSeek-V3 的例子更大：论文摘要写的是 671B total parameters，每 token 激活 37B。
Active parameters vs total parameters
人话定义：
total parameters：模型文件里一共有多少参数
active parameters：一个 token 这一步真正参与计算的大约多少参数MoE 模型经常总参数很大，但每 token 激活参数小很多。这个差异解释了为什么 MoE 可以把容量做大，同时控制单 token 推理成本。
Expert parallelism
人话定义：把不同 expert 放到不同 GPU 上。token 被 router 选中后，要被发送到对应 expert 所在的 GPU，算完再收回来。
这会引入 all-to-all / dispatch / combine 这类通信问题。vLLM 有 Expert Parallel Deployment 文档，专门说明 MoE experts 如何跨 GPU 部署。
Hybrid model
人话定义：不再是“每层都是标准 Transformer attention + MLP”的模型，而是混入 Mamba、linear attention、sliding attention、cross attention、MLA 等不同机制。
为什么影响 vLLM：不同注意力或状态机制会改变 cache 形态、prefix caching、warmup、CUDA graph capture 和 scheduler 假设，所以它们不一定能和普通 dense Transformer 同批默认迁移。
Attention-free / linear-attention model
人话定义：不使用标准 quadratic self-attention，或者用状态空间/线性注意力一类机制替代标准 attention 的模型。
在 vLLM PR #44443 的默认逻辑里，is_attention_free 会被排除在默认 MRV2 dense 路径之外。
Model Runner V2 / MRV2
人话定义：vLLM 的新模型执行核心。官方 MRV2 博客 把目标概括为更模块化、更 GPU-native、更 async-first。
它不是一个新模型，而是 vLLM 里面负责把 scheduler 输出变成模型前向、采样、请求状态更新的一套执行框架。
2. Dense Transformer 的推理路径为什么稳定
普通 dense causal LM 的一层可以粗略看成：
hidden state
-> attention
-> MLP / FFN
-> next hidden state对一个 batch 里的 token 来说，虽然输入内容不同，但它们经过的是同一类 kernel、同一类权重、同一类 tensor layout。推理引擎可以预期：
- 每层都要跑 attention。
- 每层都要跑同一套 MLP。
- tensor parallel 怎么切，基本是固定的。
- CUDA graph capture 的 shape 和控制流更容易稳定。
- scheduler 只需要处理请求长度、KV cache、batch composition 等常规变量。
这就是 dense models 适合先迁到 MRV2 默认路径的原因：它们能覆盖 vLLM 最核心、最高频的服务场景，又不会一开始就把 MoE 的动态路由和 hybrid 的 cache 特例全部带进来。
3. MoE 到底多了什么麻烦
MoE 把一层 MLP 变成这样：
flowchart LR
H[hidden state per token] --> R[router]
R --> E1[expert 1]
R --> E2[expert 2]
R --> E3[expert 3]
R --> E4[expert ...]
E1 --> C[combine]
E2 --> C
E3 --> C
E4 --> C对单机单卡，这是多一个 router 和多个 expert。到了多 GPU serving，麻烦会放大：
- token 分布不均：一个 batch 里很多 token 可能被 router 分到同一个 expert，造成局部拥塞。
- 跨卡通信：如果 expert 分布在不同 GPU，token hidden state 要被 dispatch 到对应 GPU，再 gather 回来。
- 动态 shape：每个 expert 每步收到多少 token 不固定，kernel 调度和 CUDA graph 更难稳定。
- 并行策略分裂：attention 层可能适合 tensor/data parallel，expert 层可能更适合 expert parallel。
- 调度指标更复杂：dense 模型看 batch size、sequence length、KV cache 就已经很忙；MoE 还要看 expert load 和通信。
所以 vLLM 的 MRV2 迁移 issue #41286 才会分阶段：先 dense，再 MoE，再 popular large models。这个顺序不是概念洁癖，而是风险控制。
4. 为什么 release 说的是 dense models，不是 all models
vLLM v0.25.0 release 说 MRV2 成为所有 dense models 的默认路径，但这句话不能读成“所有模型都默认 MRV2”。
PR #44443 的改动逻辑很直白：默认 MRV2 路径会排除几类模型：
不是 generate runner 的，不走
hybrid model，不走
attention-free model，不走
MoE 之外的 dense generate model，默认可走从工程角度看，这个条件组合说明：
- vLLM 想先把最常规的 generate 路径稳定下来。
- 不把 pooling、embedding、特殊 runner 混进来。
- 不把 hybrid/attention-free 的状态机制混进来。
- 不把 MoE 的 expert routing/parallelism 复杂度混进来。
这和 MRV2 官方博客里的设计目标一致：MRV2 要把 model-specific logic 和 common execution path 分开，减少 V1 runner 里 persistent batch、async scheduling、input preparation、sampling 彼此缠绕的问题。
5. Dense 先迁移，不代表 MoE 不重要
恰好相反，MoE 是现在大模型服务里最值得继续挖的方向之一。
Mixtral 展示了“每 token 只用部分 expert”的推理成本优势。DeepSeek-V3 把这个规模推得更明显：总参数 671B，每 token 激活 37B。也就是说，用户看到的是很大的模型容量，但 serving 系统真正每 token 承担的是激活路径、expert dispatch 和通信路径。
这就解释了为什么 MoE 的服务优化不是简单“把 dense 那套放大”：
dense 优化重点：
attention backend、KV cache、batching、CUDA graph、sampling
MoE 还要额外处理：
router、expert load、expert parallel、all-to-all、token dispatch/combineMoE 的问题不是比 dense 晚重要，而是比 dense 晚稳定。一个新的 runner 如果连 dense 主路径都没收口，直接把 MoE 所有动态因素拉进来，调试成本会非常高。
6. 这块可以继续挖成哪些话题
话题 A：Dense vs MoE 的推理成本
核心问题：
为什么 MoE 总参数更大，单 token 推理却不一定更贵？可以接 active parameters、router top-k、expert parallel、通信开销。
话题 B：MoE serving 为什么难
核心问题：
MoE 的麻烦到底是在算力、显存，还是通信？可以拆 token dispatch、expert load balance、all-to-all、EPLB、DBO。
话题 C：MRV2 为什么要把 model-specific logic 隔离成 ModelState
核心问题：
当一个 serving 引擎要同时支持 Llama、DeepSeek、Qwen、Kimi、Mamba、多模态模型时，公共 runner 应该长什么样？这个话题可以接代码架构和 vLLM 设计。
话题 D：Hybrid model 和 dense model 的 cache 语义差异
核心问题：
为什么 Mamba / linear attention / sliding attention 不能简单套标准 KV cache 直觉？可以接 prefix caching、paged KV、state cache、attention metadata。
7. 自检
读完这篇，应该能回答四个问题：
- dense model 的 dense 是和什么对比？
- MoE 的 sparse 是权重稀疏，还是激活稀疏？
- 为什么 MoE 有 total parameters 和 active parameters 的区别？
- 为什么 vLLM 先让 dense models 默认走 MRV2，而不是 all models？
如果一句话回答：
Dense model 的执行路径稳定，MoE/hybrid 的路径是动态和模型特定的；
MRV2 先接管 dense，是为了先把公共执行核心跑稳，再逐步吃掉更复杂的模型族。