一个 API Key 切换 DeepSeek、GLM、Kimi：Python 多模型接入指南

对于正在开发 AI 应用的开发者来说，接入第一个大模型 API 通常不难。真正麻烦的是，项目逐渐增加功能后，需要测试不同模型、比较调用成本，或者在不重写业务代码的情况下更换模型。

例如，一个 Python 应用可能用 DeepSeek 处理常规文本任务，用 GLM 分析图像或视频，再用 Kimi 处理长代码和复杂材料。如果每接入一个模型，就要维护一套客户端配置、认证方式和调用逻辑，后续维护成本会不断增加。

一种更容易管理的方式，是将模型调用配置与业务代码分离，通过统一 API 接入层管理密钥和请求地址，再使用模型 ID 选择实际调用的模型。

本文以 Python 和 OpenAI SDK 为例，介绍多模型切换的实现方式，并说明模型 ID、参数兼容性、调用验证和费用统计需要注意的问题。

一、为什么多模型项目需要统一调用入口？

不同模型可能使用相似的聊天接口，但它们在模型名称、推理参数、工具调用和多模态能力方面仍然存在差异。

如果业务代码直接绑定某个模型，切换时就可能需要修改多个文件。例如，模型名称写在业务逻辑中，API 地址放在配置文件中，密钥又分散在不同环境变量里。一旦增加新的模型，开发者就需要逐一检查这些配置。

统一调用入口可以将其中一部分重复工作集中管理。

常见的改进包括：

• 减少重复配置： 在符合接口兼容条件时，多个模型可以共用一套客户端初始化逻辑。
• 简化模型切换： 将模型 ID 放在配置层，而不是散落在业务代码中。
• 方便对照测试： 使用相同的输入和验收规则测试不同模型。
• 统一记录调用信息： 将模型名称、耗时、Token 用量和任务结果关联起来。

需要说明的是，统一 API 入口并不意味着所有模型都具有完全一致的功能。实际支持情况仍然取决于接入平台、具体模型版本和接口协议。

二、接入前需要准备什么？

开始编码之前，先确认以下条件：

• 已创建可用的 API Key。
• 已确认接入平台提供的 API Base URL。
• 已从模型列表中复制目标模型的准确 ID。
• 已确认目标模型支持当前使用的接口和参数。
• 已准备好用于测试的简单请求。

对于通过统一 API 接入层调用模型的项目，Base URL 和模型 ID 尤其重要。

Base URL 决定请求发送到哪里，模型 ID 则用于指定请求调用哪个模型。两者的作用不同，不能互相替代。

以 星链 API 为例，平台公开的接入说明采用 OpenAI 兼容接口，并提供 Python 等语言的调用方式。开发者应以当前控制台和模型详情页显示的地址、模型标识为准，不要直接套用其他平台的配置。

三、安装 OpenAI SDK 并配置环境变量

如果项目尚未安装 OpenAI Python SDK，可以执行：

pip install -U openai

接下来配置 API Key。

macOS 或 Linux 环境可以使用：

export XINGLIAN_API_KEY="你的API_KEY"

Windows PowerShell 可以使用：

$env:XINGLIAN_API_KEY="你的API_KEY"

不要将真实密钥直接写入公开代码仓库，也不要把密钥提交到 Git。正式项目建议使用环境变量或专门的密钥管理工具。

四、完整代码：通过配置切换 DeepSeek、GLM 和 Kimi

下面将客户端初始化与模型选择分开。示例使用统一入口的配置方式，模型 ID 仅作结构示例，正式调用前必须确认目标平台当前实际支持的名称。

import os
from openai import OpenAI

API_KEY = os.environ["XINGLIAN_API_KEY"]
BASE_URL = "https://xinglianapi.com/v1"

client = OpenAI(
    api_key=API_KEY,
    base_url=BASE_URL,
)

# 模型 ID 必须以当前模型广场显示的值为准
MODELS = {
    "deepseek": "deepseek-v4-pro",
    "glm": "glm-5.3-flash",
    "kimi": "kimi-k3",
}

def ask_model(provider, prompt):
    if provider not in MODELS:
        raise ValueError(f"不支持的模型配置：{provider}")

    model_id = MODELS[provider]

    response = client.chat.completions.create(
        model=model_id,
        messages=[
            {
                "role": "system",
                "content": "请准确回答问题，优先提供可验证的信息。"
            },
            {
                "role": "user",
                "content": prompt
            }
        ],
    )

    answer = response.choices[0].message.content

    # 记录请求的模型配置和用量，便于后续排查
    print("请求模型：", model_id)

    if response.usage:
        print("输入 Token：", response.usage.prompt_tokens)
        print("输出 Token：", response.usage.completion_tokens)
        print("总 Token：", response.usage.total_tokens)

    return answer

if __name__ == "__main__":
    question = "请解释 Python 中列表和元组的主要区别。"

    for provider in ("deepseek", "glm", "kimi"):
        print(f"\n===== {provider} =====")

        try:
            result = ask_model(provider, question)
            print(result)
        except Exception as exc:
            print(f"调用失败：{type(exc).__name__}: {exc}")

这段代码演示了如何将三个候选模型放入同一份配置，再通过 provider 参数切换调用目标。

需要注意，代码中的模型 ID 不保证在每个账户或平台上都可用。执行前应核对模型列表；如果某个模型暂未开放、名称发生变化，或者使用的接口不支持 Chat Completions，就需要调整配置或调用方式。

此外，程序打印的是请求配置中的模型 ID，不足以单独证明上游最终执行的模型。对于正式的模型对照测试，还应结合平台返回信息、请求日志及可获得的服务端记录进行核验。

扩展：支持流式输出版本（可选）

很多业务场景需要流式返回，下面是基于上面函数改造的流式版本，方便直接替换使用：

def ask_model_stream(provider, prompt):
    if provider not in MODELS:
        raise ValueError(f"不支持的模型配置：{provider}")

    model_id = MODELS[provider]

    stream = client.chat.completions.create(
        model=model_id,
        messages=[
            {"role": "system", "content": "请准确回答问题，优先提供可验证的信息。"},
            {"role": "user", "content": prompt}
        ],
        stream=True,
    )

    print("请求模型：", model_id)
    for chunk in stream:
        if chunk.choices and chunk.choices[0].delta.content:
            yield chunk.choices[0].delta.content

调用示例：

if __name__ == "__main__":
    for chunk in ask_model_stream("kimi", "简单介绍多模型路由架构"):
        print(chunk, end="")

五、怎样验证切换后调用的是正确模型？

多模型接入中，一个容易被忽略的问题是：程序可以正常返回内容，并不代表模型切换一定符合预期。

常见原因包括：

• 模型 ID 使用了过期名称或错误的版本后缀。
• 配置文件或环境变量覆盖了预期的模型设置。
• 接入层对模型别名进行了映射。
• 当前账户没有目标模型的调用权限。
• 实际请求使用了不同的 API 地址。

建议按以下顺序检查。

第一步：核对配置。 在发出请求之前，记录本次使用的 Base URL 和模型 ID，但不要记录完整 API Key。

第二步：查看响应。 检查响应中是否提供模型标识、请求 ID 或其他可用于追踪的字段。

第三步：查看调用记录。 如果平台提供用量明细或请求日志，应将其与应用端记录进行关联。

第四步：固定测试条件。 使用相同的输入、提示词和验收规则进行对照，避免因为测试条件不同而误判模型表现。

如果请求返回了正确格式的回答，但模型身份无法确认，就不应直接将这次结果纳入严格的性能比较。

六、模型切换时，哪些参数不能直接照搬？

统一客户端只能简化公共调用部分。对于推理参数、工具调用和多模态输入，仍需要单独验证兼容性。

表格

例如，某个模型支持 reasoning_effort，不代表另一个模型也接受同样的参数。即使请求没有报错，也需要确认参数是否真正生效。

比较不同模型时，建议先使用公共参数完成基础测试，再逐项增加推理设置、工具调用或多模态输入。这样更容易判断错误究竟来自模型能力，还是接口适配问题。

七、常见错误及排查方法

表格

八、从模型切换走向可维护的多模型架构

当项目从一个模型扩展到多个模型后，建议进一步将模型配置独立为配置文件，并建立统一的调用日志。

每次调用至少记录：

• 任务类型和模型 ID；
• 请求开始时间、完成时间和错误类型；
• 输入与输出 Token；
• 重试次数和最终任务结果；
• 可获得的实际费用及请求追踪标识。

有了这些数据，开发者就能比较不同模型在同一任务中的表现，而不是仅凭主观感受选择模型。

例如，简单文本处理可以优先测试成本较低的候选模型；复杂代码修复则应重点比较测试通过率和完整任务耗时。模型是否适合生产环境，最终需要由真实业务样本验证。

对于希望减少多套接口配置和密钥管理工作量的团队，可以了解 星链 API 的统一接入方式。但在接入前，仍应确认目标模型是否开放、接口协议是否兼容，以及平台实际计费和日志规则。

结语

一个 API Key 切换多个模型的价值，不只是减少几行配置，而是让模型选择成为可以管理、测试和维护的工程环节。

使用 OpenAI SDK 与统一 API 入口，可以简化公共调用代码；将模型 ID、参数和服务地址独立配置，则可以降低后续调整的影响范围。但协议兼容不等于功能完全一致，实际模型身份也不能仅凭客户端配置确认。

对于开发者而言，更稳妥的路径是先完成最小请求，再验证模型身份和参数兼容性，最后通过真实业务样本比较质量、延迟与费用。这样建立的多模型调用体系，才更容易随着模型版本迭代而持续维护。