1. 本地推理服务跑通之后真正的麻烦才刚开始DeepSeek-R1 部署这件事很多人卡在第一步模型权重下载完了vLLM 或 Ollama 也起来了curl一下/v1/models能返回 JSON就觉得大功告成。但只要你打算把它接进真实业务——比如给团队内部做一个代码助手、给客服系统加一个推理后端、或者跑批量数据清洗——马上会遇到三个绕不开的问题。第一接口联调混乱。本地服务监听在0.0.0.0:11435但你的客户端可能跑在另一台机器、另一个容器、甚至另一个云账号里。Base URL 写localhost还是内网 IP端口映射对不对/v1/chat/completions和/v1/completions的请求体差异在哪这些细节不统一联调就是一场猜谜。第二性能没有基线。你只知道能出结果但不知道首 token 延迟TTFT是多少、每秒能吐多少 token、并发到 20 路时会不会雪崩。没有基线就没法判断优化有没有效果也没法给业务方一个可承诺的 SLA。第三多模型切换成本高。今天用 DeepSeek-R1-Distill-Qwen-32B明天想对比 Llama-70B后天要接一个云端更强的版本做兜底。如果每个模型都维护一套 Key、一套 Base URL、一套客户端配置代码里全是硬编码改一次崩一次。这篇内容就是解决这三个问题的。我会先给出一个统一 Key 的接入层配置让你用同一套客户端代码切换本地和远端模型然后交付一份可复现的并发压测脚本把 TTFT、TPOT、吞吐量三个核心指标测出来最后给出三项验证动作确认你的服务在真实负载下是稳的。适合已经跑通推理服务、准备做接口联调和性能压测的开发者。2. 用 TaoToken 统一 Key 收口多模型接入本地部署的 DeepSeek-R1 有一个天然局限它只在你自己的机器上。一旦你需要在 CI 流水线里跑测试、在笔记本上临时验证、或者给不在同一内网的同事用就得有一个统一的接入层。TaoToken 在这里扮演的角色是一个兼容 OpenAI 协议的模型网关——你不需要改客户端的调用方式只需要把 Base URL 和 Key 换掉就能在本地模型和远端模型之间切换。它的价值不在于多一个中转而在于把模型接入这件事标准化。你的代码里只认三个东西Base URL、API Key、Model ID。本地 vLLM 服务是一个 endpointTaoToken 是另一个 endpoint客户端逻辑完全一致。这样你在做压测时可以先用本地服务跑基线再用同一个脚本打远端做对比变量只有一个结论才可信。具体来说TaoToken 的 API 入口是https://taotoken.net/api兼容 OpenAI 的/v1/chat/completions和/v1/models接口。你需要在控制台创建一个 API Key然后把它写进环境变量或配置文件。对于 Claude Code 这类工具它读取的是~/.claude/settings.json或项目级的.claude/settings.json对于 Codex它读的是~/.codex/auth.json。这两个文件的格式不一样下面分别给出。先看 Claude Code 的配置。这个文件的作用是告诉 Claude Code不要走默认的 Anthropic 端点走我指定的 Base URL用我指定的 Key 和模型。路径是~/.claude/settings.json内容如下{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: sk-你的TaoTokenKey, ANTHROPIC_MODEL: deepseek-r1, ANTHROPIC_SMALL_FAST_MODEL: deepseek-r1 } }这里ANTHROPIC_MODEL填的是你在 TaoToken 控制台看到的模型 ID不是本地路径。如果你要指向本地 vLLM就把ANTHROPIC_BASE_URL改成http://你的内网IP:11435/v1Key 填EMPTYvLLM 默认不校验模型 ID 填启动服务时--served-model-name指定的名字。再看 Codex 的配置。Codex 读的是~/.codex/auth.json格式是{ OPENAI_API_KEY: sk-你的TaoTokenKey, OPENAI_BASE_URL: https://taotoken.net/api/v1 }注意这里的 Base URL 带了/v1因为 Codex 内部拼接的是/chat/completions。如果你用的是其他 OpenAI 兼容客户端比如 Cline、Continue、或者自己写的 Python 脚本统一用https://taotoken.net/api/v1作为 base_url 即可。对于 Cline 这类 VS Code 插件配置入口在插件的设置面板里需要填三项API Provider 选 OpenAI CompatibleBase URL 填https://taotoken.net/api/v1API Key 填你的 KeyModel ID 填deepseek-r1。如果你要接本地 vLLMBase URL 改成http://内网IP:11435/v1Key 填EMPTYModel ID 填DeepSeek-R1-Distill-Qwen-32B或你实际启动时的名字。这里有一个容易踩的坑vLLM 启动时如果加了--served-model-name客户端请求里的model字段必须和它完全一致否则会返回 404。如果你没加这个参数vLLM 默认用模型路径作为 model ID比如/home/ubuntu/DeepSeek/DeepSeek-R1-Distill-Qwen-32B这个字符串又长又容易写错。建议启动时显式指定一个短名字CUDA_VISIBLE_DEVICES0,1,2,3,4,5,6,7 python -m vllm.entrypoints.openai.api_server \ --model /home/ubuntu/DeepSeek/DeepSeek-R1-Distill-Qwen-32B \ --served-model-name deepseek-r1-32b \ --host 0.0.0.0 \ --port 11435 \ --tensor-parallel-size 8 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --trust-remote-code \ --dtype half这样客户端里 model 填deepseek-r1-32b就行。TaoToken 侧的模型 ID 以控制台显示为准通常也是类似的短名。两边名字对齐联调时就不会出现明明服务活着却报模型不存在的情况。3. 可复制的压测脚本与配置片段接口通了之后下一步是压测。很多人压测就是写个for循环发请求测出来的数字没有参考价值因为并发模型不对、没有统计分位数、也没有区分 prefill 和 decode 阶段。这里我给一份基于asyncio和aiohttp的脚本能同时测 TTFT、TPOT 和吞吐量并且支持指定并发数和请求总数。先装依赖pip install aiohttp numpy脚本保存为bench_async.pyimport asyncio import aiohttp import time import json import numpy as np import argparse async def single_request(session, url, headers, payload, results, idx): start time.perf_counter() first_token_time None token_times [] try: async with session.post(url, headersheaders, jsonpayload) as resp: if resp.status ! 200: text await resp.text() results[idx] {error: fHTTP {resp.status}: {text[:200]}} return async for line in resp.content: line line.strip() if not line or not line.startswith(bdata: ): continue data line[6:] if data b[DONE]: break try: chunk json.loads(data) except json.JSONDecodeError: continue delta chunk.get(choices, [{}])[0].get(delta, {}) content delta.get(content) if content: now time.perf_counter() if first_token_time is None: first_token_time now token_times.append(now) end time.perf_counter() if first_token_time is None: results[idx] {error: no token received} return ttft first_token_time - start total_tokens len(token_times) if total_tokens 1: intervals np.diff(token_times) tpot float(np.mean(intervals)) else: tpot 0.0 total_time end - start throughput total_tokens / total_time if total_time 0 else 0 results[idx] { ttft: ttft, tpot: tpot, tokens: total_tokens, total_time: total_time, throughput: throughput, } except Exception as e: results[idx] {error: str(e)} async def run_bench(args): url f{args.base_url}/chat/completions headers { Content-Type: application/json, Authorization: fBearer {args.api_key}, } payload { model: args.model, messages: [{role: user, content: args.prompt}], max_tokens: args.max_tokens, temperature: 0.0, stream: True, } results [None] * args.num_requests semaphore asyncio.Semaphore(args.concurrency) async def bounded_request(session, idx): async with semaphore: await single_request(session, url, headers, payload, results, idx) connector aiohttp.TCPConnector(limitargs.concurrency * 2) async with aiohttp.ClientSession(connectorconnector) as session: tasks [bounded_request(session, i) for i in range(args.num_requests)] wall_start time.perf_counter() await asyncio.gather(*tasks) wall_end time.perf_counter() ok [r for r in results if r and error not in r] err [r for r in results if r and error in r] print(f总请求: {args.num_requests}, 成功: {len(ok)}, 失败: {len(err)}) if err: print(错误示例:, err[0][error]) if not ok: return ttfts [r[ttft] for r in ok] tpots [r[tpot] for r in ok] tputs [r[throughput] for r in ok] total_tokens sum(r[tokens] for r in ok) wall_time wall_end - wall_start print(f并发: {args.concurrency}) print(fTTFT P50: {np.percentile(ttfts, 50)*1000:.1f} ms fP90: {np.percentile(ttfts, 90)*1000:.1f} ms fP99: {np.percentile(ttfts, 99)*1000:.1f} ms) print(fTPOT P50: {np.percentile(tpots, 50)*1000:.1f} ms fP90: {np.percentile(tpots, 90)*1000:.1f} ms) print(f单请求吞吐 P50: {np.percentile(tputs, 50):.1f} tok/s) print(f系统总吞吐: {total_tokens / wall_time:.1f} tok/s) if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--base_url, defaulthttp://127.0.0.1:11435/v1) parser.add_argument(--api_key, defaultEMPTY) parser.add_argument(--model, defaultdeepseek-r1-32b) parser.add_argument(--prompt, default用 Python 写一个快速排序并解释时间复杂度。) parser.add_argument(--max_tokens, typeint, default256) parser.add_argument(--num_requests, typeint, default50) parser.add_argument(--concurrency, typeint, default10) args parser.parse_args() asyncio.run(run_bench(args))这个脚本的关键设计点用asyncio.Semaphore控制并发而不是一次性发所有请求用流式响应逐 token 记录时间戳这样 TTFT 和 TPOT 是真实测量值不是估算统计 P50/P90/P99 分位数避免平均值被极端值拉偏。跑本地 vLLM 服务python bench_async.py \ --base_url http://127.0.0.1:11435/v1 \ --api_key EMPTY \ --model deepseek-r1-32b \ --num_requests 50 \ --concurrency 10跑 TaoToken 远端python bench_async.py \ --base_url https://taotoken.net/api/v1 \ --api_key sk-你的Key \ --model deepseek-r1 \ --num_requests 50 \ --concurrency 10同一份脚本、同一组参数变量只有 endpoint对比才有意义。下面是一组实测数据的对照表硬件是单机 8 卡 RTX 2080Ti模型 DeepSeek-R1-Distill-Qwen-32Bmax_tokens256请求数 50并发部署方式TTFT P50TTFT P99TPOT P50系统总吞吐1本地 vLLM180 ms210 ms28 ms35 tok/s10本地 vLLM420 ms890 ms31 ms280 tok/s20本地 vLLM950 ms2100 ms35 ms410 tok/s10TaoToken 远端620 ms1100 ms33 ms260 tok/s这张表能读出几个结论并发从 1 提到 10TTFT 涨了 2 倍多但吞吐涨了 8 倍说明批处理在起作用并发到 20 时 TTFT P99 突破 2 秒用户体验开始恶化这时候要么加机器要么在网关层做限流。远端接入的 TTFT 比本地高因为多了一跳网络但 TPOT 接近说明 decode 阶段的瓶颈不在网络而在 GPU 本身。4. 三项验证动作确认服务真的稳压测数字好看不代表服务可靠。你需要三个可复现的验证动作分别覆盖接口正确性、长上下文稳定性和并发下的错误率。第一项验证接口返回结构。用curl发一个非流式请求检查返回的 JSON 里choices[0].message.content非空usage.total_tokens大于 0curl -s http://127.0.0.1:11435/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1-32b, messages: [{role: user, content: 11等于几只回答数字。}], max_tokens: 16, temperature: 0 } | python -m json.tool预期输出里能看到content: 2和total_tokens: 20左右。如果content为空但finish_reason是length说明max_tokens太小被截断了如果返回 404检查 model 名字是否和--served-model-name一致。第二项验证长上下文。DeepSeek-R1 支持 8K 甚至更长的上下文但 vLLM 启动时--max-model-len设小了会直接报错。构造一个约 4000 token 的输入确认服务不崩import requests long_text 请总结以下内容\n (这是一段测试文本。 * 500) resp requests.post( http://127.0.0.1:11435/v1/chat/completions, json{ model: deepseek-r1-32b, messages: [{role: user, content: long_text}], max_tokens: 64, temperature: 0, }, timeout120, ) print(resp.status_code) print(resp.json()[choices][0][message][content][:100])如果返回 400 且错误信息里有maximum context length说明输入超过了--max-model-len需要调大启动参数或截断输入。如果返回 200 但耗时超过 30 秒说明 prefill 阶段压力大考虑开--enable-chunked-prefill。第三项验证并发错误率。用压测脚本把并发拉到 50请求数 200看失败率python bench_async.py \ --base_url http://127.0.0.1:11435/v1 \ --api_key EMPTY \ --model deepseek-r1-32b \ --num_requests 200 \ --concurrency 50 \ --max_tokens 128健康的标准是失败率低于 1%且没有Connection reset或Timeout错误。如果失败率超过 5%检查 vLLM 的--gpu-memory-utilization是否太高导致 OOM或者--max-num-seqs是否超过了 GPU 能承受的批大小。vLLM 默认max-num-seqs是 256在 2080Ti 这种卡上可能太大建议显式设成 64 或 128。这三项做完你对服务的边界就有数了能接多长的输入、能扛多少并发、错误率在什么水平。这些数字写进文档业务方问起来你就能直接回答而不是应该没问题。5. 联调压测中最容易撞上的四类报错这一节按报错信息来排查都是实际压测中高频出现的。401 Unauthorized。本地 vLLM 默认不校验 Key但如果你在启动时加了--api-key客户端就必须带Authorization: Bearer key。TaoToken 侧则是 Key 无效或过期。排查顺序先确认请求头里有没有Authorization再确认 Key 有没有多余空格最后去控制台看 Key 是否被禁用。如果用的是 Claude Code检查settings.json里ANTHROPIC_AUTH_TOKEN是否写对Codex 检查auth.json里OPENAI_API_KEY。local proxy failed / connection refused。这个报错通常出现在客户端配置了代理但代理没起来或者 Base URL 写成了localhost而服务在另一台机器。先curl一下 Base URL 的/v1/models确认网络可达。如果客户端在容器里localhost指向容器本身要用宿主机的内网 IP 或host.docker.internal。另外检查防火墙vLLM 监听的端口是否对外开放。Error reading choices / KeyError choices。这个报错说明客户端收到了响应但 JSON 结构里没有choices字段。常见原因是 Base URL 少了/v1请求打到了根路径返回的是 HTML 或 404 JSON。另一个原因是流式请求里客户端把data: [DONE]也当成了 JSON 解析。检查 base_url 是否以/v1结尾流式解析时先判断data [DONE]再json.loads。OAuth / token refresh failed。Claude Code 和 Codex 这类工具有时会尝试刷新 OAuth token如果你用的是 API Key 模式需要在配置里显式禁用 OAuth。Claude Code 的settings.json里加上ANTHROPIC_AUTH_TOKEN后它就不会走 OAuth 流程。Codex 的auth.json里只保留OPENAI_API_KEY和OPENAI_BASE_URL不要留tokens字段。如果还是报 OAuth 错误检查是否有环境变量ANTHROPIC_API_KEY和配置文件冲突环境变量优先级更高。还有一个不报错但很坑的情况请求返回 200但content是空的finish_reason是stop。这通常是 prompt 里包含了模型认为已经结束的标记或者temperature设成了 0 且模型对某些输入直接输出空。换一个 prompt 试试如果正常说明是输入触发了模型的边界行为不是服务问题。6. 把接入层固定下来后面的事才顺走到这里你应该已经有一套能跑的本地 DeepSeek-R1 服务、一份能测 TTFT/TPOT/吞吐的压测脚本、以及三项验证动作。接下来最重要的一步是把接入层固定下来——不要让 Base URL 和 Key 散落在各个脚本和配置文件里。我的做法是在项目根目录放一个.env文件里面只写三个变量LLM_BASE_URLhttps://taotoken.net/api/v1 LLM_API_KEYsk-你的Key LLM_MODELdeepseek-r1所有客户端代码从环境变量读取本地调试时改成http://127.0.0.1:11435/v1和EMPTY即可。这样切换本地和远端只需要改一行压测脚本也不用改参数。如果你需要长期跑编码任务或 Agent 工作流可以考虑用 Coding Plan 把额度固定下来避免按次计费带来的成本波动。模型对话入口适合临时验证模型输出质量API Keys 页面用来管理 Key 和查看用量接入文档里有各语言客户端的完整示例。这几个入口按需取用不用一次全打开。最后留一个实用技巧压测时把--max_tokens设成你业务里真实的最大输出长度而不是随便填 256。因为 TPOT 和吞吐量对输出长度敏感用真实值测出来的数字才能直接写进容量规划。另外压测前先跑一轮--num_requests 5 --concurrency 1做预热让 vLLM 完成 CUDA graph 捕获和显存分配否则第一波请求的 TTFT 会偏高污染统计结果。