AI API调用实战：解决高延迟、限流与鉴权三大难题

1. 项目概述当AI API成为瓶颈我们如何自救最近在项目里深度折腾了几个大模型API从OpenAI、Claude到国内的DeepSeek、通义千问几乎把能踩的坑都踩了一遍。最让人头疼的不是模型效果而是那些“基础设施”问题请求发出去石沉大海等了十几秒才返回一个超时错误明明没调用几次突然就收到“Rate Limit Exceeded”的警告更别提那些让人摸不着头脑的“401 Unauthorized”或者“403 Forbidden”了。这些问题不解决再好的模型能力也发挥不出来整个应用体验直接崩盘。这篇文章就是我这段时间的实战总结针对AI API调用中最常见的三个拦路虎——高延迟、被限流、鉴权报错分享三种经过实测的解决方案。我不会只讲理论而是会结合具体场景告诉你每一步该怎么操作参数怎么调以及背后为什么要这么做的逻辑。无论你是刚接触AI应用开发的工程师还是正在为线上服务的稳定性发愁的架构师这些经验都能帮你快速定位问题找到成本可控、效果显著的优化路径。2. 核心问题拆解延迟、限流与鉴权的本质在动手解决问题之前我们必须先理解这三个问题的根源。它们看似独立实则相互关联共同构成了AI API调用的“稳定性三角”。2.1 高延迟不只是网络问题很多人一遇到API响应慢第一反应就是“网络不好”。这固然是一个因素但对于AI API来说延迟的来源要复杂得多。我们可以把一次完整的API调用拆解成几个阶段客户端到API网关的网络延迟这是物理距离和网络路由决定的。API网关的排队与处理延迟当请求量激增时服务商的网关可能需要进行队列管理、负载均衡。模型推理的计算延迟这是大头。模型参数规模7B、70B、千亿级、输入Token长度、请求的复杂度是否开启流式输出、思维链直接影响计算时间。服务商内部的调度与资源分配延迟尤其是在使用共享或按需计费的API时你的请求可能需要等待空闲的计算资源。高延迟的直接表现就是用户体验卡顿异步任务队列堆积。更隐性的危害在于它可能导致客户端因超时而重试反而加剧了服务端的负载形成恶性循环。2.2 被限流资源保护的必然手段限流是API服务商保护自身后端资源、保证服务公平性的核心机制。常见的限流维度包括请求频率RPM/QPM每分钟/每秒的请求次数。Token消耗速率TPM每分钟消耗的Token总数包括输入和输出。这是大模型API特有的、更精准的限流方式因为它直接对应了计算成本。并发连接数同时处理的请求数量。日/月调用总量针对免费额度或套餐的总额限制。触发限流后通常会收到429 Too Many Requests的HTTP状态码并可能伴随一个Retry-After头部提示你多久后可以重试。盲目重试只会让情况更糟。2.3 鉴权报错身份验证的“门卫”鉴权失败通常返回401认证信息无效或403认证通过但权限不足。原因可能很琐碎API Key错误或过期复制粘贴时多了空格、Key被意外轮换。请求格式不正确Authorization头格式不对例如少了Bearer前缀或者API Key被放错了位置如Query参数 vs Header。IP或域名不在白名单内一些服务商的安全策略。账户欠费或额度用尽返回的可能是402 Payment Required或429。请求的模型或端点无权访问比如你的套餐只支持gpt-3.5-turbo却请求了gpt-4。鉴权问题虽然原因简单但一旦出现整个调用链路会立刻中断是最需要优先排除的一类问题。3. 解决方案一构建智能客户端与连接优化策略面对延迟我们不能只依赖服务商优化。在客户端和网络层做文章往往能取得立竿见影的效果。这里的核心思路是“减少无效等待优化有效连接”。3.1 实现具备退避与熔断机制的智能重试直接使用简单的while循环进行重试是灾难性的。一个健壮的重试逻辑必须包含指数退避和熔断器模式。指数退避每次重试的等待时间按指数级增长例如 1s, 2s, 4s, 8s...并加上一个随机抖动Jitter避免大量客户端在同一时刻重试导致“惊群效应”。import random import time from typing import Callable, Optional def retry_with_backoff( func: Callable, max_retries: int 5, initial_delay: float 1.0, max_delay: float 60.0, jitter: bool True ): 带指数退避和抖动的重试装饰器/函数 retries 0 delay initial_delay while retries max_retries: try: return func() except Exception as e: retries 1 if retries max_retries: raise e # 计算本次等待时间 current_delay min(delay, max_delay) if jitter: # 增加最多25%的随机抖动 current_delay current_delay * (0.75 0.5 * random.random()) print(f请求失败: {e}. 第 {retries} 次重试等待 {current_delay:.2f} 秒...) time.sleep(current_delay) delay * 2 # 指数增长熔断器模式当失败率超过某个阈值时熔断器“跳闸”短时间内直接拒绝所有请求而不是继续访问可能已经故障的服务。经过一段冷却时间后进入“半开”状态试探性放行少量请求如果成功则关闭熔断器恢复服务。实操心得对于网络超时TimeoutError和速率限制429一定要采用退避重试。但对于鉴权错误401/403重试是没用的必须立即失败并告警因为这是配置问题。我通常会在客户端初始化时就对API Key做一个简单的预验证比如发一个极短的测试请求提前发现问题。3.2 连接池与长连接优化对于高频调用的服务为每个请求创建新的TCP连接HTTP/1.1会带来巨大的开销。解决方案是使用HTTP连接池。Python (aiohttp/httpx)aiohttp.ClientSession和httpx.AsyncClient默认就维护了连接池。关键是要复用同一个session或client实例而不是每次请求都新建。import httpx # 错误做法每次新建client # async with httpx.AsyncClient() as client: ... # 正确做法在应用生命周期内复用同一个client class AIClient: def __init__(self): self.client httpx.AsyncClient( timeout30.0, limitshttpx.Limits(max_keepalive_connections100, max_connections1000) )调整超时时间为不同的操作设置合理的超时。连接超时connect_timeout可以设短一点如5秒而读取超时read_timeout则要根据模型和输入长度来定对于长文本生成可能需要60秒甚至更长。3.3 地域与端点选择策略服务商通常在全球有多个接入点。选择离你服务器或主要用户群体物理距离更近的端点能显著降低网络延迟。OpenAI除了默认的api.openai.com还有api.openai.com.azure.com如果你用Azure以及一些第三方代理端点需注意安全合规。国内模型阿里云、百度智能云等在国内多个区域都有节点。例如你的服务器在华东1杭州那么调用华东2上海的端点就会比调用华北2北京的延迟低。一个简单的策略是在应用启动时对几个候选端点进行一次延迟探测Ping或发起一个轻量级API请求选择延迟最低的作为主用端点并定期更新这个选择。4. 解决方案二设计面向限流的自适应请求队列当限流不可避免时我们的目标从“避免限流”转变为“优雅地应对限流”并最大化利用允许的配额。这需要一套系统性的队列与调度策略。4.1 理解Token限流与请求限流这是最关键的一步。很多开发者只关注RPM每分钟请求数但像OpenAI、Claude等主流API其最核心的限制是TPMTokens Per Minute和RPM共同作用。TPM限制与你消耗的计算资源直接挂钩。一个包含1000个输入Token和生成500个输出Token的请求消耗的Token配额远大于一个简单的对话请求。RPM限制防止你通过海量小请求冲击网关。你的客户端必须能估算每次请求的Token消耗。虽然精确计算需要模型的分词器但我们可以用近似值如len(text) / 4估算英文Token数或调用API的元数据部分API会在响应中返回usage字段来跟踪。4.2 实现基于令牌桶的客户端限流器我们可以在客户端模拟一个“令牌桶”其速率和服务商的限流规则对齐。例如服务商限制 10000 TPM 和 100 RPM那么我们的客户端桶就应该以相应的速率补充令牌。import asyncio import time from collections import defaultdict class AdaptiveRateLimiter: def __init__(self, requests_per_minute: int, tokens_per_minute: int): self.requests_per_minute requests_per_minute self.tokens_per_minute tokens_per_minute self.request_tokens 0 self.token_bucket 0 self.last_update time.time() self.lock asyncio.Lock() async def acquire(self, estimated_tokens: int) - bool: 尝试获取执行一次请求的许可 async with self.lock: now time.time() elapsed now - self.last_update self.last_update now # 补充令牌 self.request_tokens min(self.requests_per_minute, self.request_tokens elapsed * (self.requests_per_minute / 60)) self.token_bucket min(self.tokens_per_minute, self.token_bucket elapsed * (self.tokens_per_minute / 60)) # 检查是否满足本次请求需求 if self.request_tokens 1 and self.token_bucket estimated_tokens: self.request_tokens - 1 self.token_bucket - estimated_tokens return True return False async def wait_for_capacity(self, estimated_tokens: int): 阻塞直到有足够容量执行请求 while not await self.acquire(estimated_tokens): # 计算需要等待的时间取请求间隔和Token补充所需时间的最大值 wait_for_request max(0, (1 - self.request_tokens) * (60 / self.requests_per_minute)) wait_for_tokens max(0, (estimated_tokens - self.token_bucket) * (60 / self.tokens_per_minute)) wait_time max(wait_for_request, wait_for_tokens) 0.01 # 加一点缓冲 await asyncio.sleep(wait_time)使用这个限流器在发起请求前先调用wait_for_capacity(estimated_tokens)可以极大降低触发服务端限流的概率。4.3 构建优先级任务队列不是所有请求都同等重要。一个面向用户实时聊天的请求优先级应该高于一个后台批量处理文档的请求。我们可以引入一个优先级队列。import heapq from enum import IntEnum class Priority(IntEnum): REALTIME 1 # 用户实时交互 BATCH_HIGH 2 # 重要的后台任务 BATCH_LOW 3 # 低优先级的批量任务 class PriorityTaskQueue: def __init__(self, rate_limiter: AdaptiveRateLimiter): self.queue [] self.rate_limiter rate_limiter self.worker_task None def add_task(self, priority: Priority, estimated_tokens: int, task_func, *args, **kwargs): 添加任务到队列 # 使用 heapq优先级数字小的先出队 heapq.heappush(self.queue, (priority.value, estimated_tokens, task_func, args, kwargs)) async def start_worker(self): 启动队列处理worker while True: if not self.queue: await asyncio.sleep(0.1) continue priority, estimated_tokens, task_func, args, kwargs heapq.heappop(self.queue) await self.rate_limiter.wait_for_capacity(estimated_tokens) try: await task_func(*args, **kwargs) except Exception as e: # 处理任务执行异常例如记录日志、重试或放入死信队列 print(f任务执行失败: {e})这个队列确保了高优先级请求总能优先获得资源同时在达到限流阈值时低优先级任务会自然排队等待而不是被粗暴地拒绝。4.4 动态配额感知与降级在微服务架构中你的应用可能同时调用多个AI服务商作为降级或特性备用。更高级的策略是建立一个“配额管理器”动态感知各渠道的剩余配额和速率限制智能地将请求路由到当前最“宽松”的渠道。当主渠道接近限流时自动将部分流量切换到备用渠道或对非关键功能采用更低成本的模型如从GPT-4降级到GPT-3.5-Turbo作为降级策略。5. 解决方案三建立稳健的鉴权与密钥管理体系鉴权问题看似简单但在分布式、多环境、多密钥的场景下管理不善极易导致线上故障。一套稳健的密钥管理体系是保障API调用稳定的基石。5.1 密钥的存储与轮换策略绝对不要将API Key硬编码在代码或配置文件里提交到代码仓库。使用环境变量这是最基本的要求。通过os.getenv(OPENAI_API_KEY)读取。使用密钥管理服务在生产环境中应使用专业的密钥管理服务如AWS Secrets Manager、Azure Key Vault、HashiCorp Vault或阿里云KMS。这些服务提供加密存储、自动轮换、访问审计等功能。密钥轮换定期轮换API Key是安全最佳实践。你需要一个无缝的轮换机制。例如在密钥管理服务中同时存储新、旧两套Key。客户端优先尝试新Key如果失败可能因为旧Key还未完全失效则尝试旧Key并在日志中告警提示管理员检查轮换状态。5.2 实现客户端鉴权封装与健康检查将鉴权逻辑封装在一个统一的客户端类中并加入健康检查。import os import httpx from typing import List, Optional class AIServiceClient: def __init__(self, api_keys: List[str], base_url: str): if not api_keys: raise ValueError(至少需要一个API Key) self.api_keys api_keys self.current_key_index 0 self.base_url base_url self.client httpx.AsyncClient(base_urlbase_url) self._healthy True def _get_current_key(self) - str: return self.api_keys[self.current_key_index] def _rotate_key(self): 轮转到下一个可用的Key self.current_key_index (self.current_key_index 1) % len(self.api_keys) print(f切换到API Key索引: {self.current_key_index}) async def health_check(self) - bool: 执行一个轻量级健康检查例如获取模型列表 try: # 以OpenAI为例一个轻量的检查请求 headers {Authorization: fBearer {self._get_current_key()}} resp await self.client.get(/v1/models, headersheaders, timeout10.0) if resp.status_code 200: self._healthy True return True elif resp.status_code in [401, 403]: print(f健康检查失败Key可能失效。状态码: {resp.status_code}) self._healthy False return False else: # 其他错误可能是网络或服务临时问题 print(f健康检查异常状态码: {resp.status_code}) return False except Exception as e: print(f健康检查异常: {e}) self._healthy False return False async def request_with_auth_retry(self, method, endpoint, **kwargs): 带鉴权重试的请求封装 max_key_retries len(self.api_keys) for attempt in range(max_key_retries): headers kwargs.get(headers, {}) headers[Authorization] fBearer {self._get_current_key()} kwargs[headers] headers try: resp await self.client.request(method, endpoint, **kwargs) if resp.status_code not in [401, 403]: return resp # 成功或非鉴权错误直接返回 # 如果是鉴权错误尝试下一个Key print(f请求鉴权失败 (状态码 {resp.status_code})尝试轮换Key...) self._rotate_key() if attempt max_key_retries - 1: # 所有Key都试过了仍然失败 return resp except httpx.HTTPStatusError as e: if e.response.status_code in [401, 403]: print(fHTTP状态错误鉴权失败尝试轮换Key...) self._rotate_key() if attempt max_key_retries - 1: raise else: raise e # 理论上不会走到这里 raise Exception(所有API Key尝试失败)这个客户端类实现了多个功能多Key轮询、自动鉴权重试、简单的健康检查。在应用启动时可以调用health_check()来验证配置是否正确。5.3 请求签名与精细化权限控制高级对于企业级应用或自建AI网关简单的Bearer Token可能不够。你可能需要实现更安全的请求签名类似于AWS Signature Version 4。其核心是使用密钥对请求的特定部分如方法、路径、时间戳、部分Header生成一个哈希签名放在Authorization头中。服务端用同样的算法验证确保请求在传输过程中未被篡改并且具有时效性通过时间戳防止重放攻击。此外在服务商平台可以为不同用途创建多个API Key并分配不同的权限和额度。例如线上应用Key较高的TPM/RPM限制用于生产环境。数据分析Key较低的速率限制但可能拥有访问特定数据导出API的权限。开发测试Key额度很低仅用于开发和测试环境。这样即使一个Key泄露或滥用影响范围也是可控的。6. 实战搭建一个简单的AI API代理网关将上述策略整合一个最直接的方式是搭建一个轻量级的AI API代理网关。它位于你的应用和多个AI服务商之间集中处理限流、重试、降级、鉴权管理和监控。这里给出一个使用FastAPI的极简示例框架。from fastapi import FastAPI, HTTPException, Request from fastapi.responses import StreamingResponse import httpx import asyncio from typing import List import time app FastAPI() # 模拟配置多路AI服务端点 AI_BACKENDS [ {name: openai_primary, base_url: https://api.openai.com/v1, api_key: sk-xxx, priority: 1, tpm_limit: 90000, rpm_limit: 3000}, {name: openai_fallback, base_url: https://api.openai.com/v1, api_key: sk-yyy, priority: 2, tpm_limit: 90000, rpm_limit: 3000}, {name: azure_openai, base_url: https://your-resource.openai.azure.com/openai/deployments/your-deployment, api_key: azure-xxx, priority: 3, tpm_limit: 60000, rpm_limit: 1200}, ] class BackendManager: def __init__(self, backends): self.backends backends # 为每个后端初始化一个限流器这里简化实际应更复杂 for b in backends: b[limiter] AdaptiveRateLimiter(b[rpm_limit], b[tpm_limit]) self.client httpx.AsyncClient() async def select_backend(self, estimated_tokens: int) - dict: 根据优先级、健康状态和剩余配额选择后端 healthy_backends [b for b in self.backends if b.get(healthy, True)] if not healthy_backends: raise HTTPException(status_code503, detailNo healthy AI backend available) # 简单策略按优先级排序选择第一个有配额的后端 for backend in sorted(healthy_backends, keylambda x: x[priority]): # 这里应调用限流器的非阻塞检查方法为简化示例我们假设直接通过 # 实际生产环境需要更复杂的决策逻辑 if await backend[limiter].acquire(estimated_tokens): return backend # 如果没有后端有即时配额可以等待或返回错误 raise HTTPException(status_code429, detailAll backends are rate limited. Please try later.) async def forward_request(self, backend: dict, path: str, request: Request): 将请求转发到选定的后端 url f{backend[base_url].rstrip(/)}/{path.lstrip(/)} headers {key: value for key, value in request.headers if key.lower() not in [host, authorization]} headers[Authorization] fBearer {backend[api_key]} # 处理流式响应 if stream in request.query_params: async def stream_generator(): async with self.client.stream( request.method, url, headersheaders, paramsrequest.query_params, contentawait request.body() ) as response: async for chunk in response.aiter_bytes(): yield chunk return StreamingResponse(stream_generator(), media_typetext/event-stream) else: # 非流式响应 resp await self.client.request( request.method, url, headersheaders, paramsrequest.query_params, contentawait request.body() ) return resp.content, resp.status_code, resp.headers backend_manager BackendManager(AI_BACKENDS) app.api_route(/{path:path}, methods[GET, POST, PUT, DELETE]) async def proxy_request(path: str, request: Request): 代理所有请求到AI后端 # 1. 估算Token这里需要根据实际请求体估算简化处理 # 可以从request body中解析messages或prompt来粗略估算 estimated_tokens 100 # 示例值实际需要计算 # 2. 选择后端 try: selected_backend await backend_manager.select_backend(estimated_tokens) except HTTPException as e: raise e # 3. 转发请求 try: content, status_code, headers await backend_manager.forward_request(selected_backend, path, request) # 4. 返回响应 # 注意需要过滤掉后端返回的一些敏感头信息 excluded_headers [content-encoding, content-length, transfer-encoding, connection] filtered_headers {k: v for k, v in headers.items() if k.lower() not in excluded_headers} return StreamingResponse(iter([content]), status_codestatus_code, headersfiltered_headers) except httpx.HTTPStatusError as e: # 处理后端返回的错误 raise HTTPException(status_codee.response.status_code, detaile.response.text) except Exception as e: raise HTTPException(status_code500, detailstr(e)) if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)这个网关实现了最基本的路由和代理功能。在实际生产中你还需要加入更精确的Token估算集成tiktoken等库。完善的监控与告警记录每个后端的延迟、成功率、限流触发情况。配置热更新无需重启服务即可更新后端列表和限流配置。请求/响应改写统一不同后端的API格式差异。7. 常见问题排查与调试技巧实录理论说再多不如实战中遇到的坑来得深刻。下面是我在调试AI API问题时积累的一些“血泪”经验和排查清单。7.1 延迟高问题排查清单定位延迟阶段使用curl或httpx记录每个阶段的时间。curl -w \n时间统计:\n 域名解析: %{time_namelookup}s\n 建立连接: %{time_connect}s\n SSL握手: %{time_appconnect}s\n 发送请求: %{time_pretransfer}s\n 开始传输: %{time_starttransfer}s\n 总时间: %{time_total}s\n \ -H Authorization: Bearer YOUR_KEY \ https://api.openai.com/v1/chat/completions \ -d {model:gpt-3.5-turbo,messages:[{role:user,content:Hello}]}time_namelookup高DNS问题。time_connect高网络路由或防火墙问题。time_starttransfer减去time_pretransfer高服务端处理慢排队或计算。检查请求体是否无意中发送了巨大的上下文比如整个文档是否开启了不必要的参数如stream: true虽然流式能提升感知速度但可能增加总耗时max_tokens是否设得过高对比测试用同样的请求体调用不同的模型如从gpt-4换到gpt-3.5-turbo或不同的服务商看延迟差异是否巨大。这有助于判断是通用网络问题还是特定模型/服务商的问题。7.2 限流问题排查清单仔细阅读错误信息429错误体里通常包含limit,remaining,reset等信息。例如OpenAI的响应头里可能有x-ratelimit-limit-requests,x-ratelimit-remaining-requests,x-ratelimit-reset-requests。把这些信息记录下来并展示在你的监控面板上。区分限制维度你是触发了RPM限制还是TPM限制如果是TPM限制检查你的应用是否突然产生了超长文本的请求。一个包含数万Token的请求可能会瞬间耗光你的分钟配额。检查是否由重试引起在没有退避机制的情况下一个请求失败导致瞬间重试10次很可能直接触发限流。确保你的重试逻辑是“友好”的。账户级 vs 密钥级限制有些限制是针对整个账户的有些是针对单个API Key的。如果你有多个Key确保流量均匀分布。7.3 鉴权报错排查清单Key本身最简单的方法去服务商的控制台检查Key是否被禁用、是否已过期、额度是否用完。请求头用工具如mitmproxy或代码打印抓取实际发出的HTTP请求确认Authorization头的格式完全正确。最常见错误是Bearer后面少空格或者Key前后有多余的空格、换行符。请求端点与模型确认你调用的API端点URL和模型名称model参数在你的套餐内是有效的。例如某些Beta版的模型可能不对所有用户开放。IP限制如果你的服务商设置了IP白名单请确保你发出请求的服务器的公网IP在名单内。注意云服务器重启或弹性伸缩可能改变IP。时间戳如果你使用了请求签名检查客户端和服务端的时间是否同步误差通常在5分钟内。时间不同步会导致签名立即失效。7.4 一个综合性的调试脚本最后分享一个我常用的简易调试脚本它集成了超时、重试、详细的日志输出能帮你快速定位问题根源。import asyncio import httpx import json import time async def debug_ai_api_call(api_url, api_key, payload, max_retries3): 一个带详细日志的AI API调试函数 headers { Authorization: fBearer {api_key}, Content-Type: application/json } timeout httpx.Timeout(connect10.0, read60.0, write10.0, pool1.0) limits httpx.Limits(max_keepalive_connections5, max_connections10) async with httpx.AsyncClient(timeouttimeout, limitslimits) as client: for attempt in range(max_retries 1): start_time time.time() try: print(f\n 尝试第 {attempt 1} 次调用 ) print(f目标URL: {api_url}) print(f请求头 (隐藏Key): { {k: (*** if auth in k.lower() else v) for k, v in headers.items()} }) print(f请求体大小: {len(json.dumps(payload))} 字节) response await client.post(api_url, jsonpayload, headersheaders) elapsed time.time() - start_time print(f响应状态码: {response.status_code}) print(f耗时: {elapsed:.2f} 秒) print(f响应头: {dict(response.headers)}) if response.status_code 200: print(调用成功) # 尝试解析JSON响应 try: result response.json() print(f响应体 (前500字符): {json.dumps(result)[:500]}...) # 如果有usage信息打印出来 if usage in result: print(fToken消耗: {result[usage]}) return result except json.JSONDecodeError: print(f响应体 (文本): {response.text[:500]}...) return response.text else: print(f调用失败错误信息: {response.text}) # 处理特定错误 if response.status_code 429: retry_after response.headers.get(Retry-After) if retry_after: wait int(retry_after) print(f收到429限流建议等待 {wait} 秒后重试。) if attempt max_retries: print(f等待 {wait} 秒...) await asyncio.sleep(wait) continue elif response.status_code in [401, 403]: print(鉴权失败请检查API Key和权限。无需重试。) break # 鉴权错误不重试 else: # 其他错误使用指数退避重试 if attempt max_retries: wait_time (2 ** attempt) 1 print(f{wait_time} 秒后重试...) await asyncio.sleep(wait_time) continue except httpx.ConnectTimeout: print(f连接超时 (尝试 {attempt 1})) if attempt max_retries: await asyncio.sleep(2 ** attempt) continue except httpx.ReadTimeout: print(f读取超时服务器处理时间过长 (尝试 {attempt 1})) # 对于读超时可以考虑增加超时时间或直接失败 break except Exception as e: print(f未知异常: {type(e).__name__}: {e}) break print(\n 所有重试尝试均失败 ) return None # 使用示例 async def main(): result await debug_ai_api_call( api_urlhttps://api.openai.com/v1/chat/completions, api_keyyour-api-key-here, payload{ model: gpt-3.5-turbo, messages: [{role: user, content: Hello, debug me!}], max_tokens: 50 } ) print(result) if __name__ __main__: asyncio.run(main())把这个脚本保存下来遇到任何调不通的情况先用它跑一遍大部分时候你都能从详细的输出里找到线索。