多模型统一工作台：DeepSeek、Qwen、GLM 两行配置搞定

1. 为什么要把三个大模型塞进同一个工作台我平时写代码、查资料、做技术方案手头同时开着 DeepSeek、Qwen、GLM 三个网页标签是常态。DeepSeek 推理强、写代码逻辑清晰Qwen 中文理解细腻、长文本处理稳GLM 在工具调用和结构化输出上有自己的优势。问题是每次切换都要重新登录、重新贴上下文一天下来光在三个页面之间复制粘贴就能耗掉半小时。后来我琢磨着搭一个统一的 AI 工作台把这三个模型的 API 全部接进来用一个界面调度。核心诉求很简单同一个输入框能自由切换模型或者让多个模型同时回答同一个问题做对比。听起来像是要写不少代码但实际动手之后发现真正需要改的配置只有两行——一行是模型列表的注册一行是路由分发的映射。剩下的工作都是围绕这两行配置做的外围适配。这篇文章适合两类人看一类是手头有多个模型 API Key、想统一管理但不想折腾复杂框架的开发者另一类是刚接触多模型调度、想找一个最小可行方案入门的同学。我会把整个搭建过程拆开讲清楚包括为什么这么选、每一步在做什么、哪些地方容易踩坑。代码量不大但背后的思路值得说透。提示本文涉及的所有 API 调用均基于各平台公开的标准接口规范不涉及任何非官方渠道。请确保你的使用方式符合各平台的服务条款。2. 工作台的整体设计与技术选型2.1 核心架构一个路由层加三个适配器整个工作台的结构可以类比成一个翻译中转站。用户在前端输入一句话路由层负责判断这句话该发给哪个模型适配器负责把统一的请求格式翻译成各个模型 API 能听懂的格式拿到响应之后再翻译回统一格式返回给前端。为什么要在中间加一层适配器而不是直接在前端调三个不同的 API原因有三个。第一前端不需要知道每个模型的 API 长什么样切换模型只是换一个参数值不用改调用逻辑。第二后续加新模型只需要写一个新的适配器前端代码一行不用动。第三统一格式之后可以做很多有意思的事情比如同时发给三个模型做结果对比、根据问题类型自动路由到最合适的模型、做失败重试和降级。适配器模式在这里的价值就像旅行时带了一个万能转换插头。你不用管每个国家的插座是什么形状只需要把插头换成对应的头子就行。2.2 技术栈选择为什么不用现成的框架市面上确实有一些多模型调度的开源框架功能很全但我最后选择了自己用 Node.js 写一个轻量级的服务。原因很实际现成框架的抽象层太厚出了问题排查起来很痛苦。我之前用过一个框架一个简单的 API 调用报错追了五层封装才找到真正的原因——是某个模型对temperature参数的取值范围要求不同。自己写的好处是每一行代码都在掌控之中。整个服务核心代码不到 200 行用 Express 做 HTTP 服务用原生的fetch发请求不引入任何额外的 HTTP 客户端库。Node.js 版本建议用 18 以上因为 18 开始原生支持fetch不需要再装node-fetch或者axios。如果你更熟悉 Python用 FastAPI 也是完全一样的效果思路不变。我选 Node.js 纯粹是因为前端也是 JS前后端可以共享一些类型定义和工具函数省得两边维护两套。2.3 配置文件的设计两行核心配置长什么样标题里说的只改两行配置具体是指这两个地方。第一行是模型注册表定义有哪些模型可用、各自的 API 地址和 Key 从哪里读const MODELS { deepseek: { baseUrl: https://api.deepseek.com/v1, key: process.env.DEEPSEEK_KEY, model: deepseek-chat }, qwen: { baseUrl: https://dashscope.aliyuncs.com/compatible-mode/v1, key: process.env.QWEN_KEY, model: qwen-plus }, glm: { baseUrl: https://open.bigmodel.cn/api/paas/v4, key: process.env.GLM_KEY, model: glm-4 }, };第二行是路由映射表定义什么情况下用哪个模型const ROUTE_MAP { code: deepseek, longtext: qwen, tool: glm, default: deepseek };这两行配置之所以能撑起整个工作台是因为它们把有哪些模型和怎么选模型这两个最常变的东西抽出来了。加一个新模型在MODELS里加一行调整路由策略改ROUTE_MAP里的映射关系。其他代码都是通用的不需要动。注意API Key 千万不要硬编码在代码里也不要在前端暴露。用环境变量读取是最基本的做法如果部署在服务器上建议配合密钥管理服务使用。3. 核心细节解析与实操要点3.1 统一请求格式的设计三个模型的 API 虽然都兼容 OpenAI 的接口规范但细节上还是有差异。比如 DeepSeek 的deepseek-chat模型对temperature的默认值是 1.0Qwen 的qwen-plus默认是 0.7GLM 的glm-4默认是 0.95。如果不做统一前端每次切换模型都要手动调整参数体验很差。我的做法是定义一个内部的统一请求格式然后在适配器里做转换// 统一请求格式 { model: deepseek, // 目标模型标识 messages: [...], // 对话历史 temperature: 0.7, // 统一默认值 max_tokens: 2048, stream: false }适配器拿到这个格式之后根据目标模型做三件事替换model字段为各平台的实际模型名、补充各平台特有的必填参数、调整参数取值范围。比如 GLM 的max_tokens上限和其他两家不同如果用户传了一个超限的值适配器会自动截断到上限并记录一条警告日志。这里有个容易忽略的点消息角色的命名。OpenAI 规范里角色是system、user、assistant但有些模型对system消息的位置有要求必须放在最前面。适配器里加一个简单的排序逻辑就能解决成本很低但能避免很多莫名其妙的报错。3.2 流式输出的统一处理流式输出是多模型工作台体验的关键。三个模型都支持 SSE 格式的流式返回但事件格式有细微差别。DeepSeek 和 Qwen 的格式基本一致GLM 在某些情况下会多返回一个usage字段。处理流式响应的核心逻辑是逐块读取、解析 JSON、提取增量内容、转发给前端。这里要注意的是SSE 的数据块不一定按行完整到达可能一个 JSON 对象被拆成两个 TCP 包。所以不能简单地按行分割要维护一个缓冲区遇到不完整的数据先存着等下一个块到了再拼接。let buffer ; for await (const chunk of response.body) { buffer chunk.toString(); const lines buffer.split(\n); buffer lines.pop(); // 最后一行可能不完整留到下次 for (const line of lines) { if (line.startsWith(data: )) { const data line.slice(6); if (data [DONE]) continue; try { const parsed JSON.parse(data); const content parsed.choices?.[0]?.delta?.content; if (content) res.write(data: ${JSON.stringify({ content })}\n\n); } catch (e) { /* 忽略解析失败的不完整块 */ } } } }这段代码我调了大概两个小时才稳定下来。最开始没加缓冲区偶尔会出现 JSON 解析失败导致整个流中断的情况。加了缓冲区之后连续跑了几天没有再出现类似问题。3.3 错误处理与降级策略多模型工作台的一个隐藏价值是可以做自动降级。比如你默认用 DeepSeek但它偶尔会因为负载高返回 503这时候自动切换到 Qwen 重试用户几乎无感知。实现思路是在适配器外面包一层重试逻辑async function callWithFallback(modelId, request, retries 2) { const fallbackChain [modelId, ...ROUTE_MAP.fallback]; for (const id of fallbackChain) { try { return await adapters[id].call(request); } catch (err) { if (err.status 429 || err.status 500) continue; throw err; // 参数错误之类的直接抛不重试 } } throw new Error(所有模型均不可用); }这里的关键判断是哪些错误值得重试。429限流和 5xx服务端错误值得换模型重试400参数错误和 401鉴权失败换模型也没用直接抛给用户更快。这个区分能避免无意义的等待。提示降级链不要设太长两到三个就够了。链太长会导致用户等待时间过久体验反而更差。4. 完整实操流程与关键环节实现4.1 环境准备与项目初始化先把基础环境搭起来。Node.js 建议用 18 LTS 或更高版本用nvm管理版本最省心。初始化项目mkdir ai-workbench cd ai-workbench npm init -y npm install express dotenv只需要两个依赖express做 HTTP 服务dotenv读取环境变量。不需要装 CORS 中间件因为前端我直接用一个静态 HTML 文件同源部署省去跨域配置的麻烦。创建.env文件存放密钥DEEPSEEK_KEYsk-xxxxxxxx QWEN_KEYsk-xxxxxxxx GLM_KEYxxxxxxxx.xxxxxxxx PORT3000.env文件一定要加到.gitignore里这个不用多说了。我见过不止一个项目因为把 Key 提交到仓库导致被盗刷的案例。4.2 适配器层的具体实现适配器层的核心是一个统一的接口定义每个模型实现自己的call方法。以 DeepSeek 为例const deepseekAdapter { async call(req) { const body { model: MODELS.deepseek.model, messages: normalizeMessages(req.messages), temperature: clamp(req.temperature ?? 0.7, 0, 2), max_tokens: Math.min(req.max_tokens ?? 2048, 8192), stream: req.stream ?? false, }; const resp await fetch(${MODELS.deepseek.baseUrl}/chat/completions, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${MODELS.deepseek.key}, }, body: JSON.stringify(body), }); if (!resp.ok) { const err new Error(DeepSeek API error: ${resp.status}); err.status resp.status; throw err; } return resp; } };Qwen 和 GLM 的适配器结构完全一样区别只在baseUrl、model名称和参数范围。Qwen 的temperature范围是 0 到 2GLM 是 0 到 1所以clamp函数需要根据模型动态调整上限。这个细节如果不处理传一个 1.5 给 GLM 会直接报参数错误。normalizeMessages函数负责把消息数组标准化确保system消息在最前面、过滤掉空内容的消息、把过长的历史消息做截断。截断策略我采用的是保留最近 10 轮对话加上第一条system消息超出部分丢弃。这个策略对大多数场景够用了如果做长文档问答需要另外处理。4.3 路由层的分发逻辑路由层要做的事情是根据请求内容判断该用哪个模型。最简单的实现是让用户手动指定但既然叫工作台自动路由才是加分项。我的路由策略基于关键词匹配加规则判断function routeRequest(messages) { const lastUserMsg messages.filter(m m.role user).pop()?.content || ; if (/代码|函数|debug|报错|实现/.test(lastUserMsg)) return deepseek; if (/总结|翻译|改写|长文/.test(lastUserMsg)) return qwen; if (/调用|工具|结构化|JSON/.test(lastUserMsg)) return glm; return ROUTE_MAP.default; }这个规则很粗糙但实际用下来命中率还不错。因为大多数时候用户的问题类型是明确的——写代码就是写代码做总结就是做总结。如果你想要更智能的路由可以先用一个轻量模型做意图分类再分发到对应的模型。不过那样会增加一次 API 调用延迟会上去看你怎么权衡。路由结果会返回给前端显示用户可以手动覆盖。这个设计很重要——自动路由是辅助最终决定权在用户手里。我自己的习惯是默认自动但遇到重要问题会手动切到最信任的模型再问一遍。4.4 前端界面的最小实现前端我用的就是一个单 HTML 文件没有上框架。核心是一个输入框、一个模型选择下拉、一个对话展示区。模型选择下拉里除了三个具体模型还有一个自动选项对应路由层的自动判断。发送请求的代码很直接async function send() { const model document.getElementById(model-select).value; const input document.getElementById(input).value; const resp await fetch(/api/chat, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ model, messages: [...history, { role: user, content: input }] }), }); // 处理流式响应... }流式响应的前端处理用ReadableStream逐块读取每读到一个增量就追加到对话区。这里有个体验优化点在等待第一个 token 到达之前显示一个加载指示器因为有些模型的首 token 延迟能到两三秒没有反馈用户会以为卡死了。5. 常见问题与排查技巧实录5.1 模型返回内容被截断怎么办这是最常见的问题。三个模型的max_tokens默认值不同如果不显式设置DeepSeek 默认可能只返回 1024 个 token长回答会被硬截断。排查方法在适配器里打印每次请求的实际max_tokens值和响应的finish_reason。如果finish_reason是length说明被截断了需要调大max_tokens。但注意不要无脑调到最大因为max_tokens越大计费越高而且有些模型对超长输出有额外的限制。我的做法是设置一个合理的默认值2048然后在系统提示里告诉模型如果回答较长请分段输出。这样即使单次被截断用户也能通过继续指令拿到后续内容。5.2 切换模型后上下文丢失这个问题的根源在于不同模型的上下文窗口大小不同。Qwen 的qwen-plus支持 128K 上下文DeepSeek 的deepseek-chat是 64KGLM 的glm-4是 128K。如果你在 Qwen 里聊了很长一段切到 DeepSeek 时历史消息可能超出窗口限制。解决方案是在适配器里做上下文裁剪根据目标模型的窗口大小从最近的消息开始往前保留直到接近窗口上限。裁剪时要注意保留第一条system消息否则模型的角色设定会丢失。function trimContext(messages, maxTokens) { const system messages.find(m m.role system); const rest messages.filter(m m.role ! system); let total estimateTokens(system?.content || ); const kept []; for (let i rest.length - 1; i 0; i--) { const t estimateTokens(rest[i].content); if (total t maxTokens * 0.8) break; // 留 20% 余量给输出 total t; kept.unshift(rest[i]); } return system ? [system, ...kept] : kept; }estimateTokens用一个粗略的估算就行——中文大约 1 个字 1.5 个 token英文大约 4 个字符 1 个 token。不需要精确留足余量即可。5.3 流式响应中途断开流式响应断开的原因通常有三个网络抖动、模型服务端超时、前端处理逻辑有 bug。排查顺序建议从后往前。先看前端打开浏览器开发者工具的 Network 面板看 SSE 连接是什么时候断的。如果是前端主动断的检查ReadableStream的读取循环有没有异常退出。再看服务端在适配器的流处理循环里加日志看是哪个环节停止的。最后才怀疑网络和服务端。我遇到过一次是服务端的res.write在客户端断开后继续写入导致报错加一个res.on(close)监听就能解决res.on(close, () { abortController.abort(); // 取消上游请求 });这个细节不做的话客户端断开后上游请求还在跑白白消耗 token 额度。5.4 常见问题速查表问题现象可能原因排查方法解决方案返回内容不完整max_tokens 设置过小检查 finish_reason 是否为 length调大 max_tokens 或分段输出切换模型后报错上下文超出目标模型窗口打印消息总 token 估算值实现上下文裁剪逻辑流式响应中断网络抖动或前端处理异常查看 Network 面板和错误日志加断线重连和 abort 处理429 限流请求频率过高查看响应头中的限流信息加请求队列和指数退避重试参数错误 400参数超出模型取值范围对比各模型参数文档适配器里做参数 clamp鉴权失败 401Key 过期或格式错误检查环境变量是否正确加载重新生成 Key 并更新 .env注意排查问题时建议先在适配器里加详细的请求和响应日志定位到具体是哪个环节出的问题再动手改。盲目改代码只会引入新问题。6. 几个提升体验的进阶技巧6.1 多模型并行对比工作台搭好之后我加了一个对比模式同一个问题同时发给三个模型结果并排展示。这个功能在选型阶段特别有用——同一个技术问题看三个模型的回答很快就能判断出哪个更适合你的场景。实现上就是把单次调用改成Promise.allSettled并发调用三个适配器然后分别渲染。用allSettled而不是all是因为要允许部分失败——某个模型挂了不影响其他两个的结果展示。6.2 对话历史的持久化默认情况下对话历史存在内存里服务重启就没了。加一个简单的 JSON 文件持久化就能解决每次对话结束后把消息数组写入文件启动时读取。数据量不大不需要上数据库。文件按会话 ID 分目录存储每个会话一个 JSON 文件。清理策略是保留最近 30 天的会话超期的自动删除。这个用fs模块加一个定时任务就能实现代码量很少。6.3 成本监控三个模型的计费方式不同DeepSeek 按 token 计费Qwen 有免费额度加超出计费GLM 也是按 token。如果不做监控月底账单出来可能会吓一跳。我在适配器里记录每次调用的 token 消耗按模型和日期聚合提供一个简单的统计接口。前端加一个页面展示当日和当月的消耗趋势。这个功能不复杂但能帮你及时发现异常调用——比如某个循环 bug 导致重复请求。7. 我在实际使用中踩过的坑第一个坑是环境变量加载顺序。dotenv必须在其他模块之前加载否则适配器初始化时读到的 Key 是undefined。我一开始把require(dotenv).config()放在了路由定义之后结果所有请求都返回 401排查了半小时才发现是加载顺序问题。第二个坑是GLM 的鉴权头格式。DeepSeek 和 Qwen 都是标准的Bearer格式GLM 虽然也兼容但它的 Key 格式是id.secret的形式某些情况下需要先做一次 token 交换。我用的glm-4模型直接传 Key 就能用但如果你用的是其他模型可能需要额外处理。第三个坑是流式响应的编码问题。Node.js 的fetch返回的response.body是ReadableStream直接toString()在某些 Node 版本上会得到[object ReadableStream]。需要用for await...of迭代或者用TextDecoder手动解码。这个坑在 Node 18 和 20 上的表现还不一样建议锁定 Node 版本。最后一个经验是不要追求一次把所有功能做完。我最开始想做一个功能完整的工作台结果拖了两周还没上线。后来砍到最小可用版本——只有三个模型、一个输入框、一个切换下拉——半天就跑起来了。后面加对比模式、成本监控、历史持久化都是在这个基础上逐步迭代的。先跑起来再优化这个顺序不能反。