vLLM 特性兼容矩阵全解析Chunked Prefill、APC、LoRA、推测解码与硬件支持的组合边界【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm本文以 vLLM 官方的特性兼容矩阵docs/features/README.md为核心系统梳理 vLLM 中一组互斥或存在组合约束的关键特性——Chunked Prefill分块预填充CP、自动前缀缓存APC、LoRA、推测解码SD、CUDA Graph、Pooling、编码器-解码器模型、Logprobs、异步输出处理、多步调度、多模态输入、Best-of / Beam Search 与 Prompt Embeds——在特性两两组合以及各硬件平台上的支持情况并结合当前仓库源码说明每个特性的配置入口与实现依据帮助你在部署时快速判断哪些特性可以同开、哪些硬件上必须取舍。符号约定与阅读方法官方矩阵使用如下符号标注兼容性✅ 完全兼容 部分兼容❌ 不兼容❔ 未知或待定TBD矩阵中带有链接的 ❌ / 符号其链接指向跟踪该特性-硬件/特性-特性组合问题的 tracking issue可用于跟进修复进展。以下所有结论均以当前仓库文档与源码为准适用前提是仓库当前的 V1 引擎实现。特性 × 特性兼容矩阵完整版以下是官方Feature x Feature矩阵的完整继承。行与列为 15 个特性单元格为行特性 × 列特性同时启用时的兼容性| 特性 | CP | APC | LoRA | SD | CUDA graph | pooling | enc-dec | logP | prompt logP | async output | multi-step | 多模态 mm | best-of | beam-search | prompt-embeds | | - | - | - | - | - | - | - | - | - | - | - | - | - | - | - | - | | CP | ✅ | | | | | | | | | | | | | | | | APC | ✅ | ✅ | | | | | | | | | | | | | | | LoRA | ✅ | ✅ | ✅ | | | | | | | | | | | | | | SD | ✅ | ✅ | ❌ | ✅ | | | | | | | | | | | | | CUDA graph | ✅ | ✅ | ✅ | ✅ | ✅ | | | | | | | | | | | | pooling | * | * | ✅ | ❌ | ✅ | ✅ | | | | | | | | | | | enc-dec | ❌ | ❌ | ❌ | ❌ | ✅ | ✅ | ✅ | | | | | | | | | | logP | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ | | | | | | | | | prompt logP | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ | ✅ | | | | | | | | async output | ✅ | ✅ | ✅ | ❌ | ✅ | ❌ | ❌ | ✅ | ✅ | ✅ | | | | | | | multi-step | ❌ | ✅ | ❌ | ❌ | ✅ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | | | | | | 多模态 mm | ✅ | ✅ | | ❔ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ❔ | ✅ | | | | | best-of | ✅ | ✅ | ✅ | ❌ | ✅ | ❌ | ✅ | ✅ | ✅ | ❔ | ❌ | ✅ | ✅ | | | | beam-search | ✅ | ✅ | ✅ | ❌ | ✅ | ❌ | ✅ | ✅ | ✅ | ❔ | ❌ | ❔ | ✅ | ✅ | | | prompt-embeds | ✅ | ✅ | ✅ | ❌ | ✅ | ❌ | ❌ | ✅ | ❌ | ❔ | ❔ | ✅ | ❔ | ❔ | ✅ |其中两处官方脚注原文原样继承部署时务必注意* Chunked prefill 与前缀缓存仅适用于因果注意力的 last-token 或 all pooling 场景。^ 多模态模型的 LoRA仅适用于语言主干language backbone。矩阵解读四条最关键的组合边界1. 推测解码SD是当前约束最多的特性。从矩阵看SD 与 LoRA、pooling、multi-step、best-of、beam-search、prompt-embeds 均不兼容❌与多模态组合的状态为 ❔ 待定。这与源码中的实现路径一致vllm/config/speculative.py 定义了num_speculative_tokens、草稿模型相关字段及一组校验逻辑例如要求num_speculative_tokens必须与草稿机制匹配推测解码走的是独立的 propose verify 调度路径与 LoRA 的权重注入、pooling 的抽取式输出在实现上天然互斥。各 SD 方案的文档见 docs/features/speculative_decoding/README.md包括 EAGLE、MLP、MTP、n-gram、suffix 等子目录文档。2. 编码器-解码器模型enc-dec与 CP/APC 互斥。enc-dec 行中 CP 为 ❌APC 为 ❌跟踪 issue 未解决LoRA 与 SD 同样为 ❌但它与 CUDA graph、pooling、logP 等兼容。也就是说如果你要跑 encoder-decoder 架构模型分块预填充与前缀缓存这两个吞吐优化的默认收益都拿不到这是此类模型部署前最应该确认的限制。3. 多步调度multi-step与 CP 直接冲突且与 LoRA、SD、best-of、beam-search 互斥。multi-step 是把一个 step 的多次 decode 合并进一次 GPU 启动以减少 CPU 开销的调度策略它依赖固定的连续 decode 形态因此在长请求进入时动态分块的 CP 场景下无法工作。它同样不适用于 pooling 模型pooling 请求在单次前向后就结束没有多步可跑。4. logP / prompt logP 与 pooling 互斥。矩阵中 pooling × logP、pooling × prompt logP 均为 ❌pooling 任务embedding、分类、reward 等输出的是池化向量而非自回归 token 序列token 级 logprobs 对其无定义。对应地vllm/sampling_params.py 中SamplingParams的logprobs字段注释明确最多返回logprobs1个元素prompt_logprobs则对应提示词阶段每个 token 的 logprob 计算两者在生成式路径上均可与 CP、APC、LoRA、SD、CUDA graph 同开。特性 × 硬件兼容矩阵完整版以下为官方Feature x Hardware矩阵的完整继承列覆盖 Volta、Turing、Ampere、Ada、Hopper 五档 NVIDIA 架构及 CPU、AMD、Intel GPU特性VoltaTuringAmpereAdaHopperCPUAMDIntel GPUCP❌✅✅✅✅✅✅✅APC❌✅✅✅✅✅✅✅LoRA✅✅✅✅✅✅✅✅SD✅✅✅✅✅❌✅✅CUDA graph✅✅✅✅✅❌✅❌pooling✅✅✅✅✅✅✅✅enc-dec✅✅✅✅✅✅❌✅多模态 mm✅✅✅✅✅✅✅✅prompt-embeds✅✅✅✅✅✅❔✅logP✅✅✅✅✅✅✅✅prompt logP✅✅✅✅✅✅✅✅async output✅✅✅✅✅❌❌✅multi-step✅✅✅✅✅❌✅✅best-of✅✅✅✅✅✅✅✅beam-search✅✅✅✅✅✅✅✅硬件维度的要点VoltaV100 等CP 与 APC 不可用带 tracking issue 链接即旧架构下这两项功能存在未解决的问题其余特性正常。这意味着在 Volta 上长 prompt 会退化为整段进 batchKV 复用也不可用。CPUSD、CUDA graph、async output、multi-step 均不可用属于典型的功能降级平台enc-dec、多模态、logP 等仍可运行。AMD总体支持良好但 enc-dec ❌、async output ❌。Intel GPU仅 CUDA graph 一项 ❌带 tracking issue其余主流特性均可用。关于 Google TPU 上的特性支持官方注明不在此表中需另行参考 TPU 侧的推荐模型与特性文档见 docs/features/README.md 末尾的 note。各特性的源码依据与配置入口下面把矩阵中每一项映射到仓库中的真实配置字段与实现位置便于按图索骥。CPChunked Prefill默认开启docs/configuration/optimization.md 明确说明在 V1 引擎中只要可能chunked prefill 默认开启调度策略优先安排 decode 请求剩余max_num_batched_tokens预算再用于 pending prefill放不下时自动把长 prefill 切块。对应源码在 vllm/config/scheduler.pyenable_chunked_prefill: bool True # 默认 True该文件中的校验逻辑还包含当 CP 被禁用时要求max_num_batched_tokens大于max_model_len因为整段 prefill 必须一次进 batch。这也解释了矩阵中multi-step × CP ❌的根源——多步调度需要稳定的 decode-only 批次形态无法容纳动态切入的 prefill 块。APC自动前缀缓存默认开启字段位于 vllm/config/cache.pyenable_prefix_caching: bool True即前缀缓存在当前版本同样默认启用与 CP 的组合矩阵 ✅意味着边分块 prefill 边写入可复用块是 V1 的常态工作模式。原理与使用细节可深入 docs/features/automatic_prefix_caching.md 以及设计文档 docs/design/paged_attention.md。注意矩阵脚注pooling 模型下 CP/APC 仅对因果注意力的 last-token / all pooling 生效。LoRA动态多模型服务配置字段集中在 vllm/config/lora.py其中max_lora_rank默认值为 16max_lora_rank: MaxLoRARanks 16使用文档见 docs/features/lora.md。矩阵中 LoRA 与 CP、APC、CUDA graph、logP、multi-step 之外的多数特性均 ✅与 SD ❌、enc-dec ❌多模态下 LoRA 仅作用于语言主干 脚注。SD推测解码配置入口为 vllm/config/speculative.py 中的推测解码配置num_speculative_tokens、草稿模型等字段且包含大量一致性校验如num_speculative_tokens需要与具体方案的n_predict/ block_size 对齐。特性文档目录为 docs/features/speculative_decoding/内含 EAGLEeagle.md、MLPmlp.md、MTPmtp.md、n-gramn_gram.md、suffixsuffix.md、并行草稿模型parallel_draft_model.md、动态推测解码dynamic_speculative_decoding.md等子方案文档。硬件上 CPU 平台 ❌ 不支持与矩阵一致。CUDA GraphCUDA Graph 捕获 decode 阶段的整图执行避免每步 kernel 启动开销矩阵显示它与 CP、APC、LoRA、SD、pooling 组合全部 ✅硬件上 CPU 与 Intel GPU ❌ 不可用。设计背景可参考 docs/design/cuda_graphs.md 与 docs/design/torch_compile.md。Pooling嵌入、分类等非自回归任务vllm/pooling_params.py 定义了PoolingParams用于 embedding / classify / score / reward 等池化任务的请求参数。pooling 模型体系文档在 docs/models/pooling_models/README.md。矩阵中 pooling 的关键限制× SD ❌、× logP/prompt logP ❌、× multi-step/best-of/beam-search ❌、× async output ❌、× CP/APC 仅 限因果注意力 last-token/all pooling。Prompt Embeds 与多模态prompt-embeds以嵌入向量代替部分 prompt token见 docs/features/prompt_embeds.md与 CP、APC、LoRA、CUDA graph、best-of 兼容 ✅但与 SD、enc-dec、logP 之外的 prompt logP ❌ 不兼容AMD 上状态 ❔ 待定。多模态输入见 docs/features/multimodal_inputs.md与所有主流特性 ✅ 或 仅 LoRA 受限硬件全平台 ✅是矩阵中横向覆盖面最广的特性之一。logP / prompt logPlogprobs与prompt_logprobs均为 vllm/sampling_params.py 中SamplingParams的请求级参数logprobs取int | None表示返回 top-k logprob最多logprobs1个元素。两者与 CP/APC/LoRA/SD/CUDA graph 的组合均为 ✅唯与 pooling ❌——池化输出没有 token 概率分布。Best-of / Beam Searchbest_of与beam_searchbeam_width同样由 vllm/sampling_params.py 承载。矩阵中两者组合基本兼容主流优化项但 × SD ❌有 tracking issue、× multi-step ❌有 tracking issue、× pooling ❌、× async output ❔。Async Output 与 Multi-stepAsync output异步输出处理把 detokenize 等后置处理移出关键路径硬件上 CPU/AMD ❌ 不可用与 SD、pooling、enc-dec 互斥。Multi-step 的 CPU 不可用同样带 tracking issue属于有已知阻塞问题的组合。使用建议如何在矩阵上做一次部署前核对先定硬件行确认目标平台在Feature x Hardware中的 ❌ 项如 Volta 上没有 CP/APCCPU 上没有 SD/CUDA graph/async output这些是硬约束。再划特性行把计划同时启用的特性两两查Feature x Feature重点关注 SD 列/行互斥面最大以及 enc-dec、pooling 行。遇到带链接的 ❌/ 时查 tracking issue矩阵中链接的 issue 是这些组合已知问题的官方跟踪入口可判断是已排队修复还是长期限制。用源码字段名回查文档本仓库的矩阵文档位于 docs/features/README.md每个特性名本身就是指向其使用文档的相对链接特性开关的默认值如enable_chunked_prefill、enable_prefix_caching均为默认 True可直接在 vllm/config/scheduler.py、vllm/config/cache.py 中核对确保你读到的矩阵与实际生效配置一致。小结vLLM 的特性矩阵传达的核心信息是大多数吞吐优化CP、APC、CUDA graph、logP可以无脑叠加而推测解码、编码器-解码器模型与 pooling 是三个互斥密度最高的特性族——启用 SD 时要放弃 LoRA/best-of/beam-search/prompt-embeds部署 enc-dec 模型时要放弃 CP/APC做池化任务时 token 级 logprobs 与多步调度均不可用。硬件维度上 Volta 与 CPU 是主要降级平台。以当前仓库的矩阵为基线、用各特性文档与源码字段交叉核对可以在部署前把开哪些、关哪些一次性定下来。【免费下载链接】vllmA high-throughput and memory-efficient inference and serving engine for LLMs项目地址: https://gitcode.com/GitHub_Trending/vl/vllm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
