DeepSeek V4 API 接入:Flash 与 Pro

先说结论:两个 ID,一个接口

DeepSeek V4 系列在 kkaiapi 上是两个独立的模型 ID:deepseek-v4-flash 和 deepseek-v4-pro,价格不同,请求格式完全一样。base_url 填 https://api.kkaiapi.com/v1,model 选对应的 ID,标准的 /v1/chat/completions 请求即可,不需要单独装 DeepSeek 的 SDK。 ID 拼写要精确,两个模型价格不同,打错字直接返回模型不存在,而不是静默换成另一档。接入自动化脚本前,先查一次 /v1/models 核对拼写。

curl https://api.kkaiapi.com/v1/chat/completions \
  -H "Authorization: Bearer sk-你的kkaiapi密钥" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-flash",
    "messages": [{"role": "user", "content": "用一句话解释什么是注意力机制"}]
  }'

Flash 和 Pro 怎么选

实际项目里常见的做法是分层调用:简单请求默认走 Flash,复杂请求或者 Flash 输出质量不达标时再升级到 Pro,两档共用同一份 Key 和同一份用量日志,统计成本时也能分开看。

• deepseek-v4-flash:轻量任务的默认选择,响应快、价格低,适合摘要、分类、简单问答、高并发场景
• deepseek-v4-pro:复杂推理、长链路 Agent、代码生成这类需要更强能力的任务,价格更高但换来更稳的输出质量
• 两者请求格式完全一样,原型阶段建议先用 Flash 跑通逻辑,评测发现质量不够再切 Pro,只改一个字符串

Python 与 JavaScript 快速接入

两个官方 OpenAI SDK 都支持自定义 base_url,model 字段原样传字符串。同一个客户端对象上一行调 deepseek-v4-flash,下一行就能换成 deepseek-v4-pro 或者 claude-sonnet-5,方便做 A/B。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["KKAIAPI_KEY"],
    base_url="https://api.kkaiapi.com/v1",
)

resp = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[
        {"role": "system", "content": "你是一个简洁的助手。"},
        {"role": "user", "content": "把这份会议记录里的行动项提取出来:..."},
    ],
    max_tokens=2000,
)
print(resp.choices[0].message.content)
print(resp.usage)

官方的上下文缓存机制,以及为什么中转不传递这个折扣

DeepSeek 官方平台有一套自动的磁盘缓存机制,不需要改代码就默认开启:新请求如果和之前处理过的内容有相同的前缀,匹配上的部分按缓存命中价计费,没匹配上的部分按标准价计费,命中与未命中的 token 数量在返回结果的 usage 字段里都能看到。这套机制要求前缀完全匹配、单元级对齐,不保证命中率,是"尽力而为"式的优化,不是承诺。 这里要诚实地说清楚一点:经 kkaiapi 调用 DeepSeek V4 的两个 ID,按上表的固定输入输出单价计费,目录里没有单独的缓存命中价,不管上游是否发生了缓存命中,计费口径都是一样的。如果你的场景恰好是那种超大稳定前缀被反复调用成千上万次、缓存折扣对成本影响巨大的场景,直接找 DeepSeek 官方平台可能更划算;中转的价值在于多模型统一入口和免翻墙直连,不在于转售无法计量的上游缓存折扣。

什么样的 prompt 结构对官方缓存友好

这几条即使不追求官方缓存折扣也值得遵守,因为它同时也是更容易调试的 prompt 结构:每次请求和上一次的差异只出现在末尾。

• 把稳定内容放在最前面:系统提示词、工具定义、few-shot 示例,顺序固定、逐字节不变
• 把易变内容放在最后面:用户的新消息、检索到的文档、时间戳,凡是会变的都放在后面
• 不要把变化的内容插进前缀里:系统提示词里模板化一个时间戳或请求 ID,会让整个前缀从那个字节开始全部失效
• 只追加不重写:对话历史只在末尾增长会保住之前的匹配,反过来在开头做摘要或重排会导致从头开始失配

验证接入与排查首次调用

接入前先查一次自己 Key 能调的模型列表,确认 deepseek-v4-flash 和 deepseek-v4-pro 都在里面。 401 多半是 Key 没导出到当前 shell;404 常见于 base_url 漏了 /v1;模型不存在多是拼写问题,两个 ID 都是全小写带连字符;finish_reason 是 length 说明 max_tokens 设小了,先调大再评判输出质量。

curl -s https://api.kkaiapi.com/v1/models \
  -H "Authorization: Bearer sk-你的kkaiapi密钥" | grep deepseek

常见问题