1. 为什么多轮对话的 TTFT 总是卡在同一个地方如果你正在做 LLM 推理服务大概率遇到过这种场景客服机器人、RAG 问答、Agent 工具调用每个请求都带着一段几乎一模一样的 system prompt几百到几千 token 不等。用户只问了一句话但服务端每次都要把那段长前缀重新算一遍 KV。结果就是首 Token 延迟TTFT居高不下GPU 算力被大量重复的 Prefill 吃掉。这就是 Prefix Caching 要解决的问题。它做的事情很朴素把已经算过的前缀 KV Cache 按 Block 粒度缓存下来后续请求如果前缀相同直接复用跳过重复的 Prefill 计算。vLLM 从 0.4 版本开始默认开启这个能力但很多人并不知道它到底省了多少、命中率怎么看、什么场景下收益最大。这篇文章我会用一套可复现的实验来回答三个问题Prefix Caching 能把 TTFT 降多少命中率怎么从/metrics读出来共享前缀越长收益是不是线性增长、上限在哪同时我会把推理服务挂到 TaoToken 的统一 Key/API 通道上这样你既能在本地 vLLM 上做实验也能用同一套 Key 去对比云端模型的 TTFT 表现不用来回切换账号和 Base URL。适合谁看正在用 vLLM 部署推理服务、被 TTFT 困扰、想搞清楚 KV Cache 复用机制的工程师。读完你能拿到完整的启动参数、测试脚本和排障清单直接在自己机器上跑出对比数据。2. TaoToken 统一 Key 与 vLLM 服务的前置准备在开始实验之前先把两件事理清楚本地 vLLM 服务怎么起以及 TaoToken 的 Key 怎么配。这两件事分开做互不干扰但用同一套调用习惯后面切换会很顺。2.1 为什么要在实验里引入 TaoToken做 Prefix Caching 实验核心是本地 vLLM 的 KV Cache 行为这一点必须在本机验证。但实验之外你往往还需要一个稳定的云端通道来做对照比如验证同一段 prompt 在云端模型上的 TTFT 基线或者把本地跑通的请求格式直接复用到线上。TaoToken 提供的是 OpenAI 兼容的统一 API 通道一个 Key 可以访问多个模型Base URL 固定省去了每个模型单独配 Key 的麻烦。它的 API 地址是https://taotoken.net/api注意这个地址不带任何查询参数直接作为base_url使用。模型对话入口在https://taotoken.net/modelsAPI Key 管理在https://taotoken.net/api-keys接入文档在https://taotoken.net/doc。如果你后面要做长期编码或 Agent 类任务可以看 Coding Plan 页面https://taotoken.net/coding-plan。2.2 本地 vLLM 环境确认实验用 Qwen2.5-7B-Instruct显存占用在 BF16 下约 14GBRTX 3090 24GB 可以跑。先确认 vLLM 版本Prefix Caching 的默认行为和 metrics 名称在不同版本间有差异pip show vllm | grep Version # 建议 0.6.x 及以上metrics 中 prefix_cache_queries_total 字段稳定如果你的 vLLM 低于 0.5/metrics里的 prefix cache 计数器可能叫别的名字建议先升级。升级命令pip install -U vllm模型路径按你自己的实际位置改我这边放在/root/autodl-tmp/models/qwen2.5-7b-instruct。2.3 TaoToken Key 的环境变量配置把 Key 写进环境变量避免硬编码到脚本里。Linux/macOSexport TAOTOKEN_API_KEYsk-你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/apiWindows PowerShell$env:TAOTOKEN_API_KEYsk-你的Key $env:TAOTOKEN_BASE_URLhttps://taotoken.net/api验证 Key 是否可用用一条最简单的请求curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4o-mini, messages: [{role: user, content: ping}], max_tokens: 5 }返回里有choices字段就说明通道正常。这一步只是确认 Key 有效真正的 Prefix Caching 实验还是在本地 vLLM 上做。2.4 本地 vLLM 启动参数开启 Prefix CachingvLLM 默认行为显式写出来更清楚vllm serve /root/autodl-tmp/models/qwen2.5-7b-instruct \ --served-model-name qwen2.5-7b \ --gpu-memory-utilization 0.85 \ --max-model-len 4096 \ --enable-prefix-caching关闭 Prefix Caching 做对照组vllm serve /root/autodl-tmp/models/qwen2.5-7b-instruct \ --served-model-name qwen2.5-7b \ --gpu-memory-utilization 0.85 \ --max-model-len 4096 \ --no-enable-prefix-caching两个参数互斥--enable-prefix-caching和--no-enable-prefix-caching只能出现一个。--gpu-memory-utilization 0.85给 KV Cache 留出足够空间Prefix Cache 本身也占显存利用率设太低会导致缓存池太小、命中率上不去。启动后看到Application startup complete就可以发请求了。服务默认监听http://localhost:8000。3. Prefix Caching 开关与 TTFT 对比脚本的可复制配置这一节给出完整的配置文件片段和测试脚本你可以直接复制运行。核心是把「开关对比」和「前缀长度梯度」两个实验的配置都固化下来。3.1 vLLM 服务配置片段如果你用 YAML 管理启动参数可以写成这样路径和参数名与 vLLM CLI 一致# vllm_config.yaml model: /root/autodl-tmp/models/qwen2.5-7b-instruct served_model_name: qwen2.5-7b gpu_memory_utilization: 0.85 max_model_len: 4096 enable_prefix_caching: true对应的启动命令vllm serve --config vllm_config.yaml关闭时把enable_prefix_caching改成false即可不用改其他参数保证变量唯一。3.2 测试脚本的配置区脚本里把 Base URL、模型名、system prompt 构造方式集中放在顶部方便改# prefix_cache_test.py import requests import time VLLM_BASE_URL http://localhost:8000 MODEL_NAME qwen2.5-7b # TaoToken 通道用于云端对照可选 TAOTOKEN_BASE_URL https://taotoken.net/api TAOTOKEN_MODEL gpt-4o-mini SYSTEM_PROMPT 你是一个专业的AI助手。你需要遵循以下规则 1. 回答必须准确、客观、有依据 2. 如果不确定要明确说明 3. 回答要结构化使用适当的标题和段落 4. 对于技术问题要给出代码示例 5. 对于历史问题要注明时间和来源 * 20 # 重复 20 次约 1488 tokens* 20这个重复次数是控制前缀长度的关键后面实验二会用它做梯度。3.3 单请求函数与 metrics 读取def send_request(question, base_urlVLLM_BASE_URL, modelMODEL_NAME): start time.time() r requests.post( f{base_url}/v1/chat/completions, json{ model: model, messages: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: question} ], max_tokens: 64, temperature: 0 } ) elapsed time.time() - start data r.json() return elapsed * 1000, data[usage][prompt_tokens] def get_prefix_cache_stats(): r requests.get(f{VLLM_BASE_URL}/metrics) queries, hits 0.0, 0.0 for line in r.text.split(\n): if line.startswith(vllm:prefix_cache_queries_total{): queries float(line.split(} )[1]) if line.startswith(vllm:prefix_cache_hits_total{): hits float(line.split(} )[1]) return queries, hits注意line.split(} )[1]这个解析方式依赖 metrics 输出格式如果你的 vLLM 版本输出带 label可能需要调整。先手动curl http://localhost:8000/metrics | grep prefix_cache看一眼实际格式。3.4 完整对比流程questions [ 秦始皇统一六国的过程是怎样的, 汉武帝的主要功绩有哪些, 唐朝的开元盛世是怎么回事, 宋朝的经济发展有哪些特点, 明朝的海禁政策是什么, 清朝的洋务运动取得了哪些成果, 辛亥革命的意义是什么, 五四运动的背景和影响, ] init_queries, init_hits get_prefix_cache_stats() for i, q in enumerate(questions): elapsed, tokens send_request(q) print(f{i1:4} {q[:18]:20} {elapsed:10.1f} ms {tokens:6} tokens) final_queries, final_hits get_prefix_cache_stats() total_new_queries final_queries - init_queries total_new_hits final_hits - init_hits hit_rate total_new_hits / total_new_queries * 100 if total_new_queries 0 else 0 print(f\n命中率: {hit_rate:.1f}%节省 {total_new_hits:.0f} tokens 的 KV 计算)先读一次初始计数跑完再读一次取差值这样能排除服务启动后历史请求的干扰。这个细节很多人会漏导致命中率算出来偏大。3.5 前缀长度梯度实验配置实验二用重复次数控制前缀长度配置区改成BASE_UNIT ( 你是一个专业的AI助手。你需要遵循以下规则\n 1. 回答必须准确、客观、有依据。\n 2. 如果不确定要明确说明不确定的原因。\n 3. 回答要结构化使用适当的标题和段落。\n 4. 对于技术问题要给出可运行的代码示例。\n 5. 对于历史问题要注明具体时间节点和史料来源。\n ) TOKENS_PER_UNIT 64 TARGET_PREFIX_TOKENS [256, 512, 1024, 2048, 3072] USER_QUESTION 请简要介绍一下汉武帝的主要历史功绩。 REPEAT_PER_LENGTH 5 def build_system_prompt(target_tokens): repeat max(1, round(target_tokens / TOKENS_PER_UNIT)) return BASE_UNIT * repeatmax_tokens1是关键把 Decode 开销压到最小让 TTFT 主要反映 Prefill 时间。开启 cache 时每种长度先发一次冷启动请求建缓存再连发 5 次取均值。4. 验证请求与 TTFT 实测结果配置就绪后跑两组实验看实际数字。4.1 开关对比结果开启 Prefix Caching 时8 个请求的 TTFT 稳定在 1269~1300ms命中率 99.2%节省约 11904 tokens 的 KV 计算。关闭时TTFT 在 1556~1666ms 之间命中率 0%。去掉第一个请求有 CUDA kernel 预热开销对比第 2~8 次平均 TTFT配置第 2~8 次平均 TTFT差值降幅关闭 Prefix Cache1562 ms——开启 Prefix Cache1274 ms-288 ms-18.5%为什么只降了 18.5%而不是接近 99%因为 TTFT 不只是 PrefillTTFT 排队等待 Prefill Decode 第 1 token关闭时1562ms 排队 1500 tokens Prefill decode 开启时1274ms 排队 12 tokens Prefill decode差值 288ms 就是 1488 tokens 的 Prefill 时间。剩下的约 1274ms 是排队和 decode 第一个 token 的固定开销Prefix Caching 优化不了这部分。这个结论很重要Prefix Caching 的收益有上限它只砍 Prefill。4.2 前缀长度梯度结果Prompt Tokens关闭 Cache TTFT (ms)开启 Cache TTFT (ms)节省 (ms)降幅353111.436.774.767.1%681168.743.0125.774.5%1337279.445.1234.383.9%2649574.056.1517.990.2%3961852.762.8789.992.6%关闭 Cache 时TTFT 从 353 tokens 的 111ms 线性增长到 3961 tokens 的 853ms拟合斜率约 207.6 ms/千 tokens。开启后TTFT 几乎不随前缀长度变化始终在 37~63ms 低位拟合斜率仅 6.9 ms/千 tokens。线性拟合TTFT_off 207.6 × L 38.1 (ms) # L 单位千 tokens TTFT_on 6.9 × L 34.3 (ms)斜率下降幅度1 - 6.9/207.6 96.7%。两条拟合线截距接近38.1 vs 34.3说明那部分固定开销在两种配置下基本相同。4.3 用 TaoToken 通道做云端对照本地实验跑完后可以用同一段 system prompt 通过 TaoToken 发一次请求对比云端模型的 TTFT 基线。脚本里加一个函数def send_request_taotoken(question): import os start time.time() r requests.post( f{os.environ[TAOTOKEN_BASE_URL]}/v1/chat/completions, headers{Authorization: fBearer {os.environ[TAOTOKEN_API_KEY]}}, json{ model: TAOTOKEN_MODEL, messages: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: question} ], max_tokens: 64, temperature: 0 } ) elapsed time.time() - start return elapsed * 1000, r.json()[usage][prompt_tokens]这样你手里就有两组数据本地 vLLM 开/关 Prefix Caching 的 TTFT以及云端通道的 TTFT。云端模型的 Prefix Caching 行为由服务方控制你观察到的 TTFT 更多反映网络和排队但作为对照基线足够。5. 本篇常见报错与排查清单实验过程中容易踩的坑集中在这几类对照真实报错逐个排查。5.1 401 Unauthorized用 TaoToken 通道时最常见。报错长这样{error: {message: Invalid API key, type: invalid_request_error}}排查顺序先确认TAOTOKEN_API_KEY环境变量在当前 shell 里真的存在echo $TAOTOKEN_API_KEY看有没有值。如果是在 Python 脚本里读os.environ注意脚本运行的环境和 export 的 shell 是不是同一个。Key 本身去https://taotoken.net/api-keys重新生成一个再试。Base URL 必须是https://taotoken.net/api不要多加/v1后缀SDK 会自己拼。5.2 local proxy failed / connection refused本地 vLLM 没起来或者端口不对。报错requests.exceptions.ConnectionError: HTTPConnectionPool(hostlocalhost, port8000): Max retries exceeded先curl http://localhost:8000/health看服务是否活着。如果 vLLM 启动日志停在Loading model weights说明模型还在加载等Application startup complete再发请求。如果端口被占换--port 8001并同步改脚本里的VLLM_BASE_URL。5.3 reading choices 报错请求返回的 JSON 里没有choices字段通常是请求体格式问题。报错KeyError: choices检查messages里 role 是不是system/user/assistant三选一max_tokens是不是正整数。如果服务端返回了错误信息先print(r.text)看原始响应别直接取r.json()[choices]。5.4 OAuth / 认证相关报错如果你用的是某些需要 OAuth 的客户端比如 Claude Code 类工具报错可能长这样OAuth token expired or invalid这类工具接入时Base URL、Key、Model ID 三件套要写全。以 Claude Code 为例配置文件里需要同时指定{ base_url: https://taotoken.net/api, api_key: sk-你的Key, model: claude-3-5-sonnet-20241022 }三个字段缺一不可只填 Key 不填 Base URL 会走到默认端点报认证失败。Cline 的 MCP 配置、Codex 的auth.json同理Base URL Key Model ID 都要写全。Codex 的auth.json示例{ api_key: sk-你的Key, base_url: https://taotoken.net/api, model: gpt-4o }5.5 命中率始终为 0Prefix Caching 开了但命中率上不去常见原因有三个。一是 system prompt 每次请求都变了比如带了时间戳或随机 IDhash 对不上。二是--gpu-memory-utilization设太低缓存池太小前缀还没被复用就被淘汰了。三是请求间隔太长LRU 把旧前缀清掉了。排查方法先固定 system prompt 连发 5 次看/metrics里prefix_cache_hits_total有没有增长。如果还是 0把--gpu-memory-utilization提到 0.9 再试。5.6 metrics 字段名对不上不同 vLLM 版本 metrics 名称有差异。先手动确认curl -s http://localhost:8000/metrics | grep -i prefix如果看到的是vllm:gpu_prefix_cache_hit_rate之类的 gauge 而不是 counter脚本里的解析逻辑要相应调整。以实际输出为准别照搬。6. 把实验跑通之后下一步怎么用Prefix Caching 的收益规律很清晰共享前缀越长、复用次数越多TTFT 降幅越大。在 4000 tokens 前缀下能到 92.6%但固定开销那约 35ms 的截距是砍不掉的。所以如果你的场景是短前缀、低复用别指望它带来质变如果是 RAG、Agent、长 system prompt它几乎是免费的性能提升vLLM 默认开启是有道理的。实操上我建议你把本文的脚本存下来改一改 system prompt 构造方式套到你自己的业务 prompt 上跑一遍。重点看两个数prefix_cache_hits_total的增长曲线以及开启前后的 TTFT 差值。这两个数能直接告诉你当前业务的 Prefix Caching 收益空间有多大。如果你需要把本地验证过的请求格式复用到线上或者想用同一个 Key 对比多个模型的 TTFTTaoToken 的 API 通道可以直接用Base URL 是https://taotoken.net/apiKey 在https://taotoken.net/api-keys管理接入细节看https://taotoken.net/doc。长期做编码或 Agent 任务的话Coding Plan 页面https://taotoken.net/coding-plan有对应的方案说明。下一篇我会做投机采样的实验验证小模型草稿 大模型验证能不能在零精度损失的前提下把 TPOT 降下来。如果你跟着本文跑出了自己的数据欢迎在评论区贴出来对比。