DeepSeek 系列是什么
DeepSeek 是深度求索的模型家族，API 侧主线是两个别名：deepseek-chat 对应通用对话模型 V3（MoE 架构），deepseek-reasoner 对应推理模型 R1，推理过程在独立的 reasoning_content 字段返回。它的接口是 OpenAI 兼容协议，改动 base_url 与模型名即可复用现成 SDK，中文表现与性价比是常被选中的原因。R1 系列权重已开放，可自行部署。
基本信息
| 厂商 | 深度求索（DeepSeek） |
|---|---|
| 主线模型 | deepseek-chat（V3 通用）、deepseek-reasoner（R1 推理） |
| 接入点 | api.deepseek.com，路径 /chat/completions |
| 协议 | OpenAI 兼容，Bearer 鉴权 |
| 返回差异 | 推理模型额外返回 reasoning_content 字段 |
| 权重开放 | R1 系列开放权重，可本地或私有化部署 |
V3 与 R1 的分工
| 维度 | deepseek-chat（V3） | deepseek-reasoner（R1） |
|---|---|---|
| 响应形态 | 直接生成回答 | 先输出推理内容，再给结论 |
| 延迟 | 较低 | 明显更高，随推理长度增加 |
| 计费 | 常规输入输出 | 推理 token 计入输出侧，账单更高 |
| 适合 | 问答、改写、抽取、客服 | 数学、算法、多步排查 |
典型使用场景
- 中文内容生产：写作、摘要、润色，对中文语料与表达习惯友好
- 私有化部署：用开放权重在内网跑推理模型，数据不出域
- 成本敏感的大批量任务：分类、抽取、批量改写等高频调用
- 复杂推理任务：把难题交给 reasoner，简单请求仍走通用模型
- 多路兜底：作为聚合网关里的一个供应商，与其它模型互为备份
两个模型的最小调用
两个模型的最小调用
curl -s https://api.deepseek.com/chat/completions -H "Authorization: Bearer $DEEPSEEK_API_KEY" -H "Content-Type: application/json" -d '{"model":"deepseek-chat","messages":[{"role":"user","content":"你好"}]}' # 通用对话
# 推理任务把 model 换成 deepseek-reasoner，返回里会有 reasoning_content 字段
# 复用 OpenAI SDK：把 base_url 指向 https://api.deepseek.com 即可
# 是否支持关闭思考与具体参数名，以官方文档的当前版本为准推理内容与最终答案分开取
推理内容与最终答案分开取
from openai import OpenAI
client = OpenAI(api_key=key, base_url="https://api.deepseek.com")
r = client.chat.completions.create(model="deepseek-reasoner",
messages=[{"role": "user", "content": "证明勾股定理"}])
msg = r.choices[0].message
print(msg.content) # 只把最终答案返回给用户
# 推理内容在 msg.reasoning_content，用于日志与排查，不直接展示接入方式对照
| 方式 | 入口 | 适用 |
|---|---|---|
| 官方 API | api.deepseek.com | 直接调用，最省事，按量付费 |
| 第三方托管 | 云厂商、聚合网关、推理平台 | 多供应商兜底或统一计费 |
| 本地部署 | 开放权重 + vLLM / Ollama 等 | 数据不出内网，硬件与运维自担 |
成本控制要点
| 抓手 | 做法 | 说明 |
|---|---|---|
| 任务分流 | 简单请求走 deepseek-chat，只有难题交给 reasoner | 推理 token 抬高输出侧成本，分流收益最直接 |
| 输出限制 | 设置最大输出长度，约束返回格式 | 输出单价高于输入，限制长度见效快 |
| 上下文裁剪 | 只带相关历史与检索片段 | 输入 token 随轮次累积，长会话要主动压缩 |
| 结果缓存 | 对确定性高的问答做本地缓存 | 重复问题不必二次计费 |
| 批量处理 | 离线任务集中在低峰时段跑 | 错峰能减少触发限流的概率 |
私有化部署要点
- 按并发与上下文长度估算显存：权重之外还要留出 KV 缓存空间
- 用 vLLM 等推理引擎做连续批处理，比单条串行吞吐高得多
- 量化能显著降低显存占用，但要在业务数据上确认效果损失可接受
- 配好并发上限与超时，避免请求堆积把服务拖垮
- 保留官方 API 作为兜底，本地集群故障时业务不中断
两个别名指向的底层权重会随官方迭代更新，需要行为可复现时固定到带日期标识的具体版本，或在升级前跑回归评测。
推理模型返回的 reasoning_content 适合写日志与排查，不建议直接透出给终端用户：内容较长，且可能包含被推翻的中间判断。
自部署时显存与吞吐要按并发量估算，量化能省显存但会影响效果；上线前用真实业务数据测一遍质量与延迟。