上周帮一个做跨境电商的朋友排查接口问题，卡了整整一下午。他把 GPT API 接进了一套自动客服系统，症状很怪：本地测试一切正常，部署到服务器后有的请求能返回，有的请求直接超时，偶尔还会报一条 model not found。我一层层往下查，最后发现根子不在代码，而在接入前的四个基本项没确认清楚——API 地址、模型名称、计费倍率和稳定性指标。这个情况太常见了，大多数人拿到 key 的第一反应是跑通一个 demo，然后就开始写业务，等到服务出问题才回头补课。
这篇文章就专门聊这四件事。不管你是接 OpenAI 官方接口，还是接第三方提供的 OpenAI 兼容网关，只要你是做产品、做工具、做自动化脚本的开发者，接入前建议把这四项全部确认好。后面我会给出能直接用的验证命令、测试脚本和一份检查清单，尽量做到你看完就能照着做，不再被这些基础问题拖住进度。
1. 第一件事：确认 API 地址（base_url）
1.1 地址长什么样，为什么总有人配错
API 地址，严格说是 base_url，是客户端真正发起 HTTP 请求的基础路径。它一般长这样：
https://your-api.example.com/v1把它拆开看，其实是三层：
- 协议层：生产环境必须是 https，不要用 http。明文传输会把你的 key 和用户消息全部暴露在网络上，一旦被抓包就是安全事故。
- 主机层：服务商的域名，这是通道的唯一标识。同一个 key 在不同域名下完全可能是两套账户体系。
- 路径前缀：
/v1是协议版本标记，OpenAI 兼容接口基本都靠这个前缀区分 API 路径。
最常见的配置错误是少了/v1。SDK 内部拼 URL 时，会把 base_url 和具体接口路径拼接在一起，如果你填的是https://your-api.example.com，最终请求会变成/chat/completions，而不是/v1/chat/completions，服务端返回 404，很多人却在找代码和 key 的问题，白费功夫。还有一种情况是在 base_url 末尾多加一个斜杠，变成https://your-api.example.com/v1/，某些严格的服务端或者 SDK 会把路径拼成双斜杠，虽然不少网关会宽容处理，但没必要去赌这个。
另外要留意，接入第三方网关时，控制台里的"登录地址""官网地址"和"API 接入地址"通常不是同一个东西。登录页是给人看的，API 地址是给程序用的。拿到配置后先看一眼结构，凡是长得像https://xxx.com/dashboard这种有路径的，基本可以判断不是 API 地址。
1.2 官方入口与第三方网关的差异
官方入口的 base_url 相对固定，文档里写得清清楚楚，key 也在官方后台申请。但在实际项目中，尤其在国内做产品的团队，经常会用第三方 API 网关来统一管理多个模型，这时候地址确认就更要小心。
第三方网关虽然打着"OpenAI 兼容"的旗号，兼容程度却是参差不齐的。接入前最少花十分钟确认四件事：
- 鉴权方式是否完全兼容。大多数是
Authorization: Bearer <key>，但有些网关要求额外加自定义请求头，比如x-api-key。 - 是否支持 OpenAI 官方 SDK 直接换 base_url 使用。有些网关只能通过自己封装的 SDK 调用，没法直接用官方 SDK 改地址。
- 是否支持
GET /v1/models这个探测接口。如果连模型列表都拉不到，说明这套网关对 OpenAI 协议的兼容程度非常有限。 - 是否同时支持
/v1/responses和/v1/chat/completions。新版本的 responses 接口是老版 chat 接口的演化方向，但第三方网关往往只实现了老版 chat 接口，或者只实现了新版 responses，接错路径就是 404。
我的建议是，接任何通道前，先拿 curl 拉一下GET {base_url}/models。这个接口是 OpenAI 协议最基础的探针，它通了，后面聊天接口大概率能通；它都不通，别急着往下走。
1.3 用环境变量管好地址，别写死在代码里
地址这种东西，千万不要写死在业务代码里。同一个项目在本地、测试、生产环境可能用不同的通道，而且通道切换、故障迁移时也需要改地址，写死在代码里意味着每次都要发版。
目前最顺手的做法是用环境变量配合.env文件管理，示例如下：
GPT_API_BASE_URL=https://your-api.example.com/v1 GPT_API_KEY=sk-xxxx GPT_MODEL=gpt-4o-miniPython 代码里这样读：
import os base_url = os.getenv("GPT_API_BASE_URL", "").rstrip("/") api_key = os.getenv("GPT_API_KEY", "") model = os.getenv("GPT_MODEL", "")注意那句.rstrip("/")，它能避免 base_url 本身就带斜杠时，和后面的路径拼出//chat/completions这种双斜杠。这个细节很小，但踩过的人都知道有多折腾。
1.4 一条 curl 命令，快速验证地址可用性
在写任何 SDK 代码之前，先跑一条 curl，把地址、鉴权、网络连通性一次性验证完：
curl --silent --request GET \ "${GPT_API_BASE_URL}/models" \ --header "Authorization: Bearer ${GPT_API_KEY}"如果正常，会返回一个 JSON 数组，里面带可用的模型 ID。如果失败，状态码直接指向问题范围：
- 401：key 不对，或者鉴权头格式不对。
- 404：地址路径不对，大概率少了
/v1。 - 403：key 有效但没权限访问该资源。
- 超时：网络链路不通，或者域名解析不到。
这一步做完，地址这块就算有底了。接下来进入第二个关键项：模型。
2. 第二件事：确认模型名：不是"用哪个最好"，而是"哪个真的能用"
2.1 模型名是字符串，大小写版本一个都不能错
很多人把模型名当成一个"大概印象"，写代码的时候随手敲一个gpt-4o或者gpt-4o-mini，觉得差不多就行。实际上，模型名是精确字符串，服务端不做任何模糊匹配，大小写、连字符、日期后缀，一个字符都不能差。
我见过最常见的报错是model not found，十有八九是下面几种情况：
- 把
gpt-4o-mini写成了Gpt-4o-mini或gpt4o-mini； - 在请求里带了日期版本号，但网关实际只支持不带日期的基础名；
- 网关把模型映射成了别名，比如文档要求填
gpt-4o-v2，你填官方名gpt-4o就直接报错。
推荐的唯一可靠做法，是把GET /v1/models返回的真实模型 ID 复制到配置里，不要手敲，不要凭记忆。手动输入的每个字符都是隐患。
2.2 按任务类型选模型：先看上下文窗口和价格
模型选型不是越强越好，而是匹配任务。现在大多数 OpenAI 兼容通道都提供下面几类模型，选型时可以参考这张表：
| 模型系列 | 典型上下文 | 适合场景 | 注意点 |
|---|---|---|---|
| gpt-4o-mini | 128K | 闲聊、分类、摘要、结构化抽取 | 速度快、成本低，多数场景首选 |
| gpt-4o | 128K | 复杂指令、格式化输出、较多逻辑判断 | 能力均衡，成本和速度也更高 |
| gpt-4-turbo | 128K | 旧项目兼容 | 新项目不建议选 |
| o 系列推理模型 | 视版本而定 | 数学推理、多步规划、复杂代码 | 延迟高，且 max_tokens 要额外算 reasoning tokens |
选择的基本逻辑是：先评估任务复杂度。如果只是"从文本里抽字段"或者"生成一句回复"，gpt-4o-mini足够；如果需要多步推理、严格遵循复杂指令，再上更强的模型。这背后其实是成本结构差异，下面讲倍率时会详细算这笔账。
2.3 模型能力不等于文本对话：tools、JSON、Vision、Stream 都要实测
一个特别容易被忽略的坑是：很多第三方网关只保证了最基础的文本对话兼容，对高级参数的透传并不完整。你按 OpenAI 官方文档传了tools数组、response_format或image_url，网关可能直接忽略，也可能返回 400。
业务开始前，把下面几项在测试环境里真实验证一遍：
- function calling / tools 参数是否能透传；
- JSON Output（
response_format={"type":"json_object"}）是否支持； - Vision（图片输入）是否支持；
- Stream 流式返回是否支持。
验证方式不复杂，就是用官方 SDK 各写一个最小用例，真实调用一次。不要只读文档，文档说的"兼容"和你实际需要的"兼容参数"往往是两回事。我遇到过不少网关，文档里写着支持 function calling，实际传tools参数直接报Unsupported parameter: 'tools'，这种问题等上线才被发现就晚了。
2.4 别信文档里的别名，以真实模型列表为准
部分网关会提供模型别名，可能是为了做版本管理或者路由到不同上游。比如网关文档说"填gpt4-mini会自动路由到最新的 mini 模型"，但实际请求时你会发现gpt-4o-mini也能用。
接入这类网关，我建议直接拉一次模型列表，把服务端真实暴露的模型名和文档里的别名对照一遍。你最终配置进代码的，应该是一个"服务端确实认识"的字符串，而不是文档里那串"理论上应该能用"的字符串。这一点确定后，模型这块才算过关。
3. 第三件事：算清倍率：计费倍率、输出倍率、上下文倍率
3.1 计费倍率是什么：官方定价 × 倍率 = 你实际付出的钱
聊到成本，就必须说清楚"倍率"这个词。在 GPT API 接入的场景里，倍率通常指第三方网关对官方定价的加价倍数。
比如某个模型官方输入价格是 0.005 美元/千 token，输出价格是 0.015 美元/千 token，网关标了 2 倍倍率，那你实际消耗就是：
输入成本 = 输入 tokens × 0.005 美元/千 × 2 输出成本 = 输出 tokens × 0.015 美元/千 × 2注意，输入和输出的官方单价本来就不是一个价位，乘完倍率之后，输出的成本占比会进一步放大。很多人在接入前没看倍率，只按官方定价给客户报方案，结果月结账单一出来，成本直接是预期的两倍甚至三倍。
第三方网关提供这个倍率本身没问题，核心是你必须在接入前知道它，并且把它写进成本公式里。不知道倍率就上线，等于蒙着眼睛烧钱。
3.2 怎么花十分钟验证真实倍率
文档里写的倍率不一定和实际扣费一致，尤其是一些历史遗留的计费规则。验证方法其实很简单，用"最小回显测试"就能算出来。
第一步，发一段长度可控的 prompt，让模型只回复一个简短的固定内容，比如"OK"。这样输入输出 token 都是可控的。
import os import openai client = openai.OpenAI( api_key=os.getenv("GPT_API_KEY"), base_url=os.getenv("GPT_API_BASE_URL") ) resp = client.chat.completions.create( model=os.getenv("GPT_MODEL"), messages=[{"role": "user", "content": "please reply OK"}], max_tokens=10, ) print(resp.usage) print(resp.choices[0].finish_reason)第二步，从resp.usage里读三个字段：prompt_tokens、completion_tokens、total_tokens。
第三步，在网关后台记录请求前后的余额变化，对比官方理论价格：
理论成本 = prompt_tokens × 输入官方单价 + completion_tokens × 输出官方单价 实际倍率 = 实际扣费 / 理论成本如果实际倍率和文档标称一致，说明计费透明，后面按文档算成本就行。如果不一致，先去找网关那边问清楚，因为这不是差几块钱的事，而是整套成本模型可能都是错的。
3.3 max_tokens 输出倍率：控制输出长度就是控制成本
倍率还可以理解成"输出长度的放大倍数"。max_tokens 设置多少，直接影响生成质量和成本。
这里有个常见规律：max_tokens 设太小，输出会被截断，finish_reason返回length，你拿到的是一段半截话，业务上还得做二次处理，反而更耗成本；max_tokens 设太大，模型会倾向于生成更多冗余内容，输出 token 单价本来就高，账单自然涨得快。
给一个基于经验的上限配置参考：
- 摘要、分类、实体抽取：200~500；
- 代码生成：1000~2000；
- 长文写作：先按目标字数估算，一个汉字大约对应 1~2 个 token，英文一个词大约 1.3 个 token。
新版推理模型还需要注意参数名差异。有些模型用max_completion_tokens，而不是max_tokens。SDK 版本不对，参数会被忽略甚至报错，生成长度就跑偏了。
3.4 多轮对话的上下文倍率：成本会悄悄放大
还有一种"倍率"藏在多轮对话里——上下文膨胀。
每次请求，客户端都要把历史消息全部放进 prompt，所以 prompt_tokens 会随着轮数线性增长。假设每轮用户消息和助手回复加起来 300 tokens，10 轮之后光历史就是 3000 tokens，20 轮就是 6000 tokens。这些历史 tokens 完全按输入价格计费，而且现在很多模型把历史放在 prompt 里，逐轮累积，成本增长的斜率远超你直觉。
用一个简化模型模拟：
| 轮次 | 历史 tokens | 本轮输入 tokens | 本轮输出 tokens | 单次成本（倍率=1） |
|---|---|---|---|---|
| 1 | 0 | 200 | 200 | 低 |
| 5 | 1200 | 1400 | 200 | 中 |
| 10 | 2700 | 2900 | 200 | 较高 |
| 20 | 5700 | 5900 | 200 | 很高 |
看到没，输出基本不变，但输入 tokens 在翻倍涨。对于做聊天机器人、Agent 这类应用的朋友，我强烈建议接入前就把上下文管理方案定下来：要么做滑动窗口裁剪，只保留最近 N 轮；要么定期对历史消息做摘要压缩，用小 tokens 的摘要替代大 tokens 的原文。这本质上就是在控制"上下文倍率"。
3.5 限流配额也是一种"倍率"：RPM/TPM 峰值要算够
最后再提一个和倍率相关的配额问题。不少网关按套餐给 RPM（requests per minute，每分钟请求数）和 TPM（tokens per minute，每分钟 token 数）配额。这里的 TPM 会放大你对成本的理解：一个请求虽然算下来没几个钱，但如果你的业务在某个时间点集中爆发，TPM 超限就是 429。
我在接入前会做一次简单的峰值估算：
峰值并发请求数 × 单请求平均消耗 tokens = 需要的 TPM如果算出来的 TPM 超过套餐配额，就需要调整：降低并发、压缩 prompt、或者升套餐。不懂这一点，上线当天就会被限流打懵。
4. 第四件事：稳定性：用指标定义，用超时和重试保护
4.1 先说清楚：稳定性到底该看哪些数字
很多人说"这个 API 稳不稳"，其实是凭感觉。真正接入前，应该把稳定性变成可量化的数字，最少看四个指标：
- 可用率：成功请求数 / 总请求数，建议 99% 以上才适合生产。
- P95 延迟：把 100 次请求的耗时排序，取 95% 位置的数值，这比平均值更能反映真实体验。
- 错误率分布：4xx、5xx、429 分别占多少。
- 最长连续失败次数：这个指标用于设计熔断和切换逻辑。
接入前，用测试脚本连续跑一段时间，把这些指标记录下来。如果 P95 延迟动不动就超过 10 秒，或者错误率高于 1%，你就得考虑这个通道是否适合放到生产环境。
4.2 超时配置：connect timeout 和 read timeout 要分开设
GPT API 的响应受模型、输入长度、负载影响，延迟波动很大。超时设太短，模型生成长回复时会被误判为失败；超时设太长，用户侧体验又会被拖垮。
我建议把超时分两层：
- connect timeout：TCP 连接建立阶段，设 10 秒足够。
- read timeout：等待响应数据的阶段，普通对话设 60 秒起步，流式模式要更长。
OpenAI Python SDK 里可以这样配置：
client = openai.OpenAI( api_key=os.getenv("GPT_API_KEY"), base_url=os.getenv("GPT_API_BASE_URL"), timeout=60.0, max_retries=0, )注意max_retries=0这个参数。SDK 默认会自动重试 2 次，如果你自己对重试策略有要求，或者不想让 SDK 在超时场景下重复生成，就显式关掉它，把重试逻辑交给上层统一管理。
4.3 429 限流：先看 Retry-After，再加抖动退避
429 表示请求太快，超过配额了。这种错误重试是有意义的，但不能瞎重试。
标准做法是读取响应头里的Retry-After，服务端通常会给一个等待秒数。如果没有这个头，再退回到指数退避策略，比如第一次等 1 秒、第二次等 2 秒、第三次等 4 秒，并且每次加一点随机抖动，避免多线程同时重试形成惊群效应。
import random import time def call_with_retry(fn, max_retries=3): for attempt in range(max_retries): try: return fn() except RateLimitError as e: retry_after = e.response.headers.get("Retry-After") wait = float(retry_after) if retry_after else 2 ** attempt time.sleep(wait + random.uniform(0, 0.5)) raise RuntimeError("still rate limited")4.4 什么错能重试，什么错重试也没用
重试不是所有错误都该做。我在项目里会严格执行下面的分类：
- 可以重试：429、5xx、连接超时、读取超时。这类错误通常是临时性的，换个时间窗口大概率能成功。
- 不可以重试：400、401、403、422。这类错误是请求本身的问题，重试一万次结果一样。
这里有个隐藏的业务风险。OpenAI 兼容接口大多是生成式服务，没有原生的幂等机制。如果你重发同一个请求，可能产生两次不同的生成结果，这在写库、下单、发消息等场景会造成重复数据。处理办法是在业务层做去重：给每个请求生成一个 request_id，在结果落地时检查是否已经处理过。这个细节看着不大，但线上出问题的时候都是大问题。
4.5 流式响应断流：SSE 的隐藏坑
如果用 stream=True，服务端会通过 SSE（Server-Sent Events）连续推送数据块，客户端逐块解析。流式的坑在于：连接可能中途断掉，但前面已经收到一半内容了。
我处理流式断流的思路是：
- 给流式读取设置独立的 read timeout，不要和普通请求共用同一套值；
- 解析时对不完整的数据块做容错，标准 SSE 行必须以
data:开头，结束标志是data: [DONE]； - 检测到断流后，如果业务允许，用一条"继续"消息重新发起补齐请求，而不是直接返回空结果给用户。
这类问题在本地测试时很难暴露，因为网络环境好，但部署到实际服务器后，跨机房、跨区域的长连接最容易出现读超时。接入前最好用长时间的流式测试压一下通道。
4.6 日志、用量与监控：稳定性不能凭感觉
稳定性的另一个前提是可观测。我接入任何 GPT API 项目时，最先加的不是复杂监控系统，而是最基础的日志字段：
- 请求时间；
- 模型名；
- 延迟；
- 状态码；
- usage 里的 prompt_tokens 和 completion_tokens。
有了这些日志，你可以随时回答三个问题：系统健康吗？这个月花了多少钱？最近出错是哪类错误？
再往上一步，按小时聚合 token 用量和错误率，做成简单的报表或者接入 Prometheus 类系统。不需要很复杂，但必须能看到趋势。稳定性问题大多是慢慢恶化的，今天成功率 99%，下周变 98%，没有监控你根本发现不了。
4.7 多通道容灾：什么时候触发切换
如果你的业务对可用性要求高，可以考虑配置主备两个通道。但触发切换的条件要设计得清晰，不能看到一两个 500 就切，那会造成颠簸。
我常用的触发条件是：连续失败次数达到阈值，或者最近 5 分钟窗口内可用率跌破预设值。比如连续失败 3 次，就把流量切到备用通道。切换后一定要保留日志，方便事后核对两个通道的账单和错误分布。
这里提醒一句，选择多通道容灾时只选择合法合规的服务商和官方渠道。通道越多，越要关注数据安全和供应商信誉，不要在稳定性上省事，在合规上省心。
5. 接入前必跑的 5 分钟验证脚本和检查清单
5.1 最小验证脚本：一步验证地址、模型、鉴权、延迟
下面的脚本是我每次接入 GPT API 时都会跑一次的最小验证，它能在几十秒内把地址、模型、鉴权、延迟全部测一遍：
import os import time import openai from dotenv import load_dotenv load_dotenv() client = openai.OpenAI( api_key=os.getenv("GPT_API_KEY"), base_url=os.getenv("GPT_API_BASE_URL"), timeout=30.0, max_retries=0, ) start = time.time() resp = client.chat.completions.create( model=os.getenv("GPT_MODEL"), messages=[{"role": "user", "content": "reply with OK"}], max_tokens=20, ) latency = time.time() - start print("model:", resp.model) print("latency:", round(latency, 2), "s") print("usage:", resp.usage) print("finish_reason:", resp.choices[0].finish_reason)跑出来的结果要注意看三个点：usage里的 token 数是否合理、finish_reason是不是stop（如果显示length说明 max_tokens 太小）、延迟是否在你的接受范围内。一次通过，后面按这个基础写业务就稳了。
5.2 并发快速测试：看看真实负载下的表现
单请求通了不代表并发没问题。做一个轻量级并发测试，用 10 个线程同时发 10 个请求：
import concurrent.futures import time import openai client = openai.OpenAI( api_key=os.getenv("GPT_API_KEY"), base_url=os.getenv("GPT_API_BASE_URL"), timeout=30.0, max_retries=0, ) def test_one(_): start = time.time() try: resp = client.chat.completions.create( model=os.getenv("GPT_MODEL"), messages=[{"role": "user", "content": "reply OK"}], max_tokens=10, ) return True, time.time() - start except Exception as e: return False, time.time() - start with concurrent.futures.ThreadPoolExecutor(max_workers=10) as pool: results = list(pool.map(test_one, range(10))) success = sum(1 for ok, _ in results if ok) avg_latency = sum(t for _, t in results) / len(results) print(f"success rate: {success}/10, avg latency: {avg_latency:.2f}s")这个结果能帮你判断通道在并发场景下是否会出现大量 429 或 5xx。如果 10 个并发就有好几个失败，赶紧回去看配额，这种通道进生产环境迟早出事。
5.3 正式接入检查清单
最后，把上面所有内容汇总成一份可以贴在团队文档里的检查清单：
| 检查项 | 完成标准 |
|---|---|
| API 地址 | 已写入环境变量，带/v1后缀，无多余斜杠 |
| 鉴权方式 | 已确认是否需要额外请求头，curl 可正常返回模型列表 |
| 模型名 | 已从/v1/models列表复制模型 ID，不手敲 |
| 模型能力 | tools、JSON、Vision、Stream 四类参数已实测透传 |
| 计费倍率 | 已用最小请求验证实际倍率，并写入成本公式 |
| 超时配置 | connect timeout 与 read timeout 已分别设置 |
| 重试策略 | 429/5xx/超时会重试，4xx 不会重试，业务层有去重 |
| 日志字段 | 已记录时间、模型、延迟、状态码、usage |
| 监控阈值 | 可用率和错误率有告警 |
| 容灾方案 | 主备通道与切换条件已明确 |
如果你能在一天内把这张表填完，这个 GPT API 接入项目就算基础扎实了。
6. 常见问题速查与踩坑记录
接入过程中已经踩过太多坑，这里把我碰到过的问题整理成一个速查表，照着查比重新翻文档快得多：
| 症状 | 可能原因 | 优先排查 |
|---|---|---|
| 401 Unauthorized | key 错误或鉴权头格式不对 | 检查 curl 请求头是否带Bearer |
| 404 Not Found | 地址少了/v1或路径错 | 用GET /models验证地址 |
| 400 model not found | 模型名大小写、版本、空格不匹配 | 拉模型列表对照 |
| 400 invalid parameter | 传了网关不支持的参数 | 对照网关文档删减参数 |
| 429 | 超过 RPM/TPM 配额或余额不足 | 读 Retry-After，检查配额 |
| 500/502/503 | 网关侧不稳定 | 加重试，查网关状态页 |
| finish_reason=length | max_tokens 太小 | 调大 max_tokens |
| 流式中断 | read timeout 太短或网关断流 | 调大超时，增加断流重试 |
| 成本异常偏高 | 倍率没验证或上下文未裁剪 | 查倍率，做历史消息裁剪 |
举一个真实的例子。之前有个项目在联调阶段一切正常，上线后用户反映"偶尔回复消失"。查日志发现，所有出问题的请求都是流式请求，且都是传输到一半连接断开。根因是代码里把 read timeout 设成了 10 秒，而模型生成长回答时，中间如果连续几秒没有新数据到达，连接就被本地掐断了。换成 60 秒之后问题彻底消失。这类问题不看日志根本定位不到。
还有一个和倍率相关的教训。我用一个第三方网关跑一个批量摘要任务，单条成本按官方价估算很低，但月结账单出来后发现超支好几倍。一查才知道网关对输出 token 按 3 倍收费，而摘要任务恰恰以输出为主。从那以后，"验证实际倍率"成了我所有接入项目的强制项，不再只依赖文档。
最后说点个人的操作习惯
我现在的习惯是，接任何 GPT API 相关项目，先把本文第四部分的验证脚本跑一遍，把结果直接贴在项目 README 里。地址、模型、倍率、稳定性这四件事，谁接手都能一眼看到结论，不用再重新踩一遍坑。
倍率这件事尤其容易被忽略，但吃过亏的人都会长记性。我曾经按官方价格给客户报了一个自动客服项目的预算，结果交付时才发现网关倍率是 2.5 倍，一个月白干。所以后来我把成本验证做成了 CI 里的一道检查：每次换模型或换网关，先跑一次带 usage 统计的用例，顺便把 max_tokens 的上下限都钳制住。
最后分享一个小而实用的习惯：在业务代码里为每个请求记录 prompt_tokens 和 completion_tokens，存到日志里。短期看只是多两行字段，长期看它就是你的成本报表和最可靠的稳定性数据。很多线上问题排查到最后，真正帮上忙的往往不是复杂监控，而是这些一开始觉得麻烦的基础日志。
