DeepSeek API 接入指南:参数、上下文与响应解析
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 是一个对象数组,包含完整的对话历史。每条消息必须有 role 和 content 字段。角色类型包括:
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_penalty 和 presence_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 显式传递。这才是可靠集成的核心。

