1. 为什么要在 H200 上认真做一次 vLLM 与 SGLang 的对比DeepSeek 671B 满血版在 H200 上跑起来只是第一步真正上线生产时团队最常卡住的问题是同样 8 张 H200 141GBvLLM 和 SGLang 到底该选哪个我见过不少项目在测试环境用 vLLM 跑得挺顺切到线上高并发后吞吐掉得厉害也见过 SGLang 在长上下文场景里首 token 延迟表现更稳但短请求密集时反而不如 vLLM。这些差异不是靠感觉能判断的必须用统一的压测口径把吞吐、首 token 延迟、显存占用三项指标拉出来对比。这篇是 H200 部署 DeepSeek 671B 系列的第四篇前三篇分别搞定了系统初始化、vLLM 安装、SGLang 安装。现在两台引擎都能启动服务了接下来要解决的是选型问题。我会给出两套可直接复制的启动参数、TaoToken 统一 Key 的 config.toml 与 settings.json 骨架以及一套基于 EvalScope 的压测脚本。压测数据来自 8 卡 H200 单机环境并发覆盖 128、256、512 三档你可以按自己业务的请求特征对号入座。适合谁看已经在 H200 上部署了 DeepSeek 671B、正在做推理引擎选型的运维和算法工程同学或者准备把本地推理服务接入统一 API 网关、需要一套可复现压测流程的团队。如果你还没装好引擎建议先回看前三篇把 vLLM 0.7.3 和 SGLang v0.4.3.post2 的环境跑通再往下走。2. TaoToken 前置统一 Key 让两套引擎的压测口径一致做 vLLM 和 SGLang 对比时一个容易被忽略的变量是调用入口。如果 vLLM 走本地直连、SGLang 走另一套网关压测结果里的网络开销和鉴权逻辑就不一致吞吐差异会被污染。我的做法是两套引擎都通过 TaoToken 统一 Key 接入压测脚本只改 base_url 指向不同端口其余参数完全一致。TaoToken 在这里的角色是统一 API 网关你可以在控制台创建 Key然后在 config.toml 或 settings.json 里配置模型路由。这样 vLLM 的 8102 端口和 SGLang 的 8102 端口分时启动避免端口冲突都能被同一套客户端代码调用。压测时只需要切换 base_url不用改鉴权逻辑。先拿 Key访问 https://taotoken.net/api-keys 创建建议按环境分 Key压测用一个、生产用一个方便后续做用量隔离。接入文档在 https://taotoken.net/doc 里面有 OpenAI 兼容接口的完整说明。模型对话调试入口在 https://taotoken.net/model-chat 压测前可以先用它发一条请求确认 Key 和模型名对得上。注意TaoToken 的 Key 只用于统一接入和路由不改变 vLLM/SGLang 本身的推理行为。压测对比的是引擎性能网关层要保持配置一致否则数据不可比。3. 可复制配置两套启动参数 TaoToken config.toml/settings.json 骨架3.1 硬件与软件基线压测环境统一如下两套引擎跑在同一台机器上分时启动避免显存争抢。项目配置GPUNVIDIA H200 141GB × 8CPUINTEL 8568Y × 2内存3 TB系统Ubuntu 22.04.5 LTS驱动NVIDIA Driver 550.54.15CUDA12.4NCCL2.21.5vLLM0.7.3SGLangv0.4.3.post2模型DeepSeek 671B 满血版路径 /data/DeepSeek-R13.2 vLLM 启动参数conda activate vllm vllm serve /data/DeepSeek-R1 \ --tensor-parallel-size 8 \ --max-model-len 16384 \ --port 8102 \ --trust-remote-code \ --served-model-name deepseek-r1 \ --enable-chunked-prefill \ --max-num-batched-tokens 2048 \ --gpu-memory-utilization 0.9关键参数说明--tensor-parallel-size 8对应 8 卡张量并行--max-model-len 16384限制上下文长度压测时统一用这个值--enable-chunked-prefill开启分块预填充对长 prompt 场景的显存峰值控制有帮助--max-num-batched-tokens 2048控制单批 token 上限直接影响吞吐和延迟的平衡--gpu-memory-utilization 0.9留 10% 显存给 KV Cache 动态增长。3.3 SGLang 启动参数conda activate sglang python -m sglang.launch_server \ --model /data/DeepSeek-R1 \ --trust-remote-code \ --tp 8 \ --mem-fraction-static 0.9 \ --host 0.0.0.0 \ --port 8102SGLang 的--tp 8同样是 8 卡张量并行--mem-fraction-static 0.9对应 vLLM 的 gpu-memory-utilization保持显存占用口径一致。注意 SGLang 默认的 RadixAttention 对前缀复用有优化压测时如果 prompt 有公共前缀它的首 token 延迟会明显受益这点在后面的数据里能看到。3.4 TaoToken config.toml 骨架如果你用 Python 客户端或 CLI 工具config.toml 可以这样写[default] api_key sk-your-taotoken-key base_url https://taotoken.net/api model deepseek-r1 timeout 600 [profiles.vllm] base_url http://127.0.0.1:8102/v1 model deepseek-r1 [profiles.sglang] base_url http://127.0.0.1:8102/v1 model deepseek-r1压测时通过 profile 切换 vLLM 和 SGLang其余参数不动。这样能保证两次压测的客户端行为完全一致。3.5 TaoToken settings.json 骨架如果你用 Node.js 或支持 settings.json 的工具链{ defaultProvider: taotoken, providers: { taotoken: { apiKey: sk-your-taotoken-key, baseUrl: https://taotoken.net/api, model: deepseek-r1, timeout: 600000 }, vllm-local: { apiKey: sk-your-taotoken-key, baseUrl: http://127.0.0.1:8102/v1, model: deepseek-r1 }, sglang-local: { apiKey: sk-your-taotoken-key, baseUrl: http://127.0.0.1:8102/v1, model: deepseek-r1 } } }提示本地引擎的 base_url 指向 127.0.0.1但 apiKey 仍用 TaoToken 的 Key这样压测脚本的鉴权路径和线上一致。如果你后续要把本地引擎挂到 TaoToken 网关后面只需要把 base_url 换成网关地址。4. 验证请求与压测EvalScope 脚本与成功结果4.1 安装 EvalScopepip install --upgrade pip pip install evalscope[app,perf] -UEvalScope 是魔搭社区出的评测与压测框架perf 模块专门做推理性能基准支持 OpenAI 兼容接口正好适配 vLLM 和 SGLang。4.2 先发一条验证请求压测前先用 curl 确认服务活着、模型名对得上curl http://127.0.0.1:8102/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-your-taotoken-key \ -d { model: deepseek-r1, messages: [{role: user, content: 用一句话说明什么是张量并行}], max_tokens: 64 }返回里有choices[0].message.content就说明服务正常。如果返回 404检查--served-model-name和请求里的 model 是否一致如果返回 401检查 Key 是否正确。4.3 压测脚本vLLM 和 SGLang 使用同一条压测命令只改 base_url 指向的端口。并发覆盖 128、256、512 三档evalscope perf \ --parallel 32 \ --url http://127.0.0.1:8102/v1/chat/completions \ --model deepseek-r1 \ --log-every-n-query 10 \ --connect-timeout 600 \ --read-timeout 600 \ --api openai \ --prompt 写一个科幻小说不少于2000字 \ -n 2048参数含义--parallel 32是初始并发建议从 GPU 卡数 × 4 起步8 卡就是 32--model必须和--served-model-name一致--log-every-n-query 10每 10 条请求打一次日志方便观察中间状态--connect-timeout 600和--read-timeout 600给足超时DeepSeek 671B 在 512 并发下延迟会到几百秒-n 2048是总请求数。要跑 128、256、512 三档并发把--parallel分别改成 128、256、512 重跑即可。建议每档之间等 30 秒让显存回收避免上一轮的 KV Cache 残留影响下一轮。4.4 成功结果长什么样压测跑完后EvalScope 会在终端输出汇总表同时在outputs/下生成结果数据库。关键指标包括指标含义Throughput (tokens/s)平均每秒处理 token 数越高越好Average latency (s)平均延迟越低越好Average TTFT (s)平均首 token 时间影响用户感知Average TPOT (s)每输出 token 耗时影响生成速度Succeed / Failed requests成功与失败请求数失败率要关注我实测下来256 并发时 vLLM 吞吐约 2373 tok/sSGLang 约 1661 tok/svLLM 高约 42.7%512 并发时 vLLM 约 2363 tok/sSGLang 提升到约 2247 tok/s差距缩到 5.2%但 SGLang 的延迟从 246s 涨到 327svLLM 保持在 246s 左右。首 token 时间上512 并发时 vLLM 约 246.39sSGLang 约 327.487svLLM 快约 24.7%。每 token 生成时间 vLLM 在所有并发档位都更快512 并发时约 0.156s 对 0.18s。这些数字说明vLLM 的 PagedAttention 在高并发突发请求下显存管理更稳吞吐衰减小SGLang 的 RadixAttention 在长上下文前缀复用场景有优势但短请求密集、并发拉满时延迟增长更明显。4.5 显存占用对比两套引擎都设了 0.9 的显存占用上限但实际 KV Cache 使用模式不同。vLLM 的 PagedAttention 把 KV Cache 分页管理显存碎片少512 并发下仍能维持吞吐SGLang 的 RadixAttention 对公共前缀做树状复用如果压测 prompt 有大量重复前缀显存效率会更高但本次压测用的是单一长 prompt前缀复用收益有限。你可以用nvidia-smi在压测过程中每 10 秒采样一次观察显存曲线。5. 本篇常见错排查5.1 启动时报显存不足DeepSeek 671B 满血版在 8 卡 H200 上权重占用约 1.3TB 显存FP8 量化后更低如果--gpu-memory-utilization或--mem-fraction-static设得过高KV Cache 没空间启动会 OOM。先把值降到 0.85 试跑通后再往上调。另外确认没有其他进程占着 GPU用nvidia-smi检查。5.2 压测请求全部超时最常见原因是--read-timeout设得太短。DeepSeek 671B 在 512 并发下单请求延迟可能到 300s 以上如果 timeout 只有 60s全部会失败。把--connect-timeout和--read-timeout都设到 600s。另外检查--max-model-len是否小于压测 prompt 的实际长度超长会被截断或报错。5.3 模型名不匹配返回 404vLLM 的--served-model-name和压测命令里的--model必须完全一致。SGLang 默认用模型路径作为模型名如果你在请求里写deepseek-r1但启动时没指定会 404。SGLang 可以用--served-model-name显式指定或者请求里直接用完整路径。5.4 TaoToken Key 鉴权失败检查 config.toml 或 settings.json 里的 api_key 是否带了sk-前缀base_url 是否指向https://taotoken.net/api。本地引擎的 base_url 是http://127.0.0.1:8102/v1注意末尾的/v1不能少。如果还是 401去 https://taotoken.net/api-keys 确认 Key 没过期、额度没用完。5.5 两套引擎端口冲突vLLM 和 SGLang 默认都用 8102如果同时启动会冲突。压测时建议分时启动或者给其中一个改端口比如 SGLang 用--port 8103压测脚本对应改 base_url。不要试图同时跑两套引擎做对比显存会互相挤占数据不可信。5.6 压测结果波动大如果两次压测同一引擎结果差很多检查GPU 温度是否触发降频、是否有其他进程占用显存、NCCL 通信是否正常。建议每轮压测前重启服务清空 KV Cache并在压测过程中用nvidia-smi dmon观察 GPU 利用率和温度。6. 选型建议与统一接入收尾压测数据摆出来后选型逻辑其实很清晰如果你的业务是高并发短请求为主比如在线客服、批量摘要vLLM 的吞吐优势和延迟稳定性更合适如果业务是长上下文、大量公共前缀的场景比如 RAG 检索后拼接长文档、多轮对话复用系统提示词SGLang 的 RadixAttention 能省显存、降首 token 延迟。两者没有绝对优劣关键看请求特征。统一接入这块TaoToken 的 Key 让两套引擎的压测和线上调用走同一套鉴权与路由逻辑切换引擎只需要改 base_url。如果你后续要做长期编码或 Agent 场景可以看 https://taotoken.net/coding-plan 的套餐需要管理多个 Key 和用量去 https://taotoken.net/console Claude Code 相关的接入配置在 https://taotoken.net/claudecode-anthropic 。压测脚本和 config 骨架可以直接复制到你的环境把模型路径和 Key 换成自己的就能跑。
生产环境H200部署DeepSeek 671B 满血版全流程实战（四）：vLLM 与 SGLang 的性能大比拼——TaoToken 统一 Key 接入与压测配置
1. 为什么要在 H200 上认真做一次 vLLM 与 SGLang 的对比DeepSeek 671B 满血版在 H200 上跑起来只是第一步真正上线生产时团队最常卡住的问题是同样 8 张 H200 141GBvLLM 和 SGLang 到底该选哪个我见过不少项目在测试环境用 vLLM 跑得挺顺切到线上高并发后吞吐掉得厉害也见过 SGLang 在长上下文场景里首 token 延迟表现更稳但短请求密集时反而不如 vLLM。这些差异不是靠感觉能判断的必须用统一的压测口径把吞吐、首 token 延迟、显存占用三项指标拉出来对比。这篇是 H200 部署 DeepSeek 671B 系列的第四篇前三篇分别搞定了系统初始化、vLLM 安装、SGLang 安装。现在两台引擎都能启动服务了接下来要解决的是选型问题。我会给出两套可直接复制的启动参数、TaoToken 统一 Key 的 config.toml 与 settings.json 骨架以及一套基于 EvalScope 的压测脚本。压测数据来自 8 卡 H200 单机环境并发覆盖 128、256、512 三档你可以按自己业务的请求特征对号入座。适合谁看已经在 H200 上部署了 DeepSeek 671B、正在做推理引擎选型的运维和算法工程同学或者准备把本地推理服务接入统一 API 网关、需要一套可复现压测流程的团队。如果你还没装好引擎建议先回看前三篇把 vLLM 0.7.3 和 SGLang v0.4.3.post2 的环境跑通再往下走。2. TaoToken 前置统一 Key 让两套引擎的压测口径一致做 vLLM 和 SGLang 对比时一个容易被忽略的变量是调用入口。如果 vLLM 走本地直连、SGLang 走另一套网关压测结果里的网络开销和鉴权逻辑就不一致吞吐差异会被污染。我的做法是两套引擎都通过 TaoToken 统一 Key 接入压测脚本只改 base_url 指向不同端口其余参数完全一致。TaoToken 在这里的角色是统一 API 网关你可以在控制台创建 Key然后在 config.toml 或 settings.json 里配置模型路由。这样 vLLM 的 8102 端口和 SGLang 的 8102 端口分时启动避免端口冲突都能被同一套客户端代码调用。压测时只需要切换 base_url不用改鉴权逻辑。先拿 Key访问 https://taotoken.net/api-keys 创建建议按环境分 Key压测用一个、生产用一个方便后续做用量隔离。接入文档在 https://taotoken.net/doc 里面有 OpenAI 兼容接口的完整说明。模型对话调试入口在 https://taotoken.net/model-chat 压测前可以先用它发一条请求确认 Key 和模型名对得上。注意TaoToken 的 Key 只用于统一接入和路由不改变 vLLM/SGLang 本身的推理行为。压测对比的是引擎性能网关层要保持配置一致否则数据不可比。3. 可复制配置两套启动参数 TaoToken config.toml/settings.json 骨架3.1 硬件与软件基线压测环境统一如下两套引擎跑在同一台机器上分时启动避免显存争抢。项目配置GPUNVIDIA H200 141GB × 8CPUINTEL 8568Y × 2内存3 TB系统Ubuntu 22.04.5 LTS驱动NVIDIA Driver 550.54.15CUDA12.4NCCL2.21.5vLLM0.7.3SGLangv0.4.3.post2模型DeepSeek 671B 满血版路径 /data/DeepSeek-R13.2 vLLM 启动参数conda activate vllm vllm serve /data/DeepSeek-R1 \ --tensor-parallel-size 8 \ --max-model-len 16384 \ --port 8102 \ --trust-remote-code \ --served-model-name deepseek-r1 \ --enable-chunked-prefill \ --max-num-batched-tokens 2048 \ --gpu-memory-utilization 0.9关键参数说明--tensor-parallel-size 8对应 8 卡张量并行--max-model-len 16384限制上下文长度压测时统一用这个值--enable-chunked-prefill开启分块预填充对长 prompt 场景的显存峰值控制有帮助--max-num-batched-tokens 2048控制单批 token 上限直接影响吞吐和延迟的平衡--gpu-memory-utilization 0.9留 10% 显存给 KV Cache 动态增长。3.3 SGLang 启动参数conda activate sglang python -m sglang.launch_server \ --model /data/DeepSeek-R1 \ --trust-remote-code \ --tp 8 \ --mem-fraction-static 0.9 \ --host 0.0.0.0 \ --port 8102SGLang 的--tp 8同样是 8 卡张量并行--mem-fraction-static 0.9对应 vLLM 的 gpu-memory-utilization保持显存占用口径一致。注意 SGLang 默认的 RadixAttention 对前缀复用有优化压测时如果 prompt 有公共前缀它的首 token 延迟会明显受益这点在后面的数据里能看到。3.4 TaoToken config.toml 骨架如果你用 Python 客户端或 CLI 工具config.toml 可以这样写[default] api_key sk-your-taotoken-key base_url https://taotoken.net/api model deepseek-r1 timeout 600 [profiles.vllm] base_url http://127.0.0.1:8102/v1 model deepseek-r1 [profiles.sglang] base_url http://127.0.0.1:8102/v1 model deepseek-r1压测时通过 profile 切换 vLLM 和 SGLang其余参数不动。这样能保证两次压测的客户端行为完全一致。3.5 TaoToken settings.json 骨架如果你用 Node.js 或支持 settings.json 的工具链{ defaultProvider: taotoken, providers: { taotoken: { apiKey: sk-your-taotoken-key, baseUrl: https://taotoken.net/api, model: deepseek-r1, timeout: 600000 }, vllm-local: { apiKey: sk-your-taotoken-key, baseUrl: http://127.0.0.1:8102/v1, model: deepseek-r1 }, sglang-local: { apiKey: sk-your-taotoken-key, baseUrl: http://127.0.0.1:8102/v1, model: deepseek-r1 } } }提示本地引擎的 base_url 指向 127.0.0.1但 apiKey 仍用 TaoToken 的 Key这样压测脚本的鉴权路径和线上一致。如果你后续要把本地引擎挂到 TaoToken 网关后面只需要把 base_url 换成网关地址。4. 验证请求与压测EvalScope 脚本与成功结果4.1 安装 EvalScopepip install --upgrade pip pip install evalscope[app,perf] -UEvalScope 是魔搭社区出的评测与压测框架perf 模块专门做推理性能基准支持 OpenAI 兼容接口正好适配 vLLM 和 SGLang。4.2 先发一条验证请求压测前先用 curl 确认服务活着、模型名对得上curl http://127.0.0.1:8102/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-your-taotoken-key \ -d { model: deepseek-r1, messages: [{role: user, content: 用一句话说明什么是张量并行}], max_tokens: 64 }返回里有choices[0].message.content就说明服务正常。如果返回 404检查--served-model-name和请求里的 model 是否一致如果返回 401检查 Key 是否正确。4.3 压测脚本vLLM 和 SGLang 使用同一条压测命令只改 base_url 指向的端口。并发覆盖 128、256、512 三档evalscope perf \ --parallel 32 \ --url http://127.0.0.1:8102/v1/chat/completions \ --model deepseek-r1 \ --log-every-n-query 10 \ --connect-timeout 600 \ --read-timeout 600 \ --api openai \ --prompt 写一个科幻小说不少于2000字 \ -n 2048参数含义--parallel 32是初始并发建议从 GPU 卡数 × 4 起步8 卡就是 32--model必须和--served-model-name一致--log-every-n-query 10每 10 条请求打一次日志方便观察中间状态--connect-timeout 600和--read-timeout 600给足超时DeepSeek 671B 在 512 并发下延迟会到几百秒-n 2048是总请求数。要跑 128、256、512 三档并发把--parallel分别改成 128、256、512 重跑即可。建议每档之间等 30 秒让显存回收避免上一轮的 KV Cache 残留影响下一轮。4.4 成功结果长什么样压测跑完后EvalScope 会在终端输出汇总表同时在outputs/下生成结果数据库。关键指标包括指标含义Throughput (tokens/s)平均每秒处理 token 数越高越好Average latency (s)平均延迟越低越好Average TTFT (s)平均首 token 时间影响用户感知Average TPOT (s)每输出 token 耗时影响生成速度Succeed / Failed requests成功与失败请求数失败率要关注我实测下来256 并发时 vLLM 吞吐约 2373 tok/sSGLang 约 1661 tok/svLLM 高约 42.7%512 并发时 vLLM 约 2363 tok/sSGLang 提升到约 2247 tok/s差距缩到 5.2%但 SGLang 的延迟从 246s 涨到 327svLLM 保持在 246s 左右。首 token 时间上512 并发时 vLLM 约 246.39sSGLang 约 327.487svLLM 快约 24.7%。每 token 生成时间 vLLM 在所有并发档位都更快512 并发时约 0.156s 对 0.18s。这些数字说明vLLM 的 PagedAttention 在高并发突发请求下显存管理更稳吞吐衰减小SGLang 的 RadixAttention 在长上下文前缀复用场景有优势但短请求密集、并发拉满时延迟增长更明显。4.5 显存占用对比两套引擎都设了 0.9 的显存占用上限但实际 KV Cache 使用模式不同。vLLM 的 PagedAttention 把 KV Cache 分页管理显存碎片少512 并发下仍能维持吞吐SGLang 的 RadixAttention 对公共前缀做树状复用如果压测 prompt 有大量重复前缀显存效率会更高但本次压测用的是单一长 prompt前缀复用收益有限。你可以用nvidia-smi在压测过程中每 10 秒采样一次观察显存曲线。5. 本篇常见错排查5.1 启动时报显存不足DeepSeek 671B 满血版在 8 卡 H200 上权重占用约 1.3TB 显存FP8 量化后更低如果--gpu-memory-utilization或--mem-fraction-static设得过高KV Cache 没空间启动会 OOM。先把值降到 0.85 试跑通后再往上调。另外确认没有其他进程占着 GPU用nvidia-smi检查。5.2 压测请求全部超时最常见原因是--read-timeout设得太短。DeepSeek 671B 在 512 并发下单请求延迟可能到 300s 以上如果 timeout 只有 60s全部会失败。把--connect-timeout和--read-timeout都设到 600s。另外检查--max-model-len是否小于压测 prompt 的实际长度超长会被截断或报错。5.3 模型名不匹配返回 404vLLM 的--served-model-name和压测命令里的--model必须完全一致。SGLang 默认用模型路径作为模型名如果你在请求里写deepseek-r1但启动时没指定会 404。SGLang 可以用--served-model-name显式指定或者请求里直接用完整路径。5.4 TaoToken Key 鉴权失败检查 config.toml 或 settings.json 里的 api_key 是否带了sk-前缀base_url 是否指向https://taotoken.net/api。本地引擎的 base_url 是http://127.0.0.1:8102/v1注意末尾的/v1不能少。如果还是 401去 https://taotoken.net/api-keys 确认 Key 没过期、额度没用完。5.5 两套引擎端口冲突vLLM 和 SGLang 默认都用 8102如果同时启动会冲突。压测时建议分时启动或者给其中一个改端口比如 SGLang 用--port 8103压测脚本对应改 base_url。不要试图同时跑两套引擎做对比显存会互相挤占数据不可信。5.6 压测结果波动大如果两次压测同一引擎结果差很多检查GPU 温度是否触发降频、是否有其他进程占用显存、NCCL 通信是否正常。建议每轮压测前重启服务清空 KV Cache并在压测过程中用nvidia-smi dmon观察 GPU 利用率和温度。6. 选型建议与统一接入收尾压测数据摆出来后选型逻辑其实很清晰如果你的业务是高并发短请求为主比如在线客服、批量摘要vLLM 的吞吐优势和延迟稳定性更合适如果业务是长上下文、大量公共前缀的场景比如 RAG 检索后拼接长文档、多轮对话复用系统提示词SGLang 的 RadixAttention 能省显存、降首 token 延迟。两者没有绝对优劣关键看请求特征。统一接入这块TaoToken 的 Key 让两套引擎的压测和线上调用走同一套鉴权与路由逻辑切换引擎只需要改 base_url。如果你后续要做长期编码或 Agent 场景可以看 https://taotoken.net/coding-plan 的套餐需要管理多个 Key 和用量去 https://taotoken.net/console Claude Code 相关的接入配置在 https://taotoken.net/claudecode-anthropic 。压测脚本和 config 骨架可以直接复制到你的环境把模型路径和 Key 换成自己的就能跑。
、model.eval()、torch.no_grad()与detach()：PyTorch训练/推理模式配置避坑指南)
