add llama4

README.md

@@ -176,3 +176,6 @@ curl http://localhost:80/v1/chat/completions \
 | v0.0.4 | 2026-02-10 | **Gemma3 模型支持**：新增 Gemma3ForCausalLM 模型实现（含 QK Normalization、per-layer rope 配置、layer_types 滑动窗口），修复 `patch_rope_scaling_dict` 在 rope_scaling 缺少 `rope_type` 键时崩溃的问题，更新模型注册表及 config.py 中 interleaved attention 和 dtype 自动处理逻辑 |
 | v0.0.4.1 | 2026-02-10 | **Gemma3 rope 兼容性修复**：修复新版 transformers `Gemma3TextConfig` 缺少 `rope_theta` 属性的问题，从 `rope_parameters` 字典兼容提取 rope 配置（支持 Transformers v4/v5）；修复 `rope_scaling` 嵌套字典导致 `get_rope` 缓存 unhashable 的问题；适配 MLU `forward_mlu` 接口，将 q/k 合并为单张量调用 rotary_emb 后再拆分 |
 | v0.0.5 | 2026-02-10 | **Qwen3MoE 模型支持**：新增 Qwen3MoeForCausalLM 模型实现（含 QK Normalization、ReplicatedLinear shared_expert_gate），修复 FusedMoE `forward_mlu` 签名缺少 `layer` 参数的已有 bug（影响所有 MLU 上的 MoE 模型），更新模型注册表 |
+| v0.0.6 | 2026-02-11 | **DeepSeek V3 模型支持**：注册 DeepseekV3ForCausalLM（复用 V2 实现），扩展 MLU MLA config 判断支持 `deepseek_v3`，实现 `noaux_tc` 路由方式（`e_score_correction_bias`），跳过 MTP 层权重加载，修复 MLA unpaged 缓存路径使用错误的 paged cache 算子（prefill + decode 均替换为 `reshape_linear_cache`） |
+| v0.0.6 | 2026-02-11 | **DeepSeek V3 MTP 推测解码**：新建 `deepseek_mtp.py` 实现 MTP draft model（复用 DeepseekV2DecoderLayer，EAGLE 模板适配），SpeculativeConfig 自动检测 `num_nextn_predict_layers` 并改写 draft config，target worker 为 MTP 返回 hidden states，MLU config 三处 model_type 判断扩展支持 `deepseek_mtp` 以匹配 MLA cache 格式 |
+| v0.0.6 | 2026-02-11 | **Llama4 模型支持**：新建 Llama4ForCausalLM 模型实现（复合 config 处理、sigmoid routing MoE、QK Normalization、交替 dense/MoE 层），新建 MLU hijack 适配（SparseMoeMlp MoE 替换、embedding dtype 修复），处理 `Llama4Config` 嵌套 `text_config` 的 architectures 提取问题。**⚠️ MoE dense 模式（影响所有 MoE 模型）**：原始 `forward_experts_nofused` 包含 `torch.unique`、`torch.tensor` 创建、数据依赖分支等 graph capture 不兼容操作，导致 MLU370 上所有走 `SparseMoeMlp` 的 MoE 模型必须加 `--enforce-eager` 才能运行。现已改为 dense 模式（每个 expert 处理全部 token），解决了 graph capture 兼容性，所有 MoE 模型无需 `--enforce-eager` 即可运行，但计算量增大 num_experts/topk 倍（Mixtral 4x、Llama4 16x、Qwen2-MoE 15x）。DeepSeek V2/V3 不受影响（有独立 MLU MoE hijack）。后续应拆分 `is_use_fused_moe` 标志让 MLU370 走 `forward_group_experts` 路径优化 |

vllm-v0.6.2/vllm_mlu/vllm_mlu/model_executor/layers/sparse_moe_mlp.py

@@ -73,6 +73,24 @@ class SparseMoeMlp(nn.Module):
         self.expert_group = expert_group
         self.topk_group = topk_group
         if get_device_major_capability() == 3:
+            # WARNING: MLU370 (capability=3) 不支持 fused_moe 算子，强制关闭。
+            #
+            # 背景：原始 forward_experts_nofused 包含 torch.unique、torch.tensor([0], ...)、
+            # 数据依赖分支等 graph capture 不兼容操作，导致 MLU370 上所有走 SparseMoeMlp
+            # 的 MoE 模型必须加 --enforce-eager 才能运行。当前已将 forward_experts_nofused
+            # 改为 dense 模式（每个 expert 处理全部 token，用路由权重 mask），解决了
+            # graph capture 兼容性问题，所有 MoE 模型无需 --enforce-eager 即可运行。
+            #
+            # 性能代价：dense 模式计算量为 O(num_experts * num_tokens)，相比稀疏路由的
+            # O(topk * num_tokens) 增大了 num_experts/topk 倍。prefill 阶段对 expert
+            # 数量多的模型会明显变慢，decode 阶段（token 少）影响可忽略。
+            # 已知受影响模型：Mixtral (8)、Qwen2-MoE (60)、HunYuan (16)、Llama4 (16) 等。
+            # DeepSeek V2/V3 不受影响（有独立的 MLU MoE hijack 实现）。
+            #
+            # TODO: MLU370 已有完整的 MoE 算子链（moe_gen_idx、moe_expand_input、
+            # group_gemm、moe_active、moe_combine_result），与 forward_group_experts
+            # 使用的算子相同。后续应拆分 is_use_fused_moe 标志，让 MLU370 走
+            # forward_group_experts 路径以避免 dense 模式的性能开销。
             self.is_use_fused_moe = False
 
         if params_dtype is None: