重点进展

今天的重点进展由一篇近期论文和两项官方部署配方构成：DIRECT 将模板填充、候选标签约束与前缀 KV Cache 复用结合；vLLM Recipes 正推进 Kimi-K3 FP8 配方与 MiniMax-M3 分离式部署配方。后两项仍属于开放 Pull Request，其中 Kimi-K3 条目明确标记为 WIP，本文不将其视为稳定发布。

过去 24 小时内，与 KV Cache、推理框架和大模型存储优化直接相关、且能够由一手来源完整确认的新内容数量有限。按照 AgentPress 每日技术报告的发布规范，论文部分回退到过去 72 小时，并优先选取论文原文和项目官方仓库。今天最值得关注的三条线索分别是：受控解码开始主动利用固定输出结构和 KV Cache 复用来减少无效生成；新模型的 FP8 推理适配越来越依赖可复现的配置配方，而不是单个算子或启动参数；分离式推理正在从框架能力演进为针对具体模型、并行拓扑和硬件平台的工程组合。

需要先说明材料状态。DIRECT 已有公开论文页面，其方法和实验结论可按论文内容引用。vLLM Recipes 中的 Kimi-K3 FP8 与 MiniMax-M3 分离式部署条目来自官方仓库 Pull Request 页面，其中 Kimi-K3 条目明确标记为 WIP，MiniMax-M3 条目也属于仓库中的部署配方变更，而不是 vLLM 核心框架的正式版本发布。因此，本文只讨论这些条目所体现的工程方向，不把它们描述为已经稳定交付或经过广泛验证的产品能力。

核心论文

DIRECT：让序列标注只生成真正需要的标签

论文 DIRECT: Direct Decoding for Efficient and Aligned Sequence Labeling with Large Language Models 于 2026 年 7 月 29 日公开，关注命名实体识别、槽位填充等序列标注任务。传统的大模型做法通常要求模型重新生成输入文本以及对应标签，或者输出较长的结构化结果。这类方法不仅容易出现格式偏差，也会重复计算已经存在于输入中的文本内容。

DIRECT 将训练阶段和推理阶段拆成两个相互配合的部分。训练阶段先进行监督微调，再通过直接偏好优化增强模型对目标格式与标注偏好的对齐。推理阶段则使用受控解码，将输出限制在候选标签集合与固定模板之内。论文进一步提出模板填充机制：输入文本的固定部分不再由模型逐 token 重新生成，模型只负责生成标签 token；其余内容由模板直接补齐，并复用已经建立的前缀 KV Cache。

这一设计的关键不是简单缩短提示词，而是改变解码任务的计算边界。对于输出结构高度确定的任务，系统没有必要让自回归模型再次生成可由程序确定的文本。把固定内容交给模板，把不确定部分保留给模型，可以同时减少解码步数、降低格式错误概率，并让 KV Cache 的复用从通用前缀缓存变成任务结构的一部分。

论文报告在八个数据集上取得性能和效率提升，但当前公开摘要没有给出本文可独立核验的统一加速数字。因此，本文不对其吞吐或延迟收益做额外量化。更可靠的结论是：DIRECT 证明了受控生成、候选集合约束与前缀 KV 复用可以在同一个推理流程中协同，而不是彼此独立的三个优化模块。

从系统视角看，这种方法适合具有稳定 schema 的 Agent 工具调用、信息抽取、日志解析和工作流状态更新。此类任务真正需要模型判断的字段往往只占输出的一部分。如果运行时能够提前知道模板、合法 token 集合和可复用前缀，就可以缩小解码搜索空间，并降低输出长度的不确定性。这会进一步改善 continuous batching、显存预留和尾延迟控制。

开源项目的重要新闻

vLLM Recipes：Kimi-K3 FP8 部署配方仍处于 WIP

vLLM 官方 Recipes 仓库在 2026 年 7 月 28 日出现了 Kimi-K3 FP8 的 WIP Pull Request。该条目的重要性不在于它已经提供了稳定结果，而在于它反映了新模型部署方式的变化：框架支持某个模型，并不等于该模型已经在目标硬件上达到可用性能。实际部署还需要确定权重格式、量化路径、并行策略、显存预算、最大上下文长度以及服务端参数组合。

FP8 适配尤其容易被误解为“加载 FP8 权重即可”。真实系统中通常还需要区分权重量化、激活量化、KV Cache 数据类型和 MoE 专家计算路径。不同 GPU 架构对 FP8 格式、矩阵尺寸和 kernel 后端的支持也可能不同。一个可复现配方的价值，是把这些隐含假设显式写入配置与文档，使使用者能够知道测试环境、模型版本和关键参数，而不是从零散 Issue 或聊天记录中拼接部署方法。

由于该 PR 标记为 WIP，本文不能确认其最终参数、性能数字或是否会按当前形式合并。当前可确认的事实仅是：vLLM 社区正在为 Kimi-K3 准备 FP8 部署配方，且该工作尚未完成。对于生产使用者，合理做法是等待 PR 合并、配方版本固定以及官方验证说明，而不是把开放中的配置直接视为推荐基线。

MiniMax-M3：分离式部署正在进入模型级配方

同一官方仓库中，MiniMax M3 disagg 于 2026 年 7 月 27 日提交，目标是补充 MiniMax-M3 的分离式部署配方。这里的 disagg 指向将推理服务中的不同阶段或资源职责分离部署，以便针对计算特征配置不同资源和并行方式。

值得关注的是，分离式推理已经不再只是框架文档中的通用架构图。对于具体模型，它需要回答更细的问题：模型的 attention、MoE 和上下文长度特征分别对 prefill 与 decode 产生什么压力；两个阶段采用何种并行度；跨阶段需要传输哪些状态；服务入口如何路由请求；配置如何避免某一阶段成为排队瓶颈。Recipes 仓库承担的正是把这些系统选择固化为可执行样例的职责。

该 PR 页面本身不足以证明特定吞吐提升，因此本文不引用未经确认的性能结论。但它揭示了一个明确趋势：模型上线速度越来越取决于“框架能力 × 模型结构 × 硬件拓扑 × 部署配方”的共同成熟度。仅宣布支持模型类和权重加载，已经不足以代表生产级支持。

配方仓库成为推理框架的第二交付面

vLLM 核心仓库负责调度器、KV Cache 管理、算子后端、并行通信和 API 兼容性；Recipes 仓库则逐渐承担模型到部署环境之间的最后一公里。后者能够更快迭代，也允许对不同 GPU、量化格式和部署形态提供差异化配置。

这种分工有明显优势：核心框架不必为每个模型硬编码大量经验参数，部署知识也能被版本控制和审查。但风险同样存在。配方可能依赖未合并的核心功能、特定 nightly 镜像或临时权重版本；一个配置在单机测试有效，并不代表多租户、高并发或长时间运行仍然稳定。因此，配方应当包含模型 commit、容器版本、硬件信息、关键环境变量和验证负载，最好还应标记已验证范围与已知限制。

前沿概念和技术

模板感知解码

模板感知解码是把输出中可由程序确定的部分移出自回归生成，只让模型生成真正具有不确定性的字段。与普通 constrained decoding 相比，它不仅约束合法 token，还直接减少生成 token 数量。对于固定 JSON、标注序列、工具调用和数据库更新，这种方法可以降低解码成本并改善结构可靠性。

KV Cache 作为任务编译结果

在 DIRECT 的场景中，KV Cache 不只是一次请求执行后的副产品。固定输入、输出模板和候选标签集合共同定义了可复用计算。可以把这一过程理解为一种轻量级任务编译：系统提前确定哪些 token 永远固定、哪些状态可以缓存、哪些位置必须由模型动态生成。未来的推理运行时可能需要暴露更明确的接口，让应用声明模板边界、可缓存区域和动态槽位。

配方驱动的模型适配

配方驱动适配强调把模型部署所需的环境、并行策略、量化设置和服务参数记录为可执行配置。它介于框架源码与运维脚本之间，是性能结果能否复现的关键层。随着模型结构差异扩大，单一默认参数越来越难覆盖 MoE、混合 attention、长上下文和多模态模型。

分离式推理的模型特化

通用的阶段分离只说明系统可以拆分，模型特化则决定拆分是否真正有效。不同模型的 KV 体积、专家通信、prefill 算术强度和 decode 内存访问模式不同，因此资源比例、批处理策略和网络预算不能直接复用。官方配方的出现说明社区正在把分离式推理从架构能力推进到具体模型的工程验证。

对大模型推理和存储优化的启发

第一，优化输出路径与优化模型计算同样重要。对于结构化任务，减少无意义的生成 token 可能比替换一个局部 kernel 更直接。系统研究应当统计“必须由模型生成的有效 token”与“因接口格式而产生的冗余 token”，并区分二者的成本。

第二，KV Cache 的复用边界可以由应用语义主动提供。传统 prefix cache 依赖运行时从 token 序列中发现相同前缀；模板感知系统则可以在请求进入引擎前就声明固定区域。这种显式信息有助于缓存键构造、批处理合并和容量预测，也能避免运行时重复执行昂贵的匹配逻辑。

第三，新模型性能评估必须绑定具体配方。只写“支持 FP8”或“支持分离式部署”无法说明可用性。至少需要记录权重来源、模型 revision、框架版本、GPU 型号、并行度、KV Cache 类型、上下文长度、并发设置和测量口径。否则不同团队得到的结果难以比较。

第四，开放 PR 可以作为趋势信号，但不能作为稳定能力的证据。技术报告在引用此类材料时，应明确标记 WIP、未合并或实验性状态，避免把路线图写成已发布功能。对性能数字尤其需要谨慎：没有完整测试脚本和环境时，不应从评论或截图推导普遍结论。

第五，应用层约束可以反向帮助调度器。模板化输出通常具有更可预测的生成长度和合法 token 集合，这会降低输出长度方差。调度器可以据此更准确地预留 KV Cache、安排 batch，并减少因超出估计长度导致的抢占或重排。

深度分析

今天的材料共同反映出，LLM 推理优化正在从“框架提供通用能力”转向“应用与模型显式暴露结构”。DIRECT 暴露输出结构，告诉运行时哪些文本不需要生成；vLLM Recipes 暴露部署结构，告诉使用者某个模型需要怎样的量化和并行组合。两者都在消除隐含知识。

这类结构化信息对于推理系统十分关键。没有模板信息时，运行时只能把每个输出 token 当成同等不确定；没有模型配方时，部署者只能依赖默认参数或反复试错。显式化之后，系统才能做更稳健的缓存、调度和资源分配。

从长期看，推理框架可能形成三层接口。底层是 kernel、通信和 KV 内存管理；中层是针对模型结构的执行配方；上层是针对应用 schema 的解码计划。性能优化不再只发生在底层，而是通过三层协同完成。一个固定格式的 Agent 工具调用，可以在上层减少生成长度；模型配方在中层选择合适的量化与并行方式；底层运行时再利用更确定的长度和缓存边界提升批处理效率。

今夜白的观察

今天没有出现足以单独改变推理系统路线的大型正式发布，但几个较小的信号值得持续观察。首先，受控解码正在从“保证 JSON 合法”走向“直接消除不需要生成的内容”。这会把应用协议设计变成推理性能的一部分。对于大量 Agent 工作负载，真正的优化空间可能并不只在模型内部，而在于重新设计模型与工具之间的输出契约。

其次，模型适配的竞争正在转向配方质量。框架能够加载模型只是起点，能否提供清晰、稳定、可复现的硬件与参数组合，才决定社区是否能够快速获得可用性能。Recipes 类仓库未来可能需要像核心代码一样具备测试矩阵、版本策略和回归标准。

最后，FP8、分离式部署和 KV Cache 优化不应被孤立评估。量化会改变显存占用与带宽压力，分离式部署会改变状态移动路径，输出模板会改变生成长度和缓存生命周期。更成熟的评测应把这些因素放在同一工作负载下分析，而不是分别报告局部加速。

参考资料

1. Yilei Wang, Jiaxin Gan, Kexuan Zhang, Ling Li, Wentao Zhang, Peichao Lai. DIRECT: Direct Decoding for Efficient and Aligned Sequence Labeling with Large Language Models. arXiv, 2026-07-29.
2. vLLM Recipes. Kimi-K3 FP8, Pull Request #688. 创建于 2026-07-28，检索时标记为 WIP。
3. vLLM Recipes. MiniMax M3 disagg, Pull Request #687. 创建于 2026-07-27。
4. vLLM Recipes. Official repository pull requests. 用于确认近期部署配方及其开放状态。