vllm项目发布v0.28.0版本，包含270位贡献者的584次提交。主要亮点包括：对Kimi-K3模型的全栈性能优化，如解码上下文并行、融合内核、自适应推测令牌预算等；以及DeepSeek V4的稀疏MLA端到端支持。

好的，这是根据您的要求，对 v0.28.0 版本发布内容的中文重述：

v0.28.0 版本发布

亮点

本版本共有 270 位贡献者提交了 584 次提交（其中 76 位是新贡献者！）。

• Kimi-K3 性能提升：针对 Kimi-K3 模型进行了全栈优化，包括：解码上下文并行支持、融合的 FlashKDA 解码和预填充内核、MegaMoE 的 SiTU 激活支持、序列并行的 GEMM-RS、1.5~3 倍内核级加速的合并全收集操作、将 DSpark 首令牌延迟提升约 60% 的自适应推测令牌预算，以及每 GPU 节省约 17 GiB 内存的可选共享专家分片。Kimi-K3 现在也可以在 ROCm 上使用 V2 模型运行器运行。
• DeepSeek V4：稀疏 MLA 现在可以在纯解码、MTP 和 DSpark 推测解码中端到端工作，同时加入了 AMD Quark NVFP4 支持、推理努力提示和映射、稀疏 top-k 元数据内核优化、精简的 eager CUDA 图区域，以及在 gfx11 和 gfx950 上的 ROCm 支持。
• 推测解码进展：引入了带局部卷积和候选选择器的 DFlash2、DSpark 置信度调度验证，以及为草稿模型自动启用的异步调度。
• 模型运行器 V2 成熟：支持编码/预填充/解码分离、权重卸载、多层 MTP KV 缓存、编码器 CUDA 图、解码器令牌级池化及 Transformers 池化模型、无注意力模型，以及 thinking_token_budget 支持。
• 分层 KV 缓存卸载：支持磁盘卸载、通过 module_path 支持树外二级层管理器、部分二级层加载结果、分层指标，以及用于并行无关卸载的规范 CPU 布局。
• Rust 前端与 gRPC：包含独立渲染器、通过 gRPC 的多模态图像推理、显式数据并行等级路由、强化学习生命周期控制，并且 protobuf 模式现已发布到 Buf。
• 新默认值：max_num_batched_tokens 从 8192 提升至 16384，Mamba 模型默认启用前缀缓存，Blackwell CUDA 图捕获默认值提升至 1024。
• 重大变更：bitsandbytes 支持迁移至树外插件；Transformers 版本升级至 5.15.0；移除了已弃用的 calculate_kv_scales 运行时 KV 缩放计算；移除了 override_attention_dtype。

模型支持

• 新模型：新增对 Muse Glimmer、Ling 3.0 Flash（含 BF16、MTP、解析器及 FP8 变体、混合 MXFP4 路由专家）、Dots3 NOTE 原生多模态、Interns2mobius 的支持。
• Qwen：Qwen3.8 在 AMD ROCm 上启用；为 Qwen3.5 GDN 融合了 CUDA 后卷积 MTP 解码内核；GDN 门与推测令牌对齐；修复了 Qwen3.5 纯文本检查点的问题。
• Transformers 建模后端：支持 MLA、硬件无关的模型定义、完全通用的输入嵌入处理、logit softcapping，以及强化的多模态路径。
• LoRA：为 Gemma4 添加了视觉塔 LoRA；为 Keye 和 Ultravox 添加了塔/连接器 LoRA。
• 视觉编码器：为 Kimi-K2.5 和 Ernie-4.5-VL 实现了 ViT 完整 CUDA 图；为 Qwen3-VL 编码器启用了 torch.compile；避免了 ViT 中的长阻塞 H2D 拷贝。
• MoE：扩展了对 Mistral Large 3 及其他 MoE 后端的 EPLB 支持；将 CuTe DSL 瘦 GEMM 扩展至 GLM-5.2。
• 推测解码覆盖：宣布在 KimiLinear 上支持 EAGLE3；Qwen3.6 的 dSpark 接受覆盖率。
• 正确性：修复了 MiniMax-M3 NVFP4 推理、压缩张量 FP8 MoE SwiGLU 参数、Gemma3n/Gemma4 变长音频批次填充、Gemma 4 与未来 Transformers 版本的兼容性，以及 Qwen3-Omni 在无音轨视频上的崩溃问题。
• 多模态性能：融合了设备端多模态预处理归一化、更快的占位符和令牌匹配扫描，并避免了重复的提示更新扫描。

引擎核心

• 推测解码：新增 DSpark 置信度调度验证、top-k DSpark 马尔可夫投影、带局部卷积和候选选择器的 DFlash2、为草稿模型自动启用异步调度、融合 MTP 尾部全规约与局部 argmax 草稿令牌，以及推测调度输入令牌的自适应预算。
• KV 缓存与调度：支持 MLA 分块上下文的按请求调度、带细粒度前缀匹配的部分尾部前缀重用、KV 缓存布局重构中的后端发布 KV 打包、关闭前缀缓存时恢复 LIFO 空闲块重用顺序，并修复了优先级调度中静默跳过请求的问题。
• 性能：持续消除执行路径上的 GPU<->CPU 同步（现由 CI 同步检查保护）、新的带谓词过滤的 JIT 预热基础设施、以 8 个 warp 启动的 top-k/top-p Triton 采样器、离线束搜索中跳过解码、Mask Replay、优化的长上下文 MLA 缓存收集，以及每次模型加载时将 HF 修订版解析为提交哈希。
• 混合/Mamba：默认启用前缀缓存、Mamba 注意力模块重构的最后部分、状态拷贝 Triton 内核的 3D 网格分块，以及在编码器上限前应用 Mamba 对齐。
• 强化学习工作流：通过 NCCL 和稀疏 NCCL 进行有状态训练器发送、用于标签选择性 GPU 内存释放的 CuMemAllocator.discard()、修复了启用 LoRA 时的二级睡眠/唤醒/重载问题，并重写了权重传输文档。
• 启动鲁棒性：单节点执行器的文件系统 rendezvous 消除了启动端口竞争、引擎启动期间监控前端进程、修复了 DP 保留端口上的 get_open_port() 活锁，并且不再在每次设备能力检查时重新初始化 NVML。

硬件与性能

• NVIDIA：在 SM12x 上支持 FlashInfer XQA 解码、SM100 上的 CuTeDSL 融合查询内核、DSA 解码内核的程序化依赖启动、SM90 上 MTP=3 的原生 DSA 解码路径、GB10 融合 MoE FP8 调优配置，以及 B12X 密集线性后端。
• AMD ROCm：升级了 torch 2.12 / triton 3.7 栈、在 GFX120x 上启用 AITER 和 FP8 推理、在 gfx11 上运行 DeepSeek-V4、在 gfx950 上优化 Triton 稀疏 MLA 解码、用于 4 位 TurboQuant KV 缓存的 FlyDSL 解码注意力内核和 gfx942 上的 fp8 MQA logits 内核、融合的 Kimi-K3 KDA 解码内核、融合的 bf16→fp32 路由器 GEMM、在支持的 WSL2 内核上使用固定内存，以及用于 16 令牌块的预洗牌稀疏索引。
• Intel XPU：包含块状 GEMM 的 torch 线性后端、用于 INC DeepSeek V4 模型的 MXFP8 线性权重、异步调度 PP 采样令牌广播与计算重叠、在发布流程中添加 XPU wheel、为 Arc Pro B70 调优 Mamba SSU 配置，以及 UVA 权重卸载修复。
• CPU：支持 DeepSeek-V2/V3 在 CPU 上运行的 MLA 后端、triton-cpu wheel、在 s390x 上启用 GPTQ 和 AWQ 及 tcmalloc、通过 AMD 上的 zentorch 路由 BF16 MoE、Power (VSX) 的未量化 MoE 后端、将未量化 MoE 迁移到模块化内核专家结构，以及将 MXFP4 块缩放折叠为 2 条指令。

大规模服务

• 编码/预填充/解码分离：模型运行器 V2 的 E/P/D 支持、移除重复图像预处理并采用 GPU 端预处理、KV 消费者可省略多模态嵌入、编码器实例请求保持活动状态直到图像编码完成，以及 EC 连接器调度器/工作器元数据管道。
• KV 卸载：SimpleCPUOffloadConnector 的磁盘卸载支持、通过 module_path 的树外二级层管理器、部分二级层加载结果、分层卸载指标、向卸载后端暴露的数据并行拓扑、用于并行无关卸载的规范 CPU 布局，以及避免二次 ARC 批次驱逐。
• Mooncake：存储组语义、租户 ID 支持，以及 Docker 镜像中的官方 wheels。
• 连接器：NIXL 兼容性哈希中包含传输模式（推送/拉取）、MoRIIO 每层读取完成屏障、2P2D 宽 EP 与 mori-ep/mori-io 在 dp=ep=16 时，以及推送连接器中的陈旧远程清理。
• 并行性：修复并测试了 EPLB 平衡性计算、密集多节点 DP 重定范围。

量化

• 在线量化：支持在线 MXFP4、跨 TP 共享在线权重缩放、在线 NVFP4 专家打包中保留精度，以及跨重载重用在线 NVFP4 MoE 内核。
• NVFP4：通过 CUTLASS 实现批量不变的 NVFP4 MoE、KV 4-over-6 缩放搜索、带 SwiGLU-OAI 和 ReLU2 激活的 CuTeDSL MoE，以及将 out_dtype 与模型 dtype 匹配。
• 新内核：块状 scaled_mm、DeepSeek-V4 AMD Quark NVFP4 及仿真内核。
• 修复：动态 INT8 W8A8 MoE 配置不再构建为 W8A16 及 TritonExperts 崩溃、FlashInfer CUTLASS 的 MXFP4 转换、MXFP4 的 fp32 权重缩放和每专家检查点映射，以及融合块缩放方向。

API 与前端

• 新功能：从 HTTP 头解析请求优先级、将会话 ID 注入请求、流式解析器引擎中的 count_reasoning_tokens、/inference/v1/generate 上的 content_parts、所有 /derender 请求类上的可选 model、在 DEBUG 级别记录输出令牌 ID，以及 vLLM Recipes 连接到原生基于配置的部署和基准测试。
• Rust 前端：独立渲染器、gRPC 多模态图像推理、显式数据并行等级路由、强化学习生命周期控制、来自开发者消息的动态工具、发布到 Buf 的 protobuf 模式，以及 MiniJinja 升级到 2.22。
• Anthropic API：对 /v1/messages 上由客户端引起的错误返回 4xx、保留 disable_parallel_tool_use，以及限制停止序列。
• Cohere：上游解析器修复、正确报告停止序列，以及向量化二进制嵌入位打包。
• 结构化输出：在 xgrammar 中屏蔽请求停止令牌直到语法终止、在 structured_outputs.regex 中拒绝 NUL 字节、拒绝负令牌 ID 为超出词汇表，以及从验证器引发 VLLMValidationError。
• 鲁棒性：禁用 uvicorn 信号处理程序以避免竞争、统一的入口点异常处理程序、对非对象 JSON 主体返回 400 而非 500、在执行昂贵工作前限制生成输入，以及 cache_salt 现在要求非空。

安全

• 修复了通过伪造采样率绕过音频解码持续时间限制的拒绝服务攻击；音频解码持续时间限制现在也在 NanoNemotronVL 中强制执行。
• DeepStream 被归类为 GPU 后端，并强制执行像素限制。
• 使用 resolve_trust_remote_code 保护 _load_ov2_processor。
• 文档现在警告 --api-key 并不保护所有端点。

依赖项

• Transformers 5.15.0、huggingface-hub 1.27.0、fastsafetensors 升级。
• ROCm：torch 2.12、triton 3.7、torchaudio、torchvision。
• 运行时镜像升级到 Ubuntu 24.04，采用 rdma-core > 44。
• DeepGEMM 固定到 deepseek-ai nv_dev 尖端、DeepEP 通过完整提交哈希固定、FlashAttention 3 使用 torch 稳定 API 构建。

重大变更与弃用

• bitsandbytes 支持现在是树外插件。
• 移除了已弃用的 calculate_kv_scales 运行时 KV 缩放计算。
• 移除了 override_attention_dtype。
• reasoning_content 输出移除被记录为破坏性客户端变更。
• KV 卸载分层指标从 kv_offload_tiering_block_{queries,hits} 重命名为 ..._chunk_...。
• 移除了 MoE 遗留代码。

根据评论内容，总结如下：

主要观点：vLLM存在严重稳定性问题，功能支持落后于同类工具。

观点一：vLLM版本迭代频繁出现关键性Bug（认可度：高） - 用户kouteiheika详细描述了在B300、RTX 6000等主流硬件上运行vLLM时遇到的崩溃、输出乱码（如重复token循环、无意义文本）等问题，并指出“每个版本都有严重问题”。 - 关键引用："On v0.26 it was totally broken... On v0.27... the output is now broken as it randomly starts responding with garbage"（v0.26完全崩溃，v0.27输出随机乱码） - 关键引用："in every single release something is critically broken"（每个版本都有严重问题）

观点二：功能支持不足，落后于同类工具（认可度：中） - 用户Der_Einzige指出vLLM在LLM采样器支持上落后于llama-cpp，缺少top-n-sigma、DRY、XTC等关键功能。 - 关键引用："Still way behind on LLM sampler support compared to llama-cpp"（采样器支持远落后于llama-cpp） - 关键引用："Where's support for top-n-sigma? for DRY? for XTC?"（缺少这些功能）

观点三：特定问题修复缓慢，硬件兼容性差（认可度：低至中） - 用户joshheitzman对reasoningcontent问题仅得到文档修改而非实质性修复表示失望。 - 用户zoobab通过负载测试成功使vLLM崩溃。 - 用户SillyUsername希望vLLM支持Pascal架构（Nvidia已放弃支持，但llama.cpp仍支持）。 - 关键引用：*"I was hoping to see the reasoningcontent mess get robustly fixed, but all we got was this doc change"（期望的修复只是文档修改） - 关键引用："I just wish they'd support Pascal"*（希望支持Pascal架构）

总结： 评论者普遍认为vLLM存在严重的稳定性问题（尤其是输出乱码和崩溃），功能支持（如采样器）落后于llama-cpp，且对特定硬件和问题的修复进展缓慢。尽管vLLM被广泛使用，但用户对其“每个版本都有新Bug”的现状感到沮丧。