一把 key，两套协议：ByteSpike 为什么让 DeepSeek 同时跑 OpenAI 和 Anthropic 形式

在 ByteSpike 上一次网关更新之前，想在 DeepSeek 上同时用两套协议的客户得做两遍工作。一个 key 给 `api.deepseek.com/v1/chat/completions`，另一个账号给 `api.deepseek.com/anthropic/v1/messages`。Secret manager 存两份凭证、SDK config 写两套 base URL、账单上对两份记录。

能跑，但难看。对跑混合 workload 的团队特别烦：Cursor 那类客户端用 OpenAI Chat Completions、DOSIA 那类 Agent harness 用 Anthropic Messages，两边都想打 `deepseek-v4-pro` 同一个模型质量。

修法：一把 key，按 path 路由

ByteSpike 现在用一份上游凭证解析两套 DeepSeek 协议。你调 `/v1/chat/completions`，请求路由到 DeepSeek 的 OpenAI 形 endpoint；调 `/v1/messages`，同一把上游 key 路由到 DeepSeek 的 anthropic-compat endpoint。模型名一样 (`deepseek-v4-pro`)、响应质量一样，协议形态两套 —— 客户端用自己已经会的那套。

实际用起来什么样

OpenAI-SDK 代码，换 `base_url` 和 model 名，跑通。

`curl https://llm.bytespike.ai/v1/chat/completions -H "Authorization: Bearer $BYTESPIKE_API_KEY" -d '{"model":"deepseek-v4-pro", ...}'`

Anthropic-SDK 代码，换 base URL 和 model 名，跑通。同一把 key。

`curl https://llm.bytespike.ai/v1/messages -H "x-api-key: $BYTESPIKE_API_KEY" -H "anthropic-version: 2023-06-01" -d '{"model":"deepseek-v4-pro", "max_tokens":1024, ...}'`

为什么这事值得做

• **Agent 代码就是 Agent 代码。** DOSIA Agent 模式用 `tool_use` block，永远不必为了调 DeepSeek 学 OpenAI 形态。
• **Chat 代码就是 Chat 代码。** Cursor / Cline 保留 OpenAI Chat Completions adapter，不用让 codebase 学 anthropic-version header。
• **一份账单、一份凭证、一个轮换节奏。** 轮换 ByteSpike key，两套协议一起轮 —— 不会一半失效一半还能用。

底下是怎么实现的

Admin 配 DeepSeek 上游账号时，填两个 base URL：OpenAI 形那个和 anthropic-compat 那个。ByteSpike 路由层把它们当成同一个 channel 的两张脸。客户面 API key 永远不知道某个具体请求被哪张脸服务 —— 这个细节只在 `x-bytespike-channel` 响应 header 里露出来给调试用。

这个模式可以泛化。月之暗面、智谱、MiniMax 都用同样的方式暴露双协议上游，ByteSpike 用同一套 one-key 抽象包它们。后续上游接入第二条协议时，你会在 provider catalog 里看到这个 multi-endpoint 模型铺开。

上手

现有 ByteSpike key 用户今天就可以用两套协议调 `deepseek-v4-pro` 和 `deepseek-v4-flash`。新用户去 console.bytespike.ai 注册。完整 provider 文档：docs.bytespike.ai/providers/deepseek。