DeepSeek API 接入指南:参数、上下文与响应解析

17 阅读

DeepSeek API 基础接入条件

要调用 DeepSeek 的大模型接口,首先需要两个基本条件:一个有效的 API Key,以及对 HTTP 和 JSON 格式的理解。

文章配图

DeepSeek 提供了两种基础 URL:

文章配图

  • 兼容 OpenAI 格式的端点:https://api.deepseek.com/v1
  • 原生接口端点:https://api.deepseek.com

文章配图

如果你已有基于 OpenAI SDK 的代码,直接替换 base URL 和 API Key 即可快速迁移,无需重写请求逻辑。

请求协议与接口规范

所有对话补全请求都通过 POST 方法发送到 https://api.deepseek.com/chat/completions,请求体为 JSON 格式,Content-Type 必须设为 application/json

身份验证通过 Authorization 请求头完成,格式为:

Authorization: Bearer <你的API-Key>

这是每次调用的硬性要求,缺少或错误都会导致 401 错误。

核心请求参数详解

必选参数

model 指定使用哪个模型。目前有两个主要选项:

  • deepseek-chat:通用对话模型,响应快,适合日常问答
  • deepseek-reasoner:启用深度思考模式,擅长数学、代码和复杂推理

两款模型底层都基于 DeepSeek-V3.1-Terminus 架构。官方计划未来将思考能力整合进 deepseek-chat,不再单独维护 reasoner 版本。

messages 是一个对象数组,包含完整的对话历史。每条消息必须有 rolecontent 字段。角色类型包括:

  • system:设定模型行为规则,比如“你是一个严谨的编程助手”
  • user:用户输入的问题或指令
  • assistant:模型之前的回复
  • tool:外部工具调用的返回结果(用于函数调用场景)

注意:messages 数组不能为空,至少要有一条消息。模型不会记住上一次对话,所有上下文必须由客户端显式传入。

关键可选参数

max_tokens 控制模型最多生成多少个 token。这个值只限制输出长度,不影响输入。例如设为 512,意味着模型最多回复 512 个 token,但你可以传入更长的上下文(只要不超过模型总窗口限制)。常规应用建议设在 1024 到 2048 之间。

stream 决定是否启用流式输出。设为 true 时,服务器会通过 SSE(Server-Sent Events)逐块返回内容,直到最后收到 data: [DONE]。这对实时聊天界面很有用;设为 false(默认)则等待完整生成后一次性返回。

temperature 调节输出的随机性,范围 0 到 2,默认为 1。值越低,输出越确定、重复性高;值越高,越有创意但可能偏离事实。代码生成推荐 0.1–0.3,诗歌创作可用 1.3 左右。

top_p 是另一种控制随机性的方法,也叫核采样。它从高概率 token 中选出累积概率超过 top_p 阈值的子集,再从中随机选一个。例如 top_p=0.9 表示只考虑覆盖 90% 概率的 token。通常不建议同时调整 temperature 和 top_p。

frequency_penaltypresence_penalty 用于减少重复或鼓励新话题。两者取值都在 -2.0 到 2.0 之间,默认为 0。正值会惩罚已出现过的词(frequency)或已存在的话题(presence),适合长文本生成时避免啰嗦。

其他参数如 stop(自定义停止词)、response_format(强制 JSON 输出)、tools(函数调用)等,可根据高级需求选用。

无状态服务与上下文机制

DeepSeek API 是无状态的——每次请求都是独立的,服务器不会保存任何会话信息。这意味着连续对话完全依赖客户端在 messages 中传入完整历史。

模型支持最大 128K token 的上下文窗口,相当于几百页文本。如果历史太长,系统会自动截断最早的部分。因此,客户端需要主动管理对话长度:在长会话中定期裁剪旧消息,或在关键节点重置上下文。

值得注意的是,system 消息不会自动继承。如果你希望模型始终遵守某种角色设定(比如“用中文回答”),每次请求都必须重新包含这条 system 消息。

网页版 DeepSeek 能实现“记忆”,是因为前端或后端服务替你维护了消息列表,并在每次调用时自动拼接进去。你自己开发应用时,也要做同样的事。

响应格式与字段解析

非流式响应是一个标准 JSON 对象,结构如下:

{
  "id": "8b1ca715-9270-429a-b40d-2a644f6e1d3f",
  "object": "chat.completion",
  "created": 1754880537,
  "model": "deepseek-chat",
  "system_fingerprint": "fp_8802369eaa_prod623_f8_kvcache",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "我是DeepSeek Chat..."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 5,
    "completion_tokens": 63,
    "total_tokens": 68
  }
}

id 是本次请求的唯一标识,可用于日志追踪。

created 是 Unix 时间戳(秒),表示响应生成时间。

model 返回实际使用的模型名称,便于确认是否调用正确。

system_fingerprint 是后端配置的哈希值,当出现意料之外的行为时,可提供此值给技术支持排查环境差异。

choices 数组包含生成结果。通常只有一项(index=0)。其中 message.content 就是你要的回复文本。finish_reason 表示结束原因:stop 表示正常结束,length 表示达到 max_tokens 限制。

usage 统计本次调用的 token 消耗:

  • prompt_tokens:输入部分消耗的 token 数
  • completion_tokens:输出部分消耗的 token 数
  • total_tokens:两者之和

这些数据对成本控制很重要,尤其在高并发场景下。

接入最佳实践

最简单的调用只需 model 和 messages 两个参数。测试阶段建议关闭 stream,方便调试。

参数调优方面:

  • 写代码、解数学题:temperature 设为 0.1–0.3,提高准确性
  • 写故事、头脑风暴:temperature 设为 1.0–1.3,激发创造力
  • 生产环境务必设置 max_tokens,防止意外生成超长内容导致延迟或费用飙升

会话管理的关键是:客户端必须自己保存整个 messages 数组。每次用户新提问,就把 user 消息追加进去,调用 API 后再把 assistant 回复也存下来。这样下次请求才能带上完整上下文。

对于长期对话,建议监控 total_tokens。一旦接近 128K 上限,就删除最早的几轮对话,或者插入一条总结性消息替代历史,以节省空间。

在这里插入图片描述

最后提醒:不要依赖模型“记住”任何东西。所有约束、风格、知识背景,都要通过 messages 显式传递。这才是可靠集成的核心。

在这里插入图片描述

在这里插入图片描述