先说结论大模型推理里Prefill预填充阶段决定了你发出第一句话后“转圈”多久也就是TTFTTime To First Token首 Token 延迟的主要构成。很多团队在长上下文场景下被 TTFT 逼得换卡、降并发却没有意识到Prefill 的优化空间往往比 Decode 更大极端情况下能跑出数十倍的差距。这篇文章我会先讲清楚 Prefill 为什么慢再结合目前生产环境最常用的SGLang和vLLM两个推理框架给出可落地的加速配置、启动脚本、验证方法和排错清单。无论你是刚接触 LLM 部署还是已经在生产环境里调过 SGLang/vLLM 参数这篇文章都可以直接当参考手册用。1. 背景与核心概念1.1 什么是 Prefill为什么它决定了 TTFT大模型生成一次回答内部实际上分两个阶段Prefill预填充把用户的输入 Prompt 一次性送入模型逐层计算生成完整的 KV Cache并输出第一个 Token。Decode解码基于 KV Cache 逐个生成后续 Token每步只算一个 Token。这里有一个关键点用户感知到的“首字响应速度”大多数时间都耗在 Prefill 阶段。因为 Prefill 需要把整段 Prompt 都过一遍 Transformer 的所有层Token 数越多计算量越大。而 Decode 阶段虽然也有延迟但因为每一步只处理一个 Token单步耗时相对稳定后端通常还可以用流式输出“掩盖”一部分等待感。TTFT 的准确定义不同团队口径不完全一致。严格来说TTFT 指的是从请求发出到收到第一个 Token 的时间。由于 Prefill 计算完成之后才会输出第一个 Token所以TTFT ≈ Prefill 计算时间 网络开销 调度等待时间也就是说如果你想优化 TTFT优先看 Prefill 阶段是没错的。1.2 Prefill 为什么慢不只是“计算量大”很多人把 Prefill 慢简单归结为“模型太大”“输入太长”其实从工程角度看Prefill 的瓶颈通常来自三个方向计算密集长 Prompt 对应着巨大的矩阵乘法属于典型的 Compute-Bound 场景。显存带宽与容量长序列会生成大量 KV Cache如果显存不够Prefill 过程中就可能触发碎片整理、逐块卸载甚至 OOM。调度开销当多个请求同时到达时推理框架需要决定如何切分 Batch、如何分配显存块。调度策略不合理GPU 利用率可能非常低。常规的优化思路包括减少无效计算稀疏注意力、提高计算并行度Chunked Prefill、复用历史计算结果Prefix Cache、优化显存分配PagedAttention等。1.3 “最高 47 倍速”是怎么来的很多同学看到“47 倍速”会怀疑是不是标题党。这里需要说清楚在长上下文场景下稀疏注意力类方法确实可能带来数十倍的 Prefill 加速。原理并不复杂。标准 Attention 的复杂度是 O(n²)当上下文长度从 2K 涨到 32K、128K 甚至更长时Prompt 越长Attention 计算量的增长速度越夸张。而实际文本里很多 Token 之间的注意力权重非常低完全可以跳过。稀疏注意力就是通过算法判断哪些 Token 对之间不需要计算从而把复杂度从 O(n²) 压到接近 O(n log n) 甚至 O(n)。在理想的长文本压测中几十倍加速并不是不可能。但这里有两层意思需要理解不是所有场景都能到 47 倍。短 Prompt、低并发、GPU 本身很强大的情况下Prefill 占比低优化的绝对收益不明显。优化的最终价值体现在“长上下文 高并发 低 TTFT”的组合场景。这类场景在 RAG、代码库分析、长文档问答、Agent 记忆管理中非常常见。所以这篇文章不打算只讲某一个“神器”而是把 Prefill 加速的常用工程手段串起来重点落在SGLang 和 vLLM 这两个生产级框架上。2. 主流加速思路与可选方案2.1 稀疏注意力把 O(n²) 降下来以长文本 RAG 场景为例用户上传一篇 10 万字的文档系统需要让模型“理解全文”。如果把这 10 万字全部塞进 Prompt标准 Attention 的计算量会非常惊人。稀疏注意力的核心思想是不要盲目计算所有 Token 对之间的注意力而是结合固定窗口、全局 Token、检索结果等方式只选择一部分关键关系进行计算。比如某些方案会让每个 Token 只关注最近的若干个 Token再额外关注少量全局 Token 或与当前任务相关的 Token。这类方法的工程落地通常有两种形态训练时就采用稀疏注意力结构推理直接受益。推理阶段做后处理优化把标准 Attention 的某些计算“剪掉”或者把注意力矩阵稀疏化。需要提醒的是稀疏注意力虽然能大幅降低计算量但对模型精度、长距离依赖能力的影响需要充分评测。生产环境落地时一定要带着业务数据做效果对比不能只看 TTFT。2.2 Chunked Prefill不要让长 Prompt 独占 GPU很多框架默认把一段长 Prompt 一次性算完这会导致两个问题单个长请求占满 GPU其他并发请求被阻塞。长 Prompt 的前半部分与后半部分计算时间跨度大GPU 在波次之间可能闲置。Chunked Prefill 的思路是把长 Prompt 切成多个 Chunk每个 Chunk 分别做 Prefill计算完一部分就释放一部分调度资源让 Prefill 和 Decode 可以交错执行。这样不仅降低了单请求的峰值显存压力还能提高 GPU 利用率。在 SGLang 中--chunked-prefill-size参数用来控制单个 Chunk 的 Token 数。vLLM 中也支持类似机制合理配置后长上下文场景下的整体吞吐会有明显提升。2.3 KV Cache 复用避免重复计算已是共识长上下文场景里经常出现“多个请求共享同一段前缀”的情况。例如RAG 场景下系统提示词System Prompt很长每轮问答都携带同一段指令。Agent 场景下多轮对话的历史消息是逐轮追加的前面的历史消息不需要重新计算。代码库分析场景下项目背景说明、仓库结构说明每次都一样。如果每来一个请求都把整段前缀重新 Prefill 一遍非常浪费。SGLang 的RadixAttention和 vLLM 的Prefix Caching就是为了解决这一点通过树状或哈希结构复用前缀的 KV Cache命中后直接跳过重复计算。这类优化在长上下文场景下收益非常直接往往能让 TTFT 从几秒降到几百毫秒。2.4 单一方案无法用到底组合调优才是关键我在前面提到“47 倍速”并不是说某一个参数打开就能拿到。实际上生产环境通常需要组合使用稀疏注意力或等价优化从算法层面降低 Prefill 计算量。Chunked Prefill让 GPU 调度更平滑。Prefix Caching / RadixAttention避免重复 Prefill。量化与精度选择在显存和延迟之间取平衡。合理的 Batch 和并发控制避免请求互相抢资源。下面我们进入实战环节分别看 SGLang 和 vLLM 怎么配置。3. 环境准备与部署选型3.1 硬件要求与推荐配置Prefill 是计算密集型阶段GPU 的算力尤其是 FP16/BF16 的稠密算力比显存大小更能影响 Prefill 首 Token 延迟。但既然要做长上下文显存也绝对不能小因为 KV Cache 会随序列长度线性增长。一个比较典型的配置参考资源建议规格说明GPUNVIDIA A100 / H100 / L40S / 4090 及以上显存建议不低于 24GB长上下文或大模型建议 40GB 以上内存64GB 以上模型加载、预处理、Python 进程开销较大磁盘预留模型体积的 2 倍以上例如 7B 模型 FP16 约 14GB建议预留至少 30GB系统Ubuntu 22.04 / 24.04生产环境最常用的 Linux 发行版注意vLLM 官方对 Windows 的支持一直比较有限虽然通过 WSL 或 Docker 也能跑但强烈建议生产环境直接使用 Linux 服务器。如果你只是本地调试可以用 WSL 2 Docker 的方式避免在 Windows 原生环境下踩依赖坑。3.2 安装 SGLang 与 vLLM推荐使用 Docker 部署这样能最大程度避免 CUDA、PyTorch、框架版本之间的兼容性问题。下面的命令以常见镜像为例具体版本名需要根据你的环境调整。vLLM 的 Docker 启动方式# 拉取镜像请以官方 Docker Hub 实际版本为准 docker pull vllm/vllm-openai:latest # 启动容器并挂载模型目录 docker run --runtime nvidia --gpus all \ -v /data/models:/models \ -p 8000:8000 \ --ipchost \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-7B-Instruct \ --gpu-memory-utilization 0.9 \ --max-model-len 32768SGLang 的 Docker 启动方式# 拉取镜像 docker pull lmsysorg/sglang:latest # 启动容器 docker run --runtime nvidia --gpus all \ -v /data/models:/models \ -p 30000:30000 \ --ipchost \ lmsysorg/sglang:latest \ python3 -m sglang.launch_server \ --model-path /models/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 30000如果你不想用 Docker也可以直接通过 pip 安装# vLLM pip install vllm # SGLang pip install sglang[all]版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。3.3 版本与兼容性注意事项在实际部署前务必确认以下几点CUDA 版本vLLM 和 SGLang 对 CUDA 版本有要求建议使用 11.8 或 12.1 以上版本。PyTorch 版本SGLang 对 PyTorch 版本较敏感升级框架时最好同时升级推理框架。模型格式Hugging Face 格式是兼容性最好的如果是量化模型GPTQ、AWQ要确认推理框架已内置对应 Kernel。昇腾等非 NVIDIA 硬件vLLM 对昇腾的适配在逐步完善但有些功能比如部分量化算子、某些 Prefix Caching 行为不一定等价。如果你在昇腾 910B 等设备上部署建议先确认官方支持矩阵不要默认所有 NVIDIA 特性都能直接用。4. SGLang 侧 Prefill 加速配置SGLang 是专门针对 LLM 推理延迟和吞吐做过系统性优化的框架它的核心亮点之一就是RadixAttention在长上下文、多轮对话、共享前缀场景下能显著减少 Prefill 计算量。4.1 核心优化项SGLang 中对 Prefill 影响最大的几个参数--chunked-prefill-size把 Prefill 请求切成固定大小的 Chunk。默认值通常是 8192 或 -1表示不切。长上下文场景建议设置为 2048 或 4096可以减少显存峰值让 Prefill 与 Decode 交错执行。--enable-mixed-chunk允许一个 Chunk 内部同时包含 Prefill 和 Decode 请求进一步提升 GPU 利用率。--radix-attention默认开启用于复用 KV Cache。一般不需要关闭。--max-running-requests限制并行运行的请求数避免长请求占用全部资源。--mem-fraction-static控制静态显存比例长上下文场景需要给 KV Cache 留足空间。4.2 一份可用的长上下文启动脚本下面以Qwen2.5-7B-Instruct为例给出一份适合长上下文 Prefill 优化的启动脚本。python3 -m sglang.launch_server \ --model-path /data/models/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 30000 \ --max-model-len 32768 \ --chunked-prefill-size 4096 \ --enable-mixed-chunk \ --mem-fraction-static 0.85 \ --max-running-requests 32 \ --context-length 32768 \ --trust-remote-code如果模型是 GPTQ INT4 量化格式可以在启动命令中加入量化参数python3 -m sglang.launch_server \ --model-path /data/models/Qwen3-122B-A10B-GPTQ-Int4 \ --quantization gptq \ --host 0.0.0.0 \ --port 30000 \ --max-model-len 32768 \ --chunked-prefill-size 2048 \ --enable-mixed-chunk \ --mem-fraction-static 0.85注意不同版本 SGLang 对--quantization gptq的写法可能略有差异请以官方文档为准。4.3 参数怎么调更合理如果显存较小建议把--chunked-prefill-size调小一点比如 1024 或 2048。切得越小显存峰值越低但调度开销会相应增大。如果希望低 TTFT需要观察请求进入系统后是否被长任务阻塞。适当降低--max-running-requests可以减少排队时间但会降低整体吞吐。如果 Prompt 中有大量共享前缀RadixAttention 会自动生效。你不需要额外配置只要保证请求的前缀完全一致即可。4.4 用 Python 客户端验证效果SGLang 提供了兼容 OpenAI 格式的接口验证时可以直接用openai或者requests。import time from openai import OpenAI client OpenAI( base_urlhttp://localhost:30000/v1, api_keyEMPTY, ) prompt 请用 500 字介绍大模型推理中的 Prefill 阶段。 start time.time() response client.chat.completions.create( modelQwen2.5-7B-Instruct, messages[ {role: system, content: 你是一个专业的 AI 技术助手。}, {role: user, content: prompt}, ], streamTrue, max_tokens512, ) first_token_time None for chunk in response: if first_token_time is None and chunk.choices[0].delta.content: first_token_time time.time() ttft first_token_time - start print(fTTFT: {ttft:.3f} 秒) print(首个 Token 内容:, chunk.choices[0].delta.content)这里的TTFT就是从请求发出到收到第一个 Token 的时间包含了网络开销。如果要多轮测试取平均值可以封装成函数连续请求多次去掉最大值和最小值后再计算平均 TTFT。5. vLLM 侧 Prefill 加速配置vLLM 是目前生产环境占有率最高的推理框架之一它的PagedAttention和Prefix Caching在解决 KV Cache 碎片化和重复计算方面非常成熟。5.1 基本启动命令python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b \ --host 0.0.0.0 \ --port 8000 \ --gpu-memory-utilization 0.9 \ --max-model-len 32768 \ --enable-prefix-caching \ --max-num-seqs 325.2 关键参数逐一解释--gpu-memory-utilization控制模型权重 KV Cache 的显存上限。理论上设得越高KV Cache 可以越大长上下文越不容易 OOM。但设太高会导致计算图申请显存失败建议从 0.85 到 0.95 之间尝试。--max-model-len模型支持的最大序列长度。不要盲目设置很大因为这会直接影响 KV Cache 预留空间。比如 32K 上下文比 8K 上下文需要的显存高很多。--enable-prefix-caching开启前缀缓存。vLLM 中的实现是基于哈希匹配的如果请求的前缀 Token 序列完全相同会命中缓存跳过重复 Prefill。--max-num-seqs单次 Batch 中最多并行处理的序列数。调大可以提高吞吐但会增加显存压力也可能让 Prefill 和 Decode 之间的调度更复杂。5.3 --enforce-eager 的影响很多新手在启动 vLLM 时看到 CUDA Graph 相关报错就顺手加--enforce-eager结果发现速度变慢了却不知道原因。--enforce-eager的含义是强制关闭 CUDA Graph 优化让模型以 Eager 模式执行。好处是减少显存占用。避免 CUDA Graph 捕获取证时的兼容性问题比如某些自定义算子不支持。在部分环境尤其是新卡、新驱动上更稳定。但代价是模型执行时每次调用都会有 Kernel Launch 开销单步延迟可能变高。整体吞吐和首 Token 延迟通常不如 CUDA Graph 模式。所以我的建议是生产环境优先保持默认的 CUDA Graph 模式只有遇到兼容性问题或显存实在紧张时才考虑开启--enforce-eager作为兜底方案。如果你只是在本机做功能验证临时开启没问题但不要拿这个配置去压测性能。5.4 量化模型启动示例量化模型可以显著降低显存占用让长上下文留出更多 KV Cache 空间。vLLM 对 AWQ 和 GPTQ 都有内置支持。Qwen2.5-7B 的 AWQ 量化版本启动示例python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct-AWQ \ --quantization awq \ --served-model-name qwen2.5-7b-awq \ --host 0.0.0.0 \ --port 8000 \ --gpu-memory-utilization 0.9 \ --max-model-len 32768 \ --enable-prefix-caching注意量化模型的精度损失需要在业务场景里提前评测。有些任务对量化不敏感但涉及代码、数学、逻辑推理时INT4 的精度损失可能不可接受。6. 精度与量化对 Prefill 的影响6.1 FP16 / BF16 / FP32 怎么选大模型推理中最常用的三种精度精度内存占用速度适用场景FP32最高最慢梯度计算、科学计算推理一般不推荐FP16中等快大多数 NVIDIA GPU 推理数值范围有上限BF16与 FP16 相同与 FP16 相当大模型训练和推理更稳定动态范围更大在 Prefill 阶段BF16 通常比 FP16 更安全因为大模型中间激活值可能出现很大或很小的数值BF16 的动态范围能降低溢出风险。如果你的 GPU 支持 BF16A100、H100、4090 等推荐在推理框架中显式设置dtypebfloat16。6.2 量化对 TTFT 的典型影响量化比如 GPTQ INT4、AWQ的主要收益是降低显存占用而不是直接降低计算延迟。在长上下文场景下量化带来的收益路径是模型权重占用显存更少。KV Cache 可以获得更多显存空间。可以支持更长的上下文或更大的 Batch。减少因显存不足导致的换入换出、调度等待。所以在显存有限的显卡上量化后 TTFT 反而可能下降因为它避免了“计算很快但显存不够”的窘境。但如果显存本身非常充裕量化对绝对延迟的改善有限甚至因为反量化 Kernel 的开销而略微变慢。6.3 实战建议先量显存再定精度我个人的调优顺序是先确定目标上下文长度。计算预估 KV Cache 大小。根据显存反推模型权重允许的体积。再决定是否量化、用什么量化方案。不要为了“极致速度”一上来就 INT4也不要为了“精度无损”死守 FP16。工程上永远是在精度、显存、延迟三者之间找平衡。7. 完整实战长上下文 TTFT 测试接下来我们用一套完整的流程演示如何对比不同配置下的 Prefill 性能。7.1 准备长文本输入长上下文场景需要足够长的输入才能看到 Prefill 差异。测试时可以用一份长文档截取不同长度2K、8K、16K、32K分别测试。def make_long_prompt(question: str, repeat_text: str, length: int) - str: 构造一个长度近似为 length 的 Prompt。 text repeat_text * (length // len(repeat_text) 1) text text[: length - len(question)] return f以下是参考资料\n{text}\n\n问题{question}用一段几百字的背景介绍反复拼接即可。注意构造的文本质量不重要关键是 Token 数足够长。7.2 发送请求并统计 TTFTimport json import time import urllib.request def measure_ttft( base_url: str, model: str, prompt: str, max_tokens: int 64, ) - float: 发送流式请求返回 TTFT秒。 payload { model: model, messages: [{role: user, content: prompt}], stream: True, max_tokens: max_tokens, } req urllib.request.Request( f{base_url}/v1/chat/completions, datajson.dumps(payload).encode(utf-8), headers{Content-Type: application/json}, ) start time.time() first True with urllib.request.urlopen(req, timeout300) as resp: for line in resp: line line.decode(utf-8).strip() if not line: continue if line.startswith(data:): data_str line[5:].strip() if data_str [DONE]: break chunk json.loads(data_str) if first and chunk.get(choices): delta chunk[choices][0].get(delta, {}) if delta.get(content): first False return time.time() - start return time.time() - start这个脚本通过标准库urllib发送流式请求不依赖额外 SDK适合在测试机上直接运行。7.3 对比测试与结果解读建议按照以下轮次执行配置上下文长度期望效果关闭 Prefix Caching8K基线开启 Prefix Caching8K如果前面有相同前缀TTFT 应明显下降开启 Prefix Caching Chunked Prefill32K长上下文显存压力下降TTFT 趋于稳定量化模型 长上下文32K显存占用降低TTFT 可能持平或更好测试时一定要注意每个配置至少跑 5 次取中位数或去掉极值后的平均值。保持模型、Prompt 一致否则数据没有可比性。观察 GPU 利用率确认 Prefill 阶段 GPU 是否真的跑满了。如果利用率只有 50%说明瓶颈可能在 CPU 预处理、Token 化或网络传输上。8. 常见问题与排查思路8.1 常见问题速查表问题现象常见原因解决思路TTFT 高但 GPU 利用率低CPU 预处理慢、Token 化慢、数据加载慢检查数据读取流程开启--trust-remote-code外的预处理缓存增加并发后 TTFT 急剧上升GPU 被 Decode 阶段占满Prefill 排队开启 Chunked Prefill / Mixed Chunk调整max-num-seqs开启 Prefix Caching 没有效果前缀不完全一致或模型 Token 化方式不同确认 System Prompt 完全一致避免在多轮消息中插入时间戳等动态内容长上下文请求 OOMKV Cache 预留不足或max-model-len设置过大降低gpu-memory-utilization之外的最大长度或换量化模型启动时报 CUDA Graph 错误部分自定义算子与 CUDA Graph 不兼容临时用--enforce-eager验证功能再排查算子兼容性Docker 内无法访问 GPU缺少--runtime nvidia或 NVIDIA Container Toolkit 未安装安装 NVIDIA Container Toolkit重启容器8.2 详细排查案例TTFT 高但 GPU 利用率也很高这种情况通常是计算本身确实很大也就是 Attention 的 O(n²) 计算成为瓶颈。需要从算法层优化而不是死磕显存和调度。建议确认模型是否支持稀疏注意力或局部注意力。考虑对 Prompt 做摘要或检索压缩降低实际输入长度。尝试将长文档切分成多个短文档先召回再拼接而不是全部塞进上下文。如果业务允许使用支持长上下文压缩的模型或中间层缓存方案。8.3 详细排查案例启动使用--enforce-eager后速度变慢这是非常常见的“看似合理但结果相反”的例子。Eager 模式会关闭 CUDA Graph而 CUDA Graph 的核心优势在于把一系列 GPU Kernel Launch 提前录制为一张图执行时一次性提交减少 CPU 与 GPU 的同步开销。在短 Prompt、低并发场景下这个优化不明显但在高并发、长上下文的 Prefill 阶段每次迭代都有大量 Kernel 需要启动CUDA Graph 的收益就很可观。如果你的服务是 Eager 模式建议这样排查# 查看 GPU 利用率与 Kernel 启动间隔 nvidia-smi dmon -s pucvmet -d 5如果GPU Utilization持续很低而服务端 CPU 使用率很高说明瓶颈在 Kernel Launch 和 CPU 调度。此时优先考虑恢复 CUDA Graph而不是继续堆 GPU。9. 最佳实践与工程建议9.1 上线前先做压测而不是先看效果很多人部署完模型先拿日常对话测一下觉得“还行”就上线了。但生产环境的长上下文场景极具欺骗性日常对话只有几百 TokenPrefill 只需要几十毫秒一旦用户的文档有几万字TTFT 可能从几十毫秒变成几十秒。所以建议在压测阶段就构造一个与业务场景一致的“最长 Prompt”作为每次升级的回归用例。比如你们每周处理的文档平均长度是多少系统 Prompt 固定有多少 Token用户上传的压缩文本最长多少把这些值写进回归脚本每次改配置后先跑一遍。9.2 尽量工程化共享显存的 KV Cache 规划无论你用 SGLang 还是 vLLM都要理解一个核心显存是你最大的预算KV Cache 是其中最大的动态变量。建议按照下面的公式做预估模型权重显存 参数量 × 每参数字节数 KV Cache 显存 2K 和 V × Layers × Hidden Size × 序列长度 × 精度字节数写个简单的 Python 函数def estimate_kv_cache_memory( layers: int, hidden_size: int, seq_len: int, dtype_bytes: int 2, ) - float: 粗略估算 KV Cache 显存占用单位 GB。 total 2 * layers * hidden_size * seq_len * dtype_bytes return total / (1024 ** 3)以 32 层、hidden_size 4096、32K 序列长度为例mem estimate_kv_cache_memory(layers32, hidden_size4096, seq_len32768) print(mem) # 约 32GB可以看到单请求 32K 上下文的 KV Cache 就可能吃掉 32GB 显存这还没有算模型权重。所以长上下文部署必须精打细算。9.3 监控与日志生产环境建议至少监控以下指标GPU 利用率反映 Prefill 计算是否跑满。显存占用反映 KV Cache 是否接近上限。TTFT 分位值P50 / P95 / P99。请求排队长度反映调度瓶颈。Prefix Cache 命中率反映重复计算是否被有效消除。vLLM 和 SGLang 都提供/metrics接口暴露 Prometheus 格式指标可以直接接入 Grafana。9.4 安全与合规提醒本文所有配置都是围绕正常、合法、已授权的模型部署展开。在实际项目中不要对生产服务做未经授权的压测尤其是外部服务。使用量化、稀疏化等优化手段时要确认模型许可与商业授权范围。涉及用户数据的长文本处理需要遵守数据安全规范不要将敏感数据发送到未经授权的环境中。如果涉及数据库、文件、生产配置变更务必先备份并在测试环境验证。10. 给开发者的下一步建议Prefill 优化不是一个“打开某个开关就完事”的过程它需要你对自己的业务负载有清晰认识先记录现状当前的长上下文典型长度、TTFT 中位数、GPU 利用率。再选优化方向如果 GPU 利用率低先查调度和预处理如果 GPU 利用率高考虑算法层优化。实验对比在同一套测试脚本下分别验证 Prefix Caching、Chunked Prefill、量化、Eager 模式的影响。把测试脚本沉淀成项目例如在仓库里维护一个benchmark_ttft.py每次升级模型、调整参数、更换框架后都跑一遍。另外关于框架选型我的建议是如果你们的业务有大量共享前缀、多轮对话、Agent 场景SGLang 的 RadixAttention 在架构上更有优势。如果团队已经深度使用 vLLM且模型、监控、推理链路都基于 vLLM 构建没有必要为了某一个特性强行切换vLLM 的 Prefix Caching 在大多数静态前缀场景下已经够用。两个框架的接口都兼容 OpenAI 协议切换成本并不高。最稳妥的方式是同时部署两套同一份压测脚本跑一轮用数据说话。最后再说一句关于“性能测试口径”的问题如果你要向团队或上级汇报 Prefill 优化效果请务必写明实验条件包括 GPU 型号、上下文长度、并发数、量化精度、是否命中 Prefix Cache。省略条件谈“47 倍速”可能会误导决策。工程优化最怕的不是性能差而是说不清楚性能差异来自哪里。希望这篇文章能帮你把 Prefill 优化的关键变量理清楚也建议你把文中的测试脚本保存下来作为后续持续调优的基线工具。