调用一个模型需要什么

你不用会写代码，但得知道工程师在说什么。一次模型调用需要的东西少得出奇：往哪发、用哪个模型、算谁的钱——就这三样。

三件套

① base_url ——「往哪发」。模型服务的地址。用官方就填官方的，用云平台就填云平台的，用自建网关就填你自己那台。

② 模型名 ——「用哪个」。一串标识符，指定这次要哪个模型来干活。同一个地址下通常有几十个模型可选。

③ API Key ——「算谁的钱」。一串密钥，既是身份凭证也是账单归属。谁拿着它，谁就能用你的额度。

除此之外就是这次要发的内容本身（提示词、历史对话）和一些调用参数。接入这件事，本身没什么复杂的。复杂的从来是接入之后：怎么控成本、怎么处理失败、怎么验收质量。

为什么都兼容同一套格式

这是接入时最省事的一条常识：绝大多数模型平台，都兼容同一套接口格式（业内通称「OpenAI 兼容格式」）。

原因不难理解。这套格式先出现、生态工具最多，后来者如果自己搞一套，客户迁移过来就要重写代码——谁也不想给自己设这个门槛。于是大家都选择兼容。

这件事对你的实际意义很大：换厂商往往只需要改 base_url 和模型名两个字段。所以当工程师说「换个模型很快」，多数时候他没夸口。

但有两个前提你得追问。第一，提示词要重调。接口通了不等于效果一样，不同厂商对同一段提示词的反应差别很大，通常需要针对性调整。第二，非通用功能不一定兼容。各家的工具调用、结构化输出、缓存机制细节不同，用得越深，迁移成本越高。

所以真正的建议是：从第一天起，把模型调用封装在你自己的一层里。业务代码只调你自己的接口，具体用哪家在那一层里决定。这样换厂商、加备用、做降级，都只改一个地方。

模型名里的坑

模型名看着只是个字符串，里面有几个值得留意的地方。

版本号和日期后缀。很多模型名带具体版本或日期，比如某个模型的 2026 年 7 月版。指定到具体版本，行为就是稳定的。

`-latest` 这类别名要小心。它指向该系列的最新版本，厂商一发新版，你的调用自动切过去。听起来省事，实际上意味着：某天早上你的效果、延迟和账单可能全变了，而你们没改过任何代码。

这在产品上是个真麻烦——问题很难排查，因为所有人都确信「我们什么都没动」。

建议：生产环境固定到具体版本，升级当成一次正常发版来做——先用你那组固定样例跑一遍，确认没退步再切。测试环境可以用 latest，提前知道下一版会有什么变化。

密钥的底线

这一条没有商量余地：API Key 绝对不能出现在前端。

网页的 JavaScript、App 的安装包，都是用户可以拆开看的。密钥放进去，等于公开贴出来。别人拿到之后就能拿你的额度随便跑，账单归你——而且这类事故通常几小时就能烧掉一大笔钱。

正确做法是：密钥只存在你自己的后端，前端调你的接口，由你的后端去调模型。这一层中转是必须的，没有例外。

顺带一提，有了这一层之后，你还能免费拿到几样很有用的东西：限流（防止单个用户刷爆你的额度）、用量统计（哪个功能花了多少钱）、审计日志（出问题能查）、统一降级（主模型挂了自动切备用）。这些都是产品迟早要用上的。

还有两条一起记住：密钥要能随时作废重发（怀疑泄露就立刻换，别犹豫），以及不同环境用不同的密钥（测试环境泄露不至于影响线上）。