LLM Inference 实战：从 prefill 到 decode，用 TaoToken 统一 Key 跑通 KV cache 与 continuous batching 验证

1. 先把 prefill 和 decode 拆开看LLM Inference 两阶段到底慢在哪如果你正在做本地推理服务大概率遇到过这种场景模型能跑起来但一上并发就崩首 token 延迟忽高忽低GPU 利用率像心电图。要定位这类问题绕不开 LLM Inference 的两个核心阶段——prefill 和 decode。它们对硬件的诉求完全不同优化手段也完全不同。先说 prefill。你可以把它理解成“模型把你说的话一次性全部读一遍”。用户输入的整段 prompt 会被并行喂进模型假设 prompt 有 10 个 token这 10 个 token 会在每一层同时计算 hidden states并生成对应的 KV cache。这个阶段高度并行主要吃 GPU 的算力FLOPs输入越长prefill 越重。它决定了 TTFTTime To First Token也就是你等第一个字蹦出来要多久。再说 decode。prefill 完成后模型开始一个 token 一个 token 地往外吐。每生成一个新 token它会把新 token 输入模型复用之前存好的 KV cache 预测下一个 token再把新的 K/V 追加进 cache如此循环。这个阶段没法像 prefill 那样完全并行每一步通常只处理一个新 token很容易被显存带宽、KV cache 大小和延迟卡住。生成长度越长decode 越重它决定了 TPOTTime Per Output Token。为什么 KV cache 这么关键因为自回归生成时如果每生成一个 token 都把全部历史重新算一遍代价会爆炸。KV cache 把历史 token 的 Key 和 Value 向量存下来下次生成直接复用避免重复计算。代价是显存占用随上下文长度线性增长长上下文场景下 KV cache 往往是显存杀手。这里有个容易被忽略的点prefill 阶段从空 KV cache 开始需要为输入 prompt 里的每个 token 都算一组 K/V 向量所以第一个 token 特别慢。而 decode 阶段每步只算一个新 token 的 K/V单步计算量小但受限于显存带宽GPU 算力反而用不满。从计费角度看这也解释了为什么 input token 通常比 output token 便宜——prefill 是并行的吞吐高decode 是串行的单位时间产出低。理解这一点你才能明白后面 continuous batching 为什么能显著提升吞吐。资源利用上prefill 是 compute-intensivedecode 是 memory-bound。并发少的时候一次读取权重只为少数请求各生成一个 tokenGPU 算力闲置并发上来后同一次权重读取能服务更多 token总吞吐近似随并发数增长直到算力打满进入 compute-bound 区域。这个拐点在哪取决于你的模型大小、显存带宽和 batch 策略。2. 用 TaoToken 统一 Key 做推理服务鉴权入口本地推理服务最容易踩的坑不是模型跑不起来而是 Key 管理混乱。你可能同时用着好几个工具一个脚本调 OpenAI 兼容接口一个 Cline 插件做代码补全还有一个 Claude Code 做长任务。每个工具各自维护一份 Key改一次配置要改五六个地方团队协作时更是灾难。我的做法是把调用入口统一到 TaoToken。它的 API 地址是https://taotoken.net/api兼容 OpenAI 的接口格式意味着你现有的 SDK 和脚本基本不用改只换 Base URL 和 Key 就行。官网在https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content注册后在控制台生成 Key。统一入口的好处很直接本地推理服务、压测脚本、IDE 插件全部指向同一个 Base URLKey 只维护一份。换模型、调参数、看用量都在一个地方排查问题时不用怀疑“是不是这个工具的 Key 过期了”。具体操作上你需要在控制台创建一个 API Key然后把它写进环境变量。我习惯用TAOTOKEN_API_KEY这个变量名避免和系统里其他 Key 冲突。模型 ID 按你实际要用的填比如gpt-4o-mini或claude-3-5-sonnet这类具体以控制台模型列表为准。这里要强调一点TaoToken 是统一鉴权和调用入口不是让你拿它替代本地推理引擎。你的 vLLM、TGI 或者 llama.cpp 该怎么跑还怎么跑TaoToken 负责的是对外调用层的 Key 统一。两者是配合关系不是替代关系。如果你用的是 Claude Code 这类工具配置方式略有不同。Claude Code 走的是 Anthropic 协议需要设置ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY。Cline 这类 VS Code 插件则在设置里填 Base URL、API Key 和 Model ID 三件套。Codex 的话看auth.json里的配置。不管哪种核心都是三件套Base URL、Key、Model ID缺一不可。统一之后压测脚本、生产服务、开发插件共用一套鉴权改配置只改一处。这对后面做 continuous batching 对比实验特别重要因为你要保证所有请求走的是同一条链路否则吞吐数据没法对比。3. 可复制的 endpoint 与 Key 配置片段这一节直接给可复制的配置。先设环境变量Linux/macOS 下写进~/.bashrc或~/.zshrcexport TAOTOKEN_API_KEYsk-你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/api export TAOTOKEN_MODELgpt-4o-miniWindows PowerShell 下$env:TAOTOKEN_API_KEYsk-你的Key $env:TAOTOKEN_BASE_URLhttps://taotoken.net/api $env:TAOTOKEN_MODELgpt-4o-mini如果你用 Cline 插件在 VS Code 的settings.json里加这段{ cline.apiProvider: openai, cline.openAiBaseUrl: https://taotoken.net/api, cline.openAiApiKey: sk-你的Key, cline.openAiModelId: gpt-4o-mini }Claude Code 的配置放在~/.claude/settings.json或项目级.claude/settings.json{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的Key, ANTHROPIC_MODEL: claude-3-5-sonnet } }Codex 的auth.json配置{ openai: { base_url: https://taotoken.net/api, api_key: sk-你的Key, model: gpt-4o-mini } }Python 脚本里读取环境变量用 OpenAI SDK 调用import os from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL], ) resp client.chat.completions.create( modelos.environ[TAOTOKEN_MODEL], messages[{role: user, content: 用一句话解释 KV cache}], max_tokens128, ) print(resp.choices[0].message.content)注意base_url结尾不要多加/v1SDK 会自己拼。如果你用的是 requests 直接发 HTTP完整路径是https://taotoken.net/api/v1/chat/completionsHeader 里带Authorization: Bearer sk-你的Key。配置完成后建议先跑一个最小请求验证连通性别急着上压测。最小请求能通说明 Base URL、Key、Model ID 三件套没问题后面出问题就只可能是并发或参数层面的事。4. 验证请求与 continuous batching 吞吐对比实验配置通了之后重点来了用同一批 prompt 对比开启和关闭 continuous batching 的吞吐与首 token 延迟。这里要说明continuous batching 是推理引擎如 vLLM、TGI的能力不是 API 网关的能力。TaoToken 负责统一鉴权推理引擎负责调度。所以实验设计上你要在本地推理服务侧控制 batching 开关通过 TaoToken 统一发请求。先准备一批固定 prompt长度分布要有梯度短中长都覆盖PROMPTS [ 解释什么是 prefill 阶段, 用三句话说明 KV cache 的作用和代价, 详细对比 static batching 和 continuous batching 的差异包括对 TTFT 和 TPOT 的影响, 写一段 200 字的技术说明解释为什么 decode 阶段是 memory-bound, 从 GPU 算力利用率角度分析并发数增加时吞吐量从线性增长到饱和的过程, ] * 8 # 重复 8 次凑 40 个请求压测脚本记录 TTFT 和总耗时import time import asyncio from openai import AsyncOpenAI client AsyncOpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL], ) async def one_request(prompt, idx): start time.perf_counter() first_token_time None tokens 0 stream await client.chat.completions.create( modelos.environ[TAOTOKEN_MODEL], messages[{role: user, content: prompt}], max_tokens256, streamTrue, ) async for chunk in stream: if chunk.choices[0].delta.content: if first_token_time is None: first_token_time time.perf_counter() - start tokens 1 total time.perf_counter() - start return {idx: idx, ttft: first_token_time, total: total, tokens: tokens} async def run_all(): tasks [one_request(p, i) for i, p in enumerate(PROMPTS)] results await asyncio.gather(*tasks) ttfts [r[ttft] for r in results if r[ttft]] totals [r[total] for r in results] total_tokens sum(r[tokens] for r in results) wall max(totals) print(f请求数: {len(results)}) print(f平均 TTFT: {sum(ttfts)/len(ttfts):.3f}s) print(fP95 TTFT: {sorted(ttfts)[int(len(ttfts)*0.95)]:.3f}s) print(f总 token: {total_tokens}) print(f墙钟时间: {wall:.3f}s) print(f吞吐: {total_tokens/wall:.2f} token/s) asyncio.run(run_all())在本地推理服务侧关闭 continuous batching 时vLLM 可以设--max-num-seqs 1强制串行开启时用默认值或调大--max-num-seqs。跑两轮把结果填进这张表配置请求数平均 TTFTP95 TTFT总 token墙钟时间吞吐(token/s)batching 关闭40待填待填待填待填待填batching 开启40待填待填待填待填待填实测下来关闭 batching 时短请求很快返回但长请求会拖住整个队列P95 TTFT 明显偏高开启 continuous batching 后完成的请求立即移出 batch空位马上被下一个请求填上总吞吐通常能提升数倍代价是单个请求的 TTFT 可能略有上升因为要和其他请求共享算力。这里有个细节continuous batching 有两种 prefill 策略。Prefill-First 会优先一次处理完整个 prompt长 prompt 会让已有请求的流式输出出现明显停顿Chunked Prefill 把 prompt 分成多个 chunk 分多轮处理每处理完一块就有机会继续生成已有请求的 token输出更平稳。如果你做的是交互式应用Chunked Prefill 体验更好如果是离线批处理Prefill-First 吞吐可能更高。5. 常见报错排查401、local proxy failed、reading choices、OAuth跑实验时最容易撞上的几类报错我按实际遇到的频率排一下。401 Unauthorized。这个最常见八成是 Key 没设对。先确认环境变量真的生效了echo $TAOTOKEN_API_KEY看有没有值。如果用的是 Cline 或 Claude Code检查配置文件里的 Key 有没有多余空格或换行。还有一种情况是 Key 复制时漏了前缀或者控制台里把 Key 删了但本地还在用旧的。排查顺序环境变量 → 配置文件 → 控制台 Key 状态。local proxy failed。这个报错通常出现在你本地配了代理但代理没起来或者端口不对。注意这里说的是本地开发环境的网络配置问题不是让你去搞什么特殊网络手段。检查你的HTTP_PROXY/HTTPS_PROXY环境变量如果不需要代理就 unset 掉。很多 SDK 会自动读取这些变量导致请求被转发到一个不存在的本地端口。reading choices 报错类似KeyError: choices或NoneType has no attribute choices。这通常是响应体不是预期的 JSON 结构可能是 Base URL 拼错了比如多加了/v1变成/v1/v1/chat/completions或者少加了路径。用 curl 直接打一次看原始返回curl -s 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:hi}]}如果返回的是 HTML 而不是 JSON说明路径不对打到了某个网页上。OAuth 相关报错。Claude Code 有时会走 OAuth 流程如果你已经配了ANTHROPIC_API_KEY但它还在尝试 OAuth检查是不是有残留的登录态。清掉~/.claude下的缓存文件确保settings.json里的env配置优先级最高。Cline 的话在设置里明确选 API Key 模式别选 OAuth。还有一个隐蔽的坑Model ID 写错。比如控制台里模型叫gpt-4o-mini你写成gpt-4o-mini-2024就会报模型不存在。以控制台模型列表为准别凭记忆写。排查时记住一个原则先用 curl 打最小请求排除 SDK 和插件的干扰。curl 通了问题就在客户端配置curl 不通问题在 Base URL、Key 或 Model ID。这个二分法能省你大量时间。6. 把统一入口和 batching 验证固化成流程整套跑下来我的体会是LLM Inference 的性能优化一半在推理引擎的调度策略一半在调用链路的干净程度。prefill 和 decode 的特性决定了你不能用同一套指标衡量它们TTFT 看 prefillTPOT 看 decode吞吐看整体。KV cache 是连接两个阶段的桥梁continuous batching 则是让 decode 阶段 GPU 利用率提上来的关键手段。把 TaoToken 作为统一鉴权入口最大的价值不是省了几行配置而是让实验变量可控。当你对比 batching 开关时如果每个工具各用各的 Key、各走各的链路数据根本没法比。统一之后Base URL、Key、Model ID 三件套固定剩下的变量就只有推理引擎的调度参数。如果你要长期做编码或 Agent 类任务可以考虑用 Coding Plan把调用额度集中管理。验证模型效果的话模型对话页面能直接试。接入文档里有各语言的完整示例API Keys 页面管理你的 Key。建议先把最小请求跑通再上压测脚本最后把结果表填完整。这套流程固化下来以后换模型、调参数、加并发都有基线可对比。