长上下文、结构化输出和多芯片部署，正在把大模型推理框架从“启动模型”推向真正的系统工程。LMDeploy于7月31日晚发布0.15.0版，两个正式版本间累计71次提交、涉及300个文件。更新没有押注单一性能数字，而是同时改造前缀缓存、投机解码约束、TurboMind内存调度和异构硬件路径，直接触及高并发服务最容易出错的几处连接点。

三点看懂：缓存、正确性和异构部署一起推进

前缀命中不再停在简单对话，MTP也能接上缓存

前缀缓存的价值，是让共享系统提示词、重复文档或多轮会话不必每次从头计算。问题在于，长提示通常要分块预填充，MTP等多token预测路径还需要额外的隐藏状态。0.15.0允许长上下文在命中前缀后，从剩余后缀继续分块处理；对MTP则保留一个块的重叠重算，用私有、可写缓存恢复草稿路径所需状态，避免直接改写共享KV块。

这次改动还处理了状态空间模型的检查点恢复、视觉语言模型边界扩展和缓存token计数等细节。它说明“命中缓存”并不只是找到相同token，而是要把注意力状态、循环状态、分块边界与调度顺序一起恢复。对长文档问答和固定提示模板较多的服务，命中范围扩大有望减少重复预填充；但项目没有给出统一吞吐或延迟基准，实际收益仍取决于提示重复率、上下文长度和并发形态。

投机解码更快之前，先保证JSON和语法约束没有失效

投机解码让较小的草稿模型先提出多个token，再由目标模型批量验证，以减少逐token等待；引导解码则用JSON Schema、正则或语法限制合法输出。此前两者同时开启时，约束管理器没有进入投机路径，系统不会报错，却可能返回不受约束的内容。新版本为草稿模型复制语法匹配状态，逐位置应用掩码，并在目标模型接受token后推进原始状态。

这项修复的意义不只是“支持更多组合”。当模型输出要直接进入数据库、函数调用或自动化工作流时，静默失去格式约束比明显报错更危险。版本还增加远程多媒体域名白名单，对手动跳转重新校验目标地址，并修复批量请求会话ID冲突、健康检查误判和多模态工具消息解析。LMDeploy正在把输出正确性与输入边界当成推理性能之外的生产指标。

TurboMind换掉旧调度器，升级代价也写在移除清单里

TurboMind的新内存子系统采用页级后备存储、slab子分配与对象缓存，新的调度器通过前缀树查找和检查点管理复合缓存对象，并纳入循环式GDN状态。请求生命周期转向无状态，交互式聊天入口被移除；并行配置也改为可组合方式。对平台团队而言，这更适合把会话状态放在服务层统一管理，却可能改变依赖旧会话语义的调用方式。

异构硬件同样是本版重点：昇腾A3获得多节点路径细化与Qwen3.5 MTP支持，MoE通信增加新的all-to-all后端，Hopper侧加入DeepSeek V4适配。不过后者目前明确限定Hopper，并依赖FlashMLA、DeepGEMM等组件；这不是任意GPU开箱即用的承诺。首token时间调度也承认超长提示可能拉高全局尾延迟，超过65536 token的分组在偏向较短长提示时可能回退。

兼容性代价不能忽略。项目移除了InternLM第一代、Qwen第一代与Qwen-VL、Baichuan与Baichuan2、StarCoder2等旧架构的专用支持。生产升级前应以真实流量复测前缀命中、首token时间、结构化输出一致性、显存峰值和多节点启动，并检查镜像内的内核与依赖版本，而不是只看新模型列表。

ATYUN编辑判断：LMDeploy 0.15最值得关注的不是71次提交本身，而是缓存、调度、格式约束与硬件适配开始被视为同一条推理链路。开源框架的下一轮竞争不会只看单卡每秒输出多少token，还要看重复上下文能否安全复用、结构化结果能否可靠交付、不同芯片能否稳定扩展，以及升级时能否把兼容成本说清楚。这次版本已经给出工程方向，但缺少统一端到端基准，最终价值仍要由生产负载验证。