怎么调用 deepseek 新版模型

很多开发者拿到 Key 之后能跑通一条 hello world，却在接进项目时卡住：模型名该填哪个、流式怎么开、超时设多久、并发上来就报错、日志里看不出一次请求到底慢在哪贵在哪。这篇不讲协议兼容层，也不讲客户端怎么配，只给接入与开发环节的判断标准和排查顺序，让你把调用稳稳接进自己的服务里。

拿到 Key 能跑通一条 hello world，跟把一个调用稳稳接进自己的服务，是两回事。真正卡人的地方往往很碎：模型名到底填哪个、流式开不开、超时给多久、并发一上来就报错、日志里看不出一次请求慢在哪贵在哪。这篇不讲协议兼容层，也不讲客户端怎么配，只给接入和开发环节的判断标准与排查顺序。

先把一个前提说清楚：模型名、接口路径、计费口径这些会变，别靠记忆里的写法硬编码。接入前先到站内官方页面对一遍当前口径，把变动点集中到配置层，后面换版本才不至于满仓库改代码。

先确认调用哪个入口和哪个模型名

接入第一步不是写代码，是确认两件事：请求打到哪个入口，以及请求体里模型名填什么。走官方直连和走兼容层，路径和字段可能不完全一样，这个口径以站内页面为准，不要照搬别人的示例。

请求体通常只有模型名和消息数组是必填，温度、最大长度这类按任务调。流式不是性能开关，而是体验和工程复杂度的取舍：面向用户界面开流式，后台批处理用非流式更好做重试和统计。

超时不要用一个笼统的数字扛所有情况。连接、读取、整体三档分开设，读取这档要给推理留足余量，长输出被过早掐断是常见事故。并发则要按账号额度来定，本地先压一层比被限流后再退避省事。

重试不是万能药：能重试的只有网络类错误，参数写错重试一百次也是同一个错。

日志是后面排查慢和贵唯一的抓手。至少把请求 ID、模型名、入参长度、出参长度、耗时和错误码记下来，能凭一条日志复现当时那次请求，才算合格。没有这层记录，换模型之后变好还是变差只能靠感觉。

新版模型和 R1 的调用方式一样吗？

大体是同一套 HTTP 调用结构，差别主要在模型名和响应字段。R1 类模型会多出推理过程相关内容，如果你只解析正文，最好先打印一次原始响应看看结构，再决定解析逻辑，别直接套用旧代码。

调用一直超时或者返回很慢，先查什么？

按顺序查：先量一下你这边的网络延迟基线，到 /tools/speed-test 测一次；再看是不是读取超时设得太短，长输出容易被截断；最后看是不是并发撞上了额度上限导致排队。三项排完基本能定位。

并发一高就报错，是不是只能降速？

不一定。先在本地加一层队列把并发压到账号允许的范围内，再对可重试的错误做指数退避。如果业务量确实大，可以考虑申请提额或者走多入口分流，但分流逻辑要放在配置层，别硬塞进业务代码。