换模型应该是业务指标驱动的决策，不是追新。DeepSeek 在中文、代码和成本控制上有自己的优势，但它不是所有任务的答案。团队真正要判断的是：当前问题是模型能力不够，还是检索、提示词、并发、网络或合规没做好。前者才值得换模型，后者换过去也会带着走。
本文给一套判断顺序：先看六个信号，再排除非模型问题，然后用同一批任务对比替代方案，最后决定全量替换、部分路由还是继续使用 DeepSeek。模型与价格以站内模型价格为准。
说明：DeepSeek、Claude、GPT、GLM、Qwen 等名称均为其权利人的商标，本文仅作技术选型讨论。各家能力、价格和条款会调整，采购前请核对官方页面。
一、六个该考虑换模型的信号
| 信号 | 具体表现 | 先排查什么 | 结论 |
|---|---|---|---|
| 质量天花板 | 同一批任务反复出错，改提示词无效 | 评测集、标注标准、检索质量 | 可以考虑换 |
| 长上下文不足 | 文档必须整本放入才能答对 | 分块、摘要、检索增强 | 先改架构 |
| 延迟过高 | p95 超出业务容忍范围 | 网络、并发、输出长度 | 先做优化 |
| 频繁限流 | 高峰期 429 明显增多 | 配额、共享 Key、重试策略 | 先做治理 |
| 能力缺口 | 需要多模态、特定工具调用 | 官方能力列表与版本说明 | 考虑换或多模型 |
| 合规要求 | 数据不能走某些路径或地区 | 法务、数据条款、行业规定 | 按合规选型 |
| 成本结构不匹配 | 输出长、缓存命中低、单价占比高 | 输入输出比例、重试次数 | 先降本再评估 |
信号要落到数据上，而不是“感觉不太好用”。至少看一周的错误率、人工返工率、p95 延迟和 429 次数，再决定是否进入选型流程。
二、先排除“不是模型的问题”
在换模型之前，按下面顺序做一次自查：
- 提示词是否有明确验收标准：没有标准的任务，换任何模型都无法判断好坏。
- 检索是否召回正确片段：RAG 召回错了，模型再强也只能编。
- 是否把长文档整本塞入：上下文过长会推高延迟和成本，也会稀释关键信息。
- 是否所有请求都用推理模型：简单分类、抽取用推理模型，慢且贵。
- 是否多服务共用一把 Key：配额被互相挤占，表现就像“模型不稳定”。
- 是否用错模型名或旧版本：404、能力差异有时只是配置问题。
这六项里只要有明确问题，先把问题修掉，再重新跑一轮评测。很多“需要换模型”的结论，在做完这一步后会消失。
三、替代方案分四类
| 类型 | 代表 | 优势 | 代价 | 适合场景 |
|---|---|---|---|---|
| 国内其他通用模型 | GLM、Qwen、豆包等 | 中文表现、国内支付与低延迟 | 能力各有差异，需要实测 | 国内业务、合规要求明确 |
| 国际模型 | Claude、GPT、Gemini | 复杂推理、代码与生态 | 访问、支付、数据合规 | 高难度任务、海外业务 |
| 开源自建 | Qwen、Llama 等开放权重模型 | 数据可控、可定制、可私有化 | GPU、运维、工程投入 | 有基础设施和数据隔离要求 |
| 多模型网关 | 中商起航 AI 网关 | 一个入口、统一账单、模型可切换 | 依赖服务方的可用性 | 同时使用多家模型的团队 |
选型不是“谁排第一”，而是任务匹配。中文客服、批量抽取、代码补全、复杂推理对模型的要求完全不同，用一套标准打分通常会得到错误结论。
四、用同一批任务做替换评估
- 从真实业务抽 30–50 条任务，覆盖简单、中等、复杂三档。
- 为每条任务写验收标准，能双人盲评更好。
- 用旧模型和新模型跑同一批输入，参数保持一致。
- 记录质量评分、p50/p95 延迟、输入输出 Token、错误率和重试次数。
- 计算“每完成一个合格任务”的成本，而不是每百万 Token 的标价。
- 保存失败样例，判断是能力问题、提示词问题还是数据问题。
| 指标 | 怎么记 | 决策用途 |
|---|---|---|
| 合格率 | 人工按验收标准打分 | 是否达到业务底线 |
| 返工率 | 需要人工修改的占比 | 隐性人力成本 |
| 尾延迟 | p95、p99 | 是否影响用户体验 |
| Token 结构 | 输入、输出、缓存命中 | 成本差异来源 |
| 错误率 | 4xx、5xx、超时占比 | 生产稳定性 |
| 迁移工作量 | 改配置还是改代码 | 上线周期 |
把模型名和 Base URL 放进配置，替换时只改环境变量：
import os
from openai import OpenAI
BASE_URL = os.environ.get("API_BASE_URL", "https://ai.zhongshangqihang.com/v1")
MODEL = os.environ.get("API_MODEL", "deepseek-chat")
client = OpenAI(
api_key=os.environ["API_KEY"],
base_url=BASE_URL,
)
resp = client.chat.completions.create(
model=MODEL,
messages=[{"role": "user", "content": "把这段客服对话抽取成 JSON"}],
max_tokens=512,
)
print(resp.choices[0].message.content)
如果目标模型不兼容 OpenAI 协议，需要加适配层；如果兼容，迁移通常只是改三处配置。具体模型名以站内价格页为准，不要照搬旧教程。
五、迁移步骤
- 冻结当前模型的版本、参数和提示词，保留一份可回滚的配置。
- 新模型先做双跑，不接真实流量，只比对输出。
- 灰度 5%–10% 流量，观察合格率、延迟和错误率。
- 准备兜底模型或兜底通道，主模型失败时能自动切换。
- 监控按模型、场景、版本拆分，避免混在一起看不出差异。
- 设定回滚条件，指标越过阈值就回退，不要靠感觉坚持。
- 迁移完成后更新文档，写清模型名、参数、已知差异和联系人。
六、什么时候不该换
- 只是看到新模型发布，没有业务指标支撑。
- 没有评测集，只凭几条对话下结论。
- 问题在检索、提示词、并发或网络，换模型解决不了。
- 团队没有 GPU 和运维能力，却想自建开源模型。
- 数据合规还没确认，先换模型会放大风险。
更稳妥的做法是部分路由：主力模型继续处理中文批量任务，把复杂推理、代码评审或多模态请求按任务类型分流到其他模型。路由规则写在网关或应用层，按任务标签选择模型，而不是全量切换。
| 任务类型 | 建议 | 原因 |
|---|---|---|
| 中文客服、摘要、改写 | 主力模型 | 量大，优先稳定和成本 |
| 复杂推理、架构评审 | 能力更强的模型 | 一次做对比反复返工更省 |
| 高并发分类、抽取 | 轻量模型 | 延迟和成本优先 |
| 敏感数据、私有化 | 开源自建 | 数据不出内网 |
常见问题
DeepSeek 和 Claude、GPT 怎么选？
按任务而不是按名气。中文批量处理、成本敏感场景可以先用 DeepSeek；复杂推理、代码和特定生态需求，用评测集对比后再决定。不要用单一案例替代系统评测。
换模型要改多少代码？
如果目标模型兼容 OpenAI 协议，通常只改 Base URL、Key 和模型名三处。若使用了厂商特有参数、工具调用格式或多模态字段，需要适配层和回归测试。
能不能两个模型同时用？
可以。常见做法是主力模型加兜底模型，或按任务类型路由。代价是要维护两套评测、监控和账单口径，团队要有人负责。
开源自建一定更便宜吗？
不一定。要看 GPU、带宽、运维、模型更新和人力成本。调用量小的时候，自建的总成本通常高于按量付费；数据隔离和定制需求才是自建的主要理由。
换模型后质量下降怎么办？
先看失败样例是能力问题还是提示词问题，再用固定评测集对比。保留旧模型作为回滚选项，灰度期间设置明确的回滚阈值，不要一次性全量切换。
下一步
先在中商起航 AI 网关创建测试 Key，把 DeepSeek 和候选模型接到同一个入口，用同一批任务跑一轮对比，再按模型价格核算成本。模型可用性以价格页为准。
相关阅读：
