1. 为什么 Day20 要专门验证 MoE 推理链路走到 32 天 GPU 测试计划的第 20 天前面已经把单卡环境、驱动、CUDA、显存监控这些基础动作跑顺了。今天要面对的是 DeepSeek 这类 MoE 模型在 vLLM 上的推理验证。它和普通稠密模型最大的不同在于模型总参数量很大但每个 token 只激活一部分专家所以你会看到显存占用高、但计算量并没有同规模稠密模型那么夸张。这个特性决定了测试重点不是单纯看“能不能加载”而是要看专家路由是否正常、KV Cache 是否按预期分配、请求返回是否稳定。我这次的目标很明确用一套统一的 Key 管理方式把本地 vLLM 服务和远端模型调用串起来避免在多个脚本里散落不同的鉴权配置。TaoToken 在这里扮演的是统一入口的角色它提供 OpenAI 兼容的 API 形态本地 vLLM 也可以用同样的请求格式去验证。这样 Day20 的验证动作就可以拆成两段先确认本地 GPU 上 vLLM 能把 DeepSeek MoE 跑起来再用统一 Key 发一次真实推理请求确认整条链路可用。适合跟着做的人已经在做 GPU 测试计划、手里有至少一张能跑得动 MoE 量化版的卡、并且希望把本地推理和统一 Key 管理结合起来的读者。如果你还在纯 CPU 阶段这篇的 vLLM 启动部分可以先看配置结构等卡到位再实操。2. TaoToken 前置统一 Key 与 settings.json/config.toml 骨架在开始写 vLLM 启动命令之前先把 Key 管理这块理清楚。很多人的测试脚本里会硬编码 base_url 和 api_key换一个模型就要改一次时间久了根本记不住哪个脚本对应哪个服务。TaoToken 的做法是给你一个统一的 API 入口模型对话、coding plan、console、api-keys 这些能力都挂在同一套账号体系下。你可以在 console 里创建 Key然后在不同工具里复用。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。注意 API 地址后面不加 UTM 参数保持干净。创建 Key 的页面在 api-keys 路径下模型对话在对应 deep link 里可以直接试。下面给两份配置骨架。第一份是给支持 settings.json 的编辑器或客户端用的第二份是给支持 config.toml 的工具用的。两份都只保留必要字段方便你复制后改。{ provider: taotoken, base_url: https://taotoken.net/api, api_key: sk-你的Key, default_model: deepseek-chat, timeout: 120, max_retries: 2 }[provider] name taotoken base_url https://taotoken.net/api api_key sk-你的Key default_model deepseek-chat timeout 120 max_retries 2 [logging] level info注意api_key 不要提交到公开仓库。测试阶段可以用环境变量覆盖比如在 shell 里 export TAOTOKEN_API_KEYsk-xxx然后在配置里引用。这两份骨架的作用是让本地 vLLM 验证脚本和远端调用共用同一套鉴权信息。你不需要在 vLLM 启动命令里塞 Key因为 vLLM 本地服务默认不校验但你的验证客户端需要 Key 去请求 TaoToken 的模型对话接口。这样分工清晰vLLM 负责本地 GPU 推理TaoToken 负责统一入口和远端模型对照。3. 可复制配置vLLM 启动 DeepSeek MoE 的完整命令现在进入实操部分。假设你已经把 DeepSeek 的 MoE 权重下载到本地路径是 /data/models/DeepSeek-V2-Lite 这类结构。vLLM 对 MoE 的支持需要较新版本建议先确认版本号。python3 -c import vllm; print(vllm.__version__)如果低于 0.6.x建议先升级。升级命令pip install -U vllm接下来是启动命令。这里用 DeepSeek-V2-Lite 作为示例它的激活参数较小单卡 24G 显存可以跑量化版。如果你用的是更大的 MoE 权重把 tensor-parallel-size 调大。python3 -m vllm.entrypoints.openai.api_server \ --model /data/models/DeepSeek-V2-Lite \ --served-model-name deepseek-moe \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.90 \ --enable-chunked-prefill \ --trust-remote-code \ --dtype auto参数逐个说明。--model 指向本地权重目录不要写成 HuggingFace 仓库名除非你确认网络能拉取。--served-model-name 是请求时用的模型名后面验证脚本里要一致。--tensor-parallel-size 在单卡时是 1多卡时按卡数设置。--max-model-len 先设小一点8192 足够验证等稳定后再往上调。--gpu-memory-utilization 0.90 表示允许 vLLM 占用 90% 显存MoE 模型加载后显存占用会比较高这个值不要设太满。--enable-chunked-prefill 对长输入有帮助。--trust-remote-code 在加载自定义模型结构时需要。启动后你会看到类似下面的日志片段INFO loading model weights... INFO MoE model detected, using expert parallelism INFO KV cache size: 4.2 GiB INFO Uvicorn running on http://0.0.0.0:8000看到 Uvicorn running 就说明服务起来了。如果卡在 loading weights 很久先检查磁盘 IO 和显存是否足够。MoE 权重文件通常很大加载时间比稠密模型长。4. 验证请求一次完整的推理动作与成功结果服务起来后先做本地健康检查确认 vLLM 的 OpenAI 兼容接口能响应。curl -s http://localhost:8000/v1/models | python3 -m json.tool返回里应该能看到 deepseek-moe 这个模型名。接下来发一次真实推理请求。这里用 Python 脚本同时演示如何用 TaoToken 的统一 Key 做远端对照。import os import requests LOCAL_URL http://localhost:8000/v1/chat/completions REMOTE_URL https://taotoken.net/api/v1/chat/completions API_KEY os.environ.get(TAOTOKEN_API_KEY, sk-你的Key) def ask(url, model, keyNone): headers {Content-Type: application/json} if key: headers[Authorization] fBearer {key} payload { model: model, messages: [ {role: user, content: 用一句话说明 MoE 模型推理时为什么激活参数少。} ], max_tokens: 128, temperature: 0.3 } resp requests.post(url, jsonpayload, headersheaders, timeout120) resp.raise_for_status() data resp.json() return data[choices][0][message][content] if __name__ __main__: print( 本地 vLLM ) print(ask(LOCAL_URL, deepseek-moe)) print( TaoToken 远端 ) print(ask(REMOTE_URL, deepseek-chat, API_KEY))运行前先设置环境变量export TAOTOKEN_API_KEYsk-你的Key python3 verify_moe.py成功结果会打印两段回答。本地 vLLM 返回的内容来自你 GPU 上的 MoE 权重远端返回的内容来自 TaoToken 统一入口。两段都能正常输出就说明 Day20 的验证目标达成本地 MoE 推理链路可用统一 Key 也能正常调用。如果你只想验证本地可以把远端那段注释掉。但建议保留因为对照能帮你判断问题出在本地服务还是 Key 配置。5. 本篇常见错排查第一个常见错是启动时报 “MoE model requires expert parallelism” 或类似提示。这通常是因为 vLLM 版本太旧或者 tensor-parallel-size 和专家数不匹配。先升级 vLLM再把 tensor-parallel-size 设成能整除专家数的值。DeepSeek-V2-Lite 的专家数较小单卡一般没问题。第二个错是请求返回 400提示 model not found。检查 --served-model-name 和请求里的 model 字段是否完全一致。大小写和连字符都要对上。第三个错是显存不足日志里出现 CUDA out of memory。先把 --max-model-len 降到 4096再把 --gpu-memory-utilization 降到 0.85。如果还是不够考虑用量化版权重或者换更小的 MoE 模型做验证。第四个错是远端请求返回 401。检查 TAOTOKEN_API_KEY 是否设置正确以及请求头里 Authorization 的格式是不是 Bearer 加空格加 Key。可以到 api-keys 页面重新确认 Key 状态。第五个错是本地请求超时。MoE 模型首次推理会有编译和专家路由初始化耗时比后续请求长。把 timeout 设到 120 秒以上或者先发一个短请求预热。提示排查时先看 vLLM 服务端日志再看客户端报错。服务端日志里通常有更具体的堆栈信息。6. 后续怎么接从验证到长期编码与 AgentDay20 的验证动作完成后你手里应该有一套能跑的本地 vLLM MoE 服务和一份统一 Key 配置。接下来如果要把这套东西用到长期编码或 Agent 场景建议把 Key 管理固定下来不要每次手动 export。TaoToken 的 coding plan 路径适合这种长期使用模型对话路径适合临时验证不同模型。接入文档在 doc 路径下里面有完整的请求格式和参数说明。如果你用的是 Claude Code 这类工具ClaudeCodeAnthropic 路径下有对应的配置说明。API Keys 管理在 api-keys 路径console 路径可以看用量和状态。我自己的做法是把 settings.json 放在项目根目录用环境变量注入 Key然后 vLLM 启动脚本单独放一个 shell 文件。这样换模型时只改配置不动代码。MoE 模型的验证重点始终是专家路由和显存只要这两块稳定后面的吞吐测试和长上下文测试就可以按计划推进。
1. 为什么 Day20 要专门验证 MoE 推理链路走到 32 天 GPU 测试计划的第 20 天前面已经把单卡环境、驱动、CUDA、显存监控这些基础动作跑顺了。今天要面对的是 DeepSeek 这类 MoE 模型在 vLLM 上的推理验证。它和普通稠密模型最大的不同在于模型总参数量很大但每个 token 只激活一部分专家所以你会看到显存占用高、但计算量并没有同规模稠密模型那么夸张。这个特性决定了测试重点不是单纯看“能不能加载”而是要看专家路由是否正常、KV Cache 是否按预期分配、请求返回是否稳定。我这次的目标很明确用一套统一的 Key 管理方式把本地 vLLM 服务和远端模型调用串起来避免在多个脚本里散落不同的鉴权配置。TaoToken 在这里扮演的是统一入口的角色它提供 OpenAI 兼容的 API 形态本地 vLLM 也可以用同样的请求格式去验证。这样 Day20 的验证动作就可以拆成两段先确认本地 GPU 上 vLLM 能把 DeepSeek MoE 跑起来再用统一 Key 发一次真实推理请求确认整条链路可用。适合跟着做的人已经在做 GPU 测试计划、手里有至少一张能跑得动 MoE 量化版的卡、并且希望把本地推理和统一 Key 管理结合起来的读者。如果你还在纯 CPU 阶段这篇的 vLLM 启动部分可以先看配置结构等卡到位再实操。2. TaoToken 前置统一 Key 与 settings.json/config.toml 骨架在开始写 vLLM 启动命令之前先把 Key 管理这块理清楚。很多人的测试脚本里会硬编码 base_url 和 api_key换一个模型就要改一次时间久了根本记不住哪个脚本对应哪个服务。TaoToken 的做法是给你一个统一的 API 入口模型对话、coding plan、console、api-keys 这些能力都挂在同一套账号体系下。你可以在 console 里创建 Key然后在不同工具里复用。官网地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。注意 API 地址后面不加 UTM 参数保持干净。创建 Key 的页面在 api-keys 路径下模型对话在对应 deep link 里可以直接试。下面给两份配置骨架。第一份是给支持 settings.json 的编辑器或客户端用的第二份是给支持 config.toml 的工具用的。两份都只保留必要字段方便你复制后改。{ provider: taotoken, base_url: https://taotoken.net/api, api_key: sk-你的Key, default_model: deepseek-chat, timeout: 120, max_retries: 2 }[provider] name taotoken base_url https://taotoken.net/api api_key sk-你的Key default_model deepseek-chat timeout 120 max_retries 2 [logging] level info注意api_key 不要提交到公开仓库。测试阶段可以用环境变量覆盖比如在 shell 里 export TAOTOKEN_API_KEYsk-xxx然后在配置里引用。这两份骨架的作用是让本地 vLLM 验证脚本和远端调用共用同一套鉴权信息。你不需要在 vLLM 启动命令里塞 Key因为 vLLM 本地服务默认不校验但你的验证客户端需要 Key 去请求 TaoToken 的模型对话接口。这样分工清晰vLLM 负责本地 GPU 推理TaoToken 负责统一入口和远端模型对照。3. 可复制配置vLLM 启动 DeepSeek MoE 的完整命令现在进入实操部分。假设你已经把 DeepSeek 的 MoE 权重下载到本地路径是 /data/models/DeepSeek-V2-Lite 这类结构。vLLM 对 MoE 的支持需要较新版本建议先确认版本号。python3 -c import vllm; print(vllm.__version__)如果低于 0.6.x建议先升级。升级命令pip install -U vllm接下来是启动命令。这里用 DeepSeek-V2-Lite 作为示例它的激活参数较小单卡 24G 显存可以跑量化版。如果你用的是更大的 MoE 权重把 tensor-parallel-size 调大。python3 -m vllm.entrypoints.openai.api_server \ --model /data/models/DeepSeek-V2-Lite \ --served-model-name deepseek-moe \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.90 \ --enable-chunked-prefill \ --trust-remote-code \ --dtype auto参数逐个说明。--model 指向本地权重目录不要写成 HuggingFace 仓库名除非你确认网络能拉取。--served-model-name 是请求时用的模型名后面验证脚本里要一致。--tensor-parallel-size 在单卡时是 1多卡时按卡数设置。--max-model-len 先设小一点8192 足够验证等稳定后再往上调。--gpu-memory-utilization 0.90 表示允许 vLLM 占用 90% 显存MoE 模型加载后显存占用会比较高这个值不要设太满。--enable-chunked-prefill 对长输入有帮助。--trust-remote-code 在加载自定义模型结构时需要。启动后你会看到类似下面的日志片段INFO loading model weights... INFO MoE model detected, using expert parallelism INFO KV cache size: 4.2 GiB INFO Uvicorn running on http://0.0.0.0:8000看到 Uvicorn running 就说明服务起来了。如果卡在 loading weights 很久先检查磁盘 IO 和显存是否足够。MoE 权重文件通常很大加载时间比稠密模型长。4. 验证请求一次完整的推理动作与成功结果服务起来后先做本地健康检查确认 vLLM 的 OpenAI 兼容接口能响应。curl -s http://localhost:8000/v1/models | python3 -m json.tool返回里应该能看到 deepseek-moe 这个模型名。接下来发一次真实推理请求。这里用 Python 脚本同时演示如何用 TaoToken 的统一 Key 做远端对照。import os import requests LOCAL_URL http://localhost:8000/v1/chat/completions REMOTE_URL https://taotoken.net/api/v1/chat/completions API_KEY os.environ.get(TAOTOKEN_API_KEY, sk-你的Key) def ask(url, model, keyNone): headers {Content-Type: application/json} if key: headers[Authorization] fBearer {key} payload { model: model, messages: [ {role: user, content: 用一句话说明 MoE 模型推理时为什么激活参数少。} ], max_tokens: 128, temperature: 0.3 } resp requests.post(url, jsonpayload, headersheaders, timeout120) resp.raise_for_status() data resp.json() return data[choices][0][message][content] if __name__ __main__: print( 本地 vLLM ) print(ask(LOCAL_URL, deepseek-moe)) print( TaoToken 远端 ) print(ask(REMOTE_URL, deepseek-chat, API_KEY))运行前先设置环境变量export TAOTOKEN_API_KEYsk-你的Key python3 verify_moe.py成功结果会打印两段回答。本地 vLLM 返回的内容来自你 GPU 上的 MoE 权重远端返回的内容来自 TaoToken 统一入口。两段都能正常输出就说明 Day20 的验证目标达成本地 MoE 推理链路可用统一 Key 也能正常调用。如果你只想验证本地可以把远端那段注释掉。但建议保留因为对照能帮你判断问题出在本地服务还是 Key 配置。5. 本篇常见错排查第一个常见错是启动时报 “MoE model requires expert parallelism” 或类似提示。这通常是因为 vLLM 版本太旧或者 tensor-parallel-size 和专家数不匹配。先升级 vLLM再把 tensor-parallel-size 设成能整除专家数的值。DeepSeek-V2-Lite 的专家数较小单卡一般没问题。第二个错是请求返回 400提示 model not found。检查 --served-model-name 和请求里的 model 字段是否完全一致。大小写和连字符都要对上。第三个错是显存不足日志里出现 CUDA out of memory。先把 --max-model-len 降到 4096再把 --gpu-memory-utilization 降到 0.85。如果还是不够考虑用量化版权重或者换更小的 MoE 模型做验证。第四个错是远端请求返回 401。检查 TAOTOKEN_API_KEY 是否设置正确以及请求头里 Authorization 的格式是不是 Bearer 加空格加 Key。可以到 api-keys 页面重新确认 Key 状态。第五个错是本地请求超时。MoE 模型首次推理会有编译和专家路由初始化耗时比后续请求长。把 timeout 设到 120 秒以上或者先发一个短请求预热。提示排查时先看 vLLM 服务端日志再看客户端报错。服务端日志里通常有更具体的堆栈信息。6. 后续怎么接从验证到长期编码与 AgentDay20 的验证动作完成后你手里应该有一套能跑的本地 vLLM MoE 服务和一份统一 Key 配置。接下来如果要把这套东西用到长期编码或 Agent 场景建议把 Key 管理固定下来不要每次手动 export。TaoToken 的 coding plan 路径适合这种长期使用模型对话路径适合临时验证不同模型。接入文档在 doc 路径下里面有完整的请求格式和参数说明。如果你用的是 Claude Code 这类工具ClaudeCodeAnthropic 路径下有对应的配置说明。API Keys 管理在 api-keys 路径console 路径可以看用量和状态。我自己的做法是把 settings.json 放在项目根目录用环境变量注入 Key然后 vLLM 启动脚本单独放一个 shell 文件。这样换模型时只改配置不动代码。MoE 模型的验证重点始终是专家路由和显存只要这两块稳定后面的吞吐测试和长上下文测试就可以按计划推进。
