2026 年 deepseek api 官网文档速览:Key 获取、Base URL 配置与首个调用示例
2026 年 deepseek api 官网文档速览:Key 获取、Base URL 配置与首个调用示例
搜 DeepSeek API 文档的人,通常只关心三件事:API Key 去哪拿、Base URL 填哪个、第一段代码怎么写才不报错。这三步理顺了,后面的迁移、调试和成本核算都会轻松很多。
先分清文档里的三类关键信息
第一次打开 deepseek api 官网文档,很容易被章节数量劝退。真正决定能不能一次调通的,其实只有三类信息:身份凭据、请求地址、请求结构。
- 身份凭据:API Key,决定这次请求是否被识别,以及计入哪个账号的用量。
- 请求地址:Base URL,决定请求发往哪个入口,路径中是否带有版本号。
- 请求结构:模型名称、消息格式、流式开关、最大输出长度等字段。
建议把这三类信息抄进一份备忘录再动手写代码。需要提醒的是,接口地址、模型名称、并发限制与计费规则都可能调整,凡是你没有在控制台亲眼确认过的细节,都应该回到官方页面复核,不要直接照搬第三方博客里的旧截图。
API Key 与 Base URL 的配置要点
第一步:创建 Key,并想清楚怎么保管
API Key 通常在控制台的密钥管理页面创建,创建后一般只完整显示一次,请立刻保存到密码管理器或环境变量中,不要写进前端代码,也不要提交到公开仓库。团队协作时,建议一个项目对应一把 Key,既方便按调用量定位问题,也方便出现泄露时随时撤销。
如果 Key 曾经出现在截图、日志或群聊记录里,最稳妥的做法是直接删除并重新创建,而不是抱着侥幸继续使用。
第二步:Base URL 与模型名称要成对确认
Base URL 是请求入口。有的说明给的是不带版本号的域名,有的给的是带 /v1 的完整路径,两者混用就可能出现 404。模型名称同理,文档中出现的名称不一定等于控制台当前开放的名称,尤其在版本并行阶段,复制粘贴比手打更可靠。
| 配置项 | 作用 | 填写要点 | 检查方法 |
|---|---|---|---|
| API Key | 身份识别与用量归属 | 从控制台创建,存入环境变量 | 返回 401 通常说明 Key 或请求头有问题 |
| Base URL | 决定请求发往哪个入口 | 注意是否包含版本路径 | 用一条最小请求测连通性 |
| 模型名称 | 指定实际调用的模型 | 与控制台列表逐字比对 | 提示模型不存在时优先怀疑名称 |
| 超时与重试 | 控制失败时的行为 | 设置合理超时并做退避重试 | 观察日志中是否集中出现超时 |
首个调用示例:先跑通最小请求
第一次调用不要追求复杂,构造一条单轮消息,确认能拿到返回即可。下面的示例使用 OpenAI 兼容写法,域名与模型名请替换成你在控制台看到的值。
from openai import OpenAI
client = OpenAI(
api_key="你的 API Key",
base_url="https://api.deepseek.com/v1" # 以官方文档与控制台显示为准
)
resp = client.chat.completions.create(
model="deepseek-chat", # 以控制台模型列表为准
messages=[{"role": "user", "content": "用三句话介绍你自己"}],
)
print(resp.choices[0].message.content)
跑通之后再做三件事:打开流式输出、把 Key 从代码里挪到环境变量、给请求补上超时与重试。这样一套最小工程骨架就算成型了,后续换成其他模型也只需要改动少量配置。
常见报错与排查顺序
排查顺序建议固定为:先看状态码,再看返回体里的错误信息,最后才回头比对配置。状态码告诉你问题出在哪一层,错误信息往往直接指出是哪个字段不合法。
- 401 / 403:Key 无效、已删除、带了多余空格,或请求头字段名写错。
- 404:Base URL 路径不对,或者模型名称根本不存在。
- 400:请求体字段缺失、类型错误,或消息结构不符合要求。
- 429:触发限流,需要降低并发或排队重试。
- 超时:网络链路问题或输出过长,可以先用更短的问题验证连通性。
这些错误大多与模型能力无关,而是配置层面的问题。养成先复现最小请求的习惯,能省下大量靠猜的时间。
多模型场景下怎么少改代码
实际项目里,往往既要用对话模型,也要用图像或语音能力,逐个平台维护 Key、地址和余额会很琐碎。这时可以把多个模型收敛到一套兼容接口下调用。像 通联AI中转站 这类聚合平台,思路是提供一个统一的请求入口,再按任务切换不同模型;至于当前开放哪些模型、兼容到哪一层协议、如何计费,需要以通联控制台和文档中的实时展示为准,不能想当然。
迁移时建议分两步走:第一步只替换 Base URL 与 API Key,保持请求体不变做验证;第二步再逐个替换模型名称,观察返回质量与耗时变化。这样一旦出问题,能迅速判断是入口配置的问题,还是模型本身的差异。
如果你已经理解了 Key、Base URL 和请求结构这三件事,剩下的就是把它们跑起来。可以到通联AI中转站注册账号,进入控制台创建 API Key、查看当前可用的模型与接口地址,然后用本文的最小示例完成第一次调用测试。
模型名称、接口地址与计费规则,请以通联官网控制台显示的信息为准。