1. 推理服务从本地到生产卡点到底在哪把 vLLM 在本地跑起来和把它当成一个能扛住线上流量的推理服务中间隔着一整套工程链路。本地跑通只证明模型能加载、能出 token生产环境要回答的是另一类问题目标 QPS 下 P99 延迟能不能守住、TTFT 会不会因为排队被拉长、扩容时冷启动的几十秒谁来兜底、多个模型实例的 Key 和鉴权怎么统一管。这一篇聚焦 vLLM 推理服务从本地到生产的部署链路围绕 TTFT首 token 延迟和吞吐这两个核心指标展开。我会给出config.toml与settings.json的可复制骨架再演示通过 TaoToken 统一 Key/API 通道完成一次端到端压测与结果校验。适合已经在本地跑过 vLLM、准备把它推到生产或者做容量规划的人如果你还没跑通单机推理也能跟着把配置和验证动作走一遍。核心检索词先摆清楚推理服务、生产部署、TTFT、吞吐、vLLM。这几个词背后其实是同一件事——你要在延迟和吞吐之间做取舍而这个取舍必须用压测数据说话不能拍脑袋。先说一个我踩过的坑早期按「单请求延迟 × 目标 QPS」去估实例数结果上线后 P99 直接爆掉。原因是批处理下单个请求的延迟和同 batch 内其他请求强相关输入长度分布一变排队时间就上去了。所以这篇的重点不是讲概念而是把配置和验证动作落到可复现的层面。2. TaoToken 前置统一 Key 与 API 通道生产部署里有个容易被忽略的环节鉴权和入口。推理服务本身最好只暴露内网接口对外由 API 网关统一处理鉴权、限流、日志。但自建网关要维护 Key 分发、配额、监控成本不低。TaoToken 在这里的角色是提供一个统一的 Key 和 API 通道让你在压测和灰度阶段不用自己搭一套鉴权层就能把请求打到 vLLM 实例上同时拿到统一的调用记录。官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 地址https://taotoken.net/api你需要先拿到一个 API Key然后把它配到压测脚本或网关配置里。这一步的意义在于压测流量和真实流量走同一条鉴权通道验证结果才有参考价值。如果压测时绕过鉴权直连内网上线后网关层的限流和排队会引入额外延迟之前的压测数据就失真了。拿 Key 的路径进入控制台后创建 API Key建议按环境分 Key压测一个、灰度一个、生产一个方便出问题时快速定位和吊销。相关入口控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI Keyshttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content注意Key 只放在服务端环境变量或密钥管理里不要写进前端代码或提交到仓库。压测脚本里用TAOTOKEN_API_KEY读取。3. 可复制配置config.toml 与 settings.json 骨架这一节给两份骨架。config.toml用于 vLLM 服务端启动参数settings.json用于压测客户端和网关侧的配置。两份都按「先能跑、再调优」的顺序组织参数后面标注了调优方向。3.1 vLLM 服务端 config.toml# config.toml - vLLM 推理服务启动配置骨架 [server] host 0.0.0.0 port 8000 # 生产环境建议只监听内网由网关对外 api_key ${VLLM_INTERNAL_KEY} [model] name your-model-path-or-hf-id dtype auto # 量化等级awq/gptq/fp8按硬件和精度验证结果选 quantization fp8 max_model_len 8192 gpu_memory_utilization 0.90 [batching] # 连续批处理相关vLLM 默认开启 max_num_seqs 256 max_num_batched_tokens 8192 # 调度策略fcfs 或 priority scheduling_policy fcfs [parallel] tensor_parallel_size 1 pipeline_parallel_size 1 [monitoring] # 暴露 Prometheus 指标 enable_metrics true metrics_port 8001启动命令vllm serve your-model-path-or-hf-id \ --config config.toml \ --host 0.0.0.0 \ --port 8000max_num_seqs和max_num_batched_tokens是 TTFT 与吞吐权衡的两个关键旋钮。调大max_num_seqs能提升吞吐但 batch 内请求变多预填充阶段被拉长TTFT 上升。调小则相反。这两个值必须靠压测确定不能照抄。3.2 压测客户端 settings.json{ endpoint: https://taotoken.net/api/v1/chat/completions, api_key_env: TAOTOKEN_API_KEY, model: your-model-name, concurrency: 32, duration_seconds: 300, request_distribution: { short: { weight: 0.6, input_tokens: 256, output_tokens: 128 }, long: { weight: 0.3, input_tokens: 2048, output_tokens: 512 }, tail: { weight: 0.1, input_tokens: 8192, output_tokens: 2048 } }, metrics: { record_ttft: true, record_tpot: true, percentiles: [50, 95, 99] }, warmup_requests: 20 }这份配置里request_distribution是关键。真实流量不是均匀的长尾请求会显著拉高 P99。压测时按短、长、长尾三类加权才能逼近真实分布。warmup_requests用来预热避免冷启动污染前几十个请求的延迟数据。4. 验证请求与成功结果配置就位后先做一次单请求验证确认通道打通再上压测。4.1 单请求冒烟测试curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer ${TAOTOKEN_API_KEY} \ -H Content-Type: application/json \ -d { model: your-model-name, messages: [{role: user, content: 用一句话解释什么是首 token 延迟}], max_tokens: 64, stream: true }流式返回下你能直观看到第一个 token 到达的时间。如果这里就卡住先排查 Key、模型名、网络别急着上压测。4.2 压测执行与结果校验用上面的settings.json跑一轮python bench_client.py --config settings.json --output result.json成功的结果应该包含这几类数据指标含义关注点TTFT P50/P95/P99首 token 延迟分位交互场景看 P99TPOT每 token 输出时间反映解码速度Throughput每秒完成 token 数批量场景核心Error Rate错误率应低于 1%Queue Length队列长度持续增长说明容量不足校验逻辑把压测得到的 P99 TTFT 和目标 SLA 对比。如果 P99 超过 SLA 的 1.5 倍说明当前max_num_seqs偏大或实例数不足。如果吞吐远低于预期而 GPU 利用率不高说明 batch 没吃满可以调大max_num_batched_tokens。一次典型的成功输出长这样数值仅示意结构{ ttft_ms: { p50: 180, p95: 420, p99: 780 }, tpot_ms: { p50: 22, p95: 35, p99: 58 }, throughput_tokens_per_sec: 2450, error_rate: 0.004, gpu_utilization_avg: 0.82 }拿到这组数据后按目标 QPS 反推实例数单实例吞吐 × 实例数 ≥ 目标 QPS × 冗余系数建议 1.2–1.3。同时确认 P99 TTFT 在 SLA 内。5. 本篇常见错排查5.1 TTFT 高但吞吐正常现象吞吐达标但 P99 TTFT 明显偏高。原因通常是max_num_seqs太大预填充阶段排队严重。处理调小max_num_seqs或对长输入请求单独走一个实例池避免长 prompt 阻塞短请求。5.2 吞吐上不去GPU 利用率低现象GPU 利用率长期低于 50%吞吐远低于硬件预期。原因可能是max_num_batched_tokens太小batch 没吃满或者请求分布太稀疏并发不够。处理调大 batch 上限压测时提高concurrency确认是配置问题还是流量本身不足。5.3 压测数据好看上线就崩现象压测 P99 很漂亮真实流量一上来就超时。原因多半是压测流量太均匀没模拟长尾和突发。处理在settings.json里加大长尾权重增加突发场景短时 QPS 翻倍重新压。5.4 扩容后首批请求超时现象扩容新实例后头几十个请求延迟异常高。这是冷启动模型加载要几十秒到几分钟。处理预留常驻冗余实例或在新实例就绪前先发预热请求。灰度时先切 5%–10% 流量观察别一次性全量。5.5 鉴权通道报 401/403现象压测脚本直连内网正常走 TaoToken 通道报鉴权错误。排查顺序Key 是否正确读取环境变量、Key 是否被吊销、请求头格式是否为Bearer、模型名是否在通道侧有映射。接入细节可对照接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content6. 把验证动作固定下来推理服务的生产部署本质是把「延迟与吞吐的取舍」变成一组可复现的配置和验证动作。config.toml定服务端旋钮settings.json定压测流量分布TaoToken 统一 Key 通道保证压测和真实流量走同一条鉴权路径。三者对齐压测数据才有意义。如果你还在调模型和验证输出质量可以先用模型对话快速确认通道和模型行为https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content如果进入长期编码或 Agent 场景需要稳定的调用配额和通道可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content压测和接入过程中遇到鉴权或通道问题优先查 API Keys 和接入文档API Keyshttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content最后留一个实操建议把每次压测的config.toml、settings.json和result.json一起归档标注模型版本、硬件型号、量化等级。下次调参或扩容时你有基线可对比而不是从零再猜一遍。