长上下文推理正在从“能不能跑”走向“能不能撑住产品体验”。当用户输入一段几万字的 RAG 材料或者 Agent 把十几轮历史记录塞进 prompt前端看到的不是完整回复的速度而是那个不断转圈、迟迟不吐第一个字的加载状态。这个时间在推理侧叫 TTFTTime To First Token首 Token 延迟它直接决定用户对“快不快”的体感。很多人习惯把优化重点放在续写阶段也就是 Decode却忽略了真正卡住长上下文场景的往往是 Prefill。但这里最大的认知误区在于长上下文的瓶颈不是在 Decode而是在 Prefill。理解 Prefill 为什么慢必须回到 Transformer 推理的基本结构。每次请求进来模型要做两件事先把整段 prompt 编码成 KV Cache再基于 Cache 逐步生成新 Token。前一件事就是 Prefill后一件事就是 Decode。当 prompt 从 2K 涨到 128KPrefill 的计算量是线性增长的而 Decode 的单步计算量基本不变。换成大白话说输入一变长瓶颈自动从“串行小步快跑”变成“一次性吃掉一大块计算”。标题里提到的“最高 47 倍速”真正有价值的信息不是“快了多少倍”而是它证明了 Prefill 优化还有巨大的收益空间可以被释放。这篇文章要做的就是把这套被称作“Prefill 加速神器”的优化思路拆开先讲清楚 Prefill 为什么是长上下文推理的瓶颈再梳理目前主流的 Prefill 加速技术路径然后演示如何直接在 SGLang/vLLM 生产部署里落地最后给出一个能实际测量 TTFT 的基准脚本和排查清单。读完你不仅能理解“47 倍”是怎么来的还能在自己的服务里复现、验证、调优。1. 这篇文章真正要解决的问题先看一个很具体的场景。你给一个 Qwen2.5-7B 服务配了 128K 上下文RAG 应用会往 prompt 里注入三份文档加上 few-shot 示例和用户问题总输入长度轻松超过 2 万 Token。用户点击发送后看到的可能是 5 秒、10 秒甚至更久的“空白期”然后才看到第一个字蹦出来。这段时间就是 TTFT而 TTFT 在系统内部约等于 Prefill 时间加上一个 Decode 时间。在短上下文时代这个问题不明显。2K Token 的 Prefill 在主流 GPU 上只要几十毫秒用户感知不到。但到了 32K、128K 甚至更长Prefill 耗时从毫秒级变成秒级它就成了整个交互链路里最刺眼的延迟。更麻烦的是Prefill 是计算密集型操作批处理、显存带宽、算子融合、KV Cache 分配都会影响它的效率。如果服务端用默认配置直接启动长 prompt 过来时可能单个请求就把显存占掉一大块后续请求全部排队。所以这篇博客要帮你解决的核心问题有三个第一理解 Prefill 阶段的计算特性和瓶颈来源知道为什么长上下文时 TTFT 会劣化第二掌握 Prefill 加速的主流技术路径包括分块预填充、并行预填充、前缀缓存、KV Cache 压缩等第三把这些优化真正落到 vLLM、SGLang 的启动配置和线上基准里用可复现的脚本验证效果而不是停留在 PPT 上的“最高 47 倍”。适合读这篇文章的读者不只是做推理框架源码研究的人。只要你正在做 RAG 应用、Agent 记忆、长文档分析、代码仓库问答、或者任何需要把长上下文塞进 prompt 的 LLM 产品Preflight 优化都会直接影响你的线上成本和用户体验。对于还在观望的人这篇文章也能帮你建立一条清晰的判断线索当有人说“长上下文优化”时他到底在优化哪一段计算。2. Prefill 与 Decode为什么长上下文场景先优化 Prefill很多初学者会把 LLM 推理当成一个黑盒输入 prompt输出文本。但实际推理过程可以分成两个阶段它们的计算特性和优化方向完全不同。Prell阶段Prefill做的事情是把整段 prompt 一次性输入模型通过前向传播计算出每个位置的注意力分数和隐藏状态同时把 Key-Value 信息写入 KV Cache。它是一个典型的计算密集型compute-bound阶段。Decode 阶段则是从已缓存的上下文出发每次只生成一个 Token然后把新的 Key-Value 追加到缓存中。它受显存带宽和缓存访问限制属于访存密集型memory-bound阶段。对比维度PrefillDecode输入方式整段 prompt 一次性并行处理每次生成 1 个 Token计算特性计算密集型访存密集型耗时规模随输入长度线性增长随输出长度线性增长主要瓶颈矩阵计算、注意力计算、显存占用KV Cache 读写带宽优化重点并行化、分块、算子融合、前缀共享投机解码、KV 压缩、连续批处理TTFTTime To First Token这个指标需要特别解释一下。不同框架对它的统计方式略有差异但产品意义上的 TTFT是指从请求发出到收到第一个生成 Token 的时间。它包含 Prefill 完整执行一遍的时间加上第一次 Decode 的时间再加上网络传输和调度排队时间。所以如果你听到“TTFT 包含 Prefill 还是 Prefill 加一次 Decoder”的争论更稳妥的理解是TTFT 的绝大部分波动来自 Prefill尤其是在长上下文场景下。为什么长上下文会让 Prefill 成为瓶颈看一个简单估算。假设模型规模是 7B输入长度是 32K Token。Prefill 要做的计算量大约是 32K 个位置的 Transformer 层前向计算这里光是一次注意力层就要计算 32K × 32K 的注意力矩阵。虽然 GPU 有大量并行计算单元但一次性把这么大一块计算压进去会产生很高的显存峰值也容易让计算单元在某些环节空转。相比之下Decode 虽然要串行走完所有输出 Token但每一步的计算量很小适合用连续批处理、KV Cache 等机制把吞吐拉高。另一个容易被忽略的问题是 KV Cache 的显存占用。Prompt 越长KV Cache 越大。比如 Qwen2.5-7B 的 128K 上下文如果全部塞满KV Cache 可能占用几十 GB。如果服务端没有启用 PagedAttention 这类分页管理机制长请求还会导致显存碎片化进一步拖慢 Prefill。这也解释了为什么 Prefill 优化往往不是一个单独的技术决策而是和显存管理、调度策略、批处理大小一起联动。从优化优先级来说如果产品主打长上下文第一步不是去调 Decode 的投机解码参数而是先把 Prefill 压下去。原因很简单Decode 可以靠流式输出给用户一种“已经开始工作”的感觉但 Prefill 阶段用户看到的是空白。同样的 3 秒延迟发生在生成中间和发生在开头用户体感完全不同。3. 长上下文 Prefill 加速的主流技术路径这一节不局限于某一家框架而是先把 Prefill 加速的通用技术路径梳理出来。理解了这些路径再看 SGLang/vLLM 的具体配置就会清楚每个参数到底在调什么。3.1 Chunked Prefill把大计算切碎用流水线躲开显存尖峰最直观的优化思路是既然一次性计算完整段 prompt 会产生显存尖峰那就把它切成多个 chunk逐块计算。这就是 Chunked Prefill典型实现就是 vLLM 的 chunked prefill 功能。它的意义不只是降低显存峰值还在于让 Prefill 和 Decode 可以互相穿插调度。假设你正在处理一个 64K 的 Prefill 请求同时线上还有 10 个正在 Decode 的短请求。如果不做分块这 10 个短请求只能等 64K 的 Prefill 跑完才能继续生成如果分了块每算完一个 chunk调度器可以插入几个 Decode 步骤降低其他请求的排队延迟。这是吞吐和时延之间的一种平衡也是很多生产环境默认开启该功能的原因。需要注意Chunked Prefill 不是没有代价。对于单个纯 Prefill 请求分块后无法完全并行化所有位置的计算可能比一次性计算慢一些。它真正提升的是多请求共存时的整体吞吐和请求间公平性。所以如果你只用单并发离线脚本压测可能感觉不到收益但在线上真实流量模型下收益很明显。3.2 并行 Prefill / Context Parallelism用多卡吃掉长输入如果单张 GPU 算不完长 prompt或者想要线性扩展 Prefill 吞吐可以走并行预填充路线。在 Megatron-LM、DeepSpeed 等框架中这通常叫 Context Parallelism在 vLLM 新版本里也有对应的并行机制。核心思想是把输入序列切成多段分给多张 GPU各自计算对应位置的注意力再通过通信合并结果。可以把几十 K 甚至几百 K 的 prompt 摊到多卡上让 Prefill 延迟从“单卡算到天荒地老”变成“多卡并行协作”。代价是通信开销和实现复杂度。如果你的模型已经用了张量并行TP再叠加上下文并行时要注意两张卡之间的通信带宽是否足够。3.3 Prefix Cache 与自动前缀复用基于 RadixAttention 的缓存思路长上下文里有一个常见特征很多请求共享同一段前缀。比如 RAG 用户每次都把同样的文档库文本放在 prompt 开头Agent 场景每次都会携带系统提示词和历史记忆。如果每次请求都重新计算这些前缀的 KV显然浪费大量算力。SGLang 的核心创新之一 RadixAttention 就是为这个问题设计的。它把 KV Cache 组织成前缀树相同前缀的 KV 可以复用新请求只需要计算差异部分。vLLM 也提供了enable_prefix_caching参数原理类似但实现方式和 SGLang 的树状结构不完全一样。实测中如果请求前缀一致度很高甚至可以把 Prefill 阶段的大部分计算跳过TTFT 直接下降一个数量级这也是“47 倍”这类提速数据最容易出现的场景64K 输入中63.5K 是共享前缀只有 512 Token 是新内容。3.4 投机解码与硬解码绕过 Prefill不是让 Prefill 更精准提到“加速”很容易想到投机解码Speculative Decoding但投机解码主要面向 Decode 阶段用一个小的草稿模型先预测未来几步再让大模型一次验证。它对 Prefill 阶段的直接收益不大。不过 Prefill 阶段并非没有类似思路。比如在长输入中包含大量系统提示词、few-shot 示例时可以提前把这些静态内容的 KV Cache 算好落盘等请求到达时直接加载。这种缓存不仅减少了 Prefill 计算量还缩短了请求排队时间。实践中把常用前缀预计算并持久化到 CPU 内存或磁盘对降本增效非常明显。3.5 KV 压缩与稀疏注意力减少要 Prefill 的量长上下文的“长”不是平均分布的。很多 Token 对最终生成结果贡献很小尤其是重复的模板文本、停用词片段和无关段落。KV 压缩关注的是能否把 Prefill 阶段写入缓存的信息压得更小。具体技术包括低秩压缩、Token Drop、稀疏注意力等。例如某些长文本场景只关心局部窗口和少数全局 Token可以提前裁剪注意力矩阵。这些方法往往需要修改模型结构和训练过程工程成本较高。但有专门针对 Prefill 优化的压缩方案出现时得到的收益通常比单纯优化算子更大。3.6 Kernel 融合与量化把底层算力榨干最后一条路径是把 Prefill 阶段涉及的算子做融合、手工调优或者引入量化。Transformer 里有大量简单算子比如 LayerNorm、Residual、Activation如果不融合每个算子都要读写一遍显存造成额外开销。对应到工程行为上就是使用 CUDA Graph 捕获、启用 FlashAttention-2/3、或者用 FP8/INT8 量化降低显存和计算量。Prell 阶段是计算密集型FP8 的收益一般比 Decode 阶段更显著。但引入量化时要注意精度退化最好先跑评测任务不要在没验证的情况下直接上生产。4. 落地到 vLLM配置、启动与关键参数现在进入正题怎么把这些加速思路在真实生产环境里落地。先从 vLLM 开始。vLLM 是目前最主流的开源推理框架之一优势是工程生态成熟、OpenAI 兼容接口、支持 PagedAttention、Continuous Batching 等适合作为第一套接入方案。4.1 环境准备与安装建议在 Linux 服务器上部署Python 3.10 以上GPU 显存建议至少 24GB如果跑 7B 模型并开启长上下文32GB 和 80GB 显卡更稳妥。vLLM 的安装很简单# 建议在独立虚拟环境中安装 python -m venv vllm-env source vllm-env/bin/activate pip install --upgrade pip pip install vllm安装完成后可以验证版本python -c import vllm; print(vllm.__version__)需要注意vLLM 的版本迭代很快具体参数名在不同版本中可能有变化。写代码和配置文件时建议以你安装版本的官方文档为准。本文演示的是通用思路。4.2 启动 OpenAI 兼容服务用 Qwen2.5-7B-Instruct 作为示例模型启动一个支持长上下文、开启前缀缓存和分块预填充的服务python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --max-model-len 131072 \ --gpu-memory-utilization 0.9 \ --enable-prefix-caching \ --max-num-batched-tokens 8192 \ --max-num-seqs 16 \ --port 8000关键参数解释如下参数作用建议--max-model-len最大上下文长度按模型能力设置7B 模型一般 32K/128K 视量化与显存决定--gpu-memory-utilization预留给缓存和模型的显存比例建议 0.85-0.95不要设到 1.0 以免系统 OOM--enable-prefix-caching开启自动前缀缓存复用相同前置上下文RAG 场景强烈建议开启--max-num-batched-tokens单批次最大 Token 数影响 Prefill chunk 划分显存允许时可增大但过大可能拖慢调度--max-num-seqs同一批最多并发序列数设置过小会降低吞吐过大增加显存压力从 Prefill 优化的角度--max-num-batched-tokens是一个很值得调的参数。它间接控制 chunked prefill 的 chunk 大小当请求的 prompt 很大时vLLM 会把 prompt 切分成不大于该值的小块逐步处理。调大这个值可以让单次 Prefill 计算更充分调小它可以让显存峰值更低同时给 Decode 留出更多调度空间。建议先用默认值跑再根据压测结果调整。启动后日志会打印模型加载完成、服务端口等信息。验证是否可用可以用 curlcurl http://localhost:8000/v1/models如果返回模型列表 JSON说明服务正常。4.3 vLLM 中的 Prefill 相关补充参数除了上述参数vLLM 还支持--disable-chunked-prefill来强制关闭分块预填充也支持--enable-cuda-graph默认开启来捕获 CUDA Graph 降低算子启动开销。如果显存允许还可以用--quantization加载 AWQ/GPTQ 量化模型例如python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct-GPTQ-Int4 \ --quantization gptq \ --max-model-len 32768关于--enforce-eager有一个常见误区。Eager Mode 关闭 CUDA GraphCPU 算子启动开销增大对短请求影响明显但显存占用可能下降。生产环境通常不推荐强制开启除非做算子调试。你可以把它理解成“不用图优化的纯逐算子执行”适合排查问题不适合追求性能。5. 落地到 SGLang命令、HTTP 服务与加速配置SGLang 的全称是 Structured Generation Language它和 vLLM 一样支持 OpenAI 兼容 API但在长上下文和结构化生成上有自己的优势。SGLang 内置了 RadixAttention 前缀树缓存、更激进的算子融合以及 Continuous Batching。如果你对 vLLM 的长上下文 TTFT 不满意SGLang 是值得并行对比的第二套方案。5.1 SGLang 安装与启动安装方式依然推荐虚拟环境python -m venv sglang-env source sglang-env/bin/activate pip install --upgrade pip pip install sglang[all]启动服务的命令因版本不同略有差异常见启动方式如下python -m sglang.launch_server \ --model-path Qwen/Qwen2.5-7B-Instruct \ --port 8001 \ --host 0.0.0.0 \ --context-length 131072 \ --tp 1 \ --mem-fraction-static 0.85这里--context-length指定最大上下文长度--tp是张量并行数--mem-fraction-static控制预留给 KV Cache 的显存比例。如果有多卡可以尝试--tp 2或配合上下文并行参数。SGLang 在长上下文场景下的最大优势是 RadixAttention相同前缀不再重复计算 KV Cache。5.2 理解 RadixAttention 对 Prefill 的影响RadixAttention 是一棵 KV Cache 前缀树树的每个节点对应一段连续的 Token 序列及其 KV Cache。新请求到来时SGLang 会先在树上做最长前缀匹配找到命中的 KV只对未命中部分执行 Prefill。这种设计让 RAG 场景里的重复文档注入、Agent 场景里的历史会话重建都能享受“第二次开始飞快”的收益。在实际部署时为了让 RadixAttention 命中率更高应用层最好保证相同内容放在 prompt 的相同位置不要在中途插入随机 ID、时间戳或用户昵称。否则前缀树会“断掉”失去复用能力。下面会给出一个调度层面的模拟同一套 payload 连续请求后第二次的 TTFT 通常会明显下降。5.3 SGLang 与 vLLM 怎么选两者不是互斥关系而是各有侧重。vLLM 生态更成熟第三方工具、量化后端和监控集成更丰富适合大多数标准部署。SGLang 在长上下文复用、RadixAttention 结构化和多模态场景上往往表现更激进尤其适合 RAG 前缀长度很高、大量重复文本注入的场景。如果你在做预研建议同一台机器上分别启动 vLLM 和 SGLang用同一组 prompt 和并发压力测 TTFT再用第三节末尾的对比表判断哪一套更适合你的模型和流量类型。6. 完整示例搭建一个可测 TTFT 的基准脚本理论说完了接下来写一个能真正测出 Prefill 优化收益的脚本。测试流程分两步第一步启动服务第二步用 OpenAI SDK 发送长 prompt记录 TTFT 和总耗时。6.1 准备测试 Prompt 与服务为了模拟“长上下文 共享前缀”场景可以构造两个文本块一个 20000 Token 的共享前缀一个 1000 Token 的差异后缀。第一次请求完全计算第二次请求得益于前缀缓存TTFT 应该明显下降。Python 生成测试文本# 文件路径prepare_prompt.py import random random.seed(42) def make_text(token_count: int, tag: str) - str: chunks [] for i in range(0, token_count, 20): chunks.append(f{tag}-{i} .join(random.choices(abcdefghij, k10))) return .join(chunks) shared_prefix make_text(2000, PRE) suffix_a make_text(1000, QUERY-A) suffix_b make_text(1000, QUERY-B) with open(prompt_a.txt, w) as f: f.write(shared_prefix \n suffix_a) with open(prompt_b.txt, w) as f: f.write(shared_prefix \n suffix_b)这里没有真正做 Tokenizer 分词只是用固定长度构造近似长度的中文占位文本。实际测试时可以直接使用真实任务的 prompt。6.2 测量 TTFT 的 Python 脚本假设 vLLM 服务跑在 8000 端口SGLang 跑在 8001 端口。下面的脚本用流式接口拿到第一个 token 的时间# 文件路径bench_ttft.py import time from openai import OpenAI def measure_ttft(base_url, model, prompt, max_tokens64): client OpenAI(base_urlbase_url, api_keyEMPTY) t0 time.perf_counter() first_token_at None stream client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperature0.7, max_tokensmax_tokens, streamTrue, ) for chunk in stream: if chunk.choices and chunk.choices[0].delta.content: first_token_at time.perf_counter() break if first_token_at is None: return None, None ttft first_token_at - t0 # 继续消费流测量总耗时 for _ in stream: pass total time.perf_counter() - t0 return ttft, total if __name__ __main__: with open(prompt_a.txt, r) as f: prompt_a f.read() with open(prompt_b.txt, r) as f: prompt_b f.read() ttft_a, total_a measure_ttft(http://localhost:8000/v1, Qwen/Qwen2.5-7B-Instruct, prompt_a) print(fPrompt A: TTFT{ttft_a*1000:.2f} ms, Total{total_a:.2f}s) # 第二次请求共享前缀测前缀缓存命中后的效果 ttft_b, total_b measure_ttft(http://localhost:8000/v1, Qwen/Qwen2.5-7B-Instruct, prompt_a) print(fPrompt A (again): TTFT{ttft_b*1000:.2f} ms, Total{total_b:.2f}s)运行方式python prepare_prompt.py python bench_ttft.py预期结果是第一次请求的 TTFT 主要由 Prefill 决定第二次请求如果前缀缓存生效TTFT 可能会下降到第一次的几十分之一。这个对比就是“47 倍”类优化的最小可复现单元。6.3 多长度和多并发压测只测一个长度不够。推荐把 prompt 分成 8K、16K、32K、64K 四档每档测 10 次取中位数再在同一 prompt 下增加并发。并发压测时可以用 Python 的concurrent.futures或直接使用vllm bench工具。如果你只想快速验证可以写# vLLM 官方压测工具示例具体参数以版本为准 python -m vllm.bench.benchmark_serving \ --backend vllm \ --model Qwen/Qwen2.5-7B-Instruct \ --endpoint /v1/chat/completions \ --input-len 16384 \ --output-len 256 \ --num-prompts 20 \ --request-rate 2压测报告的指标要看三个TTFT、TPOT每个输出 Token 的时间和吞吐量。TTFT 低但吞吐低说明 Prefill 优化可能有损TTFT 高但吞吐高说明调度策略还没调整到位。理想情况是长 prompt 场景下 TTFT 中位数明显下降同时吞吐不明显回落。7. 常见问题与排查思路这里整理了生产环境中最容易踩的坑每个问题都有对应的排查路径。问题现象可能原因排查方式解决方案启动即报 CUDA OOM模型本身显存占用超过 GPU 显存查看nvidia-smi实际显存占用检查--gpu-memory-utilization换更大显存卡、启用量化、降低--max-model-len长 prompt 请求一直卡住不输出Prefill 超时或 chunked prefill 没生效查看服务端日志中 prefill 耗时统计确认是否启用了 chunked prefill增大--max-num-batched-tokens或升级到支持长上下文的模型第二次同前缀请求 TTFT 没下降前缀缓存未命中或未开启检查--enable-prefix-caching是否开启对比请求内容是否完全一致开启前缀缓存保证 prompt 中相同内容位置固定开启 chunked prefill 后短请求变慢分块调度引入了额外排队同时观察短请求的 TTFT 和长请求的 TTFT调大 chunk 大小或在业务层把长短请求分流到不同副本并发 10 个 64K 请求时显存溢出KV Cache 分配不足缓存池被占满查看监控面板的 KV Cache 使用率降低并发数、调整显存预留比例、使用更小的量化模型量化后的长上下文效果变差INT4/FP8 对注意力精度有影响跑评测集对比原始模型输出必要时仅在 Prefill 阶段使用量化Decode 保持更高精度排查时记住一个原则先确认瓶颈是 Prefill 还是 Decode。方法很简单在日志里看请求的 TTFT 和 TPOT。如果 TTFT 占比超过 70%问题出在 Prefill如果 TTFT 很低但生成最终结果很慢问题出在 Decode。不要盲目调参。8. 生产环境最佳实践与工程建议8.1 服务层预热、超时与双副本灰度模型加载后建议先发几个短请求做预热把 CUDA Kernel 和显存页激活避免第一个真实用户承受额外开销。在服务前面加超时控制长 prompt 请求建议设置“连接超时 首字超时”双阈值。上线时可以做 A/B 对比旧服务用 vLLM 默认配置新服务开启前缀缓存和 chunked prefill用线上流量的 1% 或者影子流量跑几天观察 TTFT、TPOT 和错误率。8.2 应用层前缀设计决定缓存命中率前缀缓存再强也怕应用层故意制造“每次都不一样”的 prompt。建议把 system prompt、few-shot 示例、静态文档放在最前面且保持顺序固定把用户 ID、时间、随机数放在后面。如果业务必须塞入动态信息尽量放在 prompt 尾部降低前缀树被断开的概率。对 Agent 场景历史消息可以按固定模板拼接不要把每轮的响应文本顺序打乱。8.3 监控与压测不要只看平均值TTFT 的平均值会掩盖长尾问题。在生产监控里除了平均值还要看 P50、P95、P99 三个分位数。P99 TTFT 如果比 P50 高一个数量级说明系统里有大 prompt 抖动或者 KV Cache 命中率不稳定。建议每上一个大版本就做一轮回归压测保留测试脚本和结果方便对比。8.4 安全性不要裸奔部署大模型推理服务本质是一个可以被外部请求打满计算资源的服务。不要把它直接暴露在公网必须放在内网网关后面用鉴权限流保护。对单用户的最大上下文长度、最大输出长度、每秒请求数做限制。即使只是内部服务也建议加 API Key 和调用配额防止某个同学误写一个 while 循环把你的 GPU 打满。8.5 版本与回滚配置先行vLLM、SGLang、模型权重都有版本兼容问题。生产环境不要随手 upgrade。把“框架版本 启动参数 模型路径 压测结果”记录成一份部署清单。升级前先在一台影子机器上跑通如果异常快速回滚到上一份配置。对大模型服务来说没有比一次莫名其妙的框架升级更惊险的线上事件。8.6 降本思路从 Prefill 优化到缓存服务化Prefill 优化不只是调一个参数。如果线上常见请求的前缀非常固化可以考虑做一个 KV Cache 缓存服务提前计算热门前缀的 KV请求到达时直接挂载。这类方案实现成本高但省下的算力非常可观。先用 SGLang/vLLM 自带的缓存机制在一个产品流量下观察命中率如果命中率长期超过 60%再做更细粒度的缓存服务化。9. 总结与后续学习方向核心结论可以用一句话概括长上下文时代TTFT 是被 Prefill 主导的而 Prefill 优化是一个“技术栈组合拳”不是某一个参数开了就能拿到 47 倍收益。真正有效的动作是把长 prompt 切碎Chunked Prefill、把重复前缀缓存起来Prefix Cache / RadixAttention、在需要时用多卡并行吃掉超大输入Context Parallelism再叠加算子融合和量化把这些策略真正压到 GPU 上。47 倍这种数字最可能来自高度共享前缀的验证场景但它确实说明了一个事实Prefill 阶段被大多数人低估了优化它能够换来远超预期的 TTFT 改进。下一步建议你立刻做三件事。第一用文中的 benchmark 脚本对你当前服务的 TTFT 做一次基线测量记录不同 prompt 长度下的 P50 和 P95。第二在测试环境开启 chunked prefill 和 prefix caching把同样的脚本重跑一遍看变化在哪一段。第三先别把“最高 47 倍”当 KPI而是给自己设定一个真实指标比如把 32K prompt 的 P95 TTFT 降低到当前值的 50% 以内同时保证 P95 TPOT 不劣化超过 10%。跑通这个闭环后你就可以自信地对团队说长上下文推理的瓶颈我们已经找到它并压住它了。如果想继续深入值得顺着三条线索往下走一是 vLLM 的 PagedAttention 调度源码看 chunked prefill 和分页缓存的协作方式二是 SGLang 的 RadixAttention 前缀树实现理解缓存命中为什么能在极端场景下创造数量级收益三是投机解码、稀疏注意力和 KV 压缩它们是 Decode 和更远未来的优化重点。无论哪一条都需要动手跑实验而今天这套测量 TTFT 的脚本就是你后续所有实验最可靠的地基。