feat: 支持 Gemma 4 与原生多模态推理

[kuma-loong]

背景

本 PR 为 Sparse-vLLM 增加 Gemma 4 dense/MoE 文本推理与已支持模型的原生多模态推理，并针对 Gemma 4 26B-A4B 在 CUDA Graph 下的性能差距完成 Nsight Systems 定位和专项优化。

设计原则：模型适配沿用现有 cache-manager、调度和并行架构；优先新增 Gemma 专用算子，不扩展或扰动已经调优的通用算子；设备相关实现通过 OpSpec -> resolver(DeviceCaps) -> provider 在构造期绑定。

主要改动

Gemma 4 文本推理

• 新增 Gemma4ForCausalLM，支持 dense、128 experts/top-8 MoE、PLE、共享 KV、K=V/K!=V、soft-cap logits。
• 支持 Gemma 4 的异构 attention：滑窗层和全局层可使用不同 head dim、KV head 数和 RoPE 参数；RoPE cache 按逐层有效配置隔离。
• 新增异构 explicit-KV 存储，每个物理 KV 层独立管理形状，同时继续复用 cache-manager 的写入、复制、prefix cache 和运行时 view 接口。
• 支持 TP1、TP2、TP+EP、CUDA Graph、prefix cache、StreamingLLM 和 OmniKV。共享 KV 变体仅开放已验证且物理别名语义安全的方法。
• packed expert 的 [gate, up] 布局、分片和加载由 MoE provider 持有，模型层不依赖具体 kernel 或物理权重布局。

专用算子与性能优化

• 新增 Gemma 4 专用 attention、RMSNorm、QKV norm+RoPE、router、GELU-tanh、routed GEGLU MoE 和 residual fusion 实现。
• H20 provider 只在设备能力和依赖满足时选中；router 对 1024/1025 experts 的边界在 resolver 阶段正确选择 fused 或通用 provider。
• Nsight Systems 定位到 head-dim 512 全局 decode stage-1 热点。新 kernel 每个 program 同时处理 4 个 GQA query heads，microbench 从约 1.132 ms 降至约 0.238 ms，输出与参考实现 cosine > 0.999。
• 新增分组滑窗/全局 decode、融合 router、FlashInfer paged prefill plan 复用和按 workload 调整的大 token MoE launch policy。
• 滑窗 kernel 显式处理非 32 对齐 block；FlashInfer plan 以调度 scope 和 page-table 地址为失效条件，避免跨请求或稀疏 view 错误复用。

原生多模态

• 新增统一的 MultiModalPrompt、checkpoint-native processor 和 rank-local MultiModalRuntime。
• 支持 Chat/Responses 的 image、video、audio content part；媒体字段、base64 WAV 和 checkpoint 能力在接纳边界严格校验，客户端错误映射为 HTTP 400。
• 大体积 processor tensor 通过一次性共享内存分发到 TP/EP ranks；注册失败会全 rank 回滚，worker 保持可用，原始异常不会被 cleanup timeout 覆盖。
• Gemma 4 复用 Transformers 的视觉/音频塔，Qwen3.5/3.6 复用其视觉塔，文本 backbone 继续使用 Sparse-vLLM 实现。
• 新增 Qwen3.5 M-RoPE 和 Gemma 4 视觉块双向 attention 专用算子；纯文本请求不进入新多模态 kernel。
• 媒体请求显式绕过文本 prefix cache，避免相同占位 token 对应不同媒体时发生错误复用；decode 继续复用 CUDA Graph。
• 主依赖现在声明无版本约束的 TorchVision，由包管理器结合当前 Torch 和平台解析兼容版本。

性能结果

模型为 Gemma 4 26B-A4B BF16。Sparse-vLLM 与 vLLM 使用相同固定 token prompt、greedy、ignore EOS、CUDA Graph、关闭 prefix cache；每项 3 次 warmup、5 次计时，表中为 output tok/s 中位数。

TP1 / EP1

输入 / batch / 输出	Sparse-vLLM	vLLM	比值
1K / 8 / 256	844.303	782.183	1.079x
4K / 8 / 512	586.153	650.444	0.901x
8K / 4 / 512	315.685	320.965	0.984x

TP2 / EP1

输入 / batch / 输出	Sparse-vLLM	vLLM	比值
1K / 8 / 256	979.779	1101.416	0.890x
4K / 8 / 512	796.894	878.783	0.907x
8K / 4 / 512	412.051	471.418	0.874x
32K / 4 / 1K	262.417	306.440	0.856x
64K / 2 / 1K	119.502	147.294	0.811x
128K / 1 / 1K	46.708	57.588	0.811x

TP2 / EP2

输入 / batch / 输出	Sparse-vLLM	vLLM	比值
1K / 8 / 256	955.400	1079.473	0.885x
4K / 8 / 512	744.073	859.667	0.866x
8K / 4 / 512	395.720	484.122	0.817x
32K / 4 / 1K	253.053	311.643	0.812x
64K / 2 / 1K	115.413	140.950	0.819x
128K / 1 / 1K	45.108	54.880	0.822x

短文本和 32K/64K/128K 长文本矩阵均达到不低于 vLLM 0.8x 的目标，没有针对单一输入输出形状选择实现。

验证

• rebase 后完整收集 2008 个测试：首次 archive 测试树得到 1981 passed, 3 skipped, 24 failed, 223 subtests passed；24 项全部是测试树缺少 Git 元数据时由 benchmark 可复现性防线主动报错。为测试树补充本地、无远端的快照元数据后，相关 3 个测试文件 93 passed, 36 subtests passed，无剩余功能失败。
• Gemma/attention/RMSNorm/multimodal/OpenAI/cache/TP/loader 专项：425 passed, 15 subtests passed。
• 依赖约束测试在开发环境和目标 GPU 环境均为 4 passed。
• 真实模型 smoke：MoE TP1/EP1、TP2/EP1、TP2/EP2 CUDA Graph 均成功；dense 31B TP2 CUDA Graph 成功。
• OmniKV 与 StreamingLLM 各完成 1K 输入、16-token 真实生成，并分别确认 1 个 CUDA Graph 已捕获和激活。
• prefix cache 重复请求输出一致，第二次请求统计命中 1 次并复用 240 tokens。
• 多模态专项覆盖图像/视频/音频、Gemma/Qwen dense/MoE、TP/EP、CUDA Graph、OmniKV、媒体隔离、OpenAI schema 和 TP 注册失败回滚。

兼容性与说明

• 分支已 rebase 到当前上游 main。
• 未修改已有通用高性能 kernel 的调参空间，非 H20 和不满足 capability 的配置走既有通用 provider。
• 目标 GPU 环境按要求保持不变。真实 processor smoke 暴露该既有环境未安装 TorchVision；本 PR 已在主依赖中补齐无版本约束声明并验证依赖解析结构，但没有原地安装或修改测试环境。
• 性能原始数据、NSYS 报告、临时 benchmark 和内部交付记录不进入仓库；PR 仅包含生产代码、正式测试和公开文档，不包含服务器地址、绝对路径、账号或其他隐私信息。