尧图网页设计 
前言最近在做 7B/13B 模型的生产化部署老板一句“为什么用户问个长问题首字要等 3 秒”直接把我送进 vLLM 源码里扒 Prefill。今天把 Prefill 的原理、vLLM 的黑魔法PagedAttention/Chunked Prefill和实战调参经验整理出来看完你就能对着监控面板指点江山了。一、先搞清概念Prefill 和 Decode 根本不是一回事很多新手以为 LLM 推理就是“一直 forward”其实 vLLM以及所有现代推理框架都严格分两阶段维度Prefill预填充Decode解码触发时机收到 Prompt 后生成第一个字前生成第 2 个 token 到结束并行度Prompt 所有 token并行算每次只算1 个新 token计算瓶颈计算受限FLOPs 爆炸GPU 算力吃满访存受限疯狂读 KV Cache显存带宽吃紧用户感知指标TTFT首 Token 延迟TPOT / ITL每秒吐字速度简单说Prefill 是一次性的“重活”Decode 是细水长流的“碎活”。二、vLLM 里 Prefill 的完整工作流程源码级视角当你curl调 vLLM API 发一个 PromptPrefill 在引擎里其实跑了这 4 步Step 1Scheduler 分配“虚拟内存页”vLLM 最骚的设计是PagedAttention后面细说。调度器Scheduler先按 Prompt 长度算需要多少个 KV Block默认 16 token / 块然后在 BlockManager 里找物理显存块建立一张block_table逻辑块 → 物理块映射。Step 2ModelRunner 组输入把 token_ids、position_ids、还有刚才的slot_mappingKV 要写进显存的哪个槽打包准备喂给 GPU。Step 3Transformer 层 Forward KV 落盘这是 Prefill 的核心循环每一层干 3 件事算 Q/K/VPrompt 所有 token 一起算大矩阵乘Tensor Core 狂喜调用flash_attn_varlen_func做带 Causal Mask 的注意力每个 token 只看自己左边把算好的 K/V 按 slot_mapping 直接写进物理块绝不搞中间拷贝Step 4采样第一个 Token最后一层隐藏态过 LM Head 拿 logitsSampler 吐出第一个字。✅ 注意Prefill 结束 Prompt 的 KV 全存好了 第一个字也预测出来了。之后 Sequence 才进 Running 队列开始 Decode。三、为什么原生 PyTorch 显存炸PagedAttention 救场如果你自己写 demo给 100 个用户每人预分配max_seq_len8192的 KV Cache显存利用率不到 20%因为用户可能只问了 100 字内部碎片连续显存申请容易失败外部碎片vLLM 的解法 操作系统的分页思想逻辑视图 [Block0][Block1][Block2]... (连续) 物理显存 [P_12] - [P_3] - [P_99]... (散的但 block_table 指着)KV Cache 切成16 token 一块的固定大小物理块Prefill 时注意力 Kernel直接读散块通过 block_table 寻址避免torch.cat整块连续内存显存利用率直接干到 ~96%这也是 vLLM 吞吐比 HuggingFace TGI 早期版本高的核心原因。四、Prefill 的两大进阶黑科技面试/吹牛必考1️⃣ Chunked Prefill专治“长 Prompt 卡住全场”假设你有个 32k token 的文档问答如果一次性 PrefillGPU 会埋头算 200ms 只处理你这一个请求其他正在聊天的用户 Decode 直接断流ITL 毛刺巨大vLLM V1 的解法把 Prefill 切块。一个 Scheduler Step 的预算 │─ Decode 请求 token优先级最高保吐字流畅 └─ 剩余 token 预算 → 分给等待中 Prompt 的一个 chunk效果长 Prompt 分 5~10 个 step 慢慢算完牺牲一点点 TTFT换来了全站 ITL 的平滑。 对应参数--max-num-batched-tokens想压 TTFT 就调大想压延迟毛刺就调小。2️⃣ Automatic Prefix CachingAPC相同 Prompt 白嫖加速RAG 场景里几百个用户问同一篇 PDF系统提示词System Prompt一模一样。vLLM 给每个“满的 KV Block”算个哈希指纹新请求来了先查“前缀指纹库”命中了直接把物理块指针借过去Copy-on-WritePrefill 只算“用户提问那一句”的新 token实测共享长上下文场景TTFT 能降一个数量级而且几乎零额外开销。五、生产环境调优 Cheat Sheet直接抄如果你现在就在管 vLLM 服务这几个参数建议马上看一眼# 启动 vLLM 的推荐 baselineA100/H100 通用 python -m vllm.entrypoints.api_server \ --model your-model-path \ --block-size 16 \ # 默认16长文本别乱改FlashAttention 适配过的 --enable-prefix-caching \ # 长系统提示/RAG 必开白送的加速 --max-num-batched-tokens 8192 \ # 核心杠杆512~16384 自己压测 --gpu-memory-utilization 0.90 # 留 10% 给激活值别吃太满调优心法RAG / 固定 Promptenable-prefix-cachingTrue 中等max-num-batched-tokens代码生成 / 追求首字快max-num-batched-tokens拉高甚至 32k多轮闲聊 / 高并发max-num-batched-tokens压低保 ITL 稳定六、总结一句话Prefill 是 vLLM 用算力换显存效率PagedAttention 用调度换体验平滑Chunked Prefill 用哈希换重复计算Prefix Cache的综合博弈。下次同事问你“为什么 vLLM 这么快”把这张图甩给他Prefill 管 KV 算得快Decode 管 KV 读得省PagedAttention 管显存不浪费。 延伸思考Prefix Tuning / LoRA 的前缀向量本质上也是 Prefill 阶段参与注意力你猜 vLLM 的 Prefix Cache 能缓存 P-Tuning 的虚拟 token 吗答案可以而且很有意思下篇写如果这篇帮你理清了 Prefill求个 点赞 ⭐ 收藏评论区聊聊你们线上 TTFT 压到多少 ms 了 深度解析 vLLM Prefill 阶段：从 TTFT 延迟到 PagedAttention，一文搞懂大模型推理加速核心
前言最近在做 7B/13B 模型的生产化部署老板一句“为什么用户问个长问题首字要等 3 秒”直接把我送进 vLLM 源码里扒 Prefill。今天把 Prefill 的原理、vLLM 的黑魔法PagedAttention/Chunked Prefill和实战调参经验整理出来看完你就能对着监控面板指点江山了。一、先搞清概念Prefill 和 Decode 根本不是一回事很多新手以为 LLM 推理就是“一直 forward”其实 vLLM以及所有现代推理框架都严格分两阶段维度Prefill预填充Decode解码触发时机收到 Prompt 后生成第一个字前生成第 2 个 token 到结束并行度Prompt 所有 token并行算每次只算1 个新 token计算瓶颈计算受限FLOPs 爆炸GPU 算力吃满访存受限疯狂读 KV Cache显存带宽吃紧用户感知指标TTFT首 Token 延迟TPOT / ITL每秒吐字速度简单说Prefill 是一次性的“重活”Decode 是细水长流的“碎活”。二、vLLM 里 Prefill 的完整工作流程源码级视角当你curl调 vLLM API 发一个 PromptPrefill 在引擎里其实跑了这 4 步Step 1Scheduler 分配“虚拟内存页”vLLM 最骚的设计是PagedAttention后面细说。调度器Scheduler先按 Prompt 长度算需要多少个 KV Block默认 16 token / 块然后在 BlockManager 里找物理显存块建立一张block_table逻辑块 → 物理块映射。Step 2ModelRunner 组输入把 token_ids、position_ids、还有刚才的slot_mappingKV 要写进显存的哪个槽打包准备喂给 GPU。Step 3Transformer 层 Forward KV 落盘这是 Prefill 的核心循环每一层干 3 件事算 Q/K/VPrompt 所有 token 一起算大矩阵乘Tensor Core 狂喜调用flash_attn_varlen_func做带 Causal Mask 的注意力每个 token 只看自己左边把算好的 K/V 按 slot_mapping 直接写进物理块绝不搞中间拷贝Step 4采样第一个 Token最后一层隐藏态过 LM Head 拿 logitsSampler 吐出第一个字。✅ 注意Prefill 结束 Prompt 的 KV 全存好了 第一个字也预测出来了。之后 Sequence 才进 Running 队列开始 Decode。三、为什么原生 PyTorch 显存炸PagedAttention 救场如果你自己写 demo给 100 个用户每人预分配max_seq_len8192的 KV Cache显存利用率不到 20%因为用户可能只问了 100 字内部碎片连续显存申请容易失败外部碎片vLLM 的解法 操作系统的分页思想逻辑视图 [Block0][Block1][Block2]... (连续) 物理显存 [P_12] - [P_3] - [P_99]... (散的但 block_table 指着)KV Cache 切成16 token 一块的固定大小物理块Prefill 时注意力 Kernel直接读散块通过 block_table 寻址避免torch.cat整块连续内存显存利用率直接干到 ~96%这也是 vLLM 吞吐比 HuggingFace TGI 早期版本高的核心原因。四、Prefill 的两大进阶黑科技面试/吹牛必考1️⃣ Chunked Prefill专治“长 Prompt 卡住全场”假设你有个 32k token 的文档问答如果一次性 PrefillGPU 会埋头算 200ms 只处理你这一个请求其他正在聊天的用户 Decode 直接断流ITL 毛刺巨大vLLM V1 的解法把 Prefill 切块。一个 Scheduler Step 的预算 │─ Decode 请求 token优先级最高保吐字流畅 └─ 剩余 token 预算 → 分给等待中 Prompt 的一个 chunk效果长 Prompt 分 5~10 个 step 慢慢算完牺牲一点点 TTFT换来了全站 ITL 的平滑。 对应参数--max-num-batched-tokens想压 TTFT 就调大想压延迟毛刺就调小。2️⃣ Automatic Prefix CachingAPC相同 Prompt 白嫖加速RAG 场景里几百个用户问同一篇 PDF系统提示词System Prompt一模一样。vLLM 给每个“满的 KV Block”算个哈希指纹新请求来了先查“前缀指纹库”命中了直接把物理块指针借过去Copy-on-WritePrefill 只算“用户提问那一句”的新 token实测共享长上下文场景TTFT 能降一个数量级而且几乎零额外开销。五、生产环境调优 Cheat Sheet直接抄如果你现在就在管 vLLM 服务这几个参数建议马上看一眼# 启动 vLLM 的推荐 baselineA100/H100 通用 python -m vllm.entrypoints.api_server \ --model your-model-path \ --block-size 16 \ # 默认16长文本别乱改FlashAttention 适配过的 --enable-prefix-caching \ # 长系统提示/RAG 必开白送的加速 --max-num-batched-tokens 8192 \ # 核心杠杆512~16384 自己压测 --gpu-memory-utilization 0.90 # 留 10% 给激活值别吃太满调优心法RAG / 固定 Promptenable-prefix-cachingTrue 中等max-num-batched-tokens代码生成 / 追求首字快max-num-batched-tokens拉高甚至 32k多轮闲聊 / 高并发max-num-batched-tokens压低保 ITL 稳定六、总结一句话Prefill 是 vLLM 用算力换显存效率PagedAttention 用调度换体验平滑Chunked Prefill 用哈希换重复计算Prefix Cache的综合博弈。下次同事问你“为什么 vLLM 这么快”把这张图甩给他Prefill 管 KV 算得快Decode 管 KV 读得省PagedAttention 管显存不浪费。 延伸思考Prefix Tuning / LoRA 的前缀向量本质上也是 Prefill 阶段参与注意力你猜 vLLM 的 Prefix Cache 能缓存 P-Tuning 的虚拟 token 吗答案可以而且很有意思下篇写如果这篇帮你理清了 Prefill求个 点赞 ⭐ 收藏评论区聊聊你们线上 TTFT 压到多少 ms 了