1. 为什么要把三个模型塞进同一个工作台我平时写代码、查资料、做技术方案最烦的一件事就是来回切窗口。DeepSeek 用来做代码补全和逻辑推理Qwen 用来处理长文档和中文理解GLM 用来做快速问答和轻量任务三个模型各有各的脾气但每次都要开三个网页、登三个账号、复制粘贴三遍提示词效率低得让人抓狂。后来我琢磨着能不能搞一个统一的工作台把这三个模型都接进去用同一套界面、同一套提示词模板、同一套历史记录管理。试了几种方案之后发现最省事的路径其实就藏在配置文件里——真的只改了两行整个工作台就能同时调度 DeepSeek、Qwen 和 GLM。这篇文章就是把我踩过的坑、试过的配置、以及最终跑通的方案完整记录下来。不管你是刚接触多模型调用的新手还是已经在用 API 做自动化流程的老手应该都能从里面找到能直接抄作业的东西。核心关键词就几个DeepSeek、Qwen、GLM、AI 工作台、配置。我会围绕这几个点把整个搭建过程拆开讲透。先说清楚这个工作台能干什么。它本质上是一个本地运行的统一接口层对外提供一致的调用方式对内根据任务类型自动路由到不同的模型。比如你发一段代码让它补全它走 DeepSeek你发一篇长文让它总结它走 Qwen你问一个简单的常识问题它走 GLM。整个过程你只需要在一个界面里操作背后的模型切换完全透明。适合谁来参考如果你手头有多个模型的 API 权限或者本地部署了其中一两个又不想每次手动切换那这套方案就是为你准备的。如果你只是偶尔用用单个模型那可能没必要折腾但了解一下多模型调度的思路也没坏处。2. 工作台的整体设计与选型思路2.1 为什么不用现成的聚合平台市面上确实有一些聚合类工具能同时接多个模型。但我试过几个之后发现两个问题一是数据要经过第三方服务器对于公司内部代码和敏感文档来说不太放心二是灵活性不够我想自定义路由规则、想改提示词模板、想加自己的后处理逻辑现成工具往往不支持。所以最终决定自己搭一个轻量级的工作台。核心诉求就三条本地运行、配置简单、扩展方便。本地运行保证数据不出内网配置简单意味着改两行就能切换模型扩展方便是指以后想加新模型不用重写整个框架。2.2 整体架构长什么样整个工作台分三层。最底层是模型接入层负责跟各个模型的 API 或本地推理服务通信。中间是路由层根据请求的特征决定用哪个模型。最上面是交互层提供统一的输入输出界面。路由层的设计是关键。我一开始想用复杂的规则引擎后来发现没必要。实际使用中大部分请求可以通过几个简单特征区分输入长度、是否包含代码块、是否要求特定格式。基于这些特征做路由准确率已经够用了。2.3 两行配置到底改了什么标题里说的“只改了两行配置”指的是模型注册部分的两个字段。第一行是模型名称的映射把统一的模型标识符映射到具体的 API 端点。第二行是路由权重的设置决定在模糊场景下优先走哪个模型。具体来说配置文件里有一个 models 数组每个模型有 name、endpoint、api_key、weight 四个字段。我改的是 name 和 weight。name 从默认的通用名称改成具体的模型标识weight 根据实际使用频率调整。改完之后工作台就能正确识别并调度这三个模型了。注意不同工作台框架的配置字段名称可能不一样但核心逻辑是相通的——告诉系统有哪些模型可用以及什么时候用哪个。3. 核心细节解析与实操要点3.1 模型接入的三种方式接入 DeepSeek、Qwen、GLM 有三种常见方式各有优劣我分别说一下实际体验。第一种是官方 API。DeepSeek 和 Qwen 都有官方 API 服务GLM 也有。优点是稳定、省心不用自己维护硬件。缺点是按量计费高频使用成本不低而且网络延迟受限于服务商。第二种是本地部署。Qwen 和 GLM 都有开源版本可以本地跑。DeepSeek 也有开源模型但完整版对硬件要求较高。本地部署的好处是数据完全可控缺点是前期投入大推理速度取决于你的显卡。第三种是混合模式。常用的轻量任务走本地复杂的重任务走 API。我目前用的就是这种GLM 本地跑做快速问答DeepSeek 和 Qwen 走 API 做重任务。3.2 配置文件的关键字段说明不管你用哪种接入方式配置文件里几个字段是必须搞清楚的。字段名作用常见取值name模型标识符deepseek-chat, qwen-max, glm-4endpoint接口地址API URL 或本地服务地址api_key认证密钥各平台申请的 keyweight路由权重0-100 的整数max_tokens最大输出长度根据模型能力设置timeout超时时间建议 30-120 秒weight 这个字段特别重要。它决定了当路由规则无法明确区分时系统优先选哪个模型。我一般把 DeepSeek 设成 50Qwen 设成 30GLM 设成 20。这样大部分请求会走 DeepSeek长文本走 Qwen简单问题走 GLM。3.3 路由规则的制定逻辑路由规则不需要太复杂我总结了三条就够用了。第一条输入超过 4000 字符的走 Qwen。Qwen 的长文本处理能力在三者中最强上下文窗口大总结和提取信息的准确率高。第二条包含代码块或明显编程相关关键词的走 DeepSeek。DeepSeek 在代码理解和生成上的表现明显优于另外两个。第三条其余情况走 GLM。GLM 响应快适合处理日常问答和简单指令。这三条规则覆盖了我 90% 以上的使用场景。剩下的模糊情况就靠 weight 来决定。实操心得路由规则不要一开始就设得太细先跑一段时间收集实际请求的分布再根据数据调整。我一开始设了十几条规则后来发现大部分都用不上反而增加了维护成本。4. 实操过程与核心环节实现4.1 环境准备与依赖安装先说一下我的运行环境。操作系统是 Ubuntu 22.04Python 版本 3.10内存 32G显卡是 3060 12G。这个配置跑本地 GLM 轻量版没问题跑 Qwen 大参数版就有点吃力所以 Qwen 我走的是 API。依赖安装很简单核心就几个包pip install fastapi uvicorn httpx pydantic python-dotenvfastapi 和 uvicorn 用来起本地服务httpx 用来发异步请求pydantic 做配置校验python-dotenv 管理环境变量。如果你要用本地推理还需要装对应的推理框架比如 transformers 或 llama-cpp-python。4.2 配置文件的具体写法配置文件我用的是 YAML 格式放在项目根目录的 config.yaml。核心内容如下models: - name: deepseek-chat endpoint: https://api.deepseek.com/v1/chat/completions api_key: ${DEEPSEEK_API_KEY} weight: 50 max_tokens: 4096 timeout: 60 - name: qwen-max endpoint: https://dashscope.aliyuncs.com/api/v1/services/aigc/text-generation/generation api_key: ${QWEN_API_KEY} weight: 30 max_tokens: 8192 timeout: 90 - name: glm-4 endpoint: http://localhost:8000/v1/chat/completions api_key: not-needed weight: 20 max_tokens: 2048 timeout: 30 routing: long_text_threshold: 4000 code_keywords: - def - function - class - import - 这里就是标题里说的“两行配置”所在的位置。第一行是每个模型的 name 字段第二行是 weight 字段。name 告诉系统这个模型叫什么weight 告诉系统它的优先级。4.3 路由逻辑的代码实现路由部分的代码不复杂核心就是一个判断函数def route_request(prompt: str, config: dict) - str: # 规则一长文本走 Qwen if len(prompt) config[routing][long_text_threshold]: return qwen-max # 规则二代码相关走 DeepSeek for keyword in config[routing][code_keywords]: if keyword in prompt: return deepseek-chat # 规则三其余走 GLM return glm-4这个函数接收用户输入和配置返回应该使用的模型名称。逻辑很直白没有复杂的机器学习模型就是基于规则的判断。实测下来这个简单方案在大多数场景下都够用。4.4 统一接口的封装为了让上层调用方不用关心底层用的是哪个模型我封装了一个统一的 chat 接口async def chat(prompt: str, history: list None): model_name route_request(prompt, config) model_config get_model_config(model_name) payload { model: model_name, messages: build_messages(prompt, history), max_tokens: model_config[max_tokens] } async with httpx.AsyncClient(timeoutmodel_config[timeout]) as client: response await client.post( model_config[endpoint], jsonpayload, headers{Authorization: fBearer {model_config[api_key]}} ) return response.json()这个接口对外只暴露 prompt 和 history 两个参数内部自动完成路由、请求构造、超时控制。调用方完全感知不到背后有三个不同的模型在干活。4.5 本地 GLM 的部署要点GLM 我选择本地部署主要是因为它响应快适合做第一道过滤。部署用的是 llama-cpp-python模型文件从公开渠道获取。启动命令如下python -m llama_cpp.server \ --model ./models/glm-4-9b-chat-q4.gguf \ --n_ctx 4096 \ --n_gpu_layers 20 \ --port 8000n_gpu_layers 设成 20 是为了把部分层放到显卡上加速剩下的跑在 CPU 上。3060 12G 的显存跑 20 层没问题再多了会爆显存。n_ctx 设成 4096 是平衡内存占用和上下文长度设太大内存吃不消。注意本地部署的模型文件格式要和推理框架匹配。GGUF 格式适合 llama-cpp-python如果你用 transformers需要的是 HuggingFace 格式的模型文件。5. 常见问题与排查技巧实录5.1 模型返回格式不一致怎么办这是最常见的问题。DeepSeek、Qwen、GLM 的 API 返回结构不完全一样有的把内容放在 choices[0].message.content有的放在 output.text。如果不做统一处理上层代码就要写一堆 if-else。我的做法是在每个模型的配置里加一个 response_path 字段指定从返回 JSON 的哪个路径提取内容。然后在统一接口里用这个路径去取值。这样新增模型时只需要加一行配置不用改代码。5.2 超时和重试怎么处理不同模型的响应速度差异很大。GLM 本地跑通常一两秒就返回DeepSeek 和 Qwen 走 API 可能要十几秒。如果统一设一个超时时间要么本地模型等太久要么 API 模型被误杀。我的方案是每个模型单独设 timeout然后在统一接口里加重试逻辑。重试次数设成 2 次重试间隔用指数退避。实测下来大部分偶发超时都能通过重试解决。5.3 路由判断错误怎么排查有时候路由规则会把请求发给不合适的模型。比如一段包含“class”这个词的普通文本被误判成代码请求发给了 DeepSeek。排查方法是加日志。每次路由决策时把输入特征和决策结果都记下来。跑一段时间后分析日志看看哪些请求被误判了然后调整关键词列表或阈值。我踩过的一个坑是把“import”设成了代码关键词结果“important”这个词也触发了路由。后来改成匹配“import ”带空格问题就解决了。5.4 常见问题速查表问题现象可能原因解决方法请求返回 401API key 无效或过期检查环境变量配置请求返回 429触发速率限制降低请求频率或增加重试间隔本地模型无响应端口被占用或模型未加载检查端口和模型文件路径路由结果不符合预期关键词或阈值设置不当查看路由日志调整配置返回内容为空response_path 配置错误核对 API 文档的返回结构内存占用过高本地模型上下文设太大降低 n_ctx 或减少 n_gpu_layers5.5 几个独家避坑技巧第一个技巧API key 不要硬编码在配置文件里用环境变量。我一开始图省事直接写在 YAML 里后来不小心把配置文件提交到了公开仓库赶紧撤销重来。现在统一用 ${VAR_NAME} 的形式引用环境变量。第二个技巧本地模型的启动脚本加一个健康检查。服务起来之后先发一个测试请求确认能正常返回再对外提供服务。否则有时候模型加载失败但端口已经监听了请求进来会报奇怪的错误。第三个技巧路由规则里的关键词列表要定期清理。用了一段时间后会发现有些关键词从来没被触发过有些则频繁误触发。每个月花十分钟整理一下能明显提升路由准确率。6. 实际使用中的性能观察与调优6.1 响应延迟的实测数据跑了一段时间后我记录了一些典型场景的响应时间。简单问答走 GLM 本地平均 1.5 秒返回。代码补全走 DeepSeek API平均 4 到 6 秒。长文档总结走 Qwen API平均 8 到 12 秒取决于文档长度。这个延迟分布是符合预期的。本地模型没有网络开销自然快。API 模型受网络和服务端负载影响波动较大。如果你对延迟敏感可以考虑把更多任务下沉到本地但前提是硬件跟得上。6.2 成本控制的几个手段走 API 的两个模型都是按 token 计费的。用了一段时间后我总结了几个控制成本的手段。第一设置 max_tokens 上限。有些请求其实不需要很长的回复但模型默认会生成很多。设一个合理上限能省不少。第二缓存常见问题的回答。有些问题反复被问到比如“这个函数是干什么的”完全可以把第一次的回答缓存下来后续直接返回。第三把简单任务尽量路由到本地 GLM。本地推理没有边际成本能走本地就走本地。6.3 扩展新模型的注意事项以后如果想加新模型比如某个新出的开源模型流程很简单。在配置文件里加一个条目填好 name、endpoint、api_key、weight然后在路由规则里加一条判断。如果返回格式特殊再加一个 response_path。唯一需要注意的是 weight 的重新分配。加了新模型后原来的权重比例可能要调整。我一般保持所有权重加起来是 100新增模型时按比例缩减其他模型的权重。实操心得加新模型之前先用单独的脚本测试一下它的 API 是否可用、返回格式是否一致、响应速度是否可接受。确认没问题再写进配置文件避免影响整个工作台的稳定性。7. 一些个人体会和后续折腾方向这套工作台我用了大半年最大的感受是“统一入口”带来的效率提升远超预期。以前写一段代码要开三个窗口对比输出现在一个界面就能看到不同模型的回答直接选最好的那个用。路由规则虽然简单但覆盖了绝大多数场景真正需要手动指定模型的情况很少。后续我打算折腾两个方向。一个是加一个反馈机制每次路由决策后记录用户是否采纳了结果用这些数据反过来优化路由规则。另一个是尝试把更多轻量模型本地化进一步降低对 API 的依赖。如果你也在用多个模型建议先从最简单的配置开始跑起来之后再逐步优化。不要一开始就追求完美的路由规则实际使用中积累的数据比拍脑袋想出来的规则靠谱得多。配置文件里那两行改动看起来不起眼但确实是整个工作台能跑通的关键。