相信很多做大模型应用的朋友都有这种感觉模型在短文本下推理很快一旦把上下文拉长到几十万 token首字延迟就变得非常难以接受。用户敲下问题后服务端要等好几秒才吐第一个字这在生产环境里几乎是致命的体验问题。而这背后的主要瓶颈往往不是模型本身而是 LLM 推理过程中的 Prefill 阶段。本文围绕长上下文 LLM 推理中的 Prefill 优化展开完整梳理 Prefill 阶段为什么慢、主流的加速思路是什么、如何通过 SGLang 与 vLLM 对接生产部署并给出可复制的启动脚本、关键参数说明和常见问题排查方案。无论你是在做 RAG 应用、Agent 系统还是基于大模型的内部服务这篇文章都适合参考。1. Prefill 阶段为什么是长上下文推理的瓶颈1.1 一次 LLM 推理的完整过程Prefill Decode要理解 Prefill 优化先要把 LLM 推理的完整流程拆开看。一次自回归生成可以分成两个阶段Prefill预填充阶段把用户输入的提示词Prompt一次性喂给模型并行计算出所有输入 token 的 Key/Value 状态并生成第一个输出 token。Decode解码阶段逐 token 生成后续输出每一步只计算一个新的 token并把当前 token 的 K/V 追加到已有的状态中。用一句话概括Prefill 是“一次算完输入”Decode 是“一个一个往后蹦”。在短文本场景下Prefill 占用的时间很短大家主要关心 Decode 的速度。但当输入上下文达到几万甚至几十万 token 时Prefill 的计算量会急剧膨胀成为延迟和吞吐的重要瓶颈。1.2 Prefill 阶段的计算特征为什么 Prefill 会慢从计算特征来看原因非常直观。第一它可以并行但计算量巨大。Prefill 阶段需要对输入序列中的所有 token 同时计算注意力计算复杂度与序列长度的平方成正比。一个 10 万 token 的输入注意力矩阵的规模是 10 万乘以 10 万显存和算力消耗都相当惊人。第二它受限于显存带宽。除了计算注意力Prefill 还要把模型参数和输入激活值反复搬运到计算单元。长序列下中间激活值占用大量显存很容易触发显存溢出或者被迫降低 batch size从而拉低吞吐。第三它与 Decode 的优化手段并不完全兼容。Decode 重视的是低延迟和 K/V 缓存复用而 Prefill 更依赖高并行度和算子融合。如果在同一个服务里用同一套参数处理这两个阶段往往没办法同时做到最优。1.3 为什么说 TTFT 是用户体感第一步TTFTTime To First Token指的是从用户发起请求到收到第一个输出 token 的时间。很多刚接触大模型推理优化的同学会困惑TTFT 到底包含 Prefill 还是“Prefill 加一次 Decode”从工程角度看通常所说的 TTFT 包含一次完整的 Prefill 计算以及首次 Decode 生成首个 token 的时间。因为服务端必须完成 Prefill 才能拿到第一个输出 token所以 Prefill 的耗时基本决定了 TTFT 的下限。这也是为什么长上下文场景下必须优先优化 Prefill否则无论 Decode 多快用户的第一印象都会很糟糕。2. 加速 Prefill 的主流技术路线2.1 注意力计算优化注意力计算是 Prefill 阶段最核心的耗时部分。常见的优化思路包括FlashAttention 系列通过分块计算注意力避免把完整的 N×N 注意力矩阵写入显存显著降低显存占用并提升计算效率。FlashInfer一个面向大模型推理的算子库提供更高效的注意力模板被 SGLang 等框架作为后端集成。稀疏注意力/线性注意力针对超长序列设计但在通用场景下仍然需要谨慎评估精度损失。在实际部署中优先使用支持 FlashAttention 或 FlashInfer 的推理框架是性价比最高的优化手段。2.2 算子融合与并行Prefill 阶段包含大量小算子例如矩阵乘法、Softmax、LayerNorm 等。如果每个算子都单独启动 kernelGPU 的利用率会很低。算子融合的核心思路是把多个连续操作合并成一个 kernel减少显存访问和 kernel 启动开销。在并行层面还可以通过以下方式提速Tensor Parallel张量并行把模型权重切分到多张 GPU 上适合单机多卡场景。Pipeline Parallel流水线并行把模型层切分到多张 GPU 上适合模型较大或跨机场景。数据并行与请求并行多路请求同时处理提升整体吞吐。SGLang 和 vLLM 都对张量并行和部分算子融合提供了内置支持使用时只需要通过启动参数配置即可。2.3 显存管理与 Chunked Prefill长上下文输入最容易碰到显存溢出。一个很实用的优化方案是 Chunked Prefill分块预填充把超长的输入切分成多个 chunk 逐块处理。这样可以避免一次性申请超大显存同时还能让 Prefill 与 Decode 请求交错执行提高 GPU 利用率。vLLM 中通过--max-num-batched-tokens等参数控制单次 batch 的最大 token 数实际上就能起到类似 Chunked Prefill 的效果。SGLang 也支持类似的调度策略对长上下文场景非常友好。2.4 缓存复用RadixAttention 与 Prefix Cache在多轮对话、Agent 工具调用、RAG 检索场景中不同请求之间往往共享相同的前缀内容。如果能把这些前缀的 K/V 缓存复用起来就能大幅减少重复的 Prefill 计算。vLLM 的 Prefix Cache基于 PagedAttention 的页级缓存复用当请求前缀与已有缓存一致时直接复用 K/V 页。SGLang 的 RadixAttention将 K/V 缓存组织成 Radix Tree基数树结构自动识别并复用公共前缀甚至支持更细粒度的缓存命中。这也是 SGLang 在长上下文、多轮对话和高并发场景下表现突出的重要原因。对于“47 倍速”之类的加速效果虽然不同硬件和场景下数据会有差异但缓存命中带来的收益在实测中确实非常可观。3. 环境准备与部署框架选型3.1 硬件与软件环境Prefill 优化和具体的硬件环境强相关。以下是一套参考环境版本需根据你的实际项目情况调整本文重点演示配置思路项目推荐配置操作系统Ubuntu 20.04 / 22.04GPUNVIDIA A100 / H100或昇腾 910B 等国产加速卡显存单卡 40GB 以上长上下文建议多卡CUDACUDA 11.8 / 12.1 及以上Python3.10 或 3.11推理框架SGLang、vLLM 二选一或对比使用容器方案Docker 或裸机 conda 环境均可如果你使用的是昇腾 910B 等非 NVIDIA 硬件需要特别注意框架对国产加速卡的适配情况。部分版本对昇腾的支持还不完善尤其是 embedding 模型和 reranker 模型的启动方式可能与 GPU 环境不同建议先阅读框架官方文档确认。3.2 SGLang 与 vLLM 怎么选这两个框架是目前大模型推理部署中讨论度最高的两个选择SGLang主打高性能和灵活的运行时调度RadixAttention 是它的核心亮点。适合多轮对话、长上下文、复杂 Agent 调用等场景Prefill 优化的可调参数比较多。vLLM生态成熟兼容性好社区用户量大。它基于 PagedAttention对显存管理和 Decode 阶段优化做得非常出色同样支持 Chunked Prefill。在实际项目中如果团队更看重稳定性和生态兼容性可以优先考虑 vLLM如果追求极限的长上下文性能和缓存复用率SGLang 非常值得尝试。两者都在快速迭代中建议在生产选型前做一次同模型同硬件的对比测试。4. 实战用 SGLang 部署并优化长上下文推理4.1 安装 SGLang推荐使用 Docker 方式部署这样环境隔离更干净也方便后续升级。# 拉取 SGLang 镜像 docker pull lmsysorg/sglang:latest # 创建容器并挂载模型目录 docker run -it --gpus all \ --shm-size 32g \ -p 30000:30000 \ -v /data/models:/models \ lmsysorg/sglang:latest \ bash如果你希望使用 conda 环境也可以先用 conda 创建 Python 3.10 环境然后通过 pip 安装pip install --upgrade pip pip install sglang[all]安装完成后可以用python -c import sglang; print(sglang.__version__)验证。4.2 启动服务下面以 Qwen 系列 32B 模型为例演示一个适合长上下文 Prefill 优化的启动脚本。python -m sglang.launch_server \ --model-path /models/Qwen2.5-32B-Instruct \ --host 0.0.0.0 \ --port 30000 \ --tp-size 4 \ --mem-fraction-static 0.8 \ --context-length 131072 \ --chunked-prefill-size 8192 \ --attention-backend flashinfer \ --enable-prefix-caching4.3 关键参数说明--tp-size 4表示使用 4 张 GPU 做张量并行。模型较大或上下文很长时这个参数能显著加快 Prefill 计算。--context-length 131072设置最大上下文长度。需要根据模型实际能力和显存调整不是越大越好。--chunked-prefill-size 8192单次 Prefill 的最大 token 数。长上下文场景建议设置成 4096 到 8192 之间的值避免一次性申请过多显存。--attention-backend flashinfer使用 FlashInfer 作为注意力后端通常在长序列下能获得更好的性能。--enable-prefix-caching开启前缀缓存配合 RadixAttention 使用多轮对话和 Agent 场景提升明显。--mem-fraction-static 0.8指定用于缓存和运行时的显存比例需要根据显存大小实测调整。启动后服务会监听 30000 端口。可以用下面的 Python 脚本快速测试import requests resp requests.post( http://localhost:30000/generate, json{ text: 请用三句话说明什么是 Prefill 阶段。, sampling_params: { max_new_tokens: 256, temperature: 0.7 } } ) print(resp.json())5. 实战用 vLLM 部署并优化 Prefill5.1 安装 vLLMvLLM 同样支持 Docker 和 pip 安装。建议先用官方镜像验证环境再根据业务需求定制依赖。docker pull vllm/vllm-openai:latest docker run -it --gpus all \ --shm-size 32g \ -p 8000:8000 \ -v /data/models:/models \ vllm/vllm-openai:latest \ bash5.2 启动服务python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-32B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 4 \ --max-model-len 131072 \ --max-num-batched-tokens 8192 \ --enable-prefix-caching \ --gpu-memory-utilization 0.85.3 与 SGLang 的差异说明--enforce-eager参数在 vLLM 中如果加上这个参数会关闭 CUDA Graph直接走 eager 模式。这个模式可以降低显存占用但通常会牺牲部分性能。生产环境长上下文场景下建议先测试不要因为显存紧张而盲目开启必要时优先缩小 batch size 或 max-model-len。--tensor-parallel-size等同于 SGLang 的--tp-size。--enable-prefix-cachingvLLM 的前缀缓存开关适合多轮对话和 RAG 场景。vLLM 默认提供 OpenAI 兼容接口部署完成后可以直接用 curl 测试curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /models/Qwen2.5-32B-Instruct, messages: [{role: user, content: 你好请介绍 Prefill 优化。}], max_tokens: 256 }6. 精度选择与量化部署6.1 FP16、BF16 与 FP32 如何选择精度选择对 Prefill 阶段的速度和显存占用影响非常大。简单说明三者的差别精度特点适用场景FP32数值范围广精度最高但显存占用大、速度慢小模型调试FP16显存占用减半速度较快但小数值容易出现精度溢出NVIDIA GPU 推理主流选择BF16动态范围与 FP32 接近训练和推理都更稳定推荐用于大模型推理INT8/INT4显存占用进一步降低速度提升但可能带来精度损失资源受限或长上下文场景在长上下文 Prefill 场景下显存是刚性约束。如果模型允许建议优先用 BF16如果还是放不下再考虑 AWQ、GPTQ 或 INT8 量化方案。需要注意的是量化模型的 Prefill 计算可能依赖反量化算子不同框架的实现差异较大部署前要做精度对比验证。6.2 量化模型的启动示例以 Qwen3.5-122B-A10B-GPTQ-INT4 这类模型为例无论使用 SGLang 还是 vLLM核心思路都是指定量化模型目录路径并配合多卡张量并行启动。SGLang 示例python -m sglang.launch_server \ --model-path /models/Qwen3.5-122B-A10B-GPTQ-INT4 \ --tp-size 8 \ --context-length 65536 \ --chunked-prefill-size 4096量化模型部署后建议用一组标准业务问题分别比较量化模型和原模型的输出质量再决定是否上线。7. 效果验证与性能对比7.1 如何测量 TTFT测量 TTFT 最直接的方法是在客户端记录请求发出时间和第一个 token 返回时间。下面是一个简单的 Python 脚本思路import time import requests url http://localhost:30000/generate long_prompt 这是一段很长的输入... * 1000 start time.time() resp requests.post(url, json{ text: long_prompt, sampling_params: {max_new_tokens: 1} }, streamTrue) first_token_time time.time() - start print(fTTFT: {first_token_time:.3f} s)需要注意的是max_new_tokens1时模型只需要做 Prefill 和一次 Decode能更准确地反映 Prefill 阶段的耗时。如果服务端有缓存命中首次请求和后续请求的 TTFT 会有明显差异这种差异本身就是 Prefix Cache 效果的一种验证。7.2 对比维度建议做性能对比时建议至少记录以下指标TTFT首 token 延迟Prefill 耗时Decode 吞吐token/s显存占用峰值同批次并发请求数尽量做到同一个模型、同一个输入文本、同一个硬件环境下对比才具有参考价值。8. 常见问题与排查思路问题现象常见原因解决思路长上下文启动时显存溢出context-length 设置过大或显存比例设置过高调小 context-length或降低 mem-fraction-static / gpu-memory-utilization使用 --enforce-eager 后性能下降关闭了 CUDA Graph执行效率降低尽量保留 CUDA Graph优先通过减小 batch size 来缓解显存多卡并行时负载不均tensor 并行配置不合理或模型切分不均检查 tp-size必要时结合 pipeline parallel前缀缓存命中率低输入前缀动态变化或未开启 prefix caching在 SGLang 开启 --enable-prefix-cachingvLLM 开启 --enable-prefix-caching昇腾 910B 上 vLLM 无法启动 embedding 模型框架对国产加速卡的模型类型支持有限查看框架官方适配文档必要时改用其他框架或单独部署 embedding 服务量化模型输出质量明显下降量化精度选择不合适对比 FP16/BF16 输出考虑改用 AWQ 或调整量化参数遇到问题时建议按以下顺序排查确认框架版本和模型版本匹配。查看服务端日志定位是显存问题还是算子兼容问题。把参数逐步降到最小可运行状态例如先关闭 prefix caching调小 context-length。确认是 Prefill 慢还是 Decode 慢可以通过max_new_tokens1的请求分开测。对比不同 attention 后端例如 flashinfer 与 flash-attention。9. 最佳实践与工程建议9.1 参数配置要按场景实测Prefill 优化没有“万能参数”。长文档问答、Agent 多轮调用、RAG 检索等场景对 Prefill 的要求完全不同。建议把参数配置做成环境变量或配置文件方便在测试环境快速切换。9.2 优先复用再谈压缩在长上下文场景中缓存复用带来的收益往往比单纯压缩模型更明显。如果业务中有大量重复前缀应该优先开启 Prefix Cache 或 RadixAttention再考虑是否通过量化降低显存。9.3 注意生产环境变更流程调整 Prefill 相关参数或升级框架版本前一定要在上线前做充分验证。特别是涉及--context-length、--tp-size这些直接影响显存分配和计算效率的参数时建议先在测试环境用压测脚本模拟线上流量。记录优化前后的 TTFT、吞吐、显存指标。保留可回滚的部署配置。逐步灰度发布不要一次性全量切换。9.4 日志与监控生产环境建议至少监控以下指标平均 TTFT 和 P95 TTFTPrefill 和 Decode 阶段耗时拆分GPU 利用率和显存占用前缀缓存命中率请求排队时间和超时率有了这些数据才能判断 Prefill 优化是否真正解决了业务瓶颈而不是只靠启动参数“感觉变快了”。10. 总结Prefill 阶段是长上下文 LLM 推理中不可回避的性能瓶颈。本文从 Prefill 的原理出发梳理了注意力算子优化、Chunked Prefill、张量并行、前缀缓存复用等主流加速手段并给出了 SGLang 和 vLLM 的完整部署示例与关键参数解释。在实际项目中Prefill 优化的收益非常依赖具体场景RAG 应用中公共前缀越多缓存复用带来的提升越明显超长上下文中 Chunked Prefill 能显著降低显存压力提高服务稳定性。如果你正在部署长上下文服务建议先用同一份测试数据对比 SGLang 和 vLLM 在你当前硬件上的表现再决定把哪一套方案放进生产环境。下一步可以继续深入学习 FlashInfer 后端实现、K/V 缓存调度策略以及量化模型在长上下文场景中的精度表现。把这些内容研究透大模型推理优化的功底就算真正扎实了。