DeepSeek API 接入指南：用 OpenAI SDK 调用兼容端点（2026 版）

DeepSeek 是国内开发者用量最大的开源模型系列之一，但官方 API 的网络可达性、充值方式和账号管理并不总是顺手。通过一个 OpenAI 兼容的第三方端点调用 DeepSeek 全系模型，可以复用你已有的 OpenAI SDK 代码和密钥管理体系，迁移成本接近于零。这篇指南只讲实操：在哪里拿 Key、端点怎么填、四种语言的调用示例、推理模型的特殊返回字段怎么处理，以及最常见的五类报错怎么排查。

准备工作：获取 API Key

调用之前需要三样东西：API Key、端点地址、模型 ID。前两样都来自平台控制台：

注册并登录

在 EXAIV 注册账号并完成登录，进入控制台。

生成 API Key

在控制台的密钥管理页创建一个 API Key。Key 生成后只完整显示一次，立即复制保存。

确认余额

新账号通常带有可用额度；在控制台确认余额大于零，再开始调试。计费与充值见定价页。

Key 的用法和 OpenAI 一样：放进请求头 Authorization: Bearer <你的Key>。所有模型共用这一个 Key，切换模型只改请求体里的 model 字段。

端点与兼容性

EXAIV 的 DeepSeek 端点是 OpenAI Chat Completions 兼容格式：

这意味着：官方 openai Python SDK、openai Node.js SDK、LangChain、LobeChat、Dify、Cherry Studio 等一切支持「自定义 OpenAI 兼容端点」的工具，都可以直接接入，不需要专用客户端。

第一次调用：curl 验证

先用手动请求确认 Key 和端点都正常：

curl https://exaiv.com/api/ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer 你的APIKey" \
  -d '{
    "model": "kimi-k3",
    "messages": [
      {"role": "user", "content": "用一句话介绍你自己"}
    ]
  }'

返回体是标准的 OpenAI 格式，正文在 choices[0].message.content。看到这一步成功，说明 Key、端点、模型 ID 三要素都没问题，后面的接入失败就和这三件事无关了。

Python 接入：openai SDK

安装官方 SDK 后，只需要改两个参数：

from openai import OpenAI

client = OpenAI(
    api_key="你的APIKey",
    base_url="https://exaiv.com/api/ai/v1",
)

resp = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {"role": "system", "content": "你是一个严谨的技术助手"},
        {"role": "user", "content": "解释一下什么是上下文窗口"},
    ],
)
print(resp.choices[0].message.content)

原有代码从 OpenAI 迁移过来时，通常只改 base_url、api_key 和 model 三处。函数调用、JSON 输出、多轮对话这些 Chat Completions 标准能力的用法保持不变。

Node.js / TypeScript 接入

const client = new OpenAI({
  apiKey: process.env.EXAIV_API_KEY,
  baseURL: "https://exaiv.com/api/ai/v1",
});

const resp = await client.chat.completions.create({
  model: "kimi-k3",
  messages: [{ role: "user", content: "写一个快排的 TypeScript 实现" }],
});
console.log(resp.choices[0].message.content);

密钥从环境变量读取，不要写进代码仓库。Node 侧同样沿用 OpenAI SDK 的全部习惯用法。

流式输出

流式与非流式的区别只在请求参数和消费方式：

stream = client.chat.completions.create(
    model="kimi-k3",
    messages=[{"role": "user", "content": "讲一个技术圈的小故事"}],
    stream=True,
)
for chunk in stream:
    delta = chunk.choices[0].delta
    if delta and delta.content:
        print(delta.content, end="", flush=True)

流式模式下正文以增量形式出现在 delta.content。Web 应用建议直接透传给前端打字机渲染，不要等全文拼完再返回。

推理模型：reasoning_content 字段

部分模型是推理模型：回答之前会先输出一段内部思考过程。当你调用的模型支持时，思考过程放在单独的字段里：

• 非流式：choices[0].message.reasoning_content 是思考文本，content 是最终回答
• 流式：增量分别在 delta.reasoning_content 与 delta.content

处理原则很简单：最终回答永远读 content；reasoning_content 是过程文本，给用户展示或写入日志都可以，但不要把它拼进下一轮的对话历史。

resp = client.chat.completions.create(
    model="kimi-k3",  # 换成你实时目录里有推理能力的模型 ID
    messages=[{"role": "user", "content": "9.11 和 9.8 哪个大"}],
)
msg = resp.choices[0].message
print("思考:", (msg.reasoning_content or "")[:200])
print("回答:", msg.content)

推理模型通常会输出更多 token、等待时间更长，适合数学、代码审查、逻辑推理类任务；日常问答用非推理模型响应更快。不是每个模型都会填充 reasoning_content，依赖前先查模型卡。

模型 ID 速查表（DeepSeek 家族参考）

下表是 DeepSeek 家族的参考清单。其中多数 ID 现已进入 EXAIV 目录（可用性以 /models 实时为准）；其余用于第三方渠道和本地部署。实际调用请使用实时目录的 ID：

选型逻辑：长文档、大代码库分析选 V4 系列（百万级上下文）；日常对话和批量文本任务选经典线，性价比高；数学与复杂推理选 R1。具体怎么在场景里取舍，见模型选择指南（相关阅读）。

常见报错排查

401 Unauthorized。 Key 无效或格式错误。检查三点：Key 是否完整复制（首尾无空格）、请求头是否是 Authorization: Bearer 前缀、Key 是否已被吊销。重新生成一个 Key 是最快的验证方式。

404 Not Found。 十有八九是 base_url 的问题。常见错误：写成 https://exaiv.com（少了 /api/ai/v1）、或多写了一层 /v1 变成 /api/ai/v1/v1。SDK 的 base_url 应该填到 /api/ai/v1 为止，路径后缀由 SDK 自己拼。

429 Too Many Requests。 触发限流。先做客户端指数退避重试；持续出现说明并发规格需要调整，联系平台或降低请求并发。

上下文超限。 报错信息通常包含 context length 字样。检查两处：messages 数组总长度是否超过模型上下文窗口（对照上表），以及是否把上一轮的 reasoning_content 拼进了历史。

余额类错误。 控制台余额为零或不足时调用会失败，不会产生负余额。充值后立即恢复，Key 和配置不受影响。

从其他渠道迁移的检查清单

如果你已经在对 DeepSeek 的调用走别的渠道，迁移到兼容端点只需核对四项：

1. base_url 换成本文端点，Key 换成平台 Key
2. 模型 ID 对齐速查表——不同渠道的同一模型命名可能不同，以本文表格为准
3. 跑一组回归用例：拿线上真实的五到十个典型请求重放，对比回答质量与延迟
4. 确认流式与函数调用场景：如果业务依赖 stream 和 tools 字段，各跑一遍冒烟测试

迁移期间不需要停服：新旧渠道可以并行跑，按流量比例逐步切换。

FAQ

相关阅读

• Chat Completions API 参考 — 请求与响应格式详解
• DeepSeek 模型怎么选 — V4 与经典线的场景化选型
• 定价 — 实时价格与充值套餐
• Dify 集成指南 — 不写代码搭应用