1. 从一次「首字卡三秒」的线上问题说起如果你在本地部署过 Qwen、LLaMA 这类解码器自回归模型大概率遇到过这种割裂体验模型权重加载正常单条短 Prompt 回复飞快可一旦把 RAG 检索回来的长文档塞进上下文首字就要等两三秒后面吐字却还算流畅。这个现象背后不是模型「变笨」了而是推理链路的两个阶段——Prefill 和 Decode——在资源特征上完全不同。大模型生成文本的规则是逐 Token 自回归每生成一个新 Token都要基于完整历史序列做注意力计算。如果不做任何缓存每步都对全部历史 Token 重算 K、V注意力复杂度是 O(n²)上下文越长计算量越爆炸。KV Cache 就是为解决这个重复计算而生的历史 Token 的 Key、Value 向量一旦算完就不再变化只有当前最新 Token 的 Query 是全新的于是把历史 K、V 缓存进显存后续直接读取即可解码阶段复杂度降到 O(n)。但缓存不是免费的。序列越长、并发越高KV Cache 占用的显存越夸张甚至会超过模型权重本身。这就引出了 Prefill预填充与 Decode解码的分工Prefill 一次性并行处理完整 Prompt构建 KV Cache 并产出第一个 Token是算力密集型直接决定 TTFT首 Token 延迟Decode 每次只算一个新 Token复用缓存并追加是显存带宽密集型决定 TPOT单 Token 生成耗时。而这一切最终都落到 GPU 算子上执行vLLM 则通过 PagedAttention 把 KV Cache 切成固定大小的 Block 做分页管理消除显存碎片、提升并发吞吐。这篇内容面向本地部署与性能调优场景交付可复制的 vLLM 启动配置、KV Cache 显存参数、TTFT 观测脚本以及 Prefill/Decode 阶段耗时对比的验证动作帮你把「首字慢」定位到具体环节。2. 前置准备模型权重、环境与 TaoToken 接入在动手调参之前先把运行环境和模型入口理顺。本地推理需要三样东西一块显存够用的 GPU、一份模型权重、一个稳定的模型服务入口。前两者靠你自己的机器第三者可以用 TaoToken 来统一管理模型调用与密钥。TaoToken 在这里的角色是模型服务与密钥管理入口官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址为 https://taotoken.net/api 。你需要先在控制台创建 API Key再把它注入到推理服务的环境变量里。对于本地 vLLM 部署通常有两种接法一是 vLLM 直接加载本地权重TaoToken 只用于对照测试云端模型二是把 vLLM 暴露成 OpenAI 兼容接口再用统一 Key 做网关转发。创建密钥的入口在控制台的 API Keys 页面建议按项目维度拆分 Key方便后续做用量归因。如果你后续要做长期编码或 Agent 类任务可以关注 Coding Plan它更适合高频、长会话的调用场景单纯验证模型输出是否正常用模型对话页面就够。环境侧建议固定版本避免算子行为漂移。下面这套组合在实测中比较稳组件建议版本说明CUDA12.1 及以上决定 FlashAttention 等算子可用性PyTorch2.1与 vLLM 编译版本匹配vLLM0.4.x 及以上支持 PagedAttention 与分页 KV CachePython3.10兼容性最好注意vLLM 对 CUDA 与 PyTorch 版本敏感装错版本会出现算子找不到或编译失败建议用官方推荐的 wheel 组合不要随意混装。3. 可复制的 vLLM 启动配置与 KV Cache 显存参数这一节是全文的核心操作区。vLLM 的启动参数里和 KV Cache、Prefill/Decode 直接相关的有几个关键项理解它们才能调得动性能。先看一份可直接复制的启动命令以 Qwen2.5-7B-Instruct 为例python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-7B-Instruct \ --served-model-name qwen-local \ --host 0.0.0.0 \ --port 8000 \ --dtype float16 \ --gpu-memory-utilization 0.90 \ --max-model-len 8192 \ --max-num-seqs 32 \ --max-num-batched-tokens 4096 \ --block-size 16 \ --enable-prefix-caching \ --swap-space 8 \ --disable-log-requests逐项拆解这些参数和 KV Cache 的关系--gpu-memory-utilization 0.90控制 vLLM 可用的显存比例。它先扣掉模型权重占用剩下的显存才用来放 KV Cache 和中间激活。这个值调太高容易 OOM调太低则 KV Cache 空间不足、并发上不去。0.85 到 0.92 是常见区间。--max-model-len 8192是单条序列的最大长度直接决定单请求 KV Cache 的上限。KV Cache 显存占用大致正比于「层数 × 序列长度 × KV 头数 × 头维度 × 精度字节 × 2」。以 7B 模型为例FP16 下每 Token 的 KV 占用约在几十 KB 量级8192 长度单条就要几百 MB并发 32 条就是十几 GB这就是为什么长上下文和并发不能同时拉满。--block-size 16是 PagedAttention 的物理块大小KV Cache 被切成固定大小的 Block 存储通过 Block Table 映射逻辑与物理地址。块太小管理开销大块太大碎片浪费多16 是较通用的折中值。--max-num-seqs 32限制同时调度的序列数--max-num-batched-tokens 4096限制单批处理的 Token 总量。这两个参数共同决定 Prefill 批的大小批越大吞吐越高但单次 Prefill 耗时变长TTFT 会上升。--enable-prefix-caching开启前缀缓存对 RAG 场景特别有用——多轮对话或共享系统提示词时相同前缀的 KV Cache 可以复用直接压低 Prefill 计算量从而降低 TTFT。--swap-space 8是 CPU 侧交换空间当 GPU 显存里的 KV Cache 不够时可以把部分 Block 换出到内存避免直接拒绝请求代价是延迟上升。启动后日志里会打印一行关键信息形如GPU KV cache size: 123,456 tokens Maximum concurrency for 8192 tokens per request: 15.07x这行GPU KV cache size就是当前配置下 KV Cache 能容纳的总 Token 数除以max-model-len就是理论最大并发。调参时盯着这个数字比盲目试错高效得多。4. 验证请求TTFT 观测脚本与 Prefill/Decode 耗时对比配置跑起来后必须用数据验证而不是凭感觉。下面这个脚本用流式请求测量 TTFT 和 TPOT直接对接 vLLM 的 OpenAI 兼容接口。import time import json import requests API_BASE http://127.0.0.1:8000/v1 API_KEY your-local-key MODEL qwen-local def measure_ttft(prompt, max_tokens128): url f{API_BASE}/chat/completions headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } payload { model: MODEL, messages: [{role: user, content: prompt}], max_tokens: max_tokens, stream: True, } start time.perf_counter() first_token_time None token_count 0 with requests.post(url, headersheaders, jsonpayload, streamTrue) as resp: for line in resp.iter_lines(): if not line: continue line line.decode(utf-8).strip() if not line.startswith(data:): continue data line[5:].strip() if data [DONE]: break chunk json.loads(data) delta chunk[choices][0][delta] if delta.get(content): if first_token_time is None: first_token_time time.perf_counter() token_count 1 end time.perf_counter() ttft (first_token_time - start) * 1000 if first_token_time else None tpot ((end - first_token_time) / max(token_count - 1, 1)) * 1000 if first_token_time else None return ttft, tpot, token_count if __name__ __main__: short_prompt 用一句话解释什么是 KV Cache。 long_prompt 请阅读以下内容并总结要点 大模型推理优化涉及缓存、算子与调度。 * 200 for name, p in [(短 Prompt, short_prompt), (长 Prompt, long_prompt)]: ttft, tpot, n measure_ttft(p) print(f{name}: TTFT{ttft:.1f}ms, TPOT{tpot:.1f}ms, tokens{n})跑出来的结果会呈现明显规律短 Prompt 的 TTFT 通常在一两百毫秒长 Prompt 的 TTFT 会随输入长度线性甚至超线性上升因为 Prefill 是算力密集、复杂度接近 O(n²)。而 TPOT 在两个场景下差异不大因为 Decode 每步只算一个 Token瓶颈在显存带宽而非输入长度。把两组数据放进表格对照Prefill 与 Decode 的特征差异一目了然场景TTFTTPOT主导阶段瓶颈类型短 Prompt低稳定Prefill 轻、Decode 主导显存带宽长 Prompt显著升高基本不变Prefill 主导GPU 算力如果长 Prompt 的 TTFT 高得离谱优先检查是不是没开--enable-prefix-caching或者--max-num-batched-tokens设得过大导致单批 Prefill 排队。如果 TPOT 偏高则要看 KV Cache 是否频繁换出、--block-size是否合理、显存带宽是否被并发挤占。5. 本篇常见错排查调优过程中踩的坑大多集中在几类这里按现象归类。第一类是启动即 OOM。常见原因是--gpu-memory-utilization设得过高或--max-model-len与--max-num-seqs组合超出显存。排查方法是先把max-model-len降到 4096、max-num-seqs降到 8确认能起来后再逐步加观察日志里的GPU KV cache size变化。第二类是 TTFT 忽高忽低。这通常是请求排队导致的Prefill 批太大时后到的请求要等前一批算完。可以适当降低--max-num-batched-tokens让 Prefill 更细粒度地调度牺牲一点吞吐换更稳的首字延迟。第三类是 Decode 阶段越来越慢。长序列下 KV Cache 不断增长如果显存不够触发 swapTPOT 会明显抖动。检查--swap-space是否被频繁使用必要时降低并发或缩短上下文。第四类是算子相关报错比如 FlashAttention 不可用、reshape_and_cache找不到。这类基本是版本不匹配确认 CUDA、PyTorch、vLLM 三者版本对应不要用 CPU 版 PyTorch 跑 GPU 推理。第五类是把 TTFT 和 TPOT 混为一谈。有人看到首字慢就去调 Decode 参数方向完全错了。记住TTFT 归 Prefill 管TPOT 归 Decode 管先定位阶段再动手。提示排查时优先看 vLLM 启动日志和运行时的 metrics 输出里面会区分 Prefill 与 Decode 的耗时统计比只看端到端延迟有用得多。6. 把验证动作固化成日常调优流程推理调优不是一次性动作而是一套可重复的流程改配置、起服务、跑 TTFT 脚本、看 Prefill/Decode 对比、定位瓶颈、再改配置。把第 4 节的脚本存成bench_ttft.py每次调参后跑一遍记录 TTFT 与 TPOT 的变化比凭感觉靠谱。如果你需要统一管理多个模型入口和密钥可以在控制台按项目拆分 API Key把本地 vLLM 和云端模型放在同一套调用规范下对照。密钥创建入口在 https://taotoken.net/api-keys 接入细节可查 https://taotoken.net/doc 需要验证模型输出是否正常时用模型对话页面快速比对长期跑编码或 Agent 任务则更适合 Coding Plan。把观测脚本和配置模板一起纳入版本管理下次换模型或换卡时直接复用这套验证链路即可。