VLLM

4 月 21 日 vLLM 博客讲了一个很硬核的话题：如何把预填充/解码分离（P/D）扩展到混合 SSM-注意力模型。这看似小众，实则预示了下一代开源推理栈的发展方向。 把 P/D 分离用到混合 SSM 模型，难在哪？ P/D 分离的前提，是 prefill 算完后能把状态完整搬到 decode 实例。对纯注意力模型，要搬的就是 KV cache，布局整齐。但混合 SSM 模型（比如带 Mamba 卷积层的架构）除了注意力 KV，还有一套完全不同的卷积状态与 SSM 隐状态。两套数据结构混在一起，跨节点传输时极易错位。 vLLM 是怎么解这道题的？ 它引入「双描述符视图」，让同一批状态在 prefill 侧与 decode 侧各有自己的逻辑描述；再用「物理到逻辑块的桥接」把异构缓存布局对齐；并补上 Mamba 卷积状态的专门传输通道。这样 P/D 分离不再只服务于纯 Transformer。 这件事为什么对开源社区重要？ 越来越多新模型走「注意力加 SSM」的混合路线（Qwen3.5 的 GDN 就是一例）。如果开源推理栈跟不上，这些模型的部署就只能靠各家私有引擎。vLLM 把这套能力开源出来，等于让整个社区都能低成本服务混合架构模型。 推理框架的护城河正在变成什么？ 推理框架的护城河，正在从「支持多少模型权重」变成「能多快适配多异构的新架构」。vLLM 这次对 SSM 状态的搬运，是开源栈跟上模型创新速度的一个缩影。 这对未来模型选型有什么提示？ 当你评估一个新开源模型时，多问一句：它是纯注意力，还是混合 SSM？如果是后者，先确认主流推理栈对它的 P/D 分离、KV 搬运支持到什么程度，再决定规模能上多大。一个架构再先进，如果推理栈还不能高效搬运它的异构状态，实际部署成本会远超理论值。vLLM 这次把 SSM 状态传输开源，正是在补齐这块短板。未来一年，「模型架构创新」与「推理栈适配速度」会像两匹马一起跑，谁也不能落下——跑得再快的架构，跑不动也白搭。 对开源社区，这等于宣布：混合架构不再是私有引擎的自留地。谁都能在自己的集群上复现这套状态搬运，模型创新与工程实现终于能同频前进。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：vLLM-SSM

7 月 27 日 vLLM 团队宣布对 Kimi K3 实现 day-0 支持。这条博客最有信息量的不是「又支持了一个新模型」，而是它给出的那条部署提示：prefix caching 默认是关的。 K3 上线了，prefix caching 为什么反而默认关？ 对绝大多数 Transformer 模型，vLLM 默认就开 prefix caching，让重复前缀复用 KV。但 K3 采用了仍在快速演进的混合缓存设计，缓存块的组织方式和经典 KV 不完全一样。在混合缓存模型稳定之前，团队选择保守默认，需要显式传 –enable-prefix-caching 才打开。 这个细节对部署者很重要：如果你照常用法跑 K3，却发现缓存没命中、成本居高不下，第一反应应该是去检查这个开关，而不是怀疑模型本身慢。 day-0 支持对开源生态意味着什么？ 开源模型发布当天就能在主流推理框架上跑起来，已经从「奇迹」变成「标配」。vLLM 对 Qwen、Kimi 这类国产开源旗舰的适配速度，几乎与官方发布同步。背后是社区维护者与模型团队之间越来越紧的协作。 上 Kimi K3 时给部署者什么建议？ 上任何一个新开源模型，先读它在推理框架上的 release 说明，重点看三件事：prefix caching 默认状态、推荐量化方式、是否需要特定并行策略。这些往往决定了你第一批用户的账单体验。 开源模型的竞争现在拼的是什么？ 开源生态的竞争，已经不只是权重谁开放得早，而是「权重加推理栈加默认参数」的整套开箱体验。day-0 能跑只是入场券，跑得出便宜、跑得稳，才是真壁垒。 上线新开源模型前要核对什么？ 新开源模型到手，先别着急开跑。第一步读它在推理框架上的部署说明，把 prefix caching、量化、并行这三项默认值记下来。第二步，按说明手动打开被默认关闭的关键开关，比如 K3 的 –enable-prefix-caching。第三步，用一小批真实请求压测缓存命中率与单 token 成本，确认和你的预期一致。这一套动作看似琐碎，却能避免「模型跑得起来但账单看不懂」的常见窘境。开源社区对新模型的适配很快，但默认参数常常是保守值，真正的性价比要靠你自己拧出来。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：Kimi-K3

vLLM 团队 7 月 14 日发了与 TileRT 合作的博客，标题点出一个常被忽略的洞察：当 prefill 与 decode 分离之后，decode 侧其实是可以拔插的。 为什么 decode 侧值得单独做一个引擎？ prefill 是算力密集，堆矩阵乘优化就行；decode 是内存带宽密集，每吐一个 token 都要把整份权重从 HBM 读一遍。两类负载对引擎设计的要求完全不同。分离之后，prefill 池可以用一套优化，decode 池则可以换上为「低延迟流式输出」量身定做的引擎。 TileRT 就是这样一个面向延迟关键场景的专用 decode 后端。它把 decode 阶段的算子排布、访存模式重新组织，目标是把 token 间延迟压稳，而不是追求单批次最大吞吐。 可插拔 decode 带来什么架构启示？ 这件事的意义超出 vLLM 本身：它说明推理栈正在模块化。prefill、decode、路由、缓存各成一层，谁的实现更好就替换谁。对云厂商，这意味着可以针对自己的硬件做 decode 后端，而不必维护整套推理框架。 落地时该怎么选专用 decode 引擎？ 如果你的业务是对话式、对首 token 与流式延迟敏感，值得关注可插拔 decode 引擎；如果是批量离线处理，吞吐优先，专用 decode 带来的边际收益有限。 专用 decode 引擎是不是人人都该上？ 推理服务的「微服务化」已经开始。未来选推理栈，不再是选一个全家桶，而是像拼乐高一样选 prefill 池、decode 引擎、路由层各自最优的组合。 什么情况下反而不该追这个新引擎？ 可插拔 decode 引擎听上去很美，但它面向的是「延迟敏感、高并发流式」这一类特定负载。如果你的业务是离线批量生成、夜间跑批，吞吐与单位成本比毫秒级延迟更重要，那 decode 侧专用优化带来的收益有限，反而引入额外运维复杂度。判断标准很简单：打开你的线上 SLA，如果核心指标是「首 token 后多久出完一段」且用户在盯着屏幕等，那就值得上专用 decode；如果用户根本不看流式过程，提交后等结果就行，留在通用引擎上更划算。架构选择永远跟着负载走。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：TileRT解码 ...

vLLM V1 功能表里，FP8 KV Cache 已经标为可用。它解决的是推理服务最头疼的问题：长上下文把 KV cache 撑爆 HBM，能同时服务的并发数被迫砍半。 FP8 KV 到底能省下多少显存？ KV cache 的大小约等于「层数 × 序列长度 × KV 头数 × 头维度 × 字节数」。BF16 下每个元素占 2 字节，压到 FP8 的 E4M3 格式后变成 1 字节，同等 HBM 能装下约两倍长的上下文或两倍并发。在 GB300 NVL72 这类靠 HBM 容量决定吞吐的机器上，这直接转化为每百万 token 的成本下降。 省显存的代价藏在哪里？ 权重量化大家已经很熟，KV 量化的特殊之处在于：KV cache 里存的是历史注意力信息，一旦量化误差在长序列里逐步累积，模型对遥远位置的注意力会漂移，出现「长上下文末尾忘事」。所以 FP8 KV 不是免费午餐——短上下文几乎无感，超长上下文要专门评测召回质量。 什么场景该开 FP8 KV、什么场景不该？ 上下文在 32K 以内、并发吃紧，大胆开 FP8 KV；上下文逼近 1M、且任务强依赖远距离检索，先拿你的真实请求集测一遍准确率，再决定是否回退 BF16。vLLM 里通过相关开关开启，灰度切流即可。 FP8 KV 在推理部署里排什么位置？ FP8 KV Cache 会和 prefix caching、PD 分离一起，成为 2026 年推理部署的标准三件套。容量换精度，是这笔账的本质。 ...

vLLM 团队 8 月 6 日发了一篇博客：在 Qwen3.5 上把总吞吐做到单 GPU 约 25K TPS。这个数字背后，是一次对「混合架构」的服务化攻坚。 全注意力加 GDN 为什么让服务化变难？ Qwen3.5 不是纯 Transformer，而是把全注意力层与 Gated Delta Network（GDN）层叠在一起。GDN 属于线性/SSM 一路的高效结构，状态表示与注意力的 KV cache 完全不同。这带来两个工程难题：怎么在 Blackwell GPU 上把 GDN 算快，以及怎么在 prefill 与 decode worker 之间正确搬运这种异构状态。 25K TPS/GPU 这个数字是怎么挤出来的？ vLLM 的做法分两路：在算力侧针对 Blackwell 对 GDN 算子做专门加速；在通信侧扩展 NIXL 分离服务路线，让注意力 KV 与 GDN 状态都能跨 worker 传递。博客特别提到，SSM 支持 P/D 分离是社区沿着 NIXL 路线推出来的——这说明开源推理栈对新架构的适配速度，已经快到能跟上新模型发布节奏。 这对要上 Qwen3.5 的部署者意味着什么？ 如果你要上 Qwen3.5 这类混合架构模型，别拿纯 Transformer 的经验直接套：prefix caching 的行为、P/D 分离的可用性、甚至默认参数都可能不同。上线前按官方部署提示逐项核对，尤其关注混合缓存开关。 混合架构给部署者提了什么醒？ 25K TPS/GPU 证明了混合架构既能省显存、又能在新硬件上跑出高吞吐。未来模型不会再是清一色注意力，推理栈必须学会同时伺候两种状态。 ...

vLLM 文档里 Disaggregated Prefilling 仍标着 experimental，但已经是 2026 年大规模推理服务的主流方向之一。核心想法一句话：把 prefill 与 decode 拆到不同 GPU 池，分别优化。 prefill 与 decode 为什么是两种完全不同的瓶颈？ 一次请求进来，prefill 阶段要并行读完整段提示，是算力密集型，瓶颈在矩阵乘；decode 阶段逐个吐 token，是内存带宽密集型，瓶颈在把权重从 HBM 搬到计算单元。混在同一个 GPU 上跑，两者互相抢资源：一个长 prefill 会堵住正在 decode 的请求，让 token 间延迟（ITL）抖动。 拆成两池后，prefill 池专心吃算力，decode 池专心吃带宽，首 token 延迟（TTFT）与 token 间延迟（ITL）可以独立调优，甚至配不同的并行策略。 到底什么时候才值得做 P/D 分离？ 请求短、并发低的小服务，拆了反而多一次 KV 搬运的开销。当线上同时存在「大量长文档预填充」与「高并发流式输出」两类负载时，拆分的收益才压过搬运成本。vLLM 现在支持通过 connector 把 prefill 算好的 KV 块传到 decode 实例，靠 NIXL 这类高速通道做跨节点传输。 P/D 分离是不是抄大厂架构就行？ PD 分离不是银弹，而是一道容量规划题。先量出你线上 TTFT 与 ITL 哪个先触 SLA，再决定拆不拆、怎么配比两池 GPU。盲目抄大厂架构，常常是花钱买复杂度。 prefill 池与 decode 池该怎么配比？ 做容量规划时，先分别统计 TTFT 与 ITL 的线上达标率。如果 TTFT 先顶不住，说明瓶颈在 prefill 池，该加 prefill 侧 GPU；如果 ITL 抖动，说明 decode 池挤，该加 decode 侧。一个常见错误是按 1 比 1 平均分配两池，实际长上下文场景里 prefill 算力需求常常远大于 decode。建议从 prefill 多配起步，再根据监控回调。还要预留 KV 跨节点传输的带宽预算——NIXL 通道吃网络，别让它成为新瓶颈。拆分后务必做全链路压测，单看单侧性能没有意义。 ...

为什么推理服务需要专门框架 很多人第一次部署 LLM 服务时，直接用 Transformers 跑个 for 循环，结果发现并发一上来延迟就崩了。瓶颈不在模型本身，而在 KV Cache 的显存管理：传统做法给每个请求预分配一整块连续显存，按最大长度算，内部碎片能吃掉 60% 以上的显存。显存被浪费，能同时跑的请求数就上不去，吞吐自然低。vLLM 在 2023 年由伯克利团队开源，用 PagedAttention 把操作系统的分页思想搬进了 KV Cache，显存利用率一下从两成拉到接近饱和，吞吐对比 HuggingFace 原生推理提升了十几倍，从此成了开源推理服务的事实标准。 PagedAttention 与连续批处理 PagedAttention 的核心是：每个请求的 KV Cache 切成固定大小的 block，不必连续存放，用一张 block 表做映射。就像虚拟内存的页表，物理块可以散落在显存各处，逻辑上却连续。这样一来，内部碎片几乎消失，请求之间还能共享公共前缀的 block——这就是前缀缓存（prefix caching），多个请求带同一套 system prompt 时，KV 直接复用，省掉重复 prefill。 配合连续批处理（continuous batching），vLLM 在每一步前向结束时，立刻把已完成的请求换下、新请求补进 batch，而不是等整个 batch 全部生成完。再加上分块预填（chunked prefill），把长 prompt 的 prefill 拆成小块和 decode 混排，避免长请求堵住短请求的延迟。这三招叠加，是它吞吐领先的根本原因。 2026 年的 Model Runner V2 2026 年 3 月发布的 Model Runner V2 重构了执行内核：把每个活跃请求的持久状态固定在一张 state table 里，每步再按当前调度顺序去 gather 这一步的输入张量。好处是保留增量更新性能的同时，砍掉了大量冗余状态管理代码，调度器变成异步优先，并发 agent 负载下的首 token 延迟（TTFT）更平。同年 9 月还推出 vllm-metal，把这套分页 KV 与连续批处理搬到 Apple Silicon 上，M5 上 prefill 更快。Kimi K3 这类新模型发布一周内就能 day-0 支持，靠的正是模块化内核的灵活性。 ...

为什么本地部署突然香了 2026年本地大模型能跑生产环境，靠的是三件事： 量化技术成熟（4-bit/3-bit几乎不掉点） 推理框架优化（vLLM、SGLang的吞吐提升10倍） 开源模型追上来了（Qwen3、DeepSeek V4本地版） 硬件选型 场景 推荐配置 成本 个人开发 RTX 4090 24GB 1.5万 团队部署 2×A100 80GB 20万 CPU推理 至强+128GB内存 3万 部署流程 选模型：Qwen3-72B-Instruct 或 DeepSeek-V4-70B 量化：AWQ 4-bit，质量损失<2% 框架：vLLM，连续批处理 接入：OpenAI兼容API，直接对接现有应用 踩坑记录 KV Cache管理是吞吐关键，max_model_len不要设太大 多轮对话要自己管理history，框架不管 量化后有些推理能力会下降，代码模型建议保留更多精度

引言 2026年的大模型推理赛道，vLLM已经从最初的"PagedAttention论文实现"成长为最活跃的开源推理框架之一。社区贡献的插件数量突破300个，覆盖量化、调度、多模态、分布式等各个维度。本文将系统性梳理vLLM的生态全景，并给出生产部署的实操建议。 vLLM 核心架构演进 vLLM 0.6+ 版本引入了模块化推理引擎设计，将原本紧耦合的模型加载、KV Cache管理、调度器拆分为可插拔组件： from vllm import LLM, SamplingParams from vllm.plugins import register_plugin # 自定义调度插件 @register_plugin("scheduler", "priority_scheduler") class PriorityScheduler(BaseScheduler): def schedule(self, requests): return sorted(requests, key=lambda r: r.priority, reverse=True) llm = LLM( model="Qwen/Qwen3-72B", scheduler_plugin="priority_scheduler", tensor_parallel_size=4, gpu_memory_utilization=0.92, ) 这一架构变革使得第三方扩展无需fork主仓库即可集成，极大降低了生态参与门槛。 插件生态分类 截至2026年Q2，vLLM插件生态可大致分为以下几类： 类别 代表插件 核心功能 成熟度 量化加速 AWQ-GEMM, GPTQ-Marlin, FP8-KV 低比特推理与KV Cache量化 生产级 多模态 LLaVA-Plugin, Qwen-VL-Adapter 图像/视频/音频输入支持 生产级 调度优化 PriorityScheduler, BatchComposer 请求优先级与动态批处理 成熟 分布式 Ray-Distributor, DeepSpeed-VLLM 多节点张量并行与流水线并行 成熟 可观测性 VLLM-Tracer, Prometheus-Exporter 链路追踪与指标导出 成熟 模型适配 Mamba-Adapter, MoE-Router 非Transformer架构支持 实验性 关键插件深度解析 1. FP8-KV：KV Cache量化利器 FP8-KV插件将KV Cache从FP16压缩到FP8格式，显存占用直接减半，而推理质量几乎无损： from vllm.plugins import load_plugin load_plugin("vllm-fp8-kv") llm = LLM( model="meta-llama/Llama-4-70B", kv_cache_dtype="fp8", # 70B模型在单卡80G显存下可运行 gpu_memory_utilization=0.90, ) 在实际测试中，Llama-4-70B在FP8-KV模式下，吞吐量提升约35%，P99延迟降低22%，且MMLU评测分数仅下降0.3个百分点。 ...

推理引擎：LLM服务的核心基础设施 模型只是"大脑"，推理引擎是"神经系统"——它决定了模型服务能多快、能并发多少请求、成本多低。选对推理引擎，单GPU的吞吐量差异可达5-10倍。 三大主流引擎 vLLM：社区标准 架构特点： PagedAttention：操作系统级KV Cache管理 Continuous Batching：迭代级动态批处理 纯Python实现（核心算子用CUDA/Triton） 支持大多数主流开源模型 核心技术：PagedAttention 传统KV Cache: 请求A: [已分配 5/5 blocks] [等待分配...] 请求B: [已分配 3/3 blocks] → 内存碎片化，浪费30-60% PagedAttention: Block Pool: [A1][B1][A2][C1][B2][A3]... 每个请求通过页表映射到物理block → 零碎片，内存利用率接近100% 性能特征： 吞吐量：比HuggingFace Transformers高24倍 首token延迟：中等 显存利用率：90%+ 支持多模型共享GPU 优势： 社区支持最广，几乎所有模型首发支持 部署简单（一行命令启动） 持续迭代，功能快速扩展 劣势： 纯Python实现，某些热路径不如C++优化 不支持一些极致优化（如FP8推理） 调度策略相对简单 SGLang：结构化生成之王 架构特点： 前缀缓存（Prefix Caching）：跨请求共享计算 程序化生成：支持结构化输出约束 原生支持JSON/正则约束 C++核心，Python接口 核心技术：RadixAttention 请求1: "system: 你是助手\nuser: 天气" → 缓存KV Cache 请求2: "system: 你是助手\nuser: 股票" → 复用"system: 你是助手\n"的前缀KV Cache → 只需计算新的部分 多请求共享相同system prompt时，前缀缓存可节省50%+计算。 ...