为什么我放弃了传统方案，改用 DeepSeek-V3
一个让我头疼的实际问题
先说说背景。我手头有个老项目，需要做大批量文本分类和摘要——每天大概 40 万条客服工单，要自动归类、提取关键信息、生成摘要。之前的方案是用 GPT-3.5 的 API，一个月账单稳定在 3000 多块人民币，老板已经暗示过两次了。
更糟的是上季度开始，高峰期调用经常超时，重试逻辑写了三层，还是丢数据。我当时的处境就是：成本压不下来，稳定性上不去。
去年 12 月 DeepSeek-V3 开源的消息出来时，我是持怀疑态度的。国产模型、便宜得离谱的价格（输入 0.5 元/百万 tokens，输出 2 元/百万 tokens，当时缓存命中更低），便宜通常意味着不好用，这是我的第一反应。但我还是花了两个周末做了迁移测试，结果让我把整套方案换了。
第一步：先跑通一个最小对比测试
我没急着改架构，而是用同样的 500 条工单数据，分别调两边的 API 做对比。
from openai import OpenAI
client = OpenAI(
api_key="sk-xxx",
base_url="https://api.deepseek.com"
)
resp = client.chat.completions.create(
model="deepseek-chat",
messages=[
{"role": "system", "content": "你是工单分类助手，输出JSON：{\"category\": ..., \"urgency\": ..., \"summary\": ...}"},
{"role": "user", "content": ticket_text}
],
response_format={"type": "json_object"},
temperature=0.2
)
注意这里有个让我惊喜的点：DeepSeek 的 API 是 OpenAI 兼容格式的，我原来的代码只改了 base_url 和 api_key，其他一行没动。这是我原本以为要改一星期的部分，实际只花了五分钟。
对比结果（我人工抽检了 500 条）：
| 指标 | GPT-3.5 | DeepSeek-V3 |
|---|---|---|
| 分类准确率 | 91.2% | 93.4% |
| JSON 格式出错率 | ~2% | ~1% |
| 单条平均成本 | ¥0.007 | ¥0.0004 |
准确率略高我是有心理准备的——V3 的评测分数确实不差。但成本差了十几倍，这才是决定性因素。
第二步：我踩的三个坑
坑 1：temperature 设置直接照搬
我原来 GPT-3.5 用的 temperature=0.7，迁过去之后摘要开始出现奇怪的措辞。后来查了 DeepSeek 官方文档才发现，他们的建议区间和 OpenAI 不太一样：
- 通用对话：1.3
- 写作/翻译：1.5
- 代码/结构化输出：0.0
我改回 temperature=0.1 之后输出立刻稳定了。不同厂商的采样参数不能直接照搬，这个教训值两个晚上的调试时间。
坑 2：没利用缓存机制
DeepSeek 有自动的前缀缓存——如果多次请求共享相同的 system prompt 前缀，缓存命中部分价格降到 0.1 元/百万 tokens。我最初的代码把动态信息拼在 system prompt 前面，导致缓存永远命中不了。
改法很简单：把 system prompt 固定不动，动态内容全部放 user 消息里：
# 错误：动态拼进 system，缓存失效
system = f"分类标准：{today_rules}，输出JSON..."
# 正确：system 完全固定
system = "分类标准：xxx（固定内容），输出JSON..."
改完之后我们的缓存命中率从 0% 涨到 78%，成本又降了一截。
坑 3：max_tokens 没设置
有一批异常输入导致模型“发散”，输出停不下来，单条消耗了一万多 tokens。加上 max_tokens=300 的硬限制后这类情况彻底消失。这是所有大模型 API 的通病，但以前 GPT 那边我的输出普遍短，没暴露出来。
第三步：自部署还是用 API？
这里我走了一段弯路。看到权重开源（MIT 协议，671B 参数 MoE 架构，激活约 37B），我一度想自己部署——公司正好有几台闲置的 A100。
现实是：V3 完整部署至少需要 8 张 80GB 的卡（FP8 权重约 700GB），我们那几台 A100 根本凑不齐。中间也试过量化到 INT4 跑，延迟和效果都明显下降。折腾了三天，最后决定：日常走官方 API，等以后业务量再涨且卡资源到位，再考虑私有化。这是我建议大多数人的路径——除非你有严格的合规要求，否则 API 的性价比很难被打败。
上线后的实际数据
迁移完成三个月后的真实账单：
- 月调用成本：从 ¥3000+ 降到 ¥260 左右（含缓存优惠）
- P95 延迟：从 4.2s 降到 1.8s
- 错误率：超时基本消失，重试逻辑删了两层
顺便一提，我们后来把一部分代码 review 辅助任务也切了过去，V3 写代码的能力比我预期强不少，简单的重构和 bug 定位基本够用。
实用建议总结
- 迁移成本比你想的低。OpenAI 兼容接口意味着改动通常只有几行。
- temperature 从 0 开始调，尤其是结构化输出场景。
- 把 system prompt 固定住吃缓存红利，这一条对高频调用场景收益巨大。
- 一定设 max_tokens，做好输出长度兜底。
- 别急着自部署。V3 的硬件门槛不低，先算清楚 API 成本和运维成本的临界点。
诚实的局限性
最后说说不那么好的地方，免得你以为我在无脑吹：
- 极端长文本推理上，和最顶级的闭源模型还是有差距，我们超过 20K tokens 的复杂分析任务仍然走备用方案。
- 官方 API 高峰期偶有排队，虽然比我原来遇到的超时好多了，但金融级 SLA 场景要有心理准备。
- 中文场景表现很强，但某些细分领域的英文术语处理，我抽检时发现偶尔不如 GPT-4 级别的模型稳。
总体来说，对于“大批量、结构化、对成本敏感”的场景，DeepSeek-V3 是我这两年用过的性价比最高的方案。它没有让我惊艳到扔掉所有其他工具，但确实让我把原来方案里最痛的那块成本和稳定性问题，干净利落地解决了。