1. 单卡 4090 跑 DeepSeek为什么一定要先做性能压测如果你刚在 4090 上把 DeepSeek 跑起来能对话、能出结果那只是“跑通”离“跑得稳”还差一步。4090 只有 24GB 显存DeepSeek 这类模型在量化后虽然能塞进去但并发一上来显存、KV Cache、请求排队会立刻暴露瓶颈。我见过太多人本地部署完直接上业务结果两个人同时提问就开始转圈最后只能回退到单用户。EvalScope 就是解决这个问题的工具。它是魔搭社区推出的模型评测与性能基准测试框架内置 MMLU、CMMLU、C-Eval、GSM8K、HumanEval 等常用基准同时支持 LLM、多模态、embedding、reranker 的评测。对我们这次场景来说最关键的是它的 Performance Evaluator 模块可以对一个已经跑起来的推理服务发起压测统计吞吐、首 token 延迟、每 token 输出时间、QPS 等指标并生成可视化报告。这篇文章聚焦一件事在单卡 4090 本地部署 DeepSeek 之后怎么用 EvalScope 做推理性能压测。我会给出 config.toml 骨架、模型服务地址与并发参数配置、可复制的启动命令以及吞吐和延迟的验证动作。适合已经能跑通 DeepSeek 服务、想搞清楚“这张卡到底能扛多少并发”的读者。整个流程可以独立复现不需要额外硬件。2. 前置准备EvalScope 安装与 DeepSeek 服务确认2.1 创建环境并安装 EvalScope建议用 Python 3.10避免依赖冲突。conda 环境是可选的但强烈建议隔离。conda create -n evalscope python3.10 conda activate evalscope安装 EvalScope 本体和性能测试依赖。如果你只做 perf 压测装[perf]就够了想顺带跑基准评测装[all]。pip install evalscope pip install evalscope[perf]装完后可以用evalscope --help确认命令可用。如果提示找不到命令检查一下当前 conda 环境是否激活。2.2 确认 DeepSeek 服务已经以 OpenAI 兼容接口暴露EvalScope 的 perf 模式通过 HTTP 打请求所以你的 DeepSeek 服务必须暴露一个 OpenAI 兼容的/v1/chat/completions接口。常见做法是用 Ollama、vLLM 或 llama.cpp 起服务。以 Ollama 为例默认地址是http://127.0.0.1:11434/v1/chat/completions模型名类似deepseek-r1:32b。先用 curl 确认服务活着curl http://127.0.0.1:11434/v1/models能返回模型列表说明接口通了。如果这一步失败后面的压测没有意义先把服务调通。注意4090 上跑 32B 模型通常需要量化版本显存占用和量化方式会直接影响压测结果。压测前记录好你用的量化类型如 Q4_K_M否则数据没法横向对比。3. EvalScope 的 config.toml 骨架与并发参数配置EvalScope 的 perf 既支持命令行参数也支持配置文件。命令行适合快速试config.toml 适合把一套测试固化下来反复跑。下面是一个针对 4090 DeepSeek 的骨架。3.1 config.toml 骨架[perf] # 模型服务地址必须是 OpenAI 兼容接口 url http://127.0.0.1:11434/v1/chat/completions # 模型名称要和 /v1/models 返回的一致 model deepseek-r1:32b # 服务 API 类型OpenAI 兼容填 openai api openai # 并发与请求数量 parallel 5 # 并发数4090 建议从 1 开始逐步加 number 80 # 总请求数太小统计不稳建议 50 log_every_n_query 5 # 每 5 个请求打一次日志 # 超时设置本地大模型首 token 可能很慢给足时间 connect_timeout 6000 read_timeout 6000 # 输出 token 控制影响吞吐统计 max_tokens 2048 min_tokens 512 # 数据集openqa 是开放式问答适合压测 dataset openqa # 结果名称会作为 wandb 记录名和结果库名 name deepseek-r1-32b-4090-p5 # 调试模式能看到每个请求的细节 debug true几个参数需要重点解释。parallel是并发数4090 单卡建议从 1 开始依次试 1、5、10观察吞吐和延迟的拐点。number是总请求数80 是一个比较稳的起点太少会被冷启动和抖动干扰。max_tokens和min_tokens决定每次生成的长度长度越长吞吐统计越能反映真实负载。3.2 并发参数怎么选4090 的显存决定了并发上限。并发越高KV Cache 占用越大一旦超过显存服务会开始排队甚至 OOM。我的建议是做一个并发梯度1、5、10分别记录吞吐和平均延迟。如果 10 并发时延迟暴涨、吞吐反而下降说明已经过了最优并发点。参数含义4090 建议值parallel并发请求数1 / 5 / 10 梯度测试number总请求数80 起max_tokens单次最大输出2048min_tokens单次最小输出512connect_timeout连接超时6000read_timeout读取超时6000提示read_timeout一定要给大。本地 32B 模型首 token 可能要十几秒甚至更久超时设小了会大量失败数据不可用。4. 可复制的启动命令与压测执行4.1 用命令行直接发起压测如果你不想写配置文件直接用命令行也能跑。下面这条是 4090 单卡 5 并发的完整命令可以直接复制evalscope perf \ --parallel 5 \ --url http://127.0.0.1:11434/v1/chat/completions \ --model deepseek-r1:32b \ --log-every-n-query 5 \ --connect-timeout 6000 \ --read-timeout 6000 \ --max-tokens 2048 \ --min-tokens 512 \ --api openai \ --debug \ --number 80 \ --dataset openqa \ --name deepseek-r1-32b-4090-p5把--parallel改成 1 或 10就能得到不同并发下的结果。--name建议带上并发数方便后面区分结果库。4.2 用 config.toml 启动如果已经把配置写进 config.toml可以这样调用evalscope perf --config config.toml这种方式适合把测试固化比如每天跑一次回归或者对比不同量化版本。4.3 压测过程中的观察点命令跑起来后终端会按log_every_n_query的频率打印进度。重点看几个信号请求是否大量失败、首 token 时间是否稳定、有没有超时。如果失败率突然升高多半是并发超过了服务承载能力或者显存吃紧。5. 结果验证吞吐、延迟与指标解读压测结束后EvalScope 会输出一张统计表。下面是我在 4090 上跑 DeepSeek 32B 量化版的一组参考结果并发分别为 1、5、10指标1 并发5 并发10 并发测试耗时 (s)1921.774578.334612.153成功请求808080失败请求000吞吐 (tokens/s)30.47995.0293.049平均 QPS0.0420.1380.131平均延迟 (s)24.01934.70771.745首 token 时间 (s)24.01934.70771.745每输出 token 时间 (s)0.0330.0660.201平均输出 token 数732.163686.913712.0从这组数据能看出几个关键结论。第一并发从 1 提到 5吞吐从 30 涨到 95提升接近 3 倍说明单并发时 GPU 利用率不足。第二并发从 5 提到 10吞吐几乎没变95 到 93但平均延迟从 34.7 秒涨到 71.7 秒翻了一倍多。这说明 4090 在这套配置下的最优并发大约在 5 附近再往上加只会让用户等更久不会提升总吞吐。5.1 核心指标含义Throughput(average tokens/s)是平均每秒处理的 token 数衡量整体产能。Average time to first token是首 token 延迟直接决定用户感知的“卡不卡”。Average time per output token是每个输出 token 的耗时反映解码速度。Average QPS是每秒完成的请求数适合和业务量对标。5.2 用可视化看趋势EvalScope 支持把结果推到 wandb 看板。先装 wandbpip install wandb本地启动 wandb 服务wandb server start -e HOSThttp://127.0.0.1:8080 --wandb-api-key your_api_key --name deepseek-4090-perf然后在压测命令里带上--name结果会自动记录。看板上可以直观看到吞吐随并发变化的曲线比看表格更容易发现拐点。5.3 顺带跑一次基准评测性能之外如果你还想确认模型质量没被量化拖垮可以用 EvalScope 跑一个小规模基准evalscope eval \ --model deepseek-r1:32b \ --api-url http://127.0.0.1:11434/v1 \ --api-key EMPTY \ --eval-type service \ --datasets gsm8k \ --limit 10--limit 10表示只取 10 条样本快速验证链路。结果会给出准确率比如 0.9 表示 10 题对 9 题。这一步不是必须但能帮你确认服务返回的内容是正常的而不是压测时只测了个空壳。6. 本篇常见错排查6.1 连接超时或大量失败最常见的原因是read_timeout设太小。本地 32B 模型首 token 动辄十几秒默认 120 秒在某些长输出场景下也不够。把connect_timeout和read_timeout都设到 6000基本能覆盖。另一个原因是服务地址写错。确认--url指向的是/v1/chat/completions不是/v1/models也不是根路径。6.2 显存不足导致服务崩溃4090 只有 24GB并发一高KV Cache 会迅速吃满显存。如果压测中服务进程被杀先降低parallel再检查量化版本是否合适。Q4 量化通常比 Q8 更省显存但质量会有差异需要自己权衡。6.3 吞吐数据异常低如果吞吐只有个位数先确认模型是不是每次都在重新加载。有些服务在空闲后会卸载模型第一个请求触发加载导致首 token 极慢。压测前先手动发一个请求预热再开始正式测试。6.4 结果名称冲突--name重复时结果库可能被覆盖。建议在名称里带上并发数和时间戳比如deepseek-r1-32b-4090-p5-0712。6.5 模型名不匹配--model必须和/v1/models返回的名称完全一致大小写和冒号都不能错。不一致时服务会返回 404压测直接失败。如果你在接入自己的服务时遇到鉴权或地址问题可以到 TaoToken 的接入文档里对照 OpenAI 兼容接口的写法API Keys 在控制台生成模型对话入口可以用来快速验证服务是否正常返回。长期做编码和 Agent 场景的话Coding Plan 会更省心。7. 把压测变成习惯而不是一次性任务4090 上跑 DeepSeek性能不是固定值。换一个量化版本、改一次上下文长度、升级一次推理框架吞吐和延迟都会变。我试过同一张卡仅仅把量化从 Q8 换成 Q45 并发下的吞吐就从 70 多涨到 95。所以压测不该只做一次而应该固化成脚本每次改动后跑一遍用数据说话。实操上你可以把 config.toml 和启动命令放进一个 shell 脚本配合--name带上版本号结果自动进 wandb。这样一段时间后你手里就有一条完整的性能曲线知道这张 4090 到底在什么配置下最划算。压测的终点不是那张统计表而是你对自己这套部署的边界心里有数。