deepseek 如何调用大模型 api

很多人第一次调 DeepSeek 的接口，卡住的地方往往不是模型本身：Key 放哪、请求体长什么样、流式怎么接、超时设多少、报错了看哪一行。这篇按上手顺序走一遍，给的是能照着做的步骤和排查顺序，具体价格与模型清单请到站内对应页面核对。

很多人第一次碰 DeepSeek 的接口，卡住的其实不是模型本身：Key 放哪、请求体长什么样、流式怎么接、超时设多少、报错该看哪一行——每一步都能让人原地绕圈。这篇按上手的先后顺序走一遍，给的是能照着抄的步骤和排查顺序，不带概念铺陈。

先说明一点：下面所有涉及价格、模型清单、额度口径、并发档位的地方，我一律不给具体数字。这类信息变动频繁，写死在文里对你没好处，统一记成「到站内对应页面看当时的数字」，你按路径去找最新的就行。

动手前先确认三件事

第一件事是搞清楚你手里的 Key 是哪来的。官方直连和中转接口是两套体系：Key 不同、Base URL 不同、能用的模型名也可能不同。最常见的坑就是把官方 Key 填到中转的地址上，或者反过来，然后对着一个鉴权报错查半天代码——其实代码一点问题没有。

第二件事是 Key 的存放位置。本地开发放环境变量或 .env 文件，线上放平台的密钥管理服务。别直接写在代码里，更别提交到 Git 仓库。Key 一旦进了仓库历史，删文件也没用，得去后台直接吊销重发。

Base URL

接口的根地址，官方和中转各有一套，配错会直接连不上或鉴权失败

API Key

身份凭证，等同于账号权限，泄露等于账号被白用

环境变量

操作系统层面存配置的方式，让 Key 不进代码库，本地线上都适用

第三件事，动手前先在设备上量一次网络基线。到站内测速页面跑一轮，把延迟和丢包情况记下来。这不是走流程，而是给你后面排查「为什么这么慢」「为什么老是断流」留一个参照点——没有基线，你分不清是接口本身慢还是你的网络在抖。

第一次请求怎么写才不白跑

第一次请求的目标只有一个：确认链路是通的。所以请求体用最小可用结构就够了——模型名、消息数组、是否流式，其他参数一个都别加。采样参数、系统提示、工具调用这些等你确认能收到正常响应之后再逐个加。

1. 用 curl 先跑一次不写任何脚本，直接命令行发一个请求，看能不能拿到正常返回。这一步能帮你排除掉大半代码层面的干扰。
2. 再换成最小脚本用你项目实际使用的语言和 HTTP 库，发同一个请求，只保留几个必需字段。返回结构一致就说明环境没问题。
3. 最后才往业务代码里搬把这段能跑通的最小逻辑封装成一个函数，再接进你的业务流程。顺序反了的话，网络问题、代码问题、业务逻辑问题会同时冒出来，根本没法定位。

DeepSeek 走的是 OpenAI 兼容形态，请求体的字段名和响应结构可以到站内的官方接口资料页对照当时的规格说明。别照着记忆里的旧字段写，接口字段偶有调整，以页面上的为准。

curl -sS $BASE_URL/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"<模型名>","messages":[{"role":"user","content":"你好"}],"stream":false}'

超时别只设一个数

很多人的超时是随手写一个数，然后发现要么太短老是断，要么太长把线程全占住。正确的做法是把超时拆成三层，各管各的：连接超时管建连，读取超时管等数据，整体超时管整个请求的生命周期。

流式输出的超时判断要特别注意：看的是两个数据块之间的间隔，不是整段耗时。一段回答总耗时很长是正常的，但如果中间卡住半天没有新数据，那才是异常，应该断开重试而不是干等。

批量任务还要多一层保险。给整批任务设一个总超时预算，单条超时累加超过预算就停止调度，把剩下的标记为失败。不设这个的话，一条卡死的请求能把整批任务拖到天亮，而且你根本不知道卡在哪。

并发和限流要提前想

并发不是越高越好。先按你账号的额度定一个上限，再在代码里用信号量或队列把并发卡住。靠 try 里 sleep 硬扛是最差的做法：请求已经发出去了，额度已经消耗了，你只是在自己这边瞎等。

• 在代码里设置一个固定的最大并发数，所有请求走同一个闸门
• 遇到限流类报错时按指数退避重试，每次等待时间翻倍
• 给重试次数封顶，重试本身也会消耗额度，不封顶等于自己打自己
• 把并发数和重试次数做成可配置项，出问题时不改代码就能调
• 上线前按真实并发压一轮，别拿开发环境的单线程表现当生产指标

这里要强调一句：具体的并发阈值、额度口径因账号档位而异，到站内的官方接口资料页看当时的说明。别照抄别人的经验值，别人的档位和你的不一样。

失败了按这个顺序查

报错最忌讳一上来就翻代码。先把错误分类型，四类的处理动作完全不同，混在一起查就是绕远路。分类靠看报错原文里的状态码和错误关键字，不用猜。

1. 分类型先判断是鉴权类、参数类、限流类还是网络类，四类的排查方向不一样。
2. 鉴权和参数类查 Key 与 Base URL 是否配套，请求体字段名是否拼对。概念不清的话，到站内的基础概念词条把 token、上下文这些对齐，再回来看报错原文。
3. 限流类看是不是并发打高了、重试太频繁，把并发降下来观察是否好转。
4. 网络和网关类换直连和代理各试一次，确认是链路问题还是服务问题，再决定要不要切备用入口。

什么情况下这套顺序不适用？如果你的请求从来就没成功过一次，那不用分类，直接回到上一节的 curl 最小请求，从零验证一遍链路。分类排查是给「之前能通、现在不通」准备的。

返回结果怎么接进业务

非流式的返回最好处理，把文本字段取出来就行。流式就麻烦一点：要按行拼增量，而且最后一块通常只带结束标记、没有正文内容。新手常犯的错是把最后一块当成空回答，然后在业务里报一个莫名其妙的错。判断结束要看专门的标记，不是看内容是否为空。

需要结构化数据时（比如让模型输出一段 JSON），别直接把模型返回的内容塞进数据库。正确做法是先让模型按你约定的格式输出，拿到结果后本地做一次校验，校验不通过就发起重试，重试几次还不行就走兜底逻辑。

日志留哪几样才够复盘

日志不是越多越好，是越对越好。一条请求至少记下面几样，缺了任何一项，后面复盘的时候你都会后悔：请求时间、总耗时、输入和输出 token 数、模型名、状态、是否发生了重试。有了这几样，慢在哪、贵在哪、错在哪，基本都能算出来。

• 按天汇总，看慢和贵的调用集中在哪些调用方或哪些业务模块
• 对比同一批用例在改参数前后的表现，不要凭感觉说「好像变好了」
• 发现某类请求异常增多时，先查调用方逻辑变更，再查接口侧
• 原始响应归档，保留期限按你的合规要求定

钱和额度怎么盯

用量统计一定要按业务模块拆开。混在一起你只会看到一个总数，知道花了多少但不知道谁花的。拆开之后，你才可能判断某块成本是不是值得，也才能定位到该优化哪个调用方。

最后提醒一句：免费额度只适合前期验证。试用期的用量小、并发低，很多问题根本暴露不出来。上线前按真实并发和真实输入长度压一轮，把超时、并发、重试这几项真刀真枪地过一遍，才算准备好了。