2026年3月，客服SaaS公司的技术选型经常遇到这种情况：国外API账单逐月上涨，数据出境合规收紧，必须换成国产模型。需求很明确：模型要能本地部署，中文理解要稳，API别太贵。
这个场景适合用来做一次完整的国产大模型评测。本文不只给结论，也把方法给出来，你可以对照着测自己的业务。
1. 选模型范围：先按部署约束圈定，别按知名度圈
市面上常被提到的国产大模型有DeepSeek、通义千问(Qwen)、智谱(GLM)、月之暗面(Moonshot)。先不比较哪个更强，先看能不能用在你的场景里。
| 模型 | 开源权重 | 官方API | 备注 |
|---|---|---|---|
| DeepSeek-V3/R1 | 是（MIT协议） | 有 | 可本地部署，API价格低 |
| Qwen2.5系列 | 是（Apache 2.0） | 有（阿里云百炼） | 从0.5B到72B可选 |
| GLM-4-Plus | 否 | 有 | 闭源API，也有开源版但功能有差距 |
| Moonshot-v1 | 否 | 有 | 闭源，专注长文本 |
注意，开源协议要看清：DeepSeek用的MIT协议，允许商用；Qwen2.5用的Apache 2.0，也允许商用。但某些模型只开放权重，协议不一定允许商用。查的时候看“权重许可”一栏，不要只看“开源”两个字。
2. 评测基准：用你的业务题，不是排行榜题
公开榜单（如LMSYS Chatbot Arena、MMLU）有参考意义，但存在数据污染风险——模型的训练数据可能已经包含了这些测试集。更可靠的做法是自建一组业务题。
拿客服场景举例，准备30条真实工单，覆盖退款、物流、发票、售后维修四类。每条工单附上标准回复（可以拿历史人工回复改一改）。然后让每个候选模型生成回复，从三个维度打分：
- 信息准确度（是否给出正确的处理路径）
- 语气自然度（是否像客服人员，而不是“作为AI，我需要”）
- 动作可执行性（用户看完知道下一步干什么）
如果模型还要写代码，额外加10道SQL题和10道Python题，题目从你的真实脚本里改。如果是多模态场景，比如识别截图或证件，准备20张文字清晰的截图，看抽取信息是否完整。多模态领域目前Qwen-VL和GLM-4V比较靠前，但本地部署时要注意显存占用。
3. 价格与速度：算总成本，别只看单价
API价格是“按量付费”的，所以要把调用量乘上去。价格变化很快，以下是一组公开参考价格（2025年6月官网信息，2026年最新价格请以官网为准）：
| 模型 | 输入价格（元/百万tokens） | 输出价格（元/百万tokens） | 备注 |
|---|---|---|---|
| DeepSeek-V3 | 1.10（未命中缓存） | 1.10 | 缓存命中输入0.27 |
| DeepSeek-R1 | 0.55（未命中缓存） | 2.19 | 缓存命中输入0.14 |
| Qwen-Max（阿里云百炼） | 约20 | 约20 | 2025年6月标价 |
推理速度怎么测？用官方API写一个循环，发10次请求，记录每次的“首Token延迟”和“平均生成速度（token/s）”。如果做客服交互，首Token延迟更重要；如果是批量离线分析，生成速度更重要。本地部署的话，测的是GPU利用率，顺便看看是否能支持并发。
4. 开源还是闭源：先看谁来做运维
开源模型（DeepSeek、Qwen）可以私有化部署，数据不出域，单次调用成本趋近于零（电费不算的话）。但前提是你得维护一套推理服务。包括：GPU服务器、CUDA环境、模型量化降显存、高并发队列、监控报警。光跑通不够，要稳定跑365天。客服系统挂一次就是事故。
闭源API（GLM-4-Plus、Moonshot-v1）开箱即用，没有运维负担，但每次调用都要付费，数据要经过第三方服务器。很多企业卡在数据合规上，这一条比成本更致命。
一个折中方案：核心业务用开源模型本地部署，非敏感业务用API兜底。比如客服系统走本地DeepSeek，遇到异常超时切到GLM的API，保证服务不中断。这种混合架构目前被不少团队采纳。
5. 选型清单：一小时能做完的验证流程
以下步骤按顺序做，完成就基本能定方向：
- 列出3个核心场景，每个场景准备10条真实输入，并写好期望输出
- 根据部署约束（数据是否出境、是否有GPU）筛掉不合适的模型
- 对剩下2-3个模型跑同一批测试题，让3个同事盲测打分，记录分数
- 用官网价格公式计算：月费用 = 月输入tokens × 输入单价 + 月输出tokens × 输出单价
- 用官方API做一次10分钟压力测试，记录延迟和成功率
- 读一遍开源协议或服务条款，确认商用限制和数据使用条款
- 选分数最高且成本可接受的2个，小流量并行运行一周