Deepseek API调用实战：从零构建生产级LLM应用

平时在技术群里最常被问到的一个问题就是：“Deepseek模型在线API调用到底怎么搞？”。尤其是Deepseek这轮热度上来之后，很多人的第一反应是自己部署一套，显卡、显存、推理框架折腾一圈，最后发现连加载都成问题。我个人的建议很直接：如果你不是专门搞推理优化或者有严格的私有化需求，直接用官方API是成本最低、见效最快的路子，没有之一。

这篇文章就围绕Deepseek模型API调用来写，从准备工作、最小可用代码，到高频报错的排查思路，再到流式输出、函数调用、上下文管理和多Agent协作。内容覆盖了我自己从第一次拿Key到上线生产环境的完整路径，代码可以直接抄，坑也提前帮你标好。适合刚接触LLM API的开发者，也适合已经在用但被各种报错和生产稳定性问题折磨的朋友。

1. 为什么最终选择了在线API而不是本地部署

这个问题几乎每个找我聊Deepseek的人都会问。我的回答不是“本地部署不好”，而是“大部分场景下，在线API的性价比高得多”。

1.1 本地部署的真实门槛

先说本地部署。早期大家用开源模型都是往自己的服务器上灌，但真正跑一遍就知道，这里的成本远不止一张显卡的钱。

首先是显存。Deepseek这类模型的完整参数体积摆在那里，量化后的模型文件动辄几十GB起步，全精度版本更是夸张。即便用了GPTQ、AWQ这类量化方案，显存占用依旧不低。而且你还需要给KV Cache留出空间，上下文越长，KV Cache吃掉的显存越恐怖。很多人把模型加载进去发现没法用，不是模型跑不动，是显存被上下文撑爆了。

其次是推理框架的适配。VLLM确实好用，但真遇到硬件不兼容或者框架版本不匹配的时候非常折腾。我见过有人在昇腾910B-A2这类加速卡上用VLLM启动Embedding向量模型和Reranker模型，怎么都起不来，日志报得云里雾里，翻来覆去排查就是框架对特定硬件的算子支持问题。这类问题不是说不能解决，而是解决它需要投入的时间和专业度，远超普通业务团队的预算。

1.2 API调用的核心优势

在线API把这层复杂度全部抽掉了。你不需要关心显卡型号、驱动版本、CUDA版本、推理框架、算子兼容性，也不需要维护一套模型生命周期管理。拿Key、看文档、发请求，三个步骤就能跑通第一条对话。

成本上，API按Token计费，没有流量的时候就几乎不花钱。自建服务器则是一条完全不同的曲线，机器要买、电费要出、人要养，即便模型闲置，资源也是空转。

模型迭代上，API服务商更新模型版本是即时的，官方升级了模型能力，你改一下Model参数就用上了。自部署最大的痛点是“版本锁定”，一旦上线，后续想追新版本就要重新走一遍部署、测试、灰度，周期很长。

所以我的结论很明确：线上Demo、业务原型、中小规模生产流量，直接用在线API；有数据合规要求、超大规模并发、或者需要把推理成本压到极致的情况，再考虑私有化部署。两件事的投入产出比完全不在一个量级。

2. 调用前的准备工作：API Key、接口规范与模型选择

看起来是最简单的一步，但很多人就是在准备工作上踩了坑，导致后面一路不顺。

2.1 API Key的获取与权限位

API Key是调用在线API的通行证。在Deepseek开放平台的开发者后台创建应用后，系统会生成一组密钥。这里有两个容易忽略的细节。

第一，Key是按项目维度隔离的，不要一个Key到处塞。不同业务线、不同环境（开发、测试、生产）最好分开创建，出了问题也好单独吊销，不至于一个Key泄露导致全部业务受影响。

第二，Key的权限范围。部分平台允许你限制Key可以访问的模型、是否允许余额扣费、IP白名单等。建议把权限收紧，生产环境的Key只开放给固定的服务器IP段。这样做最大的好处是即便Key泄漏，攻击者也换一个网络环境就无法调用。

有的人喜欢把Key直接写进前端代码里，这是大忌。任何在浏览器端暴露的密钥，等于把账户余额公开挂在网上。正确的做法是Key只保存在服务端环境变量或密钥管理服务里，由后端统一转发API请求。

2.2 RESTful接口规范与端点结构

Deepseek API是标准的RESTful接口，和OpenAI的接口风格高度兼容，这也意味着大量现成的SDK和工具链可以直接复用，省去了很多适配成本。

理解RESTful接口，核心就是搞清楚三件事：

• Base URL（基础地址）：所有接口路径共用的前缀，相当于服务端的“根目录”。
• Endpoint（端点）：具体功能对应的路径，比如对话补全通常是 /chat/completions。
• HTTP方法：创建资源用POST，查询资源用GET，REST架构里每种方法语义清晰。

以对话补全为例，你最终请求的地址是 {Base URL}/chat/completions，请求头里带上 Authorization: Bearer {API Key} 和 Content-Type: application/json，请求体里放模型名和消息列表。这个结构简洁清晰，按照OpenAI的标准格式去写基本不会出错。

2.3 模型名别乱填：Model参数决定上下限

Deepseek平台提供了不同定位的模型，比如偏重复杂推理的Pro版本和偏重响应速度的Flash版本。这些模型名在后端是有严格注册的，不是随便填个字符串就能识别。

我见过一个很典型的报错：The supported API model names are deepseek-v4-pro, deepseek-v4-flash, and de...。这就是把模型名拼错了，或者以为API会自动映射到最新模型。平台为了保证向后兼容，通常会长期保留旧模型名，但同时也意味着你不知道确切的Model值，API就是报错给你看。

所以拿到文档后，第一件事是确认当前可用的模型标识，不要凭记忆写。这类信息在平台文档里一定有一张“模型列表”表，里面会注明模型名、上下文窗口长度、单价等。我的习惯是每次对接新API，先把这张表截图保存到项目文档里，后面排查问题都是依据。

上下文长度这一点格外重要。不同的上下文窗口直接决定你能传多少Token，以及单次请求的最大输出量。开发之前先算清楚业务场景下的Token预算，避免上线后才被截断问题困扰。

3. 第一个可运行的调用：最小代码样例与参数踩坑

准备工作做完，接下来就是动手写代码。这里我按“最简可行”的思路来：先用原生HTTP库跑通，再谈SDK和框架集成。

3.1 最小可用代码示例

我用的是Python，配合requests库，代码量非常少：

python复制import requests

api_key = "your-api-key-here"
url = "https://api.deepseek.com/chat/completions"

headers = {
    "Authorization": f"Bearer {api_key}",
    "Content-Type": "application/json"
}

payload = {
    "model": "deepseek-chat",
    "messages": [
        {"role": "system", "content": "你是一个乐于助人的助手。"},
        {"role": "user", "content": "请用一句话介绍你自己。"}
    ],
    "temperature": 0.7,
    "max_tokens": 200
}

response = requests.post(url, headers=headers, json=payload, timeout=30)
print(response.status_code)
print(response.json())

这段代码里最关键的是messages结构。它是完整的多轮会话表达方式，每条消息都带有role字段。system消息设定模型行为风格，user消息是用户输入，assistant消息是模型历史回复。多轮对话就是把历史轮流排列进去。

3.2 核心参数逐个解析

跑通之后，你会接触到一堆API参数。我逐个说下实际调参经验和典型值。

• model：必填，指定模型名称。这是最基础的参数，但也是最容易出问题的地方，后面会专门讲错误排查。
• messages：必填，对话消息列表。格式必须严格符合OpenAI规范，字段名不能写错。
• temperature：采样温度，控制随机性，通常0到2之间。数值越低输出越确定，适合分类、抽取这类有标准答案的任务；数值越高输出越发散，适合创意写作。我一般做结构化任务设0.2，做头脑风暴设0.9。
• max_tokens：最大输出Token数，控制单次生成的响应长度。需要注意，这个值不是“额外生成”的，而是单次输出的总量上限。如果你既要多轮对话又要长回复，容易在调用时忽略计费已经包含了输入Token。
• top_p：核采样概率，模型只在累计概率达到该值的候选集合中采样。OpenAI官方推荐调整temperature或top_p其中之一，避免同时调导致输出过于机械。
• stream：是否流式输出，布尔值。设为true时，响应以SSE流的形式分批到达，适合追求首字延迟的场景。
• timeout：这是客户端超时，不是API参数，但非常关键。不设超时的话，服务端迟迟不回包时，你的请求会一直挂着，worker全被占满，生产事故就是这么来的。

很多人不理解max_tokens和输出长度的关系。这里有一个容易混淆的点：模型在一次调用中，输出Token达到max_tokens后会被强制截断。有时候模型不是因为“答完了”才停止，而是“到限了”被剪断。所以看到输出戛然而止，先检查是不是max_tokens设得太小。

3.3 响应结构解析

返回的JSON结构大体是这样的：

json复制{
    "id": "chatcmpl-xxx",
    "object": "chat.completion",
    "created": 1712345678,
    "model": "deepseek-chat",
    "choices": [
        {
            "index": 0,
            "message": {
                "role": "assistant",
                "content": "你好！我是一个基于Deepseek模型的助手……"
            },
            "finish_reason": "stop"
        }
    ],
    "usage": {
        "prompt_tokens": 36,
        "completion_tokens": 47,
        "total_tokens": 83
    }
}

choices是核心数组，里面是模型生成的回复内容。message.content就是要展示给用户的文本。finish_reason有两个常见值：stop表示模型自然结束，length表示因为达到max_tokens上限被截断。

usage字段提供Token消耗统计。生产环境必须把这个数据落库，它是成本核算和异常检测的原始依据。

初学的人最容易犯的错是直接拿response.text当纯文本处理，没有转JSON就直接用；或者没判断status_code就解析内容，服务端返回错误时报错信息不直观。保持“先判断HTTP状态码，再解析JSON，最后提取内容”这个习惯，能省掉大量排查时间。

4. 高频报错排查：529不是唯一的坑

调用过程中，报错是家常便饭。下面这些是我实际遇过且高频出现在群里的问题，逐个拆解根因和应对方案。

4.1 529 Overloaded：服务端过载的应对之道

一个非常高频的报错是：

code复制api error: 529 overloaded. this is a server-side issue, usually temporary

看到这个不要慌，这是服务端过载，不是你代码的问题。大模型API在流量高峰期很常见，尤其是热门模型发布后，算力资源被瞬间打满，触发限流机制。

应对策略有三层：

第一层，指数退避重试。第一次遇到529，等1秒再试；还是不行，等2秒；再不行，等4秒。每次翻倍，重试3到5次，给服务端恢复留出时间。不要用固定间隔重试，否则你的重试请求会进一步加剧服务端压力，得不偿失。

第二层，并发削峰。你的服务如果同时发大量请求，可以在客户端做一个简单的并发控制，限制同时进行中的请求数量。

第三层，自建降级缓存。在请求量最大的场景里，对部分非实时性要求的问答结果做短时缓存，命中后直接返回，把压力分摊开。

下面是一个Python指数退避的参考实现：

python复制import time
import random
import requests

def call_with_retry(payload, max_retries=5):
    for attempt in range(max_retries):
        try:
            response = requests.post(url, headers=headers, json=payload, timeout=30)
            if response.status_code == 200:
                return response.json()
            if response.status_code == 529:
                wait = 2 ** attempt + random.uniform(0, 0.5)
                time.sleep(wait)
                continue
            response.raise_for_status()
        except requests.exceptions.Timeout:
            wait = 2 ** attempt + random.uniform(0, 0.5)
            time.sleep(wait)
    raise RuntimeError("API call failed after retries")

一个细节：重试次数和退避上限要设置合理值。5次重试时，最长等待已经到16秒以上，加上前面几次，总等待时间可能逼近30秒。如果你的接口下游有同步超时要求，比如前端3秒就要响应，那就不能同步重试，应该改为异步任务方式。

4.2 401鉴权失败与400参数错误

401 Unauthorized通常意味着Key错误、过期或者压根没传。排查路径如下：

• 检查请求头里是否有Authorization: Bearer xxx。
• 检查Key粘贴是否完整，是否带了引号或隐藏字符。
• 检查环境变量是否正确加载，很多坑来自.env文件里的Key被无意中加了换行。

400 Bad Request则多为请求体格式问题。常见的有：

• messages字段值必须是列表，不是字符串。
• 每个message的role必须是合法取值，system、user、assistant之外的值为非法。
• temperature超出允许范围，比如设为负数或大于2。
• 模型名不存在或拼写错误。

我在排查400错误时，会先用一个最简单的payload，比如只带一条user消息，每次去掉一个可疑参数，再请求一次，二分法定位到底哪个字段引起的。

4.3 连接中断与超时问题

还一类问题很让人困惑，就是在调用过程中突然收到：

code复制failed to connect to the docker api at npipe...

或

code复制cannot connect to api: the socket connection was closed unexpectedly

这类报错表面上是“无法连接API”，实际上分两种情况：

第一种是本地网络出口有问题，或者目标服务域名DNS解析异常。我处理过不少案例，本地代理配置导致全局请求被劫持，直接把代理关掉，或者把API域名加进白名单就好了。这里要多说一句，项目生产环境要保持网络环境简单干净，尤其不要挂各种代理工具，否则连接被强制断开时很难定位。

第二种是服务端主动断开长连接。API服务出于资源管理考虑，会设置空闲连接超时，客户端复用一个闲置过久的连接去请求，服务端发现连接失效便会断开。解决方案是客户端不要用共享连接池方式无限复用连接，请求前做连接健康检查。Python的requests库每次请求默认新建连接，这个问题相对少见；换成一些带连接复用的JDK HTTP客户端时，就要特别注意。

下面把常见错误码整理成一张表：

这张表建议截图存到团队文档里，遇到报错先对表再动手，能省不少时间。

5. 流式输出与多轮上下文管理

很多场景下，普通的一次性请求够用了，但要做聊天机器人或AI助手，就得掌握流式输出和上下文管理。

5.1 stream=True的实现逻辑

普通调用等模型生成完整个响应才返回，遇到长回答时等待时间可能十几秒，用户的直观感受就是“卡住了”。流式输出则是模型每生成一小段Token就立刻推给客户端，用户看到的效果是文字一个接一个蹦出来，体验上接近实时对话。

实现上，请求体加"stream": true，响应会变成SSE（Server-Sent Events）格式，一行一行往下推，每行以data:开头。Python里用requests库可以做逐行迭代：

python复制payload = {
    "model": "deepseek-chat",
    "messages": messages,
    "stream": True
}

response = requests.post(url, headers=headers, json=payload, stream=True, timeout=60)

for line in response.iter_lines():
    if not line:
        continue
    line_text = line.decode("utf-8")
    if not line_text.startswith("data: "):
        continue
    data_str = line_text[6:]
    if data_str == "[DONE]":
        break
    try:
        chunk = json.loads(data_str)
        delta = chunk["choices"][0]["delta"]
        content = delta.get("content", "")
        if content:
            print(content, end="", flush=True)
    except Exception as e:
        print("解析出错：", e)

逐行迭代的关键是不要对响应体做整体一次性读取，stream=True之后，客户端会保持连接并持续接收服务端推来的数据。要注意设置足够长的timeout，流式场景下，模型思考时间可能超过默认30秒，如果timeout太短，一段时间没新数据就会触发超时断开。

5.2 上下文窗口与Token预算

大模型的上下文窗口是有限的，超过上限的部分会被截断或直接报错。在多轮对话里，这个问题会被放大，因为每次请求都要把全部历史消息传给模型，历史越长，占用空间越大。

我的做法是建立一个滑动窗口策略，维护一个消息列表，新消息不断追加，但控制总Token数不超阈值。每次追加前，估算当前消息总Token数，一旦超过危险线，就把最老的几条消息丢弃。

可以用一个简单的比例来估算：中文场景下，1个Token大概对应0.5到0.7个汉字。更准确的方式是用平台的Token统计接口，但这个接口会一次多算一次调用成本。实际业务中我常用一个轻量方案，在本地对历史字符串做粗略切分，估算Token数，误差能控制在10%以内就够了。

滑动窗口不是简单砍掉最老消息而已。有些业务场景里，用户在第1轮给出的身份信息、偏好设定对第10轮的回答依然重要，直接砍掉会改变对话质量。进阶做法是维护结构化的摘要层，当历史消息变长时，先让模型把旧对话压缩成一段摘要，再和最近几轮完整对话拼接起来。这样既控制Token预算，又不丢失关键信息。

这里要特别提到一点，很多人会混淆上下文窗口和max_tokens。上下文窗口是模型能处理的所有Token总和（输入加输出），而max_tokens只是其中输出部分的限额。假设窗口是64K，输入已经占了60K，那输出最多只能有4K。如果请求同时设置了max_tokens为8K，就会遇到冲突，系统要么拒绝请求，要么按较小值执行，这又是一个隐蔽的报错来源。

5.3 多轮会话中的角色一致性

多轮对话的messages里，角色顺序必须保持正确。user和assistant消息应该交替出现，不能连续两条assistant消息，也不要在用户输入之后缺失对应的历史回复。角色错乱会导致模型响应变得非常奇怪，甚至主动替用户提问。

在构建消息列表时，我从数据库或缓存里取出历史消息后，会做一步顺序校验，格式不符就修正后再发送。这个逻辑虽然不起眼，但对生产环境的稳定性帮助很大。

6. 进阶玩法：函数调用、生态接入与多Agent协作

跑通基础调用后，可以把API能力进一步放大。这里讲三个方向：Function Calling、生态工具集成、多Agent协作。

6.1 Function Calling机制

Function Calling让模型可以按需调用外部函数，实现从“只能聊天”到“能操作业务系统”的跨越。机制本身不复杂：你在请求里声明一份函数清单，描述函数名、参数类型和用途，模型在需要时会输出一个结构化的调用请求，而不是纯文本回复；你执行函数拿到结果后，再把结果作为一条消息交给模型，模型综合上下文给出最终回复。

比如做一个天气助手，可以声明一个get_weather函数：

json复制{
    "name": "get_weather",
    "description": "获取指定城市的当前天气",
    "parameters": {
        "type": "object",
        "properties": {
            "city": {"type": "string", "description": "城市名"}
        },
        "required": ["city"]
    }
}

当用户问“北京今天热吗”，模型就会输出一个tool_calls，指示调用get_weather并把参数设为{"city": "北京"}。你的程序接收到这个请求后，从天气服务拉取数据返回给模型，模型再组织成自然语言回复。

这个能力的价值在于，模型不再局限于内部知识，而是可以查询实时数据、操作数据库、调用外部服务，成为真正的业务枢纽。

6.2 和主流生态的集成方式

因为Deepseek API兼容OpenAI接口规范，所以大量现有工具可以无缝对接。

在LangChain或LlamaIndex这类框架里，你通常只需要替换base_url和api_key，就能把Deepseek作为LLM后端引入。我之前用Java对接Qwen Embedding并存储到Milvus向量库时，就发现LangChain4j这类框架已经把适配层做好了，需要自己写的只是配置项。Deepseek的接入路径也类似，关键是把base_url指对，模型名写对。

另外，Codex等AI编程工具也可以通过自定义接口接入Deepseek模型。这类工具本质上是把编辑器里的上下文、代码片段组装成messages请求，发送给模型并把结果渲染回编辑器。接入时注意两点：一是确认工具支持自定义模型端点，二是在模型名和上下文长度上做好适配，否则代码补全场景很容易因为上下文超限报错。

6.3 多Agent协作模型：把子Agent当工具调用

最近多Agent架构讨论很热，很多人一上来就用复杂的主从模式，让一个主Agent动态规划任务，再派发给多个子Agent并行执行。这个模式本质上和Function Calling是一体的，甚至可以说是同一种思想：每个子Agent就是被包装成特殊工具的“函数”。

我在自己的项目里就是这么做的：主Agent接收到用户任务后，先做任务分解，识别出需要检索资料、需要计算、需要写代码等不同子任务，然后通过工具调用接口唤起对应的子Agent，子Agent完成后的输出作为工具结果返回，主Agent再汇总成最终回复。

这套架构把“模型只能回答问题”升级成了“模型可以编排工作流”，背后要处理好几件细节：

• 子Agent的调用超时和失败重试要独立管理，不能把整个任务拖死。
• 子Agent的输出要结构化，至少包含状态字段（成功/失败）和内容字段，方便主Agent判断。
• 整个调用链要有trace记录，出现问题时能定位是哪一步出的错。

我的经验是，先不要急于上多Agent，先在一个Agent里把Function Calling吃透，再逐步扩展。一上来就堆架构，很容易陷入调试泥潭。

7. 生产环境稳定性优化与成本控制

API调用上线之后，真正的考验才开始。我把生产环境摸爬滚打的经验总结成几个关键点。

7.1 重试策略与熔断设计

前面讲过指数退避重试，这里补充一个熔断维度。当API连续报错达到阈值，比如连续10次529或5次超时，就不应该继续发请求了，而是直接熔断，让流量走降级方案。否则重试风暴会把你的服务和API服务同时打垮。

熔断器可以用现成的库，也可以自己维护一个简单的状态机。核心逻辑就三条：

• 连续失败次数超阈值 -> 打开熔断，后续请求快速失败。
• 熔断状态下，每隔一段时间放一个探测请求，成功则关闭熔断。
• 熔断打开期间，接口返回降级内容或排队等待。

7.2 并发控制与会话复用

并发控制能保护的是API账户和下游系统。不要无脑把并发调高，每个账户的Rate Limit是有限的。要做一个客户端级别的并发控制队列，限制同时处理中的请求数量。

多线程环境下，如果用同一个requests.Session复用连接，连接池的socket可能闲置后被服务端关闭，再次使用会抛连接异常。建议设置requests.adapters.HTTPAdapter的pool_connections和pool_maxsize，给每个并发请求预留足够的连接，并打开连接复用时的健康检查。

7.3 成本优化几个实用思路

Token成本在放大规模后非常惊人，优化思路有四个方向：

第一，缓存高频请求。一模一样的输入，没必要每次重新调用模型。搭建一个语义缓存层，用户请求先检索缓存，命中就直接返回。我用过基于向量检索的缓存方案，相似度达到阈值就视为命中。

第二，控制上下文长度。很多请求其实不需要把全部历史都带过去，能裁剪就裁剪。上下文缩短，输入Token费用直接下降。

第三，合理设置temperature。业务场景里如果只需要“准确答案”，不要把温度调太高，否则模型可能每轮给出不同答案，业务不稳定，还会增加调试成本。

第四，利用模型的Flash版本或轻量模型做前置路由。可以先让轻量模型做意图识别、粗分类，再把复杂任务交给Pro模型。整套流程下来，成本能降不少，且体验几乎无感。

7.4 从“能调用”到“稳定可用”的最后一公里

最后想认真强调一个被频繁忽略的细节：监控与日志。

生产环境接入API后，至少要埋以下监控指标：请求量、成功/失败比例、分位数延迟（P50/P95/P99）、Token消耗量、各错误码出现次数。我见过太多团队上线前没有打日志，出问题时一头雾水。

日志里必须记录请求ID、模型名、请求Token数、响应Token数、耗时、错误码。服务端返回的响应头里通常带有一个唯一的请求ID，记得抓出来。排查问题的时候，拿这个ID找平台支持，会话效率会提升很多。

自测的经验是，在上线前用真实业务数据做至少500次压测，观察P95延迟和错误率。500次压测能暴露绝大多数连接、超时、并发问题。压测不过关就上线，就是把问题留给线上用户。

8. 实测中的几个小经验和最后的建议

文章最后，分享几个实际调用的零散经验，不成体系，但都是真金白银踩出来的。

一个是不同的API客户端库在错误信息展示上差异很大。有的库会把原始响应体完整抛出来，有的只给一句话。建议统一封装一层API调用层，把所有异常都转成标准格式，抛出状态码、错误信息、原始请求ID，避免各业务方各自的处理方式。

另一个是模型返回格式不稳定问题。纯文本输出可以直接用，但如果你要求模型返回JSON，不要直接json.loads。模型有可能输出Markdown代码块，或者在JSON前后多了解释文字。稳妥做法是让模型按固定格式输出，然后用正则或后处理剥离外围内容，再做解析。我在生产环境里加了一个“强制JSON模式”的开关，开启后模型严格按JSON结构返回，省掉了大量后处理逻辑。

再一个是长文生成的分段处理。一次请求生成万字长篇并不可靠，不仅容易超时，也容易截断。我习惯把任务分解成多个段落，每段单独生成，再拼接。和纯上下文管理不同，这属于任务编排层面的事，但API调用的思维深度就在这里体现。

Deepseek模型的在线API调用，本质上没有想象中复杂，但也没有想象中那么简单。它的核心链路很短，短到几行代码就能跑通；但要做到生产可用，围绕稳定性、成本、监控的配套建设才是真正的重头戏。希望这篇文章能让你少走一些弯路。我自己从开始对接到现在，踩过的坑基本都写在上面了，如果你在实操中遇到其他奇怪的报错，先试着往请求格式、模型名、超时和重试这几个方向排查，大概率能快速定位问题。