摘要9-25 我们用成本感知路由把请求派到自托管vLLM又用语义缓存砍掉重复流量但缓存只解决问得重复真正决定单卡成本的是引擎吞吐。本文落到vLLM 引擎层连续批处理如何把 GPU 利用率从 30% 拉到 90%、PagedAttention怎样让 KV Cache 不再为最长序列买单、投机解码用草稿模型把首 token 后延迟砍掉 2–3 倍并给出可直接抄的启动配置与压测方法。缓存省的是重复问的钱引擎优化省的是每一次都更贵的钱——两者叠加自托管 vLLM 的单位 token 成本才能压到云 API 的 1/5 以下。一句话结论在 9-25 路由落地的 vLLM 后端上用连续批处理 PagedAttention 前缀缓存打满利用率用投机解码压低延迟敏感场景的 TTFT/TPOT把路由省下的钱真正变成引擎省下的钱。1. 为什么路由之后还要碰引擎9-25 的hybrid_route把难任务派到vllm-local但一个朴素的 vLLM 部署常常跑得起来、跑不便宜现象根因代价GPU 利用率长期 30% 以下静态批处理static batching空等最长请求卡在空转钱在烧长上下文一上来就 OOMKV Cache 按最大长度预留碎片只能降并发吞吐崩短问答也慢自回归逐 token草稿全靠大模型自己TPOT 高体验差这三件事分别对应三项引擎级优化连续批处理、PagedAttention、投机解码。它们和 9-20 的 KV Cache 压缩是一脉相承的——9-20 管显存账怎么算本文管显存账怎么省、算力怎么喂满。2. 连续批处理让 GPU 永不空转静态批处理要等一个 batch 里最长的请求生成完才能释放短请求被迫陪跑。连续批处理continuous batching在每个解码步动态增删序列谁生成完谁退出新请求随时插队。静态批处理4 请求最长 200 token step1..200 四人同跑step3 起三人已完但仍占卡 → 浪费 197 步算力 连续批处理同 4 请求 step3 甲完成→释放step3 乙新请求插入 → GPU 始终满载vLLM 默认开启连续批处理瓶颈通常在max_num_seqs并发序列上限和max_num_batched_tokens每步 token 预算# 把利用率从 ~30% 拉到 ~90% 的关键参数python-mvllm.entrypoints.openai.api_server\--modelQwen3.8-27B\--tensor-parallel-size2\--max-num-seqs256\# 并发序列上限按显存调--max-num-batched-tokens8192\# 每步 batch token 预算--enable-prefix-caching# 见第 4 节经验账同款 2×A100max_num_seqs从 32 提到 256吞吐token/s约 ×3单位 token 成本对应 ÷3。3. PagedAttentionKV Cache 不再为最长序列买单传统实现给每个序列预留最大长度的连续显存长尾请求制造大量碎片。PagedAttention 像操作系统的虚拟内存分页把 KV Cache 切成固定大小的 block按需分配、按需回收。方案KV 显存占用碎片最大并发静态预留最长 × 序列数高低PagedAttention实际占用 × 序列数近 0高 3–5×# vLLM 的 block 管理示意理解用非调用classPagedKVCache:def__init__(self,block_size16,num_blocks1024):self.freelist(range(num_blocks))# 空闲块链表defappend(self,seq,tokens):# 每满 block_size 个 token 才申请一个新 blockifseq.tail_block.full:seq.tail_blockself.alloc()defalloc(self):returnself.free.pop()# O(1) 分配无碎片配合--gpu-memory-utilization 0.9把更多显存让给 KV Cache 池长上下文场景并发直接翻倍。这正是 9-20 百万上下文成本工程的落地解法KV 压缩MLA/GQA降单序列占用PagedAttention 降整体碎片。4. 前缀缓存让共享系统提示词只算一次很多业务每次请求都带相同的超长系统提示词 工具定义几百到几千 token。Prefix Caching 把这些前缀的 KV 块跨请求复用只算一次。--enable-prefix-caching# vLLM 0.4 已稳定命中自动复用场景无前缀缓存有前缀缓存节省固定 sys prompt 1.5k token100 QPS每次重算 1.5k命中复用首 token 延迟 ↓ ~40%Agent 多轮工具调用每轮重算历史历史前缀命中多轮成本 ↓ ~50%前缀缓存与 9-25 语义缓存是互补的两层语义缓存挡整句重复问前缀缓存挡相同前缀的多次计算一个在网关、一个在引擎。5. 投机解码用小模型猜大模型改自回归逐 token 生成受限于大模型的单步延迟。投机解码speculative decoding用一个小草稿模型一次猜 N 个 token大模型并行验证——猜对就全收猜错只回退到第一个分歧点。草稿模型(1.5B) 猜测: [A][B][C][D] 大模型(27B) 并行验证: A✓ B✓ C✗(应为X) → 接受 A,B从第 C 处重采 净效果: 4 步变 ~2.x 步TPOT 显著下降# 方案 A同架构小模型做草稿python-mvllm.entrypoints.openai.api_server\--modelQwen3.8-27B\--speculative-model Qwen3.8-0.6B\--num-speculative-tokens5# 方案 BMedusa 多头草稿无需独立小模型# 在模型后接 Medusa heads单次前向产出多位置候选方法适用加速TPOT成本小模型草稿任意1.8–3×需多载一个小模型Medusa同架构2–4×训练 heads无额外模型EAGLE同架构2.5–4×需树状草稿注意投机解码降延迟、不降总算力——它把大模型多步压成大模型少步 小模型多步在 GPU 便宜、延迟敏感对话/Copilot场景收益最大纯离线批处理场景增益有限。6. 可直接抄的压测与对账方法优化不能拍脑袋要压测对账。复用 9-24 的 OTel 成本归因把引擎优化量化为钱importtime,requests,statisticsdefbench(base_url,prompts,concurrency64):# 简单压测测 TTFT / TPOT / 吞吐importconcurrent.futuresascfdefone(p):t0time.time()rrequests.post(f{base_url}/v1/chat/completions,json{model:Qwen3.8-27B,messages:[{role:user,content:p}],stream:True})# 解析 SSE记录首字节与每 token 间隔...withcf.ThreadPoolExecutor(concurrency)asex:returnlist(ex.map(one,prompts))把压测结果喂回 9-25 网关的gateway.tenant_cost指标对比优化前 vs 优化后的单 token 成本给老板交差用一张表配置吞吐 (tok/s)单位成本 ($/M tok)相对云 API朴素 vLLM1,2000.900.5×连续批处理3,6000.301.5× 更省PagedAttention前缀5,4000.202.5× 更省投机解码延迟敏感5,400 / TPOT↓2.5×0.202.5× 更省7. 与既有能力对账既有能力在本文的位置升级点9-20 KV Cache 压缩PagedAttention 降碎片从算账到落地省9-25 成本感知路由vllm-local后端路由落地的后端真正变便宜9-25 语义缓存前缀缓存互补网关层 引擎层双缓存9-24 OTel 成本归因压测对账指标把引擎优化量化为钱引擎优化是 9-25 路由的下半身——路由决定派到哪引擎决定派过去贵不贵。8. FAQQ1连续批处理是不是默认就开AvLLM 默认开启但max_num_seqs/max_num_batched_tokens默认值偏保守必须按显存上调才能吃满利用率否则仍会空转。Q2PagedAttention 和 9-20 的 KV 量化冲突吗A不冲突且叠加更香——KV 量化降单序列显存PagedAttention 降整体碎片两者共同把能塞下的并发翻倍。Q3投机解码会不会让输出质量下降A不会。大模型是验证者草稿只是提议验证不通过就回退重采最终分布与大模型自回归完全一致只是更快。Q4前缀缓存命中率低怎么办A检查 sys prompt / 工具定义是否每次动态变化时间戳、随机 ID。把它们抽到固定前缀、变动部分放末尾命中率立刻上去。Q5Medusa 和独立小模型草稿选哪个A有同架构小模型如 27B0.6B直接用小模型草稿零额外训练否则上 Medusa/EAGLE但要训练 draft heads工程成本更高。Q6离线批处理也要开投机解码吗A意义不大。投机解码省的是延迟TPOT离线批处理只在乎总吞吐连续批处理 高并发已够投机反而多占显存。Q7这些优化和云端 API 比还值得自建吗A看量。压测表显示叠加优化后单位成本约为云 API 的 1/2.5当月调用超过千万 token 量级、且数据不能出域呼应 9-24 隐私维度时自建 vLLM 显著更省。9. 参考资料vLLM 文档Performance Tips Continuous Batching2026Kwon et al.PagedAttention for Efficient LLM ServingvLLM 论文2023Leviathan et al.Fast Inference from Transformers via Speculative Decoding2023本专栏百万上下文推理成本工程KV Cache 压缩与分页注意力实战2026-09-20本专栏统一 LLM 推理网关实战多租户配额、故障转移与成本护栏2026-09-25本专栏语义缓存与成本感知路由用向量缓存砍掉重复 LLM 调用2026-09-25