力 力达云
教程聚合APItoken成本国产模型资讯工具关于内测申请
← 返回资讯

DeepSeek API 接入、价格与能力详解

2026-06-14

DeepSeek 是目前国产大模型中性价比最高、开源生态最活跃的厂商之一。其 API 遵循 OpenAI 兼容协议，已有 OpenAI SDK 使用经验的开发者几乎零学习成本即可完成迁移，并在相当多任务上实现降本增效。

如果你是从 GPT 系列或者其他海外模型迁移过来的，大概率会经历这样一个过程：先是被「跟 OpenAI 一样的 SDK 调用方式」打动，接过来跑了几条 demo 请求，一切正常；然后开始批量跑任务，这时候才会撞上真正的坑——比如 R1 推理模型返回结构跟 V3 不一样、并发上去之后偶尔 429、长文本任务不小心把上下文喂爆了却没报错只是答案变差。这些坑官方文档里其实都写了，只是分散在各个角落不容易一次看全。这篇文章除了给你能直接跑起来的接入代码，也把这些容易踩的地方一次性讲清楚，你可以直接把代码复制过去改改参数就用。

注册与获取 API Key

  1. 访问 platform.deepseek.com 注册账号（手机号实名）；
  2. 进入控制台 → API Keys → 点击「创建 API Key」；
  3. 复制并妥善保存密钥（仅展示一次）；
  4. 控制台可查余额、充值及用量统计。

接入示例：OpenAI 兼容调用

DeepSeek 的端点与 OpenAI 格式完全兼容，只需替换两个参数：

from openai import OpenAI

client = OpenAI(
    api_key="sk-xxxxxxxxxxxxxxxx",          # 你的 DeepSeek API Key
    base_url="https://api.deepseek.com/v1",
)

# 普通对话（deepseek-chat = DeepSeek-V3 最新版）
response = client.chat.completions.create(
    model="deepseek-chat",
    messages=[
        {"role": "system", "content": "你是一个专业的代码助手"},
        {"role": "user", "content": "用 Python 写一个冒泡排序"},
    ],
    stream=False,
)
print(response.choices[0].message.content)

流式输出（适合实时对话 UI）：

stream = client.chat.completions.create(
    model="deepseek-chat",
    messages=[{"role": "user", "content": "请写一首关于春天的诗"}],
    stream=True,
)
for chunk in stream:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)

这两段代码到底改了什么，为什么就能跑通？ 只有两处：api_key 换成 DeepSeek 的，base_url 指向 api.deepseek.com/v1。OpenAI SDK 本身不关心你把请求发去哪家服务商，它只是按 OpenAI 的接口规范把参数拼成 HTTP 请求发出去、再把返回的 JSON 解析成 ChatCompletion 对象。DeepSeek 服务端照着同一套规范实现了接收和返回，所以 SDK 完全无感——这也是「OpenAI 兼容」这四个字在工程上的真实含义：协议层对齐，不是能力对齐。好处是你原来项目里所有基于 OpenAI SDK 封装的重试、日志、限流中间件都能直接复用，不用重写一套适配层。

流式输出那段代码里 stream=True 触发的是服务端 SSE（Server-Sent Events），本质是一条一直开着的 HTTP 长连接，服务端每生成几个 token 就往这条连接里推一个 data: {...} 分片，客户端收到一片处理一片。它的价值不是省 token 或省钱（消耗的 token 数跟非流式一样），而是首字延迟：用户不用等模型把几百字全想完才看到第一个字，尤其是对话类产品必须用这个模式，否则体验上会被有流式的竞品甩开一截。批处理、离线跑数据这种没有人盯着屏幕等的场景，用非流式反而代码更简单、更好做错误处理。

DeepSeek-V3 与 DeepSeek-R1 的区别

维度DeepSeek-V3（deepseek-chat）DeepSeek-R1（deepseek-reasoner）
定位通用对话与生产任务深度推理与复杂问题求解
推理过程直接输出答案输出完整思维链（Chain-of-Thought）
速度快，延迟低较慢，思考时间长
适用场景文案、摘要、代码补全、问答数学题、逻辑推理、代码调试、方案分析
上下文窗口64k tokens64k tokens
价格定性国产最低价区间略高于 V3，仍显著低于海外同类

选择建议：日常 NLP 任务优先用 deepseek-chat（V3）；遇到复杂数学/推理/多步规划任务，切换 deepseek-reasoner（R1）。

切到 R1 之前必须知道的一个坑：响应结构变了

很多人第一次切 deepseek-reasoner 会踩这个坑：以为跟 deepseek-chat 一样直接读 response.choices[0].message.content 就完事了，结果发现内容前面混进一大段「嗯，这道题我们先假设……」的思考过程，格式全乱。原因是 R1 的思维链和最终答案是分开放在两个字段里的，你需要分别取：

response = client.chat.completions.create(
    model="deepseek-reasoner",
    messages=[{"role": "user", "content": "一个水池有两个进水管一个排水管……"}],
)

reasoning = response.choices[0].message.reasoning_content  # 完整思维链，调试/展示用
answer = response.choices[0].message.content               # 最终答案，展示给用户用

reasoning_content 适合你想在前端做「思考过程」折叠展示，或者自己排查模型哪一步推错了；真正要给用户看的结果只取 content。另外有个容易漏看的官方限制：deepseek-reasoner 不支持 temperature、top_p、presence_penalty、frequency_penalty 这几个采样参数，就算你传了也不会报错，但也不会生效——如果你的业务逻辑依赖调温度来控制输出的发散程度，切到 R1 之后这套逻辑会静默失效，建议在切模型的地方加个显式判断，别指望它自己报警告。

价格定性

截至 2026-06，以官方公示为准：

  • DeepSeek-V3 输入价格位于国产主流模型最低区间，大规模调用成本优势明显；
  • DeepSeek-R1 推理模型按思考 token + 输出 token 计费，综合性价比仍优于 GPT-o1 等海外推理模型；
  • 新用户注册有免费额度赠送，适合快速测试。

具体单价请以 DeepSeek 官方定价页 为准，价格随市场竞争持续优化。也可用 价格对比工具 与其他厂商横向比较。

上线前怎么估算月成本，别等账单出来才后悔

不少团队上线前从来不估算成本，等第一个月账单出来才发现批量任务把预算干爆了。其实估算方法很简单，先拿一条典型请求算出「单价」，再乘以预期调用量：

单次成本 = (输入 token 数 / 1000 × 输入单价) + (输出 token 数 / 1000 × 输出单价)
月成本 = 单次成本 × 日均调用量 × 30

输入输出的 token 数不用猜，把 response.usage.prompt_tokens 和 response.usage.completion_tokens 打到日志里跑几十条真实请求求平均，比拍脑袋准得多。如果是 R1，还要单独统计思维链消耗的 token（体现在 completion_tokens 里，因为 reasoning_content 也算模型输出），同一个问题 R1 的输出 token 数经常是 V3 的好几倍，这也是为什么它单价虽然不算贵但真实花费容易超预期——预算紧张的场景建议先用 V3 试跑一版流程，确认逻辑没问题、真的需要深度推理能力再切 R1。

另外 DeepSeek 有个容易被忽略但很值钱的机制：上下文缓存（Context Caching）。如果你的请求前缀是固定的或重复率很高（比如系统提示词很长、或者同一份长文档反复被问不同问题），命中缓存的那部分输入 token 会按更低的价格计费。具体折扣比例和缓存命中条件请以官方文档为准，但结论是：把「不变的部分」（system prompt、长文档正文）放在消息列表靠前的位置、「变化的部分」（用户当次的问题）放在最后，能显著提升缓存命中率，这是个几乎零成本就能拿到的省钱技巧，很多人接入了半年都不知道有这功能。

适用场景推荐

最适合 DeepSeek 的场景：

  • 大规模文本处理：批量摘要、分类、提取——V3 性价比无出其右；
  • 代码生成与调试：在 HumanEval、SWE-bench 等基准上表现优秀；
  • 数学与逻辑推理：R1 在 AIME、MATH 等权威榜单上与 GPT-o1 不相上下；
  • 私有化部署：DeepSeek-V3/R1 均有开源权重（Hugging Face 可下载），数据敏感场景可本机推理；
  • 成本敏感型应用：ToC 产品、内容平台、开发者工具等需要高频调用的场景。

相对弱势的场景：

  • 原生多模态（图像/视频理解）：目前主力模型以文本为主，建议配合通义千问多模态能力；
  • 与百度/阿里云生态深度绑定的业务。

常见问题

DeepSeek API 和本地部署的开源模型有什么区别？ API 版本持续更新、推理算力由 DeepSeek 托管，使用方便但数据经过网络传输；本地部署用开源权重，数据完全私有，但需自建 GPU 推理环境（或用 Ollama 等工具在本地小规模跑）。

调用报错 401 Unauthorized 怎么解决？ 检查 api_key 是否正确复制（无多余空格），base_url 末尾不要加多余路径，确认账户余额充足。

能用 LangChain / LlamaIndex 接 DeepSeek 吗？ 可以。两个框架均支持自定义 base_url，将 OpenAI Provider 的端点改为 DeepSeek 即可，模型名用 deepseek-chat 或 deepseek-reasoner。

批量调用时偶尔报 429 Too Many Requests，是什么原因？ 说明你的请求频率或并发数超过了账户当前的限流阈值。这不是账户被封，而是流控保护，直接重试大概率还是 429。正确做法是加指数退避重试，而不是收到 429 就立刻原地重发：

import time
import random
from openai import OpenAI, RateLimitError

client = OpenAI(api_key="sk-xxxxxxxxxxxxxxxx", base_url="https://api.deepseek.com/v1")

def chat_with_retry(messages, max_retries=5):
    for attempt in range(max_retries):
        try:
            return client.chat.completions.create(model="deepseek-chat", messages=messages)
        except RateLimitError:
            if attempt == max_retries - 1:
                raise
            wait = (2 ** attempt) + random.uniform(0, 1)  # 指数退避 + 抖动，避免多个请求同时重试再撞车
            time.sleep(wait)

2 ** attempt 让等待时间随失败次数翻倍（1秒、2秒、4秒……），加一点随机抖动是为了防止你所有并发请求同时被限流之后又同时在同一秒重试，那样只会集体再撞一次墙。批量任务建议把并发数控制在个位数到十几的量级慢慢往上试，边跑边看 429 出现的频率，而不是一上来就拉满并发。

长文本任务效果变差、答案答非所问，但没有报错，是怎么回事？ 大概率是上下文超限但你没发现。V3 和 R1 的上下文窗口都是 64k tokens，注意这 64k 是输入 + 输出加在一起的总预算，不是输入单独 64k。如果你把很长的文档、历史对话、系统提示词一股脑塞进 messages，接近上限时模型可用于生成回答的 token 空间就被压缩到很小，输出会被截断或者变得答非所问，而这个过程通常不会报错，只是效果悄悄变差。排查方法是打印每次请求的 response.usage.prompt_tokens，如果长期贴近 64000，就该做上下文裁剪（只保留最近几轮对话 + 关键信息摘要）或者把长文档拆段分批处理。

想同时跑几百个请求提高吞吐，用同步代码一个个 for 循环调用会不会太慢？ 会。同步循环里每条请求都要等上一条返回才发下一条，网络等待时间全部串行叠加。批量场景建议用异步客户端并发发起：

import asyncio
from openai import AsyncOpenAI

async_client = AsyncOpenAI(api_key="sk-xxxxxxxxxxxxxxxx", base_url="https://api.deepseek.com/v1")

async def ask(prompt: str):
    resp = await async_client.chat.completions.create(
        model="deepseek-chat",
        messages=[{"role": "user", "content": prompt}],
    )
    return resp.choices[0].message.content

async def main(prompts: list[str]):
    semaphore = asyncio.Semaphore(10)  # 限制同时在飞的请求数，别真的把几百个请求同时甩出去
    async def bounded(p):
        async with semaphore:
            return await ask(p)
    return await asyncio.gather(*(bounded(p) for p in prompts))

这里的 Semaphore(10) 很关键，不加的话 asyncio.gather 会把所有请求同时发出去，直接把你打进上面说的 429 限流，加了信号量之后同一时刻最多 10 个请求在飞，跑完一个再补一个进来，吞吐比同步 for 循环高出一大截，又不至于把限流打爆。这个数字要结合你账户的实际限流阈值调，账户等级不同上限不同，建议从 5～10 开始试，逐步往上加，观察 429 出现的频率再定最终值。

相关阅读：国产大模型 API 全景指南 · 六大模型横向对比 · 通义千问接入详解

分类导航：国产模型专题

实用工具：价格对比表 · Token 计数器